While working on a presentation for DrupalCon Baltimore, I was brainstorming various tactics and proposals for removing components and modules from Drupal core. The act of deleting something from core can, at first glance, seem simple, but it brings up a more interesting discussion.

First, some background

Earlier this year Dries Buytaert announced a change to the future backwards compatibility support for Drupal core. You can read more about the policy change in his post. To summarize, Drupal core will continue adding enhancements, marking replaced APIs as deprecated along the way. The next major version update of Drupal will simply be the removal of all the deprecated components.

Less than a month before this he also wrote about the opportunities prepackaged distributions present for Drupal 8. The new world of Composer-based dependency management is great for developers, but will become a new barrier to entry for beginners. The predefined packaging of distributions may be an important tool for combating this problem.

A clash of concerns

The real historical problem that has made the decision to add or remove components in Drupal core difficult is the dichotomy between Drupal as a framework and Drupal as a product. Framework advocates want a small, agile core focused on robust APIs that can advance at a faster pace. We’ve traditionally called this “small core.” Product advocates are focused on Drupal being a complete product for website building; with sensible defaults, out-of-the-box content modeling tools, and a plethora of features.

Let them eat cake, and have it, too

Is there a way to focus on the framework, but still provide the product-level utility that beginners, site builders, evaluators, and the like all need? Maybe.

Let’s give the small core crowd what they want and reduce Drupal core down to its core components and APIs. All the things subsystems need for Drupal to function, and only modules that the vast majority of sites will use and are fairly integrated into core; node, block, menu, field, views, etc. Everything removed will be put back into the contrib space, but maintained by the core commit team and component maintainers with the same high standards as core.

We then create an official, standard distribution that is prepackaged by drupal.org and pulls in all those additional components from the contrib space; themes, toolbar, forum, etc. This distribution would be maintained along with small core and be available on Drupal’s download page. (With small core available for download on its own.) The end result should be transparent to anyone downloading Drupal. The initial distribution would look exactly like Drupal 8 does right now.

Let small core focus on developer needs, and free up the distribution to focus on site builder and evaluator needs.

Here are some potential benefits I’ve been thinking about, most of which fall in line with the current direction of Drupal core:

• Focus core on APIs
• Allow developers that want to contribute to focus on those APIs, not product decisions.
• Reduce some of the maintenance burden on core itself, or at least better segment it.
• Moving most modules back to contrib would give component maintainers commit access to their modules and allow them to iterate and experiment.
• Creating an official distribution separate from small core would let product managers, designers, and UX specialists focus entirely on Drupal the product; what modules and themes are included, default features, user testing, etc. (Something like the default content initiative would go right into the distribution, and never clutter core.)
• Experimental modules/themes can be created in contrib first, and then when stable, added to the distribution via its composer file.
• Small core would provide a small, vanilla starting point increasing the diversity and experimentation we might see with distributions; effectively removing all the unneeded components so builders can focus on what they want to add, not what they need to remove. The end result could be a wide range of Drupal “flavors” that look very different, but have the same core.

If you’d like to talk about this and the general topic of removing components from Drupal core, come to the Core Conversation session Peter Wolanin and I are having at DrupalCon Baltimore - Less is More - What Modules, Features, or APIs Should We Cut From Core?