Repository navigation
Compatibility/overlap with the OpenFeature Spec/SDK #368
Description
While checking something completely unrelated today, I stumbled upon this:
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:
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:
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.
Activity
julealgon commentedon Feb 12, 2024
After posting this, I found extra information that partially responds my own question.
There are plans for a
OpenFeature.Extensions.Hostingpackage already:OpenFeature.Extensions.Hostingpackage open-feature/dotnet-sdk#264There is already work in progress to create a provider for OpenFeature using Microsoft.FeatureManagement:
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 commentedon Feb 15, 2024
Hello Juliano Leal Goncalves (@julealgon)
There are a few questions asked simultaneously but I think this is the key one:
We are aware of
OpenFeaturebut are currently still invested in developingMicrosoft.FeatureManagementas 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 forOpenFeature.Regarding the idea of Microsoft.FeatureManagement implementing OpenFeature specification, that has not been explored or discussed.
julealgon commentedon Feb 15, 2024
Thanks for the update Jimmy Campbell (@jimmyca15)
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:
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.
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.Diagnosticsbasically implements a ton of the OTEL spec with abstractions such asActivity,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.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 commentedon Feb 20, 2024
I too would be interested to see how this plays. I am thinking a stepwise approach would be beneficial here:
Note it might be worthwhile folding package into dotnet repo alongside the other Microsoft.Extensions and versioned similarly ie v8.
beeme1mr commentedon Apr 23, 2024
Hey Jimmy Campbell (@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.
Juliano Leal Goncalves (@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 commentedon Apr 24, 2024
Michael Beemer (@beeme1mr)
Thanks Michael. In particular, I believe that that
OpenFeature.Extensions.Hostingabstraction will be massive in bringing the library to modern standards in .NET apps, and that will make this overlap betweenOpenFeatureandMicrosoft.FeatureManagementeven 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.
cosmic-flood commentedon Mar 15, 2025
FeatBit is a feature flag provider built on .NET. We've already integrated our SDK with OpenFeature and have also used the Microsoft.FeatureManagement SDK with FeatBit.
In my current practice, I use one or the other but don’t mix them—similar to how I approach the Vercel Flag SDK.
The advantage of this approach is that it keeps things clear for developers. However, the downside is that migrating between vendors (including in-house solutions) becomes more difficult.
Additionally, I believe this shouldn’t be OpenFeature’s responsibility; instead, providers should ensure proper compatibility with each other.
If I missed any news related to this discussion, please point me to the relevant sources. I think OpenFeature is trying the best effort.