There has been much debate within the Drupal community about having a roadmap for the development of Drupal in the future. Dries –lead and hence has the final say– is against having a roadmap:

Drupal never had an official roadmap, and will never have one. People perceive a roadmap as a list of formal deliverables; they feel stranded when the roadmap is changed, and get upset when functionality is not completed in time. Volunteer-driven projects like Drupal can't make any guarantees. Things happen, or not. Code is ready, when it's ready. Volunteer-driven projects don't mix well with official roadmaps.

I on the other hand for reasons listed below think we /need/ a roadmap. But lets first define what a roadmap is, before explaining why Drupal needs one. A roadmap – in contrast what people believe- is not a rigid layout of the plans for the period ahead. Neither is it a braindump of thing we want or a list of formal deliverables. A roadmap doesn’t come with a receipt and there is no money back either. A roadmap is an abstract flexible projection of the predictable –makeable?- future to get developers and (potential) users aligned within a certain timebox. Strictly speaking Drupal has a roadmap. A roadmap might even be: we don’t need no stinkin roadmap, hence we already do have a roadmap.

So a roadmap in my definition reflects the current state of the codebase extrapolated with a shared vision within a certain timeframe. So a roadmap is just as fixed as the codebase the vision is. Both can change so the roadmap can change.

The reason I believe we need some kind of roadmap (apart from the one we do have which says we don’t have a roadmap) are based around both internal and external reasons.

The internal reasons are:

• The maturity of the Drupal community combined with the growth of the Drupal community just screams for a coordination. On the dev mailinglist one gets about 50-100 messages a day, other mailinglists (themes, infra, support) combined with some private mail I get about Drupal, makes that I get more than 100 Drupal related mail per day. And I don’t review a single line of code let alone do some programming on Drupal! Real Drupal people either have a day job to stay in touch (getting paid I hope) or don’t have a private life. A roadmap combining the shared vision extrapolated from the codebase, could make life easier.
• I am not sure if the Drupal development will go from a "done when it’s done" to a timebox release cycle, but if the later is chosen, we need statements like "the next feature freeze will be on 1 November 2006, the next release will be close to 31 December 2006", aka a (simple) roadmap.
• If we are going to timebox our releases, we will find out that within a timebox one has to focus on one thing. Timeboxing originated from the railroad companies, you "start" a train on time and because there is nothing else on the track you know the train will arrive on the "release" date (that used to be the case at least). Now just like with trains, you cant combine all things. For example, you cant combine a passenger train with a chemical train, or at least it is not smart. It is better to have them after each other and since you know when a train leaves and enters a station this is not a bad thing. The same holds true for software development IMHO. You shouldn’t combine a release aimed at developers (example: FAPI) and endusers (example: AJAX UI) in one release. It complicates stuff. IMHO it is better to have a short release cycle and per release focus on UI, API’s for developers, usability etc. This kind of planning needs a timebased roadmap.

External reasons include:

• When people look for a mature OSS project, one of the criteria of selecting a "mature" project might be the (lack of) having a roadmap. Having one can get Drupal on the radar for a broader audience
• When more and more Big Corporations start to use Drupal -they do and they will- the need to have some alliance with the community. Often they use intermediates for that like Bryght or Lullabot since they cant spend their own time on monitoring the tooling they use up to the bit level. However, even when using intermediates, they still need to know how the tooling they use will fit in their own plans. Marketing departments who schedule events but also reserve timeslot for example for television commercials don’t tent to wait to the point that "done" is done. They need some kind of roadmap to know what the can expect of a tool at what moment.

Now I know that most community members will say they don’t care much for these external reasons, if Big Company wants function A to use they either write it themselves or go to another product which offers A. While this is the way how uncontrolled OSS projects work, it is time for a mature OSS project to get aligned with companies using our software and share a vison, share a roadmap.

Given these reasons I hope there will be a small roadmap that can indeed change on day to day basis. As an example (note: example!) this would be a good start for a roadmap:

I hope that a combination of what people plan to do in combination what the leader(s) want to come of Drupal, will eventually result in a sort of roadmap.