7 ms·

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

194 points by gjvc 2y ago

cmckn 2y ago
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.
sgammon 2y ago
java version embeds lombok symbols lol
- abrahms 2y ago
  Forgive my ignorance, but what should it be doing instead?
  - martypitt 2y ago
    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.
    - ahtihn 2y ago
      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?
      - sgammon 2y ago
        The symbols remain in the final library, necessitating either class exclusions within the scope of a JAR you don't control (which is a terrible idea) or the addition of a dependency which is irrelevant, inert, and has no place in your codebase. It is embarrassing for a library to ship ABI-visible symbols from Lombok.
sabedevops 2y ago
Where is the tldr? Anyone familiar…what does this do and why do we care about it being standards based?
- gjvc 2y ago
  the laziness on this site never ceases to amaze
  - gjvc 2y ago
    and the use of "we" to somehow give the impression that this person speaks for everyone
- MeteorMarc 2y ago
  https://openfeature.dev/docs/reference/intro/ https://openfeature.dev/docs/reference/intro/
- taveras 2y ago
  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.
MeteorMarc 2y ago
Martin Fowler about feature flags: https://martinfowler.com/articles/feature-toggles.html https://martinfowler.com/articles/feature-toggles.html
- hobofan 2y ago
  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.
  - jonathannorris 2y ago
    Pete is a great guy, also on the OpenFeature governance board :)
fire_lake 2y ago
I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?
- ygouzerh 2y ago
  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).
  - fire_lake 2y ago
    No I mean an entire framework and set of software components for doing feature flags.
    - GiorgioG 2y ago
      Clearly you haven't worked at an org that uses something like this extensively (LaunchDarkly for example.)
    - skeeter2020 2y ago
      If you have a single database than maybe you can (and should?) just start with a basic, single table approach, but as you grow in size and complexity FF management can become a challenge, with reporting gaps and feature release management. I usually see two charateristics with the former approach: growth in the # of FFs over time and a messy Excel report for what they are, do and if anyone still hits the old code. This might be fine for a while, or forever, but often gets painful.
  - echoangle 2y ago
    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)?
taveras 2y ago
As someone who’s been thinking about feature toggles and continuous delivery often lately, OpenFeature has been helpful. Kudos to the team!
chromanoid 2y ago
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.
random_kris 2y ago
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 https://github.com/grmkris/openfeature-flagd-hono-nextjs https://github.com/grmkris/openfeature-flagd-hono-nextjs
adontz 2y ago
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.
- vault 2y ago
  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"?
  - adontz 2y ago
    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.
- withinboredom 2y ago
  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?
v3ss0n 2y ago
Have they benchmarked against similar sized GGUF quants? How is it compared to them?
webda2l 2y ago
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 https://github.com/halvardssm/stdext/pull/6 by example then https://github.com/WICG/proposals/issues 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 https://github.com/nodejs/node/issues/55419), but when done and right done, it's a huge win for developers. PHP PSR, RFC & co are the way.
- oddevan 2y ago
  I was thinking of PSR interfaces when I was reading this!
bullcitydev 2y ago
Speaking as an open-source feature flag 'vendor' (https://github.com/flipt-io/flipt 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 https://cloud-native.slack.com/archives/C0344AANLA1 or joining the bi-weekly community calls https://community.cncf.io/openfeature/ https://community.cncf.io/openfeature/.
DandyDev 2y ago
Are there any big feature flag SaaS vendors that support this? Like LaunchDarkly, Flagsmith, Unleash etc?
- aepfli 2y ago
  Yes there are, as I am part of the openFeature community, I have to point you to https://openfeature.dev/ecosystem https://openfeature.dev/ecosystem where you'll see all kinds of providers which are supported (some officially, some by the community)
- dabeeeenster 2y ago
  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 https://github.com/open-feature/spec/issues/276) and the Remote Evaluation Protocol (https://github.com/open-feature/protocol https://github.com/open-feature/protocol)
- zellyn 2y ago
  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.)
- andrewdmaclean 2y ago
  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 https://docs.devcycle.com/integrations/openfeature)
vhodges 2y ago
I am looking to maybe support this in https://github.com/vhodges/ittybittyfeaturechecker https://github.com/vhodges/ittybittyfeaturechecker probably via https://openfeature.dev/specification/appendix-c 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)
caniszczyk 2y ago
I hope that OpenFeature changes the feature flagging space the same way that OpenTelemetry impacted the o11y space, we are overdue for this (in my biased opinion)

194 points by gjvc 2y ago

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.

sgammon 2y ago

java version embeds lombok symbols lol

abrahms 2y ago
Forgive my ignorance, but what should it be doing instead?
- martypitt 2y ago
  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.
  - ahtihn 2y ago
    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?
    - sgammon 2y ago
      The symbols remain in the final library, necessitating either class exclusions within the scope of a JAR you don't control (which is a terrible idea) or the addition of a dependency which is irrelevant, inert, and has no place in your codebase. It is embarrassing for a library to ship ABI-visible symbols from Lombok.

sabedevops 2y ago

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

gjvc 2y ago
the laziness on this site never ceases to amaze
- gjvc 2y ago
  and the use of "we" to somehow give the impression that this person speaks for everyone
MeteorMarc 2y ago
https://openfeature.dev/docs/reference/intro/ https://openfeature.dev/docs/reference/intro/
taveras 2y ago
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.

MeteorMarc 2y ago

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

hobofan 2y ago
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.
- jonathannorris 2y ago
  Pete is a great guy, also on the OpenFeature governance board :)

fire_lake 2y ago

I don’t get it. Why is this needed above and beyond the standard ways of configuring deployed services?

ygouzerh 2y ago
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).
- fire_lake 2y ago
  No I mean an entire framework and set of software components for doing feature flags.
  - GiorgioG 2y ago
    Clearly you haven't worked at an org that uses something like this extensively (LaunchDarkly for example.)
  - skeeter2020 2y ago
    If you have a single database than maybe you can (and should?) just start with a basic, single table approach, but as you grow in size and complexity FF management can become a challenge, with reporting gaps and feature release management. I usually see two charateristics with the former approach: growth in the # of FFs over time and a messy Excel report for what they are, do and if anyone still hits the old code. This might be fine for a while, or forever, but often gets painful.
- echoangle 2y ago
  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)?

taveras 2y ago

As someone who’s been thinking about feature toggles and continuous delivery often lately, OpenFeature has been helpful. Kudos to the team!

chromanoid 2y ago

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.

random_kris 2y ago

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 https://github.com/grmkris/openfeature-flagd-hono-nextjs https://github.com/grmkris/openfeature-flagd-hono-nextjs

adontz 2y ago

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.

vault 2y ago
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"?
- adontz 2y ago
  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.
withinboredom 2y ago
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?

v3ss0n 2y ago

Have they benchmarked against similar sized GGUF quants? How is it compared to them?

webda2l 2y ago

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 https://github.com/halvardssm/stdext/pull/6 by example then https://github.com/WICG/proposals/issues 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 https://github.com/nodejs/node/issues/55419), but when done and right done, it's a huge win for developers. PHP PSR, RFC & co are the way.

oddevan 2y ago
I was thinking of PSR interfaces when I was reading this!

bullcitydev 2y ago

Speaking as an open-source feature flag 'vendor' (https://github.com/flipt-io/flipt 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 https://cloud-native.slack.com/archives/C0344AANLA1 or joining the bi-weekly community calls https://community.cncf.io/openfeature/ https://community.cncf.io/openfeature/.

DandyDev 2y ago

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

aepfli 2y ago
Yes there are, as I am part of the openFeature community, I have to point you to https://openfeature.dev/ecosystem https://openfeature.dev/ecosystem where you'll see all kinds of providers which are supported (some officially, some by the community)
dabeeeenster 2y ago
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 https://github.com/open-feature/spec/issues/276) and the Remote Evaluation Protocol (https://github.com/open-feature/protocol https://github.com/open-feature/protocol)
zellyn 2y ago
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.)
andrewdmaclean 2y ago
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 https://docs.devcycle.com/integrations/openfeature)

vhodges 2y ago

I am looking to maybe support this in https://github.com/vhodges/ittybittyfeaturechecker https://github.com/vhodges/ittybittyfeaturechecker probably via https://openfeature.dev/specification/appendix-c 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)

caniszczyk 2y ago

I hope that OpenFeature changes the feature flagging space the same way that OpenTelemetry impacted the o11y space, we are overdue for this (in my biased opinion)