AWS Forks Elasticsearch — The OpenSearch Announcement and What It Means for Open Source

The other shoe has dropped. Yesterday, AWS announced OpenSearch, a community-driven fork of Elasticsearch and Kibana under the Apache 2.0 license. This was the widely expected response to Elastic’s January decision to relicense Elasticsearch from Apache 2.0 to the Server Side Public License (SSPL) and the Elastic License. And with it, we’ve entered a new chapter in the most significant open source licensing dispute since Redis and MongoDB went through similar transitions.

Let me be upfront: I have mixed feelings about this, and I think anyone who doesn’t is either not paying attention or has picked a side for tribal reasons rather than technical ones.

The Background

#

In January, Elastic announced that Elasticsearch and Kibana would move from the Apache 2.0 license to a dual license under SSPL and the Elastic License. The stated reason: AWS was offering Elasticsearch as a managed service, contributing minimally back to the project, and using the Elastic trademark in ways that confused customers.

Elastic’s argument has merit. They built the product, they employ most of the contributors, and they watched a company with functionally unlimited resources offer their software as a competing managed service. The financial dynamics are real — Elastic’s business depends on selling managed Elasticsearch, and AWS’s offering directly undercuts that.

AWS’s counterargument also has merit. Elasticsearch was Apache 2.0 licensed. That license explicitly permits this kind of use. Elastic benefited enormously from the open source ecosystem — community contributions, integrations, adoption — and changing the license after achieving dominance feels like pulling up the ladder behind you.

What OpenSearch Actually Is

#

OpenSearch will fork from Elasticsearch 7.10.2, the last Apache 2.0-licensed version. It will include the Open Distro for Elasticsearch features that AWS has been developing — security, alerting, SQL support, and performance tools — which were already Apache 2.0 licensed.

The project will live under its own governance (details still TBD), accept community contributions, and maintain compatibility with the Elasticsearch API. AWS has committed to ongoing development and is positioning this as a community project, not just an AWS product.

From a technical perspective, the immediate impact is limited. Elasticsearch 7.10.2 is a solid, mature product. The codebase is well-understood, and the basic functionality isn’t going anywhere. The question is what happens over the next year or two as the Elastic-maintained Elasticsearch and the AWS-maintained OpenSearch diverge.

The Fork Dynamics

#

History tells us that forks can go several ways. Some become the dominant project (LibreOffice over OpenOffice, MariaDB gaining significant ground on MySQL). Others wither as the community consolidates around the original (the various Node.js fork attempts before the io.js merger). The outcome usually depends on where the contributors and the ecosystem go.

AWS has resources that Elastic can’t match. They can throw engineers at OpenSearch, integrate it deeply into their cloud platform, and leverage their massive customer base. But Elastic has the brand, the existing contributor community, most of the institutional knowledge, and years of momentum.

For downstream users, the concern is API compatibility. If you’re building on the Elasticsearch REST API today, will your code work with both Elasticsearch and OpenSearch in two years? Probably, for the basics. But as features diverge, the compatibility surface will shrink. This is the MariaDB/MySQL story repeating itself — initially interchangeable, then increasingly not.

The Broader Open Source Question

#

This situation crystallizes a tension that’s been building in open source for years: how do you sustain open source projects when cloud providers can operationalize them at scale without proportional contribution?

The SSPL was MongoDB’s answer. The BSL (Business Source License) is MariaDB’s variant. Elastic’s dual license is another approach. Redis tried Commons Clause before switching to the Redis Source Available License. Each of these represents a company saying: “We can’t sustain this project if cloud providers capture most of the value.”

And they’re not wrong. The economics are genuinely difficult. But the solutions all involve restricting freedoms that the community relied on, which erodes trust.

AWS’s response — forking and maintaining an open source version — is technically within their rights and arguably good for open source purity. But it’s also an exercise of massive corporate power. A startup can’t sustain a fork of Elasticsearch. AWS can. That asymmetry matters.

I don’t think there’s a clean “good guy / bad guy” narrative here. Elastic changed the rules after benefiting from open source adoption. AWS is using its overwhelming resources to maintain a fork that serves its business interests. Both are acting rationally within their constraints. Both are also, in different ways, making the open source ecosystem a more complicated place.

Practical Implications

#

If you’re running Elasticsearch today, here’s what I’d suggest:

1. Don’t panic. Nothing changes immediately. Your current Elasticsearch deployment continues to work.
2. Evaluate your license exposure. If you’re using Elasticsearch 7.11+, you’re on the new license. Understand what that means for your use case.
3. Watch the ecosystem. Log management tools, APM solutions, and other integrations will need to decide which project to support. Those decisions will shape the practical viability of each fork.
4. Abstract your search layer. If you haven’t already, use an abstraction layer between your application and Elasticsearch. This gives you flexibility to switch between Elasticsearch and OpenSearch (or something else entirely) as the situation evolves.
5. Keep an eye on OpenSearch governance. The difference between a genuine community project and an AWS-controlled project with community window dressing will become apparent in the governance model.

My Take

#

I’ve used Elasticsearch since version 0.90. It’s been a transformative technology — making full-text search accessible to small teams was genuinely revolutionary. Watching this licensing drama play out is dispiriting, but it was probably inevitable.

My honest assessment: in two years, we’ll likely have two viable projects serving somewhat different audiences. Elasticsearch will cater to organizations that want the integrated Elastic Stack experience (ELK/Elastic Security/Elastic Observability). OpenSearch will serve organizations that want a managed search and analytics engine, primarily on AWS but potentially elsewhere.

For the open source community, the lesson is uncomfortable: build something successful enough, and the license you chose becomes your vulnerability. Whether the answer is better licenses, better business models, or better norms around cloud provider contributions, the current equilibrium clearly isn’t sustainable. Something has to give.