Introduction
In the modern, fast-paced world of software development, feature flags have become a developer’s reliable partner. They let teams roll out changes incrementally and reduce the risk of launching new features. Since feature flags sit at a crucial juncture in your code, it’s often hard for teams to move away from their current vendor, after all, why change something that’s already working? But this has also led to a lack of standardization, with every vendor offering their own SDKs that must be used in specific ways. OpenFeature solves this!
What is OpenFeature?
OpenFeature, as you probably must have guessed, is an open specification for feature flags. It provides a common interface for feature flag providers, allowing developers to switch between different providers without changing their code. This makes it easier to move between providers or even write your own provider. Similar to OpenTelemetry, OpenFeature is a Cloud Native Computing Foundation incubated project that makes sure that the specification is vendor-neutral, consistent, and extensible.
Why OpenFeature Matters?
Standardization is the key! OpenFeature has SDKs for most popular technologies like Python, Go, TypeScript/JavaScript, Java, etc. These SDKs are vendor-agnostic. The vendors bring in their own providers which makes it super easy to switch between vendors or even use multiple vendors since OpenFeature has Multi-Provider support. OpenFeature is CNCF incubated project hence it benefits from the improvements and broader support from the community.
FFlags & OpenFeature
FFlags is one such vendor. Except it doesn’t have its own provider. FFlags rely on OpenFeature Remote Evaluation Protocol (OFREP) providers. Many vendors do local evaluation for a feature flag which could be good when it comes to high availability as the config is cached locally but it leaves larger SDK footprint as full rules engine is required. It also becomes an overhead for the vendors to maintain the evaluators for each technology. OFREP on other hand gives spec for serving the flags through its provider and the evaluation happens on the FFlags end remotely. With this approach, the FFlags system can also log every flag evaluation which leads to better analytics and experimentation (Coming on FFlags very soon!).
Inference
If you’re building software and use feature flags, or plan to you should care about OpenFeature. Whether you are a startup experimenting with rapid releases, an enterprise aiming for robust governance, or a team who cares about Vendor-neutrality. OpenFeature is a standard you should adopt.