OpenFeature Update From the Ma... Lukas Reining, André Silva, Thomas Poignant & Alexandra Oberaigner

This talk provides an overview of Open Feature, a CNCF incubating project focused on feature flagging. The speakers discuss the importance of a vendor-agnostic API that allows developers to manage feature flags without being tied to a specific tool. They explain how feature flags work at runtime and introduce the Open Feature SDK, which supports various programming languages and frameworks like React, Angular, Kotlin, and Swift. The team also highlights the recent rise in community adoption and contributions, showcasing new companies getting involved. In addition, they discuss the Open Feature Remote Evaluation Protocol (OFFREP), which aims to standardize provider integration and facilitate easier vendor switching. Lastly, the session covers exciting updates about GitHub Actions integration and educational resources available for learners interested in feature flagging.

Hello everyone. So again thank you so much for joining us for the update from maintainers uh from us at open feature. Uh first I would like to introduce myself. My name is Andre Andre Silva. I'm recently elected the GC uh government's community for open feature and I'm uh I work currently at Lexus Nexus. Lucas. >> Okay. Yeah. My name is Lucas. I work for Codecentric and I'm

part of the open feature technical committee. Next to Alex. Hello, I'm Alex. Uh, I'm working at Dino Trace and contributor to Open Feature. >> And I'm the last one. So, I'm Thomas. I'm working at the company called John Conference and I'm part of the governance committee of open feature too. All right. So, let's kick starting. So, let's talk this today about first uh we will do a

small uh introduction to to those of you who don't know open feature yet. Then uh Thomas will give an update on uh of I will do a little bit talk on MCP of course AI needed to be included. Uh Alex will uh discuss um a little bit of GitHub actions and the CLI. Lucas will give a small overview of the insights of the community and hopefully time

will allow we will have a Q&A. So next to who in the room have ever heard of open feature before? Raise your hand. Oh. Oh, I saw a few ones. So now second, who is using open feature. Okay. Okay. We will need to to improve for the next next point and who is contributing. Okay. It seems like we still need to have more people contributing to the

project. So now next to Alex where she will talk a little bit more in detail about what is open feature. >> Yeah. So it's great to see so many people already familiar with the project but I'll going to start um from scratch so to bring everyone on the same page. So open feature is an incubating uh CNCF project and it's basically it's an open specification for feature

flagging. Um and it's it's also vendor agnostic which is really important. So it's taking uh open telemetry as an example here to define an an API for feature flagging. So you're not uh bound to any tool and work with any uh management tool uh that you want to like uh want to use. So having talked so much about feature flagging um what is what are feature flags

actually and so let me let me explain a little. So it's basically a mechanism to turn off and on features at runtime in your code. So you won't change the code um at runtime. So everything is there already. It's released. It's shipped and you just um turn on uh the light or turn it off. Basically you can think of it as a light switch. Um and you

don't have to modify the source code which is great. So you you don't break things or if things break you can switch it off again. So if you're uh looking at this um this graphic here. So if the user is using a web page for example and um yeah it's coming to the co path where it's checking is this new feature a enabled then um uh open

feature will which will um do a call to the flag management system with the context of this user one and um if it's it if it's getting true returned then the new version of feature A is uh shown otherwise uh the old version uh of feature A um yeah is is given to the user. So how does this now look behind the scenes? So within your application,

you have your flag evaluations. You're interacting with the open feature SDK. So in the code, you will never have to change that. So the open feature SDK is what's what's standardized. So this will always stay the same no matter what uh management tool you're using. And um this is where the open feature provider comes into play. So um depending what flag management system you want to use,

you just use a different provider and you plug and play it basically. So you can use a file-based provider, you can use your own tool or any any other vendor that's out there. So mentioning the SDKs now Thomas in what languages uh can you use open feature now? >> Yeah, this this is a full list of uh frameworks and languages we are supporting. So this year we

have been working towards like moving mo most of the SDKs in 1.0. So recently we've we've done it for uh React and Angular but we're also working on a mobile side to do it on Cotlin and um and Swift. Uh the goal here is like not that you cannot use uh if it's not one but we want to be sure that we have no breaking changes and

that it's going to stay for long in for for different users of open feature. Uh we're also working on a new one that is a C++ SDK uh that is like starting right now. It's it's not fully spec implemented but you can start using it Thanks. And and one thing we saw also this year is that the adoption is starting to rise. Uh as you can see

like especially in the GS world we see that we have like a big gap from last year and and we've seen that for all SDKs where we are able to collect data that the community is growing. We have more and more usage of of our SDKs. So we can see that open features becomes like more and more used across the community and and all different kind of

companies and projects. And based on that, it's also like you can see here the list of companies that are contributing to open feature data trace was super early on. So that's why it's so big now. But uh the good thing is that we see new names coming uh to the community like uh data dog is coming, Google, Spotify. So we have also big names starting to participate

to the effort of building open feature. Um the good part is that all of this like brings a lot of energy in the project and we see also some companies starting to build open feature first uh SDKs rather than in the past it was more custom SDK so it's pretty pretty good for for the project and we can see that it's moving forward and yeah and one

last thing like we are really proud of is like we are now part of the tough work radar so you can scan the QR code if you want to know more but uh the good thing is that now uh you can see that it's really highlights how popular and and stand out uh open features start to be so we we are really proud of that and you

can look at it so when access part I think and yeah and now we're going to deep dive in more specific topics that we have progressed this year and the first one is of so offrep means open feature remote evolation protocol so the goal is to be even more uh to reserve even more the vendor looking part to be uh easy to switch between between vendors and

also to standardize uh how you can integrate new providers. So it's especially useful for your home build feature flag solution because sometimes when you want to go to open feature as Alex was saying is like you have to build providers. So you have the SDK that is standard across all feature flag management uh system but the providers is specific and building a provider can require sometimes if

you are like a company that have multiple languages. So the goal of of rap is to reduce this uh this thing to be sure that we also build standard providers by by creating an API layer that uh this is the API layer. So it's basically two APIs you have to build pretty easy uh to be able to to integrate with those providers. So these APIs are two

types. We have like one that is for single flag evaluation that is used on on server and you have like a bulk evaluation system that is used on more client side and both of them are are pretty easy to implement. So you can build it on top of your homegrown solution or some vendors are already also adopting it. And when you have that you don't have to

build providers anymore. The providers are built by the community and we have uh already this list of providers that that exist. So uh everything GS world both clients and server C uh Java Python and all you can see here. So we are moving towards to include more and to be sure that you can benefits from just building two API uh two APIs on your on your system

and having like open feature for free. So yeah main benefits uh it's uh the first one is like you don't have vendor locking at all in your code. So you don't even have a provider specific to a solution. Uh switching vendors means like switch just putting a different URL in your configuration and you switch from one vendors to another. So so it makes it easier and you

also have like good community uh maintain providers because uh the one who build providers are also the one like knowing pretty well open feature. So they are like already on top of all the features that are available in in open feature and yeah uh and where where we are with uh with offrep. So right now we uh it's already adopted by different uh vendors. So I know

flagd uh dev cycle go flag flipped are already implemented it and we see more people wanting to integrate this uh this new standard. Uh 1.0 is almost there. We hope like pretty soon, but it's almost there. And uh and we're already working on the next uh on the next thing like bringing server send events on on the client or or to get notified about flag changes or

this kind of things. So it's it's moving towards like one is only the first step. We have a lot of ideas to improve our rep. And yeah, now we're going to talk about MCP and I'm going to let Andre talk about it. >> Yeah. So let's go back to me to talk a little bit of the MCP part of it. Of course, everyone here already knows what

the MCP so I'm not going to describe but uh if you need any help please reach to me after the the talk. So in practice what we try to do is you have your own uh agent you have your own tools and we want to communicate so that the agent knows what is the flag how how open feature works and the idea is you have you are

more enhanced you have more you are way more uh your agents will know better what is feature flag so the MCP currently in active development and is available on the MCP register in that uh website. So what it can do? First point as I mentioned it it gets uh intelligence from our documentation. So basically knows the best practices how to install how you should uh let's say

populate the evaluation context and so on and so on and second and most interesting based on what just uh thus described it uses the offrep uh protocol so that it can uh ask for uh for flags in your chatbot. So let's see these uh two scenarios. I'm a net developer. So I ask oh can you please help me and create a go SDK to my go project

that I only opened yesterday and say yes I can do it. So basically what it does is it it goes to the MCP gets the latest information for documentation and then it literally generates your code. And second, oh Jesus, this flag scheme has 10k flags. So how does it resolve? Please help me claude. And then it goes and say, okay, you know what? You are absolutely right.

This is a big a big flag list. So this is your flag and this is how it resolves in this um in this situation. So you can see a lot of potential here and please have a look into it. we are uh actively working on it. Raise your issues, feedback and uh have a quick look into our MCP repo. And to Alex to talk about GitHub actions

and >> Yeah. So with the uh release of the open feature action um it's now possible that you build your own um GitHub workflow for for your feature flex. Um, and this is basically um the foundation of it is the GitHub is the open feature CLI. So wouldn't it be great to have like just in your in your PR uh an overview of all the ch the

changes that um on your flag. So basically additions, removals, modifications. So you can just uh review those or or um or also check um if the remote flag or the flag management um so from the remote flag flag management system the configuration changed. So if if you have like a local uh version in your repository and you want to compare it to uh the remote uh flag

system which is made somewhat detached pro maybe it would be great to know if it's out of sync and then what would also be great right would be to automatically generate um your feature flag variables from it and and this is all possible with with the CLI and the GitHub and uh the open feature action but why why do we want to use it? So obviously it's

it's enabling a flag driven development so you can review your changes and and also track them in the git history. Um but also it's helping to maintain consistency. So um if you have if you're maybe switching providers and you're in between those this switch and you want to make sure that that they are both using the same uh flag configuration then this will obviously help. um or

you have different environments you want to uh compare the changes to or branches or whatever. So how to use it? Um it's basically really simple. You just uh create your uh GitHub workflow and then include it in in the in the steps and um use the open feature slash action um and then you specify the manifest that you're um comparing uh you want to compare. And if

you're not specifying anything you want to compare it against, then you would just take the main the base branch. Um, but you can also obviously put here like uh the the remote uh flag um the remote flex and this is working as said already with the CLI. Um by using these free commands you can generate those typed variables. So first you will p you will use the

pull um it will use behind the scenes the pull um command from the CLI to pull the the configurations from a remote uh flag management system. Then you can compare uh the manifests with the compare command and uh and in the end you can use the generate command to create uh the the the new flags or the or how they were changed. So you don't have to

care anymore about the string being wrong or or um or anything like that. Yep. And with this I'll hand over to >> Okay. So we saw that many of you already know about the project and uh as we heard like we had a huge growth and like people contributing more getting into that we we have known of many companies coming into that with that came feedback and

discussions and stuff like that. So what we want to do uh we picked two of those discussions and we want to talk about how how that work like what it brought what it means for this year's development of open feature and just give an insight to that. Uh those are like examples from what happened. Oops. So um we we saw that many of you know it uh

that not all of you use it. So open feature is built around the API singen. So what that means is that we have uh a singleton that's available in all the SDKs that you use to get to the flex and that was a decision we did on purpose. It's because it must be easy for people using the feature flags uh in their code to get the open

feature API evaluate the flag and um yeah forget about it. So you don't have to care about how to get to your feature fling client how how to set all that up. So the decision was to do that. Another point of why you might want to do that is for example in library where we do the feature flagging um also it's it gets just way easier because

uh there's a global context that's set from outside uh and the library inside doesn't have to matter about how that has been set up. Um that works pretty well for many of the mainstream use cases. Um but there are some where this doesn't work so well. Um and it was brought up uh in the context of micro front ends. So in that you have to imagine that

we had someone who was using it for microphone ends and this person had uh these different microphone ends uh do feature flagging. But these microphone ends different life cycles. So some of them were coming up later, some were going earlier and were shutting down. Um and there's only one window object in JavaScript. So what happened was that like the first microrend to go shut down open feature

and it was gone. So the connection was closed. It it was it was ended. It didn't work. So it makes sense that in this case we we need another way of doing that. Uh there are some some things we could work around that but we we like had to acknowledge that for this case there must be something better. Um also for example for dependency injection that can

be a little awkward. For example imagine we have nest spring.net where they are just centered around the idea of dependency injection. Um but for open feature in these cases you would have to I would have to get this global singleton. Um and for parallel testing for example in Java uh that can also be pretty awkward if you like imagine you have multiple tests running aside in parallel

and then um yeah you test around the life cycle that can become pretty bad. Um so we we knew that we needed to find a way to opt out of these for like these advanced use cases uh without replacing the singleton because we still think that for the main use cases that's the way to go. So right before Christmas we got together because we understood that we

couldn't clarify that after all these long uh GitHub issue discussions and we did an open meeting for everyone who wanted to contribute um to that problem and we discussed four main options. So I'm not going to go into all of them. Um and we we discussed around them and in the end we said we we are going to do PC's for them because we we thought we

have we found the candidate that we want to go with but we we were not 100% sure. Um so we said we're going to do a proof of concept and we said we're going to do it in JavaScript and we're going to do it in Go. Um they make sense because they are very different and one is also uh for the front end which is uh yeah

where the main problem came from and go works so much different that it was good to to try it both and we also said we are finding out about provider not being able to be attached to more than one of these uh API instances because then we would have the next life cycle problem. You like because the provider has a life cycle too. Um in the end

uh we are about to decide for using this isolated open uh feature API instances which basically gives you um yeah a function a method whatever uh whatever the design for the concrete language is um to get to get a single open feature instance. Um this also brings with it that you have to um that you have to do the dependency injection that you have to do whatever

is needed to bring open feature to the place where you want to use it. Um so again it's meant for cases where for example you have dependency injection and you want to use it or you have something like those micro front ends. Um this is we want to do this in a safe by design way of you are not uh accidentally using these instances. So we said

that they should come from different import paths to just be sure that you opt into that and you're not just accidentally use that. So you see that isolated in the import path and yeah it should be clear for you that you have to opt into that and you have to be sure why you do that. Um yeah it must be the same API uh contract. So uh

it should be interchangeable whatever you use then for the for the evaluations. And yeah, this this design is backwards compatible with the old one. Uh it just depends on where you get your API instance from. Um another thing we want to look into that was brought up this year and we were thinking about uh solving or like trying out this year is to separate our API from

the implementation packages. Uh when I'm talking about API here, I'm talking about the the code interface. So um I guess many of you know open telemetry that's also what they do and the idea here is that when you write a when you write a library or something like this that you don't want to use the um or that you don't have to get in the whole SDK

directly. So you can imagine that something we do is that we really need to make sure that our API remains stable and basically that's just the the interfaces that we use while the implementation changes inside. Um and for example it's it's way easier to just decide which version of the SDK you want to have uh even though you can still take the stable API package and leave

it in there. There are also other cases where for example in a library uh you can just code against this API uh and when you are about to do the real feature flagging when using that um the SDK is brought in by the application author and not by the library author and then configured by them. Um that thing is currently under discussion as uh part of the

road map proposal. Um yeah, so probably something or yeah, probably something we're going to look into this year. Um so the the last thing we want to tell you about is that we uh got a feature flagging course on the LFX education platform last year. Um so it is an introduction uh for feature flagging with open feature and here you can see feedback from one of the

persons doing that and we actually have 500 enrollments until now. So 500 people did that and yeah got their first hands on feature flagging um how to do feature flagging in their existing infrastructure without the lock in um and learned about how to be able to yeah release uh or deploy without releasing. Um that's free. It's about 10 hours of course material and it has hand on

hands-on labs and quizzes and there's a discussion forum. So if you don't find or if you don't have an idea where you can start looking into feature flagging or where you want to learn about how open feature works, how you can get started with it, that's a great place to do. So um if you're interested, it's free. Just try it out. So yeah, that's about what we

wanted to talk about for the last year. This year we finally updated the uh picture of all the maintainers we have. we took the uh first 120 people that contributed over the whole project lifetime. So, thanks to all that people and all the other ones that uh that are not on here. Uh I think we as a community are really growing. Uh it's getting really large and

yeah, it's it's fun. It works out. So, thanks to all of them. Thanks to you for being interested, for being here. And I think we have some time for questions now. Don't be shy. Go ahead. It's an excellent opportunity to talk about feature flags. >> Okay. Hey, thanks a lot about the talk. Um about the context um from Miro we use extensively uh open feature uh and

more specifically go feature flags and I have quite specific question about the performance uh more specifically about the uh evaluation of all features and per specific feature or all features evaluation and in the context that we have quite big segments uh for the features. Um so what are the recipes that you or patterns that you can see that we can use to make it more performant in

the systems where we have like more than thousand active flags? >> You want to take that? >> Yeah, I have to because flag is me by the way. So that's why I can take it. Um yeah, I think um having thousand of uh flags it's pretty great. I think what we've seen uh to resolve this kind of thing is like uh depending on how your company is

organized like you can use things like flag sets and this kind of thing where you can scope down for a specific team uh a set of flags that we are using and so you don't have to load all the flags every time you only load what is needed at a specific time. So flexet is something on go feature flag and fully compatible with uh with open feature

and I think it's a lot of vendors are doing that actually but yeah that's the kind of thing we we are doing so it's like more scope down the number of flags and we can always improve performance on the other side but we still like especially for client side u like the way of rep works or most of the system works is like it evates everything and

send it back to the front end and this could be like a performance issue if you have like thousands of flags but I'm happy to discuss more in detail if you want. >> Sure. Thanks. And then if I have an opportunity I want to ask second question about the MCP. Um are building an internal MCP for the internal provider to have an opportunity within theic flow to

actually manipulate with flags. So if I want to create a flag when I create a code to build the code inside like wrapped in the flag do you consider this to be as a part of the specification for the MCP uh that open feature will provide out of the box for the providers? >> So I can take now this one. So in relation to the MCP at

the moment we are only considered read only operations because for the right one we need to have like your feedback from the community like everyone can chat me or even Jonathan that is here in the in the listening to us. Uh and my point is if you have feedback around you okay I think it would make sense then we can have you know have chat with the

vendors because you know as a open vendor neutral we need to have consensus around community vendors so we can say look people are asking can we have create flags or write flags if if we go to in that direction yes we will make available but at the moment is not available. Okay. Okay. Got it. Thank you. But just to add on top of that is like in

CLA SIG that we have there is an effort into trying to find a common way to create APIs to create flags, update them and so on. Uh I think it's still early on. So we we don't have huge support on that but uh but it's still something we are looking at to be more standard into how you can create feature flags and so so it's not directly

related to the MCP part but it could be included uh at some point if we if we think it brings value so we are more towards like how we can create flag in a vendor agnostic way uh rather than including it in MCP but yeah that's something we are looking at. >> Cool. Thank you. No worries. Thank you so much. We have one more too. What? No,

not not all. >> We We will be around if you have. >> Yeah, exactly. We'll be around. >> Reach out and and thanks a lot. And if you want to be one of them, uh you are more than welcome. Like uh we want to see your face on on this map next year. >> join >> just join >> and you can always uh hit us at the

booth at the project pavilion. So >> Oh yeah, that's true. Actually we will we in the afternoons we are in the project P20P in the afternoons we will be around there. So feel free to join and have a chat. All right. Thanks Allet. >> Thank you.