Leading DevOps program Chef goes all in with open source
techrepublic cheat sheet
If you follow open-source news, you know that over the past few months "open-source" companies such as Confluent, Elastic, MongoDB, and Redis have distanced themselves from open-source licenses. Not so Chef, one of the leading DevOps companies. In a surprise move, Chef announced from here on out it would develop all of its software as open source under the Apache 2.0 license.
Before this, Chef had used an open-core approach. In open-core, the core software is open source, but software that makes it easier to use, offers additional features, or provides management functionality is proprietary. This is a common approach. The most well-known example is Oracle MySQL, which is dual-licensed under both the GPL and a commercial license.
Adam Jacob, one of Chef's co-founders and now a member of the board of directors, was overjoyed to announce this news. He proclaimed, "Chef is done with being Open Core, and is now a Free Software Product company. Good riddance to bad rubbish."
Jacob "couldn't be more thrilled" with the move. That's because:
It eliminates the longest-running source of friction and frustration from my time at Chef. On the one hand, we have a community that cares about the software, and about each other, where we develop the software in concert with our users and customers. On the other, we produced a proprietary software stack, which we use to make money. Deciding what's in, and what's out, or where to focus, was the hardest part of the job at Chef. I'm stoked nobody has to do it anymore. I'm stoked we can have the entire company participating in the open-source community, rather than burning out a few dedicated heroes.
What does that mean for Chef's customers? Jacob said, "Chef Software produces only open-source software projects, in the commons. It distributes that software as an enterprise product. For current Chef Software customers, nothing changes. For enterprise users of Chef products who are not customers, they can decide to either pay for Chef's distribution, or they can make or consume an alternative."
Going deeper in the new Chef FAQ, Chef stated:
"We will begin to attach commercial license terms to our software distribution (binaries) with the next major release." So, if you download and compile the code yourself, you're welcome to use it. But, if you download the binaries, you'll must pay for them. If that sounds familiar, it should. It's a variation of how Red Hat and SUSE, for example, release their enterprise Linux distributions.
. . . For existing commercial customers there will be no immediate changes until their next renewal when they will get licensed onto new SKU's representing the same core products."
If you've been using Chef binaries for free, it's a different story. The company sees three possible paths: License a commercial version; use an older version; or "Take our open source code and create a software development org to build and manage their own distro (create their own downstream fork) or leverage a public free distribution (which may or may not exist)."
OpenLineCook anyone?
If there is such a fork, it won't be OpenChef. That's because Chef has made its clear that you can't use its trademarks. Red Hat, back in the day when Red Hat clones were popular, took a similar approach to protect its business. As Stephen O'Grady, RedMonk industry analyst, observed, "What Chef is saying in effect is that anyone can build, run and even sell Chef the software, but it may not be called -- directly or indirectly -- Chef."
In a tweet, Jacob spelled out the future for people using Chef binaries: "You can continue to use them for experimentation, and for non commercial use. If you want to use our product as part of a commercial business, we ask that you pay for it. If you don't want to do that/can't do that, you can build your own distribution."
Featured
Chef also announced it was introducing a new new commercial distribution, Chef Enterprise Automation Stack. This is an enterprise-grade DevOps system for setting up and managing infrastructure, security policies, and application lifecycle dependencies as code.
Looking forward, Chef is well aware that there may be a fork. And, it's OK with that, In the FAQ, Chef stated: "It is absolutely possible that there will be derivative branches of Chef's projects and we look forward to welcoming them into our communities and working with them to ensure that their contributions can benefit everyone in the Chef open source ecosystem."
So why is it calm about this possibility? Because it knows that business customers want the support, service-level agreements, liability protection, and security that only it will be able to supply in the short term. These are the same reasons why -- even though there are hundreds of Linux distributions -- Canonical, Red Hat, and SUSE remain on the top of the business Linux mountain year-in and year-out.
Will it work? We don't know yet.
O'Grady commented, "It is far too early to make a determination on how Chef's new model will fare, whether the metric is the company's balance sheet or the less quantifiable market sentiment. Whatever its fate, however, for someone who has been alarmed at the normalization of practices that were problematic at best for open source broadly, it is encouraging to see a vendor attempting to find a model that requires compromises, but adheres at least to the letter of the law. "