 Folks, while you are thinking about the questions that you might wanna ask, a couple of things that I wanna talk about on behalf of the steering. First and foremost, if you look at the steering currently, we're missing one member. There's one thing that is wrong with the steering currently. And you probably can figure out what's that. In September, there will be elections. The elections will be happening, if I remember correctly, three seats will be up for voting. If you have a friend, if you have someone you know someone who is interested in, please nudge them. It took four people to nudge me into steering. Maybe even more than four in that case. That was Bob, there was Eddie, there was Josh and Christopher. I haven't seen Christopher yet today. And they were all convincing me for, I would even say up to two years to run for the steering. I was afraid. If you're afraid, please reach out to us. Half, I'm happy to answer all the questions that you might have about steering, so does every one of the current steering member, all the past steering members. I really appreciated their time that all of them spent with me back in Chicago when I was asking multiple questions. So please, if you know someone who is interested in, nudge them. Nudge them again and again and again. If you are thinking about running, but you're afraid, let me know. I'm happy like literally any time of day and night. And I run like two weeks ago, I run like midnight meeting. If it requires for me to go and call at 3 a.m., I'll do it for you. Please don't be afraid. Less important thing, but well, also important. There was announcements already about the annual reports. The annual reports are very important to a lot of the contributors. They help several folks either through promotions, through maintaining their upstream contributions and so forth. We slimmed them down as much as possible. Currently, there's like literally two questions, two questions that we think that we cannot generate, but you have to answer them. Please make sure this is, as we've said so many times in the past, this is a good opportunity for growing your replacement because that's one of the most important thing. We have to have people who will come after us. I know that I was called out back in Chicago and I will say here on this stage, by the end of this year, I'll be out of 6 CLI. I already talked with Eddie. I have people who will replace me and by end of 2024, I will not be running 6 CLI. And I am working on replacing myself out of the other six as well. So please make sure that we have people who are capable of stepping up because this community is the people. And there's like, there's awesome quote from Brett Cannon from the Python community. He said, I came for technology. I stayed for the community. I am positive. This is true for this community as well. So. Related to that, when we put out the announcement about the annual reports, we also sent out a reminder, please start thinking about adopting sub-project leads for your SIGs. Sub-project leads are just a way to list these people are actually running my SIG sub-projects. When you're thinking about technical leads in the future, you have a starting point for who could possibly help lead the SIG. Sorry, this is piggybacking off, sort of what he was saying with trying to step down. For those of you that might know, I recently stepped down as Contribut's lead and I'd actually been trying to find a person to take over for me for quite a while. But what wound up actually being successful was basically doing a lead mentor cohort with our other leads. And we basically had a bunch of people apply and we took some on and the people that stuck around have now taken over with all like myself, Josh, and like we've all, Christoph, we've all stepped down for, well, Nebrew was one of the people that, well, I'm looking at Nebrew because he was one of the people that took over, he took over my spot. He was part of the cohort. But there are these sort of options if you are having, if you aren't sure about how to potentially set up a new lead or again, just try and think about that sustainability plan. You can reach out to, even though I'm not the lead, I will still say this, you can reach out to Contribut's and they can help you plan this stuff. Okay, sorry. Do you have something right there? Okay. Okay. I think now we're ready for actual questions. Is there a microphone in the audience? Okay, cool. Okay, one last pitch. We are having steering session. Wednesday afternoon is what Parker told me. Please double check me. Don't trust me. Wednesday. 1725. So yeah, like the lovely session. We asked five questions to all the past steering members. There will be some interesting answers. If you're curious what they said about what it's like to be on the steering, what it's like to work with the community, what they think about the project, please check out. Yes, yes, we're not ready for the questions. So things are changing all around us without naming names. You know the theme of this conference this week. So you'll see in all the keynotes. So the question is, what are the degrees of sustainability that you are thinking of for our community and what can we do about it and when? Thank you. All right, okay. So at least in terms of sustainability for like the leads, that's really sort of what we were going for with the sub project leads. And I think it was, Eddie, I think you were the first person to PR in sub project leads. Yeah. That's the one. Yep. So at least in terms of sustainability for leadership, that is one of the things we're really pushing for is to have the sub project leads potentially be a stepping stone into the leadership type position. Especially if you happen to see the same person as a lead of most of your sub projects, probably worth it just to promote them to be a TL. They seem to be leading a bunch of sub projects might as well make sense. From a more like stepping back and looking at funding and trying to help maintainers like justify their time and things like that in the project. The annual reports was a first real go at that. And we've had, you know, we have had success with it, but it's, we've had some mixed results just with like nobody wants to share a markdown doc with their, you know, leadership essentially and it kind of gets glossed over. But we are thinking and looking at ways of trying to improve that and make it easier for, you know, everyone to sort of share their wins and share the work as well as call out the areas that need improvement. Like Customize, Customize was one recently that you sent something to the main list about it, right? Yeah. I'm just trying to be able to surface this information better. One, I'd say like one of the biggest issues in terms of just our general sustainability is that there are a bunch of sub projects and a bunch of areas that are hurting, but it's not visible at all. There have been multiple places where it's basically fallen like to one maintainer and it's, they've just been burning themselves out trying to sustain that project. And that is not a sustainable model. So like we need to be better about collectively communicating that up to, you know, the sig leaves themselves, the sigs itself and pushing it up into the greater community because there are people that are willing to help and willing to put resources at a lot of this stuff. They just think that everything's fine. They don't need to. So things just go on. Sorry, that was kind of a ranty answer, but it's been on my mind a lot. Does anyone else want to talk? You were talking about leaders, but we also need to think about the new contributors. My experience has been that it's really getting harder for new people to find meaningful work in Kubernetes. I do lead a few efforts where new contributors actually can do something, get some patches in, become a Kubernetes contributor fairly easily in logging and testing. There are things where we have code bases that haven't been touched in forever, where modernizing it carefully with some supervision is possible for new contributors and eventually these people hopefully stick around. But that is the challenge. We need to make it easier for people to do some meaningful work in the beginning without overburdening them with expectations, but then hopefully motivate them to stick around to this path towards some role in Kubernetes that can be used as justification. That certainly is worthwhile. I think everyone here covered a lot. I'll try to give you a brief, but this is something I'm really passionate about and the main reason that I ultimately agreed to run for steering. We've got contributors, we've got maintainers and leaders, we've got the infrastructure and all of those dimensions need improvement. We need to get people brought into new contributors like Patrick was talking about. We've been pushing a lot on the leadership angle and I've been pushing with some of you, like Dems, on the infrastructure support and I think we're getting to a lot better place there. We're not there yet. I think they're all important, but I wanna go Patrick and say that I'm actually most concerned about new contributors at this point. I think we've got a path forward for rotating and leads and we've got a couple of models that are working. We're still trying to sort of evangelize them to the six like someone mentioned earlier, reaching out to contributor experience and doing a mentoring cohort to bring in leads for your SIG. We did that in SIG testing. Shout out to Michelle and we've gotten a full sweep for the chairs and it works really great. We just need more SIGs to consider doing that, but we have a model for that and it works. For new contributors, I think that's kind of fallen by the wayside and that's the bottom of the pipe. We gotta bring people in as new contributors first so that we have people that can filter up in the leads later. We've had some problems in the past where we've had people who've been in the project and we haven't been really filtering them up in the leads. I think we're doing more of that. And I think you well know, dims, that we still have a lot to work on for keeping the infrastructure sustainable and it's kind of a big scary project of its own, but I think the overall between inference, hearing the CNC and so on, we've got a lot of vendors providing resources now and we're just figuring out how to adopt them and how to make it easier to get new contributors on. I can't spot Mohamed here, but Mohamed here is working on some awesome stuff to make it a lot easier to onboard people with that so we can just have people use their GitHub account and then do Octa's single sign on and give them access to things, very self-service so it'll be a lot easier to bring in new people there. I think kind of need the equivalent of that for other sub-projects, how do we make it easy to just get someone started and not throw them straight at, go right a cap. Yeah, I also have some thoughts about new contributors because it's very hard now for a new contributor to become a Kubernetes call maintainer, it's very hard and but we also have provided a sub-project rule and I think if we can do more AI related or some new things in some projects and this will attract some very creative contributors to our community and for example, the scheduler using the Wasm to do the plugin and also some other testing or other scenarios so many problems and also another question just mentioned, how to attract the contributors to work on that and also attracting the maintainers to cooperate with the question. We need more input from the users as now there's more and more Kubernetes users around the world and also we need to hear their voice and then the contributors will solve their problems. It will make it a better place so this may improve the scenario if I stick, yeah. Anyone else have questions or do anyone else have any thoughts for it? Do the annual report, there's only two questions. What do you wanna highlight and show off for your SIG and where do you need help when that second question ties into all this? Please fill out your annual reports. Wonderful, okay. So I was speaking yesterday to a first time CubeCon attendee who works at an end user company who said that it's interesting to him to get involved but it's hard for, he thinks he'll have to do it on his own time if he gets involved with contributing to Kubernetes because it's hard for him to justify having his company invest in him doing that and then went on to say but his company is very interested in multi-cluster and thinks that maybe the direction SIG multi-cluster is going is not right for them and I thought, okay, you need to get in there to represent your company's interests but also, and yes, I'm looking at you Bob but also how do we message to people in these end user companies that they can in fact shape the project and should get in there and get their voices heard? That's a really good question, I think I need a moment. Making yourself heard in the community, I think that clearly means that you need to start doing something. You need to show up in the SIG meetings, you need to talk with people who are currently the maintainers and the only way to get that done with some level of credibility is to do some work and it might be very simple. You might just pick up some odd tasks. It's also a good learning experience so you asked about why should some company invest in a developer getting involved in the community? It is a learning experience. They will become better developers, more capable, learn technology much better than going to a Kubernetes training for example. That has been my experience and that may work as an argument with a company. The other is if they clearly have a goal, if they want to achieve something, they can't do that from the outside. You'd have to be a member but that's the way how Kubernetes works. I just wanted to add one thing. Just a shameless plug for the technical advisory board for end users which hopefully we can also partner here because I think that's one of the goals we had is that we felt like this is an area that was underrepresented and we have a laundry list of things that are gonna tactically probably address the real runtime things like exactly what you mentioned Bridget. So that may be one thing for them to look forward or bring back to them as we're gonna have quite a few announcements of the artifacts that we're working on. The rule like where the rubber hits the road when it comes to Kubernetes and all the things that being in production. So hopefully that in conjunction with the CERN committee can be also a bridge. One more thing. So having gone away from the CNCF community and the Kubernetes community into sort of a company that does a lot more with ASF and with projects outside of the Linux Foundation, one thing that I can say having seen a few sides of the open source coin now is that it is particularly for a smaller company. I would say that contributing to a Linux Foundation project or to a CNCF project is a better bet, especially if you are looking to do things that benefit your company. So for example, if your company is interested in multi-cluster and they're wanting a part of the hesitation in having somebody contribute full time to that is like, is this gonna be worth our company's money? Is this gonna be worth the headcount? In comparison to other governance models out there, the Kubernetes governance model and sort of the representation of, for example, members of different companies on the CERN committee ensures a lot more equality in that regards and ensures that the contributions of smaller companies can count. It's a safer bet than some other models out there. Okay, sorry for stealing the mic. A little bit more on that topic. I know that I have spent over the past years, numerous hours talking with our directors and above. Even though that I'm coming from a company that is very open source, we still have to invest a lot of time into convincing them that instead of doing something on our own because it will cost the maintenance, it will be easier, yes, it will be slower to push this upstream, convince upstream that the benefit of having multiple people from various companies, helping shape the direction, helping deliver the code will be greater and in the long run, the company will actually save because even if the knowledge will be lost with the person or to leaving, there is still a full bucket of different people that you can choose from. So that's an important thing. And unfortunately, that is the type of gospel that we will have to bring constantly until the end of the project and probably in the second decade, even more than before because we're past the growth phase or at the tip of it. So unfortunately, yeah, it's an unpleasant work and more senior people have to unfortunately spend the time convincing directors, VP, CTO, COs and whatnot that this is a worthy investment because it will pay off. So not to also just plug my own thing but I'm giving a talk on Thursday. Now, why is this so hard? Conveying the business value of open source. This is something that I've spent a lot of time thinking about and I've actually spoken with a lot of end user companies. Actually, there's been more end user companies that have reached out to me personally to ask, okay, how do we get involved or how do we make sure that what we are involved we have people contributing but now that we are getting questioned, like, okay, why should we continue to contribute? Why should we invest in this? Things are, a lot of people are happy to toss people at open source or whatever when times are good and you have a lot of extra headcount. But now when there's macro economic conditions that tend to have your organization kind of refocus and focus internally, getting, justifying the work and justifying people working in open source is a lot harder. So there have been some strategies that work. I'll go over some of them on Thursday but specifically for getting end users more involved, one of the actually, I'd say the biggest hurdle is like, honestly, how we communicate a lot of things. We don't surface where the areas that need help, the areas that are good for engagement and when we do surface a lot of this stuff, it is, you know, we're talking, the way we talk about it is the way we talk to other contributors, which is very deeply technical. And if you are a end user or someone that's interested in contributing or might be interested even in a feature, sorry, it's hard to see if they are interested in that from looking at the description of the cap. Like when trying to share this information out and like, here's a list of caps. See what might work for you. They're gonna go cross-eyed real quick. Yeah, oops, sorry Nigel. Going back to what Patrick said, I agree with you that people just need to show up and join SIG meetings, but I don't think that's a great answer, I don't think it's enough. Like for example, the company I just joined was maintaining an entry fork of some of our stuff and I showed up on the first day and I was like, what is this doing here? I was, oh, we needed these changes made. Oh, did you propose them upstream? Did you ask anyone if they would accept the change? No, we didn't know we could, right? And that's not just the place that I'm working now, that's a lot of places. So how do we get past telling people to just show up to know that they're invited and that they can come and join those conversations? Cause I think that's what the bigger issue is and what Bridget was saying about the person, like I'm sure that person didn't know they were invited to show up, so. Yeah, I think we've mostly been thinking about how do we highlight areas that we know need work and invite people directly to those. But it's a really interesting question to flip it around and say, well, these companies are working in these areas and they want things. How do we make sure that they come participate? So I have a quick question. How many people here are from an end-user company? As you're not at a vendor selling, Kubernetes, you're an end-user. So maybe a third? I'd love to hear from you later. 10%? Yeah, it's not a lot. I'm glad to hear the light. Look, I would love to hear from some of you later if you have a moment about how you got that to work at your company. I've worked at a vendor selling Kubernetes the whole time, so I don't think I have the insight into that. But it's an important topic, I think. Am I here? Okay, so a couple of things. One is having fought that fight at the end-user company. One of the most direct things that they asked for is what are the quantifiable metrics? I hear you saying, oh, you're gonna be a better developer and I can bang that drum all day, but they're like, can you show me in our development velocity metrics how us spending time and money on this is gonna be to the benefit of the project? Because they're like, our contribution to open source is paying for a CNCF membership to help support these projects, but when you're talking to these directors and above and these senior and staff level folks making the case to say, at the end of the year you need to show that you've moved the needle at your company and how does this directly relate? So part of it is we need to make a better case for these engineers and part of it is been something you're saying now is like there's a lot of great work going on with the LTS survey and reaching out to these end-user companies and figuring out what are your pain points with upgrading Kubernetes? Why don't we have that same thing for end-users who are using it? What parts of the project are you having the most friction with? And because you know this area well, could you dedicate some time, some engineering time to help us fix it? And my larger question is how far away are we from going to CNCF or whoever else and saying we need staff maintainers to work on Kubernetes? Why is that conversation happening? And if not, why not? So specifically regarding the staff question, like one of the biggest issues, and this is like step back from Kubernetes and look at the CNCF as a whole. There's like 180, how many projects are in there now? I know it's above 180. 180, okay. Okay, so if the CNCF is going to fund a person and fund it for, we'll say like Kubernetes, you also have all these other projects and they will want someone to staff them. And in the big scheme of things, like them paying for one person isn't actually like a huge, like very impactful. Like it doesn't get a lot actually done. Like in Kubernetes, we need people everywhere. And just tossing one person at it doesn't, or like a couple of people that doesn't solve the problem. We need to think about how that money or that those resources can be sent in terms of like incentivizing more groups to actually contribute. I really think that like we should be trying to recruit end users more. Again, like in a lot, I've talked to a bunch of them. I was literally an end user up until joining Google three years ago. Like there are opportunities there. Just they don't necessarily know how to engage going back to some of the, you know, just show up type things. I know like Taylor in the CNCF has been running a program called like Zero to Merge that's basically just like trying to teach end user members like, okay, you know, you want to, you know, you're a swir or something like you want to contribute. Here is how you do it. Here's how you like interact with the projects. I think there are certainly like other like onboarding paths and other ways to get them involved actually through trying to find better ways for them to provide feedback and smooth the process for them to, you know, like how many people here have gotten actual feedback on an alpha feature? One, a couple, okay, like in terms of like people actually using it and like shaping how it might be when going to beta at all. It's very, very small. We want people, sorry, we want people to be able to provide that early feedback instead of waiting for it gets to GA and it becomes a huge pain in the ass to try and actually make it the way they want it. So the earlier that we can get them involved and get them providing feedback or even finding ways to contribute from that path, I think it will eventually lead to a better onboarding path for them. Sorry, Nigel had a response, you had a response? So a lot of the end users are using a service. I'm just judging from how many people actually pull Kubernetes and the fact that we've almost run out of money a couple of times, there is at least a good amount of people still running it natively, but there's still opportunity for them to provide feedback on like looking at, you know, the stuff that's happening in upstream is eventually going to come to GKE, to, you know, EKS, like all these solutions that by interacting upstream, it's a way for you to even potentially shape or, you know, get what you want when it comes to that service, especially like how fast the vendors are turning around, you know, keeping up with upstream releases. Like theoretically, it shouldn't be that far behind. So I'm doing that. So one thing that we have to point out for this, we actually have some contractors from the CNCF working in Kate's Infra because it was one of the understaffed pain points there. It's something we've been doing for a little while now. I'm not sure if any of them are in the room here. Yeah. Hey, Kubernetes folks back there, thank you all. Also, I'm not sure if they're in the room. Hey. Yeah, so we, it's not a model that's completely unexplored. I think it's kind of a complicated topic. One thing you also have to remember is, so say the CNCF hires a core maintainer, okay, but those people are in the pool to be hired by these companies. So it's, you know, it's a little bit of a tricky subject there. And it's also something that's going to be very difficult to scale up. But we do have people participating in the project that are paid by CNCF currently, specifically in K-Tempera. They have a hand here. So just going back to the- We have a follow-up question. So maybe do this and then- Just going back to the original question about demonstrating impact for work in open source Kubernetes. Folks that don't know me, I'm Jago McLeod. I was one of the co-founders of SIG Cloud Provider. So sorry about that. And I'm the engineering director who's accountable for Google's open source upstream Kubernetes work. So I've spent probably more time than most rationalizing investment in open source Kubernetes. If folks have trouble doing that at your own company, I'm happy to give some thoughts. Please attend Bob's session two. But if you need someone to vouch for the work and the impact, I'm happy to provide a reference. So if you want to, just grab me after. Thanks. Thank you, Jago. So just to follow up this and the conversation itself. So I'm in a boat where I'm working for a company who's doing amazing things with Kubernetes, zero upstream. Everything what they do upstream is my own time. And it's a hard sell coming from engineering. So I'm thinking how CNCF and we can help these things. Like can we engage things like people who are in a positions to talk with CEOs, CTOs and people like me who can bring my CTO CEO to the conversation. So basically host a dinner, host an event, one-to-one sessions, meetings, where we could bootstrap these companies and right people to having the right conversations with other right people instead of trying to say like, hey, I'm engineering in that corner department, use open source. Because let's be honest, sometimes these conversations need to be having at sea level execs. So. Okay. Hi. Hello? Okay. So I think I'm maybe the only person in the room who has the questionable distinction of being both a former CNCF employee working full-time on Kubernetes and now a contributor who does not work for the CNCF at all or even a company that is heavily invested in cloud native in any way, shape, or form. So I wanted to build on what Ben Elder said about like the CNCF directly funding contributions. The long and short of it is like that is no in no way, shape, or form an actual sustainable solution long-term. Like both the way that the CNCF works as an organization is such that it is far better for the CNCF to fund specific projects with specific goals and specific end dates. Like we need this thing done than it is to sort of sponsor rolling contributors. And sort of the other half of it is I remember having conversations about this internally when I worked at the CNCF because I was doing documentation. And I think I asked at one point, I was like, well, the projects, the number of projects keep expanding and expanding and expanding by 20 or 30 every conference. And like as a documentation person, we're always really concerned about the longevity, like what happens in 10 years. And I was like, you know, what's the plan? Because as we were two people at that time two or three years ago, and I was like, we're two people and we can't keep up with the ask already. And that's not on us. It's just that the size and the shape of the ask across all of the CNCF is so big. So like what happens in 10 years? What happens when some of these projects, for example, one of the many CNI providers doesn't have any users and they decide they want to archive. But they still do technically have a user or two in the wild. And that user or two runs into a CVE, like who updates the docs then, right? It's not sustainable to say, well, the CNCF can hire people. Bad idea. It will never scale. I've brought this up in the chair and Techlead's meeting before too. Like if there is a specific project, like if you have something that's a definable scope of work, that is much easier to get a potential contract or something like that for. The other thing I just want to point out, in the earlier days too, that there were some staff for Kubernetes because like Celeste and then Zach before she left, that helped like bootstrap docs. And that worked great when there was less than 50 projects. And now like in from, in 20, I think it was June, 2020, before the sandbox changes in the CNCF, there were 50 projects total. And now we are, so that is 2020, five years of CNCF. So five years, 50 projects. And now we've gone from 2020 to 2024 and that's expanded to 180 projects. It's just like scaling. Something Kubernetes is good at, just not so much on the people side. I have one thing to add to the end user company discussion. Having joined eBay, which is an end user company for the last eight months or so, I'm running into the same challenges convincing the company to get involved in open source. One thing that seems to resonate and you could try it, your mileage might vary, but one thing you might try is to convince them, what happens when you upgrade Kubernetes? Usually the chances are that they're doing some, they're doing some kind of custom patches for their needs and it would be best if it could be upstream. So, but that does involve a conversation with the community, with the maintainers. Is this even the right way to do things? So, the instinct is, oh, you know what? Let's just do this little patch here and get done with it, move past, run the business. That's how it is. I'm gonna try your point of upgrade experience and use that as a way to push for, hey, you need to try alpha features and give feedback so that when it really comes down the pipe later, are you gonna like it or not? And chances are you won't if you don't and get involved early. So yeah. Early is candidates two. Early is candidates two. Sorry, I'm gonna bow guard the mic and respond to that and also to the other person who I didn't catch talking about convincing their CEOs. I don't know if it's useful, I'm no Kelsey, but if it's useful for core maintainers to come and find a way to talk to end user companies, to their leadership, to explain why it's important, why it's effective for people, I'll go out for that. Let's find a way to do it maybe at scale or at small, medium to scale, like a Twitter space or something where we can talk one-on-one, but one-on-small group, really, because obviously I can't meet with all your companies, but I'll go out on a limb and say I think there's other people who would do that. I have one point on Vinay's question. So specifically answering that part of the problem where the leadership doesn't want to implement the feature in upstream. If you already have the machinery to do this downstream, why not keep doing that and also raise an upstream PR and get that in as well? Eventually it will come to you. As a person who is in charge of bringing your cube to OpenShift for the past significant number of years, I have a couple of thoughts. Easier and harder. I'm happy to talk with each and every one of you, even your CEOs, if they are interested, like Tim said. But to focus specific on, oh, this is a small patch. Yeah, those small patches usually take the longest. From my own personal experience, several stories which go, it took us about a week and seven engineers to figure out what changed in upstream that broke OpenShift, seven whole days with seven engineers to figure out which part broke. So if you're not, yeah, that was, and that wasn't just once. The other time was like, oh, we're running tests. Everything seems to be fine and then something dies. Roughly around 17 minutes into the tests and then there's like another week and seven people. About, oh, I'll implement my own version and then in parallel do the same thing upstream? Don't. You'll run into issues about we pick this approach, but upstream based on discussion, when the other way around, you'll end up in the much worse pain because you'll end up supporting the thing that you put out rather than trying to delay the release by a one release until it gets, let's say, beta. Yes, it will be delayed by a quarter give or take, but you'll earn a lot more time by not doing this. And like I said, if anyone like Tim said, if anyone wants to talk, I'm happy. I am currently going through 130 and finding issues. It was working a month ago for me. It's not anymore. So actually like specifically and user companies, if you, I have spent a lot of time talking to various companies, just like Tim, Marge, whoever, like I am feel free to poke me. I'm happy to talk to whoever about approaching like a strategy that's actually sustainable for them. Hello. I actually grabbed a mic. Oh, no. Sorry. I normally keep my mouth shut for many reasons, but I will say, seconding Bob, seconding Tim, and kind of stealing some of the thunder from the AMA later today, this is also like our job. Like the CNCF, we go out and talk to these companies to try and promote talking and doing open source. Like I have given this talk like five times to different companies. So yeah, also grab me. You need someone to talk with the C level people. Well, that's when I throw Chris under the bus because it's Chris and everyone will talk to Chris. Just keep these questions in mind this afternoon and hopefully I won't footgun myself. Also, like for those of you, is Taylor here? Taylor is not here, but he will be here this afternoon. Taylor does only go in, you know, former docs chair or was he a TL? He was a TL. Like he's head of end user ecosystem. Like what's his official title? Head of ecosystem, but he helped bootstrap the end user tab. Like that's again, part of his job is engaging with end users. So I love hearing all of these conversations. I also want everyone to understand like this is also part of why we're here. Part of why we try and engage all of these companies. Part of the whole point of KubeCon is also to evangelize open source. I swear I'm not just a shill. Like I was one of you, I still am one of you, but like this is from the inside of the house. Like the stuff that you don't see is the amount of like talks that we give to end user companies. All right, I'll shut up. Like one quick thing on top of that. Like honestly getting, you know, those people in and actually contributing is again, one of the things that I think is the big ways we solve the long-term sustainability issue. John's. It actually follows really well on what T.V.Witch is saying. The earlier questions that led into this whole brouhaha here pointed out that a lot of the companies look at the sense of what contribution can be and say, we don't have to throw people at it. We're already throwing money at it. And for us to do our jobs, we have to have those conversations internally to tell people what money is great. But if we had billions of resources and five maintainers, they still can't do anything. Being able to have a conversation internally where we say, look, money is great, but we also need to have people. Let's look at the concept of where resources are and right now, chief, he's cringing in the back. I bet I can't even see him. Being able to have a conversation that says, yes, we realize that donations to the CNCF accomplish X, but also that doesn't accomplish Y and Z, which is what people accomplish. And if we can't have those conversations without also having the CNCF, having a conversation at the back end, we're not gonna be able to change those mindsets because people are looking at internal budgets, they're looking at where the resources come from. Hi, my name is Wen Zhan from SID, I'm a co-chair. I just want to charming for promote the contribution from every individual engineer. There is a conversation between, I don't know, Kim and the companies and CNCF and the companies from the high leader to encourage everybody to contribute to open source, but on the other hand, for the individual engineers who already did great work, I think from every six, the leads, the chairs, the TLs, we're happy to just write some paragraph about the thing that you did great in the community, like let your manager know what you did great and then move the needle in the community so that it helps the individual engineers' performance, promotion, yeah, reach out to us. I'm sure SIGS City is more than happy to do that and I try to reach out to some of the other SIGS leads to help the engineers and I always get like long paragraph of the thing that this engineer did great in the SIG. So I think the people who is already in this room probably don't need that anymore, but if you know people who want to start to contribute or who already did the great work, let them know, that's a great way to continue to have your manager to encourage you to contribute. Thank you. Actually, another quick little thing on that. I know other people have, I have written promo statements for people that don't work for Google, just for other helpful things. And we've also helped, not exactly the same, but we've also written like visa letters in terms of support for people to get citizenship or to travel to places. That is something Steering has done multiple times in the past. No, yeah, yeah, highlighting the importance of the area is one of the things that we do, but also the CNCF, as G.C. mentioned. Also just want to have a really quick plus one. If anyone wants to hear more about why you should upstream patches and not fork, I'm ramping up into our fork at GKE and we have been maintaining this a long time, have very mature tooling around this. And yeah, we still try to minimize patches as much as possible. It's very expensive to maintain patches on top of a project as active as Kubernetes. If you want to talk more about that, come catch up with us later. All right, I guess it's me. So at perhaps the risk of my health, I will be a little bit of a devil's advocate on the end user question. So I think we're a little bit fighting reality to say that end user, the vast majority of end user companies are going to ever support extensive contribution from their engineers. I mean, I think there's a few very special end user communities that depend really heavily on Kubernetes that probably will do so. But I think we should ask ourselves maybe what is the best way for end user companies to contribute? And I think that somebody brought up earlier, hey, feedback on alphas. Hey, contributing to the requirements process, feeding the vendors who are really financially incentivized to contribute directly to Kubernetes because that's what they sell. They're the ones who are gonna put most of the money into it, but the end users need to give their input because it's useless. There's no point if it doesn't satisfy the end users. But I think it's a little bit deluding ourselves to say, hey, there's a lot of end user companies out there that have it in their incentive structure for somebody to be contributing so that something runs a little bit smoother for them. I think that, I agree, there's a lot of end users don't. There are some that I'd say are more tech inclined that do have something like spotifying groups like that, that can and do. But I think there are certainly other opportunities, even besides providing alpha feedback on this stuff. A good example, most of the real cluster, sys admin type people, they have a pretty good technical understanding of Kubernetes when they can help with things like, they might not have good coding skills, at least for Go and Cycades, but they can certainly help with things like triage. They can help with docs, a lot of the other non-code places, incentivizing that on the actual end user company side is a little bit of a problem. But there are opportunities for them to get engaged and help, even if it's not directly doing a cap or something. Yeah, that's kind of what I'm saying, is can steering or can we, as a community, figure out how can we best support those people to give the input that they can that they're gonna get the support from their companies, because they're not gonna get the support to spend 40 hours a week on writing code for Kubernetes. That's not gonna happen. One of the big challenges for a lot of those and the docs roles and some of the other things like that is going back to metrics and things like that is trying to think of a metric or provide a metric that can demonstrate the impact that they can take back and use to justify that stuff. And that's something that I have been balling over quite a bit. I think where myself and some of the other, like sick docs people might actually try even try and do a panel or talk specifically on trying to look at the business value or the value of docs and things of that nature. But before I ramble on, Niproon had a comment. I really took the microphone from him. I think I'm good. I hope Brigitte had her hand, but I wanna let you finish. No, I just wanted to add one thing over there. My name is Madhav. I used to help run this thing in the community called the Cap Reading Club. The original purpose of that was to try and get end user feedback early on for caps in the release cycle, but that sort of fizzled out. And I think it was Joseph who suggested that there can be collaboration between the technical advisory group for end users and the Kubernetes project. So if we can sort of revive something like that again and start doing these sessions with end users while the release cycle is going on, I think that would be a good starting place at least so that you don't have to have contributors write the code, but people who are actually maintaining the infrastructure to give this feedback to the community early on. I know if I can't share my expressed interest, but I think we need more help with the reading club because time zones are always difficult. And that's part of the reason why I had to step down as well. But I think if we can do something like that, work with us, actually work with the end user group at CHCF and try to revive this a little bit more, that would be a good starting point. Five minutes? I'm wondering if it would make sense to try to highlight some of the contributions end users are making in terms of a mid-cycle blog post or as you mentioned, some sort of Twitter space podcast, whatever. But I'm wondering if you could highlight, hey, look, this is an end user company who wanted something and got what they wanted. Then contributors at other end user companies might be able to take that to their leadership and say, oh, look, we could be doing this too and getting what we need out of Kubernetes. I actually think the CNCF has collection stories like that. Are the blogs? Sorry, I think that, doesn't the CNCF have a collection of stories like that? We. So part of this might just be trying to find better ways to surface that kind of thing. For highlighting our people, I definitely, you know, big plus one, but for at least other stories, I think we just need to surface that information better. Let me also say another thing that we can do is if it's specific to like the Kubernetes blog, you let us know, you let Contribex comms know and we'll signal boost the crap out of it across all of our socials. So like it won't just be through Contribex comms, we'll also have the CNCF Twitter account post it. There's opportunities to cross post it with the CNCF blog. Like we can do a lot with that. It's really just a matter of do you want it specifically on the Kubernetes blog or do you want it on the CNCF blog? And then, you know, I'm not saying it's politics, it's more just preference. That's all. Just to talk on the point that Machia was making and actually in the morning, while coming to the conference, we were exactly discussing patches and how difficult it is to do carry patches. And we were trying to be on like different sides of the spectrum. So what happens is when you're developing a product, the velocity is also important. And hence, like getting the patch in to both places is important. And that's what we need to advocate. At least it's better than not doing upstream at all. So we want to do upstream, but then we want to also maintain the same. So that's what I wanted to basically point out. Hi, I'm from SIG Multicluster. So the end user that Bridget was talking about is definitely of interest to me. And actually what I've heard here so far is every time we start talking about end users, we start talking about getting them to contribute. But at least from my perspective in SIG Multicluster, we just like them to show up without getting the impression that if they stick their finger in, they don't know where it's going to stop. Just getting their input is good. And I also think I'm also curious about if we keep saying that we do all these caps and things get to alpha and beta, but users don't actually start using them until they're GA and they're in products that they can consume. Doesn't that mean really then that we should make GA less of a set in stone thing and be ready more quickly to say, we got this wrong, we'll kill that project, we hear you and we need to do a V2 or without having to wait four years for a gateway API and stuff like that. I will point to John and Dins. I'm Micah. I'm also one of the co-chairs of the LTS Working Group and the flip side of that is stability. Yeah, of course, but sometimes I think when it's obvious, because a big concern is that end users who look at something that we do, that Kubernetes does and decide that it's not for them, they're not going to say that. And so when you do hear from one end user who's saying, well, I think this group is, you've got slings slightly wrong and it doesn't quite match, then there's a lot more other end users who we're not hearing about, we have the same feeling. And so that's why I said, I think we should be ready to kill things more quickly. Because there have been cases where it's been obvious that things have been wrong early on, like maybe KubeFed, stuff like that, but the projects just keep on dying a very slow death and nothing comes up to replace them until they've been killed. And an important thing, I think Tim will say the same thing. Adding stuff, I think that's literally from Tim's talk from like couple months. Adding stuff is like this easy, getting rid of them afterwards. It takes years. I know what I'm talking about. I've changed names for cron jobs. It was for some of you, if you recall, scheduled jobs, the pain that I went with Clayton and going through the entire APM missionary and making sure that both scheduled jobs and cron jobs work, it took us like a year, up to two years. A lot of pain around that. I was the person that started killing a lot of the, like two or three pages of flak from KubeColter Run 4, which I've heard so much different things about myself. And I'll probably do something more in the near future, which will be controversial to some. But that's fine, but it will cost a lot of time. So that's the reason why we have those alpha, beta, NGA. The alpha is the place where we can say, oh, sorry, we will kill it. That's the, and one more point. The contributions that we're talking about doesn't mean that you have to do the thing. The feedback is the contribution that we're looking for. So maybe we could be a little bit more specific with regards. Feedback is already a contributions because you are shaping the future. You are helping to steer it in the correct direction. So by way of history, we wrote this deprecation policy doc way back early in the project. We wrote it to give ourselves plenty of room to kill off things that we thought were bad ideas and described how we would evolve those things. And it turns out now 10 years in, it was completely impractical. And we, I'll speak for a lot of the other long timers, like, we have still bruises from the abuse that we've taken for getting rid of things that were already legitimately marked alpha or beta, right? So the idea of telling somebody at the GA and then saying, haha, not really. Like, it's kind of a non-starter. I'm very sympathetic to the topic of how do we get feedback earlier, more directly. It is difficult. It's in fact, sort of existential with the project of like, we can't launch things that we don't understand and we can't get feedback until we launch them. I don't, I'm not sure how to crack that nut. But pushing things to GA and getting people onto it and then ripping it away is not the path. Just one stat. The entry cloud providers will go away in 131 and that'll get rid of 1.7 million lines of vendor code. And that's taken like four years. And if anybody remembers, I think it was Seattle, the second Seattle, KubeCon, where we sat at the contributor summit and described moving cloud providers out of tree and we thought it would be a two-year project. That was 2017. 18. Oh, Lucas says 16. So eight years later, we're almost done. And ending on this, we have reached the end of the AMA, unfortunately, but all of the folks are here. So feel free to chime in and thanks for answering all the questions and also thanks for bringing up all the questions. Okay, please don't go anywhere. I mean, you can, but it'll hurt my feelings. Oh, you guys can go. That's fine.