 So what's the session going to be about? So we're going to talk about what does the Kubernetes steering committee steer? I'm Navarone. And I'm supposed to be Bob Killen? But hey, you're Tim, no? So here are the members of the committee. So we are a seven-member committee where Bob, Tim, Carlos, Christoph, Benjamin, Stephen, and I will talk more about how is the committee staffed in a way. So let's see some stats about the Kubernetes project and why are we relevant. Kubernetes is a big project. In its whole lifetime, we have had almost 80,000 contributors. I think we're having 10% year-on-year growth, 10% or 15%. There are around 1,800 org members and 345 repositories across four GitHub organizations. During 2022, it was the sixth largest open source project by developer activity and fifth largest by number of PRs. And in the past, I think in 2021 or 2022, we were number two in terms of project velocity, which was just behind Linux itself. Needless to say, it's quite large. And in order to manage the technical aspects of the project with these many people contributing to the project, we have to put a lot into how we structure ourselves. What kind of groups on what areas of code? We have 345 repos, so we need maintainers for all of them. How do you potentially resolve conflict between groups or inside groups themselves? How do you know the groups are healthy? They're not burning out or they need more maintainers or how do you actually ensure that they continue state of the over time? Or maybe sometimes groups are formed for certain reason and after achieving what they want to do, they may not be relevant anymore. And we have to make a decision on if they're still needed. And these are the project governing things that we do and which makes us relevant. And where we come into the picture. Now, here's a picture of what are our community groups and how we are organizationally structured. I would encourage you all to check out the link at some point in time. But I'll give you a TLDR. We have this picture as well as a document detailing what each group does and what kind of groups we have and what they're supposed to do or what should be the scope of each group. TLDR is we have three types of groups, special interest groups are SIGs, working groups are WGs and committees. So special interest groups make up the majority of our community groups. They essentially own code. For example, you might have used kubectl. So six CLI maintains that area of the code. We have working groups, which are transient groups. They're supposed to achieve a certain use case. For example, very recently yesterday we had conversations around long-term support. So working group LTS was one of the groups set up sometime back and they achieved some amount of LTS capabilities and then they grabbed up. Now, because there is more interest we are bringing that group up. So just to give an example of what is the working group. And then we have committees, which is what we are. There are two more committees. One is the security response committee who handle any sort of CVs, security disclosures. If anyone wants to reach out, like, hey, I found a vulnerability in your code, that they are the people who handle it. And then we have code of conduct committee. That's really important because they ensure that the code of conduct of our community it remains enforced and they handle any kind of conflicts arising in the community. So the steering committee is essentially the top-level governance body within the project. So what does the steering do? It is basically a synopsis of the formal definition of what we are supposed to do. We are the governing body of the project. We provide decision-making and oversight into activities of the project and what other groups are supposed to do. We also do provide financial planning. For example, like, if someone wants funding for certain things, we try to redirect that to whoever is supposed to fund that. For example, FCNCF is the right authority. And very importantly, we define the project values and the structure of the project. Now, these are our direct responsibilities. We do a lot of this. I would basically go on next and let's try to understand holistically what do we really do. So whatever we do comes up to this thing that we want to protect the long-term sustainability of the community. How do we protect our contributors? How do we encourage a leadership pipeline? How do we ensure that people grow in the community? We don't have any area of the community lagging behind or we have less amount of maintainers in an area. And if we look at such a big project and a big community, we also do want to engage with commercial contributors, people or companies or vendors or end users. How do we promote them to put in resources or people to this project to ensure that people are funded to work on Kubernetes and hence its sustenance? With that, I'm going to hand it over to Tim. So bear with me since Bob was unable to make it. I'm filling in for Bob. I should know all of this stuff, but he has really awesome detailed speaker notes. And I want to actually make sure I touch on the things that he says. So first, this idea of supporting and protecting contributors and the breakout of the SIGs, the working groups, the committees, the different reasons these entities exist. One thing maybe that everyone didn't say explicitly is that a steering committee, you might think of us as the overarching, like in that 80,000 people in the 300 repos and that sort of funnel as being a hierarchy up to the top, the hierarchy of importance or something like that. And we try to be the opposite. We try to make sure that the vast majority of things are delegated out to proper topical owners. But then there are some unusual things that come up. So a couple of examples of these recently. So I've been a member of a variety of nonprofit boards. I do volunteering and things like that. And through some unfortunate experiences, one of the things I've learned when I volunteer for something is to ask because I'm an American and we're a litigious society, what type of liability insurance do you offer your volunteers? If I do something and something goes wrong and somebody decides to sue me, what happens? And this is a question that's been coming up more and more in open source. And in particular for a project the size of Kubernetes. We've had this come up in multiple different areas. So we've been trying to figure out how we established some sort of a framework to give protections to our open source contributors. It's tricky. We have lawyers involved, we're looking at different options but we've been trying to force this issue as we've recognized at our level within the project that there isn't, we don't have a SIG legal for example. So we are sort of a place where an unusual thing like this bubbles up and we don't necessarily have this exactly resolved yet, I don't feel like, but we're actually making some progress and the ecosystem is starting to realize this is something we need to think about and do. Another angle of this is increasingly perhaps you've seen talk of regulation both in Europe and in North America, there's talk of regulating the way software is developed and distributed and that has impacts on open source. So those are perhaps some places where we might put our voice in and represent the project and our developers. A similar area of where we sort of might weigh in on something is providing visa support to our contributors. I'm very privileged as an American, I have a passport that allows me to more or less travel the world and I don't have to think about it but very commonly we have contributors who are major contributors in the projects in this space, they work up some really interesting thing, describe it in a potential presentation for a conference, get it accepted to the conference and then the hosting country of the conference says, oh, you need to do paperwork to improve why you're coming to our country and there is a sort of senior body within the organization, it comes to us to write that letter of support for those individuals to help them be able to come and share their experiences and lead within the project. So those are maybe not something that you exactly see in the details of the charter but things that kind of escalate up to us where we're supporting our community. Another big area is project health. So it's really easy I think to be deceived perhaps by the 10,000 people who are here this week. It is, I've been in this project for quite a while and it continues to overwhelm me each one of these conferences, the growth but despite the outward appearances, we're hurting and most of open sources between the pandemic, unusual geopolitics, economic pressures, a lot of companies who would maybe previously been more actively supporting open source and open source developers are supporting in different ways and or individuals who are doing things on a volunteer basis or having to focus on earning a paycheck or different things like that have led to a more recent decrease in the actual number of contributions. So this is a chart that Sophia Vargas at Google created to show that you might think that everything's going great but over the last couple of years actually we've seen some decrease and that's hurting, we have less active, we have a smaller number of active people in aggregate and that leads to more of the people who are active carrying more load and then we run into problems of burnout. So we've definitely been experiencing attrition and our contributor experience SIG has been working to bring new contributors but this takes time, it's difficult and then perhaps at our level we can be advocating out to member companies of the CNCF or others in the ecosystem or as a great example I think Don Foster's keynote at the beginning, at the end of this morning's beginning keynotes, talking about what it means to be contributing to the humans in open source, making sure that that message gets out there as something that we try to support because we need that for our developers and then more simple conceptually types of programs making sure that we've got mentoring cohorts working through our project and that we're inviting to new people so that they can show up and contribute. So with that you have something like a leadership pipeline. We have a variety of sort of titled or named roles within the project and we've been working to evolve that across time. We want to encourage individuals to do the important work and sometimes that requires having some structure. So we used to just have a very simple flat scenario where we had SIG leads or SIG chairs and that was that but there's a lot of responsibility that falls on that person. Everything from recording a meeting on Zoom, uploading that Zoom meeting to YouTube, keeping the calendar up to date, the agenda but also the code, doing code reviews and approvals and things like that mentoring of new people coming into the SIG. So we've worked to split that out more so that there's a separation of chair duties and tech lead responsibilities so that we can maybe have more people come in and have a specific responsibility. The ambiguity in the past was confusing both to new contributors and to the existing folks in leadership. So with these separations and also we can have maybe more formalized sub-project leaderships. That's not something that's officially merged as a process and I guess I should mention there that when I talk about merging process we literally do that. Our processes are written and marked down they merge into get of their public and known. They go through the normal open source review process as we iterate as a project body towards making decisions on how we're gonna run but we as a body try to instigate change in leadership on those things. So we're working on some evolution there. So on the employer's topic then we need to engage the organizations who are here effectively at KubeCon. The keynote this morning they talked about 300 some odd end user companies are members of CNCF 800 companies total. We need those companies valuing the humans doing work also in these projects giving those employees an incentive hopefully to participate and contribute to these projects. So our steering committee also works to interface with some of those companies and we talk to our own employers and some of the big groups, the Googles and Amazons and make sure that we're advocating and helping them understand the business value. This is one of the weird things for me as an engineer having to learn through my career to advocate for business value. It's not just about code and checking does the thing compile and run functionally correctly but we also have to think about the business size. So this is something that our steering committee does and not just with the big cloud providers the Googles, Amazon, the VMware sorts of companies but also end user companies, the Mercedes or Shopify or Apple type of companies helping them understand that they also as a consumer of this open source stuff even if they're not making money directly off of it it might make sense for them to be contributing to the long-term sustainability of the project. So let's say we succeed in that message. We've convinced somebody like, hey, I'm gonna start dedicating an engineer's time in part or in whole to these projects. Those people need a way to come in and understand where help is needed, where they could apply their labor. So one of the things that we've been doing over the last few years is an annual report process. Each of the SIGs writes up a document describing where they've been the past year and giving some roadmap information for the coming year and shining a light a bit on areas of help needed. So that hopefully if somebody is looking they see the progress of the project and kind of can project where it's going and maybe get on board and contribute. So we have 30 some odd SIGs so you can imagine 30 times five to 10 pages of documentation like there's hundreds of pages of where we are as a project. Steering consolidates that into a shorter report around 20 pages and we use that as something for collateral that we can try to start conversations around where we are, where we're going and hopefully get more people involved with the long-term sustaining on the project. And that is our last slide. We're on 20 minutes ish in. We've got a bit of time for Q and A. We'll pass the mic around and then there's just some links which I'll leave up while we chat on where to find us, where to get more information on what we do. Yeah, so any questions? Are you ready for dinner? So how easy or hard are you finding people that wanna volunteer at the time to be part of the steering committee and are you facing burnout with the existing members of it? So did we say explicitly that we're an elected body? So members of our community have voted for us to represent them. We also had to either be nominated by somebody in the community or self-nominate. So in the case where somebody is nominated, we have a checkpoint to say like, are you sure you wanna do this? Do you have the time? Can you do this? But basically those of us who are on steering have been on steering have chosen to contribute our time to this. Burnout is real though. There are weird things that come up. One week you may do almost zero hours of steering related work and here and there, it will be a full-time job for a week because something has come up. It's relatively unpredictable. Unfortunately, I think that leads to a situation where it biases towards employees of larger companies. This is effectively my job. I'm in a position where I kind of define my job. So I have that flexibility. But if I were in a different role, I couldn't just tell my boss like, oh, our production service with Kubernetes that I'm responsible for running. I'm not gonna be doing that for this week. I've got this community stuff I need to do. So I think that that makes it a little less approachable than it should be and that's a challenge. So we're trying to figure out how to do better on that but I don't know that we have a great answer. Something else we do publicly, like all of our elections, the results of them are on GitHub. So you can see we've had lots of people put their name in the hat. So I think we are getting volunteers but then we still have the problem of burnout. And it's a two-year term that we sign up for. It's really hard to project where you're gonna be as an individual or in a career two years out. So it's tricky. Just a couple of minutes ago, I was actually twisting somebody's arm to put their name in the hat this fall that they should consider being one of the volunteers to do this. So if any of you are interested, if hopefully we haven't scared you away, like these sorts of governance roles are important, an important place to contribute to the overall health of projects. So think about how you might do something yourselves. Thank you. Just a question about like things like which seems pretty clear, like can be handled by like a steering committee but things like what you mentioned, the legal issues is not like super clear because I know like things that might have their own like legal teams for that. So I'm just curious about like the boundary of the responsibilities which handled by the steering committee and handled by CNCF. Thank you. That's another area where things are kind of fuzzy. Again, despite the impression you might get from this massive conference, like I literally don't know what the budget of this thing is, like this is a big deal that the CNCF puts on. They are consummate professionals putting on an event like this. But not necessarily all of the details of how the interactions between that entity and all of the hundreds of projects that are related to CNCF. Those are things that are all emerging and being developed right now. The CNCF similarly has a GitHub repo where these processes are defined and they're actively in the process of definition. Yesterday I was commenting on something for an emerging process that would better clarify where the Kubernetes Code of Conduct Committee is versus the CNCF Code of Conduct Committee. Those are things that are regularly coming up and partly a surprise sort of fashion like, oh, you're doing that, we're doing that. Let's be open source, let's collaborate, let's figure out who should do it and how we can do it together well or if you should do it or me do it. And there are not necessarily clear boundaries but in that open, transparent way. We work really closely with the CNCF and try to figure out what's the best way to go. The CNCF is a corporation, they have a governing board and there's a technical oversight committee as well and we interface with those bodies regularly and things that we're seeing will bring up as sort of emerging patterns, ask if they're seeing. And then also this gentleman here who quietly asked a question, he works on OpenStack, they also have a foundation. We chat with them periodically, try to cross-pollinate ideas and challenges and figure out the best way to solve things together even though there aren't necessarily clear lines or we're totally separate different things but that doesn't mean we can't work together. Thank you. It was really good to see you guys are thinking about how to organize the leadership of the SIGs a little better. And I don't mean this to be a leading question, I'm actually really curious what you think. You're an elected leader, but the SIG leads nominate the replacements. Do you think that's the best way to have that process work? Have you thought of any alternatives? So this is somewhere where I failed because this was very clearly in the real Bob's speaker notes. He mentioned a couple of things on this. So some of those changes in governance that we have so you can't see the speaker notes I guess but we have the ability for SIGs now to define new roles. If a particular SIG things like we need a such and such that SIG can write it up, describe what that's gonna be, get it into their charter and do it. If a SIG wants to have an election, they can do it. So if a SIG wants to operate a particular way that makes the most sense for them, they can. Then the other thing is I was talking about breaking out the chair and the tech lead role. One of the things that we've discussed there is, do we have, and this is maybe, I don't know if you're referring to this, I don't think of it as a contentious thing personally but some people find it contentious. I think we can find a harmonious way to move forward with these things but we've been talking about whether we can or should have terms for leads. And I think that is a really positive thing personally because the term is just to say like every second year at a particular time, I should pause and reflect and be introspective. How is my SIG doing? How am I doing? Does it still make sense for me to lead? Is there somebody I could pull up to hand the reins to? I think that's a very positive process to do and it doesn't mean that you must fade off into the background. It's not removing anything from you. It's a positive, additive, non-zero-sum game way to view the world. The next step of the conversation though is well, if we have terms, should we have term limits? You can only be a lead for two terms or whatever the magic N number is. Three terms, one term, six terms, I don't know. That starts getting more contentious. I don't know that there's a right answer. On the one hand, you want to bring in new people. Have less burnout maybe, spread the load, encourage newcomers. On the other hand, maybe you have somebody who's the excellent professional doing the job perfectly. Everybody wants and has them. And if you have a process that says they must fade away, that doesn't feel right either. So there's an inherent conflict on that. And we don't have an answer. We're just talking about it at this point and we'll see what evolves. I think to your question of elections, elections make sense when there are like, there are a lot of people in the fray who are right for doing their job, but you want to choose between someone. Like let's say you want to choose two out of five people, but you don't have consensus on how do you want to nominate them. I think in those cases, elections make a lot of sense. Unfortunately in our community, when we want to like do succession of chairs or technical leads, we have very few people who are willing to do that job day in and day out because it literally takes a lot of time, bandwidth, and the knowledge to be gained over years to even do that job. So, but I would really love to see like some of our community groups try out elections. I think, code of conduct, staring, and I'm not sure if anyone else has tried elections recently but Quantarybacks does maintain Electo. So, if you want to have an anonymous election mechanism using some GitHub artifacts you can. Thanks for the great talk. I have a question. What's the future of Kubernetes? So, I think looking at the chart, I saw it's okay. It looks quite stable and maybe that's also one of the reasons why people are not joining so much anymore but I don't know, it's just a theory. Thanks. Maybe Kubernetes 2.0, time for it. I can speak to this, I guess. So, I've made my career an open source. I first bumped into open source in 1995. So, I'm coming up on 30 years. I've seen a bunch of repeated patterns. You look at these numbers, I think it's hard to say like there's, as much as I said, like we have a problem. Like this is in many ways a good problem to have compared to a lot of projects. At open source often you have a sole maintainer who is burning out. We do have a lot of people but also then this other picture, there's a decline that could be a worrying thing. The way I'm choosing to positively see this and talk about this, I think it is true, I guess in time we'll see, I could well be wrong but in other large, rapidly growing open source projects, I've seen this massive influx and hype and money and interest and need to stabilize and add features and improve and then at some point it kind of gets good enough. A few years ago we were all joking like the goal is to make Kubernetes boring. Maybe we're starting to get there and it collapses down, not in a fatal way but it collapses down into a stable core. I think that you could look at the project and see the signs of that starting to happen and say, oh, this is a healthy evolution. I think technically like one of the reasons that we see some amount of decline in metrics is also because we have made Kubernetes so pluggable that a lot of entry development has now moved out of tree. For example, cloud providers, storage interfaces, networking, we've made it so modular that people can now develop out of tree and plug it in into a compliant Kubernetes cluster which makes it really stable and like just want to make things boring and maybe release once a year. Don't quote me on this. Any more questions? I think we're on time but can take a couple more questions. Cool then. Thank you so much. Thank you.