Feature flags are a way for engineering teams to control which users see which features, independently of whether that code has been deployed. A team can ship new code to production but keep the feature switched off, then turn it on for a small group of users first, watch what happens, and roll back instantly if something goes wrong—no redeployment required.
As flag usage grows, most teams reach for a vendor to manage them. The vendor ships an SDK, your services call that SDK directly, and before long, that SDK is threaded through your codebase across every team that evaluates a flag.
The problem is that every one of those call sites is now tied to that vendor. Switching to a different provider becomes a migration project: It means finding and replacing SDK calls across every service that uses flags, which involves rewriting code, retesting, and redeploying across your entire stack. This SDK dependency problem is what OpenFeature was designed to address.
What OpenFeature is, and what it solves
OpenFeature is a CNCF (Cloud Native Computing Foundation) open standard that decouples your feature flag logic from the vendor providing it. Instead of calling a vendor SDK directly, your code calls the OpenFeature API. The vendor sits behind a provider interface defined by OpenFeature.
Flag adoption tends to spread organically across teams. One team picks a vendor, the SDK gets embedded, and other teams follow. The more services that evaluate flags, the more deeply that vendor SDK is embedded across your stack, and the harder it becomes to swap it out.
OpenFeature addresses this by standardizing how your code talks to a flag provider. Your application code stays consistent regardless of which vendor sits underneath it. Swapping providers becomes a configuration change rather than a codebase-wide migration.
In short, OpenFeature abstracts the SDK from the vendor. This is what's known as "feature flag portability."
What OpenFeature doesn't solve
Managing feature flags at scale requires more than portability; it requires governance. OpenFeature has no concept of audit trails, approval workflows, role-based access controls, or flag lifecycle management.
For teams operating at scale—especially in regulated industries like financial services, healthcare, software technology, logistics, and insurance—those gaps matter because:
- Flags that never get retired accumulate as technical debt, and as AI-assisted development raises the rate at which flags are created, that debt compounds faster.
- Ownership that isn't tracked becomes a support and incident response problem.
- A flag change that bypasses an approval workflow is an audit finding.
These are platform-level concerns that a portability standard isn't designed to address. Without a governance layer on top, flag operations at scale become a source of potential production risk, compliance exposure, audit liability, and engineering overhead.
JB Hunt, a leading logistics provider, cut feature experimentation time from three months to one month and saw a 90% reduction in MTTR after moving to a governed feature management process.
Adding governance on top of OpenFeature
Most teams don't start with a vendor. They build a homegrown flag system that works well enough until the team grows, the flags accumulate, and the operational gaps become too costly to patch around. At that point, most reach for a commercial solution. That's when the SDK dependency problem takes root.
CloudBees Feature Management (CloudBees FM) supports OpenFeature, with provider SDKs across major languages. Your code can call the OpenFeature API instead of a proprietary SDK, keeping your flag implementation portable and vendor-agnostic.
On top of that, CloudBees FM adds the enterprise controls that compliance-heavy teams need: immutable audit trails, mandatory approval workflows, environment-level permissions, and flag lifecycle policies that prevent sprawl from compounding over time.
Frequently asked questions about OpenFeature
Is OpenFeature production-ready?
Yes. OpenFeature is a graduated CNCF project, which means it has met the foundation's standards for stability, adoption, and community support. It has provider implementations for most major feature-flag vendors and supports the SDKs that most engineering teams already use.
Does adopting OpenFeature mean I have to change how flags are evaluated in my code?
Minimally. Your flag evaluation logic stays the same; you still call a function that returns a value. The change is that the call goes to the OpenFeature API rather than directly to a vendor SDK. For most teams, this is a small refactor, not a rewrite.
Can I use OpenFeature with a homegrown flag system?
Yes, if you build or use an existing community-contributed provider for it. OpenFeature's provider interface is extensible. That said, most teams building their own flag systems are already dealing with the operational gaps that homegrown solutions tend to leave unaddressed. Portability becomes less valuable if the underlying system still lacks those controls.
If I'm already using a vendor SDK, do I need to migrate everything to OpenFeature at once?
No. Most teams introduce OpenFeature incrementally; new services adopt it first, and existing services migrate when they're already being touched for other work. You don't have to flip the switch across your entire stack at the same time.
