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

51–60 of 67 posts

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

#51

Post by ahtihn »

martypitt wrote: post #9
abrahms wrote: post #4

Earlier quoted context omitted.

Forgive my ignorance, but what should it be doing instead?

Lombok is a very divisive framework in Java, with strong opinions on both sides. Given that, it's a bold choice to include Lombok in a library that other developers will pull into their stack - it's likely to make this a non-starter from those in the 'no' camp. As Lombok is just compiler sugar, when building an SDK for other developers, it's probably less alienating to just write the boilerplate that Lombok saves you…

Lombok is a compile-time dependency. Consumers of a library using lombok don't need to depend on lombok, so I don't see why it would matter?

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

#52

Post by j45 »

remram wrote: post #50
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 use…

I suspect it’s because some users will actually be pioneers and early adopters vs believing they are.

This kind of threshold adds some flexibility into the subjectivity of finding the best cohort to test a feature with.

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

#53

Post by j45 »

adontz wrote: post #40
vasco wrote: post #24

Earlier quoted context omitted.

> User courage was 0.95 initially and could be updated manually. We tried to regenerate it daily based on surveys, but without much success. Based on this ending, the courage bit sounds clever but is misguided. It adds complexity in a whole other variable, yet you have no way of measuring it or even do a good assessment. I thought you were going to describe how you calculated courage based on the statistical usage of…

Mostly functional changes. Like deploying a new parser, which may not support all the old files. There were users which will contact customer support in panic stating that their life is ruined by this change and there were users who's like that fixed by next quarter.

What’s important is if it worked for you and your audience.

There’s no standard requiring something to work for everyone, and it being less value if it isn’t.

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

#54

Post by j45 »

siva7 wrote: post #25
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…

Sounds like an overengineered solution to something that can be solved as simple as with a checkbox "i would like to get access to experimental features" in the UI.

Getting one or a few new features is one thing, getting too many might be too much.

Some granularity and agency for the user is valuable. Maybe let them pick everything as a whole or a few features at a time.

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

#55

Post by j45 »

hobofan wrote: post #17
echoangle wrote: post #16

Earlier quoted context omitted.

But why do you need an external service for that? Isn’t that basically a single DB table with a name and an on/off value for each flag (or maybe an integer for multiple options)?

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…

Great summary. The more parties involved with more and more configurations the more management of details is needed.

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

#56

Post by remram »

j45 wrote: post #52
remram wrote: post #50

Earlier quoted context omitted.

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 use…

I suspect it’s because some users will actually be pioneers and early adopters vs believing they are. This kind of threshold adds some flexibility into the subjectivity of finding the best cohort to test a feature with.

Where the best cohort to test with is the one that agrees with you...

You can call this measure "courage" but that is not actually what you are measuring. What you measure is not that different from agreement.

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

#57

Post by zellyn »

DandyDev wrote: post #35

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

LaunchDarkly has a mix of OpenFeature providers they wrote, and quite reasonable community-contributed ones, depending on language. They are also very actively engaged with OF in meetings, discussions, etc.

(We are a big LD user at work.)

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

#58

Post by gjvc »

gjvc wrote: post #31
sabedevops wrote: post #5

Where is the tldr? Anyone familiar…what does this do and why do we care about it being standards based?

the laziness on this site never ceases to amaze

and the use of "we" to somehow give the impression that this person speaks for everyone

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

#59

Post by jonathannorris »

hobofan wrote: post #18
MeteorMarc wrote: post #6

Martin Fowler about feature flags: https://martinfowler.com/articles/feature-toggles.html

No, that is Pete Hudgson on martinfowler.com. Most articles on martinfowler.com haven't been written by Martin Fowler himself in years. It's best thought of as a publishing venue for Thoughtworks.

Pete is a great guy, also on the OpenFeature governance board :)

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

#60

Post by andrewdmaclean »

DandyDev wrote: post #35

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

Hey there! Andrew here, Community Manager for OpenFeature and DevRel lead at DevCycle. We (DevCycle) have worked hard to ensure an OpenFeature Provider is available for every language supported by OpenFeature and for which we have an SDK (https://docs.devcycle.com/integrations/openfeature)
Post reply on HN