[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
developers.
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
updated....
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
myself.
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
profiles?
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,
Matt
http://www.NinjitsuWeb.com
More information about the development
mailing list