[development] One core, many distributions

Sat Nov 19 19:29:23 UTC 2005

I see two separate issues here, actually.

1) Is Drupal a developer platform, a CMS, or both?  

I see no reason why it can't be both, personally.  I also don't like the "Core 
and derivative systems" model.  That will very likely result in "The Debian 
Problem", vis, the mainline system takes so long for anything to happen that 
you get fragmented derived distributions that are "mostly compatible" and 
also have added administrative overhead to keep them in sync.  (I say this as 
a Debian Sid user. <g>)  That's not a good thing.

As a developer platform, it should encourage developers to build drop-in 
modules that can make it do whatever they want.  That's what we do now 
(although some parts could be done better, which is the point of most 
discussion on this list <g>).  Easily-interchangeable modules ALSO allows for 
a good user-CMS, because then the user can mix and match modules without 
having to worry about code.  If the module isn't at that point, then the 
developer's job is not done.  (And yes, I am speaking as a web developer.)

2) There's too many modules in core.

Hey, I won't disagree with you there. :-)  I've no use for most of the modules 
in core by default.  At the same time, though, contrib is, as others have 
pointed out, not always reliable.  There's overlap, modules are unmaintained, 
there's no vetting of a module or a developer before code gets in or gets 
flagged ready for a given release, etc.  So how do I know WHICH method of 
image handling to use?  (To date I've used inline and upload rather than 
image, because I've not figured image out.  I'm sure there's a usability 
lesson in there somewhere.)

My recommendation would be to have another "level" of modules, "endorsed" (or 
something less stupid sounding).  First, strip the core shipped modules down 
to a minimum: the required modules, throttle, taxonomy, path, menu, upload, 
comment, image, page (the one node type), and possibly xml-rpc.  (The exact 
list is subject to debate, of course.)  That creates a core system that is 
lean, mean, but still functional for a basic bunch-of-pages site.

Then, create an online "Download and install from archive" function, as others 
have said is slowly in the works, that lists only "endorsed" modules.  forum, 
blog, email-this-page (or one of the dozen versions of it), story, many of 
the taxonomy_ modules, etc.  A module only gets into the "endorsed" archive 
by meeting a certain level of stability, up-to-date-ness, having an active 
maintainer (which could be "the Drupal core team" like many are now), being 
sufficiently generally useful that more than one or two sites would need it, 
etc.  They would not necessarily have to meet the same schedule as core, 
however.  

That way, core's stability is easier to maintain since there's less code, 
which also reduces the workload for big changes like the forms API.  
(Speaking of which, great job guys!!)  It also encourages more modular, 
no-I-can't-take-that-hacky-shortcut design for the endorsed modules.  It 
could also allow a larger selection of easily-available modules 
(categorized?), which in turn would, hopefully, reduce the amount of 
duplication that goes on because people simply don't know a module is there.  
(See also: email-this-page, tellafriend, etc.)  A new version of core would 
require only a fraction of endorsed to be fully rock solid before it's 
released, though, say 1/3 or 1/2.  The rest can be updated in the few weeks 
after launch.  

The "contrib" archive would remain the "someone thought this might be useful" 
dumping ground, and endorsed modules would start there before being brought 
up to the major leagues, but would not get any special billing the way 
endorsed modules would.  Endorsed modules would be addressed by the docs 
team, but the big mass of contrib would not.

This way, we have a lot more flexibility and modularity of the development 
process, improve the user experience for Joe User, don't alienate Peter Power 
user (this is the most important group!), and still allow Dan Developer free 
reign in contrib.  

OK, enough of me talking. :-)  Any thoughts?

On Saturday 19 November 2005 12:31 pm, Jose A. Reyero wrote:
> Well, I was writing this as a reply to a reply to the previous
> 'Encouraging collaboration' thread, but it's grown too big, so sorry,
> but I want to open a new thread.
>
> A "great developer platform" is how I see Drupal, and I'm sure most of
> the developers too. But the thing is: we need some focus, some targets
> to agree on.
>
> The problem is: currently we are pretending Drupal -core- to be too many
> things at the same time, mostly that great developer platform (1), but
> also an out of the box ready to use community portal (2) or kind of
> that. And the consequence is we are handling too many issues when fixing
> bugs for 'Drupal core' that are too specific of some more 'user level,
> site specific' modules.
>
> The main point is *core shouldn't need to be an out of the box nice
> site* that anyone can use, and we need to jump in the *one core, many
> distributions* idea for that. And that need to be an out of the box nice
> site is actually consuming far more effort than what could be a proper
> CMS core.
>
> IMHO we are wasting efforts in some higher level modules, that should be
> more focused to get what is properly the core system working right in
> the first place. And I'm not making any judgement about which modules
> should be in core and which ones not. I mean,, ok to have a few nice
> modules in core, but when a module grows too much, because people wants
> all that nice features, and them to be easy to set up, we can a) move it
> out of 'core' or b) provide a basic one in core that can be extended by
> a contrib module.
>
> Just as an example -and I have nothing against forum module: At some
> point, we are duplicating the taxonomy interface to handle a forum
> specific vocabulary. Then, this causes some bug -like this one, again
> just an example: http://drupal.org/node/24274 -, and then we have a
> *core bug*, module specific, but as it is a core module,  this one  has
> the same importance -in the bug tracking system- as any other critical
> bug -like a basic API not working properly.
>
> Notice that on one side we have a very big module in core to handle
> forums, but on the other side we don't have an small one for what could
> be a badly needed feature for other modules to build upon: a basic image
> node module. -again just an example, but I'm not talking about forum vs
> image at all.
>
> And as a side effect... How many modules you need to patch for what
> could be a small 'core patch' -if core was smaller- before your patch
> can be even considered because you can say at least 'it applys to HEAD'
> ?? And how many modules you need to re-patch again because of a minimum
> detail has changed in the main core patch during the follow up on the
> issue tracker?
>
> So I want to insist on the idea of "many distributions to serve
> different sites, one core to serve them all" --nice 'mantra', isn't it? ;-)
>
> But, anyway, that's an old idea. Just look at Linux.... Could you
> install 'Linux' --properly understood as the core OS- and pretend you
> have a nice OS ready to play with your computer?
>
> Cheers,
>
> Jose

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson