Adding this issue as a place to discuss ideas related to the future of Drupal core development and the packaging of components. This is after the core conversation Peter Wolanin and David Hernandez had at DrupalCon Baltimore to discuss the feasibility of removing core modules and APIs and what qualifies something for removal.

Link to session: https://events.drupal.org/baltimore2017/sessions/less-more-what-modules-...
Link to video: https://www.youtube.com/watch?v=jPdR82N8Wg0

Idea summary

What is the problem to solve?

The crux of the debate is the continuous clash between Drupal as a product and Drupal as a framework. As we continually progress with composer, and make workflows a little more difficult for site builders, we start losing that user base. We also could do more to advance product level features and interfaces, but risk further bloating core and making it less attractive as an api-focused framework.

Who is this for?

(Evaluators, site visitors, content authors, site managers, (advanced) site builders, developers, core developers, site owners, other?)

Result: what will be the outcome?

(Describe the result: how will this improve things for the stated audience(s)?)

Prior to drupalcon, I had various ideas about the removal of components, small core rehashing, etc. One idea that I've been settling on is removing modules from core and repackaging them as an official distribution maintained by the core team. I wrote some about this idea in a blog post. https://ffwagency.com/digital-strategies-blog/proposal-future-drupal-cor...

Tim Millwood also made a post encapsulating some of his thoughts. http://www.millwoodonline.co.uk/blog/the-future-of-drupal

How can we know the desired result is achieved?

(Usability test, a metric to track, feedback)

Comments

davidhernandez created an issue. See original summary.

yoroy’s picture

Issue summary: View changes

Thanks for posting. I'm listening to the core conversation recording. Big topic! I'm adding the 5 questions for pitching an idea to the issue summary and put some of the intial bits in the right(?) place.

There's many angles to this. What are the actual problems you think we need to address? What is that clash between Product/Framework? Increase speed of innovation? Keep site builders on board? Unbloat, redefine core? Other? All of the above?

In general I do support the notion that we should innovate not only by adding things but also by removing stuff, and I agree we have core features that have outlived their usefulness at least in their current state.

Mile23’s picture

Just from reading the IS, it seems that the idea is to change the way core is packaged, not necessarily change focus on who uses it.

We now have the subtree split infrastructure at the DA, so we can (theoretically) move core components to vendor. #1826054: [Meta] Expose Drupal Components outside of Drupal

We also have issues dealing with allowing core to live in vendor/ as a dependency. #2385395: Make Drupal core folder agnostic and allow it to be placed in vendor/drupal/core

And some focus on turning modules into dependencies: #2701253: [meta] Make it possible to put modules into the vendor directory

Lots of use cases: #2002304: [META] Improve Drupal's use of Composer

I think you'll find lots of support for the idea of making everything into dependencies. Each step along the way is an improvement, and even if the goal of DEPENDENCY ALL THE THINGS! isn't achieved, each small step will make the next step easier.

The problem isn't technical, because you'll be able to assemble a deployable tarball built from all the pieces. The problem is cultural/political, because everyone adopts the false dichotomy of small-fry vs. enterprise.

So in phases:

1: Work on allowing all Components to be dependencies. Since we now have the subtree split, this is doable except for some minor stuff: #2867960: Merge Component composer.json files to account for them during build

2: Then we'd figure out how to build drupal/drupal with dependencies on those Components instead of having them in the codebase as they are now.

Whatever build process ended up happening in that regard would be a demonstration of what's actually required to move a component (be it a Component or a module) out of drupal/core and into drupal/drupal. This allows us to understand risks and benefits of the next steps:

3: Major refactoring of the way extensions work would be required in order to allow them to live in vendor/. Consider the problem of discovery alone, because that's a big problem. :-) We would have to support both vendor/ discovery and modules/ discovery, because people will still want to be able to drop a contrib module in a directory and be done.

4: Finally, once the modules are out of the core/ directory, we have to refactor core/ to be path-agnostic, which I've looked at, and recoiled in horror. Start with the 'Kill includes' issue tag.

So a lot of work has been ongoing already on this, and it's not been moving very fast. Welcome to the struggle. :-)

timmillwood’s picture

I think we need to remove core modules out of drupal/core and put them in drupal/drupal. This means they need to either go in the /modules or /vendor directory, rather than /core/modules.

8thom’s picture

Thanks Peter and David for starting this core conversation! It's as a very important step in the evolution of the Drupal project.

Firstly, I'd suggest we avoid the term "small core" as it has negative connotations due to history which mainly stem from the confusion about what "core" is product v framework. Perhaps, flexicore or just contrib in core? We need to be clear that in a rearchitecture like this, core (product) wouldn't need to be impacted in anyway, if anything we could look to add more contrib to core, without the maintenance burden.

With Drupal 7 and before it was almost impossible to build a site without contrib which meant end users didn't see the benefits when evaluating Drupal. I'd like to see this flipped around in D8/9 so we can have far more OOTB functionality yet in a way that doesn't impact stability or advanced users.

With composer we now have the opportunity to achieve this win/win situation :)

By pinning core to stable contrib releases, we can allow this additional functionality in core yet the flexibility to remove or replace these core modules which aren't in use. We would also have the ability to update core modules to DEV releases which would push further innovation rather than managing core patches.

Overall, this will offer the project more agility - let core manage the plumbing and let contrib live on the bleeding edge *(with stable releases).

It's concerning that we have modules in core that we don't consider relevant or "best practice", what are people evaluating Drupal going to think? They could be sunsetted to contrib while remaining in core, then eventually removed from core in D9 but still available long term as normal contrib.

Don't think this as something that needs to happen all at once or that all core modules should be managed in contrib, it would be easier to start with one module that fits a profile of contrib in core and make sure the architecture is suitable, then other modules from there should be a lot easier.

Maybe start with an experimental module?
Perhaps it might be more achievable short-term to reframe the idea to "Move x module to contrib and reference by composer".

yoroy’s picture

kreynen’s picture