Elastic’s return to open source

The big news in the open source world last week was Elastic’s return to open source. As the Elastic founder and CTO Shay Banon announced, “We never stopped believing in open source at Elastic” and so Elastic “will be adding AGPL [GNU Affero General Public License] as another license option next to ELv2 [Elastic License 2.0] and SSPL [Server Side Public License] in the coming weeks.” I talked with Banon about it, and he was giddy with happiness over the license change/addition.

He was also very clear as to why the company could move back to its open source roots: AWS was no longer copying Elasticsearch. After Elastic changed its license in 2021, AWS could no longer copy-and-paste Elasticsearch as one of its service offerings. Eventually, AWS opted to fork Elasticsearch and develop a rival product, OpenSearch, which has seen growing success.

Banon explained that now that “Amazon is fully invested in their fork” and “the market confusion [around Elastic’s Elasticsearch trademarks] has been (mostly) resolved,” Elastic felt it no longer had to worry about AWS selling Elasticsearch as its own branded product. This has resulted in a “partnership with AWS [that] is stronger than ever.” This resonates with my own experience at MongoDB: AWS can be a fantastic partner. It just sometimes needs help getting there.

In the wake of Elastic’s return to an open source license, the question is whether other erstwhile “open source” companies will follow suit. As Banon suggests, that’s largely a question for AWS to answer.

Trademarking ‘partnership’

If you aren’t paying close attention, you can easily get sucked into thinking open source companies like Elastic are the bad guys. As the clichéd thinking goes, such companies only use open source as a marketing ploy and switch their licenses as soon as the cash comes rolling in.

Such arguments may sound great online, but they’re almost entirely wrong and get the bad guys all mixed up.

Take Banon, who founded Elastic and before that created the Elasticsearch project in 2010. As he tells it, he took out loans to trademark Elasticsearch to try to protect his work. This wasn’t the work of a rapacious open source corporate overlord. It was a developer trying to play by the open source rules (i.e., Red Hat, JBoss, and other early open source leaders relied on trademarks to protect their investments). By 2015, however, Amazon CTO Werner Vogels was calling the launch of the “Amazon Elasticsearch service, a great partnership between Elastic and AWS.”

Except it wasn’t. There was no partnership. There was nothing but AWS taking Elasticsearch and selling it as its own, with no contributions of cash, code, people, or anything else. For Elastic, it wasn’t about competition, but rather the way AWS sold the trademarked product. As Banon notes, “The problem was never AWS taking Elasticsearch and providing it, it was calling it AWS Elasticsearch and implying that it’s their service (including stating it explicitly).” According to Banon, “It’s a clear trademark infringement, but regardless of how much we tried, we had 1,000 lawyers thrown at us.”

Fortuitous forks

This brings us to the OpenSearch fork. Many thought AWS forking Elasticsearch sounded the death knell for Elastic. Nope. As I noted back in 2021, as good as OpenSearch may be for AWS, it hasn’t been bad for Elastic. Quite the contrary. By forcing AWS to build OpenSearch rather than borrow Elasticsearch, Elastic gave itself room to resume its open source ways. As Banon messaged me, “I personally always wanted to get back to open source, even when we changed the license. We were hoping AWS would fork and would let us move back when enough time has passed.” It was a calculated risk that appears to be paying off: “We just feel we can safely do it now that the fork has happened and it’s a big sunk cost for AWS,” he said.

I was at AWS when OpenSearch was born and worked with the founding team. It was and is a significant cost. But it was also a learning opportunity for AWS. It taught them just how hard it is to build community around an open source project, and how much money it takes (engineers, marketers, etc.,) to develop a product and not simply operationalize someone else’s product. Of course, there’s nothing “simple” about operations—it’s a difficult skill to master, and AWS arguably does it best.

More recently, AWS, working with other companies, forked Redis to create the Valkey project. From an AWS perspective, Valkey differs from anything they’ve done before because it’s one of the few projects where an AWS employee was one of the key contributors to the forked project. It’s also unusual in that this same employee, the impressive Madelyn Olson, contributes more than anyone else. If you look at a typical Cloud Native Computing Foundation project, for example, AWS almost never features in the top five for companies contributing (Kubernetes, OpenTelemetry, and others). Valkey could be a positive sign of things to come for AWS and open source.

It also might be a fantastic thing for Redis because AWS may invest so much in Valkey that it won’t have room for offering a Redis service (ElastiCache), similar to what happened with Elasticsearch. Not everyone agrees. Dave Neary, for example, thinks Redis misstepped with its license change, prompting the fork. Regardless, there’s a reasonable chance that Valkey, like OpenSearch, will make it easier for Redis to return to its open source start.

This is the TL;DR behind Elastic’s return to an OSI-approved open source license: When AWS ships open source code as its own, without contributing, it makes it hard for that code to remain open source. But when it partners and/or forks a project and delivers its own innovative offering, it follows its first leadership principle (Customer Obsession) and makes it easier for open source to remain open. The Elastics of the world want to remain open source. Just ask Banon. AWS has the power to make that possible.