To solve many of the goals Dries laid out in his 8 Steps for Drupal 8 article I think it makes perfect sense to remove everything from core except for the framework.

We should not try to focus on making Drupal core the product, and instead create an official distribution that is the product. This official Drupal distribution can the be marketed as the "Drupal product" but, as far as development is concern, Drupal core is not a product.

Doing this will address the following points in Dries article:

  • Create better separation between framework and product
  • Grow Drupal by making it a better product
  • Distributions could help, if we do them right
  • Aim for a shorter release cycle

Create better separation between framework and product
I think this one is obvious. Drupal Core = Framework; Drupal Distribution = Product

Grow Drupal by making it a better product
By separating the Drupal core project with the Drupal distribution project, there are clear domains on what needs to be done (separate issue queues, and separate goals) to make things better on both fronts. Right now, there is a conflict with developing Drupal in that decisions are often torn between making core more versatile or easier to use. By introducing the Drupal distribution, we can still have the tools to make extremely complex websites and have a really easy-to-use Drupal product without compromising on either front.

Distributions could help, if we do them right
As it stands right now, Drupal core is a distributions. One of the tough things about making other distributions off of Drupal core is that the developers of new distributions are stuck with the assumptions of the Drupal core distribution. This means these developers can't choose what to leave out of their distributions. A sticky position for spin-offs of Drupal core.

Aim for a shorter release cycle
Fast release cycles only make sense if you need to update the themes and modules in core. If we treat Drupal core like a framework, that means removing all themes and most modules from core. They will end up back in contrib, where many of them were originally made great in the first place. Then these modules can get better on their own time, not on the time of the entire core project. Core can also have a slower release cycle and it won't be a problem because it won't hold up the changes happening down stream at the module level.

Comments

philbar’s picture

First step: Make distributions ready for something like this.

See: Community initiative on Install Profile Packaging

philbar’s picture

Here is a quick list of actions for this issue:

  1. Clone non-essential modules and themes from core to contrib (Perhaps add sponsored contrib infrastructure to support them)
  2. Create official install profile for Drupal including any desired contrib modules or themes.
  3. Remove non-essential modules and themes from core.
  4. Create stable release of Drupal install profile which will automatically run the packaging script

This should result in the same "Drupal" but with a better development workflow because of the benefits listed in the original post.

Crell’s picture

I believe Dries has already nixed the smallcore = fewer modules approach.

However, I think everyone is on board with a more frameworky core. That's part of the logic behind the Butler project.

philbar’s picture

I was hoping to get Dries input on this.

It seems like the "smallcore" approach was crushed because we need a solid product to stay relevant, which means shipping with dozens of modules in core. An official distribution will solve that problem, because the modules would still be packaged with Drupal, they would just be developed separate from core.

Crell’s picture

I think you misunderstand "smallcore". It's an easy mistake because the name is horribly misleading, but I encourage you to read this article on the subject.

bonobo’s picture

For additional background/perspectives, this is also worth a read.

frob’s picture

The main problem with this is the main product then becomes something that doesn't do anything out of the box. Drupal core should really be the product with maybe a Drupal Framework release much like there is a Pressflow release.

Remember that quick product iteration only works well if backward comparability exists. If there is a new version of Drupal every nine months that that didn't work with the previous version's modules, then developers would drop off or the community would branch; half would stick with the old version and half with the new.

In my opinion, it is better to build a large scale product, that does everything, is rock solid, and release it every few years.

philbar’s picture

The main problem with this is the main product then becomes something that doesn't do anything out of the box.

I don't think you understood what I wrote in my original post:

"We should not try to focus on making Drupal core the product, and instead come up with an official distribution that is the product. This official Drupal distribution can then be marketed as the "Drupal product" but, as far as development is concern, Drupal core is not a product."

What I mean, is that the current core project should focus on creating the framework only. This way modules like "Fields, Toolbar, Views..." can be developed on their own time, independent of core release schedule, like other contrib modules are developed. The Drupal product that provides the out-of-the-box experience should be created as a distribution built on top of the framework and pulls in all the modules using the drush-make script which would result in an identical product as we have now.

frob’s picture

Isn't this more or less exactly what has happened. While I do think that some modules got rolled into core that shouldn't have, some where past due (like fields). Remember that before fields you had to write the schema for a custom content type that needed more than a body. You could call fields the new schema in a way. You don't have to use all the modules. I have not had time to install the beta of 7 yet but doesn't still allow two types of installations, typical and minimal (or something like that)?

I don't see the problem with having one product that has stuff that in most sites never gets turned on, such as the upload module, or stuff that gets replaced by a better module later on, like the upload module. So long as the API remains strong extra stuff can always just not be turned on if the system is properly modular. Remember that part of our job as developers is to hide all the stuff that the user shouldn't change anyway. If I had my way then all modules would have a core module and an ui module: Views, Views UI; Context, Context UI; there should be Taxonomy, Taxonomy UI; CCK, CCK UI.

Sorry I got into a bit of a rant there. I just think that we are on the right track with distributions and core. Mostly its marketing anyway.

lelizondo’s picture

What would happen if Drupal Core is released in 1 year but the Drupal distribution is not very good because it would take 2-3 years to be ready. In my opinion that would get us in the position where the framework is ready but is not usable, and by the time is usable, the next framework release would be ready.

Wasn't that the whole point of the #D7CX initiative? To have core and as many modules ready by the time of the D7 release?

niccolox’s picture

Issue tags: +smallcore lives

lets get real.

Drupal core (D6 or D7) doesn't do anything (useful) out of the box.

its in a strange state where it pretends to be a full featured content management system - ready-to-go - but really you need to download dozens of modules, themes and do all sorts of configuration

its too bloated to be really core platform and its too small to be a fully featured content management system

how many websites out there really are just running Drupal core ? I would hazard a guess, something like 2

how many websites have
20 + contrib modules ? > 90% ?
50+ contrib modules ? > 70% ?
100 + contrib modules ? > 50% ?

why is Drupal core so huge, it just doesnt seem manageable

as of today, Drupal CORE
All issues
9946 open, 38098 total
Bug reports
4989 open, 21693 total

thats a pretty big queue

if it was a small core, it would have something closer to views
All issues
812 open, 12622 total
Bug reports
334 open, 4894 total

or the only other community "distro", COD
All issues
9 open, 90 total
Bug reports
1 open, 35 total

frob’s picture

I have used COD and it is not ready to go right out of the box either.

Where are you getting those numbers for "if it was a small core" I am assuming that you are making them up.

Out of the box drupal core manages users, user access, and content. It does alot out of the box and is very useful out of the box. The more I use D7 the more I like the way it does this. Have core modules and two distributions that can be installed, typical and minimal.

Typical should be managed by the community and should be allowed to evolve with future best practices.
Minimal should stay right where it is, with nothing defined.

That is my opinion.

niccolox’s picture

I made these up, hence the ??
20 + contrib modules ? > 90% ?
50+ contrib modules ? > 70% ?
100 + contrib modules ? > 50% ?

the others I pulled from the issue queues (which are no doubt different)

it would be a very interesting metric to get an idea of various constellations... i.e. website DNA, what modules are being used with what modules, clusters and not just distribution/numbers

frob’s picture

That would be a very interesting metric. The Drupal DNA, or DMA Drupal Module Association Project.

David_Rothstein’s picture

Seems like there is a related issue filed recently: #1255674: [meta] Make core maintainable. Should these discussions be merged?

I also wanted to comment quickly on this part of the original post:

As it stands right now, Drupal core is a distributions. One of the tough things about making other distributions off of Drupal core is that the developers of new distributions are stuck with the assumptions of the Drupal core distribution. This means these developers can't choose what to leave out of their distributions. A sticky position for spin-offs of Drupal core.

This may have been true in Drupal 6, but I don't think it's much of an issue in Drupal 7. For example, if you want to (effectively) "leave out" the core Poll module from your Drupal 7 distribution, then you should be able to easily do that with something like 3 lines of code in your install profile:

/**
 * Implements hook_system_info_alter().
 */
function MYPROFILE_system_info_alter(&$info, $file, $type) {
  if ($type == 'module' && $file->name == 'poll') {
    $info['hidden'] = TRUE;
  }
}

At that point, the Poll module should be completely invisible in the user interface for users of that distribution. (It will still be there in the file system, of course, but in the grand scheme of things I don't think that's very important.)

niccolox’s picture

well, Small Core seems to becoming a reality, OpenID has spun out of core and its now contrib again

what else ?

David_Rothstein’s picture

OpenID has spun out of core and its now contrib again

Huh? It's still in core last time I checked (which was 5 seconds before writing this comment) :)

niccolox’s picture

sorry, I jumped the gun

patches for d7 and d8, not yet rtbc ...
http://drupal.org/node/556380#comment-4913568

philbar’s picture

Nice to see some movement on this:

Demo Drupal Product page:
http://drupal.org/node/1260214

Along with:
#1255674: [meta] Make core maintainable

philbar’s picture

Issue tags: +Platform Initiative

tagging

Damien Tournoud’s picture

Status: Active » Closed (duplicate)

Duplicate of so many issues it's not even funny. In particular [#125567] .

lelizondo’s picture

@Damien Tournoud, I think the nid you posted is wrong. It would be good to know where to continue the discussion.

C-Logemann’s picture

This is the complete issue nid: #1255674: [meta] Make core maintainable

C-Logemann’s picture

Issue summary: View changes

Fix grammar errors.