July 9th, 2024

OpenFeature: Standardizing Feature Flagging

The OpenFeature React SDK provides a vendor-agnostic API for feature flagging in software development. It aims to standardize feature flagging, support various languages, and promote community-driven development.

Read original articleLink Icon
OpenFeature: Standardizing Feature Flagging

The OpenFeature React SDK has been officially released, offering a vendor-agnostic API for feature flagging in software development. Feature flags allow teams to modify features or code paths without changing the source code. OpenFeature aims to standardize feature flagging, promoting community-driven development and avoiding vendor lock-in. As an open-source project under the CNCF, it supports various programming languages and works with different feature flag management tools. The SDK enables flexibility by allowing integration with multiple platforms and solutions, making it easier to switch between or consolidate tools. OpenFeature encourages industry collaboration and extension development, providing a common interface for feature flagging across the community.

Link Icon 7 comments
By @janosdebugs - 3 months
After reading the specs, this sounds like an awful lot of complexity for something that should be simple and low cost. The spec also seems to be very loosely defined, more like a recommendation than a spec. This means you'll likely have to integrate a library and that library will be the authoritative source of truth as far as the expected behavior is concerned.
By @lelag - 3 months
I don't know why I was expecting something relating to feature engineering and/or feature extraction in the context of AI research before I clicked...

Now I'm there, wondering why we need full blown frameworks to handle booleans in applications...

By @chambers - 3 months
I was excited for this standard a few years ago, but I've come to believe it's missing understanding of its domain.

For example, Dynamic Configs is an important and relevant concept yet it's only mentioned briefly in the team's meeting notes & blog. Similarly, the spec tries to define how an "experiment" is different from a feature flag, but ended up giving up and leaving their attempt as a rough draft https://openfeature.dev/specification/sections/tracking.

IMO, feature flagging is a red herring for the larger problem of feature control. That perspective is not defined, so I'm doubtful the proposed standard will integrate well with the more advanced use-cases of enterprises, e.g., experimentation.

By @salil999 - 3 months
I'm confused as to why this needs to be standardized? OTel makes sense because multiple applications can consume metrics and logs. Feature flags are typically contained within a company and they typically don't need to be transferred across to other places.
By @klysm - 3 months
I don't see any value in having this standardized. Different products need vastly different kinds of feature flagging for widely different reasons. Just build what you need when you need it!
By @prvt - 3 months
Sounds like if-else with extra steps.