 Good morning. We'll give folks a few more minutes to come on in. Everyone has made their last minute- slides, right? Like, no, no, none of that usual thing, none of that. Everyone goes, yes, yes, uh-huh. I'm not refreshing them. I say this every time and I'm not doing it. Amy, why are you looking at me? I'm looking at all of you. It's collective. There's all of you. I think you just need to enforce this and just never ever reload it. I mean, I've tried and then everybody's like, oh, but I had something good. Then it just turned into like, all right, fine. Learning through pain. Let me check to make sure that Liz didn't tell me that she's not coming or something that I've missed it. I don't think so. Excellent. Okay. I was just looking around on my email to be like, did Liz tell me she wasn't coming? Did I miss her? Everyone, trouble for not having a, you know, the last minute festival of the slides in here, but I will go ahead and post slides as well. All right, should we get started? Indeed. Hello everyone, welcome. Okay, so- We've made it here. Sorry, say that again. It's the, you have made it here slides. Yeah, exactly. I'm almost, almost here mentally. Yes, I am here. Right. So projects that need to see input. And I know there's some, I'm looking at this and thinking of these, these are all annual review ones, right? So these are our current annual reviews out here. We've got a brigade network service mesh. We've got open EBS QB edge and telepresence and all of these need to OCI is on them. Oh, yes. Yes, exactly. Hello friends. Get in there. We also have some incubation. Those votes went out yesterday. So we have TIKV and we have Rook that has gone out. I left those alone as far as like the projects needing TSE input, but the vote reminders will go out at the end of this week. So lots of good things happening running around in here. That's great. And I think there's also some projects applying for incubation where we need some sponsorship from, you know, some of these are included a little bit further down. Okay. Great job of being able to shepherd them. Nope. Nope. We are all good. This is all lovely. So. All right then. Any comments on this before we move on to SIG updates? Let's say it looks like SIG app delivery up first. Let me see if they're on the line even wandering through and it doesn't look like we've got any of those folks here. So that being said, we've got some cloud native summit China talks, which is kind of exciting in here. That's kind of one of the things that I wanted to highlight was, hey, look, we are going to be able to do that and then they're doing things. So other fun things just in Cormac cloud native build packs. Yeah. Yes, I'm working on it. Yeah. I'm looking for looking for end users who are using it. If you are one such please contact me. Lovely. Or if you know of anyone, if you know of anyone who knows of anyone who's using cloud native build packs, send them to Justin. Okay. Right. SIG app delivery arrives. We can we can come back to that. We can move back. We're good about this. It's fine. I think I saw Paris is here. I don't know. And I'm actually taking Josh's place Josh was supposed to be here so I'm kind of doing what the JavaScript community calls battle decks right now so Josh could that be your sense of regrets. I am here in his deed. Hello everyone. How are you hope everyone's doing all right safe, staying inside staying sane and things like that. I've actually been doing a ton of work inside of this SIG. And of course we're always looking for new contributors. The first thing that we have published is a letter sent to the maintainers with a survey link and a ton of other stuff. So the reason I'm here for TOC and everybody that's on this call right now is to please take the survey, not only just the survey inside but there's a ton of other introductory information about our group in there and how we can provide support to your projects. So I'm doing sort of this as a focus group style because we know that people have survey fatigue so you can you might catch me at one of your projects community meetings might come introduce myself and say hello and do sort of a live question and answer session if folks don't necessarily have the time to do the survey. The survey is important to us because it has to do with where we're going to be starting with a lot of the sub project activity that I'm about to tell you there is going to be a CNCF blog post that pretty much reads as this letter but just in a blog post format that Juliet CNCF helped us out with that's going to be going live this week. So you'll also be able to share that as well. We did have a change of chairs as well lately if anybody missed that. Jared unfortunately has some personal obligations that he wants to tend to but he's still going to be sticking around and contributing to the group. Steven Augustus is going to be stepping up into the chair duties so you may see Steven here next month doing the status. And then as far as some of the sub project activities to drill down a little bit deeper. We've got a governance working group now that's spun up officially a contributor growth group that's spun up officially and maintain our circle. We're almost almost there. Just some highlights in each one of those. The governance and actually the contributor growth that doesn't have a bullet there actually moving their meetings based on growth of both of those working groups and the people that are now involved in them. So those meetings are now being moved to accommodate better times for those folks on the governance working groups also been working on the maintain our multi org requirement. It's obviously a very testy issue that you all have seen that Josh moved to the TOC repo instead of our contributor strategy repo. The TOC members and the community is also very welcome to look in our issue log backlog inside of the contributor strategy stuff that's that's just things that we're working on that make it moved over to the TOC repo one star in a better state. As far as the maintainer circles is concerned this is something that I'm really looking forward to myself personally, but just getting maintainers together on a smaller scale but a lot to talk about topics that are either learning or something that can be taken away in a value add one of the first maintainer circles that we're going to run is going to be on inclusive language. So we can all talk together about that I know several projects have already made huge strides in this area some have already submitted and approved PRs. Others are forming working groups like Kubernetes. So how can we all learn together from that so that's going to be the first maintainer circle topic. Karen Chu is going to be helping me Karen does great events and if I'm sure everybody on the line knows Karen. So Karen's going to help help out with that as well. The contributor growth team has been working on documentation template and the idea of a template repo for projects to fork. Essentially, with some templates in there like contributing guides author author md etc. And this also I just want to reiterate is based on a lot of the survey feedback that we're going to be getting back. So if there is something that you like about a project please fill it out. You don't even necessarily have to fill out the whole thing. This is just really about like best practices and how we can surface that data right. So, I've already mentioned the bullet below about Kubernetes working group naming we are obviously staying close to them with Steven now being a chair of ours as well. So we have some of that continuity there, which is nice. This is also an open invite for all of you to attend our bi weekly Thursday meetings, or any of our working group meetings, the next working group is actually today in a few hours and that's the governance working group. We also have been doing some side reviews of projects that's not even necessarily on the slide so when I say we've been busy we definitely been busy. And like you badge and some other folks. So if there's any to see members here that would like our official guidance or weigh in or anything on any for any projects on deck just let us know. And that's it. Fantastic. So just to double check on the survey. Do you want maintainers of existing projects to answer that maintains of any projects what's the kind of any one that considers themselves an upstream contributor will work out the fuzzy details on the end. We just want to hear kind of from everybody that's working upstream. So, maintainers are, you know, the most preferred especially because there's some kind of questions on there that will feed into maintainer circle as well. So, main to maintainers the preferred but I'd rather see all projects represented then wait around for very big maintainers and like I said, contributing to a project could be for sure. Great. And then we come back to the multi organization issue at the end of today. But aside from that anyone got any questions or comments. Maybe with my maintainer head on the one. There is already a maintainer so which since you have since out every year will those be spliced together going forward. I mean, this is, you can see on the survey itself it's a much more deep dive into the actual mechanics of how you run your groups, whereas the maintainer survey I think it's like a pulse on CNCS work and a pulse on the TFC and a pulse on, it's just like a general, just pulse of how you're doing I think, where this is like, hey, do you all have contributing at markdown files do you really like them, like that kind of stuff so feel free to delegate to I mean, if you are a busy maintainer, and you've got folks growing up in the ranks say here take the survey. Take the survey for us kind of thing that's fine. But like I said, I am one I'm happy to, you know, definitely combine in the future, but this is hopefully a one off, and I don't necessarily see that you know going into this depth from here on out with 50 other projects. Oh, I'm on mute. Okay. Unless anyone has any more questions. Thank you Paris. Thank you so contribute to strategy. Who's next network. Network. Amy, can you refresh this. No, I'm just, just kidding. What I wanted to mention on the slide is the, the fact that contour as a project has been voted in at incubation level. So welcome contour. There was a much diligence on the project. The folks are folks pretty pumped. It's good. I'm just getting accepted three sandbox projects have also recently come through and been accepted into sandbox. One is Kuma, another BFE, and another CNI genie. So congrats to those projects those maintainers. And the next one is also up for review under the news sandbox project proposal process and is reapplying for consideration. Well, in some respects, Paris is making us look a bit bad. The, the, we've been busy as well, although we have not not as many updates since last time we met. We're working on collecting interested parties in the as we go to form the service mesh performance working group. Some of those early interested parties are listed here. We also network service mesh is up for its annual review it's a sandbox level project. I think that's that's probably in the queue that we were talking about earlier for the TOC. And in queue for TOC as we recently received a presentation from the ambassador project, and they're applying for incubation level consideration. And that's, that's it. I'm interested in two notable exceptions who aren't on the participant list for the performance working group. I guess Nighthawk Envoy is that is that Envoy the project and the other one, Linker D. Yeah, Linker D. And yep, that's just oversight and I think on the listing here is actually the list of interested parties of the service mesh is specifically that are interested in. There's multiple aspects of what the working group is going to be walking through. The short of it to your to your question is, there's actually a long list of service meshes that much earlier on have express interest and desire to participate. Linker D is certainly one of those. Linker D. I guess I won't, I won't go. Won't go through the list, but it just, we've, we probably talked about 20 different service meshes. Each of which, at various points have said they are keenly interested in understanding their own performance and being kind of well, you know, being well represented in under that topic under the topic of performance. Any other questions for SIG network? Yes, I'm kind of new to all this. So I have a question. We are a telecom company. Actually, we are, it's a Mavinier. We are in 5G radio and the packet core and recently you probably know we won this project. So how do we inject telecom specific requirements into it? Because we have a lot of questions on mesh. We are currently using Istio, which is not very good to what we are doing to the use cases that telecom has. How can we collaborate and inject our view on what needs to be done? Requirements, because we are to the point where we even thinking of building our own lightweight mesh, because Istio doesn't work well with what we need. Yeah. I'm really pumped that you asked that question. There's a lot, the short of it is, please come to the next, we'll make that a topic of the next SIG network meeting. I think actually last time that we gave an update to this same update, we were talking about one of the focuses of that, that service mesh working group being on patterns and practices and those patterns of how people are using and kind of are using a service mesh is inclusive of what it is that users really need. We're not in a position to give feedback to each of those service meshes, those are relationships that we're frequently spending time with. We're not in a position to dictate to them what to do, but what all have been receptive to this type of feedback. And so, yeah, please ping me in advance of the, or Ken Owens, the other chair on SIG network in advance of, just after this call, that's a very interesting topic. Yeah, and we can, we can discuss about the deployment of what we are doing in public network versus private network and how it impacts networking in general. It has much more, I would say, dependencies. It's not just service mesh. Service mesh is very impacted by what we are doing. Would be very interesting to discuss. Totally. Thank you. Thank you, Ziv. Great. Any other comments on SIG network or questions? All right. Who's here from SIG observability? Yes. Can you reload the slides please? No, just joking. Yeah. So, from our end, there is a threat which is kind of long lived about the tech lead. Amy told me she will be sending the formal voting thing today, which I felt to do. Sorry for this. For the third chair, we are looking for nominations again. So anyone who has any suggestions or interest or anything, please focus. Also, we will have our next call right after this call. There's an update on incubations. Actually, I didn't update the slides, but that's on me. Cortex did answer the questions that they are currently in progress with, with getting back on all the utility questions. And Thanos is not in the public comment phase. We did start work on on data analysis as a subject and we started with the document which is collecting use cases and we will be discussing this in 35 minutes. We also intend to work on best current practices talks, but there's nothing yet which which we could link or show. That's a real quick update. I'm so glad you stated out what BCP was so I didn't have to ask. Yeah, I realized it's like it's a super common term within ITF and the networking space but it's not so much. It's the best current practices with with the emphasis emphasis on current as an acknowledgement that this is always changing. Okay, so I guess if anyone has any ideas for good nominations for a third chair for sick observability. And that was a good time to get in touch with you. Any other comments or questions. So on the on the Thomas due diligence very, very well done, especially for such a relatively newly formed sick. I've been passing that around. And the example of how to do a good due diligence of a project so well done. Excellent. Who's here for runtime. And that's me Quinton. Hello. Cube edge is a project that we've had in sandbox for a while now. They've applied for incubation. They've done a great job of putting all the information together for the due diligence. We're just working through some of the final steps there but it looks pretty well set up to be kind of done in time for cube con Asia. And then we have a quay which is applied for incubation. And that's going through due diligence at the moment. It's looking for a to see sponsor if anyone is willing to do that. Okay, by the way, we do already have to see sponsors. So really, really I'll just sort of following the process now should go into public comment. I believe this week if I'm not mistaken. Elena is here she's been doing a great job of looking after us as a signal. I also had a bunch of interesting interactions with a bunch of different projects. And so maybe I should actually step back to runtime is is a sick which which deals with all things related to containers essentially container run times container orchestration container registries. So we've been doing a pretty good job and actually one of my coaches Ricardo has been doing a really good job of reaching out to projects that are kind of outside of the direct CNCF. We're a community and interacting with those. So we've had a bunch of those going on recently. Lupine is a sort of research research project in very lightweight virtual machines and containers. We've also been interacting with G visor crustlet is a project for running web assembly in containers and communities essentially. And I think that is sort of high level summary of what we've been up to a container device interface I didn't mention that was also interesting. So this is all around how to standardize on interfaces with slightly strange devices so GPUs are one of them if PGA is another one a sex these kinds of things which are increasingly becoming necessary. Melanox advanced network interface cards are another example. So all of these things are becoming increasingly used in particularly machine learning environments. So they're becoming very interesting and it's very useful to have standards for these things to be interfaced with through cloud native technologies. So that's another area that we're working closely with. And that's it. Great. That's a Lupine thing. It looks right up my street. Any other questions for runtime. Okay, so over to storage. We have votes out for their graduation of T I K V and work. The, you know, we've done the diligence and the public comment periods was done last, the last couple of weeks. We also have per figure who have presented the SIG as a project for incubation. SIG would like to recommend this to move forward so we need a talk sponsors and we can start a due diligence review. The Pravega is a streaming storage project. There are, there are some similarities to both the next project and to Kafka, for example. So, and there's quite a detailed comparison in the, in the, in the proposal document. And Pravega have already done a fairly extensive presentation with Q&A at the SIG storage, if, if any of the talk members want to want to have a review of that. The CNCF storage landscape version two was released on Monday. There's a link to the white paper there and the CNCF team helped us out and put a blog post together, which was kind of cool. And we've also got a new project coming up who are presenting to, to the SIG and will be applying for the sandbox project, the previous project, which is, which is based on Linsdor and the RDB underlying projects too. And finally, we've also got sessions for both KubeCon EU and the, and Shanghai and China, I mean, sorry, where we'll be doing some presentations there too. That's great. Everyone is admiring the SIG storage logo. Well, you can, you can thank me for that. Fantastic. So if any other SIGs are looking for that logo, it looks like Amy is the person who's arranging that. This is fantastic. Also, I think the fact that you've done a blog post is great. And I guess any other SIGs have any announcements or news they want to share with the world of CNCF blog post is probably a good way to do it. That's a great idea. Okay. Did, do we have anybody from app delivery? I know we kind of skipped over it. So I don't know if anyone had any comments they wanted to make in that absence. I did see we had someone from backstage who's here, which is great backstage does look very interesting. Thanks for joining us. Right. I think SIG security, presumably they are not with us this month. That is correct. They sent their regrets. Right. Look forward to being able to come back next month. Yes. Okay. I think the one other topic we have is this, maybe, you know, have a bit of discussion around the maintainer diversity requirements. And so the issue that's linked in the slides, really, I'm going to paraphrase the saying we have this graduation requirement that says there should be maintainers from more than one organization. We should document why that's a requirement. It's a long thread ensues. And kind of coming out of that discussion. Alexis ended up writing a pretty detailed document with some suggestions around clarifying essentially saying we could have a steering committee, you know, it doesn't have to just be maintainers. The control of a project direction doesn't just have to be in the hands of people who are making code commits. So he's basically come up with this proposal. I'm just going to try and find the link and copy it. Yeah, so, oh, Justin got there at the same time as me. I'm sure we're not going to sort of read through the whole thing now, but I wanted to flag it up and see if anyone has any thoughts or comments about this general idea. This is Colin Sullivan from the Nats project. And I just want to say I think this is a great idea for projects like ours that we do have generally as a whole very diverse ecosystem of contributing companies. But we do have a couple repositories of servers which have as of late the last year or so due to adding a lot of new features do appear and do have contributors from primarily one company at this point. If this would be a path to move forward with graduation, we'd be all behind it. And, you know, we're really looking forward to seeing what comes out of this. Yeah, I've already commented on this. Josh Burkus I've been commented on the document a bit requested to Alexis that we actually add this to the advisory documents that we're assembling in governance working group. You know, because that's part of the reason the governance working group exists. The, and I can definitely see this as a way of handling the sort of catch 22 of, hey, we need to have maintainers from other organizations involved in the project. But it's hard to get maintainers when you currently only have people from one company working on it, because people from other organizations don't see themselves as eligible. The, and outside of the CNC F I've seen other projects sort of bootstrap, having a broader spread of input through a steering committee or similar body. So, you know, as one path for CNC F projects, it's excellent. It's a very nice document from Alexis. Great, great. And one question I have and I'm sure there are people on this call who can answer this quite well is how similar is this proposal to the existing Kubernetes Steering Committee model. I would say TBD, as is pointed out in the comments in the the original text Alexis is talking about an appointed steering committee, which is going to be appropriate particularly for projects that are trying to bootstrap multi organization right if you're trying to bootstrap multi organization. If you have an elected steering committee it's going to largely elect people from the majority sponsoring company. And you won't have solved your problems. So, his document is talking about mostly an appointed steering committee in the case of projects that already have a large very diverse contributing base. Those projects just have a straight up election with limits on how many people they can end up with from the same organization. And that's how Kubernetes is written. And that would be the way to go if you're if you're not trying to bootstrap. Yeah, there's some steering committee members that actually commented on the dock as well. I think it was mainly around things like elections. So a question. So will this become a requirement for graduation or will it depend on the project. The project already has some election process. Maybe it doesn't have to follow this and maybe projects that need that help then it then it will become a requirement. I think my feeling is that it wouldn't be a absolutely prescribed model in the same sense that we don't really prescribe any models anywhere else. But it would be a model that we recommend and that would say, you know, you may have an alternative that works and we'd be happy to consider it but you might also want to consider this as an option. Yeah, it depends on on the project. The. I would see more narrowly focused projects as continuing to have our sort of quote unquote traditional model of having a group of named maintainers who are the senior leadership. Because, you know, if your entire project consists of like three different repositories and that maintainer pool is a total of 10 people, and they represent multiple organizations already. Then you don't have any good reason to add a steering committee. The reason status steering committee would be, you know, either a you're again trying to bootstrap multi organization and using this mechanism to do so or be your project is actually spread out across, you know, 50 different repositories because you have drivers and plugins and that sort of thing. And you want to make sure that the sub projects are concerns are being represented in general strategic direction. So, you know, those projects would definitely a steering committee is a good idea for them. So I can actually see, you know, I mean obviously we're going to have all kinds of models, but I can see those as being the two main models for for CNCF, depending again on the structure of the underlying project. Yeah, I think that really makes sense. There's no need to require the overhead of a steering committee if it's not needed and there's some equivalent way of having a diverse group of people controlling the project. So if the project is, you know, a line like an ISV, would a steering committee allow the project to be graduated without maintaining diversity and all of the repositories, or is the steering committee just a means to an end to achieve that. My read of this is that the steering committee is a way of ensuring that the project is not under the control of a single organization. So that sort of manifested in maintainers or steering committee doesn't really matter. Liz, can you hear me. Yes. So one of the things that we have on the Kubernetes side is the steering committee is not involved in the technical decisions. So the maintenance diversity seems to be more oriented towards the technical decisions. So I don't know how steering steering is oriented towards the community side of things rather than the technical decisions that are made on a day to day basis. So how does steering, I can't get my head around how steering can help with the decisions that are going to be taken. So, just just two cents. I had bounced a few ideas back and forth with Alexis earlier. So I have a bit of background to the doc. One of the, I think one of the key things that that Alex is just trying to capture is that the steering committee can act as a way of, of making sure that there is a roadmap making sure that there are some quality contributions and that you know the maintainers are not blocking roadmap requests or roadmap development items, or PRs or whatever. So I would say commercial reasons or things like that, right, which is, which is one of the, one of the key reasons why we want to try and achieve maintainer diversity here. So, so I think that that was one of the key things there so so in a sense, effectively the steering committee does enable a way of controlling or a way of imposing some checks and balances I guess for projects that might only have a strong focus on one vendor or one maintainer without where those checks and balances are ensuring that innovation is still happening and the project is still working on behalf of the end users rather than just on behalf of the on behalf of the vendor. So I think that that's what we were that was was Alexis was trying to capture in the dark. I like the concept. I like the idea. It's just that how would you force somebody to that, you know, when you don't have, you know, control over the internal hierarchy within a company right so that would be the question here. So it's not about it's not about enforcing control. It's, it's, it's about adding sort of like a layer of governance. So the steering committee would be able to laze with the CNCF talk or or the executive staff. And the idea being is that at least once a quarter or whatever they would be able to report back. If there are these these sort of problems and the thing is they the, you know, you might even have a CNCF observer on the on the steering committee and they could help, you know, arbitrate or or or negotiate if there are some blockers there. But the point is that if there is an escalation requirement. So for example, you know, an end user has submitted a PR and the maintainer has blocked it. Then the end user has a route by the steering committee to raise that as an issue. And if you know some sort of resolution can't be achieved. Then the, you know, the TOC or the CNCF can get involved. You know, with obviously the ultimate sanction being that, you know, they, they, they downgrades the, the, the status of the projects or whatever. Yeah, I would say, ideally, the steering committee would have some ability to actually appoint maintainers. Because obviously one of the other concerns with having too much single organization dominance is that somebody who would have otherwise qualified to be a maintainer never gets promoted to maintainer because they don't work for the right organization. So, you know, particularly for projects that are trying to bootstrap that have a, you know, de facto majority single organization maintainership. I think it would be important for the steering committee to actually have that power to appoint maintainers and then obviously if they can do that. The ability of, of anybody to cherry pick contributions for corporate strategy reasons would be limited. Definitely worth exploring for sure Josh Alex. I think, you know, what we're trying to, what we're trying to do is to get the right balance of, you know, a vendor or an ISV providing enough critical masks to ensure enough maintainers and enough innovation is happening in the project. And as incentivized to do that right versus forcing diversity as a, as a arbitrary metric, which might actually stop that from happening. And which might actually have a detrimental effect on the project. So I think, you know, there's, there's a set of compromises and maybe a steering committee might be a way of helping with the governance and maintaining, you know, the core principles of what the ISV is trying to do to ensure it's a healthy project that that that is working for its end users. Without it necessarily without necessarily penalizing sort of an ISV or a company that's actually, you know, happily paying it for the innovation. It's a really great thinking that's gone into this document. I know, you know, Alexis has worked on it. He got some input from various people who've been involved in various different sort of roles around this. You know, different projects that had issues like this. So, yeah, I think it's really well worth us all. You know, digging into the details looks like there's lots of good comments on there as well. Yeah, let's review it, consider it, maybe this becomes the future. All right, Ricardo making the point this seems very relevant to the idea going around about Istio starting its own foundation. Yeah, I was interested about hearing comments from people that had any stance on that. I mean, I think they haven't actually announced anything as far as I know, but Yeah, you know, if Google decided to start its own foundation, then it would not actually be vendor neutral. So, and part of the reason of having something like a Syrian community is just to assure that venture vendor neutrality. And I think we've seen from lots of end users that the neutrality is something that they really value. They really value the fact that the existence of a project is not under the control of a single company who could decide tomorrow they don't want to do it anymore. But yeah, it's just a general comment, not about any specific project. All right, so does anyone have any other business they would like to talk about on today's meeting. Just one last comment on that last topic. So they seem to be two kind of fundamentally different concerns the one is the longevity of a project so so somebody takes on a project and it, you know, collapses. Then that's bad, especially if they bet their business on it. And the other one is that this project continues to exist quite happily but that any given user or competitive vendor or whatever does not have influence over the direction of that project. And that seems like a different concern. And I'd be curious what the CNCF sort of opinion on that are we trying to solve both of those with with diversity of, you know, company diversity specifically with in the contributors or are we prepared to separate those two concerns and say, they're actually different concerns and we can address one and not the other one or we can address the two concerns separately. That question makes sense. That was essentially a question to you, Liz. I'm not sure why we wouldn't want to address both those things. I think, and, you know, anybody else tell me what their views are from end users, but I think people want to see longevity, you know, they want the, the, the future of the project to be solid and they want the direction of the project to be. I think Alexis had some quite good words in here about good faith roadmap I think you know that that idea that well we're not going to suddenly take the project off in one particular direction so that it particularly supports one particular vendors model. If there are other valid models that the project should be supporting I think both those two things are important to users. But I think that the governance is mainly addressing the, the, the, the direction of the project, not less. I mean, I think the longevity is a, is a side effect could be a side effect of that right. The longevity really depends on, I mean, it's obviously related, but I, but it, I think it depends a lot on the, you know, just the, the usefulness of the project and the adoption of the pro, you know, adoption of the code by the end users. And, you know, even if something's under a single vendor right I think that, you know, that still can be achieved the longevity can still be achieved it's just that we want to make sure that the, that the technology that you know the technical direction or the roadmap of the, of the project isn't tied to a single vendor because that's, that's generally why end users adopt right. I don't think longevity as, I mean it's a concern but I don't think it's as big a concern and I see these proposals as mostly addressing the, the, the, the technical direction piece of this. That makes sense. At some level it's, it's slightly academic if we have a model that we think protects in some way in both those things, you know, if a steering committee model allows for things like you know the dominant vendor deciding that they don't want to invest in a project anymore. If there's still users and expertise and interest in that project the steering committee is in a position to continue. And, but then that becomes that becomes maintain a problem right that the steering committee doesn't solve so that's why I think we're trying to primarily solve for the, that as long as the project is being maintained, that it's, you know, that it's, it's not, it's not going in a way that would like lock other vendors out I mean you can you can imagine extreme scenarios like, you know, like, like a service mesh requiring, you know the use of certain, you know, I won't pick on a particular vendor but using vendor specific, you know, you can only use this vendor specific underlying networking interface and think like that right so. That would be consistent with CNCF neutrality principles. Yeah. I do think it's important if we think about the de-risking of a project you know when we're saying that a project is graduated it's something that an end user should be able to kind of bet their business on really. I think we should be at least requiring some story on continuity, you know, along the lines of well what happens if, you know, the single company decides they're no longer interested in it. What's the contingency? I do think that the donating intellectual property to the CNCF more addresses that problem, like, you know, then necessarily a steering committee does, right. Yeah, the code ownership, the intellectual property ownership is there. Yeah. That's that's already not an issue. But isn't the common failure scenario is the case where one company funds a project and provides the majority of the engineering resources to work on it. You know, implicitly influences the direction of the project. And very few other companies or no other companies step forward and actually provide resources to work on the project and you know by resources I mean people with the appropriate skills and experience and whatever else might be required to be effective on the project. That's sort of the de facto way of influencing the direction of a project is to actually fund engineers to work on it. And, and when that works, you know, that's how you influence a project. I think, I think that the thing that I'm sort of worried about a little bit is company standing on the sidelines saying we don't want this project to succeed because it's competitive with our project. And therefore we don't fund it with engineers, but we also don't want it to be in the CNC F because you know, blah, blah, blah, which I think is sort of an invalid reason. I think if you want to influence the few, the direction of a project you donate engineer to the project and they work on it and influence it that way. And if you get blocked if you get you as a company get prevented from contributing in that way then then there should be some escalation procedure to address that. But I'm, I'm sort of wondering whether sitting on the sidelines telling a project what to do without actually contributing engineers to work on a project is is sort of a legitimate concern. So it's your concern about having representatives on the steering committee from essentially a competitor of the person who's doing all the work or sorry the organization who's doing all the work. It's not so much who's allowed to be on the steering committee it's more a case of like, is that a, you know the steering committee can say whatever they like but if, if the engineers who building project don't do that then then like doesn't matter what the steering committee says. I just think it potentially becomes a political problem rather you know I don't, I'm not sure that it addresses the engineering challenges. You know if company access is doing all the development on a project and the steering committee is comprised of a bunch of companies and they say we want to do something like somebody's got to do that thing and if it's not funded it doesn't get done. Anyway, I guess I'm I'm a little uneasy about about the control concern because I think the way that you influence project as you contribute to them and if you don't contribute to them you don't get to influence them, which is a different concern than a consumer who has no intention to contribute to a project they just want to know that this thing's not going to disappear. And they want to know that vendors other than or people teams other than me care about it and are going to make sure that it's there in five years time when I need it, which is a different concern. I think the steering committee model does help with that. Well essentially preventing gatekeeping on the maintainers so you know company A has all the maintainers and then blocks company B from having any maintainers. I think a steering committee model can help with that in terms of assessing whether or not somebody really should be accepted as a maintainer if they continue to continue being blocked just because they're from the wrong vendor. How how was how was does that help less like when we say that had just having steering committee is enough then you are basically removing the incentive for anybody to add maintainers from other companies right so and they're going to say oh our charter says this, you know, so it's enough so we don't really need to try. We don't really want to try. So that's the problem. And the steering the technical people will tell the steering committee. Look, we here are the reasons why we can't get them on board or, you know, they are here for six months and they are gone or whatever they will come up with something or the other which justifies their point of view and steering committee has no way to judge whether the input they are getting is. correct or not. Yeah, the point. Can I, can I just make a couple of comments on this, just to give a bit more color so so we're the steering committee is actually supposed to be composed of, you know, the maintainers themselves and users and and people who are using the projects right. So, so it's not, it's not like some third party arbitrary people that are that are on the steering committee and the other thing is, the steering committee is also there to help with the governance and to kind of act as a as a as a pot to unblock things with the to see acting as kind of like perhaps a final ombudsman for for, you know, blockers. It's not. I don't think we were, I don't think. Yeah, I don't just completely speak for Alexis here but I don't think Alexis was suggesting that the steering committee has this controlling function. It's more of a an escalation part and a way of resolving issues before they become kind of issues and to help, you know, work with the maintainers because the maintainers are also on the steering committee right because at the end of the day. One of the risks for projects becoming unsuccessful is is you know if they can't get that critical mass of innovators and if a project is currently successful and has a critical mass of innovators from a particular company. I'm forcing additional maintainers to come on board just for the sake of hitting a tick box and in particular criteria may not necessarily be beneficial to the to the to the project specifically right and I think that's that's what Alexis was trying to capture here that adding is just for the sake of hitting a tick box might not always be the right solution, but putting in checks and balances as an alternative via a steering committee might be a viable alternative. Yeah, time there's there's some really good points being made here so I encourage everyone to continue the debate. We can come back to it in a future meeting. We'll also be discussing this in the governance working group meeting in one hour branches on the CNCF community calendar. Great. Great. And I think we'll look forward to your comments and feedback from that group that will be really useful. Fantastic everyone. Nice to see you all take care CC. Thank you.