OpenFeature – a vendor-agnostic, community-driven API for feature flagging
24 comments
·October 25, 2024adontz
withinboredom
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 total.
We ended up creating just ~100 versions of our app (~100 experiment buckets), and then you could join a bucket. Teams could even reserve sets of buckets for exclusive experimentation purposes. We also ended up reserving a set of buckets that always got the control group.
You've approached it a different way, and probably a more sustainable way. It's interesting. How do you deal with the bias from your 'more courageous' people?
vasco
> 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 new features vs old features when exposed to them to update courage, meaning people who still keep using the product when it changes have more courage so they see more changes more often.
But even that I don't know what purpose would have because now you destroyed your A/B test by selecting a very specific sub population, so your experiment / feature results won't be good. I'm assuming here a product experimentation approach being used, not just "does it work or not" flags.
siva7
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.
vault
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"?
fire_lake
I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?
ygouzerh
Do you mean feature flags? This enable you to change the configuration at the runtime. Ex: A/B Testing and changing a behavior for a subset of users, disable feature when you want it (particularly useful when you are in Trunk Based Development and don't want to deploy a beta feature to everyone for example).
echoangle
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)?
hobofan
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 be controllable by e.g. a marketing/product manager and not only software engineers
That can quickly grow into something where it's a lot easier to reach for an existing well thought out solutions rather than trying to home-grow it.
random_kris
Nice! Sometime ago i made a small poc with usage on Frontend (nextjs) Backcend (js) Flag provider (flagd + flag api that serves json flags from db)
Cool stuff
cmckn
Looks like an interesting project. Really cute logo. :)
How much does the flagd sidecar cost? Seems like that could be a lot of overhead for this one bit of functionality.
chromanoid
I can see that this might be very useful, since it is more some kind of application configuration specification that goes far beyond simple flags. In the end the common provider that works securely across all services and clients is probably the real problem.
taveras
As someone who’s been thinking about feature toggles and continuous delivery often lately, OpenFeature has been helpful.
Kudos to the team!
MeteorMarc
Martin Fowler about feature flags: https://martinfowler.com/articles/feature-toggles.html
hobofan
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.
sabedevops
Where is the tldr? Anyone familiar…what does this do and why do we care about it being standards based?
taveras
This is a “standard” SDK for feature flags, allowing you to avoid vendor lock-in.
i.e., using feature flag SaaS ABC but want to try out XYZ? if you’re using ABC’s own DDK, refactor your codebase.
I appreciate that you can use the OpenFeature SDK with environment variables, and move into a SaaS (or custom) solution when you’re ready.
sgammon
java version embeds lombok symbols lol
abrahms
Forgive my ignorance, but what should it be doing instead?
martypitt
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 from.
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 each user (we called it courage) and a decimal number [0.0, 1.0] to a feature flags (we called it threshold). That way not only we enabled more experimental features for most experiment tolerant users, but these were the same users, so we could observe interaction between experimental features too. Also deploying a feature was as simple as rising it's threshold up to 1.0. User courage was 0.95 initially and could be updated manually. We tried to regenerate it daily based on surveys, but without much success.