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@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