 Thanks a lot. So I'm here to talk about the Kubernetes community. So as we all know, Kubernetes is a very important project to Google and to a lot of other folks in the open source community. So today, I want to talk a little bit about the Kubernetes project as a community project and how the community project is run and why that's successful and how that contributes back to the success of Kubernetes itself as a technology. So Kubernetes, as we all know, is a container orchestration system. It's essentially what we'd like to call container-centric infrastructure. So not just deploying any type of application, this is focused directly on containers and is container-native from the very beginning. It's inspired by Google's own experience, deploying systems using container technology. Google has been deploying containers at Google for about 10 years. So all applications at Google are deployed using containers, everything from search to Gmail, et cetera. So Kubernetes is also a really good project in the sense that we've had experience building things like that for the last 10 years, and we want to bring that out into the open source community. It runs pretty much anywhere, so it can run in cloud environments as well as on-premise and your own data centers. It was open sourced in 2014. And instead of keeping this project just to Google, we created the CNCF, which is the Cloud Native Computing Foundation in order to host Kubernetes and to promote Kubernetes as a project in the open source community. The velocity of Kubernetes is pretty astounding. So what we have here is a graph showing the number of commits to the project and the releases. This is a little bit of a dated graph. We have a huge velocity over the last three years. But right now, after we've released 1.6, we're at well over 50,000 commits. So we're continuing on this trajectory, and we're continuing to get more and more product to commits and contributors. The community growth is quite large, so we can see that the number of active contributors to Kubernetes, this is a weekly graph. So week over week, I think that dip there is Christmas. But we can see that even some people are committed to Kubernetes well enough that they're committing over their Christmas holiday. But we have well over 1,500 contributors to the Kubernetes project itself. And that spans over 15 time zones. So that means that pretty much any time zone that you happen to go to would have a Kubernetes contributor in it. Also very important to the project is the composition of the community. If this was a 100% or a very largely Google-driven project, then we don't think that it would succeed as an open source project. It's very important that we have other developers contributing to the project and even contributing more than Google does. So we can see here that before 1.0, that Google was about 3 fourths of all of the commits to Kubernetes. But between 1.0 to 1.5, we actually have more commits via other people in the community. So we can say on aggregate even over 1.0 to 1.5, Google is not the highest contributor. So we can say this actually even goes further nowadays, which where Google is actually not the top contributor, it's actually individual contributors. So essentially the long tail of individual developers that are contributing to Kubernetes is actually the largest group of contributors rather than any one single company. So what drives this kind of success? This is something that has been a core part of the Kubernetes project from the very beginning, that we do everything in the open. So everything in the Kubernetes project is done in the open, all the development is done in the open, all the design work, all of the decisions for which new features to include is all done in the open. This is something that we felt was very important for the success of the project. So we see this as a kind of a very large community that we need to grow and to do that, we need to be very engaged. So we encourage users to develop communities of their own in local areas by creating meetup groups and sharing information with local developers and to as well as helping not just users but developers that want to build things on Kubernetes. There are now over 4,000 projects based on Kubernetes. So things that use the Kubernetes API to build on top of Kubernetes. These open source and projects include things like OpenShift and these other type of path solutions, as well as many other different types of projects. All of the pieces of Kubernetes are also open source. So things like the UI dashboards and things like that are all open source projects based on Kubernetes. And then where the users and the developers in the wider community are not able to fill a particular need, we work with vendors and other companies in order to essentially plug the holes in where Kubernetes is weak. So things like providing support and starting new clusters easily, things like that, can be developed by vendors. So these are the types of this type of ecosystem of just not just end users but developers as well as vendors creates this virtual cycle that allows us to develop, to grow the community and create a much more robust and good project. And this project, this community, is made up of all of these companies that you see here and more. So companies like not just Google, but Fujitsu, Huawei, Red Hat, CoreOS, many of these companies are contributing to Kubernetes and working in the community, building projects around Kubernetes, building products around Kubernetes, building support systems and support solutions on top of Kubernetes, and essentially building a much more robust and stable community. But building an open source community comes with a lot of challenges. And there's a lot of costs to companies like Google contributing to open source and putting their weight behind a particular project. So many of the things that you can imagine are on here, but some are a little less obvious. So things like the fact that it's time consuming. It's very time consuming for developers in the project of at Google to spend time supporting and nurturing and building the community around Kubernetes rather than just committing code. We think that it's important to grow the community as well as building code, so we actually think that it's worth it to spend this time cultivating the community. It's also 24-7, so that means that even though many of the developers are based in the US, we still have things going on around the world. So we need to have a more robust community in order to allow that to continue on a 24-7 basis and have local community resources within individual time zones. So another thing is that tools are very difficult to deal with when you get to a large project. And these can be a fairly large drag on the velocity, all of the things that I've talked about above. Also, when you start to build a project like this, many of the other companies and the members of the community can feel that they don't really have to contribute and don't get anything out and basically get all of the benefits out of it. This is essentially the tragedy of the commons, but building a very nurturing community and a community where it's easy to get started and to contribute kind of helps with this and allows more people to contribute. So how do you address all these problems and how do you make a community like this work? So one of the most important things is inclusion. So inclusion means including as many different types of people into the project as possible. We do this by creating a safe place or a safe community where people can do things and build communities in a more constructive way. So this means that we have things like a code of conduct and we make it clear that people should not be engaging in things like harassing behavior as part of the project and that makes it much easier for new people to join the project. We also have cross-organizational teams. So the Kubernetes project includes many, many people who are working at companies and contributing to Kubernetes as well as individual contributors. And so we need to have a way of communicating with all of these different stakeholders in different parts of... They're working on different parts of Kubernetes. And so we have these cross-organizational teams and those are essentially called special-interest groups that can be then... Can focus on a particular area of Kubernetes. So that means that that makes it easier to scale up Kubernetes where developers can focus on the area of where they have the most expertise and the most knowledge and not get bogged down in the overall churn of the project. Next is transparency. So transparency is also a very huge part of developing an open-source project. We elected to do everything in the open, including deciding which features to build and which... And doing the discussion of all the design of those features out in the open. And this, we think, takes a little bit more time to actually break that down and come in to get a design worked for a new feature. But by doing it transparently in the open, we end up getting better solutions. We come up with better... We get better ideas included, even though it takes a little bit more time to get things decided. Also, ownership goes along with these cross-organizational teams. So the teams each own different parts of Kubernetes. And learning together is also one of the most important parts of making things... Doing things out in the open. Many open-source projects that are backed by companies are done in a way that they do the new feature development or deciding which features to build in a closed way and then just releasing the code. We don't think that this is the right way of doing things. We think that people will learn much better and get much more out of the project by learning together, collaborating together, talking about the ideas in the open. And developing the project and allowing it to move in a direction that best fits the community's needs. So I mentioned special interest groups. This is an example of what those look like. So special interest groups include many different companies or folks from many different companies and as well as independent developers. Many of them meet weekly and have over the Internet VC meetings to talk about the new features and hash out what's going on recently and things like that. And so two of these examples, one is cluster lifecycle. That's essentially talking about how to make Kubernetes easier to install and focus on how to get a cluster up and running. And then the service catalog, which is another special interest group that is focused on developing the service broker. There was many other special interest groups. So not just cluster lifecycle and service catalog, we have apps, which is focused on deploying applications to Kubernetes. We have things like on-prem, which is focused on on-premise workloads. We have things like windows running containers on windows as well as contributor experience. So even things that are not technologically oriented, but more how to make it easier for Kubernetes developers to contribute to the project are also things like, are also created as special interest groups which focus on that area and make the project a better, make it a better project for new contributors. So this is a really key part to how to make the project scale to a larger size and as well as keep it successful. So next I wanna talk a little bit about transparency. So the main thing that most people think about when they think about transparency is the actual GitHub issues and proposals as well as the commits for the code. But it's not really just about that. It's a whole range of things. We found that just creating an open-source project and sending out the codes and keeping the issues open is not sufficient to having a good transparent project. So we added things like these SIG meetings, so these community meetings, burned-down meetings for projects to kind of assess how well the project went, things like developing a new roadmap process. So we used, we started building a way to discuss which features that we wanted to add to the project in the future, not just creating GitHub issues, but creating, we created a whole new, separate repository with feature issues that people can talk about and comment on and then the next release, when the next release comes around, we can figure out exactly which features we want to have in the next release so that we know where the developers can focus their attention. So doing all of these things in the open is important to the project so that everybody knows how things are decided, knows what things are going on, knows how to contribute, where things are being decided, things like that. So I talked a little bit about the roadmap. So we have a semi-annual kind of on-conference with SIG groups to kind of figure out things like the themes and priorities and have a kind of a top-down plan. And this gets kind of done at the start of each release. So we have the features repo as I mentioned and at the start of each release that gets populated with the features that folks want to include in the release. And then that's basically frozen about two weeks before, two weeks into the development of that release so that each issue is required to get SIG approval so for the launch label to add it to the launch. So this serves as a kind of like public place to look and see the new features that are being added to Kubernetes and see the design and how it's working. It's being fleshed out. So it has also helped to add improvement to documentation and blog coverage which is like really important to but challenging and open source. We know when we create a new project or we create a new release, we know exactly which features need attention in the documentation and how to best explain those to the developers. So lastly, we have ownership. So ownership is essentially how to progress in the project. So you start as a contributor. So contributors are actually programmers and then we have product managers which work at individual companies and try to influence what sort of features are added to Kubernetes and help to integrate with the individual companies as well as SIG leaders and release managers. And each of these kind of own like different parts of the project, right? So SIG leaders kind of help coordinate a SIG and the release managers actually do releases and contributors actually write the code. So each of these can kind of work on their specific area and don't have to worry about all of the other things going on. And individual contributors can also like kind of rank up in their involvement with the project and grow in responsibility. So just being a developer that adds code to the project as a member, you can then become a reviewer to review other patches to the project. Eventually you can become an approver, somebody who can approve PRs to the project and then finally an owner of a particular area of the project. So finally like when I talked about like that we learned together, one of these things like we talked about burn down meetings and we talked about other different types of meetings that we can have like we definitely don't know like everything about how to work in a project but we know that these types of doing these meetings very often and kind of evaluating how things have run in the past and how things are doing, how we can improve things in the future has really helped us to evolve the project. So here's some user feedback on the project. So not just from end user and developers but also like companies that feel that not just the technology but the fact that the open source project itself is so successful, LEN gives them confidence in how to move to that in the future. So we've seen that like from user feedback that import open source is very important over half are very important or critical and that these types of projects, the fact that they have a good community that's easy to get involved in and is able to be scaled properly is very important to the actual success of the project and whether users and companies adopt it. So here's some kind of sample talks from Kubon, sorry and that you can kind of check out but I just wanna like close by saying that it's very easy to join the Kubernetes project. Just go to GitHub slash Kubernetes and check it out as well as join the Slack channel. So from the Kubernetes website, there's a Slack link and you can check that out in order to get more involved with the special inquiries groups and the wider community. Thank you very much.