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.
That's the nature of having existing players with significant market share but no standardized spec. OTel was/is in the same boat where in order to be a successful project, first you have to integrate with the products orgs are already using.
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.
Just mentioning that tracking isn't left as a rough draft, but rather it's being actively worked on. For reference, eBay uses OpenFeature for their experimentation tooling.
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.
OTel made sense because there were multiple observability vendors eager to lock you in with proprietary formats and SDKs. The motivation behind OTel is to instrument once and ship anywhere, whether your vendor is Datadog, Splunk, Sentry, or whatever.
This seems to be the same thing for feature flags, because these days people are farming FF management out to vendors like LaunchDarkly.
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!
Readit News
Now I'm there, wondering why we need full blown frameworks to handle booleans in applications...
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.
This seems to be the same thing for feature flags, because these days people are farming FF management out to vendors like LaunchDarkly.
Deleted Comment