[development] Restructure Core Module Support [ was: Time to remove poll module from core]

[Chris Johnson]

Robert Douglass wrote:
> http://drupal.org/node/61285
>
> Its presence in core is holding up its own development.
>

 > cool idea. And let's rm archive.module and maybe blog.module too. :)
 > Cheers,
 >    Gerhard


As someone mentioned in the thread this posting was derived from, moving 
modules out of core often means they fall of the face of the earth and no 
longer get support and updates.  That's not good.

On the other hand, we cannot add every valuable module which has or needs good 
on-going support to core.  Various solutions to this have been proposed 
before.  Here's mine for this year:

=>  Core should be core required files and code only.  For the rest of this 
posting, I will call these the "framework files" or just "framework," but the 
name is mostly not important to me.  It's just for clarity.

=>  There should be a group of the most useful, best coded modules which are 
maintained and supported like the core itself.  For the rest of this posting, 
I will call these the "core modules"

=>  There should be a contrib repository for any and all other code 
contributed by anyone with a CVS account.  Support and maintenance is whatever 
is contributed.

Why:  this removes the tension of trying to keep "core" small by removing some 
useful and important modules in order to add newer, more "interesting" 
modules, yet at the same time provides a reasonable library of "core modules" 
which can be relied upon from release to release by the community.  As we grow 
more expert developers, the size of the "core modules" library can grow, too.

Not everybody is using Drupal the same way.  This creates an inherent 
continuing conflict over which modules should be in what we now call core.  It 
causes frustration when a module that a dozen sites depend on get dropped from 
  core and a new release of Drupal comes out.

Is Drupal a full-featured CMS out of the "core" box?  Why bother struggling 
with that question and instead admit that Drupal can do a variety of different 
things with the right modules.

Moving to a framework with installable profiles (collections of modules) for 
different uses will help move Drupal into wider usage, and at the same time, 
provide a better upgrade path for current installations.  It will also 
encourage more API-style thinking when developing, since the "framework files" 
will be mostly APIs upon which all else is built.  This would result over time 
in the framework becoming more generic and more optimized, which should allow 
for more creative and unusual modules to be built on top of it.

It might even be sane to say that without installing at least one profile or 
bundle of modules on top of the framework, it wouldn't even function at all. 
For sake of example, the "download Drupal" page could offer the new user (say) 
3 bundles or profiles, each a collection of the framework files plus only the 
modules needed to implement that profile.  They might be:  CMS, blog, and 
e-commerce site.  Or something else.

The same serious attention that is given to today's "core" would be given to 
both the "framework" and the "core modules" tomorrow.  The initial division 
would not change the total amount of code maintained but would allow more 
modules to be added without pushing others out as the developer manpower 
became available.

I think this sort of division would make life simpler for many existing sites 
who face upgrades, as well as make Drupal less intimidating for newcomers 
looking to start building.  And, of course, scratching my own itch, this would 
make my life much simpler, because I use very few of today's "core" modules, 
but use lots of other modules outside of them.  I want a clean framework to 
build on top of and I'm willing to do the work to make it happen.


Ok, that's my few minutes on the soapbox for this quarter.  :-)

..chrisxj