OpenFeature is a CNCF (Cloud Native Computing Foundation) open standard that defines a vendor-agnostic API for feature flag management. It specifies how applications evaluate flags, pass evaluation context, and handle provider lifecycle events, so your application code isn't coupled to any single feature flag vendor's SDK.
The standard matters because feature flag SDKs have historically been proprietary. Every vendor ships its own client library with its own API surface, initialization flow, and context model. If you adopt one vendor's SDK across your codebase and later need to switch, you're looking at hundreds or thousands of call sites to rewrite. OpenFeature eliminates that lock-in by putting a standard interface between your application code and the vendor-specific provider underneath.
How does OpenFeature work?
The architecture has three layers.
The API. Your application code calls openfeature.getClient().getBooleanValue("flag-key", defaultValue, context). This API is the same regardless of which vendor is providing the flag values. It supports boolean, string, integer, float, and object return types.
The provider. Each vendor implements an OpenFeature provider that translates the standard API calls into their platform-specific flag resolution logic. When you initialize OpenFeature, you register a provider. Switching vendors means changing the provider registration, not rewriting every flag evaluation call.
The evaluation context. A standardized object that carries the targeting attributes (user ID, device type, country, custom properties) to the provider. The provider uses this context to evaluate targeting conditions and return the correct variant.
OpenFeature also defines hooks (middleware that runs before or after flag evaluation) and events (lifecycle signals for provider readiness, errors, and configuration changes). The full specification is maintained as a CNCF project with SDKs for Java, Go, JavaScript, .NET, Python, PHP, Ruby, Swift, and Kotlin.
What is Confidence's relationship with OpenFeature?
Confidence donated the iOS and Android OpenFeature provider SDKs to the CNCF. These aren't wrappers around a proprietary SDK. They're first-class implementations of the OpenFeature standard, maintained as open source contributions to the CNCF project.
Every Confidence SDK implements the OpenFeature standard. Your flag integration code uses the OpenFeature API, and Confidence's provider handles the resolution underneath. This means the flag evaluation calls in your codebase aren't Confidence-specific. If you ever change platforms, you swap the provider, not the integration code.
This is a deliberate architectural choice. The Confidence manifesto states that you should never outgrow your experimentation platform, but it also reflects a belief that vendor lock-in through proprietary SDK surfaces is the wrong way to earn a customer's continued use. Confidence earns it through the quality of the platform, not the cost of leaving.
Why does an open standard matter for feature flags?
Three practical reasons.
Migration cost drops to near zero. Switching from Vendor A to Vendor B means changing one provider registration, not rewriting thousands of call sites. For companies evaluating experimentation platforms, this removes the single biggest barrier to switching: the accumulated SDK integration debt.
Multi-provider setups become possible. A large organization might use one provider for server-side flags and another for client-side, or migrate incrementally by running two providers in parallel. OpenFeature's provider model supports this cleanly.
Community-maintained quality. Because the specification is vendor-neutral and CNCF-governed, the SDK implementations benefit from contributions across the ecosystem. Confidence's donated iOS and Android providers are maintained to CNCF standards, not just Confidence's internal bar.