Within the Drupal community, we continue to wrestle with what, exactly, these things called distributions should be, and could become. Going into D7, the benefits of distributions (and specifically, the tools that support building distributions) are clear to developers. For most shops, the notion of building a site without using (at the very least) features hasn't really been an option for the last few years. Within FunnyMonkey - like at many other shops - we treat custom builds as product development, creating an install profile to contain config that can't be pushed to features, and making use of drush make during the build. Again, this is nothing horribly unique; this workflow simplifies testing, and technical decisions can be directly traced to code or a feature. Over the course of even a mildly complex project, having a clean, replicable build for all team members to work against saves countless hours of time.
But this is really only of interest to developers, or to people who directly benefit from a clear development process. These benefits filter down (theoretically) to the end user and content administrator in the form of a site that is easier to manage and use. But, the power of distributions has yet to become obvious to less technical users because, up to this point, the focus of distributions has been on automating a site install that delivers complex functionality out of the box. Distributions have done a great job solving this issue. Between installation profiles, drush make, and features, many of the pain points of replicating site builds have been eliminated or minimized.
So, using distributions, Drupal can be used to create products, and everyone can build an app store, and developers can sit back and make it rain.
Except: while distributions have taken the pain out of replicating complex site builds, they still require ongoing maintenance. Like every other software system, technology requires periodic updates; Drupal is no exception. Any Drupal site, whether built from scratch or deployed from a distribution, requires maintenance over time.
Most distributions are based on a collection of features. As a result, maintaining a distribution raises an additional question: should a distribution attempt to stay synchronized with the features that power the distribution, or with the underlying modules that are used within these features?
Tracking Overridden Features
The reflexive answer - the satisfying answer, the one that we want to be right - is that any site built on a distribution should stay synchronized with the features that drive the distribution. Over time, these features will evolve, and will have new, better, shinier functionality. However, the strength of features makes managing the config covered by that feature potentially more complex over time (there are many strengths and advantages to features, but one of the most obvious is the ability to push complex config to code where it can be managed and tracked via version control). Even a simple change (adding a field to a view, adding a field to a content type, changing a variable that has been strongarmed, etc) results in the feature being overridden. Over time, these overrides will need to be tracked against the features in the base distribution, and reverting these overrides could potentially break customizations in the production site. So, on a production site with overridden features, the overrides need to be tracked and either merged or ignored on each feature update. This is very possible to do, but it requires a level of technical expertise that is generally beyond the immediate reach of the people that distributions are supposed to empower: less technical users who just want to launch and use a web site.
Distribution-based Sites as Standalone Web Apps
And this brings us to the other alternative: once a site has been deployed from a distribution, that site is essentially detached from the distribution, and the site should be viewed as a standalone web app. With this approach, the features used on the production site should be checked into version control, and all site-specific overrides should be committed. This approach cuts the site off from potentially all future improvements in the base distribution, but it ensures that all modifications remain untouched. And, of course, this method requires a level of technical expertise that undercuts one of the main selling points of distributions. Managing overridden features in a sane way requires technical expertise, and distributions are supposed to make it easier for non-technical people to run Drupal sites.
Middle Grounds
There are additional possibilities here for working with and adapting the features within a distribution, but all of these methods require a level of technical expertise that undercuts the "distributions will simplify Drupal for non-technical users" argument. Probably the best option involves having features that are well architected, and make logical separations with documented dependencies within features. Then, end users can turn on the features that they want, and then they can clone and modify or ignore the features that they don't want to use. This leaves the core features untouched and in synch with the base distribution, but it also creates an additional set of features that should be managed via version control.
In any case, no matter the approach, maintaining a complex web site requires technical expertise. Distributions take the pain out of deployment, but they haven't done the same for maintenance.
Where To Go From Here
At the risk of stating the obvious, keeping all features untouched is really only possible in a SaaS environment, or an environment where the site admin has the discipline to resist unnecessary changes to the config. Aside from these two scenarios, most sites will require some modifications to meet the specific needs of the people running the site. And it's worth noting that in a SaaS environment, people are used to not having full admin rights, so there are use cases where only providing limited admin access could work. But, for most people/organizations, one of the key appeals of Drupal is the ability to tinker, modify, and expand the base build. This is good, and normal, and natural; if an organization doesn't think about how to use their web site in different ways after the initial launch, they are essentially stuck in time, and that's not good, and distributions need to be flexible enough to support that reality. However, within the community, until we clarify what we mean when we talk about admininistering a site deployed from a distribution, people using distributions will remain uncertain about the best approach to keep their site working well over time.
Image Credit: "Mind the Gap" taken by ammiiirrrr, published under an Attribution Non-Commercial Share Alike license.
Blog posts and documentation licensed under a CC NC-A-SA license.