[development] Drupal 7 "When it's Ready"

Matt Chapman Matt at NinjitsuWeb.com
Wed Mar 4 19:31:40 UTC 2009

I agree entirely that the expanding gap between core & contrib is a 
major problem, and one that seems to be underestimated by some core 

However, I'm slightly concerned that establishing a set of golden 
modules in this way will stifle the evolution by natural selection that 
has served Drupal so well. To make the point, imagine if it had been 
decided that Drupal 5 was not ready for release until Flexinode was 

It's not so important to users that module X be available, but that 
feature Y be provided by some module; preferably with an upgrade path 
from module X, but that is secondary from a development perspective.

Rather than golden modules, what we need are golden 'use cases.' Perhaps 
this takes the form of supported Profiles or Patterns. (I'll use the 
term 'profile' to mean any means of collecting modules and 
configurations for implementing a specific end-user functionality. I 
think installation profiles as currently supported by Drupal are 
severely lacking, having abandoned one in favor of database dumps for 
the time being.)

It has been my experience that the lack of a D6 version for needed 
modules caused me to look for and find other, better solutions. Or it 
forced me to more closely analyze the strengths and weaknesses of the 
various solutions, to determine which is most worth my effort to upgrade 

Also, I strongly suspect that it is often the case that the modules with 
a better underlying architecture are easiest to upgrade. A lag in 
upgrading a particular module may be a sign that it could be replaced by 
a  better solution.

Finally, supporting profiles instead of modules makes the system less 
susceptible to single points of failure. It takes less technical 
expertise to maintain a profile than it does to maintain a module. If I 
maintain the Community Events Management profile, and there's no e-mail 
reminder functionality available for Drupal 7, I can petition 3 or 4 
different module developers to upgrade their module, or I can try to 
organize some developers to create a new, better one, to leverage the 
new DX features of Drupal 7.

You may say, 'What about modules that are so generic that they are used 
in most any site?' I'd suggest that those are exactly the sorts of 
modules that should be included in Core. We're seeing this happen with 
CCK, and Views seems poised to follow shortly. We could even make the 
criteria for core eligibility more explicit: If a module is used in 
EVERY supported profile, then it should be moved to core in some form. 
(And the converse: if a module is not used by any supported profile, it 
should probably be removed from core.)

One thing that would really help this is more street cred for profile 
maintainers. However about some front-page case studies for a couple 

Hey, Acquia, could you throw some money at a few profile maintainers to 
get them to really polish their profiles, or convert them into patterns 
& add the patterns module into your distro?

All the Best,


More information about the development mailing list