Define aims and outstanding technical tasks for distro support and Features-style config packages in core

Some interrelated issues with Drupal 7: - On its own, a core Drupal install does practically nothing. Few if any sites run just the core. - Rather than becoming more accessible, Drupal site development is increasingly costly. Typical site development costs range into the tens of thousands of dollars. - Most custom development essentially repeats, with small variations, work that has been completed and paid for tens of thousands of times before. - Alternatives to custom development like Drupal Gardens are limited, lacking a lot of the advantages of Drupal, and tied to particular corporate service offerings. - With few exceptions, Drupal distributions seem to have low adoption rates. - Despite early efforts like Kit and later ones like Debut and the interoperability aims in the Open App Standard in practice, distro developers went their own ways, developing features that worked only within the confines of their own distro. A big missed potential of Drupal 7 was interoperable features.

The closest that Drupal 7 came to interoperability was the Panopoly feature set, which has been adopted by several distributions including Open Atrium 2. But, while it's a valuable contribution, Panopoly comes at significant costs. Far from being slim and basic, the base install of Panopoly adds dozens of modules to Drupal core and pushes it well past what's available in typical shared hosting.

It would be great to address these problems from the start in Backdrop. Steps to do so could include: - Define clear standards for interoperable feature development. - Ship core with several workable features that: - provide out of the box usable website solutions, - can be the basis for other, more specialized features and distributions, - model the standards for interoperable features.