 Hi everyone, welcome to probably the last session of the day. Before we head to Boothcrawl and poster sessions, what are we going to talk about here? So as you might know, this is the steering committee of Kubernetes and this is the maintain a track session. So we'll be going to talking about some updates from what we have been doing in the past few months and something which is a surprise, which is related to the title, we'll come to that later on in the next part of the presentation. So I'm Nabarun. I'm Park Hoshi from Dark Cloud and I'm a newly elected member of the steering. Thank you. So the steering committee is a body of seven people and the people are spread across the globe from a lot of different companies and the committee usually goes through election every year where almost half of the committee rolls out or changes every year and is up for election. Half of the seats change. Before you go on to what we do, why do we need this committee even? The reason is we are very big. We have almost 85,000 plus contributors, contributing Kubernetes in the lifespan of the project. Currently we have almost 1200 org members. We used to have a lot until a few months back, but what we aim to do is we aim to prune org members every year who are inactive in the last screening duration. We have almost like 350 plus repos and 30 plus community groups. Community groups are essentially sakes, working groups and committees like the steering committee. We are the fifth largest open source project by developer Velocity, but last year I think we were second just after the kernel. Enough about why do we exist, but what does the steering do? So we are essentially the governing body of the Kubernetes project, making non-technical decisions about the project. And we also oversee the operations of the other community groups and if they are conforming to the charter that they decided to work on. And we also decide on if the updates to their charters are good for the long-term sustenance of the community. We also handle things related to financial planning. We tackle things like if any of the groups requires money for, let's say, giving out some swag or subscription to some service which will help them in fulfilling their work. And we define the project values and structure. You might have seen the Kubernetes project values that is upheld by the steering committee. Now, a few updates. Since, in Chicago, it's just been like three months, but we have progressed on a few things that we identified are very important for the community. One of them being annual reports. So these reports are supposed to be submitted by each community group every year to signify the health of the project, to give updates about what they did in the past year. Now, until last year, there were almost eight or nine questions of them, like most of them could have been generated data. Like how many caps did you work on? What caps did you work on? What is the status of the cap? What did you ship in the last year? Or how many contributors were there to your subprojects? And in last year, what we saw is we saw that eight groups didn't file the report, whereas 22 groups did file the report. Now, this made us go back to the drawing board and think, what is wrong? Why aren't one-third of our groups not even submitting the annual reports? And what can we do to make the process better for them? So we went ahead, talked with the community members, the chairs and tech leads, and we talked amongst ourselves, the standing committee, with the goal of making the annual reports better. So what we did is we collated or coalesced all the questions down to just two important questions and moved out all the generated content out into like separate things that we can generate any day if you want any community metrics. So the questions are, the first being what work did the SIG do that should be highlighted? It may be something which is in caps already or it may be something which is not captured by caps because caps only hold record for technical decisions and technical stuff inside the subproject. Nontechnical things usually don't show up in Kubernetes enhancement proposals. So it's important for the SIGs to highlight the work that they did across the year. And the next point is probably the more important one. What are the areas that the community groups feel that they need most help with? This has like far-reaching implications. First, if the signal that we get to know like which areas are understabbed, which areas have less number of maintainers and which need more curation or some more directed efforts like mentorship groups to grow more owners or grow more contributors in that area. And this also helps people who make decisions in companies to staff open source contributions by making sure that the areas which are understabbed and if they care about those areas in their products, they can stop those areas and make the sustenance better. For the groups, if you are a chair or a tech lead, two important dates. May 1st to file the PR to update the annual reports for review and we need to merge them by May 22nd. If you're not a chair or tech lead and if you contribute to any of the community groups in Kubernetes, I would highly recommend you to go ahead and help the chairs and TLS build that report. We have had very good examples in the last year where contributors were not the leads of those groups actually write the reports with the help of the leads. And that also makes them very good candidates for knowing more context in the groups and the future leaders of the groups essentially. So if you want to grow, that's also one ways that you can contribute. Now, while reviewing your sakes or working groups, if you're a SIG, I would highly request everyone to consider like adopting Subproject Leads. This is a new role, that new governance role that we introduced last year to ensure that there is a good stepping stone from a contributor to someone who owns code in a Subproject to a tech lead. Now, the Subproject Leads, you can look at the Subproject Leads when you want someone else to step in as a technical lead in your SIG and that is very important. And if I put annual reports, one thing that we did was going back to the context of financial planning, there were two reports that we usually maintain, the Steering Report and the Funding Report. The Funding Report usually used to have tickets for like request of resources. For example, if you want to get a subscription to a service like Buffer, you would request like, I need XYZ amount per month for this. Or if you're a Subproject or some area of Kubernetes where you need infrared resources, you can ask there and then we essentially look forward the request to CNCF through ServiceDex. Now, what we're seeing is having two different reports really did not make much sense. It's better to consolidate both into the same, so you consolidated funding into Steering. So if you in future need any help with resourcing, you have to create an issue in Steering. Now, I talked about the elections and how do we rotate every year? Elections are coming up in September, just before Q1 North America. I would highly recommend anyone who wants to make a difference or who sees that they can make a difference to the project, come and raise their hands for the elections, write a manifesto what they want to do and just participate in our process. That's one of the great ways to provide an impact to the community. Now, coming back to the title of where we've started. Like, where is the project going? It's the 10th year and we wanted to basically know what did our Emeritus Steering Committee members thought about their whole journey from day zero of Kubernetes to day 10 and what they feel about the future. What is going to come in Kubernetes or what do they see Kubernetes going towards in the next decade? So we asked a few concise questions and thanks to all of our Emeritus Steering Committee members for responding back and answering our questions and giving us the time and the space to actually know better what the intended Kubernetes to be and if they still think like that is the goal and if it's changed, what's their goal for the next decade? Now, we collated all those answers into a few themes like eight or 10 themes. We'll just go through some timelines of themes starting with the unexpected success of the project and what do they think about it right now? So Tim mentions that the most significant thing right now is the sheer scale of the community and how big it has become, which is also emphasized by Paris who mentioned that it was probably one of the first projects to reach 10,000 contributors and we are at 86,500 contributors last week. Maybe we have grown by 100 more as we see the velocity by now and it has become grand. And because of the sheer scale of Kubernetes, we have, and the composability of Kubernetes, we built a grand ecosystem around it. You are here for Kipcon and CloudNativeCon. So on one side, there is Kubernetes and on the other side, there is the whole CloudNative landscape of how many? I keep forgetting, I think it's 180 plus projects at this point in the CNCF and everything is built around Kubernetes. So this is what has been built and probably nobody expected it to be this big back in like 10 years back. And with that, we have a worldwide spanning community with Kipcons happening this year in four different locations. I think this is the first year when Kipcon is happening in North America, Europe, China, and India, which is showing up as the new entrant to the Kipcon org. Or now with the unexpected success, there's a cost. What is it? Almost half of the internet depends on Kubernetes. No pressure, right? Might break a release or two. The internet might break, maybe, we'll see. Having said that, it is also critical to make sure that because of the popularity of the project, things don't break and we ensure things like software supply chain security or whenever you deploy apps to Kubernetes, things are fine. When you run critical workloads on Kubernetes, things should run as usual. But there's a positive point. We will adapt to run workloads of the next decade. We started with like stateless applications, then went to stateful applications, then batch workloads, periodic workloads, HPC workloads, event-driven workloads, and the new age of AI workloads. But with the hidden success and the cost of popularity, there's a hidden cost too. And more so in the context of steering, it is hard work and it's not at all fun work. At many times, it's grunt work, be it like, I talked about the annual reports, 34 or 40 groups come up with the annual reports, collating them to a annual report called Scienceive Annual Report. Thanks to Paris and Bob. We did see that in 2022. I mean, many of us have used that annual report to convince our bosses to fund us to work on open source. Not just this Qtrip or anything, but day-to-day activities, doing things like Qtrip, doing things like steering, doing things like release. But it's not fun work at all. It's really hard work. And I thank everyone who has been doing this for years and years. Now, the stuffing situation, right? We have, the common theme has been funding of open source. But how many do fund open source? We haven't talked about this extensively in the Contributor Summit as well, in both the AMAs from the steering committee as well as the CNCF staff. The main trend which is being seen right now is since everything is like a well-oiled machine, Kubernetes releases are consistently coming every four months. Now, people have decreased their understanding or appreciation of what this machinery is. And what we've seen across time is the stuffing is reducing over time. We can see that in DevStats very easily, that the number of unique contributors across time had reached a peak back in, I would say like 2021 or 2022, pardon the numbers, but it is decreasing right now. And that is a grave situation. And that is a cost to us. And we need to make sure that we don't go beyond the criticality where the community will just break. Now, some challenges. What were the challenges across this 10 years? And some of the challenges will also be relevant for the next decade. Paris mentions that being the only woman for a while and not having her voice heard was one of the big problems. And even if you saw the current committee members, you would see a common pattern. This needs to be changed or we need more people from different set of backgrounds to come and join the community, to show interest in the community. The steering committee as well as the Kubernetes community so that people from everywhere feel heard and they can put their voices equally out in the open. The next step, Clayton mentions that things will keep on continuing to be heard. And I think this is the general theme. Things are not going to be, not going to get easy anytime soon. But what we need to do is make Kubernetes easier to consume. Make sure that people are able to use Kubernetes time to time. And there's one more thing about community is once people rotate out of the community, often the context gets lost. It's very important for us to keep documenting things that run the community. It's important to keep things updated. For example, when I was the release leader of Kubernetes 1.2.1, things were drastically different from what they are right now. And when I was there, I'm pretty sure that things were very different when people were releasing or Josh was releasing Kubernetes before 1.2.1.0. Josh, I believe that was that or what? Oh, wow. So the importance of evolution of documentation and keeping context is very important. Things change, things keep on changing and we should not lose track of knowledge, experience and culture as well. What Joe mentions is on a different tangent as well. Too many choices. When you consume Kubernetes, there are a lot of things, lot of options that you have, but have we standardized on something? When I was talking to Joe, he mentioned that things like QADM, which made cluster bootstrapping a standard, we should have brought it up to a much bigger level and coalesced on all the different, 100 different ways to bring up a cluster, 100 different ways to consume Kubernetes. What if there's a standardized way? And with change, Derek mentions that we have to be patient with everything. I remember a sentence from Kristoff, who says like, we have to take a beat of the situation whenever we face a problem. When there is a problem, we should pause, sit down and think like what the community thinks about this, take a step back and then try to solve it. And finally, I think if any company or if any person is sitting here who consumes Kubernetes and has been consuming Kubernetes over time, upgrades is a pain. Upgrade, I believe like there was a report from some analytics company who mentioned that the major users of Kubernetes when we released 1.26 were still like 1.22 or 1.21. I don't remember the exact numbers or exact versions, but it was like when we released certain version, the most used is still like minus four or minus five, which probably are already out of date because we support only three at a time. And that's all about the challenges and I'll hand over to Paco to talk about the next part of the presentation. Also, I want to take a break for the upgrades because it really hurts many users. Years ago, when we released a new version, they asked me what's the new features and they are very curious about the new versions. But recently, I find that many users ask when we release a new release, they ask me why. A new release needs upgrade, there's a lot of work and they want no action required upgrades, not the current one, I think. And also Jordan has mentioned that in last QTS in Europe about that we want users to not have to look the details of their tree logs and upgrade. But it is so hard for us, I think. And so there are challenges here. And also we build the LTS team group to work on how to make this better experience for users to upgrade and there's many talks and also it will take many efforts from our maintainers. And here's the maintainer burnout. And firstly, the biggest challenge here is that mentioned Nikita, that many employers to found the consumers, I think recent several months, some of the maintainers did not leave the community for some, for job reason. And this is quite a big problem, I think. And also, maintainers at the earlier days, they can know everything about their project. But now it is bigger and bigger and not all maintainers can know everything. And so there are so many sticks. And sometimes we need to work across sticks and things become worse now, I think. And for a new beginner, when they want to know more about communities, they find it so hard. And so many things is updating and to catch up with those changes is very challenging. And also, we still have a lot of work to be done. Mr. Baijoi, and also he asked a lot of questions and thinks there's many things to do. And for customer mean, it is still harder to, than it really needs to be. So there's a lot of work we can done. And also Clayton mentioned that there's the, I think it's the baseline that we should keep the SLOs and something like that is very important. And Dimps also mentioned that we can, we should leave it sustainable and in better hands than you're in early form. And later we will talk about, so next, you can listen to Dimps and team Hawkins talk tomorrow, I think. And this is about the current maintainers status. And another part is the clear boundaries. First, currently Kubernetes call is so important and we should make it sustainable call. Tim Pepper mentioned that. And also, we need to define a clear boundary between the core Kubernetes and the six sponsored new sub projects. And also we update the charts about the sub project leads. And this may help to our sub projects leads to grow and be recognized and we can in the sub projects, contributors can be very new ideas can test new ideas there. This will help the community to grow. And this one I think this is what we should do and the most important part is people is the most important part of our community. Contributors and also users. We should make sure everyone's voice was heard and respected mentioned by Clinton. And we should remember that we should give focus to people and find the empathy, find ways to translate and bridge the cross conflicts. This is quite important. And the Kubernetes has always been about the people and other previous member, I think most of them are so respect every contributions, big or small. And I think the most important part is what, because things change every day. And for example, now the AI is the new trend. And so the steering committee will not decide where the project go, but that's the contributors. We will make it possible to go where the contributor want to. That's very, very important. I think not only contributors, but also community users. And we should thank everyone about the involving in the community and doing things. This really helps us and listen to the community. And also we need to hold the truth to the core values. This is the most important part. And how to get that? We have several, we have done something, like weekly meeting, new users and contributors can show up there to share your ideas. And also this is quite important because when we do the annual report this before, this is quite important part of the, and also we have the shadow programs and currently not only RIS team and also PR and also other parts. This will help new contributors to grow. And we also asked about the next decade, but we cannot predict the future. So here are some ideas. First of all, this is asked by before about do we have the plan for V2? But I think until now I don't know any process about that. I think it is good. And so we will keep V1 going, yeah. And also we, in the new next decade, we should still do the right thing like before. I think this is the keystone technology here. And also we should focus on the distributor to the system developers and empower more people. Maybe 10 times or 100 times, but who knows? I'm not sure about that, but I think AI will help us and we may, as the user group grows so much, I think we may do that in the future. And AI is a new wave and you can see many things related to AI in KubeCon. And in today's keynote, Nikita mentioned that I find this picture is very interesting. The AI is the center of the universe now. And AI is the new wave and we're good to see the infestation in this area is also in KubeCon communities. To argue this, we should also consider building more connections with other communities like Linus Foundation. And we should collaborate with them to make the wave larger. And Clinton also mentioned that communities can be a big part of that, yes, I think. And this is an opportunity to improve those AI jobs on communities platform, on the platform. Yes, the big opportunity for us, also a challenge. So, any questions? Well, I think other steering may share some comments about. Okay, so one of the questions I have is, have any decisions of the steering committee ever been challenged and how do you handle that? Bob. I'll start with this. Honestly, it is quite difficult. We do essentially try and get together and make sure that we can speak publicly with one voice. We might be slow to reply on some things, but it's not always the case. And honestly, I don't think we've had two situations that are exactly alike. So it's really just trying to do our best and work from there. So even internally, when we try to make a decision, we have a rule to have majority consensus so that we agree on some decisions. And even when we try to vote on a decision, we keep a very long soak time in the community so that everyone can come in and comment. So that we understand what is the vibe of the majority. We keep the discussions in public. We keep the discourse in public so that the community as a whole can have enough time to come and communicate to us their concerns. So far, we have had only, as Bob said, like one or two situations where, or probably like, more than that. Yeah, I mean, yeah. That's why we have a private meeting and also another public meeting. Coming to the meetings, we have a monthly public meeting and a monthly bi-weekly public meeting and a bi-weekly private meeting. In the private meetings, we try to discuss any of the stuff which can create conflicts and try to come to a consensus so that it's publicly consumable. And anyone can come to us and raise their concerns in the public meetings or mail us in steering at the rate, communities.io or even privately, let us know their concerns in steering private at the rate, communities.io or on Slack. So they're available through three mechanisms. That was a nice question, though. Any more questions? It's a very hard question. Maybe a stupid question. What happens when a work group doesn't file the annual report? What happens to these eight work groups? For most, nothing happens. For some, for all of them who don't file, we try to see what went wrong or what is going wrong if they have less contributors. We try to analyze the situation, take a beat of the situation and decide accordingly. For example, we have some working groups in the past one year that we saw probably are not relevant or they have sufficed with their goal because working groups are supposed to be not perpetual. They have a goal. If their goal is done, they should spin down or if they are relevant in some other circle, probably they should move there. For example, IoT Edge, that is more relevant at the CNCF level because it's not just about Kubernetes but about other projects as well. And we ask them to move to the CNCF level. So that's why we archive working groups. We have archived CIGIY in the past year. Not in? Yeah, but we were discussing about this because that is not very relevant anymore. We might archive that. So we do take a look at, and even before this discussion comes into the picture, we try to ping 50 times, 100 times, DMs publicly so that we get optimum attention. Any more questions? Thank you all for attending and have a nice good talk.