OpenFeature: Standardizing Feature Flagging

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.

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...

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.

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.

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!

Sounds like if-else with extra steps.