Always be shippable

Drupal will soon be 15 years old, and 5 of that will be spent on building Drupal 8 -- a third of Drupal's life. We started work on Drupal early in 2011 and targeted December 1, 2012 as the original code freeze date. Now almost three years later, we still haven't released Drupal 8. While we are close to the release of Drupal 8, I'm sure many many of you are wondering why it took 3 years to stabilize. It is not like we didn't work hard or that we aren't smart people. Quite the contrary, the Drupal community has some of the most dedicated, hardest working and smartest people I know. Many spent evenings and weekends pushing to get Drupal 8 across the finish line. No one individual or group is to blame for the delay -- except maybe me as the project lead for not having learned fast enough from previous release cycles.

Trunk-based development

The past 15 years we used "trunk-based development"; we built new features in incremental steps, maintained in a single branch called "trunk". We'd receive the feature's first patch, commit it to our main branch, put it behind us, and move on to the next patch. Trunk-based development requires a lot of discipline and as a community we have mostly mastered this style of development. We invested heavily in our testing infrastructure and established a lot of processes. For all patches, we had various people reviewing the work to make sure it was solid. We also had different people figure out and review all the required follow-up work to complete the feature. The next steps are carefully planned and laid out for everyone to see in what we call "meta" issues. The idea of splitting one large feature into smaller tasks is not a bad idea; it helps to make things manageable for everyone involved.

Given all this rigor, how do you explain the delays then? The problem is that once these features and plans meet reality, they fall apart. Some features such as Drupal 8's configuration management system had to be rewritten multiple times based on our experience using it despite passing a rigorous review process. Other features such as our work on URL routing, entity base fields and Twig templating required much more follow-up work compared to what was initially estimated. It turns out that breaking up a large task into smaller ones requires a lot of knowledge and vision. It's often impossible to estimate the total impact of a larger feature on other subsystems, overall performance, etc. In other cases, the people working on the feature lacked time or interest to do the follow-up work, leaving it to others to complete. We should realize is that this is how things work in a complex world and not something we are likely to change.

The real problem is the fact that our main branch isn't kept in a shippable state. A lot of patches get committed that require follow-up work, and until that follow-up work is completed, we can't release a new version of Drupal. We can only release as fast as the slowest feature, and this is the key reason why the Drupal 8 release is delayed by years.

Shippable trunk based development

Trunk-based development; all development is done on a single main branch and as a result we can only release as fast as the slowest feature.

We need a better way of working -- one that conforms to the realities of the world we live in -- and we need to start using it the day Drupal 8.0.0 is released. Instead of ignoring reality and killing ourselves trying to meet unrealistic release goals, we need to change the process.

Feature branch workflow

The most important thing we have to do is keep our main branch in a shippable state. In an ideal world, each commit or merge into the main branch gives birth to a release candidate — it should be safe to release after each commit. This means we have to stop committing patches that put our main branch in an unshippable state.

While this can be achieved using a trunk-based workflow, a newer and better workflow called "feature branch workflows" has become popular. The idea is that (1) each new feature is developed in its own branch instead of the main branch and that (2) the main branch only contains shippable code.

Keeping the main branch shippable at all times enables us to do frequent date-based releases. If a specific feature takes too long, development can continue in the feature branch, and we can release without it. Or when we are uncertain about a feature's robustness or performance, rather than delaying the release, it will simply have to wait until the next release. The maintainers decide to merge in a feature branch based on objective and subjective criteria. Objectively, the test suite must pass, the git history must be clean, etc. Subjectively, the feature must deliver value to the users while maintaining desirable characteristics like consistency (code, API, UX), high performance, etc.

Shippable feature branching

Feature branching; each feature is developed in a dedicated branch. A feature branch is only merged into the main branch when it is "shippable". We no longer have to wait for the slowest feature before we can create a new release.

Date-based releases are widely adopted in the Open Source community (Ubuntu, OpenStack, Android) and are healthy for Open Source projects; they reduce the time it takes for a given feature to become available to the public. This encourages contribution and is in line with the "release early, release often" mantra. We agreed on the benefits and committed to date-based releases following 8.0.0, so this simply aligns the tooling to make it happen.

Feature branch workflows have challenges. Reviewing a feature branch late in its development cycle can be challenging. There is a lot of change and discussion already incorporated. When a feature does finally integrate into main, a lot of change hits all at once. This can be psychologically uncomfortable. In addition, this can be disruptive to the other feature branches in progress. There is no way to avoid this disruption - someone has to integrate first. Release managers minimize the disruption by prioritizing high priority or low disruption feature branches over others.

Here is a workflow that could give us the best of both worlds. We create a feature branch for each major feature and only core committers can commit to feature branches. A team working on a feature would work in a sandbox or submit patches like we do today. Instead of committing patches to the main branch, core committers would commit patches to the corresponding feature branch. This ensures that we maintain our code review process with smaller changes that might not be shippable in isolation. Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review.

Feature branches are also not the silver bullet to all problems we encountered with the Drupal 8 release cycle. We should keep looking for improvements and build them into our workflows to make life easier for ourselves and those we are implementing Drupal for. More on those in future posts.

How Acquia is addressing the explosion of sites

I believe that the "digitalization" of the world is a "megatrend" that will continue for decades. On the one hand, organizations are shifting their businesses online, often inventing new ways to do business. On the other hand, customers are expecting a better and smarter user experience online.

This has led to two important sub-trends: (1) the number of sites an organization is creating and managing is growing at a rapid clip, (2) so is the underlying complexity of each website.

Forrester Research recently surveyed large enterprises about their website portfolio and found that on average they manage 268 properties across various channels. On top of that, each website is becoming more and more advanced. They evolved from simple HTML pages to dynamic websites to digital experience platforms that need to integrate with many other business systems. The combination of these two trends -- increasing number of sites and the growing complexity of each site -- poses real challenges to most organizations.

At Acquia, we are seeing this explosion of websites in the enterprise every day. Many organizations have different websites for different brands and products, want different websites for each country or region they operate in, or offer separate portals for their affiliates, dealers, agents or franchises. We're also seeing organizations, small and large, operate a large number of marketing campaign websites. These organizations aren't focused on scaling back their online properties but rather how best to manage them over time.

I outlined this trend and its challenges almost five years ago (see Acquia product strategy and vision) and most of it is still relevant today, if not more relevant. In this blog post, I want to give you an update and share some lessons learned.

Current situation

Most larger organizations run many different types of websites. It's not unusual for a small organization to have ten websites and for a large organization to have hundreds of websites. Some of Acquia's largest customers operate thousands of websites.

Acquia cloud site factory many sites

Most organizations struggle to manage their growing portfolio of digital properties. You'd be surprised how many organizations have more than 20 different content management systems in use. Often this means that different teams are responsible for them and that they are hosted on different hosting environments. It is expensive, creates unnecessary security risks, poses governance challenges, leads to brand inconsistency, makes it difficult to create a unified customer experience, and more. It costs large organizations millions of dollars a year.

Acquia cloud site factory many platforms

Drupal's unfair advantage

When managing many sites, Drupal has an unfair advantage in that it scales from simple to complex easily. That scalability, coupled with a vast ecosystem of modules, elevate Drupal from a single site point solution to a platform on which you can build almost any kind of site: a brand site, a corporate website, a customer support community, a commerce website, an intranet, etc. You name it.

This is in contrast to many of Drupal's competitors that are either point solutions (e.g. SharePoint is mainly used for intranets) or whose complexity and cost don't lend themselves to managing many sites (e.g. Adobe Experience Manager and Sitecore are expensive solutions for a quick marketing campaign site, while WordPress can be challenging for building complex websites). So the first thing people can do is to standardize on Drupal as a platform for all of their site needs.

Acquia cloud site factory many drupals

By standardizing on Drupal, organizations can simplify training, reduce maintenance costs, streamline security and optimize internal resources – all without sacrificing quality or requirements. Standardizing on Drupal certainly doesn't mean every single site needs to be on Drupal. Transitioning from 20 different systems to 3 still translates into dramatic cost savings.

The Acquia advantage

Once an organization decides to standardize on Drupal, the question is how best to manage all these sites? In 2013 we launched Acquia Cloud Site Factory (ACSF), a scalable enterprise-grade multi-site management platform that helps organizations to easily create, deploy and govern all their sites. Today, some of Acquia's biggest customers use ACSF to manage hundreds of sites - in fact on average an ACSF customer is currently managing 170 websites within their Site Factory platform and that number is growing rapidly.

Acquia commissioned Forrester Research to analyze the benefits to organizations who have unified their sites on a single platform. Forrester found that moving to a single platform dramatically reduced site development and support costs, conserved IT and marketing resources, and improved standardization, governance and scalability — all while accelerating time-to-market and the delivery of better digital experiences.

One of the things we've learned is that a complete multi-site management solution needs to include advanced tools for both developers and content managers. The following image illustrates the different layers of a complete multi-site management solution:

Acquia Cloud Site Factory solution stack

The different layers of the Acquia Cloud Site Factory solution stack.

Let's go through these individually from the bottom up.

Infrastructure management

Consider an organization that currently has 50 websites, and plans to add 10-15 more sites every year. With ACSF these sites run on a platform that is scalable, secure and highly reliable. This infrastructure also allows hardware resources to be logically isolated based on the site's needs as well as scaled up or down to meet any ad-hoc traffic spikes. These capabilities enable organizations to simplify multi-site management efforts and eliminate operational headaches.

Code management

If this organization with 50 sites had individual codebases for each site, that would be 50 disparate codebases to manage. With ACSF, the underlying code can be shared and managed in one central place but the content, configuration, and creative look-and-feel can be catered to each individual sites' needs. ACSF also enable developers to easily add or remove features from their codebases for individual sites. ACSF also comes with tools to automate the process of rolling out updates across all their sites.

Site management

Organizations with many sites also need efficient ways to manage and govern them effectively; from developer tools such as Git, Travis, or Behat that enable them to build, test and maintain sites, to tools for non-developers to quickly clone and spin up sites using site templates defined by a brand manager or a digital design team. ACSF enables customers to effortlessly manage all their sites from a single intuitive dashboard. Developers can create groups of users as well as sites allowing certain users to manage their dedicated domain of sites without stepping over other sites. Non-technical content managers can quickly spin up new sites by cloning existing ones they have access to and updating their configuration, content and look-and-feel. These features allow organizations to launch sites at unprecedented speed inherently improving their overall time to market.

Content sharing

Write once, publish anywhere. We learned from customers managing multiple sites that one thing they often need is the ability to easily share content between sites. For example, if an organization has a privacy policy that needs to be updated, it doesn't make sense to update all their 50 sites individually. There needs to be an easier way to discover existing content that can be repurposed across other sites as well as the ability to author new content once within a platform and deliver it to other sites as needed.


Finally, I should mention personalization. For a few years now we have been developing Acquia Lift. Acquia Lift builds unified customer profiles across all your websites, and uses that information to deliver real-time, contextual, and personalized experiences. For instance, if the organization in the above example had 50 websites for each of their 50 different products, Acquia Lift can present relevant content to its users as they browse across these different sites. This enables organizations to convert anonymous site visitors into known customers and establish a meaningful engagement between them.


I believe that the "multi-sites era" will continue to accelerate; not only will we see more sites, but every site will become increasingly complex. Organizations need to think about how to efficiently manage their website portfolio. If you're not thinking ahead, you're falling behind.

Seb Van Stichel

Seb van stichel

Today the world welcomed a healthy baby boy: Seb Van Stichel. Congratulations to my sister, Mien, and my brother-in-law, Johan. My Opa, the oldest member of our family at 94 years old, is holding his great-grandson, the youngest member of the family. I'm honored to be Seb's godfather; my Christmas budget will be going up. :-)

Drupal 8 now ships with beta-to-beta updates

We've just achieved a big and exciting milestone in Drupal 8's development: starting with Drupal 8 beta 15, we are providing beta-to-beta upgrade paths. This will make it much easier to update Drupal 8 development sites between the current beta and future betas and release candidates.

There has been a lot of excitement building around Drupal 8. Many have been wondering when to start building Drupal 8 sites. The answer for many is NOW.

This change signals an important opportunity for organizations to begin developing with Drupal 8, especially for:

  • Sites that rely mainly on the expanded functionality provided by Drupal 8 core alone.
  • Projects that will take months of development time.
  • Sites for which the benefits of Drupal 8's outweigh the effort needed to port (or work around) contributed modules that do not yet have Drupal 8 versions.

I strongly encourage you to evaluate Drupal 8 for your upcoming projects. Also, if you haven't already, now is the time to port contributed modules so they are ready in time for Drupal 8's release! There are only about five release-blocking issues left before we create the first release candidate.

Note that betas are not supported releases of Drupal, and both developing and launching sites with beta releases present risks. However, I'm pleased that various Drupal agencies, including Acquia, are helping to eliminate those risks through support, development, and hosting optimized for Drupal 8.

Before you get started with Drupal 8, be sure to review all the release notes for beta 15.

Digital Distributors: The Supermarkets of the Web

It's hard to ignore the strong force of digital distributors on the open web. In a previous post, I focused on three different scenarios for the future of the open web. In two of the three scenarios, the digital distributors are the primary way for people to discover news, giving them an extraordinary amount of control.

When a small number of intermediary distributors get between producers and consumers, history shows us we have to worry -- and brace ourselves for big industry-wide changes. A similar supply chain disruption has happened in the food industry, where distributors (supermarkets) changed the balance of power and control for producers (farmers). There are a few key lessons we can take from the food industry's history and apply them to the world of the web.

Historical lessons from the food industry

When food producers and farmers learned that selling directly to consumers had limited reach, trading posts emerged and began selling farmers' products more than their own. As early as the 14th century, these trading posts turned into general stores, and in the 18th century, supermarkets and large-scale grocery stores continued that trend in retailing. The adoption of supermarkets was customer-driven; customers benefit from being able to buy all their food and household products in a single store. Today, it is certainly hard to imagine going to a dozen different speciality stores to buy everything for your day-to-day needs.

But as a result, very few farmers sell straight to consumers, and a relatively small amount of supermarkets stand between thousands of suppliers and millions of consumers. The supermarkets have most of the power; they control how products are displayed, and which ones gain prominent placement on shelves. They have been accused of squeezing prices to farmers, forcing many out of business. Supermarkets can also sell products at lower prices than traditional corner shops, leading to smaller grocery stores closing.

In the web's case, digital distributors are the grocery stores and farmers are content producers. Just like supermarket consumers, web users are flocking to the convenience and relevance of digital distributors.

Farmers supermarkets

This graph illustrates the market power of supermarkets / digital distributors. A handful of supermarkets / digital distributors stand between thousands of farmers / publishers and millions of consumers.

Control of experience

Web developers and designers devote a tremendous amount of time and attention to creating beautiful experiences on their websites. One of my favorites was the Sochi Olympics interactive stories that The New York Times created.

That type of experience is currently lost on digital distributors where everything looks the same. Much like a food distributor's products are branded on the shelves of a supermarket to stand out, publishers need clear ways to distinguish their brands on the “shelves” of various digital distribution platforms.

While standards like RSS and Atom have been extended to include more functionality (e.g. Flipboard feeds), there is still a long way to go to support rich, interactive experiences within digital distributors. As an industry, we have to develop and deploy richer standards to "transport" our brand identity and user experience from the producer to digital distributor. I suspect that when Apple unveils its Apple News Format, it will come with more advanced features, forcing others like Flipboard to follow suit.

Control of access / competition

In China, WeChat is a digital distributor of different services with more than 0.5 billion active users. Recently, WeChat blocked the use of Uber. The blocking comes shortly after Tencent, WeChat's parent company, invested in rival domestic car services provider Didi Kuaidi. The shutdown of Uber is an example of how digital distributors can use their market power to favor their own businesses and undermine competitors. In the food industry, supermarkets have realized that it is more profitable to exclude independent brands in favor of launching their own launching grocery brands.

Control of curation

Digital distributors have an enormous amount of power through their ability to manipulate curation algorithms. This type of control is not only bad for the content producers, but could be bad for society as a whole. A recent study found that the effects of search engine manipulation could pose a threat to democracy. In fact, Google rankings may have been a deciding factor in the 2014 elections in India, one of the largest elections in the world. To quote the study's author: "search rankings could boost the proportion of people favoring any candidate by more than 20 percent -- more than 60 percent in some demographic groups". By manipulating its search results, Google could decide the U.S. presidential election. Given that Google keeps its curation algorithms secret, we don't know if we are being manipulated or not.

Control of monetization

Finally, a last major fear is control of monetization. Like supermarkets, digital distributors have a lot of control over pricing. Individual web publishers must maintain their high quality standards to keep consumers demanding their work. Then, there is some degree of leverage to work into the business model negotiation with digital distributors. For example, perhaps The New York Times could offer a limited-run exclusive within a distribution platform like Facebook's Instant Articles or Flipboard.

I'm also interested to see what shapes up with Apple's content blocking in iOS9. I believe that as an unexpected consequence, content blocking will place even more power and control over monetization into the hands of digital distributors, as publishers become less capable of monetizing their own sites.


Dries Buytaert is the original creator and project lead of Drupal and the co-founder and CTO of Acquia. He writes about Drupal, startups, business, photography and building the world we want to exist in.

Updates from Dries straight to your mailbox