Recently, there has a been a LOT of discussion about the future of drupal core and some of its rather "legacy" modules. This is a good conversation to be having, however I think we are spending our efforts in the wrong place, or perhaps better, I think we have or priorities misaligned.

What do I mean by this?

As great as removing the cruft from core, and lessening the burden on core developers is, I think there's a more important conversation to be having here, and these points shed a completely different light on this conversation. The issue we really need to be discussing is one of packaging management, not bikeshedding about what modules should and should not be maintained by core any longer.

Why is this significant?

Packaging is a core concern for a number of reasons, the two I want to immediately highlight are the aforementioned "lessening" of core contributors work load, as well as supporting other drupal based distributions which already have to depend on packaging as a factor of what they do.

Lessening Core Workload

Core has a number of items that, in any other distribution, would be considered "feature" modules. These module are VERY important as, just like any other distribution, they characterize WHAT the standard install profile IS. I bring this up because, just as Open Atrium would be a completely different product without case tracker, or documentation, so drupal core is a different product without a module that specifically handles blogging. This is why removing blog from drupal core is something I'm not thrilled about. It's not that we want to deliver a different product (or if we do, that's definitely NOT the conversation we're actually having) it's that we want to remove the "product features" from the plate of the core developers, and this brings us to the first "value" I think we need to be tracking.

Value #1:
It's not what we deliver, it's how we deliver it.

The tl:dr version of this is pretty simple. Just because we remove blog module from the list of things that core devs need to worry about doesn't mean that it can't or shouldn't be delivered in the standard install profile. The very real practicality is that we have hundreds of thousands of existing drupal installs out there that need the ability to upgrade their core-provided blog module at some point. I propose that this is best handled by a blog module packaged within the standard install profile.

Supporting Drupal Distributions

Currently, standard and minimal are the "blessed" install profiles. This is actually a good thing as Drupal needs to be SOMETHING when you install it. What's bad about them is that they don't have to follow the same packaging rules as the rest of the drupal based distributions in the current ecosystem. This of course means that certain points of pain for building a distribution are largely not felt by core, and thus will never actually be fixed (or at least are significantly less likely to). This also means that what is currently distributed as "drupal core" is both slow and difficult to change. If core were implementing the same sort of distribution strategy as all other distributions, new profiles could be added to core once deemed strong enough and popular enough to do so. In the same way "standard" product features would still be packaged with core, but get the benefit of a faster potential improvement cycle by being in contrib. This brings us to values number 2 and 3.

Value #2:
All install profiles should be packaged the same way.

Value #3:
Asynchronous development cycles are good for both product and kernel.

Back to the Original Point

We're spinning our wheels bikeshedding WHAT should be removed from core when I think the real question is: "What should be packaged into our product." In truth, Drupal's not really all that well defined of a product. There are a bunch of modules that are there that no one ever turns on and various components of modules that are commonly enabled that no one makes use of. But the fact that Drupal is a rather badly defined product doesn't mean that it can't still be packaged effectively, and this is why I'm concerned about the current conversations within the community. I know my values are not necessarily the same as everyone else, but to summarize my value statements again:

Proposed Values:

1.) It's not what we deliver, it's how we deliver it.
2.) All install profiles should be packaged the same way.
3.) Asynchronous development cycles are good for both product and kernel.

These values are NOT really addressed by bikeshedding what we're going to move out of core. Understand, I DO believe we need to be moving product features out of core, however I also believe that people will be more likely to agree on what is a "product feature" if they have assurances that that code will continue to be distributed, it just won't require the maintenance of core contributors to do so. I am very concerned that we'll spend months debating the various components we want to remove, and then even more months figuring out how to handle their removal in an upgrade path for Drupal 8. I've been told packaging is not a concern until Drupal 9+, and as much as I admire and respect the various individuals I've had private conversations with concerning this topic, I cannot shake the feeling that packaging is the far more important problem, and that ignoring it in favor of removing code completely from what we distribute is a horrible horrible misstep. This approach brings up many other questions, but they're important questions to answer, and I hope that this post can facilitate a larger conversation on this topic.

Kris "EclipseGc" Vanderwater