Open Feature Project, 6 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project Meeting, July 6, 2023

Description

Meeting minutes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit

OpenFeature website: https://openfeature.dev/

A

A

B

C

Okay, hello, everyone: it looks like we're still getting some people, trickling in so I'm gonna, wait a couple minutes: um Mike Mike, who usually kind of runs these meetings. He is away today, so I'll be doing that I hope everybody can hear me. Okay,.

C

And I always wish there was a dark mode for Google Docs, but I. Don't think such a thing exists.

D

Why do you want dark mode for Google Docs? Just because you want dog mind for everything.

C

Yeah it just feels like I, have a huge vertical monitor here that I I usually have the meeting notes on and I uh dislike the bright white light. In my face: yeah I, guess: I guess: I tldr I do like dark one for everything.

C

Well, I guess: I want like an invert color mode, because it's a done mode is like not.

E

C

D

It's probably uh like a Chrome extension. You can find something I.

B

Would imagine sure.

B

C

Okay, um it's three after so uh we'll get started, but feel free to continue to add things to the agenda as we go and when we're finished what's on the agenda, we can just uh we can just talk.

C

um So a quick welcome for first time, attendees uh you're not obligated to introduce yourself, but if you'd like to uh you, can just unmute and do that or use uh raise your hand um with the Emoji reaction or whatever, um if you'd like to do that, or anybody who'd like to interest themselves.

E

Yeah I mean I, can I can uh can.

F

Introduce myself so.

E

My name is piklas I'm, an engineer at Spotify and we've been sort of looking at open feature for some time and right now with yeah, basically looking to to share some client-side mobile client-side SDK implementations.

E

So yeah I'm part of the team that also completes you know, is part of here as well from and Brian from from RM.

C

E

C

People from Spotify, okay good to meet you all.

C

Yeah indeed, okay, um yeah I, guess we can go ahead and get started so first thing on the agenda. uh Besides that roles for next meeting, uh is there any volunteers prescribed for this meeting and then as well as next meeting? uh We need some volunteers.

C

If not, I can go ahead and I'll just try notes, at least when I'm, not speaking.

D

I, don't remember, I could say.

C

Thanks Pete, okay, so um yeah so first topic, I had uh so yeah client-side, um I I, don't I won't name any of the organizations that I know happen to be using it right now, um but because uh I don't think um it's probably better to get their permission. But I know that there's at least a few organizations that are using our web SDK and prod um and uh I. Think that's great I mean I. Think it's pretty mature.

C

um The I guess I'm kind of skipping down to the second point, but the small concern I have for that is it's still labeled, experimental um and I think the reason it's really still experimental is because there's that uh spec PR request 171 for static Dynamic context, that's been out there for a while, and maybe the folks from Spotify could clarify this as well, but I believe they targeted this kind of draft specification with the static Dynamic context for their client sdks as well looks like that's the case, so yeah I I really feel that before we can kind of move these things towards 1.0 or even beta.

C

um That's something we kind of need to emerge so that we can guarantee some amount of stability there uh and that's not to say that it needs to be merged and to stay this in now we can totally make changes, but I think we need to spec out the the behavior for sure.

C

um So that's really the first thing I wanted to bring up um I, don't know if anybody has thoughts on that.

C

If not, the ask would be especially as we we go in and review some of the possible contributions from Spotify that, especially if you're a contributor to the spec go, take a look at that PR, um the the small uh bummer about the pr is.

C

It does cause a lot of thrashing in the numbers and I made a note about that in my um in my uh description of the pr um I, don't really I'm not sure how much of a concern that is, to be honest, I mean the the numbers changing doesn't seem to be a huge deal um to me, but it can make testing harder. Some some sdks specifically mention numbers in their test Suite. So that's a little bit annoying I'm open to suggestions uh in terms of changing that, but that seems to be a smaller detail.

C

So would love feedback on that PR? It's LinkedIn in our notes, um especially uh any of the the folks from Spotify. If you have thoughts on the the way that works, that would be. uh That would be helpful and insightful too, since you've implemented um some of that.

C

Any other any questions about that. Any other comments about that. At that point.

C

There's been a lot of activity on that PR, it's quite old.

G

C

I've tried to kind of resolve any of the open issues, uh so just could use some some fresh eyes: um okay, uh I guess yeah. The next big one is is the the Spotify sdks um kind of like I, said one out of order. So um personally uh I can review the sdks from like a spec adherence standpoint. uh I think um I think it should be fairly uh fairly straightforward. uh My only concern personally is I. Don't have Swift experience or kotlin experience.

C

um I've experienced a lot of other jvm languages, but not problems specifically, so it would be great to have people from orgs Volunteers in general, with familiarity just like, with Swift and Colin in general and app development um just to review the sdks.

H

I can help with Scotland if needed, but no commitment uh or beginning of July.

D

What are you are you taji mentioned spec compliance. Is that, like the main, is that the main thing we're looking for? Who is it like? Is it yeah? It's mainly that, or is it also just what other things should people be? Is there anything else? In particular, people should be looking at when they're reviewing.

C

Well, the the difficulties with sdks, um like the some of the biggest challenges, can be concurrency issues and language languages where that's relevant.

C

um So you want to take a look up for those uh I'm, not sure I, I really haven't looked at them at all, yet, um but from a spec point of view, Eventing is particularly difficult. uh Cavindu will attest to that, as will Lucas who's not um with us yet, but Eventing is Eventing, especially with multiple providers is very tricky, um so I'm not sure how much of the Eventing is implemented, because it's it's very new, um but that's a concern yeah.

C

My my main concern is spec adherence and then just language challenges, uh especially the concurrency like I mentioned. Those are really the big ones. um We'd also want to make sure that there's no potential uh spots in the sdks that could represent painful breaking changes in the future if enhancements are added. So that's another thing that we should keep an eye out for which again spotting that sometimes takes some language expertise, um so that would be good to have help with.

G

Yeah I can help a bit on the Swift side, but not as like detailed familiar with the spec. Obviously, as a lot of You Are.

I

We plan to merge this SDK to the openfuture.org, or is it something that's going to stay in Spotify org.

E

Again, I can actually uh well. We have that question up like so. Our idea is to uh to like that's our goal, to get these uh sdks, basically as uh full-fledged citizens of the open feature world, uh so basically transferring them. There I also want to sort of point out that we've like When developing these. This is the case.

E

We've taken um some decisions, uh as per like if you're familiar with kotlin co-routines, for example like these, like certain functions and certain apis, are suspend functions, which means that they need to be called from such a sort of um yeah such an environment. That can support that, and the same goes for uh for some of the Swift apis that are, they are sort of await, um um which means that they're asynchronous and that needs to be called as such.

E

um But anyone with some some context in those environments would would know um yeah and we're like yeah we're completely up for discussing all of this as well. The.

G

First, sort of like the the promise based or async based architecture like, is that something where we should. You should support both sort of synchronous access and um in promise-based, Access I know with like a lot of our sdks for Dev cycle.

G

Like we, we sort of support both where it's like um you can either sort of like do callback based architecture and do promise based architecture, because, um yes, like all modern, obviously Swift and kotlin and stuff like that, is moving towards like acing promises, but um there's still a lot of folks sort of writing a bit more Legacy code as well.

E

G

E

I think like that is uh exactly the sort of like discussion that we uh we foresaw uh when taking this uh decisions.

C

Yeah I mean I, I might not know enough about the environment, uh to really say, but um yeah and I guess one of the questions there would be if we were to implement a kotlin SDK.

C

um Well now that we haven't found SDK and if we were to move it into the org potentially, what would the providers, what would the candidate providers be and what apis, um what apis would be most compatible with those? So that was definitely something that that, especially in JavaScript, for instance, we considered like we looked at how many of the the backing providers that we first saw people making um were they were they asynchronous right. So I think that could be a potential question.

C

So I, don't know how many what kotlin providers might be written um quickly. I guess is, is a question. What vendors might be interested in writing providers? That kind of thing could help shed some light on that question.

F

uh If I can add a question there thought uh have you have you had any feedback from the community about the need for mobile? That's the case. Do you have an idea who might be interested in developing mobile providers on top of it.

C

um I couldn't specifically name uh orgs I mean one of the challenges with the project. Honestly, is that people use this stuff and we don't know when they're using it uh it's we find that people use are using stuff in prod, basically because they, you know, write a bug, they write an issue or they write a feature request, or they just say, hey we're using this in prod, and you know we just want to let you know. So it's really hard to gather that kind of feedback.

C

um It's it's one of the biggest challenges in the project, especially preemptively, before we've released something like a swift, SDK or call an SDK. It's hard to know who might use it, who might be interested I mean we've had a lot of people asking about python, so I I, don't know I'm, not sure. If somebody else on the call knows of of somebody who's, you know shopping at the bit to use open feature and in a mobile setting. Maybe you can shed some light. If that's the case.

H

uh One question: do you actually see create some equivalent SDK from scratch, because for me it would be just the job SDK binding, there's some more uh syntax sugar or do it should expect something to be created from stretch for Portland.

C

Well, I think what what Spotify is built is is completely from scratch and kotlin really targeting Mobile use cases right is that's correct.

F

I

I think the main difference or like here is like we are supporting the client-side API, whereas the Kion sites back rather than a server spec. So this is why it's it's a different SDK, but.

F

I

Could be almost the same thing.

C

Yeah, the Java SDK is entirely targeting server, I mean I, suppose you could use it in the client, but it's really built for server for dynamic context for every single request. It basically assumes you know, thread per request and and that you're on a server setting and the context is dynamically changing. That would not be the case with the kotlin SDK. It would Target the it does. Target the static Dynamic context or the static context that we've talked about um and I mentioned earlier in this, the the draft spec.

H

Yeah so, but yeah, basically it wouldn't make sense to have one gvm. Focused uh client is the key, so I just wonder whether it makes sense to prioritize kotlin in this case, because kotlin runtime is quite painful, so maybe it would make sense to actually create a pure Java SDK that would just Implement client-side and make it this rebootable for all the platforms.

C

Yeah, for me, that's an open question. I mean I. I, certainly am not opposed to a pure kotlin, SDK um I I. To be honest, I, don't know enough and I don't do enough. Android development to really comment on what would be more generally useful to the community I'm kind of of the opinion. If we have a Colin SDK, that's pure kotlin and implements the spec, um it makes sense to have it in New, York.

B

C

And I I haven't had I, haven't seen anybody. Volunteers, who've read a Java SDK for for the client can't.

G

You call kotlin code from java in Android app like I, believe.

H

The problem that, if you go this way, you have to include kotlin, runtime and quickly, runtime is very heavy, and for many users it will be a much concern in terms of security footprint of the library if you adjust your program. So this is why four libraries suspected to just go with a pure Java.

G

Very similar to the Swift swift, like it's Swiss, gotten better over the years with that, but originally how Swift had its own runtime in okay.

H

I think for prototyping, whatever works, I guess so in open future. We don't have much asynchronous content s. Otherwise core routines would be quite interesting. Top life for Po got on SDK. Maybe somebody who it together it will show the value for that.

C

Yeah uh I mean yeah I think these are valid concerns and it may be that we want to have a a Java. uh You know a client focused Java SDK at some point, um but yeah I kind of agree with I, don't I'm, not sure I, guess Pete Rhode, I kind of agree with the policy like if we have or with the idea that if we have a call in SDK, we should at least investigate it.

C

I would love to get something out there to help mobile users, because, like I said right now we don't have. um We don't have a lot of things to even offer mobile users, so it may be that we see a lot of adoption and we get a lot of feedback. And if we have people saying hey, I would love to use open feature without having to include a kotlin runtime. We can talk about. uh You know Java implementation, the target's client, that's my feeling at least.

D

Foreign just to clarify I, guess: I'm, not I'm, definitely not a Android expert either, but some some people on the call, no no more than I would um that the kotlin implementation that that Spotify has would it is, is the would it work fine with a Java um provider or a Java Android app, it's just that it would introduce that runtime requirement or or is that, would that be more issues than that.

G

That's basically, it I believe.

H

It depends on the implementation, because you can write a kotlin code which cannot be easily plugged into Java. So, for example, if you build everything around core routines Etc, it's just obtained to integrate with Java, but if it's done properly, there should be no problem to integrate it. So if you accept trade-off of kotlin runtime, which fun road I guess is kind of expected, when it should.

G

Work yeah, like co-routines I, think, would be really nice to have, um but I would sort of see that as an addition like, you should make sure that the base SDK Works without co-routines and then co-routines, are kind of in a like a nice syntax sugar for people who are just developing in kotlin.

G

um On top of that, that's kind of how we've approached it ourselves.

C

The other question, though, is slightly different than using a kotlin SDK in in a in a you know: Java uh Client app. um What about using a Java provider, plugging a Java provider into a column, SDK uh I'm I'm wondering what the differences would be there or if that would be a concern.

H

Ed quite well again, it depends on your implementation, but yeah in the principle there is no program is not quite inter-exchangeable. So unless you strongly depend on some implementations of the runtime, it should work.

C

Yeah and I guess that would be up to Providers. You could write a provider that would be generally usable and um depending on yeah, how you've implemented it um and what what apis it makes use of in the runtime. Okay, that.

D

Makes sense you, presumably if I was a if I was a vendor implementing um just a feature flagging thing for for Android I would make it so that it would work with kotlin and Java, because there's got to be people who want it to work with kotlin and Java, so I would I would guess that we'd run into less issues on on that side, unless there was something in the actual SDK itself. That was using something super common specifically sounds like.

D

Is there like something we can do? Is there like a specific like follow-up? We can do to kind of just like confirm it, because it would be a bummer if we um got all the way to kind of ratifying this and then discovered like? Oh it's just fundamentally, this kotlin thing can't run in a Java app or can't run with a without a kotlin like a fully kotlin provider.

D

G

Yeah I think you could confirm that, like you can run like a kotlin SDK in a Java app like I have it. We have example apps that do that yeah.

D

G

Can show you, but um but yeah there is that obviously, as I'll link describe the like the runtime um choice that they have to include that in your app, which can increase your app size and stuff like that yeah, if you're a job only app but I, think that's a fine trade-off for for where we're at right. Now.

D

E

And I I think that the sort of the biggest question is uh is probably like base it on kotlin Co routines and suspend functions were not um because that is probably what's going to be the pain uh if, if wanting to use it with a with a Java from a Java app, for example,.

G

Yeah like if we have, if it's all based on code, routines and suspend functions right now, then it's it's probably not super usable to anyone, who's, not building an a kotlin, specific application.

G

So that's kind of the trade-off thing.

H

Yeah, so it also means no Quito. If you want to do something good reactive, it should be quite handy for Pure, saver and communication, otherwise.

C

F

C

Think yeah I think we're still in preliminary stages here. I think that um we've probably gone as far into this discussion as as we'll be productive in this meeting uh I think that I will I will perhaps create an issue somewhere um and I'm, not sure where, yet um maybe in like a kotlin, SDK, uh placeholder repo or something like that, um and we can kind of kind of capture some of these concerns on GitHub um and then kind of formally start the review process.

C

So I'll I'll decide exactly how what what the best place to document that is and that'll respond in the open feature Channel. um So that's that's my takeaway just so we can track the review. We can have um asynchronous. You know further asynchronous discussions like this one, and that kind of thing um so yeah I mean I just want to say um on behalf of all the open, Future Community, thanks to Spotify, so much for for your interest in the project and for going ahead and creating this stuff. That's really great!

C

It's super exciting, like I said client-side is it client-side is specially mobile is very very new to us. It's untrodden territory, um so having having somebody with expertise uh just like take a stab at it is, is super awesome thanks a lot um yeah and if there's no more um discussion on that one, if there's no more points uh we'll move on to Cavendish point. So last call on that. Does anybody want to say anything else? Hey.

D

I've got just one one question more than anything else around. um Just the review process overall I know that we a long time back, we talked about uh having like oh maybe this is. That is exactly what Govinda is going to be asking about. Actually, with the um there was this gherkin-based kind of end-to-end tests that were kind of like described the the spec is there, do we have those for client-side, and would they be at all useful for this process of reviewing the kotlin and the Swift sdks.

C

uh Yes, we have them. um The the gherkin Suite is is currently implemented in all four 1.0 sdks um and uh it's also implemented the same. Suite is implemented for the web SDK. So there's nothing to the suite. That's like specific to um the static versus the dynamic evaluation. It's basically the same Suite, uh so I I think Pete. To answer your question. We could Implement those gerking tests in a hypothetical kotlin or Swift provider, uh sort of SDK um I.

F

Hope that answers.

C

Your question yeah.

F

C

I can uh add a link to that. um They are all using. They assume, flag, D and I. Think that's specifically what Commando is going to talk about, um but they they would I think they would work theoretically to validate the Swift and kotlin sdks. We're talking about.

A

Yeah, so to continue on that point, so right now the gagging tests. So basically the girl can Define the test requirements and then we use flag D to do the actual end to a new elevation. So the problem is so as soon as you have an SDK. You have to have the provider ready to run those States um or the basically, um in these examples, go SDK provide for flag D to run, go SDK test. So that's like a chicken and egg problem. So you have this GK.

A

You need to have the provider uh country uh flag, D, ready to run the test, so that's kind of a blocker, because if you are newly developing something you don't have tests because you don't have the providers built in or provided support. So that's where the question or the concerns come from from the end-to-end test strategy, and this was raised by the Thousand contributors, so Chan. So if you follow the open feature, uh Community thread, so there was some concern around that. So uh one thing we can do is of course canceling like this.

A

So basically we continue to build the SDK. So new implementations of SDK and wait for providers to adapt and then create the test, so it oh, we can switch it to SDK side, only so basically having a built-in provider, simple built-in provider, like in memory uh by evaluation or environment variable provider, so we can do some end-to-end validation based on that provide implementation, so that that's that's the proposal. So if someone know someone has any other opinions, so I'm open for this or else we can continue with an offer and discuss more there.

C

Still Mike and my my concern I, like I I, totally see the issue. um My concern is that the uh the thing that flag be really gets us in this situation is something capable of doing Dynamic evaluation and by Dynamic evaluation. I mean it takes some context.

C

Context is the word that we use that a lot of other sdks kind of use, the user or some call it context uh for, but it's like attributes that are a factor to a differential evaluation or a dynamic evaluation right so flag D can actually take these attributes and then use them to determine intelligently the result of the flag value.

C

uh The the important thing about that when it was when it comes to an end-to-end test. Suite is that part of one of the jobs of the SDK is to take the context, however, that SDK defines context and pass it to the provider. The provider usually serializes that in some way, maybe sends it down to the wire, maybe uses it in evaluation that does locally, but it's still the sdk's job to get that context propagated to the provider correctly.

C

So to really test that in an end to end way, you need a you need a back end that is sensitive to context and can actually use that context to evaluate a flag. So.

D

C

A minimalistic way go ahead. Pete.

D

I mean it doesn't seem like that would be that hard to do in memory provider just like if I was, if I'm thinking. If I was writing this test, Suite from scratch, I'd just write like a really basic good memory provider. That has like some kind of like magic thing where, if the user ID is five, then it was true and if they use ideas, six, it's always false whatever and then.

A

F

A

That should be possible, I mean like flag. Db can use Json logic, but we just need the agreement to do that and if we do have that, uh that removes this chicken and a problem and also could be easier for new SDK implementation to follow up because with the SDK you have this simple inbuild provider, which is common for all the sdks and the testing. E3 testing is loud, no codependencies there for flag deal any other system, so.

C

Yeah I totally agree with. With both your points. We could easily Implement something like that. So I think. Then the question is I. Guess I've, three thoughts that Amelia kind of I had when we talked about this. Do we implement the provider you're talking about as a real provider that we publish? That's like a really basic one that uses Json evaluation? It's all local! It's based on some file. It can easily be used for testing.

C

Do we make it a kind of it's a very simple mock one that like Pete, says it's just if the user ID is five, it returns some something and it's purely useful for testing in our end-to-end test Suite.

C

So those are the two questions and then the the last point I'd like to make. Is it's true that we can build this, but it does sort of add a variable to our end-to-end test Suite that assumes that that provider that fake provider is built correctly, whereas we, if we use flag D, it's the same thing across all of the sdks right, this one artifact, we know works and we don't have to test it's. It's already tested just is done and works everywhere. Those are my three thoughts.

C

A

A point there so provider as a provider flag. This is feature complete, oh yeah well tested from as an individual component and it's a single point for all the sdks.

A

But then we still have that dependency issue, especially the circular dependence issues in go SDK, so I have seen that and it's really hard to get rid of so yeah but on the other hand, uh compared to let's say mocked provider having a simple provider built in makes sense so yeah. So we can argue on both sides, so yeah. What we can do is continue with an offer and then have a discussion there and see the pros and cons and see what what parts we are choosing here.

A

I think it will help the community in the long run.

C

Yeah without belaboring the point too much I'm just curious, um Kevin doing Pete, specifically or anybody else who has a take. uh Do you favor doing like a test double as Pete is calling it or more of like a a basic but fully functional provider?.

D

Yes, a test double, which is a basic, fully functional provider. I would say: I like I like personally I would, um if it was me I would I would make something: that's flexible enough, that I can that the tests can be expressive and not weirdly magical. Like oh user5.

D

Is this special thing in news of seven it's a special thing, but I, don't I'm, not sure I personally would go all the way to what Govinda is saying with like a like Json logic, or something like that, because I'm not sure it's necessary I would I would not.

D

I would not do like a full, completely compliance provider, because that, like there'd, probably be like I, don't know, 60 no 40 of the code in that, provided that's not necessary for this end-to-end test and um and like unless, unless there was a way yeah, it is, and unless that provider already existed right like if it was the the JavaScript I would consider like making like a a fully functional provider. That's more for people getting started or for demo purposes like we did.

D

We did some of that with the JavaScript SDK, where I kind of put together a a full-fledged uh like a very basic but full provider, partly because it's.

C

Like a file based provider like not.

D

C

D

Memory just in memory yeah, because you don't need the file based like in the that's, that's exactly the kind of thing I'm saying of like I. Don't think it's worth doing that for for this purpose, because you don't need to do it and it just makes it more complicated and more.

A

D

A bigger risk that there's a bug in the provider that, rather than in the tests and then.

D

One thing, I would say is like I would 5 000 times prefer a custom kind of test double than using like a mocking framework to build a provider that would be.

B

Something I would say is a bad idea.

D

C

Yeah Okay Kevin: do you want to maybe make an o-fep, then is the takeaway for this, because it sounds like there's a decent amount of Interest exactly.

A

I'll open it up. If uh with the concern, we are having right now and those proposals and we can discuss e yeah.

H

Yeah, since the American framework was mentioned so I briefly discussed it with a few contributors but I'm currently building a demo that would include open feature and wire monk with jhpc adapter. uh So if someone is interested, there will be actually some well, let's say, prototype adapter, maybe next week ready for evaluation. uh So if you want to try it out but yeah um adjusted to the total Creator, because my ID is to actually use it for generic protocol and right now, I'm using one of the vendors as a proof of concept. For that.

C

Absolutely I keep us updated drop something in the channel and uh when you have something to show well.

H

This continuous thrust fixes so it gets delayed more than I expected, but I just gave up and switched to go one. So it should be easier.

H

C

You're next on the list.

I

Yes, uh I wanted to talk about the flag, Evolution Warrior provider, so basically, for we don't know it's like um we wanted to introduce like some generic providers that can communicate with grpc or RPC based communication to any flag system, backend, that is doing remote, flag evaluation and we have an effect probably for this, but we still have like some, like not everyone agree about the need of this one. So that's why I wanted to bring it here and to be sure that we can? We have the opportunity to discuss about it.

I

I think the main use case was for open source projects, so they kind of like just plugged in one provider that is generic enough. So any flag system can trust like comply to the a PC based schema and be able to do flag evaluation without for open source projects to have to onboard like a lot of pro custom-made providers or having to prepare a plug-in system to to have like providers into the open source solution.

D

So I I was asking about this in the slack I. Think the one of the big questions I've got is why, in the context of in this example of I, think we we kind of refer to to kind of Jenkins, but obviously it's more than just Jenkins right.

D

The example of like a platform thing that wants to allow its consumers to configure feature Flags in that platform like internal feature Flags in that platform um at runtime like why, wouldn't they just use flagged it I, wouldn't Flag Day, be like almost exactly The Right Use case, because I just don't see a scenario where and Jenkins or any any other kind of thing would say like we. We want to do this. Allow this support for people to configure fridge Flags. So let's go and build a feature flagging back end.

D

It just doesn't seem when there's a when there's like this native flagly thing built.

H

Let me clarify the use case, so, of course, flag. D could be one of the options, but here we are talking not just about open source projects, but rather about adopters of Open Source projects. So, for example, if you run kubernetes taked on Argo whatever in your environment- and you want to use some feature plugs supplied by this project and hence you would like to connect to your feature, Flag Management solution. So Jenkins he is probably a red herring because Jenkins has a plug-in engine, so you can easily have SD cases plugins.

H

If you invest some time but the real deal. There is a number of smaller projects that use basically uh Native fields that do not have a plug-in framework embedded like, for example, so kubernetes has embedded framework, but the vast majority of cncf projects actually does you have plugin like a system? Yeah ID is that if they can somehow take a generic SDK, they could let their users to choose a feature flag provider. They work for the ages. Keeper could be one of the options, but the other one.

H

Some other people would like to take uh go feature box would take Cloud bees me Etc and uh for me it would be important to have basically this Choice uh delegated to the end users of the product could act as a bridge as a kind of performance solution. Yeah.

D

That's I mean that's the I guess so I always get into trouble when we talk about flag D, because I I think I always get confused as to what it does. But I thought that one of the things that you could do with Flag Day is have it plug in a provider into Flag Day and then lets it talk to another back end. So like it's a kind of like a runtime like a uh sidecar adapter. So so wouldn't that be so I guess! That's that's what that's the uh kind of the architecture!

D

Grandiose call it architecture, that's the architecture I was imagining, is you've, got your Jenkins or whatever that's got open, feature SDK and plugged into Flag Day and that's baked into the the platform and then it's doing to flag, D and then and then uh I'm a consumer of of Jenkins. That's you know, working in Enterprise Corp, whatever and I have my feature. Flagging solution.

D

I then configure flag D to talk to that uh feature. Flagging solution, using whatever is the appropriate provider and plug into Flag Day, and then uh it works.

H

Yeah it's possible, so the downside of this approach is that you basically have plugged you as a proxy. So when you build a plug D, you need to embed your provider for that and then basically maintain this as a solution So in theory, if there are open feature providers that already run on premises, for example, go feature flag instead of using plug d as a kind of for proxy, you could just connect Google feature plug directly. If there was a unified protocol, yeah.

I

Yeah, so another thing is also it limits what you can do with your feature, Flags, because you need to flag the as like. You cannot expand more than future offered by Flag Day. So um here you have like providers that and send everything to to the backend, and you can just do whatever you want. I'm, not sure if this is a strong limitation for most of the almost most of the use cases, but for some it may be, or maybe like a limitation.

A

I

A

Yeah one one point so regarding the flag, the architecture, so basically it doesn't have any UI or anything like that, but it just exactly acts like a proxy and expose feature flag defined in multiple sources, files, kubernetes or HTTP endpoint. Yes, it can act as a proxy, but uh uh yeah like Tom said it's, it's just a proxy, so you can't directly connect to your in provider through that so or you have to support that and build the extensions there and so on. So.

C

Yeah, the the the the the other thing that I think is is probably material. um Well, firstly, I should say plugins using flag d as a proxy right now is not possible. Like it's hypothetically, close to possible, you can't do it right now.

C

um It could be made to to happen with relative ease, assuming that you have providers for go for the back-end vendor in question, but the way I look at this whole proposal, it's very similar to I think the easiest way to kind of communicate. It is like just like people build um Hotel, metrics, endpoints or Prometheus metric standpoints into their third into their open source. Apps right, you could build a flag, a Flag Management protocol into your app and, and you would not- and if it was.

C

If we actually said this was an open feature standard, not a flag, D standard I feel like it makes it a much more attractive proposition because flag D is at the end of the day. It it's not really open feature flag. D is, is a very basic flag: evaluation Daemon. It is not the open feature. Project I feel like if we were to to ratify this ratify some some kind of protocol. Some wire protocol, like you know, Thomas, is proposing.

C

um It would be a new direction for the project, but it would also be a new direction for feature flags as a concept like we could just say here now you can you can, in your application, in a totally vendor neutral way, given a back-end proxy. That's compliant to this basically add any Dynamic evaluation. You want to your application as long as it's it's been baked in there, just like you bake in Prometheus metrics, and you bake in hotel, metrics or traces.

C

That kind of thing and I really do think it could be interesting for for vendors, um for the open source world, but but I I do I, I, guess I kind of see some of the concerns, because it's a new direction for the project, I think I think that's something I kind of want to highlight.

G

The the funny thing is the first thing. I thought was that it might actually be more interesting for the client side because, like if you can create a like a vendor, neutral API for the client side, then you could basically like just have the open feature. Client-Side SDK, as your interface to um you, wouldn't need to bundle the sort of the the providers SDK.

G

Alongside with that and like the open feature, sort of a client-side SDK could be just the the only endpoint and then you're just plugging in sort of a different endpoint um for different providers um so like that was where my brain went first um and for contacts we like for our back-end SDK is a Dev cycle.

G

We have both a cloud version and a local bucketing version, and most people go towards the local bucketing version, but there are people who use like our API version of our our our our our our our our server sdks for certain use cases which I can get into if you're interested, but um that's kind of what I'm thinking this is. This is plus plus sort of like the proxy use case that we're talking about.

I

I think one of the benefits is for the adoption of the project. It's because like if you are a vendor, you just have to have your server compatible with the open feature like a schema and you don't have to build your provider. So it makes also easier for studying to to be, if you're, a new vendor just to be compatible with open feature in a in a short way. Let's say it's, probably not the most efficient one, because you don't have local evaluation or whatever, but at least you can check, say um open, Future, compatible.

D

I guess I'm I'm super skeptical of that last part, because if I was a if I was a feature flagging, vendor um I would want whatever I'm like like releasing as a that as a kind of blessed kind of.

F

D

Product to be like you know, to work reliably to be kind of like production grade whatever, um and that means you've got to build all the caching and stuff on on the into the provider. There's no way that you can just assume that um every time I need to do a flag evaluation, I can make a network call right. So now, I've got to build at least the caching and probably the rules engine into the open feature. Sdk.

G

You'd be surprised, the number of people that we have using uh like we have. We use like Edge workers for this API and so like you can get probably 20 millisecond 10 millisecond response times from like Edge workers for this type of use case, um and there are a decent number of people who are solely relying like, obviously not super high scale, like all those customers go to local, but for like low to medium scale.

G

It's a much easier entry, it's an easier entry point than um than having to sort of like bundle, a larger, totally.

D

I totally believe that, for someone consuming feature, Flags like I would definitely consider it, um but if I'm a event, I think as a vendor, I wouldn't want to release that and put my name on it as like. This is the only way like this is the way that you use blah using uh using open feature, because it just feels like the experience would be as.

H

A vendor you don't have to uh so it's basically your choice, yeah.

D

I totally agree, I think all the vendors would choose not to that's that's the big concern I have is that no one's gonna snow, like the vendors are not gonna, uh are not gonna, say like oh yeah, let's, let's Implement a let's implement this y protocol and I get the semantics exactly the same. It.

I

Doesn't mean that you have to go like uh like remote every time also, we can also build some standard caching uh thing in a provider that is there for everyone, so yeah you have like already a caching system. That is maybe not the best, but you have one still so yeah.

D

I

Mean, like that's.

D

Like I feel like I, feel like where we're eventually going to get to is the same thing that every freaking feature flagging vendor goes through. Where they have this conversation, like uh I, don't know, then maybe you can relate to this. Like you start off by saying feature. Flagging is a pretty straightforward problem. I'm pretty sure we could solve this in.

D

um You know a couple of weeks of Dev time and then in like two years, you're like oh, my gosh, maintaining all of these different providers and making sure that the caching and the rule sets works correctly.

D

Like it's I feel like we're saying like hey, we could just like pretty sure we can just solve that problem and I like I, I, I, guess I'm I'm I'm not like I'm, not like super super opposed to it, but I think that we're I I I worry that we're being a little naive as to what would be involved in making this actually work and and being a bit nice.

J

I, don't you never get I it's important. It would be impossible to find a common denominator of of rules and things like we. We talked about this a lot internally when we got introduced to the project, and that seems like an unstarter and don't tell anyone, but we still find well, don't tell anyone they're all public. We still find inconsistencies between our rules.

J

Engines between our languages is really a massive massive can of worms and, um and then yeah, and you start to like you know, the HP doesn't have shared memory, State between requests and all of a sudden, you're dealing with stuff like this, rather than like yeah.

J

What you're, like so far down a whole shaving things that is like you can't see the way up.

G

C

G

Be like treat it only as an HTTP like interface that people in certain contexts um would use like, for example, if you're writing like a edge worker right like you, might want to have an uh a vendor agnostic, like HTTP interface, that you can call for future flag values right like like, if you're writing like there's a lot of people, sort of adopting that right now, um and so like that's a use case where, like an a vendor agnostic, sort of uh open feature, um um HTTP sort of interface could be very interesting for those, but um but yeah I would I would avoid trying to like bake in a bunch of logic on top of um that interface and just keep it really simple, where it's like you're making a call to this this interface and it's just making basic HTTP request, either to a locally run proxy or a or a server somewhere to return new values.

D

I guess like at the end of the day what I think about is like it's a if the goal is to allow something like Jenkins to someone to run something like Jenkins and talk to their provider of choice, which could be in a bunch of different Frameworks I I feel like. If we go on this y protocol thing, then we're back to the end times M thing where, in order to to make sure we sit, we hit that we need every vendor to have implemented this wire protocol right like I like it sounds like this.

D

What we're saying is in order for against that use case of like I'm, Jenkins and I want to talk to launch Darkly uh or I want to plug I want, as a user of Jenkins I want to plug Jenkins into launch Darkly I can only do that if launch Darkly has implemented the open feature of wire protocol.

H

Or we have pluggedy as a proxy for generic use case. Yes again, it wouldn't be optimal, but it would be a kind of Rich solution for those who need it.

D

Yeah I mean yeah the Counterpoint.

G

Is it might be easier to get providers to do that than like build out eight or ten or, however many different providers? Ultimately, you need to to cover all the sdks you're going to have foreign.

G

C

Considering some, some providers do already have proxies that you can deploy in your infrastructure, which I I I mean I, get what you're saying you don't want to do remote evaluation, um but remote evaluation when you're talking about a call to localhost potentially like.

E

Yeah, it's a totally.

C

Different thing I mean something you know guaranteed to be in the same virtual data center or whatever it is I.

D

Mean again, that's why I go back to like yeah. It sounds like Flag. Day would be great.

D

The thing I don't know like yeah I I that I'm gonna say like what like my last point is that, like I kind of feel like this is a very, very Niche problem like I, don't actually think there's anyone that many people I'm sure there's someone out there, but I I would be surprised if there's that many people out there that are like I want to do a b testing on a Jenkins feature as part of running it locally right like well.

H

It's not about EBT, it's uh especially about configuring, the problem, yes, big projects, including cncf ones. Already they have notion of future flux, whether it's environment, variable property files or whatever you take Yeah. So basically, by providing extended interface, we allow um people operating police services to connect to them to the standard feature, flood Management systems and their infrastructure.

D

Like that, I don't think anyone's like I want to dynamically reconfigure the feature flagging for Jenkins they just want to, like maybe configure it in a yaml file just like they're doing today, but like I I. It feels like a solution in search of a problem. To me, to be honest, just.

J

Just one I know we're really short on time, but one thing that we haven't really talked about, but this has been a really constant background hum when we've been building flags with, is that product a b, testing folk, an engineering Folk are quite often different and have different needs and we've strategically stood pretty much.

J

Every decision we've made in the engineering Direction just because we wanted to not have to deal with these sorts of problems and requirements that people have um and I feel like I'm wondering whether open feature might be still, you know, steering yourself in or it might have found itself in the same Waters right where um that there seems to be it's kind of difficult to get um satisfactory answers to both of those groups of people in terms of the requirements they have, because even like some, some products and a b testing teams will be like at five milliseconds, isn't good enough right, like I've added latency onto our requests, they'll be like we're not happy with that like so we just go all right, we're probably not vote for you and that you know or you're.

J

Well, that's why we wrote the local evaluation on server side, but yeah.

C

I think that's a good point. I I think we got to table this discussion. uh We can move more of it to the issue. Max has another point and we have two minutes left so I'll try not to hurt you too much Max, but sorry.

K

B

David's, a performer yeah, thanks yeah, don't worry about it. uh Mine is just a quick update of the meeting we had last week with Emily, so um just to kick off incubation, there aren't any major blockers. The only thing I put in here is there's kind of a bit of inconsistency when it comes to the versioning system. So in one point it says it's required and then in another place this is just a guideline.

B

So that's like just one thing: we need to kind of fix um yeah other than that I'm still waiting for the um service ticket from the cncf to get approved to get the space for the due diligence document, but that's pretty much it. Nothing else has happened. Everything else looks good when it comes to contributions and adopters and everything. So, ideally, if all the adopters that we have listed or that we've uncovered from now on respond for the interviews, we could reach incubation by uh cubecon North America questions. Doubts.

C

That sounds great kubecon incubation by kubecon n a would be huge. Let's.

B

C

K

Yeah not to since we only have a minute left, I think I can express the thought in slack and just get some feedback there. It's uh kind of we had a discussion a couple of meetings ago around the Ruby SDK um I chatted with Jose briefly in DMS, on the cncf slack and he's interested in handing maintainership off and I would be well or I would be interested in taking that on from our side, I just have a couple of like project structure, questions slash.

K

um You know next steps for moving some of the work that justworks did on our sorbet aware SDK into the the main Ruby SDK, um not sure we don't have time for discussion, but um I'll illuminate some or add more thoughts on slack after this.

C

Okay, thanks Max, sorry that we've uh kind of killed your time. But please um please make a comment and.

F

And slack and if.

C

You'd like to we can put you at the the top of next next times meeting, if you'd like to to go into that with a little bit.

K

More yeah, if I, don't if I, have more questions or like feel like we had any more discussion. Time. I'll, add an agenda item for next time. Foreign.

C

Thanks all great meeting very interesting stuff, thanks for coming everyone. Thank you.

H

B

H