 I'm Tim, I work at Google. Mostly I work on Kubernetes, sometimes on GKE and Anthos, but mostly Kubernetes. Anyone ever heard of Kubernetes? Anybody? Anyone? No? None? So Kubernetes, a little bit of history, I'm going to use the Kubernetes community as a jumping off point to the theme of community today. Kubernetes started development in 2013. We announced it at DockerCon 1. Anybody who was here at DockerCon 1? 2014? Yeah, I've won. All right. Actually, DockerCon 1 felt a lot like this today. A lot of techies, a lot of people who are really interested in tense learning, figuring out how to make this stuff work for them. So we announced it at DockerCon 1. Same day, there were six other orchestration systems announced. So we were on to something. A year later, we hit 1.0. That was our goal, GA in one year. Kubernetes is probably the largest Go project in the world. It's all written in Go. And it was a wonderful decision. I'm happy to talk about why, if anybody wants to be convinced on why to use Go. It is one of the most active open source projects in history. By some metrics, it is the, it is in the top couple of GitHub projects in terms of activity. Now we're multiple repos, so the stats are a little bit harder to aggregate. But it's a very busy project, I guess, is the point I'm trying to make. That, Kubernetes. I've been part of this project since before it started. I jumped in with the Google crew in 2013. I saw something really interesting, and I wanted to be part of it. So I've had a front row seat to everything that's happening around the Kubernetes community and the growth of this project. So at risk of spoiling the ending, Kubernetes would not, absolutely categorically, would not be the project that it is without the community. In fact, it might not have been a success at all. There was a lot of competition in the space, and by many regards, the way we won was by building the community around Kubernetes. Now, you may have heard me or other Kubernetes people talk about community before. I've done this at other conferences at KubeCon. It's one of my favorite things to talk about, because I'm really passionate about our community that is not going to stop me from doing it again. So here's a quick snapshot of our community. We threw this slide together. Actually, this is a couple of years old, but you can see in here some of our contributors, some of our conferences. I think up in the top left there is one of the early developer meetups. We have a wonderful community. These people are not just people that I share code with, but they are my friends. They are the people that I want to impress. They are the people that I respect madly, that I look up to. That is not something to be taken lightly. One of my favorite Henry Ford quotes, working together is success. You have to work together. You can't do it alone in this world today. In this digital world where everybody is a software company, it is too hard to go it alone. So one of the things that we talked about early on in the Kubernetes process was how are we going to manage this project? Are we going to open source it? Are we going to make it a Google thing? And we argued a lot about it. And we argued with our leadership about what we could do and how we could do it. And we agreed on this idea of radical openness. Not just throwing the code over the wall. Not even some half-hearted attempt at community building. We were talking about top-to-bottom openness. We all agreed that we had to be open to new ideas. We had to be open to people who came in with a different perspective and showed us why we were wrong. Even people that challenged our own experiences, we came to this with the Borg experience and we knew from the beginning Google is not a typical enterprise. We were going to get people who came in and said you are wrong about this or you need this abstraction. Boy, did we ever. We were always ready to throw away what we had done in service of something better. This was our ethos at the beginning of the project. So very, very, very early in the project. At DockerCon 1, Red Hat announced that they were also joining on with this project. And actually, if you listen to the Kubernetes podcast from Google, Clayton Coleman from Red Hat, the senior architect at Red Hat, who made that decision, talks about how he made that decision and how very last minute it was and how they were waffling over which open source projects to get behind because they had the same ideas. They saw the same need. And fortuitously, they picked Kubernetes to get behind. They coughed up engineers. They brought them to the table. And I'm not just talking engineers. I'm talking engineers, powerhouses. People who are to this day amaze me with their ability to ingest and synthesize information and see design. It's like looking at the matrix, some of these guys. And they brought their perspective. Red Hat is an enterprise software company. So they brought exactly what we were hoping for to this project. And they brought their energy and their perspective. And they did come in and they said, you're wrong about this. We need that. There are some serious parts of the Kubernetes project that are different and significantly so because of Red Hat's work. Some of our favorite features, like namespaces, everybody who uses Kubernetes is like, you have to know what namespaces are, right? That was a Red Hatism. I think I mentioned the word namespace. I meant something else entirely. They ran with the idea. Look what we got, right? This is like a happy accident. My Bob Ross. It was a happy little accident. It was beautiful. Miscommunication gone right. So the first few months of this project, we worked our butts off. We started accumulating contributors. Man, we would go anywhere and talk to anyone about this project. I did lunch and learns with four people at the table showing off what we could do with Kubernetes and what we had. A lot of it was a bunch of shell scripts glued together with a little bit of go code or some salt. Mostly the people who showed up to the project were people scratching their own itches. This is what open source is, right? I have a problem. You're doing something interesting. I bet I can bend it to what I need to do. But some of them were company sponsored and that's where it started to get really interesting. Like, why is your company investing two people in this project when you barely know what it is? Mostly these people just wanted to help. They were great. They showed up and, you know, and truthfully, many of them are still with the project. Not all of them, sadly, but many of them are still with the project five years later. One contributor showed up. I'm not going to name names today, but anybody who knows who this is will know. He showed up and he said very politely, your CLI is garbage. It's complete trash. I'm going to rewrite it for you. Anybody mind? We said have at it. Go nuts. And he came back and thus was born in a cube cuddle, right? We had a few inputs on the design, but he went off and he did a lot of this work on his own because he saw a problem and he wanted to fix it. And it was much better than what we had before, and we still have it to this day. Another contributor showed up, saw what we had done, and said, hey, why doesn't this thing support AWS? Well, I work at Google. I made it support Google. It supported Google really well. He showed up and said, well, I'm going to do AWS support. Does anybody mind? Have at it. And so he did. And he maintained AWS for years. And he gave forth to a project called cops, which anybody who's running Kubernetes on AWS probably knows cops. So I'm going to feel like a reiterate. These are people who didn't do it for money. They weren't all getting paid. Many of them spent their time and their passion on this project aside from work. Some of them were doing for work, but many just because they really wanted to. So quick snapshot, version 1.0, we had just short of 500 contributors. I think it was about 480. Some of those were drive-by contributions. Sure, that's what open source is. But in one year, we grew from 10 people to 500 people working on this project. Now, some were more active than others. Yeah, of course. But holy cow, even at a quarter of that, even at 120 people, it would have been a phenomenal success. But 500 just blew us away. But it didn't stop at 1.0. By 1.4, one year later, we were well over 1,000 contributors. So I had 1,000 people, random people from around the world, helping us with this little software project that we started. So I'm going to tell one of my favorite community stories. One day, we started to get a bunch of pull requests for ARM support. I'm like, what is it? Who's running Kubernetes on ARM? What a ridiculous thing to do, right? And so we pushed back, well, what are you doing? Why do you want this? Anybody knows what this is? Raspberry Pi, one of those little things that sort of changed the whole ecosystem. And if you weren't watching, you might not even have noticed. But man, this little computer for 35 bucks is phenomenal. This guy was making a cube cluster of Raspberry Pies. And we just thought that was the most ridiculous and awesome thing that anybody could do. So we merged his patches. Surprise two, he was 15. He was doing pull requests on the bus on the way to school. Okay? He brought a whole new perspective to this project. He wanted to do something with Raspberry Pies. For a school project, he thought Kubernetes was cool. He glued these things together. So we made him a maintainer. Now, I think he was 16 by the time we gave him merge access. But he's a maintainer. He has full approval access to an entire sub tree of the code base. We trust him, right? Radical openness. He showed up. He did something. He put in the time and he proved that he knows what he's doing. Welcome to the project. The point I really want to make here is that this community comes from places and from people that you would not expect. This was off the wall. He was in Finland when he came to the first cube con. He had to bring his dad because he was only 16. And his dad didn't want him traveling to the states on his own. Reasonable. Now, I focused a lot on software development. I'm a software engineer. But let me say this unequivocally because I heard a few people talk about this today. This is not the only way to become part of our community or any community. It is not the only contribution you can make. It might not even be the most important way, honestly. Clearly to get off the ground, a project like Kubernetes needs a lot of code to be written, right? So we slung a lot of code. But to stay afloat, we need a lot more than that. For example, docs. We have a community-driven group, a SIG, special interest group that runs our docs. Developer platform docs are so critical. And I hear a lot of people talk about how wonderful the GitLab docs are, and what a great culture to have set up there with the docs. Our docs were written by engineers. Have you ever read docs written by engineers? Yeah. Do you know how hard it is to write and organize and curate really good docs? It's really difficult. We have a group for testing. This is that underserved thing that everybody does. We know we need to do it, but some of us don't really take it that seriously. I don't want to say everyone because there's probably good people in the audience, but some of us don't always take it as seriously as we should. But we care about it. But good testing needs tools, and it needs infrastructure, and it needs dashboards and logging. And we have a whole group of people who just work on that stuff. Some of it is software, some of it is design, some of it is just you're doing it wrong. They are constantly keeping our feet to the fire, and they have approval authority, or they have the ability rather to stop changes going into the project. We say, look, if SIG testing doesn't trust us on a change, stop it. They are a group of awesome people, and their work is super valuable. Release engineering. Any release engineers in the audience? Yeah, this is a thankless job. We merge dozens or hundreds of PRs a day across dozens of repos. We cut a release every three months. Not exactly fitting with the DevOps ethos there, so we accumulate a lot of changes in between each release. We have a community-driven release team. They have self-assembled and built a process, not just a release tooling process, but a community process where they have shadow roles where people step up and they say, well, I'm going to shadow the release managers, and then they will be the next release managers. They build themselves a human pipeline of people who are not always software engineers, but they are there. They care about the project, and they are contributing their time and their passion and their energy. Let's just talk about infrastructure. This is a place where it's near and dear to my heart. Running a project this big requires a lot of scaffolding. We have a team that runs our GitHub org. There's a lot of work in administering a GitHub org when we have a community like this. We also have a team that runs our Slack. You'd think that might be easy, but it turns out, not so much. We have a team that runs all of our infrastructure, like serving our website or hosting DNS, and these things don't change often, but they do change, and they need people to be responsible for these things. And we have a volunteer army of people. We put out a call on Twitter recently saying we could use some help with the infrastructure. At the next meeting, the next Zoom meeting, we had 75 people show up. I have no idea what to do with 75 people. I thought three, four would show up. 75. In fact, we have a community-driven group that drives our community. We have our contributor experiencing, which is responsible for organizing the meetings and doing these events and making sure that the contributors are all happy and having a good time. Now, imagine Kubernetes without that community. None of this would work. None of it would work at all. I can't even fathom where we would be without having built a community like that. And the community is not just the community. It's the community. It's the community. It's the community. It's the community of the people. It's the stuff between the people, right? It's what brings us our power. It binds us. Sorry, I'm a Star Wars nerd. I had to work it in. This is what the community is about. Now, I'm talking about Kubernetes, but you can have this community, too, right? You have to pay attention to it. You have to pay attention to what's happening when it works. Thank you very much.