Problem/Motivation

At present it feels like we're constantly adding new modules to core so that core can compete with market competitors on features.
However, the only thing we have to show to compete against these products is the standard install profile, which on its own solves no-one's use-case.
We have #2809635: Create experimental installation profile to try to at least present a cohesive product that demonstrates the power of Drupal.
However there are many ways to put Drupal together.

Proposed resolution

Let's think of it like Lego, something we've always identified with.

You have your base building blocks like entities, views, plugins.

And what core currently ships is like a bucket of bricks, you can build whatever you want - but there isn't much guidance. And if you've never played with the bricks before, you're not really sure how to put them together.

On the competitor side of the spectrum, they're shipping assembled sets. Like a Police Station Lego set, but where you open the box and its already assembled (no assembly required).

The experimental install profile, which takes its cue from the User Guide is analagous to the standard lego set, where you get the parts and you get some instructions and you get the fun of putting it together yourself. Next time you get a big bucket of bricks, you can draw on your experience following instructions to build something useful.

But we also have an analogy to the competitors fully assembled set. These are contrib install profiles. Unlike standard, these are profiles that are built to serve a specific purpose - for example

  • open social - build your own social network
  • lightning - a media focussed publishing platform
  • aGov - focussed on the common needs of the Australian (and other) governments
  • Commerce kickstart - a store in a box

We should promote and allow installation/download of vetted profiles from the installer.

Precedence

We already download language packs from the installer, so downloading additional profiles shouldn't be much more of a stretch

Benefits

Instead of feeling like we have to keep adding modules to core to compete with fully baked products, in-turn increasing our maintenance burden - we can let core focus on what it does well - providing a solid framework for building fully baked products. I.e. core focuses on generic building blocks instead of boat hulls.

We still retain the fanfare around new releases. Drupal 8.X now comes with the ability to install the fizbar profile. Drupal 8.Y includes updates to the portfolio profile to support an image gallery. Drupal 8.Z now comes with inline entity form to power even greater site building opportunities.

In this model the vetting is done by the product managers, via this queue. Code in core maintains a manifest of vetted profiles, and their versions. The installer uses this to populate the list of options. Profile maintainers wanting core to bump to a newer version of their profile must open a core issue and provide a patch. Reviewers review it for suitability. If a version isn't ready, core doesn't fetch it, it only promotes stable, vetted versions.

People can see the full power of Drupal if they're evaluating it - and we greater convey the notion that the possibilities are endless.

Comments

larowlan created an issue. See original summary.

Crell’s picture

catch’s picture

This needs to be evaluated along with #1841788: Add project browser for me.

bojanz’s picture

Lightning, Open Social and Commerce Base (our D8 Kickstartish thing) all assume (and in case of the last two, require) that they will be downloaded via Composer.

So, same dilemma as with project page. Doing this requires somehow embedding Composer into the flow.
Personally I'd rather move that process above Drupal, with a desktop app like https://glamanate.com/blog/conductor-composer-ui

Mixologic’s picture

Have we solved the upgradability issue with distributions? (User downloads a Distro, it mostly suits their needs, they customize some of the features to make it totally suit their needs (add a field to a content type, alter a view etc).

Then a new version of the distribution is released. And the distribution itself had added some new options made changes to those same features (new field, new column in a view). How does the user who has customized their distribution get those new options?

Which brings up a second question: Is a distribution intended to be a starting point, or a product?

Finally, a third thing I'd point out is that we really ought to iron out the vocabulary of what we are talking about. I keep seeing the words "Installation profile" when I believe that "Distribution" is what is intended. Those are totally not the same thing, and I think "Installation profile" is almost never what people mean.

tim.plunkett’s picture

The problem described in #5 is only a problem for distributions, which are products.
An install profile does (should?) not have that problem, because it intended only as a starting place.

Mixologic’s picture

The issue summary is using the term "contrib install profiles" to refer to four distributions listed as examples, hence my point about clearing up the vocabulary.

moshe weitzman’s picture

Sure, we can distinguish between install profiles which are meant as starting points whereas distributions are meant as ongoing motherships. Bu I don't think it matters much for this issue. I would love to see drupal.org advertise these things a bit more. And once a user finds one, I think they should Just get instructions for a Composer based download of code and then a Drupal install. As part of the simplification/modernization of drupal.org projects, it would help immensely to get rid of the packaging of distros.

jibran’s picture

Video from @larowlan's session from DrupalSouth is up. From 24m25s mark he discussed the whole idea in more detail. The discussion brought up some interesting points as in why we need this, how to us this feature, resources needed from DA, what the vetting process should be and more. I think this video provides some good context behind this idea.

Mixologic’s picture

Scope/Goal of this issue

I have a couple of questions about the scope/goal of this issue:

Is the goal modest, and aims to improve the initial impressions and user experience for *evaluators* of drupal?
or is the goal more ambitious, and aims to productize distributions to the point that they can actually become the natural starting point for people to start using drupal, and only bake a custom solution with vanilla drupal if a distribution cannot be tweaked to suit their needs?
ie are we just trying to show them we *can* build a police station? Or do we actually want to give them an assembled police station?

If we aim to have distributions as products, my next question (what I was getting at in #5):
Is the user experience and ongoing maintenance of running a site on a distribution something that we would consider ready to promote to productization? Is it easy to keep up with upgrades? Is it problematic if you customize them? Don't hack core is true of Drupal, the applicaiton, but is "Don't hack your distro" true of distribution users? Are the lines clearly drawn or is this still sorta unresolved?

Making distributions the primary user experience

Whether distributions are ready for prime time, or don't need to be because they're just demos, then it seems like we have at least a couple of options for how to steer users into selecting a distribution as their starting point.

  • Option 1. Build into the application itself a way to get a better 'out of the box' experience, and continue to steer users towards downloading vanilla drupal on d.o. The installation process itself would allow users to select from some options on what kind of site they want to build.
  • Option 2. Change the way we steer users on d.o. to direct them to a better out of the box experience, funneling them towards vetted distros to begin with, and de-emphasizing vanilla drupal as the place to start. (sorta what Moshe said in " I would love to see drupal.org advertise these things a bit more")

The reason Im emphasizing the a distinction between install profiles and distributions is that there is exactly one stand alone installation profile on drupal.org.

The rest are distributions, and it is important to note that the only way we achieve an out of the box solution is with full distributions.

In order for distributions to provide that out of the box solution, they require a build/assembly process - currently thats drush make, in the future could be composer (https://www.drupal.org/node/2715441#comment-11669389). So if we were to provide a mechanism within the application itself to turn itself into a distribution, the application itself would need to be responsible for that build process (module retrieval/dependency resolution/asset retrieval/patch applications/any JS build process stuff that needs to happen etc). - it is certainly not as simple as the process for downloading language packs.

The work needed to accomplish option 1. involves adding a process to d.o. for vetting profiles, exposing an api that the drupal app can consume, building into core a way to self build the distribution (running composer or other build tools).

Option 2 involves adding a vetting process, and reworking the content model/download experience.

I personally strongly agree that we should be promoting fully baked experiences that are built with drupal, I would lean towards option 2 as its not more code for either core or the DA to maintain in order to accomplish the goal of making a users first experience with drupal delightful.

nedjo’s picture

nedjo’s picture

How does the user who has customized their distribution get those new [configuration] options?

I wrote the Configuration synchronizer module with this problem in mind. See the Drutopia initiative and the set of modules listed there for enabling distribution configuration management use cases.

we have at least a couple of options for how to steer users into selecting a distribution as their starting point

Option 3: possibly, drawing on Distribution installer, the installer code as well as the distributions could live in contrib, meaning the only Drupal.org requirement would be to point to the installer with its curated set of distributions as an alternate to installing core. However, enabling additional packages via composer remains a barrier.

And there are very familiar pitfalls here, including the potential to privilege specific use cases or, indirectly, companies. A key question would be establishing criteria for inclusion of a given distribution.