It's funny and yet so sad how software professionals are secretive; protecting methods of "modern" software development like they're trade secrets. Then people write books about ten year old methods which lets the cat out of the bag for everyone and the rest of the people using twenty year old development methods "catch up" to ten years ago. Repeat cycle.

The funny thing is that the methods are not revolutionary; it's how they are used in the right combinations and adjusted according to development conditions. Software development is controlled and constant microevolution -- it's a learning process, but what's learned should be applied and not forgotten as development progresses. The process that's used should allow breathing room for this learning and changing.

No one wants their competitor to exploit their competitive edge but public discussion about software development often ends up ten years behind in yawn territory. Then along came open source projects and blogs.

Take Asa Dotzler's blog for example, where he's starting to talk more about the details of Firefox development. Firefox is part of a larger group of Mozilla projects that use common code, so all of this common code has to be coordinated and the CVS branching done in such a way as to not interrupt active development in one project while another is preparing for a release.

A specific Mozilla example is how Firefox 1.0 used a very old but stable branch of Gecko, the Mozilla project's rendering engine used in The Mozilla Suite (Seamonkey), Firefox, Thunderbird, etc. When Firefox 1.0 was finally ready to release Gecko was already half a year of development down the road and not held up by the Firefox stabilization and testing effort. Now that Firefox 1.0 is out the door the Firefox team will catch up to a more current version Gecko with the 1.1 release and then probably be well behind the bleeding edge of Gecko again by the time Firefox 2.0 arrives.

The Mozilla project is truly a great public example of modern release engineering (releng) practices. The Linux kernel is actually very straightforward and uninteresting in comparison because kernel development uses multiple active and completely independent development trees instead of Mozilla's CVS branching, committer access, bug tracking, patching and fairly formal peer review process.

A lot can be learned from Mozilla releng if you're paying attention. This is how big companies are doing releng and when the projects get this big and interdependent, you have to. But even for small projects a good releng plan can make development smoother and the team more flexible. Why doesn't your company have a releng plan?