Five years on, OpenSearch is stepping out of AWS's shadow

The number that decides the renewal is the contribution share

The figure a procurement team can put in front of a vendor is 72%. That is AWS's share of contribution activity across OpenSearch repositories in 2025-26, down from 91% in the project's first year, according to foundation figures provided to The New Stack. The same data puts Amazon-affiliated engineers at 71% of maintainers in the core repository, against 95% in April 2022.

Those two numbers are the ones that move a licence conversation, because they describe how much of the codebase one company still writes. A buyer weighing OpenSearch against an Elasticsearch renewal is not buying a search engine in the abstract; they are buying the right to keep running it if the vendor's priorities change. A contribution share that has fallen 19 points in five years is evidence the project no longer depends on a single sponsor's roadmap.

The governance change behind the numbers is dated. AWS announced OpenSearch in January 2021 after Elastic moved Elasticsearch and Kibana off Apache 2.0 to proprietary and source-available licences, and Elastic later added AGPL as an option without folding the fork back in. In September 2024 AWS transferred the project to the Linux Foundation, establishing the OpenSearch Software Foundation, which the foundation says means AWS could no longer close the project or change its licence.

Executive director Bianca Lewis told The New Stack the transfer also made commercial sense, because AWS earns revenue from compute rather than from owning applications, so growing OpenSearch long term was never part of AWS's plan. That is the vendor's own account of its incentive, and it is worth repeating in a call because it explains why the contribution share can fall without the project stalling.

Self-managed now outnumbers the managed service

The 2026 Open Data Infrastructure Report, published last month by the Linux Foundation and the OpenSearch Software Foundation, puts 60% of surveyed OpenSearch users on self-managed deployments in the cloud, up from 37% in 2024. Use of Amazon's managed OpenSearch Service rose from 44% to 48% over the same period. Self-managed has grown faster than the managed option, which is the opposite of what a fork owned by a cloud provider would predict.

For a cost model this matters because the two paths bill differently. A self-managed cluster is compute, storage and staff time on a bill the buyer already controls; the managed service is a per-resource line on an AWS invoice. The report does not publish a price for either, so the comparison has to be built from the estate's own instance hours rather than from a list rate, and the number to ask a vendor for is the per-hour rate for the instance families the cluster actually runs.

The survey also records the objection. Of 71 surveyed non-adopters, 24% cite vendor-neutrality concerns tied to AWS. That is a small sample and the report does not break it down further, but it names the thing a sceptical platform team will raise in the first meeting: the foundation is independent on paper, and the chair of its Technical Steering Committee is still an AWS employee.

What the governance arithmetic looks like

AWS holds 4 of 15 voting seats on the Technical Steering Committee, and AWS employee Andrew Ross was reelected chair in October. Four seats out of fifteen is not control, and the foundation's legal structure is what stops the project being closed or relicensed, but a chair plus the largest single block of maintainers is enough for a reader to ask what happens on a tied vote. The sources do not describe the voting rules, so that is a question for the foundation rather than a finding.

The honest reading is that OpenSearch has moved from a project one company could unilaterally steer to one where it holds a large minority and the chair. That is a different risk profile from January 2021, and a different one from a fully distributed project. A buyer who needs the stronger claim should ask the foundation for the current maintainer list per repository and the last twelve months of commit counts by employer, because the 72% figure is an aggregate across repositories and the core repository is where the 71% maintainer share sits.

None of this makes the managed service a bad buy. It makes the choice a question of which dependency the estate can carry: a single cloud's pricing and roadmap, or the operational load of running the cluster. The contribution figures tell you the second option is now viable in a way it was not in 2022.

The cost table, and a worked three-year example

The sources publish no list price for either path, so the table carries the figures that are published and marks the rest as quote-only. The one product number in the material is the release: OpenSearch 3.9 adds AI-focused search and retrieval features alongside performance and monitoring updates, which is the capability a buyer would otherwise price as a separate vector store.

Worked example: an estate running a self-managed OpenSearch cluster on cloud compute, sized to the search and retrieval load of a mid-size product, pays for instance hours, storage and the engineering time to patch and upgrade. Over three years the model has two moving parts, the instance rate and the headcount fraction, and neither is published by the foundation. What the sources do give is the direction of travel: 60% of surveyed users have already chosen that path, so the operational tooling and community answers for self-managed deployments are being written by more people than in 2024.

The managed service is the simpler line to forecast, because it appears as a per-resource charge on an existing AWS bill and needs no separate patching rota. Its exposure is the one the non-adopters named: pricing and roadmap sit with a company that also competes with the rest of the estate's cloud spend. The number to ask for on a renewal is the committed-use discount on the instance families behind the domain, not the on-demand rate.

What changes if volume doubles

Doubling indexed volume hits the self-managed path on storage and instance count, and hits the managed path on the per-resource line. Because neither rate is published in the sources, the model cannot say which grows faster in cash; it can say which grows faster in attention. A self-managed cluster at twice the size needs shard planning and a patching window that scales with node count, and that is the cost a finance business partner usually misses when the compute estimate looks cheaper.

The AI features in 3.9 change the volume question, because vector search and retrieval workloads are storage-hungry in a way keyword indexing is not. A team that would otherwise buy a separate vector store can fold that spend into the OpenSearch cluster, which improves the case for either path but especially for the self-managed one where the marginal cost is instance hours rather than a second product line.

If egress moves, the calculus shifts toward whichever path keeps queries inside one cloud region. The sources do not publish egress rates for either option, so the figure to request is the data-transfer charge for cross-region replication and for any read traffic that leaves the region. That line, not compute, is where a three-year search budget usually breaks.

What would change the answer

A shorter term favours the managed service, because the operational investment in a self-managed cluster pays back over upgrade cycles rather than over twelve months. A three-year term with a committed-use discount on the managed side, or a team that already runs Kubernetes and patching rotas, moves the answer the other way. The sources give no discount figures, so the comparison has to be run on the estate's own quoted rates.

A change in the governance numbers would change it too. If AWS's contribution share fell materially below 72%, or its maintainer share below 71%, the vendor-neutrality objection loses its factual basis and the 24% of non-adopters who cite it would be arguing against the data. If the share rose again, the reverse. The foundation publishes these figures, so they are checkable at each renewal rather than taken once.

The decision rule is narrow. An estate that wants a search platform with no single-vendor licence risk and can staff the upgrade cycle should price self-managed OpenSearch against its Elasticsearch renewal now, using the 60% adoption figure as evidence the operational path is well trodden. An estate that cannot spare the engineering time should stay on the managed service and negotiate the committed-use rate, while watching the contribution share as the leading indicator of how much leverage it has.