Over the course of the past three plus years, the market has seen a growing number of commercial open source organizations – with encouragement from some investors – drifting away from traditional open source licensing and norms. While there have been significant differences in the precise mechanics of their respective approaches, the common thread between the likes of Confluent, Elastic, MongoDB, Redis Labs and Timescale has been their willingness to violate open source norms long considered sacrosanct.
Contrary to internet opinions, however, little if any of this was done with malicious intent, or absent due consideration for the grave implications of the various moves. In the majority of cases, the difficult decisions were made reluctantly, under duress. Whether that duress was real or more theoretical in nature is a matter of some debate, but there can be no doubt that the companies involved embarked on these courses because they felt they had to, not because they particularly wanted to.
There have been many contributing factors to this drift away from open source, including the intrinsic problems of compelling payment for assets otherwise available for free, but by far the biggest driver has been the once cold war that recently escalated into a full scale hot war between cloud vendors and commercial open source providers. The relationships between these archetypes is fraught, and has evolved from relatively benign indifference on the part of open source providers to existential, unmanageable dread.
The collective trajectory away from open source is why Chef’s announcement this morning would be interesting by itself. A commercial open source organization choosing to move against the current of our times, back towards the embrace of a purer open source model even as its peers abandon it certainly qualifies as news. What’s curious is that in this particular case how Chef is doing so is even more interesting than the fact they are. Here are the three most important statements that can be inferred from Chef’s announcement.
- Source Code Is Not the Real Value:
In RedMonk’s pre-briefing on this news, perhaps the best take came from my colleague Rachel Stephens who said, “as much as this announcement comes after Adam [Jacob, co-founder Chef and former CTO] has formally left the company, it has his fingerprints all over it.” For anyone that has followed his industry commentary and work on sustainable open source, and more specifically his agitation against the blurred open source licenses that had become more common, any reaction but abject approval would be implausible. And approve he most certainly did. In a link to his commentary on the announcement, Adam said in part “So happy that [Chef] is now a 100% open source company.”If his perspective is understood here properly, his belief is that this decision is fundamentally an implicit validation of the value of the software. Traditional open core models such as the one Chef formerly operated under, according to Jacob, imply that the open source code is valueless relative to the non-open source software held back. If the underlying source code is one hundred percent open source, however, the value is restored: “with a Free Software Product model, we say the software we produce is a valuable component of a complete Product.“
With respect, from this vantage point this announcement implies the exact opposite.
Where other commercial entities have sought to protect their source code – which they view as the asset worth protecting – with licenses of escalating complexity and potential for collateral damage, Chef has chosen a diametrically opposed path. They have instead chosen to strip whatever minimal licensing protections they were afforded via a loose open core model, leaving the entire body of code available to any taker. The permissive license selected – the Apache software license – offers very few restrictions on usage. Interpretations may differ then, but the most plausible conclusion seems to be that Chef is not valuing their source code as an asset worth protecting. This move may cut the legs out from under specious arguments about value with nit-picking corporate procurement personnel, but outside of that specific context it’s difficult to argue that removing protections is suggestive of greater rather than lesser value for the code itself.
Whether the potential devaluation of the source code is good or bad depends entirely on one’s context, of course. It has been argued here many times, however, that the evidence is clear on the subject. As such, Chef’s behavior is consistent with long term market direction.
-
Trademark is the Real Value:
If one accepts even if only for the sake of argument that source code is not the primary value, the logical question is what is? The answer can be found in the phrase “as long as our trademark policy is respected” contained within the official announcement. This unobtrusive bit of seeming legalese is in fact doing a great deal of work. It neatly encapsulates, in fact, the bet that Chef is making on its business model, and by extension the company.For all of the understandable attention Chef is receiving for its move away from open core to a fully open source development model – which may or may not be the same as a fully open source model broadly, as we’ll come back to shortly – comparatively little has been paid to what is implied by the above statement. 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 such a scenario, the obvious implication is that the source code, however intrinsically valued, is in fact worth less than the name by which it is called.
The contrast versus commercial open source peers such as Elastic is particularly stark. The search company has, as a matter of policy, applied greater protections to its source code via proprietary licenses than it had for its trademark – a trademark approach that Adam notably characterized as a “mistake.” Correlation does not prove causation, of course, but it is notable that Elastic finds itself competing with Elastic-branded alternatives from AWS while Chef has a reseller agreement with the cloud giant.
This is a bet, to be clear. There is no guarantee – and importantly no protections other than trademark and, potentially, popular sentiment – should one or more of the cloud giants pick up Chef’s work and start selling it under a new brand with no contributions back – be that code, revenue or both. It is also worth noting that Chef’s existing reseller agreement with AWS centers around Automate, the previously protected proprietary software that is now open source.
But faced with a choice between trying to reconcile fundamentally incompatible models in open source and proprietary software and a model that tacitly acknowledges the lessened importance of actual code relative to brand, Chef has chosen the latter.
-
Distribution is the Secondary Value:
Even less discussed than trademark has been the binary license. While Chef can rightly claim that it now has a fully open source software model, it understandably spends less time discussing the fact that the binary builds of this software are issued under a proprietary software license. Builds which have led, probably inevitably, to questions of whether Chef’s 100% open source model is in fact 100% open source. Setting that question aside for the moment as the market will need time to assess it, what this means in practice is that anyone who chooses to run Chef must now choose between leveraging a build of fully open source software that is wrapped in a proprietary license on the one hand and building the software themselves on the other.What this in turn suggests is that in addition to the primary value of trademark, Chef is assigning at least some secondary value to distribution in the form of its packaged binaries. Which is likely to make for some interesting and complicated edge cases that will be challenging for the company to navigate, as has been discussed at length even in the few hours since the news dropped. But it is at the same time perfectly aligned with Mårten Mickos’ old saying that “enterprises are willing spend money to save time, while an individual developer is more likely to spend time to save money.” Those who have more time than money are free to build it themselves, per the company. Enterprises, however, are overhelmingly likely to trade money to save that time and effort.
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. It is just as encouraging, if surprising, to see this approach championed by an investor, given that group’s historic and demonstrated lack of concern for so-called soft issues like community standards and practices.
Chef may not have this model right, and it may not be the right model for Chef let alone other commercial open source organizations, but this line of experimentation seems inarguably less likely to result in permanent damage to open source than the hybrid licenses which have preceded it. As such, it’s earned the warm welcome it has received thus far in open source circles, even if some of the downstream negative implications have yet to be fully understood.
Disclosure: AWS, Elastic and MongoDB are RedMonk clients. Chef, Confluent, Redis Labs and TimeScale are not current clients.
