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.

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):

For people wondering if switching to the red hat model has worked for chef – super yes. It”;s for others to give details, but I wouldn”;t do the open core model again, if I wasn”;t building on an existing free software island.

–; Adam Jacob (@adamhjk) May 7, 2020
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.

Selling the whole product, and having the whole product be open source, and having third party produced builds, collaborating together, it”;s better on, I suspect, every angle.

–; Adam Jacob (@adamhjk) May 7, 2020
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.

It”;s less clear you could begin this way, but I think you could. If we had, it would”;ve been less of a shock to parts of the chef community. Not hearing a single conversation about lack of differentiation is like being in a hot tub, if you lived 13 years of it.

–; Adam Jacob (@adamhjk) May 7, 2020
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.

1) produce a product based 100% on open source code. 2) be the sole distributor of that product, based on your trademark, under whatever commercial terms make sense for your business. 3) encourage and collaborate with folks who want to build alternative distributions

–; Adam Jacob (@adamhjk) May 7, 2020
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.

It”;s not bad! It”;s also that the distribution is controlled – so the supply chain belongs to the company, and you can”;t get it for free. Rivals can”;t just rebrand – they have to also rebuild the supply chain, and recertify

–; Adam Jacob (@adamhjk) May 8, 2020

Of course. Source control, commits, quality assurance, build pipelines, asset hosting, marketing collateral, sales teams, customer success, etc

–; Adam Jacob (@adamhjk) May 8, 2020
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.

Yes, and it”;s why one size doesn”;t fit all cases. The foundation/island model is great if the goal is widespread adoption for the public benefit, with monetary upside being in competing solutions on top.

–; Adam Jacob (@adamhjk) May 8, 2020

So you”;ll see communities around the software directly, like chef, or hashicorp, etc, but not likely widespread multi vendor collaboration outside the edges.

–; Adam Jacob (@adamhjk) May 8, 2020

Foundations tend to accrue value to either the upstream directly, or to a consortium of vendors who compete on features above the core.

–; Adam Jacob (@adamhjk) May 8, 2020

Then imagine hashicorp does that with, say, Vault. All those companies would love to monetize vault. But if Hashi did that, suddenly they are peers (at best), with larger, more capable rivals. It would decimate the vault business for hashicorp, even as it widened total vault use

–; Adam Jacob (@adamhjk) May 8, 2020

The side effect is that the upstream is the “;commercial”; distribution, and multiple downstream distributions can exist. But it”;s not quite like a free software island, where the upstream is free, and only downstream commercials.

–; Adam Jacob (@adamhjk) May 8, 2020
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.

This is subtle but a big deal. If you aren”;t the upstream, then value must accrue, and supply chains must be created, that are tied to the upstream. That”;s bot what you want, most likely, if you”;re the primary source of value in the system.

–; Adam Jacob (@adamhjk) May 8, 2020
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.

Yep. If you”;re downstream, you better be building something on top, with proprietary differentiation.

–; Adam Jacob (@adamhjk) May 8, 2020

Exactly. I get into some variant of this argument with well meaning folks who advocate for foundations over all – that”;s great, if the money is supposed to go to huge organizations and the foundation itself. Otherwise..

–; Adam Jacob (@adamhjk) May 8, 2020

Absolutely. We had pissed of community members, because the assertion that “;Chef”; never belonged to them, while true (it belonged to Opscode/Chef software), was not the original social contract. Same happens to rhel, if you remember

–; Adam Jacob (@adamhjk) May 8, 2020

Do you think it matters whether you split company name and product name? Like, Zoom is sold by Zoom LLC. But Chef was sold by Opscode LLC.

–; Nat Torkington (@gnat) May 8, 2020

Thanks! I appreciate this braindump — always good when someone else's experience aligns with your own :). You're very good at communicating this, btw. Thanks for your time.

–; Nat Torkington (@gnat) May 8, 2020

My pleasure! I spent a lot of time thinking about it. You can read some of it over here https://t.co/1V40cBwvaS – more from the angle of building sustainable communities, but the same analysis. When we can travel again, we can have a drink and swear a lot about it.

–; Adam Jacob (@adamhjk) May 8, 2020

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.

Read more: feedproxy.google.com