 Hello everyone! We'll get started now. My name is Christophe Blacker. This is the Kubernetes Steering Committee Ask Me Anything session. So this is going to be an interactive session between us and the community for you to hopefully ask us some questions and understand how the Kubernetes community is governed. So brief introductions on who we are. As I said, my name is Christophe Blacker. I'm a principal SRE at Red Hat as my day job and I'm in my second term on the Kubernetes Steering Committee and we'll just keep going down the line. I guess I'll start since I'm holding the mic. My name is Bob Killen. I am a program manager at Google. In Kubernetes I'm a member of the Steering Committee and also chair of Sick Contruder Experience. I've been involved with the project more actively since 2017 or so and I am still in my first term as Steering. I'm Tim Pepper, a software engineer by trade and currently the interim head of VMware's open source program office. I've been active in contributor experience and SIG release and the working group around long-term support and previously was on the code of conduct committee but was elected to the steering committee this past fall so I'm one of the newbies. Hi, my nickname is Jim's. I work for VMware as well, software engineer by trade. I help with things in SIG architecture, SIG node and SIG kits infrastructure. Hello everyone. I am Paris, I work at Apple. I'm an emeritus chair for SIG contributor experience. This is actually my second and last term on Steering Committee and I'm also the Kubernetes governing board rep. Hey everyone, I'm Steven Augustus, head of open source at Cisco. Currently one of the co-chairs for SIG release, one of the steering committee members and emeritus SIG PM and SIG Azure chair. And we have a seventh member of our committee who isn't here today, Jordan Leggett. Unfortunately he wouldn't be able to join us but we did want to call him out that there are seven of us that sit on this committee. We are the kind of like top governing group within the committee. I think Steven, if you want to briefly touch on us and our roles in the community governance model, I was like, do I remember the picture? I remember the picture. So there are a few different governance shapes within Kubernetes. There are committees. The SIGs are special interest groups within SIGs are sub-projects. So sub-projects are actually the groups that are responsible for owning code. And I put code in quotes because we have a lot of things that can qualify as code that are not necessarily just code. So there are groups of people that can maybe not be made from time to time and they may be a time-bounded effort to figure out some really interesting topic. Those are called working groups. So a few different things may get together, choose representatives, start a working group. Tim mentioned LTS earlier, our long-term support for Kubernetes. And that was SIG release and Snowden architecture. So basically, yeah. And that lasted for almost two years. So working groups are time-bounded efforts. SIGs are one of the primary governance models. We are responsible for the operations of a specific group within the community. SIGs are pretty interesting because there are some different ways that you can carve them. I'm hoping I'm doing the slide justice. But there are cross-cutting SIGs. They're kind of vertical SIGs for various efforts. So if you think of previously the cloud provider SIGs, for example, so SIG Azure, SIG AWS, and so on and so forth, those were dealing with a very specific model. But now if you look at, say, SIG cloud provider, that's kind of cross-cutting because it's hitting every one of those. SIG release, SIG nodes, SIG architecture, these are kind of concerned with SIG contributor experience as well. They're kind of concerned with cross-cutting community efforts. And then kind of, I won't say the top level, but off to the side are committees. So we are the steering committee and it's the primary governance body for Kubernetes. The steering committee is meant to be effectively a delegate of last resort, ideally. There should be a group that has the charter to do a certain thing within Kubernetes. If it doesn't exist, we're the group you talk to to kind of make the determination where that should go. And then we help form that group, identify leads, and they kick off operations. But the steering committee is meant to handle kind of operations of the community as well as marketing, messaging kind of to the wider community, not just within Kubernetes, but to the world really. And then for committees, we also have the security response committee, our SRC, and the code of conduct committee, our COCC. And those committees are responsible for kind of the names imply for one kind of looking after the community's code of conduct and making sure that we have ways of having those discussions incident resolution. And then on the on the security response committee, kind of this similar mandate, but as it relates to vulnerabilities within Kubernetes. So I said a lot of words as someone want to say more. Okay, so to get us started, I'm going to just throw in a seed question to see if everyone could take a minute and talk about, what do you see as one of the big challenges that Kubernetes as a project is going to face in the next coming years? Who wants to start with that one? I kind of immediately want to toss it to Paris. I think this is going to be the primary one for most of us, and that's the sustainability efforts. We have a lot of areas of the project that are like lacking maintainers, and we are trying to figure out ways to sort of in either engaged like Paris has been involved in with engaging the governing board or other groups to think about ways of how we can get more people involved in the project and staring secondary experience and a bunch of groups. I see a lot of the groups I've been working on trying to think of ways to ensure continuity of the project and growing people in like future leadership roles. One of the big things that's been on the table right now is actually thinking about like terms for chairs as well as like separating out like some of the more roles to make it easier for people to sort of grow into these future roles. I know other people have stuff to say on the subject, so I'll just like pass it on. That gave me the mic. Yeah, I think that's definitely something that we've been working on a lot, which is talking to member companies about how they can get more involved and support full-time maintainers. One of the things that happens in the life cycle of a project is people eventually fall off for whatever reason, whether that's they grow away from the project because they want to get involved in something else, like their day job or they want to go to another project, but that leaves a hole of institutional knowledge. It leaves a hole of vision. It leads a hole of working on major complex problems. That's kind of where we are today. When we talk about new contributors and bringing on new contributors, we have 70,000 contributors, so what we really need is maintainers and growing maintainers. A major effort is how do we get member companies to help support us in ways that are dedicated time? We are working with CNCF and the governing board to come up with different kinds of programs and incentives to better align with those member companies and the work that we have to do upstream. One of the aspects for me in that is communication because so much of this comes back to people. How do those 70,000 people learn what the more core, long-standing people do? So ensuring that our documentation, our developer, our internal documentation, our processes are good and clear, that we have durable artifacts, that our KEPs are understandable, relatable, that they progress. We get some good conversation and it doesn't just peter out. Getting back to having a community meeting again. When I first started, that was one of my entry paths to understanding what was going on. It represents, there's hundreds of hours of YouTube videos that are historical knowledge, institutional knowledge. We kind of paused for a while because it was friction for us leaders to have to create that additional content. But getting back to doing that is enabling our next folks, hopefully, to understand where we are, where we want to go. So we talked a lot about one end of the spectrum, where there are systemic issues that we need to deal with and we are trying to deal with it in various ways. For the people in this room, if you are not yet participating in a SIG, please participate in one. If you're participating in a SIG, see if you can participate in more than one because that's where we are losing more people more quickly because people are not spanning the horizontal one. Yeah, exactly. So, for example, if you're doing things in SIG storage and say, hey, storage in my area, my expertise, I know all these things in storage. I would say, please do some investigations about SIG node because most of the storage related stuff goes on in SIG node and you need to have good working relationship with them. And when some things get changed in Kubelet, your stuff is going to break. So make sure that you can talk to that SIG and make sure you can talk to a SIG testing, for example, right? So you can look at jobs that are breaking apart between multiple SIGs. Steve, if you want to respond. So, yeah, I mean, just to dig into the growing leadership, we're now entering the, we're in our third phase of leadership, roughly, within the community. I think the first round, the first two rounds where there was a lot of time spent with kind of transfer of knowledge and with a big-strap steering committee and having the opportunity to kind of really make sure that the second generation of leaders knew what they needed to be successful. I think right now what we're seeing is there are lots of folks who are in SIG leadership roles, whether it's a chair or a technical lead, they, as y'all were mentioning, don't have the same time and energy to dedicate to the projects, or they are maybe not in a job role where they can dedicate that energy to the projects. But what I think would, I would love to see more of is how can we create people who are, who are leading, right? As you know, there are a lot of, I think, I think, you know, as we've gone through these iterations of the steering committee, we haven't necessarily done the same iterations for SIG chairs and technical leads, right? And we may be in a place where their chairs, I could be one of them at this point, their chairs who have been working on the specific SIG for several years, they're, you know, they're over capacity, they don't know the things they may need to know, or they were kind of there at the time that the SIG was formed and maybe are in leadership because they were there at that time, not necessarily because they were the right leader for that group. So definitely as you contribute to some of these groups, I would love to hear more about how we can create that kind of, you know, building that leadership. And I think a lot of it comes with like understanding, like, when it's time to let something go, or when it's time to delegate something out. So just keep that in mind. Shout out to Tomb. To make sure it was on that. Thank you, everyone. I work with such intelligent and articulate comrades here that like, we, I don't have anything to add to that. So thank you all for that answer. At this point, we'd like to open up to questions from you. If you have any questions about the Kubernetes project about our governance model, about where we've come from or where we're going, we'd love to hear them. Yeah, first would be like, what's going on right now? So where's your biggest support of interest? And on top of this, like, is there any block or anything where kind of a person like me can just look up and see what's going on? Yeah, so, um, so the first part of the question was, what are what's one of the biggest problems that we're trying to identify or that we have identified right now? The second one was, if I wanted to help, where do I get started? Like, where is there? Is there a blog post? Yeah, for sure. Yeah. So yeah, we are going to publish probably hopefully in the next 36 hours, the annual reports. This is a new thing for us. We only have done one edition so far. It's if and I see some folks on their laptops right now, but if you go to cncf.io slash reports and then find Kubernetes community report for 2021. That was our first edition. And that was a way for us to bubble up that roadmap of current initiatives, the things that we celebrate from the last year, where you can get involved each thing actually has like a help wanted area. And they actually detail out what's help wanted. Because you know, the infamous thing to do in open source is to say, Oh, just go take a help wanted issue. But since we're trying to grow maintainers, I think it's important that we identify what that actually means for someone trying to grow into that maintainer role, meaning what would you actually be maintaining. So that's what they're that's where they're going with the help wanted. I'm trying to think of what was the other part of the question. Oh, big problem. We need more reviewers everywhere. That's there's no say we have I think 37 groups at this point. There's no group that we have that doesn't need reviewers, which is very concerning as if y'all are following supply chain security, and the open SSF efforts. Everything that the industry is telling us is that code reviewing is great. Yes, we know that. But how do we get more quality reviewers for such a complex code base, because growing reviewers takes a lot of time. And a lot of us in this room don't have the time, especially when you don't have aligned incentives to have the time. So growing and finding more reviewers for us is imperative at this point, because it does take so long to onboard into the project and grow trust. Trust is the foundation of all of the roles that we have within the project. And that is not something that can be quantified. So that's really kind of the one main like theme. I think that we can pull out from every single group. Obviously, every group runs a little bit differently. That's the whole deal here. They are allowed to have that kind of autonomy so that they can get the work done. But that also introduces complexities, because as Dim's mentioned earlier, when you're going across SIGs, that means you kind of have to know what their norms are and how they do business as well. So yeah, I think that's my answer. Next question. All right. So is there a list somewhere of companies that are hiring people to be full time entertainers? We actually just worked with CNCF recently to create a feature on the CNCF job board that will allow companies to identify where they can provide upstream support. However, if you want something a little quicker than perusing job descriptions, I think dev stats, where we collect the contribution metrics and going through the like the top 10, 20, 50, whatever it is, companies, that's probably a good indication that they at least have some kind of department, whether it's one person, five people, 50 people, 200 people, but it's at least a good way to start a conversation. So if you know people that work at those companies, I would definitely advise reaching out to them. I also tweet about this a lot. So yeah, I always retweet other people's. There's a job board in the main pavilion as well that typically lists like over in the pavilion center that has a bunch of like links and stuff about open recs, different teams that are hiring and speak to them when you're when you're speaking to a potential employer about this state your interest that you're interested in contributing to upstream and what what do they offer as far as a potential slice of time to do that, especially going into that that kind of job relationship, understanding. Okay, what is how much of my time like we all listed at the top, we have day jobs, we have employers and that kind of stuff we have responsibilities to our employers. But all of our employers know at least we're going to spend part of our time working on upstream and having that conversation early and often with your with your employers, they understand what is the value that that that you're bringing to upstream to the community, what value can working in upstream bring to them is an important thing. If you don't know how to talk to your employer about the value that upstream can bring to them. That's definitely a conversation you can have with us. We do this, we do this all the time trying to advocate for like, why contributing to Kubernetes can bring value to your your particular employer. Yeah, I think that so originally I was going to do a shameless plug and say that like, all of us are people that you can have conversations with about that. But also, I think that, you know, especially regarding the time spent upstream, it doesn't always come for free. And I think, you know, over the last five years or so, it wasn't until very recently that I was in a role specifically for contributing upstream, right? It was slices of time at work until people said, what you're doing upstream is more valuable than whatever this job function is. So just keep doing that. So like, sometimes you have to rest it away from from your employer. But yeah, we can help you have that conversation for sure. Sorry, apparently, it was muted. Tim's taking the mic to Tim. No, no, you're all right. I have a comment and a question. On the topic of more reviewers, I want to emphasize you do not need to be an area expert to be a reviewer. All we're doing is writing code. Anybody who knows how to read code can review code and find things that are wrong with it and flags, things that need more review by area experts, that helps so much. So now my question. Once upon a time, we described what we called our swim lanes, what Kubernetes was, who it was for what we were going to do and what we were not going to do. That was seven years ago, maybe eight years ago. Since then, things have changed a little bit. You can look around the conference to see the size change there. We all know that the death of project is sprawl. So when and how do we go about redefining our swim lanes? I guess I'll start out with maybe one point around how we do that. Over the last period, going back to the maintainers question, there have been a number of projects or dependencies that have struggled on maintenance. One of the questions has been, well, can't we just roll that into Kubernetes? This fits well in SIGs such and such. It fits here or there. Shouldn't we just roll it into Kubernetes? We've had to say that actually doesn't make sense. That project has other uses and resources. Yes, we could step to it, but it's not necessarily going to be any better because we're short. So part of it is just sticking to that original mission, I think, and not allowing things that are desperately in need of help to simply come into us because it would be convenient. So when the pressure of, hey, do you think that we can have a 2.0 of Kubernetes? That would be like a signal. When we add more things to the 2.0 bucket, that increases the things about like, okay, what did we do wrong? What did we get right? How many things did we have to fix how many times? So there is a bunch of knowledge that we all have that can be rolled into a thing for a V2 at some point in time in the future, which we are not there yet. Oh, we're not near the bash rewrite. Should I reopen the issue? So I think there's a lot of iteration around this, too. What is currently in the project doesn't necessarily need to stay. I think part of what we've done for the annual reports this go around is definitely look at areas where sub projects were in need of help are maybe so far gone that we're like, hey, let's have a conversation. And on the sub project and the SIG level, right? Okay, let's have a conversation about like, if this still makes sense, if we have the people to support this, if it if it fits somewhere else, right? So like, sometimes the, I guess the call is coming from inside the house, like trying to figure out where these, you know, like where the knobs, you know, that we can we can tweak to make the project a little bit more sustainable, right? I think that comes down to like, so the annual reports, the fact that all of the SIGs, all of the SIGs and other governance groups should have something in even if, even if it's, you know, not as heavyweight as one would do for a special interest group, some sort of lightweight charter to explain what they should be doing and and occasionally reviewing that charter to make sure that still fits, right? And I think that, you know, as we do the annual reports, we do reviews of the charters, we do like, we kind of ask the question, do you still think this this thing does what it says on the tin? And that's a really great conversation for SIG leadership, because you don't realize you're like, hey, I, wow, we aren't touching that anymore. We should like, could we hand this off over here? I think service catalog, you know, the formation or the questions about formation for working group batch, for example, right? We're created opportunities to say, this is something that needs to exist on multiple fronts on the CNT up level, as well as as a working group within and Kubernetes, right? So there are a bunch of different ways for us to go about like, how we iterate over the process. But I think that, you know, the annual reports are a great start. And as SIG leadership really understanding what your charter is, and if you're still fitting into that model, one of those, one of those kind of swim lane principles that that we've, we've talked about a few times is making understanding what the Kubernetes core is, and in understanding what's part of that, and where we can add extension points to allow an ecosystem to flourish around Kubernetes and not being afraid of that. Not being, and also not being afraid to say no. The, as we go through, as we go through that, that, that the evolution and the expansion of the cloud native ecosystem around Kubernetes, there's definitely opportunities in a lot of areas. And even sometimes where Kubernetes has set and created standards for things, thinking like CNI and that kind of stuff, by creating a standard and creating an interface, an extension point, entire ecosystems within the CNCF have sprung up because of that. But we understand there's a lot of those components that don't necessarily need to, and it's not beneficial either to Kubernetes or to those, those ecosystem projects to reside in the core. So it's being unafraid, at least from my perspective, to say no, that isn't like a core competency that we want Kubernetes to focus on. We want to allow an ecosystem to kind of flourish around it, and we'll just provide that, that kind of stable foundation and interconnection points. So a slightly related thing, we've had a push, so probably not everybody in the audience knows, we have alpha features, beta features, and GA features. There's been a push to make sure that we have the core functionality graduated up to GA stable. And through that, and through production readiness reviews, we actually identified a lot of things that were sort of stuck in alpha and beta and decided, you know, these were ideas, they've coalesced into this other place, or they're just not as relevant. We're going to choose to say no and kind of clean house and declare what is our current core. My question actually is a kind of a combination of what I hear that you're arsenic. You're mentioning that you have, like the community have actually a lot of maintainers. This is some of the challenges, right? And what I probably didn't figure out properly, based on my experience, is how actually a company, because we know that for charity, all developers can contribute for free, but in case we want to have more dedication of professionals, because the reviewers means more experienced people that know what to see, what to mark, etc., based on the process. But from accounting and financial perspective, actually the cost of the people which are going to work for the project, whatever it is, how this is going to be managed, because they can, let's say, work one day in the week, or something like this, how this actually, this is answered. I don't know your all companies are recognized with such kind of contribution, but other companies actually doesn't have this experience. Probably, I don't know if this is answered somewhere in the community, but if you can address this, then the senior guys, the experienced guys, the available guys that can actually, the leader types, they probably will become more available for you, because actually each contribution from experienced developer to IP, which is going to, actually is not going to be owned by the company where he or she is employed, is going to be a pure cost for the company. So this is a kind of a challenge that I see in case I decide to propose my company actually to contribute somehow. So one of the business values there that you can pitch is that you're de-risking for the company. So the company has risk, and depending on the project, and if they have some employee embedded in the project, it gives them an early signal of changes that are going to impact the company. And I tend to think of it as an older notion of innovation to have specific IP generation, even as a person who has multiple patents. The real benefit comes in the mindshare, having the humans who can solve problems on staff and are connected to the space to make that problem solving more efficient. If you're outside the project and you're just kind of echoing a bug report, you're not going to get anywhere quick on solving the problem. You know, we've also talked, there is another model where foundations come to employ people. We kind of joke around that we, it doesn't matter who our current employer is, we kind of bounce around, we do our job, we have our position in the community not tied to an employer. And certainly when you get to a level of maintenance, companies are coming after you. They want you to work for you because they value what you bring. One of the comments, let's have like de-risking your investment of it, like, sorry, feedback on it, open sources, honestly done by the people that show up. So it's great to have someone that can represent your interests within the project, like on feature direction. There's a lot of times where, you know, the project is looking for end user advocates and people like that to help provide feedback, people to test early to help contribute code. And like, otherwise, we're sort of developing features. I don't want to say in a vacuum, but you know, we're sort of doing what we think is best. And by having more end user groups and other people, like, directly contributing and directly getting involved helps, you know, us develop the features and develop the things that are better for you, better for the other end user groups that want to use the project. We're running up on time. If anybody has any final quick thoughts. Yep. I think the foundation has a huge role to play here. And that's something that I've pitched now. And I'm going to continue to pitch, which is helping member companies find business value, teaching them how to hire and maintain and retain maintainers. One of the things that a lot of companies don't have is open source strategists. It's a role that I think a lot of our companies should have. Maybe you don't have an OSPO, but you should definitely have an open source strategy at the end of the day, which is where you're contributing and why. Because it's, and I feel like in the case of Kubernetes, it's very advantageous to align with upstream. We have a ton of benefits. If you align with upstream, then you get our beautiful doc set, which means you don't have to build docs in house. And then also there's a ton of other business value like expertise. It just depends on what your product is and where your product is going. And that's how you can align those folks in those areas. Another big one is influence. By growing that person in that area, you're gaining the influence because you needed a seat at the design table. A lot of us are investing very large sums of money into this project and ecosystem. And it's very important that you have a seat at the table if you're going to invest that kind of money. So I want to like distill something that we're seeing here to kind of riff off of the other side of Tim's point. Hey, you can just get up and write some code. You don't have to just write code, right? All of these roles that we're talking about that go to sustainability of projects and talking about the business value internally, they're not necessarily engineering roles. In fact, most of them are not. Right? So think about like you have you have folks in your company to have those discussions with to activate around open source that are maybe not focused on open source right now and they could be. And you don't have to be a maintainer to show up. Okay, so we are we unfortunately at time for this session. However, we're highly available people. We may sound like very busy people, but we're also very friendly. You can come up and talk to us ways to get in touch with the Kubernetes steering committee. We have a steering committee channel on Slack. We have email addresses up there for both our public mailing list as well as our private mailing list. If there's any concerns we've raised privately, we have a public recorded meeting every month that is open to community members to both listen in to the issues and things that the steering committee is actively dealing with, as well as to raise concerns directly to the steering committee. If you have questions about how something's operating, or if you have concerns to raise. We also this this is an elected position. We have elections every fall. So if you're interested in getting involved in open source governance or what the nature of this role is, please come and talk to us. Thank you everyone. We'll be walking the halls. We're also extremely online. Hit us on Twitter.