We just released Drupal 8.0.0! Today really marks the beginning of a new era for Drupal. Over the course of almost five years, we've brought the work of more than 3,000 contributors together to make something that is more flexible, more innovative, more easy to use, and more scalable.
Drupal 8 has been a big transformation for our community. This particular reboot has taken one-third of Drupal's lifespan to complete. In the process we've learned that reinvention doesn't come easily or quickly. There are huge market forces happening around us, and we can't exactly look away. Mobile is moving our society to near-universal, global internet access. Most companies have begun to transform themselves digitally, leaving established business models and old business processes in the dust. Digital experience builders are turning to platforms that give them greater flexibility, better usability, better integrations, and faster innovation. The pace of change in the digital world has become dizzying. If we were to ignore these market forces, Drupal would be caught flat-footed and quickly become irrelevant.
But we didn't. I'm proud to see that we've responded to these market forces with Drupal 8, and delivered a robust, solid product that can be used to build next-generation websites, web applications and digital experiences. We've implemented a more modern development framework, reimagined the usability and authoring experience, and made technical improvements that will help us build for the multilingual, mobile and highly personalized experiences of the future. From how we model content and get content in and out the system, to how we build and assemble experiences on various devices, to how we scale that to millions and millions of pageviews -- it all got much better with Drupal 8.
I'm personally incredibly proud of this release. Drupal 8 is the result of years of hard work and innovation by thousands of people, with lots of attention to detail at every level. Congratulations to everyone who stepped up to contribute; this was only possible thanks to your persistence and tireless hard work. It took a lot of learning, our best thinking and our best people to create Drupal 8, and I'm very, very proud of what we have accomplished together.
For 15 years, I have believed that Open Source offers significant advantages to proprietary solutions through superior innovation. Today, I believe that more than ever. Drupal 8 is another key milestone in helping us win and doing what is best for an open web. Of course, our job is not done but now is the time to have fun and celebrate this monumental milestone. Tonight, we'll be hosting more than 200 parties around the world! (It's also my 37th birthday today and the release of Drupal 8 along with all those parties is pretty much the best present ever!)
A couple of weeks ago a Chief Digital Officer (CDO) of one of the largest mobile telecommunications companies in the world asked me how a large organization such as hers should think about organizing itself to maintain control over costs and risks while still giving their global organization the freedom to innovate.
When it comes to managing their websites and the digital customer experience, they have over 50 different platforms managed by local teams in over 50 countries around the world. Her goal is to improve operational efficiency, improve brand consistency, and set governance by standardizing on a central platform. The challenge is that they have no global IT organization that can force the different teams to re-platform.
When asked if I had any insights from my work with other large global organizations, it occurred to me the ideal model she is seeking is very aligned to how an Open Source project like Drupal is managed (a subject I have more than a passing interest in).
Teams in different countries around the world often demand full control and decision-making authority over their own web properties and reject centralization. How then might someone in a large organization get the rest of the organization to rally behind a single platform and encourage individual teams and departments to innovate and share their innovations within the organization?
In a large Open Source project such as Drupal, contributions to the project can come from anywhere. On the one extreme there are corporate sponsors who cover the cost of full-time contributors, and on the other extreme there are individuals making substantial contributions from dorm rooms, basements, and cabins in the woods. Open Source's contribution models are incredible at coordinating, accepting, evaluating, and tracking the contributions from a community of contributors distributed around the world. Can that model be applied in the enterprise so contributions can come from every team or individual in the organization?
Reams have been written on how to incubate innovation, how to source it from the wisdom of the crowd, ignite it in the proverbial garage, or buy it from some entrepreneurial upstart. For large organizations like the mobile telecommunications company this CDO works at, innovation is about building, like Open Source, communities of practice where a culture of test-and-learn is encouraged, and sharing -- the essence of Open Source -- is rewarded. Consider the library of modules available to extend Drupal: there can be several contributed solutions for a particular need -- say embedding a carousel of images or adding commerce capability to a site -- all developed independently by different developers, but all available to the community to test, evaluate and implement. It may seem redundant (some would argue inefficient) to have multiple options available for the same task, but the fact that there are multiple solutions means more choices for people building experiences. It's inconceivable for a proprietary software company to fund five different teams to develop five different modules for the same task. They develop one and that is what their customers get. In a global innovation network, teams have the freedom to experiment and share their solutions with their peers -- but only if there is a structure and culture in place that rewards sharing them through a single platform.
Centers of Excellence (CoEs) are familiar models to share expertise and build alignment around a digital strategy in a decentralized, global enterprise. Some form multiple CoEs around shared utility functions such as advanced data analytics, search engine optimization, social media monitoring, and content management. CoEs have also grown to include Communities of Practice (CoP) where various "communities" of people doing similar things for different products or functions in multiple departments or locations, coalesce to share insights and techniques. In companies I've worked with that have standardized on Drupal, I've seen internal Drupal Camps and hackathons pop up much as they do within the Drupal community at-large.
My advice to her? Loosen control without losing control.
That may sound like a "have-your-cake-and-eat-it-too" cliche, but the Open Source model grew around models of crowd-sourced collaboration, constant and transparent communications, meritocracies, and a governance model that provides the platform and structure to keep the community pointed at a common goal. What would my guidance be for getting started?
Drupal and Open Source were created to address a need, and from their small beginnings grew something large and powerful. It is a model any business can replicate within their organization. So take a page out of the Open Source playbook: innovate, collaborate and share. Governance and innovation can coexist, but for that to happen, you have to give up a measure of control and start to think outside the box.
The web has done wonders to make government more accessible to its citizens. Take the State of New York; NY.gov is a perfect example of taking a people-centric approach to digital government. The site lets people easily access state government news and services, including real-time public transit updates, employment resources, healthcare information, and more.
One year ago, The State of New York redesigned and relaunched their website on Drupal in partnership with Code and Theory and Acquia. Today, one year later, they’ve nearly tripled the audience to more than 6 million users. The most-visited part of the site is the services section, which aligns well with the governor’s priority to provide better customer service to state residents. Annual pageviews have quadrupled since launch to a record high of more than 17 million and mobile usage has increased 275 percent.
For more details, check out the press release that the State of New York published today.
At Acquia Engage, our annual customer and partner conference held last week, Cisco's Jamal Haider spoke about the tremendous savings ($400 million USD!) that came from building its support community on the Acquia Platform and Drupal. The company transformed its support organization into a valuable self-service portal for customers, leading to a 77% deflection rate for customer service calls.
Using Cisco's support community, customers can access detailed, multilingual technical information on all of the company's products and services, including advice from experts, events, documents and videos. The site boasts more than 38 million visits a year and 600,000 active users. It is faster, more flexible and more user-friendly than ever before. In addition to massive cost savings, Haider cites Drupal's feature velocity as a main reason for the company's move away from Jive.
The explosion of content continues to grow. With more and more organizations managing multiple sites and digital channels, the distribution of content is increasingly difficult to manage. Content can easily become siloed in different sites or platforms. Different data models make it challenging to access, update, and replicate content changes across your sites.
Today, we're excited to announce Acquia Content Hub, a cloud-based content distribution and discovery service. Content Hub serves as a central content repository or hub that allows for bidirectional distribution of content between different platforms. Content Hub lets authors and site owners reuse content from other sites, commerce platforms, and more. To facilitate sharing between all these different systems, we normalize the content, and provide centralized tools to search and discover content within your network of sites. In addition, Content Hub can automatically keep content consistent across different sites (publish-subscribe), mitigating the risk of out of date information, all while respecting workflow rules on the local destination site.
I'm excited about the launch of Content Hub because I believe it will become a critical building block for creating digital experiences that are smart, personal, contextual, predictive, and continuous across digital touch-points in our lives (see Big Reverse of the Web). It's an ambitious vision that will require organizations to better leverage all of their content and data. This means that eventually all data has to get linked: from textual, audio and video data, to customer information and customer support data, to sensory and contextual customer information. To process that amount of data, we will have to build smart systems on top of it to create better digital experiences for the customer. Last year we launched Acquia Lift, and now 12 months later we're launching Content Hub -- both are important steps towards that vision.
Today Acquia announces the WPP-Acquia Alliance, a global partnership with the world's largest communications services company. This isn't just a milestone for Acquia -- I believe it to be significant for the Drupal community as well so let me tell you a bit more about it.
WPP is a marketing company. A very, very large marketing company. With more than 188,000 people in 112 countries, WPP's billings are nearly $76 billion USD and its revenues approach $19 billion USD.
The reason that the WPP-Acquia Alliance is interesting for Drupal, is because WPP's primary client is the Chief Marketing Officer (CMO). The influence of the CMO has been on the rise; their responsibility has evolved from "the one responsible for advertising" to having a critical role in designing the customer experience across all the customer touchpoints (including the websites). The CMO often has a deep understanding of how to use technology to deliver an integrated, system-wide customer experience. This is one of Drupal's strengths, and bringing organizations like WPP into the Drupal fold will help bring Drupal into the office of the CMO, grow the adoption of Drupal, and expands the opportunity for everyone in our community. If you believe, as I do, that the CMO is important, then I can't think of a better company to work with than WPP.
WPP will connect its Drupal developers from several agencies under one umbrella, creating a Drupal center of excellence, and the world's largest Acquia-certified Drupal practice. Globant, Hogarth, Mirum, Possible, Rockfish, VML and Wunderman are some of the agencies who'll be contributing to the WPP-Acquia Alliance, and building innovative Drupal applications for global clients. Acquia will provide WPP its open cloud platform, solutions for multi-site management, personalization tools, and more.
I feel lucky to be a part of creating and building Drupal. According to BuiltWith, Drupal powers 2.8% of websites in the top 1 million. That translates to 1 out of 35 websites. I've been thinking about what that means in terms of real impact: if any of the 3.2 billion internet users today have visited 35 or more of the top 1 million websites, they've "used" Drupal. I imagine most active internet users have visited more than 35 websites, and as such, Drupal must have "reached" almost everyone on the internet. That is a pretty incredible thought.
I've heard so many amazing stories about how Drupal sites have been a part of cultural, social and political movements. One of the stories that I'll never forget is from the Egyptian uprising in 2011, when the internet shut down for days and people took to the streets in protest of the Mubarak regime. This moment showed the profound impact of the web and the injustice citizens feel when it is taken away. The Drupal site Al Jazeera was an essential news source on this uprising for the rest of the world and remained online despite traffic to its live blog spiking 2,000 percent during the crisis.
Another such story is that of the Global Disaster Preparedness Center (GDPC), whose 189 partner organizations (including the American Red Cross) needed a better way to collaborate on disaster relief issues. GDPC embraced Open Source and built a multilingual Drupal site where disaster preparedness professionals can share information and resources that otherwise wouldn't be available. Considering the recent rise in natural disasters, this information has saved lives.
These two stories show how the web has the power to change lives, fuel economies, educate the masses and make the world much smaller in the best of ways. According to Cisco, Internet traffic in 2019 will be 64 times the volume in 2005. It is expected that another 1.8 billion people could come online by the end of 2018.
Yesterday, we announced the first Drupal 8 release candidate after almost five years of hard work by thousands of people in our community. The road towards Drupal 8 has been long and hard, but I'm excited that Drupal 8 will touch the next billion people who join the internet. They are joining fast. I hope you'll share stories of the impact Drupal has made on your lives as we continue to grow.
Today, we announce Drupal 8.0.0 RC1, the first Drupal 8 release candidate. It's a very exciting milestone, and one that has taken a lot of hard work, long nights, weekends, and extreme commitment from our community. I appreciate the dedication of everyone involved, and understand what it takes to give up personal time in pursuit of building something greater. So, for that I want to thank you.
In total, Drupal 8 has had more than 3,200 contributors and 15,000 committed patches. The good news is, we've finally reached the day when Drupal 8 has hit zero release-blocking bugs and is ready for takeoff!
Historically, the adoption of Drupal has roughly doubled with each new release. We expect no different from Drupal 8, a release I believe positions Drupal most strongly for the future. We've undergone some big architectural changes to get more people using Drupal, and to prepare ourselves for the future. I can't wait to see what the community does with Drupal 8. It's time to start building!
Today, we're excited to announce that Acquia has closed a $55 million financing round, bringing total investment in the company to $188.6 million. Led by new investor Centerview Capital Technology, the round includes existing investors New Enterprise Associates (NEA) and Split Rock Partners.
We are in the middle of a big technological and economic shift, driven by the web, in how large organizations and industries operate. At Acquia, we have set out to build the best platform for helping organizations run their businesses online, help them invent new ways of doing business, and maximize their digital impact on the world. What Acquia does is not at all easy -- or cheap -- but we've made good strides towards that vision. We have become the backbone for many of the world's most influential digital experiences and continue to grow fast. In the process, we are charting new territory with a very unique business model rooted Drupal and Open Source.
A fundraise like this helps us scale our global operations, sales and marketing as well as the development of our solutions for building, delivering and optimizing digital experiences. It also gives us flexibility. I'm proud of what we have accomplished so far, and I'm excited about the big opportunity ahead of us.
Of all the trends in the web community, few are spreading more rapidly than decoupled (or "headless") content management systems (CMS). The evolution from websites to more interactive web applications and the need for multi-channel publishing suggest that moving to a decoupled architecture that leverages client-side frameworks is a logical next step for Drupal. For the purposes of this blog post, the term decoupled refers to a separation between the back end and one or more front ends instead of the traditional notion of service-oriented architecture.
Decoupling your content management system enables front-end developers to fully control an application or site's rendered markup and user experience. Furthermore, the use of client-side frameworks helps developers give websites application-like behavior with smoother interactivity (there is never a need to hit refresh, because new data appears automatically), optimistic feedback (a response appears before the server has processed a user's query), and non-blocking user interfaces (the user can continue to interact with the application while portions are still loading).
Another advantage of a decoupled architecture is decoupled teams. Since front-end and back-end developers no longer need to understand the full breadth and depth of a monolithic architecture, they can work independently. With the proper preparation, decoupled teams can improve the velocity of a project.
Still, it's important to temper the hype around decoupled content management with balanced analysis. Before decoupling, you need to ask yourself if you're ready to do without functionality usually provided for free by the CMS, such as layout and display management, content previews, user interface (UI) localization, form display, accessibility, authentication, crucial security features such as XSS (cross-site scripting) and CSRF (cross-site request forgery) protection, and last but not least, performance. Many of these have to be rewritten from scratch, or can't be implemented at all, on the client-side. For many projects, building a decoupled application or site on top of a CMS will result in a crippling loss of critical functionality or skyrocketing costs to rebuild missing features.
To be clear, I'm not arguing against decoupled architectures per se. Rather, I believe that decoupling needs to be motivated through ample research. Since it is still quite early in the evolution of this architectural paradigm, we need to be conscious about how and in what scenarios we decouple. In this blog post, we examine different decoupled architectures, discuss why a fully decoupled architecture is not ideal for all use cases, and present "progressive decoupling", a better approach for which Drupal 8 is well-equipped. Today, Drupal 8 is ready to deliver pages quickly and offers developers the flexibility to enhance user experience through decoupled interactive components.
Traditionally, CMSes have focused on making websites rather than web applications, but the line between them continues to blur. For example, let's imagine we are building a site delivering content-rich curated music reviews alongside an interaction-rich ticketing interface for live shows. In the past, this ticketing interface would have been a multi-step flow, but here we aim to keep visitors on the same page as they browse and purchase ticket options.
To write and organize reviews, beyond basic content management, we need site building tools to assemble content and lay it out on a page. On the other hand, for a pleasant ticket purchase experience, we need seamless interactivity. From the end user's perspective, this means a continuous, uninterrupted experience using the application and best of all, no need to refresh the page.
In a fully decoupled architecture, our losses from having to rebuild what Drupal gives us for free outweigh the wins from client-side frameworks. With a fully decoupled front end, we lose important aspects of the theme layer (which is tightly intertwined with Drupal APIs) such as theme hook suggestions, Twig templating, and, to varying degrees, the render pipeline. We lose content preview and nuances of creating, curating, and composing content such as layout management tools. We lose all of the advancements in accessibility and user experience that make Drupal 8 websites a great tool for both end users and site builders, like ARIA roles, improved system messages, and, most visibly, the fully integrated Drupal toolbar on non-administrative pages. Moreover, where there is elaborate interactivity, security vulnerabilities are easily introduced.
Fully decoupled architectures can also have a performance disadvantage. We want users to see the information they want as soon as possible (time to first paint) and be able to perform a desired action as soon as possible (time to interaction). A well-architected CMS will have the advantage over a client-side framework.
Much of the content we want to send for our music website is cacheable and mostly static, such as a navigation bar, recurring footer, and other unchanging components. Under a traditional page serving model, however, operations taking longer to execute can hold up simpler parts of the page in the pipeline and significantly delay the response to the client. In our music site example, this could be blocks containing songs a user listened to most in the last week and the song currently playing in a music player.
What we really need is a means of selectively processing those expensive components later and sending the less intensive bits earlier. With BigPipe, an approach for client-side dynamic content substitution, we can render our pages progressively, where the skeleton of the page loads first, then expensive components such as "songs I listened to most in the last week" or "currently playing" are sent to the browser later and fill out placeholders. This component-driven approach gives us the best of both worlds: non-blocking user interfaces with a brisk time to first interaction and rapid piecemeal loading of complete Drupal pages that leverage the theme layer.
Currently, Drupal 8 is the only CMS with BigPipe deeply integrated across the board for both core and contributed modules—they merely have to provide some cacheability metadata and need no awareness of the technical minutiae. Drupal 8's Dynamic Page Cache module ensures that the page skeleton is already cached and can thus be sent immediately. For example, as menus are identical for many users, we can reuse the menu for those users that can access the same menu links, so Dynamic Page Cache is able to cache those as part of the page skeleton. On the other hand, a personalized block with a user's most played songs is less effective to cache and will therefore be rendered after the page skeleton is sent. This cacheability is built into core, and every contributed module is required to provide the necessary metadata for it.
Client-side frameworks encounter some critical and inescapable drawbacks of conducting all rendering on the client side. On slow connections such as on mobile devices, client-side rendering slows down performance, depletes batteries faster, and forces the user to wait. Because most developers test locally and not in real-world network conditions on actual devices, it's easy to forget that real risks of sluggishness and unreliability, especially due to spotty connectivity, continue to confront any fully decoupled site — Drupal or otherwise.
As we've seen, fully decoupling eliminates crucial CMS functionality and BigPipe rendering. But what if we could decouple while still having both? What if we could keep things like layout management, security, and accessibility when decoupling while still enjoying all the benefits an interaction-rich single-page application would give us? More importantly, what if we could take advantage of BigPipe to leverage shortened times to interaction and lowered obstacles for heavily personalized content? The answer lies in decoupled components, or progressive decoupling. Instead of decoupling the entire page, why not decouple only portions of it, like individual blocks?
This component-driven decoupled architecture comes with big benefits over a fully decoupled architecture. Namely, traditional content management and workflow, display and layout management are still available to site builders. To return to our music website example, we can drag a block containing the songs a user listened to most in the past week into an arbitrarily located region on the page; a front-end developer can then infuse interactivity such that an account holder can play a song from that list or add it to a favorites list on the fly. Meanwhile, if a content creator wants to move the "most listened to in the past week" block from the right sidebar of the page to the left side of the page, she can do that with a few mouse clicks, rather than having to get a front-end developer involved.
We call this approach progressive decoupling, because you decide how much of the page and which components to decouple from Drupal's front end or dedicated Drupal renderings. For this reason, progressively decoupled Drupal brings decoupling to the assembled web, something I'm very passionate about, because empowering site builders and administrators to build great websites without (much) programming is important. Drupal is uniquely capable for this, precisely because it allows for varying degrees of decoupledness.
Drupal 8 is ahead of the competition and is your go-to platform for building decoupled websites. It comes with a built-in REST API for all content, a system to query data from Drupal (e.g. REST exports in the Views module), and a BigPipe implementation. It will be even better once the full range of contributed modules dealing with REST is available to developers.
With Drupal 8, an exciting spectrum opens up beyond just the two extremes of fully decoupling and traditional Drupal. As we've seen, fully decoupling opens the door to a Drupal implementation providing content to a broad range of one or more clients ("many-headed" Drupal), such as mobile applications, interactive kiosks, and television sets. But progressive decoupling goes a step further, since you can fully decouple and progressively decouple a single Drupal site with all the tools to assemble content still intact.
Although Drupal has made huge strides in the last few years and is ahead of the competition, there is still work to do. Traditional Drupal, fully decoupled Drupal, and progressively decoupled Drupal can all coexist. With improved decoupling tools, Drupal can be an even better hub for many heads: a collection of applications and sites linked and supported by a single backend.
One of the most difficult issues facing front-end developers is network performance with REST. For example, a REST query fetching multiple content entities requires a round trip to the server for each individual entity, each of which may also depend on relational data such as referenced entities that require their own individual requests to the server. Then, to gather the required data, each REST query needs a corresponding back-end bootstrap, which can be quite hefty. Such a large stack of round trips and bootstraps can be prohibitively expensive.
Beyond performance and endpoint management, developer experience also suffers under a RESTfully decoupled Drupal architecture. For each individual request, there is a single corresponding schema for the response that is immutable. In order to retrieve differently formatted or filtered data according to your needs, you must create a second variant of a given endpoint or provision a new endpoint altogether. Front-end developers concerned about performance limitations desire full control from the client side over what schema comes back and want to avoid working with the server side.
Decoupling thus reveals the need to investigate better ways of exposing data to the client side. As our pages and applications become ever more component-driven, the complexity of the queries we must perform and our demands on their performance increase. What if we could extract only the data we need by writing queries that are efficient and performant by default? Sebastian Siemssen proposes using Facebook's GraphQL (see demo video and project on drupal.org) due to the client's explicit definition of what schema to return and the use of consolidated queries which break apart into smaller calls and recombine for the response, thereby minimizing round trips.
I like GraphQL's approach for both fully and progressively decoupled front-ends. It means that decoupled sites will enjoy better overall performance and give front-end developers a better experience: very few round trips to the server, no need for custom endpoints, no need for versioning, and no dependence on back-end developers. (I even wonder if GraphQL could be the basis for a future version of Views.)
In addition, work on rendering improvements such as BigPipe should continue in order to explore the possibilities given a more progressive rendering system. It's currently in progress to accelerate Drupal's perceived page loads where users consume expensive or personalized content. As for tools within the administration layer and in the contributed space, further progress in Drupal 8 is also necessary for layout management tools such as Panels and block placement that would make decoupling at a granular level much easier.
A great deal is being done, but we could always use more help; please get in touch if you're interested in contributing code or funding our work. After all, the potential impact of progressive rendering on the future of decoupled Drupal is huge.
Decoupled content management is a rapidly evolving trend that has the potential to upend existing architectural paradigms. Nonetheless, we need to be cautious when approaching decoupled projects due to the loss of functionality and performance.
With Drupal 8, we can use progressive rendering to build a Drupal-driven skeleton of the page to fill out increasingly expensive portions of the page. We can then selectively delineate which parts of the page decouple once the page load is complete. This concept of progressive decoupling offers the best of both worlds. Layout management, security, and content previews are unaffected, and within page components, front-end application logic can work its magic.
Drupal 8 is now a state-of-the-art platform for building projects that lie at the nexus between traditional content-rich websites and modern interaction-rich web applications. As always, while remarkable strides have been made with Drupal 8, more work remains.
Special thanks to Preston So and Wim Leers at Acquia for contributions to this blog post and to Moshe Weitzman, Kevin O'Leary, Christian Yates, David Hwang, Michael Pezzi and Erik Baldwin for their feedback during its writing.
Updates from Dries straight to your mailbox