Why Cloudera, Yugabyte, and Chef Went Open Source

Will Open Source Get More Open in 2020?

Licensing changes at Cloudera, Yugabyte, and Chef show an interest in getting more open--though it’s too soon to say it signals a broad trend that others will follow. Yet there’s still a lot to learn from each company’s motivations.

I was hopeful that would jump start a broad trend towards more companies embracing the open in open source. With Cloudera and now Yugabyte making similar moves, the obvious question is: Will more OSS companies follow suit?Probably not. Each of these announcements makes sense for the company for different reasons. But when you step back, there are a few common elements tying them together. 

Cloudera. Hortonworks and Cloudera merged after years of competing. Hortonworks was all open source and offered services and support (commonly called the Red Hat model). Cloudera was open-core, meaning is created its own proprietary code around the code of open source Hadoop. With the merger, everyone expected them to consolidate on one of the models. This hints at why they chose open:

“By investing in open source projects such as Spark, Kubernetes and Kafka, we keep our customers on a sustainable long-term architecture vs. pulling them onto an island of Cloudera-only developed tools.”

Hadoop started the big data movement and seeded the ecosystem in the Apache Foundation. While the vendors that followed, like Confluent, are making code more proprietary to defend their niche, Clouders sees the opportunity to go the other way and attract wide swaths of customers that are largely satisfied by the core projects. They hope to be to data platforms what RedHat is to compute platforms.

Yugabyte. The most valuable thing an open source company can do is reach ubiquity of use.

In almost every case, open source companies that achieve broad universal adoption also generate meaningful financial returns. It’s like fishing in a stocked pond.

Hadoop has reached that point, though may be on the decline. Yugabyte, on the other hand, is still in the early adoption stages. I think their is both validation of the value of ubiquity and acknowledgement of how much further they still have to go to achieve it. The company described the change as a move to full open source, though I see it as really just dialing back proprietary in favor of more open source. It is true that the YugabyteDB project, by some definition, is fully open source, but some of the code that the Yugabyte company produces is still proprietary. That said, this is a meaningful announcement. It sets a high water mark on the recent trend towards proprietary code, especially for a DB company running on public clouds. There is still a strong business rationale for a high degree of openness.

Chef. I analyzed Chef’s licensing changes , but it’s worth revisiting a couple of points about Chef that are also generalizable.

Continuous integration and delivery (CI/CD) along with an increased sensitivity to security have changed how users view open source offerings. While it used to be fine to get versions of software periodically, users today expect and demand ever-updating software. Using outdated open source software is not only inconvenient, in some cases it is no longer acceptable because it can introduce security vulnerabilities. Users will pay to ensure that they are getting the latest security patches. Notice in that "the subscription agreement will cover the terms of support and maintenance, as well as access to the latest updates and security patches." Cloudera and Chef are both recognizing that there is lots of value in timely access to open source code from trusted sources (Cloudera and Chef engineers), and in some cases more value than value from add-on proprietary features. Customers wanted to pay for an open trusted core more than for an open core + add-ons. As part of Chef’s open source transition, Chef went from monetizing product features to, among other things, monetizing its robust build pipeline through timely distributions. Chef customers get a subscription to these builds ensuring heightened security as well as the latest features.

More Experimentation Ahead in 2020

We shouldn’t extrapolate from the above three announcements that we’re in a new era of more open open source. Instead, we should recognize all the signs that open source software is alive and well despite the many high-profile moves towards proprietary codebases. What is ahead then? 2019 was a year where we saw rich experimentation on the . In 2020, that experimentation will continue. But I expect we'll see a lot more open source companies really leaning in to their source distribution models as competitive differentiators for their products, in the same way traditional software companies emphasize on-prem or cloud, or vertical versus horizontal.Open source still has its place in the enterprise.