OpenFeature: a vendor-neutral API for feature flag evaluation

A specification, not a library

OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution, and this repository describes the requirements and expectations for OpenFeature.

That is the whole scope. There is no code to install here, no client library, no provider implementation. What the repository holds is the written contract that a flag client and a flag provider are expected to satisfy, so that the same application code can be pointed at LaunchDarkly, or at an in-house evaluation service, without changing.

The primary language being Gherkin is a hint about the shape of the project rather than an accident. The specification is behavioural, expressed as requirements that describe what a client must do when a flag is evaluated, and the tooling parses those requirements rather than executing them.

The project is Apache-2.0 licensed, the home page is openfeature.dev, the default branch is main, and the last push to the repository was on 2026-10-14. The recent releases are v0.9.0 from 2026-07-29, v0.8.0 from 2024-03-11, and v0.7.0 from 2023-09-08, so the version numbers track the specification rather than a shipped package, and there is a gap between v0.8.0 and v0.9.0 that suggests the release cadence is driven by the pace of the specification work rather than by code changes.

The six design principles, and what they rule out

The design principles section lists six constraints the specification must be designed with, and together they say a lot about what kind of standard this is.

Compatibility with existing feature flag offerings. Simple, understandable APIs. Vendor agnosticism. Language agnosticism. Low or no dependency. And extensibility.

The compatibility principle is the one that constrains the most. A specification that only a greenfield implementation could satisfy would be useless in practice, so the requirement is that the specified API has to fit the feature flag products that already exist, which is why a vendor-neutral layer ends up looking like a thin abstraction rather than a reimagined flag system.

Vendor agnosticism and language agnosticism together are what make the project a standard rather than a library. The point of a language-agnostic specification is that a Go team, a Java team, and a TypeScript team can all evaluate a flag the same way, which is what lets a company standardise on one evaluation semantic across a polyglot estate.

The low or no dependency principle is the one with a real engineering consequence. An SDK that drags in a large dependency tree is a liability for a library that most applications will add to every service, so the specification pushes implementations towards something a flag client can be built on without a framework behind it.

The SDK section states the split explicitly. The OpenFeature SDK provides a mechanism for interfacing with an external evaluation engine in a vendor agnostic way, and it does not itself handle the flag evaluation logic. That sentence prevents a common misreading, where people expect the SDK to contain a local fallback evaluation and a cache, which are provider concerns.

An up-to-date SDK compatibility overview is published on the site, which is the document to check before choosing an implementation.

Parsing the prose into requirements

The tooling section is the most distinctive part of the project, because it treats the specification as a document that a program consumes.

The specification complies with RFC 2119, the standard that gives words like must, should, and may their normative force, and it seeks to conform to the W3C QA Framework Guidelines, the framework for writing technical specifications. Some basic tooling, donated by Diego Hurtado, has been employed to parse the specification and output a JSON structure of concise requirements, highlighting the particular RFC 2119 verb in question.

So the requirements are extracted from the Markdown by a Python script, and each requirement carries the verb that gives it its force. That is a more useful machine-readable artefact than a hand-maintained list would be, because the JSON is generated from the prose and cannot drift away from it.

The workflow is short. To parse the specification, you type make. The generated JSON files appear as siblings to any of the markdown files in the /specification folder.

The lint target makes the pipeline a gate rather than a one-off. It runs a Python script that lints the JSON output against specification.json, then markdownlint over the markdown files, then markdown-link-check over the README and the specification files. The link check is the one that matters most in practice, because a specification that links to a specification or a provider document that has moved is a specification that people cannot follow.

The repository also carries a .specignore, which marks the parts of the tree the tooling is allowed to ignore, and a specification.json at the top level, which is the checked-in version of the parsed output.

The style guide, because the prose is the artefact

The style guide is short, and each rule exists because the specification is read by people and parsed by a tool at the same time.

Use code blocks for examples, and the code blocks should be pseudocode rather than any particular language, but should be vaguely Java-esque. Use conditional requirements for requirements that only apply in particular situations, such as particular languages or runtimes. Use sentence case in ticks when identifying entities outside of code blocks, so `evaluation details` rather than `EvaluationDetails`. Do not place line breaks into sentences, and keep sentences to a single line for easier review. String literals outside of code blocks should be in both ticks and double quotes, so a literal like PARSE_ERROR is written in ticks and quotes. Use Title Case for all titles. And use the imperative mood and passive voice.

The single line rule is the one that surprises people, and the reason given is reviewability. A diff that changes one line of prose is easy to review, and a diff that reflows a paragraph because someone edited the line above is not. For a document where every sentence is a requirement that someone might implement against, that is a sensible constraint.

The pseudocode rule is the other one with teeth. Because the examples are not valid in any language, they cannot be executed and cannot drift out of sync with a real implementation, and the vaguely Java-esque requirement is there to make the examples readable by the people who will read them, which is the JavaScript and Java and Go developers the specification is trying to serve.

The repository layout matches this. There is a specification/ directory with the Markdown documents, a tools/ directory holding the Python parser and the JSON linter, and the Makefile that ties them together with the markdown tooling, which is installed with npm ci into node_modules.

What the specification deliberately leaves to providers

There is one design decision that shapes how a team should read this project, and it is the division mentioned in the SDK section.

The specification defines the API, the lifecycle of an evaluation, the shape of the metadata a provider returns alongside a value, and the error handling behaviour. It does not define what a provider actually does when the evaluation service is unreachable, whether there is a local cache, how targeting rules are expressed, or how a flag is rolled out as a percentage. Those are the provider's business, and different vendors will do them differently on purpose, because that is where the differentiation lives.

This is why a conformance-oriented specification can be useful even though the ecosystem is young. The application code path is the same everywhere, so when a team swaps providers the change is in configuration rather than in code, and the semantics of a boolean evaluation do not shift underneath the application.

The governance arrangements are worth noting too. There is a public roadmap project on GitHub, a contributing guide in the community repository, a Slack channel under the CNCF, a CII Best Practices badge, and a CODEOWNERS file in this repository, which is how a document like this is reviewed. The specification is community driven, which is the point of it, and the process artefacts are the evidence that the process exists.

The project also has a release-please-config.json, a release-please-manifest.json, a renovate.json for dependency updates, and a version.txt, so the specification version is tracked in the repository rather than only on the releases page.

Editorial conclusion

Adopt the OpenFeature specification if you are building or choosing a feature flag client and want the evaluation semantics to be the same regardless of which flag vendor sits behind it. Do not adopt it expecting a working library, because this repository contains requirements rather than an implementation. Verify first that the SDK you plan to use declares conformance with the specification version you are targeting, since the spec has moved through several numbered revisions.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-feature/spec on GitHub
3. Project website
4. README
5. Releases