Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenFeature – a vendor-agnostic, community-driven API for feature flagging

github.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#41

Post by adontz »

vault wrote: post #22
adontz wrote: post #21

A little story from personal experience. Most people think of feature flags as boolean on/off switches, maybe per user on/off switches. If one is testing shades of colors for a "But Now!" button that may be OK. Regarding more complex tests my experience is that there are not a lot of users who tolerate experiments. Our solution was to represent feature flags as thresholds. We assigned a decimal number [0.0, 1.0) to e…

From your naming, I would have done the opposite :) Start with courage 0.05 and show experiments whenever it is greater than the threshold. To enable a feature for everybody, you lower the threshold to 0. How did you measure "experiment tolerance"?

Yeah, naming was bad. Courage 0 is maximum courage.

>> How did you measure "experiment tolerance"?

Feedback from CS mostly. No formal method. We tried to survey clients to calculate courage metric, but failed to come up with anything useful.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#42

Post by withinboredom »

adontz wrote: post #38
withinboredom wrote: post #23

Earlier quoted context omitted.

Interesting. At one place I worked, employees were excluded from experiments (they had to enable the flag personally to see them) by default. At one point, we had so many experiments that literally nobody except employees were using "that version" of the software. Everyone else was using some slightly different version (if you counted each feature as a version), and there were thousands and thousands of versions in t…

>> How do you deal with the bias from your 'more courageous' people? That's a great question. We had no general solution for that. We tried to survey people, but results were inconclusive, not statistically significant.

I mean that "courageous" people are more likely to take risks and accept new features and thus probably more likely to be attracted to novelty (see: Novelty Effect) and require longer experiments to understand the actual impact.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#43

Post by lucideer »

adontz wrote: post #21

A little story from personal experience. Most people think of feature flags as boolean on/off switches, maybe per user on/off switches. If one is testing shades of colors for a "But Now!" button that may be OK. Regarding more complex tests my experience is that there are not a lot of users who tolerate experiments. Our solution was to represent feature flags as thresholds. We assigned a decimal number [0.0, 1.0) to e…

This seems like it would skew the data significantly for certain use-cases.

Unless you're feature flagging to test infra backing an expensive feature (in which case, in a load-balancer / containerised world, bucketing is going to be much a much better approach than anything at application level), then you most likely want to collect data on acceptance of a feature. By skewing it toward a more accepting audience, you're getting less data on the userbase that you're more likely to lose. It's like avoiding polling swing states in an election.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#44

Post by aepfli »

DandyDev wrote: post #35

Are there any big feature flag SaaS vendors that support this? Like LaunchDarkly, Flagsmith, Unleash etc?

Yes there are, as I am part of the openFeature community, I have to point you to https://openfeature.dev/ecosystem where you'll see all kinds of providers which are supported (some officially, some by the community)

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#45

Post by adontz »

skeeter2020 wrote: post #29
adontz wrote: post #21

A little story from personal experience. Most people think of feature flags as boolean on/off switches, maybe per user on/off switches. If one is testing shades of colors for a "But Now!" button that may be OK. Regarding more complex tests my experience is that there are not a lot of users who tolerate experiments. Our solution was to represent feature flags as thresholds. We assigned a decimal number [0.0, 1.0) to e…

This seems really complex, specifically in the area where I find product, CS & marketing least likely to want it: targeting and controlling their audience. Sounds like a cool thought experiment, fun and challening to implement and not really practical or useful. If you have a huge userbase and deploy very frequently FFs are great for experiments, but for the rest of us they're primarily a way to decouple deploys from…

Yes, it's not a good solution. Targeting was missing, good catch. I've just shared an unusual experience to inspire further experimenting.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#46

Post by jacobr1 »

random_kris wrote: post #20
hobofan wrote: post #17

Earlier quoted context omitted.

In it's simplest incarnation, yes it could be just a single DB table with boolean flags. However there are a lot of connected needs that most real world-usages run into: - Per-user toggles of configuration values - Per-user dynamic evaluation based on a set of rules - Change history, to see what the flag value was at time of an incident - A/B testing of features and associated setting of tracking parameters - Should…

In microservice world. Do you want to track features in each service or have a source of truth using flagd I prefer central source of truth

In a microservice world obviously you'd have a feature-flag service. But you still have a build/buy consideration.

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#47

Post by dabeeeenster »

DandyDev wrote: post #35

Are there any big feature flag SaaS vendors that support this? Like LaunchDarkly, Flagsmith, Unleash etc?

Hey there - one of the Flagsmith founders here - yes we are supporting it, building adapters for our SDKs and I'm on the CNCF project governance board.

We've got the core functionality pretty much down now, and so there's some more interesting/challenging components to think about now like Event Tracking (https://github.com/open-feature/spec/issues/276) and the Remote Evaluation Protocol (https://github.com/open-feature/protocol)

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#48

Post by vhodges »

I am looking to maybe support this in

https://github.com/vhodges/ittybittyfeaturechecker

probably via https://openfeature.dev/specification/appendix-c (I don't have time to maintain a bunch of providers).

We are evaluating new solutions at work and OpenFeature is something we're interested in. (I did the home grown solution that's in use by one product line)

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#49

Post by oddevan »

webda2l wrote: post #28

A coding world with more standardization will be better world. I met this week "Standardized Interface for SQL Database Drivers" https://github.com/halvardssm/stdext/pull/6 by example then https://github.com/WICG/proposals/issues too. Huge work to get everybody on the same page (About my previous example, it's not well engaged by example https://github.com/nodejs/node/issues/55419 ), but when done and right done, it'…

I was thinking of PSR interfaces when I was reading this!

Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging

#50

Post by remram »

adontz wrote: post #21

A little story from personal experience. Most people think of feature flags as boolean on/off switches, maybe per user on/off switches. If one is testing shades of colors for a "But Now!" button that may be OK. Regarding more complex tests my experience is that there are not a lot of users who tolerate experiments. Our solution was to represent feature flags as thresholds. We assigned a decimal number [0.0, 1.0) to e…

What does "tolerating experiments" mean? If they can tell it's an experiment, then isn't your change bad?

Do you mean "tolerate change"? But then you still eventually roll out the change to everyone anyway...

Or do you mean that users would see a different color for the "buy now" button every day?

From a purely statistical point of view, if you select users which "tolerate" your change before you measure how many users "like" your change, you can make up any outcome you want.

Post reply on HN