>
Open Source

OpenSearch is no longer the Elasticsearch fork and they know it

Five years after the Apache 2.0 fork, OpenSearch is having an identity conversation. The project started in 2021 as a community response to Elastic’s shift away from an open source license, and the original pitch was simple: keep the search and observability stack open. The new pitch, articulated by Bianca Lewis, the executive director of the OpenSearch Software Foundation, is more ambitious. OpenSearch is positioning itself as an AI data infrastructure layer, with its own roadmap, its own community, and a particular bet on what AI agents need from a search platform.

The interview aired at Open Source Summit India shortly after the project’s second OpenSearch Con in the country, and the conversation in the published version is lightly edited. A few of the answers frame the project’s strategy in ways that are worth examining, especially for anyone deciding whether OpenSearch belongs in their stack.

Is this still a fork?

The first question the published interview tackles is the obvious one. Five years on, is OpenSearch still tethered to Elasticsearch, or has it become its own product? Lewis was unambiguous: the project is independent now, focused on different strengths, and only broadly comparable to Elasticsearch for similar kinds of use cases.

Shared surface is shrinking. Communities, corporate backers, and engineering roadmaps have all diverged. Early-day overlap that made the fork an easy story is no longer the dominant story. Per the interview, downloads have crossed 1.7 billion, with 400 contributing companies, more than 3,000 contributors, and 15,000 OpenSearch stack users. None of those are market-share numbers, but they are the right shape of numbers for a project that has its own installed base.

Why the ELK brand still wins

The interview is honest about a problem. ELK Stack (Elasticsearch, Logstash, Kibana) is still the more recognisable brand among younger developers. The interviewer pushed on this, and the answer is a mix of philosophy and a 35-year-old choice in software licensing.

Foundation governance is the easy part. OpenSearch sits on a Linux Foundation governance model, and the foundation is a non-profit that nobody owns. Contrast with Elastic is concrete. Elastic owns its own stack, and even though the license has returned to open source, the company is still the holder of the trademark and the brand. For a developer who cares about who in the end controls the long-term direction of the platform, that is a real distinction.

Brand recognition is the harder part. Developers who learned search and observability in the last decade learned the ELK acronym first. Per the published interview, the weight of numbers (downloads, contributors, companies, stack users) is the cleaner way to establish the new brand. That is a longer argument, and one that most named-licensing debates run into. Whether the foundation governance story is the kind of story that survives a quick stack comparison at a developer conference is the real question.

The complexity and cost question

The most pointed question in the interview is whether OpenSearch is doing anything about the cost and complexity of running a full observability stack. Lewis answered yes, with caveats.

Launchpad is the complexity answer. It is a deployment tool that lets you set up an observability or search stack in a few minutes. Per the interview, the day-one experience is what open-source projects have historically struggled with, particularly on the observability side. Day-two, day-three, and day-four wins come from the fact that you own the platform and can customise it.

Cost is more honest. OpenSearch is free to download, but you still pay for the infrastructure and the operational time. The interview pivots to a longer argument about unifying the data layer: instead of running logs, traces, and metrics through three separate tools, you run them through OpenSearch and let the same data pipeline answer multiple questions. That is more cost-effective than the per-tool approach in some cases and a marketing argument in others.

Token economy is also an interesting but not yet proven practice. The interview argues that you can attach cost information to traces and logs and reason about service cost as part of root-cause analysis. That is a real feature in the OpenSearch project under various forms, but the question of whether it is the breakthrough that observability practitioners have been waiting for is still open.

Agentic AI readiness

Lewis makes the strongest claim about agentic AI. The argument is that OpenSearch is ahead of nearly every other platform in the world on fully integrated agentic AI, because the work started in the 3.5 release and the project has shipped two minor versions since then.

Concrete pieces on offer are a model-agnostic architecture (any AI model can connect), short-term agentic memory (so an agent remembers the context of its last week or two of work), and, with the 3.7 release, long-term agentic memory. Long-term memory is described in the interview as generally available, which is the strongest claim a feature can carry in a public roadmap.

Practical question is whether agentic memory as a feature is the right framing. Most agents that need to remember a conversation prefer to maintain their own short-term and long-term memory layer, and the value of having that inside the search platform is that the agent can recall data the platform already has. The pitch is plausible, but the evaluation is unfinished: nobody has published a benchmark that puts OpenSearch’s agentic memory against a separately built memory layer for cost, latency, or accuracy.

Vendor-owned open source and the Linux Foundation model

The interview closes with the most uncomfortable question, and the answer is the most honest one in the conversation. The question is whether the Linux Foundation model of vendor-forked open source projects (MariaDB, Redis, Elasticsearch, Terraform, OpenTofu) is fair to the original projects that the foundation ventures are built on top of.

Lewis offered a sympathetic without being assigned framing. Open core is a go-to-market strategy, it gets a community built, and then the community discovers that the largest customers are not being converted. The moment when the original vendor closes the source is the moment the community that built the foundation has to choose between staying and going. Per the closing line, the Linux Foundation model is nonprofit, nobody owns it, and profit is not the motive.

A reader who has watched this cycle play out repeatedly will notice something the interview does not say out loud. Pattern recognition says that the original project discovers that the foundation version is the version that the community actually wants, and the original company spends its energy on the proprietary value-add rather than the open-source core. That is not a problem the foundation can solve by staying neutral. It is the structural problem of selling open-source trust.

What to take from the interview

OpenSearch is doing the right things for a foundation-owned open-source project. Governance model is non-profit, the download base is real, the contributing community is large, and the engineering roadmap is shipping. The interview is a fair reflection of that.

Less-tested parts are the agentic AI claims and the cost-unification argument. Both are forward-looking, both are real engineering work, and neither has been independently benchmarked. Anyone deciding whether OpenSearch belongs in their stack should treat those pitches as roadmap, not as shipped value.

Bigger question the interview raises is whether the foundation model survives the agentic era. If agents are the dominant user of search and observability platforms in five years, the contract between a foundation and its community will look different. Linux Foundation has been here before, and the pattern is that the foundation survives by being the boring, dependable layer underneath whatever the next trend turns out to be. OpenSearch is betting that boring is enough.

Trade-offs

  • OpenSearch is foundation-owned, which is a real governance advantage. It is also a slower-moving organisation than a venture-backed competitor. The choice is the same one every foundation project makes.
  • “Completely independent” framing is half-true. Community is independent, engineering is independent, and roadmap is independent. Shared history with Elasticsearch is a real input to the design, and a future in which the two projects need to collaborate is not impossible.
  • Launchpad lowers the day-one cost. Day-three cost of running a production-grade observability platform is still yours to bear.
  • 3.7 long-term agentic memory is the most interesting feature on the roadmap. It is also the least battle-tested.
  • Linux Foundation model is a structural advantage for buyers. It is also a structural disadvantage for the people who work on the project, because the foundation cannot pay the same salaries a venture-backed competitor can.
  • Strongest claims in the interview (agentic AI readiness, cost unification) need independent evaluation. The claim that the project is shipping is well-supported; the claim that its roadmap is ahead is not.

Leave a comment