Open source isn’t supposed to work like this. Like Elasticsearch, that is. A few years ago AWS called out Elastic for shifting away from Elasticsearch’s Apache-style permissive licensing to “some rights reserved” licensing. By early 2021, Elastic went farther down its licensing path, and AWS responded by forking Elasticsearch, resulting in OpenSearch.
Along the way, OpenSearch has picked up some open source adherents such as Instaclustr and Aiven, which have both built managed services for OpenSearch. Meanwhile, a chorus of industry voices beyond AWS has criticized Elastic for how it has handled licensing (see this tweet and this one).
But here’s the thing: For all the sound and fury, Elastic, the company, seems to be doing quite well. Elasticsearch, the code, doesn’t seem to be struggling, either. As I pointed out recently with serverless, sometimes we imagine a developer’s choices are strictly binary: open or closed. But as the Elasticsearch example suggests, developers aren’t nearly so simpleminded.
Much ado about something
I’ve been involved in open source for more than two decades, ever since I went to work for a Linux company in 2000. Nor have I simply been a passenger. I care a lot about all those pedantic, tedious open source debates that embroiled segments of the tech world during that time, and I have actively participated in the discussions on free software (GPL) versus open source (Apache/BSD/MIT), Open Core, and so on. I’ve written about the Free Software Foundation, open source licensing minutiae, developer devotion to community, and a lot more.
Yet during that same period of time, open source software came to permeate and even dominate huge swaths of computing. It’s hard to imagine cloud computing even existing without open source infrastructure powering it, even as most developers mostly yawned about open source licensing. As I detailed back in 2014, open source licensing has consistently moved toward more permissive licenses, to the point that most GitHub repositories don’t have a license at all.
As I wrote, “The GitHub generation seems determined to take open source to its logical conclusion: releasing most software under no license at all.” Personally, I didn’t like that. I wanted (and still want) people to care about these issues. But most don’t.
It’s useful to view the Elasticsearch fracas against this backdrop of laissez-faire licensing. It’s not that it doesn’t matter, as Fedora project leader Matthew Miller highlights. But for most developers, most of the time, it’s not the main event. Don’t believe me? Let’s look at Elastic’s financial results.
Elasticsearch is fine
In turning to finance, I’m not trying to sidestep the very real community concerns about Elastic’s license changes. What I am suggesting, however, is that if enough people were incensed about what Elastic has done, we’d see an impact on the adoption of Elasticsearch. Reviewing the company’s last few quarters, it’s hard to make that case.
On the company’s most recent earnings call, CEO Shay Banon reported 50% revenue growth and 89% revenue growth for the company’s cloud service. The company has seen significant acceleration during the past two quarters and now has more than 16,000 customers, with 780 that pay Elastic more than $100,000 each year. Back when AWS announced its Open Distro for Elasticsearch (March 2019), Elastic was trading at roughly $85 a share. Today the company trades at $182 a share and is worth nearly $17 billion.
In other words, you don’t have to like what Elastic did with its licensing to recognize that it hasn’t seemed to create customer problems for the company. I disagree with statements in the earnings call (I don’t personally believe that “every data problem can be solved by looking at it through the prism of a search box”), but it’s hard to credibly claim that the company’s license changes have hurt it financially.
What about its community? Surely that has suffered as the company has changed the license on formerly Apache-licensed software? On the earnings call, Banon said, “Based on all the metrics that we’re looking at—downloads, engagement on forums and GitHub and others—our users are just running ahead with us.” Well, he would say that, right? But what does the underlying data suggest?
Community is fine
Let’s start with committers. Did they leave Elastic post–license change? No, but then, most of the committers to Elasticsearch work for Elastic. That’s bad, right? Not really. At least, it’s not any different from OpenSearch, where most, if not all, committers work for AWS. But this isn’t really an Elasticsearch versus OpenSearch issue. It’s how most company-driven open source projects work. MySQL, for example, is a popular open source database that is almost entirely developed by Oracle. Grafana? Most contributions come from Grafana Labs. Commits to the Elasticsearch code base haven’t slowed over the years, and external contributors have continued to be part of Elasticsearch development, as can be seen in the GitHub data.
That’s contributor data. Another view is adoption data. Elastic’s business has always been a bottom-up, developer-led phenomenon. Through all the license changes, the Elasticsearch community has remained active, and if developers had stopped incorporating Elasticsearch into their projects, that would show up in the company’s financial results. It hasn’t.
In other words, even as Elastic and AWS have traded sanctimonious barbs in public, in private, developers and companies just keep embracing Elasticsearch (and OpenSearch, from what I’ve seen). Customers buying into these vendors’ respective managed services are not interested in source code, anyway. They just want someone to take away the undifferentiated heavy lifting of the underlying infrastructure (and its licenses!) for them so they can focus on delivering business value.
So here’s a hint for those on both sides who want to cast such decisions in a moral or ethical light: don’t. You don’t have to like how Elastic does business, so long as you recognize that it’s just that—business. It isn’t religion. It’s software, powering a software business.