I sent an internal note to all of Acquia's 700+ employees today and decided to cross-post it to my blog because it contains a valuable lesson for any startup. One of my personal challenges — both as an Open Source evangelist/leader and entrepreneur — has been to learn to be comfortable with not being understood. Lots of people didn't believe in Open Source in Drupal's early days (and some still don't). Many people didn't believe Acquia could succeed (and some still don't). Something is radically different in software today, and the world is finally understanding and validating that some big shifts are happening. In many cases, an idea takes years to gain general acceptance. Such is the story of Drupal and Acquia. Along the way it can be difficult to deal with the naysayers and rejections. If you ever have an idea that is not understood, I want you to think of my story.
This week, Acquia got a nice mention on Techcrunch in an article written by Jake Flomenberg, a partner at Accel Partners. For those of you who don't know Accel Partners, they are one of the most prominent venture capital investors and were early investors in companies like Facebook, Dropbox, Slack, Etsy, Atlassian, Lynda.com, Kayak and more.
The article, called "The next wave in software is open adoption software", talks about how the enterprise IT stack is being redrawn atop powerful Open Source projects like MongoDB, Hadoop, Drupal and more. Included in the article is a graph that shows Acquia's place in the latest wave of change to transform the technology landscape, a place showing our opportunity is bigger than anything before as the software industry migrated from mainframes to client-server, then SaaS/PaaS and now - to what Flomenberg dubs, the age of Open Adoption Software.
It's a great article, but it isn't new to any of us per se – we have been promoting this vision since our start nine years ago and we have seen over and over again how Open Source is becoming the dominant model for how enterprises build and deliver IT. We have also shown that we are building a successful technology company using Open Source.
Why then do I feel compelled to share this article, you ask? The article marks a small but important milestone for Acquia.
We started Acquia to build a new kind of company with a new kind of business model, a new innovation model, all optimized for a new world. A world where businesses are moving most applications into the cloud, where a lot of software is becoming Open Source, where IT infrastructure is becoming a metered utility, and where data-driven services make or break business results.
We've been steadily executing on this vision; it is why we invest in Open Source (e.g. Drupal), cloud infrastructure (e.g. Acquia Cloud and Site Factory), and data-centric business tools (e.g. Acquia Lift).
In my 15+ years as an Open Source evangelist, I've argued with thousands of people who didn't believe in Open Source. In my 8+ years as an entrepreneur, I've talked to thousands of business people and dozens of investors who didn't understand or believe in Acquia's vision. Throughout the years, Tom and I have presented Acquia's vision to many investors – some have bought in and some, like Accel, have not (for various reasons). I see more and more major corporations and venture capital firms coming around to Open Source business models every day. This trend is promising for new Open Source companies; I'm proud that Acquia has been a part of clearing their path to being understood.
When former skeptics become believers, you know you are finally being understood. The Techcrunch article is a small but important milestone because it signifies that Acquia is finally starting to be understood more widely. As flattering as the Techcrunch article is, true validation doesn't come in the form of an article written by a prominent venture capitalist; it comes day-in and day-out by our continued focus and passion to grow Drupal and Acquia bit by bit, one successful customer at a time.
Building a new kind of company like we are doing with Acquia is the harder, less-traveled path, but we always believed it would be the best path for our customers, our communities, and ultimately, our world. Success starts with building a great team that not only understands what we do, but truly believes in what we do and remains undeterred in its execution. Together, we can build this new kind of company.
Founder and Project Lead, Drupal
Co-founder and Chief Technology Officer, Acquia
In my latest SXSW talk, I showed a graphic of each of the major technology giants to demonstrate how much of our user data each company owned.
I said they won't stop until they know everything about us. Microsoft just bought LinkedIn, so here is what happened:
By acquiring the world's largest professional social network, Microsoft gets immediate access to data from more than 433 million LinkedIn members. Microsoft fills out the "social graph" and "interests" circles. There is speculation over what Microsoft will do with LinkedIn over time, but here is what I think is most likely:
In the past I wrote that data, not software, is eating the world. The real value in technology comes less and less from software and more and more from data. As most businesses are moving applications into the cloud, a lot of software is becoming free, IT infrastructure is becoming a metered utility, and data is what is really makes or breaks business results. Here is one excerpt from my post: "As value shifts from software to the ability to leverage data, companies will have to rethink their businesses. In the next decade, data-driven, personalized experiences will continue to accelerate, and development efforts will shift towards using contextual data.". This statement is certainly true in Microsoft / LinkedIn's case.
If this deal shows us anything, it's about the value of user data. Microsoft paid more than $60 per registered LinkedIn user. The $26.2 billion price tag values LinkedIn at about 91 times earnings, and about 7 percent of Microsoft's market cap. This is a very bold acquisition. You could argue that this is too hefty a price tag for LinkedIn, but this deal is symbolic of Microsoft rethinking its business strategy to be more data and context-centric. Microsoft sees that the future for them is about data and I don't disagree with that. While I believe acquiring LinkedIn is a right strategic move for Microsoft, I'm torn over whether or not Microsoft overpaid for LinkedIn. Maybe we'll look back on this acquisition five years from now and find that it wasn't so crazy, after all.
From the day we started Acquia, we had big dreams: we wanted to build a successful company, while giving back to the Open Source community. Michael Skok was our first investor in Acquia and instrumental in making Acquia one of the largest Open Source companies in the world, creating hundreds of careers for people passionate about Open Source. This week, Michael and his team officially announced a new venture firm called _Underscore.VC. I'm excited to share that I joined _Underscore.VC as a syndicate lead for the "Open Source _Core".
I'm very passionate about Open Source and startups, and want to see more Open Source startups succeed. In my role as the syndicate lead for the Open Source _Core, I can help other Open Source entrepreneurs raise money, get started and scale their companies and Open Source projects.
Does that mean I'll be leaving Drupal or Acquia? No. I'll continue as the lead of the Drupal project and the CTO of Acquia. Drupal and Acquia continue to be my full-time focus. I have been advising entrepreneurs and startups for the last 5+ years, and have been a moderately active angel investor the past two years. Not much, if anything, will change about my day-to-day. _Underscore.VC gives me a better platform to advise and invest, give back and help others succeed with Open Source startups. It's a chance to amplify the "do well and do good" mantra that drives me.
While Michael, the _Underscore.VC team and I have been working on _Underscore.VC for quite some time, I'm excited to share that on top of formally launching this week, they've unveiled a $75 million fund, as well as our first seed investment. This first investment is in Mautic, an Open Source marketing automation company.
Mautic is run by David Hurley, who I've known since he was a community manager at Joomla!. I've had the opportunity to watch David grow for many months. His resourcefulness, founding and building the Mautic product and Open Source community impressed me.
The Mautic investment is a great example of _Underscore.VC's model in action. Unlike a traditional firm, _Underscore.VC co-invests with a group of experts, called a syndicate, or in the case of _Underscore.VC a "_Core". Each _Core has one or more leads that bring companies into the process and gather the rest of the investors to form a syndicate.
As the lead of the Open Source _Core, I helped pull together a group of investors with expertise in Open Source business models, marketing automation, and SaaS. The list of people includes Larry Augustin (CEO of SugarCRM), Gail Goodman (CEO of Constant Contact), Erica Brescia (Co-Founder and COO of Bitnami), Andrew Aitken (Open Source Lead at Wipro) and more. Together with _Underscore.VC, we made a $600,000 seed investment in Mautic. In addition to the funding, Mautic will get access to a set of world-class advisors invested in helping them succeed.
I personally believe the _Underscore.VC model has the power to transform venture capital. Having raised over $180 million for Acquia, I can tell you that fundraising is no walk in the park. Most investors still don't understand Open Source business models. To contrast, our Open Source _Core group understands Open Source deeply; we can invest time in helping Mautic acquire new customers, recruit great talent familiar with Open Source, partner with the right companies and navigate the complexities of running an Open Source business. With our group's combined expertise, I believe we can help jumpstart Mautic and reduce their learnings by one to two years.
It's also great for us as investors. By combining our operating experience, we hope to attract entrepreneurs and startups that most investors may not get the opportunity to back. Furthermore, the _Core puts in money at the same valuation and terms as _Underscore.VC, so we can take advantage of the due diligence horsepower that _Underscore.VC provides. The fact that _Underscore.VC can write much larger checks is also mutually beneficial to the _Core investor and the entrepreneur; it increases the chances of the entrepreneur succeeding.
The Gotthard Base Tunnel, under construction for the last 17 years, was officially opened last week. This is the world's longest and deepest railroad tunnel, spanning 57 kilometers from Erstfeld to Bolio, Switzerland, underneath the Swiss Alps. To celebrate its opening, Switzerland also launched a multi-lingual multimedia website to celebrate the project's completion. I was excited to see they chose to build their site on Drupal 8! The site is a fitting digital tribute to an incredible project and launch event. Congratulations to the Gotthard Base Tunnel team!
In an earlier blog post, I looked at the web services solutions available in Drupal 8 and compared their strengths and weaknesses. That blog post was intended to help developers choose between different solutions when building Drupal 8 sites. In this blog post, I want to talk about how to advance Drupal's web services beyond Drupal 8.1 for the benefit of Drupal core contributors, module creators and technical decision-makers.
Moreover, newer headless content-as-a-service solutions (e.g. Contentful, Prismic.io, Backand and CloudCMS) have entered the market and represent a widening interest in content repositories enabling more flexible content delivery. They provide content modeling tools, easy-to-use tools to construct REST APIs, and SDKs for different programming languages and client-side frameworks.
In my view, we need to do the following, which I summarize in each of the following sections: (1) facilitate a single robust REST module in core; (2) add functionality to help web services modules more easily query and manipulate Drupal's entity graph; (3) incorporate GraphQL and JSON API out of the box; and (4) add SDKs enabling easy integration with Drupal. Though I shared some of this in my DrupalCon New Orleans keynote, I wanted to provide more details in this blog post. I'm hoping to discuss this and revise it based on feedback from you.
While core REST can be enabled with only a few configuration changes, the full extent of possibilities in Drupal is only unlocked either when leveraging modules which add to or work alongside core REST's functionality, such as Services or RELAXed, or when augmenting core REST's capabilities with additional resources to interact with (by providing corresponding plugins) or using other custom code.
Having such disparate REST modules complicates the experience. These REST modules have overlapping or conflicting feature sets, which are shown in the following table.
|Feature||Core REST||RELAXed||Services||Ideal core REST|
|Content entity CRUD||Yes||Yes||Yes||Yes|
|Configuration entity CRUD||Create resource plugin (issue)||Create resource plugin||Yes||Yes|
|Custom resources||Create resource plugin||Create resource plugin||Create Services plugin||Possible without code|
|Custom routes||Create resource plugin or Views REST export (GET)||Create resource plugin||Configurable route prefixes||Possible without code|
|Translations||Not yet (issue)||Yes||Create Services plugin||Yes|
|Revisions||Create resource plugin||Yes||Create Services plugin||Yes|
|File attachments||Create resource plugin||Yes||Create Services plugin||Yes|
|Authenticated user resources (log in/out, password reset)||Not yet (issue)||No||User login and logout||Yes|
I would like to see a convergence where all of these can be achieved in Drupal core with minimal configuration and minimal code.
Recently, a discussion at DrupalCon New Orleans with key contributors to the core REST modules, maintainers of important contributed web services modules, and external observers led to a proposed path forward for all of Drupal's web services.
Buried inside Drupal is an "entity graph" over which different API approaches like traditional REST, JSON API, and GraphQL can be layered. These varied approaches all traverse and manipulate Drupal's entity graph, with differences solely in the syntax and features made possible by that syntax. Unlike core's REST API which only returns a single level (single entity or lists of entities), GraphQL and JSON API can return multiple levels of nested entities as the result of a single query. To better understand what this means, have a look at the GraphQL demo video I shared in my DrupalCon Barcelona keynote.
What we concluded at DrupalCon New Orleans is that Drupal's GraphQL and JSON API implementations require a substantial amount of custom code to traverse and manipulate Drupal's entity graph, that there was a lot of duplication in that code, and that there is an opportunity to provide more flexibility and simplicity. Therefore, it was agreed that we should first focus on building an "entity graph iterator" that can be reused by JSON API, GraphQL, and other modules.
This entity graph iterator would also enable manipulation of the graph, e.g. for aliasing fields in the graph or simplifying the structure. For example, the difference between Drupal's "base fields" and "configured fields" is irrelevant to an application developer using Drupal's web services API, but Drupal's responses leak this internal distinction by prefixing configured fields with
field_ (see the left column in the table below). By the same token, all fields, even if they carry single values, expose the verbosity of Drupal's typed data system by being presented as arrays (see the left column in the table below). While there are both advantages and disadvantages to exposing single-value fields as arrays, many developers prefer more control over the output or the ability to opt into simpler outputs.
A good Drupal entity graph iterator would simplify the development of Drupal web service APIs, provide more flexibility over naming and structure, and eliminate duplicate code.
|Current core REST (shortened response)||Ideal core REST (shortened response)|
While both JSON API and GraphQL are preferred over traditional REST due to their ability to provide nested entity relationships, GraphQL goes a step further than JSON API by facilitating explicitly client-driven queries, in which the client dictates its data requirements.
While a unified REST API and support for GraphQL and JSON API would dramatically improve Drupal as a web services back end, we need to be attentive to the needs of consumers of those web services as well by providing SDKs and helper libraries for developers new to Drupal.
An SDK could make it easy to retrieve an article node, modify a field, and send it back without having to learn the details of Drupal's particular REST API implementation or the structure of Drupal's underlying data storage. For example, this would allow front-end developers to not have to deal with the details of single- versus multi-value fields, optional vs required fields, validation errors, and so on. As an additional example, incorporating user account creation and password change requests into decoupled applications would empower front-end developers building these forms on a decoupled front end such that they would not need to know anything about how Drupal performs user authentication.
I believe that it is important to have first-class web services in Drupal out of the box in order to enable top-notch APIs and continue our evolution to become API-first.
In parallel with our ongoing work on shoring up our REST module in core, we should provide the underpinnings for even richer web services solutions in the future. With reusable helper functionality that operates on Drupal's entity graph available in core, we open the door to GraphQL, JSON API, and even our current core REST implementation eventually relying on the same robust foundation. Both GraphQL and JSON API could also be promising modules in core. Last but not least, SDKs like Hydrant that empower developers to work with Drupal without learning its complexities will further advance our web services.
Collectively, these tracks of work will make Drupal uniquely compelling for application developers within our own community and well beyond.
Special thanks to Preston So for contributions to this blog post and to Moshe Weitzman, Kyle Browning, Kris Vanderwater, Wim Leers, Sebastian Siemssen, Tim Millwood, Ted Bowman, and Mateu Aguiló Bosch for their feedback during its writing.
Updates from Dries straight to your mailbox