Dries meets the King and Queen of Belgium

A few weeks ago at Davos, I had the honor of meeting the King and Queen of Belgium. VTM, the main commercial television station in Belgium, captured the moment for the evening news. Proof in the video below!

Fast tracking life-saving innovations

Last week, a member of my family died in a car accident. Jasper was on his way home and was hit by a taxi. He fought for his life, but died the next day. Jasper was only 16 years old. I was at Davos and at one point I had to step out of the conference to cry. Five years ago, another family member died after she was hit by a truck when crossing the road.

It's hard to see a tragedy like this juxtaposed against a conference filled with people talking about improving the state of the world. These personal losses make me want to fast-forward to a time in the future where self-driving cars are normal, and life-saving innovations don't have as much regulatory red tape to cut through before they can have an impact. It's frustrating that we may have the right technology in sight today, but aren't making it available, especially when people's lives are at stake.

Imagine two busses full of people crashing, killing everyone on board, every single day. That is how many people die on America's roads every day. In fact, more people are killed by cars than guns, but I don't see anyone calling for a ban on automobiles. Car accidents (and traffic jams) are almost always the result of human error. It is estimated that self-driving cars could reduce deaths on the road by 90%. That is almost 30,000 lives saved each year in the US alone. The life-saving estimates for driverless cars are on par with the efficacy of modern vaccines. I hope my children, now ages 6 and 8, will never need a driver's license and can grow up in a world with driverless cars.

The self-driving car isn't as far off as you might think but is still being held back by government regulators. Delayed technology isn't limited to self-driving cars. Life-saving innovations in healthcare are often held back by regulatory requirements. The challenge of climate change could be addressed faster if the regulatory uncertainty around solar and wind power permits and policies were reduced. The self-serving interest of lobbying groups focused on maintaining the status quo for industries like Big Oil make it harder for alternative energies to gain momentum.

Regulators need to frame their jobs differently; they need to ask how they can facilitate and enable emerging disruptive innovations, rather than maintain existing systems. Their job should focus more on removing any barriers that prevent disruptions from having a faster impact. If they do this job well, some established institutions will fail. In some cases, economic sacrifices by the incumbents should be of lesser concern than advancing social health and safety for the benefit of society. I'm less concerned about technology destroying jobs, and more concerned about our children not being able to benefit from available technical advances that improve their lives. We should realize that opportunities for long-term economic growth come with short-term disruption or temporary pain.

Losing family members in fatal accidents makes one think about what could have been done. I'm often asked how one can create a "Silicon Valley" model elsewhere in the world. I may have an answer. If you want to out-"Silicon Valley" Silicon Valley, create a region with a regulatory environment that supports prompt, responsible innovation to drive the adoption and iteration of new technologies. A region where people can responsibly launch self-driving cars, fast-track healthcare and address climate change. A region where long-term advantages are valued more than short-term disadvantages. Such a region would attract capital and entrepreneurs, and would be much better for our children.

Drupal: 15 years old and still gaining momentum

On December 29, 2000, I made a code commit that would change my life; it is in this commit that I called my project "Drupal" and added the GPL license to it.

Drupal name and license

The commit where I dubbed my website project "Drupal" and added the GPL license.

A couple weeks later, on January 15, 2001, exactly 15 years ago from today, I released Drupal 1.0.0 into the world. The early decisions to open-source Drupal and use the GPL license set the cornerstone principles for how our community shares with one another and builds upon each other's achievements to this day.

Drupal is now 15 years old. In internet terms, that is an eternity. In 2001, only 7 percent of the world's population had internet access. The mobile internet had not entered the picture, less than 50% of the people in the United States had a mobile phone, and AT&T had just introduced text messaging. People searched the web with Lycos, Infoseek, AltaVista and Hot Bot. Google -- launched in 1998 as a Stanford University research project -- was still a small, private company just beginning its rise to prominence. Google AdWords, now a $65 billion business, had less than 500 customers when Drupal launched. Chrome, Firefox, and Safari didn't exist yet; most people used Netscape, Opera or Internet Explorer. New ideas for sharing and exchanging content such as "public diaries" and RSS had yet to gain widespread acceptance and Drupal was among the first to support those. Wikipedia was launched on the same day as Drupal and sparked the rise of user-generated content. Facebook and Twitter didn't exist until 4-5 years later. Proprietary software vendors started to feel threatened by open source; most didn't understand how a world-class operating system could coalesce out of part-time hacking by several thousand developers around the world.

Looking back, Drupal has not only survived massive changes in our industry; it has also helped drive them. Over the past decade and a half, I've seen many content management systems emerge and become obsolete: Vignette, Interwoven, PHP-Nuke, and Scoop were all popular at some point in the past but Drupal has outlived them all. A big reason is from the very beginning we have been about constant evolution and reinvention, painful as it is.

Keeping up with the pace of the web is a funny thing. Sometimes you'll look back on choices made years ago and think, "Well, I'm glad that was the right decision!". For example, Drupal introduced "hooks" and "modules" early on, concepts that are commonplace in today's platforms. At some point, you could even find some of my code in WordPress, which Matt Mullenweg started in 2003 with some inspiration from Drupal. Another fortuitous early decision was to focus Drupal on the concept of "nodes" rather than "pages". It wasn't until 10 years later with the rise of mobile that we started to see the web revolve less and less around pages. A node-based approach makes it possible to reuse content in different ways for different devices. In a way, much of the industry is still catching up to that vision. Even though the web is a living, breathing thing, there is a lot of things that we got right.

Other times, we got it wrong. For example, we added support for OpenID, which never took off. In the early days I focused, completely and utterly, on the aesthetics of Drupal's code. I spent days trying to do something better, with fewer lines of code and more elegant than elsewhere. But in the process, I didn't focus enough on end-user usability, shunned JavaScript for too long, and later tried to improve usability by adding a "dashboard" and "overlay".

In the end, I feel fortunate that our community is willing to experiment and break things to stay relevant. Most recently, with the release of Drupal 8, we've made many big changes that will fuel Drupal's continued adoption. I believe we got a lot of things right in Drupal 8 and that we are on the brink of another new and bright era for Drupal.

I've undergone a lot of personal reinvention over the past 15 years too. In the early days, I spent all my time writing code and building Drupal.org. I quickly learned that a successful open source project requires much more than writing code. As Drupal started to grow, I found myself an "accidental leader" and worried about our culture, scaling the project, attracting a strong team of contributors, focusing more and more on Drupal's end-users, growing the commercial ecosystem around Drupal, starting the Drupal Association, and providing vision. Today, I wear a lot of different hats: manager of people and projects, evangelist, fundraiser, sponsor, public speaker, and BDFL. At times, it is difficult and overwhelming, but I would not want it any other way. I want to continue to push Drupal to reach new heights and new goals.

Today we risk losing much of the privacy, serendipity and freedom of the web we know. As the web evolves from a luxury to a basic human right, it's important that we treat it that way. To increase our impact, we have to continue to make Drupal easier to use. I'd love to help build a world where people's privacy is safe and Drupal is more approachable. And as the pace of innovation continues to accelerate, we have to think even more about how to scale the project, remain agile and encourage experimentation. I think about these issues a lot, and am fortunate enough to work with some of the smartest people I know to build the best possible version of the web.

So, here is to another 15 years of evolution, reinvention, and continued growth. No one knows what the web will look like 15 years in the future, but we'll keep doing our best to guide Drupal responsibly.

Selecting a client-side framework for Drupal

Last month, my blog post about whether a client-side framework is right for Drupal stimulated some excellent insights into how the future of the Drupal front end might look. There was broad agreement that incorporating more JavaScript into Drupal's administrative interface is important for a future-ready user experience.

I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds. Of course, this does not mean I oppose fully decoupling through any other framework; in fact, I believe we should redouble our efforts toward a first-class API-first Drupal. But progressive decoupling means that we will be able to work toward a next-generation user experience without abandoning much of the work we've done so far.

With that in mind, I tasked a small team made up of various experts from the Drupal and various JavaScript communities with putting together a list of criteria and a comparison matrix to help us decide on the most appropriate client-side framework for progressive decoupling in Drupal.

JavaScript framework comparison matrix

After a hundred hours of work, we came up with a criteria document and comparison matrix (PDF version):

Special thanks to all of the following experts who provided review and input: Miško Hevery (creator of Angular; Google) and Igor Minar (technical lead for Angular; Google); Ed Faulkner (core maintainer for Ember); Amitai Burstein (Drupal and Elm contributor; Gizra); Sebastian Siemssen (Drupal contributor, Elm and React developer; Zensations); and John Albin Wilkins (Drupal 8 mobile initiative lead), Alex Bronstein (Drupal core maintainer; Acquia), Wim Leers (Drupal core contributor; Acquia), and Preston So (Drupal contributor, Acquia).

Though this is a good starting point that lays the groundwork for a formal adoption process in Drupal core, it is time to open our comparison for review by members of both the Drupal and JavaScript communities. We should also more rigorously evaluate these frameworks' appropriateness through actual development.

First, have we decided on the right criteria regardless of the frameworks themselves? This is probably the most important at this stage. While many organizations choose to adopt client-side frameworks for fully decoupled implementations, Drupal is the first to consider layering a framework on top to allow both richly dynamic and more traditional modules to coexist gracefully through progressive decoupling. What issues around templates, rendering, and client-side caching should we incorporate into these criteria? Is there anything missing or overemphasized?

Second, have we selected the right frameworks to focus on? Are there other frameworks, libraries, or even compile-to-JavaScript projects (such as Elm) that should be included in the matrix? In my view, it is best for Drupal to adopt a framework with an already large community and ecosystem that would allow us to more quickly bridge the gap and resolve any friction during adoption. To provide a good frame of reference, we've also included Backbone, Angular, and Knockout, all three slightly older among client-side frameworks. Others on our shortlist that we didn't consider due to low levels of adoption and small communities are Mithril, Riot, and Vue. Still other ambitious projects such as the Elm and ClojureScript languages are also candidates, but their adoption will mean more up-front work to support typical features of client-side frameworks, as well as buy-in into an approach where JavaScript is compiled from a different language.

Finally, have we drawn the right conclusions against these criteria? In other words, did we fill out the cells correctly? While they have been reviewed by some of the frameworks' experts, there might be unexpected gotchas or caveats.

I'm sharing the initial comparison matrix on my blog for maximum reach; I want both the Drupal community and the JavaScript framework communities, as well as the broader front-end community, to take note. After three installments on my blog ("The future of decoupled Drupal", "Should we decouple Drupal with a client-side framework?"), it's time to move the technical conversation to drupal.org. There is now an issue in the core issue queue on drupal.org to iterate on the matrix.

Preliminary conclusions

At the moment, the most promising candidates in the comparison matrix appear to be Angular 2, Ember, and React, given their technical robustness, relative suitability for progressively decoupled Drupal, and their strong levels of community support and broader adoption. Given that Backbone is already in core and several modules already rely on it, we have included it too.

What we've learned from talking to the different projects is that they are often converging on similar techniques and best practices; they are by and large adding support for Virtual DOM implementations or rehydration (seamless state transfer), and they are all obsessing over small payload size and performance, better testability, etc. Therefore it is important to focus on the fundamental, often philosophical, differences between the projects that will likely be unchanged in time; key architectural differences, their release cadence and stance on backward compatibility, their license, their governance model, their flexibility and learning curve, etc.

From a quick glance at the criteria and our needs, it seems that Ember is currently our best candidate, as it appears to have a slight technical edge overall. Ember 2.0 has an all-new rendering engine named Glimmer, and it has server-side rendering through FastBoot. On the other hand, however, Ember is quite bulky and opinionated (enforcing patterns for code structure) compared to other candidate frameworks. A more fundamental difference is that unlike Angular and React, which have corporate governance and funding, Ember is a community-driven project like Drupal.

While React is lightweight, it needs integration with a variety of other libraries in the React ecosystem to work as a full-fledged implementation, which gives it a steep learning curve from an implementation standpoint. Because React is a relatively young project, best practices are shifting quickly and making it less attractive. The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors.

Angular 2 is a complete rewrite of Angular 1 to address issues with that version of the framework, including performance problems stemming from a large file size. The new version also introduces a new template engine that incorporates both directives familiar to Angular 1 developers and nestable component-based templates. But Angular 2's Apache 2.0 licensing is incompatible with Drupal's own GPLv2 license. While Drupal's PHP code and JavaScript code run in isolated processes, it appears that an Apache 2.0-licensed project can't be jointly distributed within an umbrella project that uses a GPLv2 license.

In addition to being at a slight technical disadvantage to Ember, the legal concerns with React and Angular make me believe Ember might be our best bet. But I'm not a lawyer nor a JavaScript expert, so I can't make this decision alone; I'm looking for lots of feedback, particularly from JavaScript experts, to determine the best option for Drupal.

Conclusion

Whatever the result of the debate around which client-side framework to adopt, I believe that Drupal needs to move quickly to embrace a framework that will aid development of a progressively decoupled architecture and corresponding user experience improvements. By providing some baseline criteria and including our accomplished community, I have no doubt we can reach this decision quickly but also intelligently.

Special thanks to Preston So for contributions to this blog post.

Acquia retrospective 2015

As many of my loyal blog readers know, I sit down to write a retrospective at the end of each year. It's helpful from the perspective of seeing how far Acquia has come in a single year, but it should also give you a glimpse of what is in store for Acquia in 2016 and beyond. If you find it interesting to take a look back at previous retrospectives, here they are: 2014, 2013, 2012, 2011, 2010 and 2009. These posts provide a pretty detailed overview of Acquia's trajectory as a company.

Market trends

Since Acquia started eight years ago, we've believed that open source offers significant advantages over proprietary software because of its faster innovation, higher quality, freedom from vendor lock-in, greater security, and lower total cost of ownership. Early in our life as a company, we made a big bet that open source combined with the cloud, offered through a subscription model rather than perpetual license, would be a very compelling solution for the market. Few people believed us at the time, but now it is clear that our early vision is starting to pay off; perpetual software licenses are on the decline and Deutsche Bank analyst Karl Keirstead recently called cloud and open source the two leading themes in Silicon Valley.

The market demand for Acquia's digital business platform continues to grow; three of the top analyst firms, IDC, Gartner and Forrester have all named digital business transformation a top strategic imperative for the C-suite in 2016 and beyond. Open source, cloud computing, big data, the Internet of Things (IoT), and artificial intelligence are all catalysts for the expansion of digital transformation into all corners of the organization.

Organizations are rapidly expanding the range of digital interactions with their customers and partners, moving Drupal and Acquia to the core of their business. There is a growing focus on personalization and data-driven automation, which bodes well for products like Acquia Lift. In general, I believe that the growing reliance on digital provides Drupal and Acquia with a multi-decade opportunity.

Open source

Within the last 12 months, some of the largest technology companies including Apple, Google, Microsoft and Facebook have open-sourced key components of their business. There are many motivations for this shift. According to Apple, the company open-sourced its Swift programming language to extend it to new platforms. Google open-sourced TensorFlow, its artificial intelligence platform to make an even bigger impact outside Google, even though the company employs 2,000 engineers working on artificial intelligence alone. Microsoft open-sourced .NET to increase its relevance with developers and play nicely with other operating systems. In Deutsche Bank's 2016 predictions, Keirstead says "open source keeps eating the world", causing major price deflation for the traditional enterprise software industry. Whether the motive is faster innovation or increased adoption, companies are relying less and less on proprietary software and embracing open source.

Cloud adoption

Amazon SVP of Web Services, Andy Jassy, explained in his 2015 AWS re:Invent presentation that websites have been a "critical gateway" to AWS' wider cloud adoption in the enterprise. His rationale: nearly every organization has one or more websites, and many aren't considered "mission-critical applications". Therefore, most organizations feel comfortable moving some or all of their websites to the cloud. Websites are an important stepping stone for organizations to build up the knowledge and confidence to migrate their entire businesses to the cloud.

As cloud adoption grows, we're seeing our customers use a mixture of SaaS, PaaS and IaaS. In particular the Platform-as-a-Service (PaaS) model continues to grow fast, which is great news for Acquia Cloud. A growing number of enterprises are choosing PaaS ahead of Infrastructure-as-a-Service (IaaS) to save time and money on building, scaling and maintaining infrastructure so they can focus on building websites. Gartner sizes the PaaS market at $4.1B in 2015, attaining a compound annual growth rate (CAGR) of 65%+ through 2018. We are a few years ahead of our competitors (Adobe, Sitecore, IBM, Oracle) when it comes to PaaS, and I don't see that changing in 2016.

The migration to the cloud is only getting started. When I met with Eric Schmidt this year, he told me that he believes Google's cloud business could outpace its advertising business in five years. To put that in context, Google made more than $65 billion in advertising in 2015, roughly 90% of its total revenue. I don't think Google Cloud can possibly grow that fast, but directionally it's an eye-opening goal. Amazon's cloud business, bigger than its four closest competitors combined (including Google's cloud business), generated roughly $7 billion in revenues in 2015 and is expected to grow 80% year-over-year. Needless to say, it is exciting for Acquia be a "critical gateway" in such a massive movement to the cloud.

Andy jassy reinvent

A photo of Andy Jassy's keynote at AWS re:Invent 2015.

Digital experiences

As the web evolves, the idea of a "digital business" takes on an entirely new meaning. I've said this before but digital is not just about building websites anymore; many of our customers are using digital to change the way their business operates, automate manual processes, and save millions of dollars in the process. Digital strategies are no longer confined to the marketing department; they're quickly becoming a boardroom priority.

Digital experiences are also getting more sophisticated. What used to be as simple as building a website now involves getting the right information, to the right user, at the right time, in the right context -- an idea I call B2One and talked about as part of my Big Reverse of the Web thesis. It's all about understanding the user's context and preferences to deliver the best next experience. We started investing in this area in late 2013, acquired a personalization company in 2014, and expect this trend to grow really big, especially as big data, the Internet of Things (IoT) and artificial intelligence mature.

Beyond personalization and contextualization, companies have a greater need for flexibility and freedom to integrate a variety of external services, ranging from commerce to marketing automation solutions. While there are plenty of point solutions on the market that achieve pieces of this puzzle, Acquia and Drupal uniquely provide a platform to do it all.

Acquia continues its growth

Acquia's growth is an indicator that businesses are already betting big on open source, cloud, personalization, and digital transformation. Looking at our numbers for 2015, it is hard to believe that last year was only our seventh full year as a revenue-generating business. Our new logo subscriptions -- the business that we get from companies new to Acquia -- continued its fast growth, while our renewal rates are among the best around.

To support our growth, we added $55 million in new venture capital funding in 2015, bringing Acquia's total raised to $188.6 million.

We dramatically increased headcount last year. In May, we moved into a beautiful new corporate headquarters in Boston, where we hosted a launch party with mayor Martin J. Walsh that established us as an anchor growth company for the city. Globally, we added 150 more employees in 2015, bringing us to 720 people. The executive team changed substantially in 2015, with the addition of Al Nugent as CISO, Preston Bradford as COO, Heather Hartford as Chief People Officer, and most recently Loren Jarrett as CMO. We also announced the appointment of Christine Komola, CFO of Staples, to Acquia's board of directors. We expanded European operations with the opening of a new office in Munich. Acquia now operates out of 10 global offices on three continents!

Acquia state street

A photo of Acquia's headquarters in downtown Boston.

We made key investments in talent for our partner team, grew the number of Drupal certifications achieved globally, and strengthened our relationship with agency partners. We were proud to announce our WPP Global Alliance partnership this year, which brings Acquia closer to the organizations building the world's most amazing digital experiences.

Top industry analysts continued to recognize Acquia as a leading provider of digital experience software and services. In October 2015, we were named a "Strong Performer" in The Forrester Wave: Digital Experience Platforms Q4 2015. In August, Gartner named us a "Leader" in the 2015 Magic Quadrant for Web Content Management. This type of external validation supports Acquia as a viable alternative to proprietary solutions provided by companies like Adobe, IBM, Sitecore or Oracle.

Acquia Cloud continues to enable organizations to run their websites securely and reliably, while providing them with the tools to accelerate web development and shorten time to market. We manage over 13,000 AWS instances (virtual servers) powering approximately 197,000 websites. In December 2015, Acquia Cloud served 10.8 billion Apache hits and 6.2 billion Drupal bootstraps (requests handled by Drupal instead of one of different caching layers or the web server directly), with billions more served from our caching layers and Acquia Cloud Edge.

Last year, we launched Acquia Cloud support for the São Paulo, Brazil and Frankfurt, Germany regions. With our German expansion we became the first Drupal PaaS to offer pan-European high availability to accommodate EU data sovereignty requirements.

Drupal 8

With the launch of Drupal 8 in late 2015, the Drupal community achieved our most significant release in the history of the platform. We implemented a more modern development framework, reimagined the usability and authoring experience, and made improvements that will help everyone build the multilingual, mobile and highly personalized digital experiences of the future. From how we model content and get content in and out the system, to how we assemble experiences on various devices, to how we scale that to millions of pageviews — it all got much better with Drupal 8.

Now that Drupal 8 is released, I'm convinced that it will attract new developers and site-builders to the platform. Nonetheless, the wait for Drupal 8 has been long and painful, temporarily slowing down much of the commercial Drupal ecosystem. Despite some turbulence, I'm proud that the Acquia team was a force in helping to push Drupal 8 over the finish line.

Acquia employs more than 150 Drupal experts, and has fixed upwards of 1,200 issues in Drupal 8. I reassigned our Drupal team from feature development (i.e. Spark) to working on criticals. This team was a major force in bringing the total number of criticals down from a high of 90 at the beginning of the year to zero in early October, through development, performance work, patch reviews, sprint coordination, and in helping to manage the Drupal 8 Accelerate program. To help jumpstart faster Drupal 8 adoption, Acquia is investing significantly in porting the top 50+ contributed modules. We have always believed in giving back more as a core part of our company's DNA. Our entire team is ready to enable and support companies working with Drupal 8.

Acquia products

Last year was an exciting one when it came to new products. We announced Content Hub, a cloud-based content distribution and discovery service. As more of our customers scale with Acquia across hundreds of sites, Content Hub lets authors and site owners reuse content from internal and external sites. And we added a critical commerce integration through a partnership with Hybris, which provides even more options for enterprises to drive commerce experiences.

We announced a variety of important security and compliance milestones that will be crucial to protecting our customers. First, we introduced Acquia Cloud Edge, a new DDoS security product developed in partnership with CloudFlare to keep our customers safer from external threats. Soon after, Acquia achieved HIPAA compliance upon passing an independent audit of Acquia Cloud Site Factory and Acquia Cloud. HIPAA compliance is significant because of Acquia's roster of healthcare customers, who require certain safeguards for data security and look to scale Acquia Cloud across their portfolio of sites.

In addition to this compliance milestone, our spam-blocking software, Mollom, has blocked over 10 billion spam comments.

Acquia Lift customers challenged some of our original assumptions about personalization. We worked to improve our Acquia Lift personalization product with the help of our customers, creating a new workflow and UX that supported more flexibility and freedom depending on the individual organization. In 2015, we learned a lot about the challenges organizations face when starting out with personalization and doubled down to help our customers become successful. Personalization will continue to be a huge focus of ours in 2016.

Looking ahead

This year, we will be rolling out many new products and enhancing existing ones. Acquia Cloud will get a brand-new, responsive, card-based UX in early 2016, and we'll give development teams the ability to create on-demand environments. We will continue to focus on security enhancements from audits like SOC and ISO, as well as key control planes including FedRAMP, Single Sign-On, and much more. Our team was challenged to get the first cloud service running on our new grid architecture by the end of 2015. With a few hours to spare on the 31st, the "Uptime" service is now running on our grid architecture, a major milestone. A continued focus on developer tools, more microservices, personalization and a "jumpstart" Drupal 8 distribution are just some of the technology we will be rolling out in 2016. Overall, you'll see us getting faster, more secure and more efficient, and providing even more options for our customers to create highly personalized digital experiences.

Longer term, I'm very excited about Acquia's opportunity. I believe we've steered the company to be positioned at the right place at the right time. Time will tell, but 2016 promises to be another big year for Acquia.

Pages

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