Drupal: One core, many distributions

  • The comment you are replying to does not exist.
  • The comment you are replying to does not exist.
  • The comment you are replying to does not exist.

This is an old post I sent to drupal-devel mailing list more than 3 years ago, I would like to revive as I think finally the small core / many distributions idea is gaining some ground. I haven't changed anything from the original post here, http://lists.drupal.org/pipermail/development/2005-November/011428.html

-------------------------------------------------------------------------

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?

------------------------------------------------------------------------

Comments

Makes sense...

This post makes sense... Core should provide something out of the box, but should became more and more something to build on.

Lean, mean core and killer contrib modules! A goal for Drupal 8!

#smallcore

The greatest goal for D8.

standard answer

The standard answer is that it depends a great deal on infrastructure to be built. The packaging scripts are already intelligent in some ways, but they need to be much more intelligent for install profiles to be packaged. The packaging code is all in the open, and Derek's company highlights this as a focus projects but as far as I see, lack of resources dedicated to this is the biggest obstacle.

Helping drupal.org package distributions would help a great deal with pushing this forward, and anyone can do this by either helping write and review code or donating to Derek :)

http://3281d.com/projects/improve-install-profile-packaging

> lack of resources dedicated

> lack of resources dedicated to this is the biggest obstacle.

Yes, and I'd rewrite it like 'wasting too many resources on other issues'.

The thing is we either go for the small core / distributions model, or we go for the 'drupal is a cms ready to use' (for what?). IMHO we've wasted a great deal of time and resources on the second option in Drupal 7.

the way i like to put this

is that drupal core should be the framework.
distributions/install profiles are applications built on this framework.
sites are instances of these applications.

until we can properly develop Drupal the CMS as an application built on the Drupal the Framework, our api's should not be considered sane.

Very true. Maybe if we pay

Very true.

Maybe if we pay more attention to patches like the one below, we'll be able some day to build Drupal CMS as an install profile out of Drupal core.

And this patch is one of the key element

Ugh, more of that 'review my

Ugh, more of that 'review my patch' spam. Drupal developers are hopeless ;-)

I will...

Development Seed is making some great progress

A couple days ago I installed and have been playing with Development Seeds Open Atrium project and I must say, this is one of the most future thinking pieces of software and has breathed new life into how I think about Drupal.

They have a wonderful install profile, which sets up a fully functional "distribution" of Drupal which actually does something out of the box.

Not only have they made a wonderful use of install profiles, but they've essentially created an entire new process for developing a Drupal site with the spaces, context and feature modules. I believe that the features module will become an increasingly popular way of creating Drupal sites and it will simplify the creation of install profiles (and in turn we'll end with many more of them).

I believe this will be the way people will move forward with future Drupal development. I for one, will be trying to use this suite for my next couple developments to see how everything turns out.

Unfortunately it means I have a learn a new way of doing things, but from the portability of "features" i believe my investment will pay off.

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
This Work, Drupal: One core, many distributions, by Jose is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike license.