?

Log in

No account? Create an account

Calendaring Out Releases

« previous entry | next entry »
Jan. 31st, 2007 | 08:15 pm

So while flying to Boston I started thinking a bit more about how releases work in a calendar year and how open source releases work in general.

What made me first think about this was developer quorum.

What is developer quorum?

Developer Quorum is any period of time where you have enough developers to complete a release or undertake a major distribution of software. To release software you really must take it into account.

For a US/European company like MySQL we see two of these periods a year:

Last week of November through the Second Week of January.
June 20th through the first week of August.

These periods are a result of the cumulative nature of the holidays for multiple countries. While there are always people around, maybe up to two-thirds at any point, you will be missing critical people.

I've yet to see an influence by China, but then at MySQL we only have a handful of Chinese developers (and currently no Indian developers in India).

For a large, and shipped, piece of software like MySQL you need roughly six weeks for a Release Candidate, assuming you are honest with your Beta. And by "honest with your beta" I mean that when you existed beta to go to release candidate your bug count really supported this.

The period of time you are in Beta is a factor of the number of features you have added to any given release. The open source community does test beta software but it doesn't test with anywhere near the energy that is applied to either release candidates or initial releases.

Initial release bugs are something both open source and closed source software share in common. In the open source world major projects seem to "shake out" within three months of an initial production release. Looking back at the Apache 2 release this was the case and with MySQL 5.0 it was the case as well. It will be interesting to see how long it takes for Vista to go through this cycle.

I believe that the frequent nature of open source releases is what makes the "three months" the magic number. Open source early adopters are more tolerant of frequent new releases then what the average consumers are (though I think this is changing), and you can quickly cycle through releases since you have an audience ready to test the software. Since the Internet is your distribution channel, your cost there is nearly zero :)

After reading my explanation of this you find yourself cringing at the loss of time, consider the solution.

Smaller, more frequent releases. Both initial release and release candidate timing is constant, so just adjust features to make your beta cycle what you need it to be.

Web development, with its short turn around time should, is the model for this. Much harder to do when you are shipping software and dealing with legacy support, but the model does prove that it can work.

One large draw back in this? Handling legacy support. The software industry lacks a good answer to this right now. The cost of "shipped" software is directly proportional to the number of years of required legacy support. I've wondered if many of the TCO analyzers have factored this in to their equations. Require longer support, and your costs will grow since the cost of support grows.

And why do I not mention Alpha releases? Alphas should not be tracked in the same manner that a Beta is. You should take specific features, develop them in branches, release these as alphas, and not apply them to the Beta until they are ready.

Sure, this will drive the marketing guys nuts, but what is the alternative?

Drawn out betas.

Which also make the marketing guys nuts.

Link | Leave a comment |

Comments {0}