[development] One core, many distributions

Dan Robinson dan at civicactions.com
Sun Nov 20 23:39:12 UTC 2005


How about a stack?

(Read from bottom to top)

Drupal Verticals (Education, Blogging, CivicSpace yada yada)
Drupal Experimental - All the other stuff (this is sandbox)
Drupal Community Contribs - Lots of other stuff (new / part of current
contribs)
Drupal Base Modules - relatively generic, popular, highly desireable,
maintained stuff (new / part of current contribs)
Drupal Core - totally generic everyone needs them stuff (this is core)

If I was drawing a picture it would be a bunch of stacked boxes and L
shapes showing a somewhat more sophisticated "stacking".  Don't go all
wacky on the naming (just put it here for a conversation starter).

And who are the "customers"

Accidental Webmaster
Webmasters
ISVs / Consultants / VARs
Developers

Each of the above is it's own defined group with specific
needs/desires.  IMHO Drupal currently does an excellent job with
Developers (and pretty well (but not as well) with the others).  Simply
making more of a distinction between the modules would go a long way in
helping these users.

Dan

> Adrian Rossouw wrote:
>
>> I agree, but I believe that pathauto like functionality should be 
>> part of our default install, and we should emphasise it.
>> It's one of our more powerful features, and the improvements in 
>> usabilty and browsability are amazing.
>> Plus google loves you much much much more.
>
>
> Okay - people have lost their minds (sorry don't mean to single you
> out here Adrian - especially considering your comments later on in
> this thread - and all the work that you do, but this comment just
> floored me enough to end months of silence).
>
> What floored me is the irony that the topic should come up in a thread
> about creating a leaner core that can support multiple distributions.
>
> Path auto is the epitome of a contributed module.  It serves a purpose
> that many people may find useful, but is NOT REQUIRED and does not
> serve a CORE purpose.
>
> (Core module = module absolutely required to make the
> software/development environment work.)
>
> I've more or less given up trying to define what Drupal is.  Its a lot
> of things to a lot of different people.  (I'm finally coming around to
> thinking of it as two distinct things: 1) a rapid software development
> platform 2) a Drupal Branded CMS that uses has the rapid software
> development platform at its core).  But I can define what Civicspace
> is - I can define what DrupalArt is - I can define what Drupal Blog is
> - I can define what DrupalEd is etc.  And I know that Drupal is at the
> CORE of all of them.
>
> So I'm in full agreement with Jose's idea of 'one core to serve them
> all'.  If something doesn't 'serve them all' it has no place in core.
>
> Take this idea to its logical conclusion and Forum.module should be
> dropped from core.
>
> "HERESY!!!," the masses rise up and shout.  "That's where drupal all
> began. BURN THE HERETIC."
>
> Fine - light your torches - but when your done and Drupal 5.0 comes
> out with a full installer that starts with a lean core and adds only
> whatever users need and/or want - you'll realize that your already on
> the same page.
>
> andre
>
> p.s. As for multiple contributed modules that do more or less the same
> thing.  If people don't want to work together it doesn't matter.
> Natural selection will take place.  Competition is good.  The module
> that adapts the quickest to the needs of the community will become the
> defacto standard - until a new competitor comes along.
>
> Why did someone write Drupal when there was another forum tool
> available at the time?  Why do people improve Drupal when they could
> be working on phpNuke ;-)?  The multiple contrib module issue is a
> non-issue.
>


More information about the development mailing list