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
OpenFeature – a vendor-agnostic, community-driven API for feature flagging
31–40 of 67 posts
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#32A 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.
I'd go with that option too. I don't think users want to be surprised with being experimented on. Some users could take it worse than others.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#33A 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…
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…
> 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
Was this at Spotify by any chance? :)
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#34Speaking as an open-source feature flag 'vendor' (https://github.com/flipt-io/flipt), the OpenFeature organization has been a joy to work with. They are very welcoming of new contributors (e.g., implementing a provider SDK in a new language).
If you're interested in this space I'd recommend lurking in their CNCF Slack Channel https://cloud-native.slack.com/archives/C0344AANLA1 or joining the bi-weekly community calls https://community.cncf.io/openfeature/.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#35Are there any big feature flag SaaS vendors that support this? Like LaunchDarkly, Flagsmith, Unleash etc?
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#36Earlier 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…
> 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 Was this at Spotify by any chance? :)
[deleted]
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#37Earlier 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…
> 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 Was this at Spotify by any chance? :)
No.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#38A 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…
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.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#39A 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.
I respectfully disagree. Depends on number and severity of experiments. Comparing two decimals is really not harder than checking a boolean, still a single "if". I do not see much over-engineering here.
Re: OpenFeature – a vendor-agnostic, community-driven API for feature flagging
#40A 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…
> 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.