An often raised question on drupal.org is, "when will release x.y be done?". And most often the first answer received will be "It is done when it is done." Or it is just as likely the answer will be phrased in a somewhat less friendly manner: "When is the last time you patched a bug or tested a patch?". While one of these is a question, both qualify as good answers to the question "when willl it be done?". This is because software development in the Open Source differs in some important points to traditional software development. In this posting you can read what the difference is and how you can make, be, that difference.

Software Development

Traditionally, software development is characterized by a triangle with three criteria:

• functionality
• time
• resources

Functionality being what the program offers, time the development period from scratch to when the product ships and resources the number of man-hours (and other less scarce resources like computers or CPU power) you have available for the project.

In traditional software development, the project leader juggles with these three criteria to get the product ready. Most often the time schedule of the release is fixed because of marketing reasons or rigid roadmaps. So to make the release date, the project leader can hire more resources and/or lose functionality. This method is known as timeboxing, often used in Agile Software Development.

Another way of completing a project would be by setting both the number of man-hours ("resources") and the release date ("time") as fixed constants and change the offered functionality if and when needed. This method is knows as the DSDM(ethod). Here the project leader has to discuss the MoSCoW functionality with the customer to fit in the fixed constraints. Other methods as described exist and might fit the needs of a project.

With Open Source software development however, such as is the case with Drupal’s developments, there are no fixed constraints. The number of resources is not known, people might join to code or leave with uncompleted work. People might promise to do some work but will never finish it and someone unknown might step in and deliver bulks of golden code. Neither is the release date known or fixed. We do have a tradition of delivering two or three major releases per year, but we don’t have a marketing division that wants to ship 12.0 before the competition ships 11.6. As for the offered functionality, as long as code is in CVS status, anyone can add (proposed) code for Drupal core or modules. Once the project leader Dries announces a freeze no more functionality can be added. Now the focus is shifting to debugging, optimizing, and documenting the code. This doesn’t mean that no functionality can be added to the project however. Since a stable Drupal version will be supported and used by the general public for over a year, late changes can be added tro make sure the code is reflecting the changes that are happening in the rest of the world. For example, when the new feed icon "standard" was established, new code was quickly submitted and added to the frozen Drupal code.

Making waves

So does this lack of a formal software development method makes us coding cowboys? No, not at all! While there is not one method used within the Drupal project, multiple methods help multiple people to deliver quality code. Most Drupal coders will probably feel comfortable with Agile software development though other methods are used as well within the Drupal community. Often people are amazed by the fact that there is no formal roadmap. "If you don't know where you're going, any road will take you there" seems to be their mantra. Dries often publicly stated that there is no need for a formal roadmap. In retrospect one could arguably say that some releases seem to focus on Search Engine Optimization, others on scalability. The release that will be out soon ("when it is done"), 4.7, seems to focus on both usability with AJAX, and on the developer with a complete new "forms’ API". Upcoming releases might focus on ease of install and themability. But there is no formal roadmap where these releases are plotted.

Does this lack of a roadmap mean we are drifting in the ocean of hypes, grabbing every ship that passes by? No. The Drupal community is riding the waves, not thrown around by it or looking at others surfing the waves. At its best, Drupal is even creating the waves. We have often set the standards (in technology, in functionality and in the way we communicate and interact) for others to watch and follow. Drupal -being liquid- is all about generating the waves, surfing the waves. And on this ocean of waves, a compass is of far more use than a roadmap.

”Me too”

So to get this compass pointing in the right direction, you should step in. For example, by applying for a CVS account and contribute code. But even if you are not a coder, there a zillions of ways of helping us out by becoming "us". You could help in Drupal forums, file bugs, test code, review patches, convince friends to use Drupal, help friends install Drupal, setup a local Drupal User Group, organize events, learn from the Drupal IRC channels, create themes, promote Drupal or write pages for the handbook. There is a lot you can do, without coding one simple line. All for the Great Cause, establish Drupal World Dominance!

So, "It is done when it is done". Become the "done" part and stop being part of the "when" by joining us and become part of the Drupal team.