Variations and Variables

[fahad19]

This PR

Introduces a new OFEP as per a previous discussion on Slack.

Proposes a new model for features, breaking it down into 3 kinds of values all scoped under a single feature:

• feature flag
• variation
• variables

Notes

This is being proposed to help open up the possibility to create OpenFeature providers for Featurevisor: https://featurevisor.com/

SDK docs showing examples of the proposed feature model:

• https://featurevisor.com/docs/sdks/

Further guides for the concepts introduced:

• https://featurevisor.com/docs/use-cases/experiments/
• https://featurevisor.com/docs/use-cases/remote-configuration/

---

I understand this proposal can be very different than your overall vision around feature flags, but I feel it's worth raising it to you all because it enables many other tools (both Open Source & SaaS) to create OpenFeature Providers then ❤️

[moredip]

my 2 cents is that if there's a way we can achieve this in "userland" (e.g. using "foo:bar" key names with semantics that the provider understands) then we should strongly prefer that over changing/extending the spec

[fahad19]

my 2 cents is that if there's a way we can achieve this in "userland" (e.g. using "foo:bar" key names with semantics that the provider understands) then we should strongly prefer that over changing/extending the spec

@moredip: you are very much right in suggesting if we can a solution in the userland for scoped variations/variables like using foo:bar as keys.

I like this suggestion. and likely creating a new Featurevisor provider for OpenFeature following this pattern.

my response would be the same if I were an OpenFeature maintainer.

the only remaining thing for me is to figure out the "activation" event to be triggered at will, which is discussed in above thread.

[fahad19]

summary:

• for scoped variables, we can follow featureKey:variableKey pattern, keeping the OpenFeature API the same
• for experiment activation (which are not always handled at the time of evaluation, but when application decides when it has been exposed to the user visually), we can delegate that to the userland (application) without touching OpenFeature SDKs in any form

really appreciate all the inputs <3

I would have defended the OpenFeature API the same way to not have any further tweaks in the API to accommodate Featurevisor or any other solutions.

will take the learnings from here and build the provider at some point.

thanks everyone! 🙌