Upstream-First: Why the OpenSearch LTS No-Fork Policy Is the Right Model for Enterprise Open Source

Commercial open source support has a structural problem that the OpenSearch LTS program is designed to solve. When a vendor offers paid support for an open source project, there is a persistent incentive to maintain a private patched branch — a version that paying customers get, and the community does not. It is not malicious; it is a rational response to a business model that monetises exclusive access to fixes. But it produces outcomes that are bad for both the community and, in the long run, for enterprise operators.

The OpenSearch LTS program makes a different choice. The no-fork policy — the requirement that all fixes developed for LTS versions be contributed back upstream — is not a philosophical preference. It is a condition of accreditation, enforced by the Foundation. This post explains why that matters technically and practically, and what it means for organisations choosing between commercial LTS support and other approaches.

When a commercial vendor maintains a private patched branch, several things happen over time. The private branch diverges from the public project at every patch that is not contributed back. This divergence is slow at first and accelerates — each private fix creates a delta that subsequent fixes have to account for, so the cost of re-merging grows with time. Eventually, the private branch and the public project are different enough that migrating between them, or evaluating security equivalence between them, becomes a significant engineering exercise.

For enterprise operators, this creates several concrete problems. Supply chain audits become harder because the software running in production is not the same artefact that the community has reviewed. Vulnerability assessments become ambiguous because a CVE disclosed against the public project may or may not apply to the private branch, depending on whether the vendor has already patched it and how the patch interacts with other private changes. And switching support providers becomes expensive because the new provider may be starting from a different codebase baseline.

None of this is hypothetical. It is the normal trajectory of commercial open source support when there is no structural incentive to contribute back.

The LTS program’s no-fork requirement changes the incentive structure by making upstream contribution a condition of continued accreditation rather than a discretionary act. Accredited providers cannot offer Foundation-approved LTS support while maintaining private patches. The two are mutually exclusive.

In practice, this means that every security fix and bug patch developed by any accredited provider for an LTS version goes through the standard OpenSearch contribution process — pull request, community review, merge to main, backport to the LTS branch. The fix is visible to the community, reviewable by anyone, and available in the public codebase. There is no proprietary delta between what a paying customer gets and what the public project provides.

If an organisation running one provider’s LTS support decides to switch to another accredited provider, they are switching support contracts, not codebases. The version of OpenSearch they run is the same one the community maintains. The transition cost is contractual, not technical.

Every fix applied to an LTS version under the program is a public commit in the OpenSearch repository. Compliance teams can point to specific commits for specific CVE remediations. Security teams can review the fix, not just take the vendor’s word for it. This is a fundamentally different evidence standard to “our vendor patched it” with no further detail.

Organisations that do not use commercial LTS support still benefit from the program because the fixes that accredited providers develop flow back into the community release. The security work done under commercial contracts strengthens the project for everyone. This changes the relationship between commercial support and community open source from extractive to contributory — which is the model that makes open source ecosystems healthy over time.

The Foundation monitors compliance with the no-fork requirement as part of ongoing accreditation status. This is not purely self-reported. Because all contributions must go through the upstream process, divergence between what an accredited provider ships and what exists in the public codebase is detectable. A provider who develops private patches without contributing them upstream creates a verifiable discrepancy. Sustained non-compliance would result in loss of accreditation — which means loss of the right to offer Foundation-approved LTS support and loss of access to the pre-disclosure vulnerability notification process.

That last point matters: the pre-disclosure notifications that allow accredited providers to begin patch work before a CVE is public are contingent on being trusted participants in the Foundation’s security coordination process. A provider who misuses that access by not contributing fixes back upstream would not remain part of that process.

The no-fork policy reflects a broader architectural principle worth stating explicitly: the LTS program is designed to make commercial support and open source development mutually reinforcing rather than in tension. The program’s value to enterprise operators comes from the Foundation’s credibility and the community’s ongoing work. If commercial support hollowed out the community project, the foundation on which the program rests would erode. Upstream-first is how the program avoids that outcome.

For operators evaluating LTS support, this is not an abstract governance point. It is the mechanism that makes the vendor-neutral framing of the program substantive. You are not just choosing between vendors who have signed up to a set of principles — you are choosing providers whose commercial model depends on those principles being enforced.

Eliatra has been contributing to OpenSearch upstream since the project’s earliest days. Our engineers maintain the Security and Operator repositories — the repositories most directly involved in the vulnerability patching work the LTS program formalises. The no-fork requirement of the LTS program is consistent with how we have always worked. Our commercial support has never depended on withholding fixes from the community, and the LTS accreditation process formalises that approach as an industry standard.

Want to understand how upstream-first LTS support would work for your OpenSearch deployment? Get in touch with the Eliatra team at https://eliatra.com/opensearch-lts/