Compatibility/overlap with the OpenFeature Spec/SDK

[julealgon]

While checking something completely unrelated today, I stumbled upon this:

• https://openfeature.dev/

Similar to OpenTelemetry, this appears to be a SPEC + SDK standardization effort around the concept of feature flags/toggles. I noticed it already has a .NET implementation as well:

• https://www.nuget.org/packages/OpenFeature

However, its interface is not very "idiomatic" to modern .NET patterns. For instance, it doesn't seem to have native integration with the hosting model and Dependency Injection, while this library here has those.

Looking at the list of known providers for OpenFeature, it doesn't list Microsoft's FeatureManagement there:

• https://openfeature.dev/ecosystem/?instant_search%5BrefinementList%5D%5Btype%5D%5B0%5D=Provider&instant_search%5BrefinementList%5D%5Btechnology%5D%5B0%5D=.NET

Does Microsoft intend to support this spec in a way similar to how it does for OpenTelemetry today? Are there any talks around unifying this FeatureManagement project around the concepts exposed by OpenFeature, perhaps even making it the oficial SDK, or at least the hosting model compatible SDK (like OpenTelemetry.Extensions.Hosting)?

We had some plans to leverage FeatureManagement for our own currently custom feature flags system, but now I'd also want to be able to leverage this standardized OpenFeature SDK as it will be easier to support things such as OpenTelemetry integration in the future if the SDK is standardized.

[julealgon]

After posting this, I found extra information that partially responds my own question.

There are plans for a OpenFeature.Extensions.Hosting package already:

• Introduce OpenFeature.Extensions.Hosting package open-feature/dotnet-sdk#264

There is already work in progress to create a provider for OpenFeature using Microsoft.FeatureManagement:

• feat: Adding a Provider implementation on top of the standard dotnet FeatureManagement system. open-feature/dotnet-sdk-contrib#129

Would be great to hear an official response from a Microsoft rep on this though. From how this is going thus far, it appears that OpenFeature will "win" in the abstraction front? I was hopping for something more "native" like what happened with OpenTelemetry where some .NET classes implemented the OTEL spec without needing different abstractions.

If all of the above goes through, we'll end up with 2 feature toggling abstractions: one provided by OpenFeature, and another provided by Microsoft.FeatureManagement.

[jimmyca15]

Hello @julealgon

There are a few questions asked simultaneously but I think this is the key one:

Are there any talks around unifying this FeatureManagement project around the concepts exposed by OpenFeature, perhaps even making it the oficial SDK, or at least the hosting model compatible SDK (like OpenTelemetry.Extensions.Hosting)?

We are aware of OpenFeature but are currently still invested in developing Microsoft.FeatureManagement as an opinionated solution for feature management.

---

One of OpenFeature's key values is the ability to plug and play with different feature management service providers. In our case, that would be Azure App Configuration. While it is not committed at this moment, it is not unreasonable to think that Azure App Configuration may provide a flag provider plugin for OpenFeature.

Regarding the idea of Microsoft.FeatureManagement implementing OpenFeature specification, that has not been explored or discussed.

[julealgon]

Thanks for the update @jimmyca15

One of OpenFeature's key values is the ability to plug and play with different feature management service providers.

In that front, Microsoft.FeatureManagement also provides that capability, so its not that unique.

What I do think is the best benefit that OpenFeature provides is the hooks extension point. There are packages such as this that then tap into that extension point to provide OTEL capabilities to the library:

• https://www.nuget.org/packages/OpenFeature.Contrib.Hooks.Otel

Because of this, there is no reason to have OTEL implemented at the provider level itself. So LaunchDarkly doesn't have to implement it, Flagd doesn't have to implement it, and so would Microsoft.FeatureManagement also no have to implement it if OpenFeature was promoted as the canonical abstraction.

My worry with Microsoft keeping its own abstraction is that this will unnecessarily fracture the community around feature toggles, and multiple implementations of the same concepts would have to be implemented.

In our case, that would be Azure App Configuration. While it is not committed at this moment, it is not unreasonable to think that Azure App Configuration may provide a flag provider plugin for OpenFeature.

That's both good and bad to hear. The good part is of course the willingness to have an official OpenFeature provider, but then the bad part is exactly that the entirety of Microsoft.FeatureManagement goes to waste in that scenario... Either an additional Microsoft.FeatureManagement provider would need to be created and maintained, or it would basically discourage the use of the library in favor of OpenFeature.

This is why I asked regarding having Microsoft.FeatureManagement implement the spec itself like System.Diagnostics basically implements a ton of the OTEL spec with abstractions such as Activity, Meter, etc. Even if you can totally use all those classes without OpenTelemetry, they are still "compatible" with OpenTelemetry in a way that doesn't force people to change their logic in the vast majority of scenarios.

Regarding the idea of Microsoft.FeatureManagement implementing OpenFeature specification, that has not been explored or discussed.

Would it be possible for you to bring it up to the team? If implementing the spec via Microsoft.FeatureManagement is either unfeasible or unwanted, perhaps an alternative approach would be to adopt OpenFeature as the standard abstraction, then deprecate Microsoft.FeatureManagement as an abstraction over time.

[thompson-tomo]

I too would be interested to see how this plays. I am thinking a stepwise approach would be beneficial here:

• we split the package to make integration leaner chore(deps): update dependency system.text.json to v7.0.3 open-feature/dotnet-sdk-contrib#66
• we implement the evaluation hook & record metrics Record feature flag evaluation metrics #340
• provide an enricher interface which runs before evaluation to add additional metadata
• close out remaining gaps

Note it might be worthwhile folding package into dotnet repo alongside the other Microsoft.Extensions and versioned similarly ie v8.

[beeme1mr]

Hey @jimmyca15, I'm on the OpenFeature governance committee. If you're interested, it would be great to work with you and the FeatureManagement team on improving our .NET support. OpenFeature is collaborating closely with many feature flag management vendors and has contributed to the OpenTelemetry semantic convention for tracking feature flag evalutions. Please let me know if you would like to chat about this in more detail.

@julealgon, we're working on a v2 of the SDK to address some of the concerns you mentioned. If you have a moment, could you please review the open issues to make sure we are leveraging modern .NET paradigms?

[julealgon]

@beeme1mr

@julealgon, we're working on a v2 of the SDK to address some of the concerns you mentioned. If you have a moment, could you please review the open issues to make sure we are leveraging modern .NET paradigms?

Thanks Michael. In particular, I believe that that OpenFeature.Extensions.Hosting abstraction will be massive in bringing the library to modern standards in .NET apps, and that will make this overlap between OpenFeature and Microsoft.FeatureManagement even more obvious (and unfortunately confusing).

I'd love for OpenFeature and Microsoft to collaborate on a unified interface before that happened so that we had a single Hosting model approach to feature toggling in .NET but that might be wishful thinking on my end.