Yesterday, after publishing a blog post about Nasdaq's Drupal 8 distribution for investor relations websites, I realized I don't talk enough about "Drupal distributions" on my blog. The ability for anyone to take Drupal and build their own distribution is not only a powerful model, but something that is relatively unique to Drupal. To the best of my knowledge, Drupal is still the only content management system that actively encourages its community to build and share distributions.

A Drupal distribution packages a set of contributed and custom modules together with Drupal core to optimize Drupal for a specific use case or industry. For example, Open Social is a free Drupal distribution for creating private social networks. Open Social was developed by GoalGorilla, a digital agency from the Netherlands. The United Nations is currently migrating many of their own social platforms to Open Social.

Another example is Lightning, a distribution developed and maintained by Acquia. While Open Social targets a specific use case, Lightning provides a framework or starting point for any Drupal 8 project that requires more advanced layout, media, workflow and preview capabilities.

For more than 10 years, I've believed that Drupal distributions are one of Drupal's biggest opportunities. As I wrote back in 2006: Distributions allow us to create ready-made downloadable packages with their own focus and vision. This will enable Drupal to reach out to both new and different markets..

To capture this opportunity we needed to (1) make distributions less costly to build and maintain and (2) make distributions more commercially interesting.

Making distributions easier to build

Over the last 12 years we have evolved the underlying technology of Drupal distributions, making them even easier to build and maintain. We began working on distribution capabilities in 2004, when the CivicSpace Drupal 4.6 distribution was created to support Howard Dean's presidential campaign. Since then, every major Drupal release has advanced Drupal's distribution building capabilities.

The release of Drupal 5 marked a big milestone for distributions as we introduced a web-based installer and support for "installation profiles", which was the foundational technology used to create Drupal distributions. We continued to make improvements to installation profiles during the Drupal 6 release. It was these improvements that resulted in an explosion of great Drupal distributions such as OpenAtrium (an intranet distribution), OpenPublish (a distribution for online publishers), Ubercart (a commerce distribution) and Pressflow (a distribution with performance and scalability improvements).

Around the release of Drupal 7, we added distribution support to This made it possible to build, host and collaborate on distributions directly on Drupal 7 inspired another wave of great distributions: Commerce Kickstart (a commerce distribution), Panopoly (a generic site building distribution), Opigno LMS (a distribution for learning management services), and more! Today, lists over 1,000 distributions.

Most recently we've made another giant leap forward with Drupal 8. There are at least 3 important changes in Drupal 8 that make building and maintaining distributions much easier:

  1. Drupal 8 has vastly improved dependency management for modules, themes and libraries thanks to support for Composer.
  2. Drupal 8 ships with a new configuration management system that makes it much easier to share configurations.
  3. We moved a dozen of the most commonly used modules into Drupal 8 core (e.g. Views, WYSIWYG, etc), which means that maintaining a distribution requires less compatibility and testing work. It also enables an easier upgrade path.

Open Restaurant is a great example of a Drupal 8 distribution that has taken advantage of these new improvements. The Open Restaurant distribution has everything you need to build a restaurant website and uses Composer when installing the distribution.

More improvements are already in the works for future versions of Drupal. One particularly exciting development is the concept of "inheriting" distributions, which allows Drupal distributions to build upon each other. For example, Acquia Lightning could "inherit" the standard core profile – adding layout, media and workflow capabilities to Drupal core, and Open Social could inherit Lightning - adding social capabilities on top of Lightning. In this model, Open Social delegates the work of maintaining Layout, Media, and Workflow to the maintainers of Lightning. It's not too hard to see how this could radically simplify the maintenance of distributions.

The less effort it takes to build and maintain a distribution, the more distributions will emerge. The more distributions that emerge, the better Drupal can compete with a wide range of turnkey solutions in addition to new markets. Over the course of twelve years we have improved the underlying technology for building distributions, and we will continue to do so for years to come.

Making distributions commercially interesting

In 2010, after having built a couple of distributions at Acquia, I used to joke that distributions are the "most expensive lead generation tool for professional services work". This is because monetizing a distribution is hard. Fortunately, we have made progress on making distributions more commercially viable.

At Acquia, our Drupal Gardens product taught us a lot about how to monetize a single Drupal distribution through a SaaS model. We discontinued Drupal Gardens but turned what we learned from operating Drupal Gardens into Acquia Cloud Site Factory. Instead of hosting a single Drupal distribution (i.e. Drupal Gardens), we can now host any number of Drupal distributions on Acquia Cloud Site Factory.

This is why Nasdaq's offering is so interesting; it offers a powerful example of how organizations can leverage the distribution "as-a-service" model. Nasdaq has built a custom Drupal 8 distribution and offers it as-a-service to their customers. When Nasdaq makes money from their Drupal distribution they can continue to invest in both their distribution and Drupal for many years to come.

In other words, distributions have evolved from an expensive lead generation tool to something you can offer as a service at a large scale. Since 2006 we have known that hosted service models are more compelling but unfortunately at the time the technology wasn't there. Today, we have the tools that make it easier to deploy and manage large constellations of websites. This also includes providing a 24x7 help desk, SLA-based support, hosting, upgrades, theming services and go-to-market strategies. All of these improvements are making distributions more commercially viable.


bojanz (not verified):

Small correction: Ubercart was never a distribution, especially not a distribution of Commerce (which is a D7/D8 continuation of the D6 Ubercart module by its original author, Ryan Szrama).

Max Ra (not verified):

Distributions are indeed a unique value proposition by Drupal. In many cases they go hand-in-hand with a multi-site setup that leverages a distribution and then allows further customization on a site level, making it possible to power hundreds of websites this way in a very efficient manner. Unfortunately Composer does not allow such per-site customization, making it hard for many organizations to migrate to Drupal 8: Resolving this issue would pave the way for many higher education and government organizations to migrate to Drupal 8.



While it would be good to improve Drupal's Composer support, it takes a lot more to run a successful SaaS business. Running a SaaS business involves complex infrastructure management, code management, site management, configuration management, reporting and analytics, billing systems, support tools, etc. Better Composer support might make it all a bit easier though!

Tim Lehnen - h… (not verified):

This is a very timely discussion - Drupal 8's use of Composer and configuration management will hopefully be a renaissance for building distributions - though I think there's still work to do for us to figure out the best way to support the Drupal 8 model of distributions on

I concur as well that distributions represent that unique value for end-users and evaluators of Drupal - giving them the extra leg-up on getting started with Drupal for their needs. This is part of why distributions are highlighted on the newly launched industry pages on They are a great way to show evaluators in a specific industry, "Hey there's a distribution of Drupal built just for you!".

Gus Austin (not verified):

While Drupal 8 may resolve some of the technical challenges, there's still a significant amount of time needed to develop and maintain a distribution or Drupal product. There's a reason why most of the popular distros began as internal projects of a company. Many aren't sustained if the company shifts it's focus somewhere else.

If Drupal wants to encourage its community to build and share 'quality' distributions, there needs to better tools and models to sustain. provides a few examples. As an open source project itself, OpenCollective provides multiple ways to leverage or integrate -



I totally agree we're not done improving our tools or figuring out different business/sustainability models behind Drupal distributions – that is what my blog post was all about. We'll keep making progress!

I believe Nasdaq's Drupal-as-a-service platform will be very sustainable but they can charge a premium for the reliability, security and scalability aspects of their solution.

Gus Austin (not verified):

We're hoping to prove some of these concepts with Building on top of Thunder, using OpenCollective to collect/distribute funds, and offering a hosted service.

I think we can make community maintained and sustained distributions a reality. Finding better ways to collaborate, share best practices, onboard contributors, and pool resources between projects would help a great deal.

Jeff (not verified):

Case in point - Open Atrium 2 came out with much fanfare and exciting development over a couple of years and then - it bombed. No explanation - just stopped further development - bare bones maintenance only. I suspect it was a case of not having the resources to move to D8 in the long term driven by a likely disappointing commercial ROI. Nice product but overly complex for anyone to inherit without deep pockets because of the heavy use of Features for config mgmt, and dependency on OG which is a long way from D8, as is Panopoly, and other unavoidable interoperational complexities. As a result the usage of OA2 is in steady decline.

So if you did use it as a SaaS platform you're pretty much stuck on D7 (as long as Phase2 maintains it) with no move to D8. The risk of failure is very high with a distro dependent on other distros like Panopoly, and complex modules like Organic Groups, not to mention quite a few custom patched modules in alpha state. So the reality is you really need to roll your own if you want to offer and support a long term SaaS platform. I nearly got burned by OA2 and now am developing a similar in-house "distro" that borrows a lot from OA2 philosophically but with much less complexity and minimal dependency on other distros, and built on D8.

Distros sound good on paper but come with the same caveats as modules - is the maintainer reliable in the long term? For a distro developed and maintained by a commercial enterprise the answer is very often no, especially if there's a lot of custom mods and/or dependency on other complex distros. Or be prepared to inherit development yourself, which sort of defeats the whole purpose of distros.

benjamin melançon (not verified):

So glad to see continued focus on making distributions better and easier and a continuing key differentiation for Drupal!

The Drutopia initiative - - as inheritor of the Open Aid and Open Outreach distributions is also making Free Software as a Service, or LibreSaaS, central to its business model, as a way to support development of the distribution without a NASDAQ-sized organization as the engine.

Afraid I haven't pulled this into a blog post yet but I talked about it at the February Boston Drupal meetup, and for better or for worse there's video:…



Great timing! Clearly, I should come to the Boston Drupal meet-ups more often!

Like you, I believe it is important to provide the capability to easily transfer data from one platform or solution to another, and not be shackled to proprietary vendors' platforms. In the past, I've referred to this as "OpenSaaS" and "OpenPaas" [1, 2].

Almost all SaaS providers employ a proprietary model – they might allow you to export your data, but they usually don't allow you to export the underlying code. For example, users of Drupal Gardens were able to export their Drupal Gardens site – the code, the theme and data – and move of the platform to any Drupal hosting environment. By doing so, we provided an easy on-ramp but we allowed them to grow beyond the capabilities of Drupal Gardens without locking them in.

I really believe we can bring the Open Source principles to SaaS where appropriate, and I hope your model will do the same.

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.