Linux kernel

The Linux kernel project has seen major changes to its development and release strategy in the last few years, in particular since the first stable release of the 2.6 series in December 2003. This series was opened almost three years after the 2.4 series in January 2001, which many felt was too long. A problem that resulted from the long interval between major releases was that vendors had to back- and forward-port a lot of patches. Nowadays, major development happens on the 2.6 series and new releases are published every three to four months. This new development model has faced much controversy. While some people, in particular developers of the kernel, claim that the new model is working very well, some users are worried about the number of significant changes and lack of stability in the kernel. Andrew Morton, a lead developer, has expressed several times that he believes the kernel is getting buggier.

Past problems

• Because of the long release cycle, many changes accumulated. It was hard to get the development stable and there were few testers.
• Features got out very slowly because of the long release cycle.
• Hardware support and crucial features had to be backported to the latest stable kernel.
• Vendors backported many features to their own releases. The code base from different vendors diverged a lot from each other and from the official development version.

Solutions

• New versions are now released every two or three months. There is a two week merge window after each release during which new features are accepted; subsequently, the focus is on stabilization.
• There is now a steady flow of code into production and many people get to test the new code.
• Features get out more quickly.
• Vendors can directly work with current releases and get their changes into official versions easily.

Outstanding problems

• There is no long-term stable version based on the 2.6 kernel. This is being addressed with Adrian Bunk's 2.6.16 long-term maintenance tree but whether it will have a big impact remains to be seen.
• Regressions between versions are introduced more frequently. Better control and tracking of regressions are needed.
• The Bugzilla bug tracker needs to be integrated better into the development process and it would be helpful to have a QA person. In January 2007, Google announced that they're looking for a kernel QA person who'd work together with Andrew Morton.

GNOME

GNOME provides a complete desktop environment that is easy to use. The project experienced major problems, such as delays, during its 1.x series and in particular during the preparation of its 2.0 release. GNOME introduced time based releases after its 2.0 release and has significantly improved release management. The project has published time based releases every six months for a number of years now and is considered as the reference model for a good implementation of time based release management. They have shown that it's possible to set and meet deadlines in volunteer projects and to release on time.

Past problems

• The main goal of version 2.0 was to change internal interfaces but after more than a year of work the project felt they had to deliver more user-visible changes, therefore leading to delays.
• Developers were disappointed with delays and that their work was not available to users.
• It was not clear what was going on. Developers constantly had to ask about the release status.
• Freezes were announced and people worked towards them but then they were delayed. Freezes also often came unexpectedly.
• Vendors had deadlines but the GNOME schedule was unpredictable. Vendors did not know whether they should aim for the next version or focus on the previous version and backport fixes.
• Vendors had to backport many changes to a version that the GNOME project considered as old.

Solutions

• The project introduced a rigorous schedule promising a release every six months.
• There was a core team so few people had to agree to the introduction of a schedule.
• GNOME introduced policies to keep the development tree fairly stable.
• The project introduced the idea of reverting: if a feature was not ready on a certain cut-off date, it would be taken out again.
• The project gained credibility because releases were actually performed on time.
• The schedule allowed vendors better planning, and hence vendors could implement their features on the main development tree.

Outstanding problems

• The six month schedule has been successful in the delivery of incremental updates. There are some concerns whether this release cycle makes the project less innovative and ambitious regarding major changes that would lead to GNOME 3.0.