Skip to main content

OpenFeature Adoption Story

· 4 min read
Liran Mendelovich

Our team recently needed to use one of the largest feature management cloud services. This service has a documented SDK with usage guidelines. Thinking about how to define the exposed interfaces, while keeping it simple and generic, we started doing some research, and encountered OpenFeature. Gladly, the mentioned feature management cloud service has already created an OpenFeature provider. Let me explain why and how it was adopted.

Why Feature Management was needed

Our product needed a solution for feature flags:

  • providing a gradual release mechanism and a simple way to define target audiences such as target group or split release
  • Using feature flags for dynamic configuration values which can be changed in runtime dynamically without needing for a new release deployment.
  • Ability for A/B testing - can be done via feature for specific region, specific users, etc.

Why OpenFeature was chosen

While keeping it simple and generic, we had a few considerations:

  • What to name the methods?
  • How to do provide information for error handling ?
  • What response structure to define ?
  • How to define properties passed to the methods ?

Because OpenFeature is an open standard, we felt confident in the way things are defined, and it answered all of the above questions for us.

Feature Management Cloud Service Provider Implementation For OpenFeature

Although the provider implementation is used transparently, as it is open sourced, we explored its implementation.
What we saw is that the provider implementation is very short and simple, acting like a "bridge" from OpenFeature to the feature management cloud service specific vendor SDK which already exists.
This tells me that the OpenFeature standard makes sense.

How OpenFeature was adopted

As for this context OpenFeature can be treated as a "bridge", it was used accordingly:

  • OpenFeature provider initializer was added.
  • Generic OpenFeature client wrapper was created.


As our provider was fetching feature flags configuration and receiving real-time configuration changes, we needed to know its status and provide an alert on scenarios like service is down or communication failure. When adoption was done, OpenFeature did not support that functionality. However, OpenFeature recently added Events. Together with provider events implementation, it could have given us this functionality. To overcome the missing events enhancement, we implemented it directly via provider abilities. It did cause some mix between OpenFeature and vendor specific implementation.


A common action is provider initialization. As it was vendor specific, it was done by provider call implementation.
OpenFeature recently added Initialization to the spec. This could have made it a more standard implementation.

Fetching flags

We used an option for fetching all enabled flags from the feature management service. This was not included in OpenFeature at the time, see example at Flag Retrieval discussion.

SDK used functionalities

OpenFeature SDK has several used functionalities. What we used for our case:

  • Evaluation via OpenFeature Client (getBooleanEvaluation with context and similarly for other types)
  • Initialization - see Initialization
  • Events - see Monitoring
  • Fetch all flags - see Fetching flags

Features Management SDK - example flow

sequenceDiagram participant SDK as SDK (server-side) participant features as Features Service actor request as User Request participant developer as Developer participant metrics as Metrics Provider note left of SDK: initialize rect rgb(30,144,255) note left of SDK: OpenFeature method end SDK->>features: fetch config https://... rect rgb(127,255,0) features->>SDK: Feature Flags configuration JSON end note left of SDK: save config in cache request->>SDK: getBooleanEvaluation rect rgb(30,144,255) note left of SDK: OpenFeature method end SDK->>request: true/false from cache SDK->>features: <stream> fetch config changes events https://... features->>SDK: OK note left of features: fetch config changes responses developer->>features: Change feature flag value features->>SDK: Changed event SDK->>features: fetch config https://... rect rgb(255,0,0) features->>SDK: Error end rect rgb(30,144,255) note left of SDK: OpenFeature Error event end SDK->metrics: Features Service status=Error request->>SDK: getBooleanEvaluation SDK->>request: true/false from cache


High Level Adoption

  • Main functionality used is for evaluating a feature flag value, which fit our needs.
  • Adopting OpenFeature flag required adding OpenFeature SDK dependency and using it.


Some thoughts raised during the adoption:

  • Feature Flags Configuration
    Considering this as the provider configuration of feature flags, e.g.
    feature2=enabled by 50% split
    feature4=enabled by customerId=4
    This configuration can be represented as a scheme.
    Perhaps this configuration scheme could be implemented as part of the standard, adding import/export configuration across vendors? See Slack discussion and example flagd-definitions.
  • Events - see Monitoring
  • Fetch all flags - see Fetching flags
  • Flags registration
    Does the spec consider for some providers to expose initial flag registration via their SDK?