OpenFeature: Standardizing Feature Flagging

by alexzeitler • 2 years ago

55 11 2 years ago

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.

scarlson• 2 years ago

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.

salil999• 2 years ago

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.

antonyt• 2 years ago

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.

chambers• 2 years ago

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.

abrahms• 2 years ago

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.

lelag• 2 years ago

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

vladsanchez• 2 years ago

LOL

coold• 2 years ago

seems like you never used it, its a lot more than just booleans

klysm• 2 years ago

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!

prvt• 2 years ago

Sounds like if-else with extra steps.

OpenFeature: Standardizing Feature Flagging

Related Stories