 Good morning, all. OK, it is morning, but I'm not even on this time zone. Some of you have been here a while. Good morning. Thank you. All right, so I get to talk about the history of Kubernetes and the history of the Cloud Native Compute Foundation. Now, Chris gave some of the perspective from the Cloud Native Compute Foundation perspective. I am going to give a little bit of it from the Kubernetes perspective and from Google's perspective, interestingly. So first, we're going to go back in time. In 2014 and 2015, Google and a broad number of industry partners brought together what was to be the next evolution of Borg and Omega, the internal container orchestration systems that Google had built and used for years. And they brought forward this idea of Kubernetes. We had a huge cross-industry collaboration. We had Intel. We had CoreOS. We had Samsung. We had Red Hat. We had Google all contributing to this project to bring forward the idea of what CoreOS calls GIFI, Google Infrastructure for Everyone. This project was launched in 2015 with a 1.0 of announcement at OSCON. And all seven of the four founders of the industry had industry-changing vision for Kubernetes. OK, that's a joke. I know it's morning. Anyway, thank you. So all of the founders, all of the people who were broadly interested in Kubernetes had this vision that it was going to change the industry. We were going to take the concept of portable workloads and move it from VMs or software, because Java, of course, had that portable workload vision for a long time. But we were trying to take that portable workload vision and move it to containers. But there was a problem in this. There was a problem in making this transition. And that was that it was Kubernetes by Google. Now, I was brought into the project, in fact, to help make this shift from a company-led project to a community-led project. So the by Google line on this logo, which was the logo that it launched with in 2015, really was a challenge. I got lots and lots of conversations started with, here's the Wikipedia page of all the projects Google has killed, why would I bother? We all mourn Google Reader. That said, bringing together a broad industry group to change the conversation about cloud computing, to move the concepts from talking about VMs or talking about sticky services in clouds to having a portable workload unit of containers was really going to be a thing that took corporate independence for the open source project. And the Linux Foundation is known for bringing together all of these groups, all of these companies, to move forward the actual industry changing big picture visions. So as we brought Kubernetes out at 1.0 in 2015, we knew and announced that this needed to be a foundation. As Chris mentioned, it wasn't really started until December or so of 2015, but with the announcement of 1.0 came the intent that Google was going to donate all of the IP, all of the trademark, and all of the content around Kubernetes to a foundation, which then became the Cloud Native Compute Foundation. So this Cloud Native Compute Foundation was set as a governing body that had a bigger vision than just Kubernetes. We really wanted it to be, again, industry changing. So we set a three-model government. Yes, many of us are from the US. And for all of the joys and flaws of our government, the three models are actually pretty good. So we have a governing board, a technical oversight board, and an end user board offering checks and balances to one another. And so we began the CNCF. As I said, we didn't want this to be just the Kubernetes Foundation. We thought that that would be very narrow and very limiting. And that we really wanted to have this broader conversation. And I have to say, great thanks, Billinix Foundation, the Cloud Native Compute Foundation staff, Chris, Dan, everyone who's been working on this, and the technical oversight committee specifically for taking us from the one project, Kubernetes, inside the Cloud Native Compute Foundation, to the 14 that are there today, broadly addressing the whole stack that that landscape diagram showed us earlier, from network to tracing to instrumentation to the containers that exist under the container standards that exist under orchestration or around orchestration and under this portable workload unit and all of the other pieces around Kubernetes and more broadly, the container native narrative. But I'm really here to talk more specifically about Kubernetes, because taking Kubernetes from a company-led project to a community-led project has brought us a lot of interesting points to think about and work through. So this has been a two-year journey that I'm going to summarize in another 13 minutes. Forgive me if I gloss over some of the finer points. One of the things we learned was self-organization works really well in small groups. Kubernetes has enjoyed huge growth in the last two years. And what worked early on doesn't now. At this point, Kubernetes, as the size of the project, dwarfs all the other projects inside the Cloud Native Compute Foundation as a single project. But one of the tenets of the Cloud Native Compute Foundation is that each project is self-governing. And so what we are learning inside Kubernetes may or may not be adopted by other projects, but they will adopt it as they need it. So self-organization doesn't work very well for large groups. Early on, we used handraisers, people who volunteered to lead different special interest groups, to do a lot of the work that was needed in order to bring the project together. And those handraisers in small groups have a lot of trust. You have a small group, you know each other, even if you don't know this person exactly, someone else that you know knows that person in. So you have commutative trust in a small group in a way you just can't in a large group. So these handraisers generally had the skills that they needed. If they didn't, they were supported by people around them. But as the project grew, the handraising got more complicated, because there was status attached to different roles. There was status attached to being part of the Kubernetes project, and it became more politicized. So different cultural standards that we had, including chopping, wooden, carrying, water, making sure that everyone was working on the core and the important pieces, the boring pieces, I would argue, of the work that needs to be done. Those cultural norms got lost, and that made for some challenges in the last couple of years. It's one of those things that we saw and have seen happen in other projects, where the core doesn't get the attention that it needs, because the edges are more interesting to, say, a vendor community, or the edges are more interesting to a politicized community. So this chopping, wooden, carrying, water is a cultural value for Kubernetes, needs to be better communicated, and needs to continue to be rewarded. One of the other things that we found was implicit government generates mistrust. So it's really simple if you say, this is the deciding person. Linux is great. Linux has Linus, and whenever there might actually be a huge dispute, or a small dispute, but with people who can't come together and come to a solution, as the last resort, Linus can decide. That didn't work for Kubernetes. It sort of worked for a while. We didn't want it to be a benevolent dictatorship, but it was sort of a corporate dictatorship for a while. But then we said, no, we really want it not to be Google-led. We want this to be community-led. But then it sort of was like, well, who can really make decisions? And so it started to look like this weird, shadowy cabal, those seven of the four founders. Maybe one of them could make a decision, but if they disagreed, who would actually decide in the end? And we found that this really led to lots and lots of confusion for our end users, or our end contributors. I'm sorry. Someone would ask, how do we make this decision? The answer was, oh, I don't know. Maybe you should talk to Brian. Well, maybe Tim will have an opinion. Or you'd get 100 comments into a proposal on GitHub, and someone would go, oh, you know who should weigh in on this, just as you thought you were getting to a resolution. So this implicit governance really led to a lot of mistrust and led to a lot of churn and discomfort. So while we were working and we were moving the project forward, even at the crazy velocity that it was moving, there was a lot of wasted cycles in this discomfort. And so we have spent a lot of this last two years trying to solve this. Another thing we learned is people are messy. So I would argue that, let's see, what is the running joke? Three different hard problems in technology naming things, off by one errors, maybe it's only two. I'm going to postulate that the other one is people. Because most of your challenges in a tech organization don't ultimately come down to the tech. They come down to the people involved with them. So we've built this massive platform to enable distributed compute workloads. And so we tried very hard in order to build this and not fall victim to Conway's law to make a distributed decision-making system inside Kubernetes. We built out special interest groups. We built out autonomous working groups. We built out groups that then should have the permission and the accountability to make decisions on their own about their area of code and then work with other area owners and make decisions that are correct for the project at a technical level. The problem is people. Someone wanted a less, not someone, some several ones, wanted more direct authority. They wanted to know that they were supported in this, as opposed to organically growing these special interest groups who had leaders and should be making decisions independently. But there was some level of need for blessing from a broader project group. And so even when someone was a special interest group lead, there wasn't necessarily clear trust from some of the people who were in the special interest group that that person would have the right skills and comfort from the person who was leading about making the decision, be it driven collaboratively or not. So in the middle of all of this, we found lots and lots of opportunity to grow. And the project continued to grow in spite of all of our challenges. And we continued to put out good software. It just was uncomfortable during this adventure. So ultimately we decided we really needed project governance. Now we knew that we needed it all along, but we thought we were doing it relatively well. But there was lots of room for improvement. So we started a plan, trying to figure out how to bootstrap a governance process from a group that was incredibly distributed, had lots of opinions, and no clear, anointed leadership. So the broader community got together, had a long conversation, and came up with a bootstrap governance committee. There were seven of us who sat on that committee with a single explicit need. We need to figure out how to get to the first body that can help us make governance decisions, because we are not the right body all by ourselves. And this was a group that was roughly several of the founders and a few of the people who had joined to participate in the community later. So this group wrote a steering committee charter and built out a model for the first election and a transition model for the governance. So this bootstrap steering committee worked with the broader Kubernetes community to elect additional members and have a large group for the first two years, because we expect this to be a lot of work building out the rest of the governance for this project. So we will have 13 people on this group for the next two years, and then it will drop back to Kubernetes' favorite number of seven. So in this steering committee charter, one of the things that was explicitly called out was we are going to screw this up. We actually, in Kubernetes, spend a lot of time on retrospectives focusing on what we've done, what we've done right, what we've done wrong, and how we can learn from it. And that, I think, as a cultural underpinning is a huge and important point. Another thing that we spend a lot of time on and a lot of effort on is trying to bring together and grow that community, bring together and teach and share our experiences in order to make sure that we are growing the next generation of leadership. That is actually part of how this steering committee has been formed. The longstanding founders of the project, longstanding contributors as part of the Bootstrap Steering Committee, ended up, or the Bootstrap Governance Committee, ended up sitting and participating in the first two years of the steering committee in order to bring another six people together to think about things in a very similar way. So this transition of knowledge, this transition of culture is huge. We continue to see Kubernetes grow madly. I love this graph because it actually shows two things that I think are hysterical around this, one of which is yay, launch, big spike there. But also, that we as a group tend to take the end of the year off. So we continue to see huge growth and investment in Kubernetes. As Chris showed in the slides about the CNCF, there are more than 140 members now looking at this broader cloud native compute vision. Kubernetes is simply a piece of this. And we really, really hope that our vision of a learning organization, a growing organization, and an organization that allows for high trust at edges and intersections of both our independent group software, group areas of focus, as well as the edges of the Kubernetes ecosystem are a great way for us to continue to build a composable internet and also to change the model of cloud computing, so that it is more of a container orchestrated workload as opposed to focusing on VMs or other hardware-based systems. But this container orchestration allows us to work across multiple clouds, across hybrid clouds, and also to bring this workload system across all of our industries. So functionally, we see our future as very bright and that this Kubernetes governance, looking at the high trust, building a community that works well together and making sure that the governance that we have is right for our communities is super important. Thank you.