Any thoughts on OpenFeature?

[Starefossen]

Any thoughts on support for the OpenFeature the open standard for feature flag management. I saw Unleash and @ivarconr name on Interested Parties, but not much else.

OpenFeature looks very much like what OpenTelemetry is about to become, I don't think Unleash should miss out on this 🚀

[pransh15]

Hey @Starefossen 👋

Thanks for starting this discussion. We are monitoring the space and are interested in OpenFeature, but currently we do not have the bandwidth internally to pursue this. As we always do, we listen to our community and insightful ideas to understand how we can we provide value.

We met with someone from the OpenTelemetry working group at Devoxx Poland just last week to understand their setup and that does look interesting. 💡

Perhaps, if your or someone from the community would like to take this up, we'd be happy to help kickstart the initiative!

[Starefossen]

Thanks for taking time to answer this, @pransh15 🙏 I thought that would be the case, great to hear that you are positive. I’ll dig around to get a feel of the effort required to get something working 😅

[pransh15]

That sounds great, @Starefossen. Looking forward to hearing from you again. 😸

[itzsaga]

Wanted to add on that I believe this will be table stakes in the future and was one of the first things I looked into when I learned we use Unleash at my current employer.

[rroik]

I agree, and I’d like to highlight that OpenFeature support is a crucial factor in choosing a feature flagging system. Having OpenFeature compatibility would make it much easier for teams to transition from other providers to Unleash without extensive rework. It also enables multi-platform support during migration, allowing us to implement feature flags consistently across diverse environments

[black-snow]

We're currently evaluating and I was rather shocked tbh that Unleash doesn't support it. Would've been my favourite but lack of OpenFeature support is almost a red flag atm.

[toddbaert]

Hey! I'm a maintainer over at OpenFeature! We'd love to see an Unleash provider (we've had frequent requests for them). We'd happily host them in our various contrib-repos, which house providers for other OSS projects and vendors, complete with CI and publishing. It looks like @liran2000 has already opened a Java provider PR.

@pransh15 On the topic of OpenTelemetry integration... this is something we're quite interested in as well. We have some built in extensions (hooks) to enable OTel-semantic conformant metrics and traces for feature-flag evaluations. They can essentially be wired up with a single line of code to any OpenFeature SDK.

We also helped develop the OTel semantic-conventions for feature flags, which can really be leveraged by anyone, even without OpenFeature. I hope they might be generally useful to the Unleash project - we tried to keep them as generic as possible.

[ivarconr]

Hey! I'm a maintainer over at OpenFeature! We'd love to see an Unleash provider (we've had frequent requests for them). We'd happily host them in our various contrib-repos, which house providers for other OSS projects and vendors, complete with CI and publishing. It looks like @liran2000 has already opened a open-feature/java-sdk-contrib#424.

This is really great @toddbaert . Thanks for bringing this to our attention. Would the Unleash team be able to patch fixes themselves? (PS! we will never consider an SDK official if the team is not able to fix any problems for our users).

We also helped develop the OTel semantic-conventions for feature flags, which can really be leveraged by anyone, even without OpenFeature. I hope they might be generally useful to the Unleash project - we tried to keep them as generic as possible.

This is really cool. What is the process of having opinion on the spec itself? We love that there are standardization on this, but also see some improvements that can make it more explicit. E.g. "enabled" and "variant" are actually two different concepts in feature flagging, and merging them down to one attribute takes away some of the semantics.

[toddbaert]

This is really great @toddbaert . Thanks for bringing this to our attention. Would the Unleash team be able to patch fixes themselves? (PS! we will never consider an SDK official if the team is not able to fix any problems for our users).

Our contrib repositories are "monorepos" that contain a bunch of integrations, extensions, etc. We have a component-owners file (see this example in the java-contrib) that helps keep track of ownership of each sub-component. Anyone listed as a component-owner is automatically added as an assignee/reviewer for changes that impact that component, and their review is required for changes.
For components involving vendors or OSS tools, we generally add as many established maintainers from that project as are interested.

Note that you're also completely welcome to host any OpenFeature providers in your own organization if you'd like full control.

This is really cool. What is the process of having opinion on the spec itself? We love that there are standardization on this, but also see some improvements that can make it more explicit. E.g. "enabled" and "variant" are actually two different concepts in feature flagging, and merging them down to one attribute takes away some of the semantics.

OpenFeature makes a distinction between "enablement" and "variants" as well. Generally though the specification doesn't directly support flags that have a multipart payload with a boolean state as well as some other auxiliary variant (there are ways to accomplish this with the OpenFeature API, but exactly which would be best I can't say with my limited knowledge of Unleash). I know some flag providers do support this, but many also do not. This is the kind of thing that's difficult when designing an open standard API - we're trying to build something that is maximally compatible with tens of paradigms. That said, these sorts of discussions are exactly what we're all about. The spec is completely open source, and it's been built by getting consensus from as many vendors as possible. We'd certainly welcome PRs or issues from Unleashed folks. If you'd like to specifically discuss how the OpenFeature API could best be used to match Unleash's concepts, I'd be happy to meet about that or start a discussion.

[ivarconr]

Thanks for clarifying.

This is the kind of thing that's difficult when designing an open standard API - we're trying to build something that is maximally compatible with tens of paradigms.

I do understand that building one spec to match multiple vendors needs is challenging.

OpenFeature makes a distinction between "enablement" and "variants" as well. Generally though the specification doesn't directly support flags that have a multipart payload with a boolean state as well as some other auxiliary variant (there are ways to accomplish this with the OpenFeature API, but exactly which would be best I can't say with my limited knowledge of Unleash).

At unleash we believe feature management is a first class, and it is important to have a clear concise domain language. We believe a semantics beyond a single value is important. Based on our 9 year experience working with thousands of companies, we see that dynamic values are less common and often a miss-use of feature flags for static configuration which often leads to permanent flags with resistance to remove.

The spec is completely open source, and it's been built by getting consensus from as many vendors as possible. We'd certainly welcome PRs or issues from Unleashed folks. If you'd like to specifically discuss how the OpenFeature API could best be used to match Unleash's concepts, I'd be happy to meet about that or start a discussion.

We would love to see Unleash work great with Open Feature.

[BrandonAtHoag]

Would love to see this too. I'm not including Unleash in my company's feature flag solution considerations specifically because there's no Javascript provider for Openfeature.

[gastonfournier]

Thanks @BrandonAtHoag for sharing your feedback! We understand the importance of having a JavaScript provider for OpenFeature but currently, we don't have the capacity to take this on. It'd be good if you can open an issue here requesting for an Unleash provider. We'd be happy to assist by providing feedback and validation if someone from the community can take the lead on this effort, as we did with some existing OpenFeature Unleash providers for other languages.

[gastonfournier]

Hi @BrandonAtHoag out of curiosity, what's the main reason for choosing OpenFeature? We have some ideas but it's always better to know from the source.