Development cycles
just saw the news about the Drupal 7 Release Candidate. I could not be more perplex with the length of its cycle. The code freeze was announced in September 15, 2009, so its more than a year!
I’m perplex mostly because of the nature of this software: an internet application. Because the internet environment changes in an incredible pace, its really counterproductive to stop accepting deep modifications for so long time. NoSQL databases are getting more and more used, JavaScript techniques getting more refined and the whole HTML5/Video is dominating news. Two years to launch a new version is quite a lot.
I have a hunch: Drupal 5 was a true revolution but had a quite short life cycle, coz Drupal 6 was released soon after. I believe several developers got pissed with that as they were forced to make a long conversion process from Drupal 4 to 5 and than from 5 to 6. Drupal 6 took quite some time to actually be used by old sites, because several important modules (Views and CCK mainly) delayed the port to see what direction D7 would take. The result is that Drupal 6 was coined “Drupal Vista: wait for the 7”. This might be forced Drupal core guys to extend the cycle.
The whole problem is now gone since most sites are now ported to D6. But I really believe that was not matter of the short-cycles-that-pressure-developers, but the lack of clear support from project managers. I say that because some even more complex programs are getting big supporters, despite the apparent paradox.
The most enlightening example is Google. Google’s most popular softwares adopted the strategy of the “fast iterations”. The idea is not to aim “quality at all cost” (typical for projects that release when it is ready) but “to fix as soon as possible”. Chrome is 3 years old or so and it is in version 9! The adoption rate is even bigger than Firefox! Android is in version 2.2 already and gaining more and more support of developers. Can you imagine a more complex software with a faster release cycle?
Faster cycles have several advantages:
- Gain easy testers with the early adopters
- Avoid that small enhancements being postponed for years just because is a “new feature”
- Avoid the proliferation of hacks-as-plugins that implement the small enhancements I just mentioned
- Revert wrong decisions often
- Encourage more people to participate to the core development, since their suggestions might be implemented soon after
- Avoid analysis-paralysis loop of each change
- Reduces the possibility of forks (what is the advantage of Pressflow if Drupal 7 was released quite after?)
I think Drupal community still is somewhere between The Cathedral and the Bazaar. They are still in CVS mentality of a centralized control and serialized development of features. We have to make features in parallel, not in series. So no more “feature freeze”, “guys, lets think about the next version… ideas?”. Every time is time to release a new features. It has to create several forks (and not only patches) that will work on each features and, when any of them are ready, commit into mainstream and launch as a new small version, like 7.1, 7.2, 7.3…
One last comment for those that think several people want stability over cutting edge stuff. It’s just to maintain a similar concept used by Ubuntu: time to time a given release will be considered “long term support”. And if Drupal 7.2 is LTS, for example, it could be released several other “features-releases” like 7.3, 7.4 and several “bug-releases” for 7.2, like 7.2.1, 7.2.2, 7.2.3… Fixed time support also gives business and people the right information for a proper planning.
