Drupal as a Service

Our idea of delivering Drupal as a service is starting to catch on as people realize just what it could mean for the project’s ability to expand. But the notion of “SaaSifying” open-source tools isn’t new, and actually we think the traditional model is kind of broken.

Sure, there are plenty of providers running open-source tools "as a service," often providing significant value in terms of convenience for setup and administration. WordPress.com is probably the premiere example: the code is open-source, and you aren't locked-in to any proprietary tools if you start a blog there. It’s great exposure for the WordPress project, and it is in fact possible to take your ball and go home — or to another provider — if you want, which is more than we can say for most closed-source SaaS offerings.

However, while there’s no lock-in, you're actually locked out of your code as long as it’s on the WP.com service. You can't touch it, meaning you're effectively cut off from the teeming universe of open-source innovation. Without the ability to add your own plugins or themes, you're stuck with whatever the provider decides to give you. That doesn't seem very cutting edge.

Worse, it negates a lot of the value of open source: the ability to extend, integrate and leverage contributed code. This value is even more present for Drupal. Our tagline is “come for the code, stay for the community.” If you can’t touch your code, and you’re cut off from the universe of community contributions (and service providers), what exactly is the point again?

When it comes to Drupal, the 90s-style model of a single-codebase with many tenants simply won’t get it done. You can’t just drop a monolithic multi-site on the internet and expect a revolution. The question is, what does it take to really deliver Drupal as a Service in a way that changes the game?

At Pantheon, we're inherently suspicious of existing models, and anything that smells like limited innovation, especially lock-ins or lock-outs. We don’t want to do it that way. When we first got started, we asked ourselves “what would need to be possible on the ultimate Drupal as a Service offering?”

Users would need to be able to:

• Launch sites quickly.
• Start with any number of Drupal products, including your own re-usable start-states.
• Access every site codebase in its entirety.
• Make changes to the code and leverage the power of the Drupal community, both through contributed code and the professional services ecosystem.
• Manage a portfolio of sites to keep things updated and on-track.
• Avoid single points of failure: problems on one codebase can't spill over to another.
• Use automated maintenance where humans don't need to be involved, and management that’s simplified and streamlined where they do.
• Eliminate scalability as a risk factor.

That's the vision that's been guiding us. We think the future of Drupal as a service has huge potential -- but only if it's done in a way that's open to the Drupal community and supports the growing ecosystem around the project.

We’re doing it, delivering next-generation infrastructure with a range of great user-facing Drupal products (like Open Academy, Open Public, etc) available out of the box. We keep it free and open for developers to use and easy for customers to try. This accessibility eliminates the friction around start-up but also lets our users dig in as deeply as they care to. While you don't have to break out a text editor to build your site, if you want to get something done that takes a module, or you want to build a custom theme, you can do it yourself or hire the developer of your choice.

For developers, we’re committed to being a true platform for innovation. In addition to keeping our service free and open, we’re contributing to important core initiatives like CMI and also developing Panopoly as a best-practice “base” for future Drupal products.

We want to help the Drupal ecosystem converge on a solid set of standards for site-building, product development, and product augmentation — similar to how we helped best-practices emerge around a high-performance runtime stack. This will help more developers build better sites for a wider range of customers, in less time, with less stress, worry, and long-term hassle.

That's open; that's Drupal; and that's service. That's how we get to 10% of the web. That's Pantheon.