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.
Version | Date | Months |
1.0 | 1999-03-03 | |
1.2 | 2000-05-25 | 15 |
1.4 | 2001-04-02 | 10 |
2.0 | 2002-06-27 | 15 |
2.2 | 2003-02-06 | 7 |
2.4 | 2003-09-11 | 7 |
2.6 | 2004-03-31 | 7 |
2.8 | 2004-09-15 | 6 |
2.10 | 2005-03-09 | 6 |
2.12 | 2005-09-07 | 6 |
2.14 | 2006-03-15 | 6 |
2.16 | 2006-09-06 | 6 |
2.18 | 2007-03-14 | 6 |
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.