Adobe acquires Magento for $1.68 billion

Yesterday, Adobe announced that it agreed to buy Magento for $1.68 billion. When I woke up this morning, 14 different people had texted me asking for my thoughts on the acquisition.

Adobe acquiring Magento isn't a surprise. One of our industry's worst-kept secrets is that Adobe first tried to buy Hybris, but lost the deal to SAP; subsequently Adobe tried to buy DemandWare and lost out against Salesforce. It's evident that Adobe has been hungry to acquire a commerce platform for quite some time.

The product motivation behind the acquisition

Large platform companies like Salesforce, Oracle, SAP and Adobe are trying to own the digital customer experience market from top to bottom, which includes providing support for marketing, commerce, personalization, and data management, in addition to content and experience management and more.

Compared to the other platform companies, Adobe was missing commerce. With Magento under its belt, Adobe can better compete against Salesforce, Oracle and SAP.

While Salesforce, SAP and Oracle offer good commerce capability, they lack satisfactory content and experience management capabilities. I expect that Adobe closing the commerce gap will compel Salesforce, SAP and Oracle to act more aggressively on their own content and experience management gap.

While Magento has historically thrived in the SMB and mid-market, the company recently started to make inroads into the enterprise. Adobe will bring a lot of operational maturity; how to sell into the enterprise, how to provide enterprise grade support, etc. Magento stands to benefit from this expertise.

The potential financial outcome behind the acquisition

According to Adobe press statements, Magento has achieved "approximately $150 million in annual revenue". We also know that in early 2017, Magento raised $250 million in funding from Hillhouse Capital. Let's assume that $180 million of that is still in the bank. If we do a simple back-of-the-envelope calculation, we can subtract this $180 million from the $1.68 billion, and determine that Magento was valued at roughly $1.5 billion, or a 10x revenue multiple on Magento's trailing twelve months of revenue. That is an incredible multiple for Magento, which is primarily a licensing business today.

Compare that with Shopify, which is trading at a $15 billion dollar valuation and has $760 million of twelve month trailing revenue. This valuation is good for a 20x multiple. Shopify deserves the higher multiple, because it's the better business; all of its business is delivered in the cloud and at 65% year-over-year revenue growth, it is growing much faster than Magento.

Regardless, one could argue that Adobe got a great deal, especially if it can accelerate Magento's transformation from a licensing business into a cloud business.

Most organizations prefer best-of-breed

While both the product and financial motivations behind this acquisition are seemingly compelling, I'm not convinced organizations want an integrated approach.

Instead of being confined to proprietary vendors' prescriptive suites and roadmaps, global brands are looking for an open platform that allows organizations to easily integrate with their preferred technology. Organizations want to build content-rich shopping journeys that integrate their experience management solution of choice with their commerce platform of choice.

We see this first hand at Acquia. These integrations can span various commerce platforms, including IBM WebSphere Commerce, Salesforce Commerce Cloud/Demandware, Oracle/ATG, SAP/hybris, Magento and even custom transaction platforms. Check out Quicken (Magento), Weber (Demandware), Motorola (Broadleaf Commerce), Tesla (custom to order a car, and Shopify to order accessories) as great examples of Drupal and Acquia working with various commerce platforms. And of course, we've quite a few projects with Drupal's native commerce solution, Drupal Commerce.

Owning Magento gives Adobe a disadvantage, because commerce vendors will be less likely to integrate with Adobe Experience Manager moving forward.

It's all about innovation through integration

Today, there is an incredible amount of innovation taking place in the marketing technology landscape (full-size image), and it is impossible for a single vendor to have the most competitive product suite across all of these categories. The only way to keep up with this unfettered innovation is through integrations.

Marketing technology landscape 2018
An image of the Marketing Technology Landscape 2018. For reference, here are the 2011, 2012, 2014, 2015, 2016 and 2017 versions of the landscape. It shows how fast the marketing technology industry is growing.

Most customers want an open platform that allows for open innovation and unlimited integrations. It's why Drupal and Acquia are winning, why the work on Drupal's web services is so important, and why Acquia remains committed to a best-of-breed strategy for commerce. It's also why Acquia has strong conviction around Acquia Journey as a marketing integration platform. It's all about innovation through integration, making those integrations easy, and removing friction from adopting preferred technologies.

If you acquire a commerce platform, acquire a headless one

If I were Adobe, I would have looked to acquire a headless commerce platform such as Elastic Path, Commerce Tools, Moltin, Reaction Commerce or even Salsify.

Today, there is a lot of functional overlap between Magento and Adobe Experience Manager — from content editing, content workflows, page building, user management, search engine optimization, theming, and much more. The competing functionality between the two solutions makes for a poor developer experience and for a poor merchant experience.

In a headless approach, the front end and the back end are decoupled, which means the experience or presentation layer is separated from the commerce business layer. There is a lot less overlap of functionality in this approach, and it provides a better experience for merchants and developers.

Alternatively, you could go for a deeply integrated approach like Drupal Commerce. It has zero overlap between its commerce, content management and experience building capabilities.

For Open Source, it could be good or bad

How Adobe will embrace Magento's Open Source community is possibly the most intriguing part of this acquisition — at least for me.

For a long time, Magento operated as Open Source in name, but wasn't very Open Source in practice. Over the last couple of years, the Magento team worked hard to rekindle its Open Source community. I know this because I attended and keynoted one of its conferences on this topic. I have also spent a fair amount of time with Magento's leadership team discussing this. Like other projects, Magento has been taking inspiration from Drupal.

For example, the introduction of Magento 2 allowed the company to move to GitHub for the first time, which gave the community a better way to collaborate on code and other important issues. The latest release of Magento cited 194 contributions from the community. While that is great progress, it is small compared to Drupal.

My hope is that these Open Source efforts continue now that Magento is part of Adobe. If they do, that would be a tremendous win for Open Source.

On the other hand, if Adobe makes Magento cloud-only, radically changes their pricing model, limits integrations with Adobe competitors, or doesn't value the Open Source ethos, it could easily alienate the Magento community. In that case, Adobe bought Magento for its install base and the Magento brand, and not because it believes in the Open Source model.

This acquisition also signals a big win for PHP. Adobe now owns a $1.68 billion PHP product, and this helps validate PHP as an enterprise-grade technology.

Unfortunately, Adobe has a history of being "Open Source"-second and not "Open Source"-first. It acquired Day Software in July 2010. This technology was largely made using open source frameworks — Apache Sling, Apache Jackrabbit and more — and was positioned as an open, best-of-breed solution for developers and agile marketers. Most of that has been masked and buried over the years and Adobe's track record with developers has been mixed, at best.

Will the same happen to Magento? Time will tell.

As web applications have evolved from static pages to application-like experiences, end-users' expectations of websites have become increasingly demanding. JavaScript, partnered with effective user-experience design, enable the seamless, instantaneous interactions that users now expect.

The Drupal project anticipated this trend years ago and we have been investing heavily in making Drupal API-first ever since. As a result, more organizations are building decoupled applications served by Drupal. This approach allows organizations to use modern JavaScript frameworks, while still benefiting from Drupal's powerful content management capabilities, such as content modeling, content editing, content workflows, access rights and more.

While organizations use JavaScript frameworks to create visitor-facing experiences with Drupal as a backend, Drupal's own administration interface has not yet embraced a modern JavaScript framework. There is high demand for Drupal to provide a cutting-edge experience for its own users: the site's content creators and administrators.

At DrupalCon Vienna, we decided to start working on an alternative Drupal administrative UI using React. Sally Young, one of the initiative coordinators, recently posted a fantastic update on our progress since DrupalCon Vienna.

Next steps for Drupal's API-first and JavaScript work

While we made great progress improving Drupal's web services support and improving our JavaScript support, I wanted to use this blog post to compile an overview of some of our most important next steps:

1. Stabilize the JSON API module

JSON API is a widely-used specification for building web service APIs in JSON. We are working towards adding JSON API to Drupal core as it makes it easier for JavaScript developers to access the content and configuration managed in Drupal. There is a central plan issue that lists all of the blockers for getting JSON API into core (comprehensive test coverage, specification compliance, and more). We're working hard to get all of them out of the way!

2. Improve our JavaScript testing infrastructure

Drupal's testing infrastructure is excellent for testing PHP code, but until now, it was not optimized for testing JavaScript code. As we expect the amount of JavaScript code in Drupal's administrative interface to dramatically increase in the years to come, we have been working on improving our JavaScript testing infrastructure using Headless Chrome and Nightwatch.js. Nightwatch.js has already been committed for inclusion in Drupal 8.6, however some additional work remains to create a robust JavaScript-to-Drupal bridge. Completing this work is essential to ensure we do not introduce regressions, as we proceed with the other items in our roadmap.

3. Create designs for a React-based administration UI

Having a JavaScript-based UI also allows us to rethink how we can improve Drupal's administration experience. For example, Drupal's current content modeling UI requires a lot of clicking, saving and reloading. By using React, we can reimagine our user experience to be more application-like, intuitive and faster to use. We still need a lot of help to design and test different parts of the Drupal administration UI.

4. Allow contributed modules to use React or Twig

We want to enable modules to provide either a React-powered administration UI or a traditional Twig-based administration UI. We are working on an architecture that can support both at the same time. This will allow us to introduce JavaScript-based UIs incrementally instead of enforcing a massive paradigm shift all at once. It will also provide some level of optionality for modules that want to opt-out from supporting the new administration UI.

5. Implement missing web service APIs

While we have been working for years to add web service APIs to many parts of Drupal, not all of Drupal has web services support yet. For our React-based administration UI prototype we decided to implement a new permission screen (i.e. https://example.com/admin/people/permissions). We learned that Drupal lacked the necessary web service APIs to retrieve a list of all available permissions in the system. This led us to create a support module that provides such an API. This support module is a temporary solution that helped us make progress on our prototype; the goal is to integrate these APIs into core itself. If you want to contribute to Drupal, creating web service APIs for various Drupal subsystems might be a great way to get involved.

6. Make the React UI extensible and configurable

One of the benefits of Drupal's current administration UI is that it can be configured (e.g. you can modify the content listing because it has been built using the Views module) and extended by contributed modules (e.g. the Address module adds a UI that is optimized for editing address information). We want to make sure that in the new React UI we keep enough flexibility for site builders to customize the administrative UI.

All decoupled builds benefit

All decoupled applications will benefit from the six steps above; they're important for building a fully-decoupled administration UI, and for building visitor-facing decoupled applications.

Useful for decoupling of visitor-facing front-ends Useful for decoupling of the administration backend
1. Stabilize the JSON API module
2. Improve our JavaScript testing infrastructure
3. Create designs for a React-based administration UI
4. Allow contributed modules to use React or Twig
5. Implement missing web service APIs
6. Make the React UI extensible and configurable

Conclusion

Over the past three years we've been making steady progress to move Drupal to a more API-first and JavaScript centric world. It's important work given a variety of market trends in our industry. While we have made excellent progress, there are more challenges to be solved. We hope you like our next steps, and we welcome you to get involved with them. Thank you to everyone who has contributed so far!

Special thanks to Matt Grill and Lauri Eskola for co-authoring this blog post and to Wim Leers, Gabe Sullice, Angela Byron, and Preston So for their feedback during the writing process.

How the Open Demographics Initiative recommends you ask for gender information
© Open Demographics Initiative's gender identification questions

Last week, Nikki Stevens presented "Other, Please Specify" for TEDx at Arizona State University. In her TED Talk, Nikki shares the story behind the Open Demographics Initiative, which is developing a recommended set of questions that anyone can use to ask online community members about their demographics.

Nikki demonstrates how a majority of demographic surveys require users to conform to restrictive identity fields, which can alienate minority or underrepresented groups. The Open Demographics Initiative wants to develop forms that are more inclusive, in addition to giving people more control over the data and information they chose to disclose.

Inspired by Nikki's presentation, I reached out to the engineering team at the Drupal Association to see if there are plans to implement the Open Demographics Initiative's recommendations on Drupal.org. I was happy to learn that they are collaborating with the Open Demographics team to add the recommendations to the user registration process on Drupal.org.

Adopting Open Demographics on Drupal.org will also allow us to improve reporting on diversity and inclusion, which in turn will help us better support initiatives that advance diversity and inclusion. Plus, we can lead by example and inspire other organizations to do the same.

Thank you Nikki, for sharing the story behind the Open Demographics Initiative, and for helping to inspire change in the Drupal community and beyond.

Join more than 5,000 others and subscribe to my blog by e-mail:

Last night, I read a thoughtful blog post from Sebastian Greger, which examines the challenges of implementing privacy in a decentralized, social web. As a part of my own POSSE plan, I had proposed implementing support for Webmention on dri.es. This would allow me to track comments, likes, reposts, and other rich interactions across the web on my own site.

Sebastian correctly explains that when you pull in content from social media websites into your own site with the intention of owning the conversation, you are effectively taking ownership of other people's content. This could be in conflict with the GDPR regulation, for example, which sets tight rules on how personal data is processed, and requires us to think more about how personal data is syndicated on the web.

Data protection is important, but so is a decentralized, social web. These conversations, and the innovation that hopefully results from it, are important. If we fail to make the Open Web compliant with data regulations, we could empower walled gardens and stifle innovation towards a more decentralized web.

You might have noticed that Wikipedia recently started enabling link previews; when you hover over a link, it displays a card with more information about the linked page.

Wikipedia link previews

My first reaction was: what took them so long? Link previews help to solve an important usability problem of having to open many articles, often in multiple browser tabs. However, after I started to read more about how Wikipedia implemented the link previews, I was reminded of how hard it is to do things at the scale Wikipedia requires.

Nirzar Pangarka, who works as a designer at the Wikimedia Foundation, shared that more than 10,000 links get hovered each second across Wikipedia. In another post, David Lyall, an engineering manager at the Wikimedia Foundation, shared that they are seeing up to half a million hits every minute on the API that serves the link preview cards.

I have a great appreciation for Wikipedia's seemingly straightforward link previews. Delivering a feature at this scale is an impressive achievement.

Last month, Acquia discontinued service and support for Mollom, the spam service I started more than ten years ago. As a goodbye, I want to share the untold story of how I founded Mollom.

In 2007, I read Tim Ferriss' book The 4-Hour Work Week, and was hooked. The book provides a blueprint for how entrepreneurs can structure and build a business to fund the lifestyle of their dreams. It's based on Ferriss' own experience; he streamlined his business, automated systems and outsourced tasks until it was not only more profitable, but also took less of his time to operate. The process of automation and outsourcing was so efficient, Ferriss only spent four hours a week to run his business; this gave him time and freedom to take "mini-retirements", travel the world, and write a book. When I first read Ferriss' book, I was inspired by the idea of simultaneously having that much free time and being financially stable.

While I was reading Ferriss' book, I was also working on a website spam filter for my blog, called Mollom. I had started to build Mollom as a personal project for exclusive use on my own blog. Inspired by the 4-Hour Work Week, I was convinced I could turn Mollom into a small SaaS service with global customers, complete self-service, and full automation. This would allow me to operate Mollom from anywhere in the world, and would require just a few hours of my time each week. Because I was starting to use machine learning, I enlisted the help of one of my best friends, Benjamin Schrauwen, a professor in machine learning at the University of Ghent.

In the same year, Jay Batson and I met at DrupalCon Sunnyvale, and we had already started to explore the idea of founding Acquia. My oldest son Axl was also born in the summer of 2007, and I was working hard to finish my PhD. Throughout all of this, we were also working to get Drupal 6 released. Needless to say, it was a busy summer.

With my PhD nearly complete, I needed to decide what to do next. I knew that starting Acquia was going to have a big impact, not just on Drupal but also on my life. However, I was also convinced that Mollom, while much smaller in scope and ambition, could provide a path to the freedom and independence Ferriss describes.

Mollom's foundational years

Exciting 2007, I determined that both Acquia and Mollom were important opportunities to pursue. Jay and I raised $7 million in venture capital, and we publicly launched Acquia in November 2007. Meanwhile, Ben and I pooled together €18,000 of our own money, bootstrapped Mollom, and publicly launched Mollom in March 2008.

I always made a point to run both businesses separately. Even after I moved from Belgium to the US in the summer of 2010, I continued to run Mollom and Acquia independently. The Mollom team was based in Europe, and once or twice a week, I would get up at 4 AM to have a two-hour conference call with the team. After my conference call, I'd help my family get ready for the day, and then I was off to work at Acquia.

By 2011, Mollom had achieved the goals our team set out to accomplish; our revenues had grown to about €250,000 in recurring annual revenue, our gross margins were over 85 percent, and we could pretty much run the business on autopilot. Our platform was completely self-serviced for our users, the anti-spam algorithms self-learning, the service was built to be highly-available, and the backend operations were almost entirely automated. Not bad for a side hustle. I often joked about how I could run Mollom from the beach in Greece, with less than an hour of work a day.

However, our team at Mollom wasn't satisfied yet, so instead of sitting on the beach, we decided to invest Mollom's profits in feature development. We had a team of three engineers working on adding new capabilities, in addition to re-architecting and scaling Mollom to keep up with its growth. On average, Mollom handled more than 100 web service requests per second, and we regularly saw peaks of up to 3,000 web service request per second. In a way, Mollom's architecture was ahead of its time — it used a micro-services architecture with a REST API, a decoupled administration backend and relied heavily on machine learning. From day one, our terms of service respected people's privacy, and we never had a data breach.

Team december
A photo of the Mollom team at an offsite in 2011: it includes Daniel Kudwien, Benjamin Schrauwen, Cedric De Vleeschauwer, Thomas Meire, Johan Vos and Vicky Van Roeyen. Missing in the picture is Dries.

In the meantime, Acquia had really taken off; Acquia's revenue had grown to over $22 million annually, and I was often working 60 hour work weeks to grow the company. Acquia's Board of Directors wanted my full attention, and had even offered to acquire Mollom a few times. I recognized that running Mollom, Acquia and Drupal simultaneously was not sustainable — you can only endure regular 4 AM meetings for so long. Plus, we had ambitious goals for Mollom; we wanted to add many-site content moderation, sentiment analysis and detection for certain code of conduct violations. Doing these things would require more capital, and unless you are Elon Musk, it's really hard to raise capital for multiple companies at the same time. Most importantly, I wanted to focus more on growing Drupal and driving Acquia's expansion.

Acquia acquires Mollom

By the end of 2012, Ben and I agreed to sell Mollom to Acquia. Acquia's business model was to provide SaaS services around Drupal, and Mollom was exactly that — a SaaS service used by tens of thousands of Drupal sites.

Selling Mollom was a life-changing moment for me. It proved that I was able to bootstrap and grow a company, steer it to profitability and exit successfully.

Mollom closing
Selling Mollom to Acquia involved signing a lot of documents. A photo of me signing the acquisition paperwork with Mary Jefts, Acquia's CFO at the time. It took three hours to sign all the paperwork.

Acquia retires Mollom

By 2017, five years after the acquisition, it became clear that Mollom was no longer a strategic priority for Acquia. As a result, Acquia decided it was best to shut down Mollom by April 2018. As the leader of the product organization at Acquia, I'm supportive of this decision. It allows us to sharpen our focus and to better deliver on our mission.

While it was a rational decision, it's bittersweet. I still believe that Mollom could have continued to have a big impact on the Open Web. Not only did that make the web better, it saved people millions of hours moderating their content. I also considered keeping Mollom running as part of Acquia's "Give back more" principle. However, Acquia gives back a lot, and I believe that giving back to Drupal should be our priority.

Mollom end of life announcement
Mollom's end-of-life announcement that replaced the old https://mollom.com.

Overall, Mollom was a success. While I never got my 4-hour work week, I enjoyed successfully creating a company from scratch, and seeing it evolve through every stage of its life. I learned how to build and run a SaaS service, I made some money in the process, and best of all, Mollom blocked over 15 billion spam comments across tens of thousands of websites. This translates to saving people around the world millions of hours, which would otherwise be devoted to content moderation. Mollom also helped to protect the websites of some of the world's most famous brands; from Harvard, to The Economist, Tesla, Twitter, Sony Music and more. Finally, we were able to offer Mollom for free to the vast majority of our users, which is something we took a lot of pride in.

If you were a user of Mollom the past 10+ years, I hope you enjoyed our service. I also want to extend a special thank you to everyone who contributed to Mollom over the past 11 years!

Rest in peace, Mollom! Thank you for blocking so much spam. I'll think about you next time I visit Greece.

Jacob Rockowitz recently posted a blog post with ideas about how we can make Drupal more welcoming.

What I found most interesting about Jacob's blog post is that he makes the point that every WordPress site (not WordPress.org) has an 'About WordPress' section in the administration backend that shows both WordPress' values and contributor credits.

Wordpress about section

This could be an interesting approach for Drupal and is an idea worth exploring. Today, Drupal's values and principles and Drupal's contribution credits live on Drupal.org, but not in the Drupal software itself. When done well, it's probably one of the most impactful ways to educate people and organizations that are new to Drupal about our community and open source. And by having credits in the software, we'd inspire more people and organizations to contribute back. It's an interesting idea.

On March 28th, the Drupal Security Team released a bug fix for a critical security vulnerability, named SA-CORE-2018-002. Over the past week, various exploits have been identified, as attackers have attempted to compromise unpatched Drupal sites. Hackers continue to try to exploit this vulnerability, and Acquia's own security team has observed more than 100,000 attacks a day.

The SA-CORE-2018-002 security vulnerability is highly critical; it allows an unauthenticated attacker to perform remote code execution on most Drupal installations. When the Drupal Security Team made the security patch available, there were no publicly known exploits or attacks against SA-CORE-2018-002.

That changed six days ago, after Checkpoint Research provided a detailed explanation of the SA-CORE-2018-002 security bug, in addition to step-by-step instructions that explain how to exploit the vulnerability. A few hours after Checkpoint Research's blog post, Vitalii Rudnykh, a Russian security researcher, shared a proof-of-concept exploit on GitHub. Later that day, Acquia's own security team began to witness attempted attacks.

The article by Checkpoint Research and Rudnykh's proof-of-concept code have spawned numerous exploits, which are written in different programming languages such as Ruby, Bash, Python and more. As a result, the number of attacks have grown significantly over the past few days.

Fortunately, Acquia deployed a platform level mitigation for all Acquia Cloud customers one hour after the Drupal Security Team made the SA-CORE-2018-002 release available on March 28th. Over the past week, Acquia has observed over 500,000 attacks from more than 3,000 different IP addresses across our fleet of servers and customer base. To the best of our knowledge, every attempted exploitation of an Acquia customer has failed.


SA-CORE-2018-002 timeline of events as seen by Acquia

The scale and the severity of this attack suggests that if you failed to upgrade your Drupal sites, or your site is not supported by Acquia Cloud or another trusted vendor that provides platform level fixes, the chances of your site being hacked are very high. If you haven't upgraded your site yet and you are not on a protected platform then assume your site is compromised. Rebuild your host, reinstall Drupal from a backup taken before the vulnerability was announced and upgrade before putting the site back online. (Update: restoring a Drupal site from backup may not be sufficient as some of the exploits reinstall themselves from crontab. You should assume the whole host is compromised.)

Drupal's responsible disclosure policy

It's important to keep in mind that all software has security bugs, and fortunately for Drupal, critical security bugs are rare. It's been nearly four years since the Drupal Security Team published a security release for Drupal core that is this critical.

What matters is how software projects or software vendors deal with security bugs. The Drupal Security Team follows a "coordinated disclosure policy": issues remain private until there is a published fix. A public announcement is made when the threat has been addressed and a secure version of Drupal core is also available. Even when a bug fix is made available, the Drupal Security Team is very thoughtful with its communication. The team is careful to withhold as many details about the vulnerability as possible to make it difficult for hackers to create an exploit, and to buy Drupal site owners as much time as possible to upgrade. In this case, Drupal site owners had two weeks before the first public exploits appeared.

Historically, many proprietary CMS vendors have executed a different approach, and don't always disclose security bugs. Instead, they often fix bugs silently. In this scenario, secrecy might sound like a good idea; it prevents sites from being hacked and it avoids bad PR. However, hiding vulnerabilities provides a false sense of security, which can make matters much worse. This approach also functions under the assumption that hackers can't find security problems on their own. They can, and when they do, even more sites are at risk of being compromised.

Drupal's approach to security is best-in-class — from fixing the bug, testing the solution, providing advance notice, coordinating the release, being thoughtful not to over communicate too many details, being available for press inquiries, and repeatedly reminding everyone to upgrade.

Acquia's platform level fix

In addition to the Drupal Security Team's responsible disclosure policy, Acquia's own security team has been closely monitoring attempted attacks on our infrastructure. Following the release of the Checkpoint Research article, Acquia has tracked the origin of the 500,000 attempted attacks:

SA-CORE-2018-002 map of attacks against Acquia Cloud customers
This image captures the geographic distribution of SA-CORE-2018-002 attacks against Acquia's customers. The number denoted in each bubble is the total number of attacks that came from that location.

To date, over 50 percent of the attempted attacks Acquia has witnessed originate from the Ukraine:

SA-CORE-2018-002 countries as seen by Acquia

At Acquia, we provide customers with automatic security patching of both infrastructure and Drupal code, in addition to platform level fixes for security bugs. Our commitment to keeping our customers safe is reflected in our push to release a platform level fix one hour after the Drupal Security Team made SA-CORE-2018-002 available. This mitigation covered all customers with Acquia Cloud Free, Acquia Cloud Professional, Acquia Cloud Enterprise, and Acquia Cloud Site Factory applications; giving our customers peace of mind while they upgraded their Drupal sites, with or without our help. This means that when attempted exploits and attacks first appeared in the wild, Acquia's customers were safe. As a best practice, Acquia always recommends that customers upgrade to the latest secure version of Drupal core, in addition to platform mitigations.

This blog post was co-authored by Dries Buytaert and Cash Williams.

Cowboy Dries at DrupalCon Nashville
© Yes Moon

Last week, I shared my State of Drupal presentation at Drupalcon Nashville. In addition to sharing my slides, I wanted to provide more information on how you can participate in the various initiatives presented in my keynote, such as growing Drupal adoption or evolving our community values and principles.

Drupal 8 update

During the first portion of my presentation, I provided an overview of Drupal 8 updates. Last month, the Drupal community celebrated an important milestone with the successful release of Drupal 8.5, which ships with improved features for content creators, site builders, and developers.

Drupal 8 continues to gain momentum, as the number of Drupal 8 sites has grown 51 percent year-over-year:

Drupal 8 site growth
This graph depicts the number of Drupal 8 sites built since April 2015. Last year there were 159,000 sites and this year there are 241,000 sites, representing a 51% increase year-over-year.

Drupal 8's module ecosystem is also maturing quickly, as 81 percent more Drupal 8 modules have become stable in the past year:

Drupal 8 module readiness
This graph depicts the number of modules now stable since January 2016. This time last year there were 1,028 stable projects and this year there are 1,860 stable projects, representing an 81% increase year-over-year.

As you can see from the Drupal 8 roadmap, improving the ease of use for content creators remains our top priority:

Drupal 8 roadmap
This roadmap depicts Drupal 8.5, 8.6, and 8.7+, along with a column for "wishlist" items that are not yet formally slotted. The contents of this roadmap can be found at https://www.drupal.org/core/roadmap.

Four ways to grow Drupal adoption

Drupal 8 was released at the end of 2015, which means our community has had over two years of real-world experience with Drupal 8. It was time to take a step back and assess additional growth initiatives based on what we have learned so far.

In an effort to better understand the biggest hurdles facing Drupal adoption, we interviewed over 150 individuals around the world that hold different roles within the community. We talked to Drupal front-end and back-end developers, contributors, trainers, agency owners, vendors that sell Drupal to customers, end users, and more. Based on their feedback, we established four goals to help accelerate Drupal adoption.

Lets grow Drupal together

Goal 1: Improve the technical evaluation process

Matthew Grasmick recently completed an exercise in which he assessed the technical evaluator experience of four different PHP frameworks, and discovered that Drupal required the most steps to install. Having a good technical evaluator experience is critical, as it has a direct impact on adoption rates.

To improve the Drupal evaluation process, we've proposed the following initiatives:

Initiative Issue link Stakeholders Initiative coordinator Status
Better discovery experience on Drupal.org Drupal.org roadmap Drupal Association hestenet Under active development
Better "getting started" documentation #2956879 Documentation Working Group grasmash In planning
More modern administration experience #2957457 Core contributors ckrina and yoroy Under active development

To become involved with one of these initiatives, click on its "Issue link" in the table above. This will take you to Drupal.org, where you can contribute by sharing your ideas or lending your expertise to move an initiative forward.

Goal 2: Improve the content creator experience

Throughout the interview process, it became clear that ease of use is a feature now expected of all technology. For Drupal, this means improving the content creator experience through a modern administration user interface, drag-and-drop media management and page building, and improved site preview functionality.

The good news is that all of these features are already under development through the Media, Workflow, Layout and JavaScript Modernization initiatives.

Most of these initiative teams meet weekly on Drupal Slack (see the meetings calendar), which gives community members an opportunity to meet team members, receive information on current goals and priorities, and volunteer to contribute code, testing, design, communications, and more.

Goal 3: Improve the site builder experience

Our research also showed that to improve the site builder experience, we should focus on improving the three following areas:

  • The configuration management capabilities in core need to support more common use cases out-of-the-box.
  • Composer and Drupal core should be better integrated to empower site builders to manage dependencies and keep Drupal sites up-to-date.
  • We should provide a longer grace period between required core updates so development teams have more time to prepare, test, and upgrade their Drupal sites after each new minor Drupal release.

We plan to make all of these aspects easier for site builders through the following initiatives:

Initiative Issue link Stakeholders Initiative coordinator Status
Composer & Core #2958021 Core contributors + Drupal Association Coordinator needed! Proposed
Config Management 2.0 #2957423 Core contributors Coordinator needed! Proposed
Security LTS 2909665 Core committers + Drupal Security Team + Drupal Association Core committers and Security team Proposed, under discussion

Goal 4: Promote Drupal to non-technical decision makers

The fourth initiative is unique as it will help our community to better communicate the value of Drupal to the non-technical decision makers. Today, marketing executives and content creators often influence the decision behind what CMS an organization will use. However, many of these individuals are not familiar with Drupal or are discouraged by the misconception that Drupal is primarily for developers.

With these challenges in mind, the Drupal Association has launched the Promote Drupal Initiative. This initiative will include building stronger marketing and branding, demos, events, and public relations resources that digital agencies and local associations can use to promote Drupal. The Drupal Association has set a goal of fundraising $100,000 to support this initiative, including the hiring of a marketing coordinator.

$54k raised for the Promote Drupal initiative

Megan Sanicki and her team have already raised $54,000 from over 30 agencies and 5 individual sponsors in only 4 days. Clearly this initiative resonates with Drupal agencies. Please consider how you or your organization can contribute.

Fostering community with values and principles

This year at DrupalCon Nashville, over 3,000 people traveled to the Music City to collaborate, learn, and connect with one another. It's at events like DrupalCon where the impact of our community becomes tangible for many. It also serves as an important reminder that while Drupal has grown a great deal since the early days, the work needed to scale our community is never done.

Prompted by feedback from our community, I have spent the past five months trying to better establish the Drupal community's principles and values. I have shared an "alpha" version of Drupal's values and principles at https://www.drupal.org/about/values-and-principles. As a next step, I will be drafting a charter for a new working group that will be responsible for maintaining and improving our values and principles. In the meantime, I invite every community member to provide feedback in the issue queue of the Drupal governance project.

Values and principles alpha
An overview of Drupal's values with supporting principles.

I believe that taking time to highlight community members that exemplify each principle can make the proposed framework more accessible. That is why it was very meaningful for me to spotlight three Drupal community members that demonstrate these principles.

Principle 1: Optimize for Impact - Rebecca Pilcher

Rebecca shares a remarkable story about Drupal's impact on her Type 1 diabetes diagnosis:

Principle 5: Everyone has something to contribute - Mike Lamb

Mike explains why Pfizer contributes millions to Drupal:

Principle 6: Choose to Lead - Mark Conroy

Mark tells the story of his own Drupal journey, and how his experience inspired him to help other community members:

Watch the keynote or download my slides

In addition to the community spotlights, you can also watch a recording of my keynote (starting at 19:25), or you can download a copy of my slides (164 MB).

Values and principles balloons

Since its founding, Drupal has grown a great deal, and today there are thousands of contributors and organizations that make up our community. Over the course of seventeen years, we have spent a great amount of time and effort scaling our community. As a result, Drupal has evolved into one of the largest open source projects in the world.

Today, the Drupal project serves as a role model to many other open source projects; from our governance and funding models, to how we work together globally with thousands of contributors, to our 3,000+ person conferences. However, the work required to scale our community is a continuous process.

Prompted by feedback from the Drupal community, scaling Drupal will be a key focus for me throughout 2018. I have heard a lot of great ideas about how we can scale our community, in addition to improving how we all work together. Today, I wanted to start by better establishing Drupal's values and principles, as it is at the core of everything we do.

Remarkably, after all these years, our values (what guides these behaviors) and our principles (our most important behaviors) are still primarily communicated through word of mouth.

In recent years, various market trends and challenging community events have inspired a variety of changes in the Drupal community. It's in times like these that we need to rely on our values and principles the most. However, that is very difficult to do when our values and principles aren't properly documented.

Over the course of the last five months, I have tried to capture our fundamental values and principles. Based on more than seventeen years of leading and growing the Drupal project, I tried to articulate what I know are "fundamental truths": the culture and behaviors members of our community uphold, how we optimize technical and non-technical decision making, and the attributes shared by successful contributors and leaders in the Drupal project.

Capturing our values and principles as accurately as I could was challenging work. I spent many hours writing, rewriting, and discarding them, and I consulted numerous people in the process. After a lot of consideration, I ended up with five value statements, supported by eleven detailed principles.

I shared both the values and the principles on Drupal.org as version 1.0-alpha (archived PDF). I labeled it alpha, because the principles and values aren't necessarily complete. While I have strong conviction in each of the Drupal principles and corresponding values, some of our values and principles are hard to capture in words, and by no means will I have described them perfectly. However, I arrived at a point where I wanted to share what I have drafted, open it up to the community for feedback, and move the draft forward more collaboratively.

Values and principles alpha
An overview of Drupal's values with supporting principles.

While this may be the first time I've tried to articulate our values and principles in one document, many of these principles have guided the project for a very long time. If communicated well, these principles and values should inspire us to be our best selves, enable us to make good decisions fast, and guide us to work as one unified community.

I also believe this document is an important starting point and framework to help address additional (and potentially unidentified) needs. For example, some have asked for clearer principles about what behavior will and will not be tolerated in addition to defining community values surrounding justice and equity. I hope that this document lays the groundwork for that.

Throughout the writing process, I consulted the work of the Community Governance Group and the feedback that was collected in discussions with the community last fall. The 1.0-alpha version was also reviewed by the following people: Tiffany Farriss, George DeMet, Megan Sanicki, Adam Goodman, Gigi Anderson, Mark Winberry, Angie Byron, ASH Heath, Steve Francia, Rachel Lawson, Helena McCabe, Adam Bergstein, Paul Johnson, Michael Anello, Donna Benjamin, Neil Drumm, Fatima Khalid, Sally Young, Daniel Wehner and Ryan Szrama. I'd like to thank everyone for their input.

As a next step, I invite you to provide feedback. The best way to provide feedback is in the issue queue of the Drupal governance project, but there will also be opportunities to provide feedback at upcoming Drupal events, including DrupalCon Nashville.