PurePerformance - Introducing OpenFeature – Stepping into the footsteps of OpenTelemetry with Mike Beemer and Todd Baert

Episode Date: June 13, 2022

Feature Flagging has gained a lot of momentum which we can observe by counting the number of feature flagging solutions. To ensure a good developer experience when implementing feature flags the CNCF OpenFeature project was launched during KubeCon 2022 in Valencia. It is aiming to provide a feature flag standard similar to what OpenTelemetry did for Observability.Tune in to this podcast where we have two of the founding members Mike Beemer and Todd Baert explain why it was the right time to initiate the project, which problems it solves and what use cases feature flagging brings to organizations.If you want to learn more about the project check out the following resources discussed during the podcastWebSite: https://openfeature.dev/GitHub: https://github.com/open-featureCommunity: https://github.com/open-feature/communityITPro Today Launch Coverage: https://www.itprotoday.com/testing-and-quality-assurance/open-source-openfeature-project-takes-flight-advance-feature-flags

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. I am your featured host, Brian Wilson. And let me see, I'm trying to figure out if I should have a co-host today. But maybe I'll go with a yes on that and I'll enable my co-host, Andy. Andy Grabner, are you there did did this work was i able to get you on here did you target me on i don't know that was actually really clever i'm actually really good and i like that was the dumbest intro what are you talking about because

they don't know what we're talking about today. It'll make sense. I think they know because they read the title of the podcast. Oh, well, if they did that, maybe they just listen. They don't even read the title. They just see a new one comes in and they jump right on. Like, I got to listen to the latest because my mind is going to be blown and I'm just going to be that much better. My mind will be switched on or turned on or whatever. Yeah.

Yes, exactly. Yeah. Hey, will be switched on or turned on or whatever. Yes, exactly. Hey, Brian, talking about being turned on. What? Last week, at the time of the recording, last week was KubeCon, KubeCon Valencia. Big conference. I think for me at least the first truly big conference

in Europe since we kind of, you know, pretend that the COVID pandemic is over. We don't know yet. But what was really cool, many major announcements, and one of them was around open feature. And this is exactly the reason

why we have our two guests on the podcast today, which is Mike Beamer and Todd. And I would actually like, Todd, I forgot you to mention your last name, but you will do this yourself because I now let you introduce yourself. I'm sorry. Please, quickly, folks. And I'll start with Todd, actually, because I just messed up a little bit. Todd, could you quickly introduce yourself, who you are, what you do, and also where you came from? Your background is also, I think, very interesting for the topic today. Yeah, problem my my my name is uniquely hard to pronounce anyway so it's probably a good

idea that you didn't attempt it um it it looks like bert but it's bart just like the simpson character that's easy to remember so yeah todd bart um i've been with uh i've been with dynatrace for a couple of years i actually had a hiatus recently, but I came back specifically for this project because I was so interested in it. I've been working in IAM for a long time, so I'm kind of a standards and specifications nerd, which is maybe part of the reason I was so interested in this project. But also, I've had some experience with feature flagging. I've used it as a consumer, as a user for sure. And also, CloudBees, the most recent organization I was at, has a feature flagging offering.

So there was a few reasons I was really interested in this project. I think that's a quick overview for me. Currently, my title is Senior Software Engineer. I guess that's the last thing I'll add. Cool. And just one thing to your last name, because if I read it from my German background, the A and E is typical in German, an E. So that's why

Bernd actually makes sense, because the A becomes an E, and then the R, T. Whatever. This is my... I'll just do an equivalent to Neil Peart, because most people call him Neil Peart from Rush the Drummer, but then you found out later on in life, oh, I'm pronouncing it wrong

because it's not as it looks. It's not as it looks. You can be in the famed halls with that drummer. Well, and now over to Mike. Perfect, yeah. Hey, I'm Mike Beamer. Thanks for having me. I've been at Dynastrace for quite a few years now and really have performed a number of roles from consulting.

I was on the DevOps team for a while, development team, developer manager, and then have moved into a PM role recently. Part of that role is focusing on Open Feature, and it's really been an exciting opportunity. So I'm really excited to share it with you guys and actually able to prove, I guess, how exciting it is by pulling Todd back in and a few others. And I'm sure we'll talk about that throughout the podcast today. Hey, Dan, let's kick it right off because some people may have not heard the announcement at KubeCon about Open Feature. So either of you who wants to kick it right off because some people may have not heard the announcement at KubeCon about open feature. So either of you who wants to kick it off, tell us what is open feature all about? Why do we need yet another standard?

I mean, not saying the standard is not good, but let us know what problems does it solve and why did you start this whole project? And then what is this all about? And what is also always interesting with standards, who is on board with these standards? Because if just like we had done a trace, what do you mean? I'm just laughing because let's start with 15 questions I'm going to rattle off. I know, I know, but I want to know all these things.

I want to know in the end who is on board because if it's just one company that tries to drive a standard, I think it's not going to last long. So with this, Mike, over to you. Yeah, absolutely. So, I mean, that's certainly one of the challenges of starting to define a spec is if people don't adopt it, then it's not worth hardly writing. So I'll get into that in a second.

But really what Open Feature is, is standardizing feature flagging at the developer level. So the idea is if you look at a lot of existing vendors or open source projects related to feature flagging, they're all kind of the same. They behave in a very, very similar fashion. The method signatures are slightly different, but the behavior tends to be basically the same. So when we took a look at that, we decided that it would make sense and it's probably the right time to try to standardize that. We pitched the idea to a number of the top vendors and it was well received. So to answer the question about who else is involved, really it is most of the top Futureflag vendors right now and the ones that haven't joined, I'd like to think it's because we haven't found a point of contact yet there.

So if you happen to be listening to it, you notice that there's a missing vendor. Certainly try to get them in touch with us. Love to have their input. But to answer the question, I mean, there's vendors like LaunchDarkly and Split. Those are probably the two biggest feature flag vendors. But we also have Harness, which just released a new feature flag product recently,

which is really interesting. CloudBees, Unleash, and FlagSmith. So those are the big ones we've been working with recently. But then even since the press release came out, we've added a number of other feature flag vendors as well. So really, it's grown quite a bit over the last few weeks. Pretty exciting. And so did I just understand this as a developer

or from a development perspective, you want to standardize the API and the interface that I as a developer can develop again so that in the end, I can just swap out one feature flagging backend with another without having to think about rewriting my feature flag implementation. So in terms of like not having to modify code, yes, that would be the intent.

Really, I think the more realistic path would be if you're starting with some kind of basic open feature implementation, perhaps backed by something like our planned Kubernetes operator or potentially something even like a config file or environment variables. That may be how you start. You kind of get your feet wet with feature flagging. And then as your use cases become more complex, you may want to look at a vendor. And that's where open feature works out well. You could register a new provider, whatever one basically fits your needs at the time. And then of course, you'd have to, at this point uh port over the flags that you need to define in the product but in terms of like the code you wouldn't have to go update you know potentially hundreds or

thousands of lines of code to you know make that transition and that means uh i guess it's similar to other standard projects where you develop against an interface but then i think this was your point that you get into, you don't have to change the code, but maybe during runtime, I need to load a different adapter or whatever it is called, and then to say I'm sending, yeah.

Yeah, that's worth clarifying. So I just threw around the term provider. The provider in the sense of open feature is basically the tool responsible for flag evaluation. So that could be done in a number of ways. And that unlocks some pretty interesting potential. So if you think of like a split or launch darkly, we could basically have this provider interface

that would map to their existing SDKs. And so it makes the barrier to get, basically to support future providers and vendors fairly low. Actually, they wouldn't have to go completely get rid of all of the code that they've worked for years on. They could basically just make it compliant to our interface, and then it would just work. This is where we're starting, and we'll have to figure out which parts of feature flagging needs to be standardized. We're starting with the developer-facing APIs, but perhaps there's a demand for how do we represent

a feature flag in a configuration eventually, so maybe some GitOps flows and things like that. And those are things that we have potential of going in there, but we haven't really talked about it. We've started on the developer-facing side so far. And I guess, I mean, the standard is not only good for the developers as it is for the developer experience, but I guess from our background, and I'm talking about actually all the four of us,

we all work for an observability vendor, it also makes it easier for us to then monitor feature flag usage and the impact feature flags have. I guess that means we only need to instrument the key interfaces. Do you think, are you going to, by default, also instrument OpenFeature with, let's say, OpenTelemetry? How would that work?

Yeah, so one of our design goals was to have OpenFeature be zero dependency or low dependency. So we didn't actually want to include open telemetry built in, but we did want to provide first-class support. The way we decided to do that was through like a hook mechanism. So basically like feature flag lifecycle hooks you could subscribe to. We're planning on shipping an open telemetry hook for open feature. And basically what that

would do is when you do a flag evaluation, it would add a span to the trace and that span would represent a feature flag. We're also, I have a pull request open actually at the moment to try to define what a feature flag looks like on a distributed trace in the open telemetry spec. So that's something that hopefully gets merged in shortly. And that would basically be like an industry standard then for representing a feature flag on a trace or feature flags on a trace to clarify actually. But to the larger point, I think what you're getting at is correct. Once you have developed a standard for something like feature flagging, it really opens up opportunities to just enrich the entire ecosystem. So open telemetry is one

really great example. But really, there's no limit to how many integrations, you know, this opens us up to. Like Mike was saying, we have this hooks paradigm that allows for kind of behavioral extension to feature flag evaluation. And so that could involve things like validation. Perhaps you want to allow non-engineers input into your application behavior. Maybe you want to allow designers to experiment with AV testing. And this is great. This is definitely what, um, what some of the, you know, key purposes of advanced feature flagging, uh, are, um, but our, uh, our system and having some standards around it really allows you to add a lot of robustness to the, um, the,

the developer, uh, facing side of things into the application, um, code itself. For example, you can validate those feature flags. Maybe you only want a certain pattern for values to come back, like you want a CSS hex color, for instance, so we can add behavior to your flag evaluation that's going to ensure that that's the case. When you look at SDKs across a lot of the various vendors, kind of advanced features like this simply don't exist. And I think part of the reason is, if you think of what vendors have to do, they're really focused on the back end, on their feature flag control plane, I guess you could call

it. So defining feature flags, defining rule sets for evaluating feature flags. And then they have to, kind of as a corollary, almost as a chore, develop SDKs in numerous languages, right? So they have to maintain SDKs for every single implementation language they want to have. And so we're kind of removing that burden from them in a way. And I think that's one reason that a lot of vendors are so interested in open feature, because it kind of removes that burden and allows the community to implement

more advanced features around this open standard so that every single vendor doesn't necessarily have to worry about maintaining an SDK and Node and Python and Rust and Go, whatever it may be. I mean, this reminds me a lot about, again, open telemetry, right? The reason why, and this is one of the questions I wanted to ask at the beginning.

Why would I, as an existing feature flag vendor, kind of, you know, why do I want to apply, why do I want to be part of that standard? Because that means the users that you already have and potential other users in the future can easily switch to another tool. But then on the other side, like what happens with open telemetry, we're standardizing the way data gets collected. the users that you already have and potential other users in the future can easily switch to another tool. But then on the other side, like what happens with OpenTelemetry, we're standardizing the way data gets collected, but you really differentiate yourself and what you do with the data. And this is now the same thing

what you tell me here, right? It's basically not the way you are telling, you know, is it A or B or you may have brought up the hex codes. It's really what you can do, what advanced features you can provide to people that really want to leverage feature flags for certain use cases.

And this makes a lot of sense. And obviously you're taking away the pain for vendors to keep up to date their SDKs because otherwise they have to hire people that build the SDKs in all the new upcoming languages. And now that the community, it seems, takes care of it. Yeah, and I think vendors really see their value add on the flag management system side.

They see the value added in providing rich UIs for all sorts of members of the org to be able to understand the feature flags and maintaining the lifecycle of feature flags. So knowing when flags are stale or not being evaluated anymore and being able to define them richly and use different inputs and attributes to differentially execute and resolve those flag values. Open feature is kind of agnostic to all of that. However your flag is defined in your provider, open feature doesn't really care so much. You're going to configure a provider for it,

and open feature is going to kind of expose this rich API to developers, not really caring so much about where that flag data came from. That's the point so i think it allows vendors to focus on what they care about most and less boilerplate and that's why a lot of them are quite excited hey do you think i may be jumping ahead in where the project is but in terms of future i know comparing it to open telemetry we have this concept of third-party vendors are going to ship their code with telemetry built in, right? So if you get something off the shelf, it's gonna have a lot of good information that they're aware of. Do you foresee a situation where a third-party vendor might say these are common places where flags might be so we can preset placeholders for things or is, is, is, is there any, I guess, um, vision of a similar thing where vendors are building something in with it?

Or do you think this is all going to be in the realm? It's too, it's too, it's too unique to each user that it's not something that can be baked in with third party stuff. No, I think that's exactly like one of ambitious goals of the project is to allow for exactly that. And it's another reason why standardization is really necessary for this because nobody's going to bake in a vendor-specific SDK to a major ORM, like third party ORM or whatever other kind of library we're talking about, right? But if you have a zero dependency kind of API, something that is vendor agnostic and exists across multiple languages, where the paradigms are well understood,

it becomes a lot more reasonable to kind of add that to a third party library, just like open telemetry right so i think it unlocks a whole lot of potential that just would be totally unreasonable without a standard yeah um yeah absolutely hey both of you mentioned the term life cycle a lot feature flag life cycle can you fill me in because i'm not sure if i fully understand what that means in the context of a feature flag. Yeah, I mean, there's basically two parts to that. So the one I think we were referring to when it comes to vendors would be, when you're first coming up with what feature you want to develop, you would have to create the feature flag. So how does that process look like? You add it to your code, you would experiment with

it in some capacity, either just turning it on or maybe rolling it out to a subset of users. You would monitor the impact. And then once it gets to a certain point in its lifecycle, I suppose, say like a month or so after it's been enabled and we're not toggling it anymore, it should be cleaned up. So that's considered a best practice in feature flagging. And a lot of vendors have tooling around that. So you could detect basically the staleness of a flag, and then you could automate some kind of maybe Jira ticket creation or something like that to say, hey, it's time to clean this thing up.

So an example would be, I put in a feature flag and I toggled it multiple times in the first month, but all of a sudden that feature flag is I toggled it multiple times in the first month, but all of a sudden that feature flag is still in the code, but it always returns the same value. Nothing has changed. Then I can say, hey, why do you keep this if statement still in there? That's actually now I understand. So staleness means it's actually legacy, not legacy code, but it's dead code kind of, right? It's more or less dead code. Yeah. And you want to clean that up eventually. So that would be all part of a new feature release

is you would have the old one in there just in case something didn't work as expected, but eventually you need to remove the old code. Otherwise you're going to have... Actually, feature flagging would make... arguably make your application more complex. Actually, not even arguably. It would make your application more complex if Actually, not even arguably. It would make your application more complex

if you never cleaned up feature flagging. So that would be definitely viewed as an anti-pattern. Yeah, that being said, there are some flags that... That's one use case. That's like the rollout use case, right? So you're rolling in a new feature. There are feature flags that are considered permanent, or at least conceptually, you'll see that in some vendors.

They'll mark some flags as permanent, and then they're exempt from this kind of staleness evaluation. And those might be, say, feature flags related to maybe something that you even want to have a manual circuit breaker on, like you want to be able to turn this off if some environmental condition changes that kind of thing or there may just be like a key differentiator in your system for users for specific geographies or something like that and you want to dynamically evaluate that and you see no reason that's ever going to change but feature flagging becomes using a feature flag makes sense because it it kind of makes this pivot point in your code official and controllable outside your actual application so that again maybe you know marketing or design or something like that has input on the on some some characteristic of the application performance or application behavior but yeah yeah, I think that primarily the use case

that people are most familiar with is the rollout kind of situation of a new feature for AV, whether it's AV testing or dynamic evaluation, that kind of thing. Yeah, and that's also where I see it tying really nicely back to like Dynatrace or just observability in general is trying to measure the impact that a flag has on a particular request. Or if you think about like A-B testing, which is a pretty common pattern in feature flagging, if you're able to basically split those metrics, it becomes

pretty interesting to look at the data and see what the impact was or that feature had on your application. It doesn't have to be just like response time metrics and things. It could actually tie back to like business metrics as well. And I also like the, I think Todd, you mentioned that having flags that can turn on certain aspects of the app. If it's, for instance, if the app is under like pressure, right? I mean, Brian, we talked a lot about site reliability engineering and chaos engineering and rebuilding resilient systems. And sometimes

you cannot ensure resilient systems by just scaling up. Sometimes you actually have to scale down. But in a matter of turning on or functionality, maybe, I remember, Brian, do you remember when we talked about Super Bowl load testing? That's where my head was before I was going to go there. Super Bowl, Black was before i was gonna go there super bowl black have all these performance improvements for those high pressure situations on standby. And the way I was thinking about it, Andy, is if you're getting feedback from a tool like Dynatrace, could you then have that like, hey, response times are starting to degrade or whatever. Can you have that then feed into your feature tool to trigger the flags to kick on and turn

on those performance saving or yeah turn on the performance saving uh optimizations which would be real interesting way to use it but that's where i think then uh todd those permanent ones would be in there because you probably want to leave those in all the time for when the conditions are right kick in i don't know is that circuit breaker ish i don't know basically circuit breakers is the terminology there and that's where i think it becomes extremely interesting for for dynastrace or observability in general. And I would actually argue that observability, you know, by definition, basically, is passive. And I think we could actually kind of move beyond that in some ways.

We use observability data to, like, make runtime decisions, which becomes incredibly interesting. And the possibilities are pretty vast, I would say. Andy, you need to come up with a cool phrase for that. Exactly. Now we would need a tool, or we would need a captain that could make decisions based on observability data and then trigger other tools. Wouldn't it be cool if, oh man, there is a CNCF project that is called captain and then can do exactly that?

I was wondering if we're going to be able to pull up the Captain. We can coin the term aggressive observability. Maybe not aggressive, though. That sounds aggressive. I like what Mike said, that observability is typically passive. And I think what we talked about at KubeCon last week with some of the people that came to our booth, we said, don't let your dashboards or your alerts

limit the capabilities of observability. Let observability, invite observability into the driving seat of your automation. I think that's exactly what we're doing here. And I find this fascinating. Is it possible then, do you have concepts in mind where you can put tags on feature flags?

And I'm thinking about it, right? There might be feature flags that you can turn off for a certain, in a certain situation, but certain feature flags you should not turn off. And again, coming back

to that load scenario, you're overloaded. So I want to say, hey, if you're overloaded, you can turn off. And again, coming back to that load scenario, you're overloaded. So I want to say, hey, if you're overloaded, you can turn off non-critical features, but you should not turn off a feature that is critical to our business because it's, I don't know, it's a legal requirement that we have a certain thing on the page. Yeah. I mean, the type of thing you're describing is definitely a type of thing that a lot of the feature flag vendors will, will offer solutions for. I think what we're focused on in open feature is really bringing the kinds of

amazing, rich feature flag features that you're talking about to the community at large, because frankly, right now, when you say feature flags to people, a lot of people are just like, well, I use an environment variable for that. Why do I need, why do I need this system? Right. But it's that kind of rich capability, all the stuff that we're talking about that really has exploded recently. It's why these vendors have been so successful.

It's why feature flagging has been so successful. But I think that the types of things you're describing are really more features of the backend vendor system. What we're trying to do is just bring developer access to feature flags, really advocate for that, make it as easy as possible, lower the barrier to entry as much as possible and standardize it at the application development level

as much as possible. The rules, the backend systems, the tagging of a flag or categorization of a flag, those are all features that are available across various vendors for sure. And we just want to kind of make the transition to mature feature flagging as easy as possible for people from an engineering perspective. That's what we're hoping to do. And now from a developer experience,

if I am looking at Open Feature today, what are the languages that you support right now and what's the plan? Sure. So we're pretty early in the process still. We're working on defining the spec, which you could probably imagine is a relatively slow, trying to get a lot of different vendors and even non-vendors input on this and what we can do going forward and how we can keep it powerful, yet simple, has been kind of an ongoing debate. Working on that, making good progress though. Once that is defined, actually right now, even though it's not fully defined,

we are working on a Java, a Node, Go, and a Python SDK. I think a Golang SDK will hopefully be available rather shortly. You may have noticed that those are all backend technologies. So the front end is something that we'll, of course, need to address, but it's been a bit out of scope for our current, you know, over the current month or two so far. So hopefully we can get to that soon. It's certainly an important part and that's really where like AB testing and

stuff becomes really, really important. So definitely circle back to that. But right now it's, it's back in technologies. Yeah. And a lot of the challenge with defining the specification too is really coming up with standard semantics for a lot of this stuff. I mean, back to a question I don't think we actually fully answered. The evaluation lifecycle is one of those semantics, one of those semantic components as well. So like we were discussing the flag lifecycle in the context of a vendor. But from the open feature perspective,

we have a context, we have a notion of flag evaluation lifecycle as in here are all the steps at which you can hook into the flag evaluation API and perform various behaviors. So you can add user data at this point. You can do some validation at this point. You can do some integration with a logging system or a telemetry system at this point. You can do some validation at this point. You can do some integration with a logging system or a telemetry

system at this point. So that's the other kind of meaning for flag evaluation lifecycle, for lifecycle. So there's a lifecycle of a flag potentially in your vendor backing system. But then the flag evaluation lifecycle is something that we rigorously define in our specifications so that you can

kind of have all these different points at which you can plug in different integrations. But it's exactly this kind of semantics and these kinds of definitions that are really important to capture so that our specification is future-proof, our standard is flexible, that type of thing. So that's where a lot of our effort and energy is going at the moment. So an example then would be, if I understand this correctly, one lifecycle event could be before it's evaluated, I have a hook where I can enrich the context, let's say, user IP address, username, user some context, right?

That would be something. And then the evaluation can kick in with much more context and then can give me the feature flag value based on my geo region. Where I think one of the things you mentioned in the very beginning is cleaning up values. So let's say if the value is red

and it's spelled out, I don't know, with an uppercase R, but you want to or have everything lowercase so you want to convert it from a textual value to a hexadecimal.

This would be stuff you could also put in, I guess, in the lifecycle. That's really powerful. Absolutely. So currently we have a before hook, an after hook, a finally hook, and an error hook.

Those are the ones we have currently defined. And now, I know it's still in the early stages, but so as a developer, I will get SDKs that I can then code against. You also mentioned something in the beginning. I think it was you, Mike. Your first kind of open source implementation is going to be some type of Kubernetes operator

that at least provides a backend that I can play with and I don't have to immediately, or what would I do as a developer once the SDK becomes available in my language? What's the backend implementation I would choose? Yeah, so one of the ideas was to basically provide a provider-compatible Kubernetes implementation. So at a high level, what we're hoping to do

is provide developers the ability to define a flag as a custom resource in Kubernetes. The Kubernetes operator would be responsible for more or less providing an Open Feature agent somewhere, likely as a sidecar. And then the Open Feature SDK would communicate to that cloud-native provider. So that would be a way to experiment with Open Feature quickly. And then you could certainly make the decision that a vendor makes more sense or potentially even we'll be able to provide vendor support inside the Open Feature agent that I had mentioned as well so you could actually move the feature flag logic outside of your application essentially and put it into a separate process and

and that would really be uh more easily supported by the kubernetes architecture yeah and vendors are interested in this too um if you could think of i think one particularly interesting use case would be imagine i'm defining flags in CRDs, and it's not uncommon for the Kubernetes API to, you know, create resources, to define and create resources and manage resources within Kubernetes, but also communicate with some external systems. So you could, for instance, have a CRD that defines a feature flag, and then if we had the integration, it would go ahead and sync those resources that are defined in your Kubernetes cluster also to a vendor and actually use their APIs to create the requisite artifacts in their system. And so now you see you've kind of synchronized, you know, your Kubernetes cluster with your, your vendor. So there's, there's a lot of potential here, um, as well as just for flag evaluation, like, um, like Mike was saying before. So to remove kind of remove the flag evaluation out of the actual

process, um, the application process and put it into a sidecar, um, just to make it more flexible, more portable, because now you're talking over a socket, right? Or some kind of protocol. And therefore, you don't actually even have to implement a flag evaluation logic in every single language. You could just do it once and then use kind of a socket or some kind of remote evaluation protocol, some kind of communication protocol to do that communication and flag evaluation.

Now, one of the things that I think we all learned because I've listened into some of the conversations you had over the last week, especially at KubeCon when we were all there, but I also remember some of the internal conversations we had, and I'm sure this is true for many other organizations. Every organization that has built software over the years most likely had a requirement for feature flagging in some way or another.

And some organizations like we internally that I know, right, we've built over the years not only our own feature flag implementation, not only once, but multiple times. And I think defining a standard is so helpful also for any software organizations that try to consolidate their existing feature flag implementations. And I think, and again, correct me if I'm wrong, but I believe as you started digging around in the very early phases of this project, and when we realized that internally we even have different ways of handling feature flags, I think we immediately saw the internal benefit already of consolidating and standardizing because we shouldn't have multiple frameworks to do the same thing. Yeah, absolutely.

I mean, really, if you're starting from scratch, this could provide a means to get started quickly and have the flexibility to change in the future. Or if you roll your own solution, obviously that's not possible. So that's certainly one aspect to it. Also, if you talk to a lot of the vendors, they'll say one of their biggest competitors is actually just the homemade solutions, effectively. And then it goes back to the same deal. Like if you have built your own tooling, then you have to basically completely convert everything over.

And that process can be extremely painful. So that's where, if you could start with, you know, a standard feature flagging system, like a open feature, you could, it really provides a lot of interesting possibilities.

Even if you decide to use open feature backed by your own like homemade solution. Yeah. And that's really nice thing too. Like even if you had just multiple disparate systems it's writing a provider is not terribly difficult. So you can, you can wrap your, you know, current implementation in a provider essentially, and then use open feature to kind of help you transition and help you unify

onto a particular system as painlessly as possible. I think that's definitely an added benefit too. Looking at the current stage right now, it's time of the recording. We are at the end of May 2022. When people listen to this podcast, what is a great way to get started with? Where should they look at? What do you as the leaders like in this project? What do you want from the community?

What type of participation do you want? What type of feedback? What are you looking for? Sure. So at the moment, you can visit our website at openfeature.dev. And there's a number of links out to GitHub primarily. You can look at our community page. Feel free to join our biweekly community syncs.

The spec is ongoing right now. So if that's an area of interest to you, certainly feel free to review that repository and monitor the pull requests. You can also certainly reach out if you have an interest in client-side feature flagging. That's an area that we could use some help for research and SDK implementation. Same with server-side, too. There's a lot of opportunities for writing providers, hooks, a lot of code to be

written at this point. So if that's an area of interest, we'd love your help. We're also um in addition to uh sorry go ahead no no let me finish let let you finish sorry um uh so yeah in addition to um help the spec and help with the initial sdk implementations we're we're working on the initial architecture for that cloud-native kind of provider and the associated Kubernetes components and the operator, that type of thing. You know, more input on that is also something we could also use, I'm sure. I know that we are, on the Captain side at least, very actively involved with projects like Google Summer of Code or LFX Mentorship.

Are you guys also having any projects in these? Do you have any work in these projects? No, not yet. Certainly, it's a good idea. But the project's pretty new. So I think when they were looking for volunteers for that, it was a little project's pretty new. So I think when that, when they were looking for volunteers for that, it was a little too early in the process,

but hopefully if it's available later in the year or available next year, I think it's certainly a good idea to get involved. Because I think it's great, right? If you, especially if you have research tasks or some of the coding tasks, I think that's where a lot of people are out there and would like to get their hands dirty on contributing to open source

and if it's especially an interesting project like yours. But the good news is you don't need Google Sum of Code or anything like this to just become a contributor. Again, we will post all the links in the summary of the podcast so that people find Open Feature and all the community meetings and how they can contribute and get in touch with you. Mike and Todd, is there anything else we've missed out to explain on Open Feature?

No, I think we covered everything pretty well. Todd, do you have anything? Yeah, I can't think of anything we missed. I think this is a great conversation. Brian, did you learn something today? I sure learned a lot. I haven't been exposed to feature flagging too much

in the real world. We've had some interesting conversations in the past about it. Obviously, there's the I'm going to say obviously twice in a row, obviously, there's the obvious use of feature flags for code features or trying different colors, A-B testing. But I really like the idea that we brought up, and I'm not claiming we're the first to think of it, but having those performance options built in for certain conditions and tying that in with everything else i think there's a lot of cool stuff going on with this

it's going to be interesting to see how it plays out over time and i'm really looking forward to seeing what you all can do with it i think it's great that you have a lot of vendor buy-in already because just like we're seeing with open telemetry it's not about the the rudimentary component which is how do you set the flags in the code or how do you capture the traces it's about what you do with it which is where the vendors are going to come in so it's exciting to see some standardization on that back-end piece so that people can really focus on doing really cool stuff with that data or with that functionality.

That's all I got, Andy. I'm also at the last thought that I had, and I know Brian, the two of us, we come from a quality background, from a testing background. It's going to be interesting as you have many different feature flags in your code, which means you have many different

kind of combination possibilities. How can we make sure that we're testing in an automated way for all the possibilities? And I think you also want to, I assume, right, I didn't spend too much time on feature flagging, but you may also have some exclusion rules where you say if this feature flag is turned on,

the other one doesn't make sense, maybe. Yeah, like prerequisites. Yeah, that is uh yep exactly so and this also needs to be tested for right and that's going to be interesting to see how we can automate that yeah yeah and those are things that we haven't really fully explored but there's certainly possibilities of perhaps like as part of your pipeline sending in certain headers that could enable feature flags so you could really run some load tests based on, you know, different, you know, different stats, states of the flag, which then you can,

you know, generate reports and make sure that it's, it's, you know, running at an acceptable performance level or whatever the case may be. So I think that's, it will make testing more complex, certainly, but I think there's ways to make your pipeline aware of that and test for those cases. I mean, actually, testing has been brought up before, and I think that OpenFeature does, in many ways, simplify testing because now you have a single API to mock.

So to mock a single target for flag evaluation, for faking flag evaluation data, you know, and unit tests, it's now a lot easier, right? So some SMSDKs from some vendors don't even really have a concept of mocking. So you're kind of left to figure it out on your own. Now you have a single target for that, right? So you can inject a mock provider, just like you can inject any provider, you know, that's reading from file or reading something a file or reading something basically from a Kubernetes service of some kind, you can inject a mock provider. That mock provider can behave exactly how you want it to behave.

And it's a good target for testing for that reason too. Yeah, I like that. That's a great idea. Awesome. Well, gentlemen, Brian, shall we say thank you? And we want to have you back because I think this is an exciting project. Yeah, we definitely look forward to having you guys come back when, I guess next time you have some news to share about the project. At the very least at 1.0, we'll have to have another meeting.

Yes, even before that. Yes, and of course, Andy, I can't wait to hear how Captain integrates with it all at some point. Yeah, that's true, right? You brought it up now. I brought it up now. I'm getting ahead of the Captain episode.

Feature flagging. But thank you guys all for being on here really appreciate you spending the time hope the uh listeners got something cool out of this as well and if anybody has any questions or comments it's funny i always say this bit but no one ever has any questions or comments it's always just nothing so we answer we answer everything yeah yeah if you have any questions or comments continue keeping them to yourself how about that that's the feature flag I turned on. I turned on Snarky Brian.

Oh. Perfect. Yeah. Well, thanks for having us. Thanks, everybody. Thanks, Brian. Thanks, Andy. Thank you.

Bye-bye. Bye-bye. Bye-bye. Bye-bye.