The Business of Open Source
How do you build a business around open source when you’re competing with AWS and the like? Chef’s answer: double down on Open Source.
People talking in front of a fountain (source: lcarissimi via Pixabay)
In a recent Twitter thread, Adam Jacob (co-founder and former CTO of Chef) talked about Chef’s switch from an “open core” model to a a “Red Hat” model for licensing their software. It was a fascinating discussion, with important implications for open source companies and their business models. I’ll reproduce the thread here, with Nat Torkington’s comments.
First, I’d like to start with some background. The behavior of major cloud companies, such as Amazon, has increasingly stirred up angst and fear in open source companies. These companies provide (and support) software that anyone can download, install, and use for free. There are often commercially licensed add-ons around the open core. Amazon and other cloud providers have taken the free software without paying (after all, it’s free, that’s the point), and offer it in their commercial cloud products “as a service.” There’s nothing in the license to prevent this; after all, you can download and run the software without charge. It’s more free than beer; after all, you wouldn’t leave a party with a keg to sell on the street corner. The cloud providers have the technical capabilities to run and support the software at scale, so they have no need to buy services from companies like Chef (or Puppet, or Elastic, or MongoDB, or DataStax, or…), and in many cases they have the ability to build their own versions of the open source company’s proprietary add-ons. The result is that they are taking away market share without contributing anything in return. Stephen O’Grady has a good (and much more detailed) summary of the problem.
Learn faster. Dig deeper. See farther.
Many open source companies have responded with changes to their licensing and distribution models. And many of these changes are, essentially, making the software less “open.” Elastic, for example, distributes ElasticSearch (open source core) with proprietary components; ElasticSearch itself is free software, but to use their distribution legally, you have to untangle it from the proprietary components–not a simple task.
Chef has gone in the other direction. Just over a year ago, they doubled down on open source; as of April 2, 2019, all software development is under the Apache 2.0 license. You can download their software, use it, contribute to it, and even redistribute it or turn it into a service on your cloud platform, all for free. There is one catch: Chef is a trademark, and you do not get the rights to the trademark. You can redistribute the software, but you can’t call it Chef. This model is comparable to Red Hat’s: all of their software is open source, under the GNU Public License. You can use it to make your own distribution, but you can’t redistribute it and call it Red Hat.
And this is where it gets really interesting. Adam Jacob has been doing a lot of writing about sustainable free and open source communities: what does a community mean? Under what rules should it operate if it’s going to be healthy and meet the needs of its members? A community under which “freedom’s just another word for nothing left to lose” isn’t a community that’s meeting the needs of its members. Given his focus on open source communities, it’s not surprising that Adam supports Chef’s decision, though he left Chef before that decision was made. In this thread, he talks about why that decision was important and what it takes to build a healthy business around open source software. Here’s Adam (with my annotations and Nat’s comments):
An “existing free software island” is a project that already exists. Hadoop is an example; the Hadoop project pre-existed Cloudera and, while Cloudera contributed to the Hadoop ecosystem, they also built a lot of proprietary software. Hadoop is the “open core,” the island on which the company was built. Adam is saying that he’d use open core model–proprietary add-ons to an open-source core–only for building on an open source project that already exists and has its own community.
If the whole product is open source, the company is part of the community, and benefits genuinely from the work and enthusiasm of the community. In contrast, an open core company is building on top of an existing community. They may make that project usable to a wider community, but they shouldn’t count on the support of that community.
Adam spent 13 years explaining why Chef, the commercial product, was different from the Chef that you could download for free. With the Red Had model, those conversations would never have been needed.
Why collaborate with people building alternative distributions? Because that’s what leads to a healthy community, and your company is based as much on the health of the community as it is on the product itself. Maintaining control of the trademark is sufficient for product differentiation.
The supply chain is everything that produces and supports the bits that you download. The open source company manages and controls the open source infrastructure: the Git archives, the testing discipline, and so on. I’ve seen surprisingly little thinking about what the “software supply chain” really is, but if you’ve seen badly managed open source projects, understanding and managing the supply chain is where a company adds real value.
Upstream and downstream are relative terms referring to the source tree; if you develop from the source tree, you are “downstream” from it. In the Chef/Red Hat model, downstream development is encouraged, but requires building a new community and support infrastructure, in addition to rebranding.
I admit I’m not sure what can be “upstream” of an open source project, unless a company builds a product and releases a component of it as open source–for example, Apple’s LLVM or Swift–or many projects that Google started and eventually grew tired of. You can develop downstream, but that development implicitly adds value to the upstream on which you depend. This doesn’t mean you can’t succeed, but it does mean that you don’t have control over your own fate.
A few years ago, our theme at OSCon was “Open Source has Won.” It’s very difficult to imagine a new programming language, or a new web framework, or a new set of deployment tools, or a new library for machine learning, and so on (and so on and so on) succeeding if it’s not open source. Our habits have changed. However, it’s always dangerous to declare victory too early; and while the last 30 years have turned open source from a fringe movement into the mainstream, open source business models still face challenges. Companies ranging from Chef to Elastic are experimenting with new models. Chef’s model is open, straightforward, and designed to build strong communities. Those are the right values; we’ll see if they win out.