 Well, we heard from the creator of Linux this morning, and there are obviously more open source projects. Linux isn't the only one. How many people have here have heard of an up-and-comer project called Kubernetes? Anyone? So Kubernetes has actually, you know, been described to me as sort of the new Linux of the cloud, that Kubernetes is one of these projects that is just growing in terms of developer momentum. I think if you take, you know, sort of the number of developers times pull requests, this is an insanely fast growing project. I'd be curious to hear how the project is dealing with the amazing development pace, and maybe there was some things that Lena said that were inspirational. But Brian Grant is here. He's the primary architect of Kubernetes, along with Aparna Singha from Google, who is the lead product management, the leader of the project management team for Kubernetes at Google. To talk about this incredible new project, please welcome Brian and Aparna. Come on up. Welcome. Now is it working? Alright, maybe the antenna got buried. So yeah, we're going to talk to you about this relatively new open source project called Kubernetes. I will explain how and why we built the Kubernetes community, which is really what sets it apart from other similar open source projects, as well as from other open source projects at Google. Yeah, so application containers are an increasingly popular way to accelerate application development and employment. But containers alone often aren't sufficient to manage containers in production and scale. We need a container orchestration system like Kubernetes. I like to think of it as container-centric infrastructure for deploying and managing applications. Kubernetes was created by Google, drawing upon experience with Borg, the system that runs search and Gmail, but designed to run anywhere. I did a software engineer at Google for about 10 years. I previously worked on Borg, and I've been involved with Kubernetes from its inception. We open sourced Kubernetes in 2014 and created the Cloud Native Computing Foundation to host Kubernetes and also to foster an ecosystem of cloud-native infrastructure. As you can see from this graph of commits over time, Kubernetes has grown very fast. We've sustained linear growth in the main Kubernetes repository, which is what this graph shows, now with more than 43,000 commits. But changes to the original repository now account for less than half of all the changes to the project across all our repositories. It's been estimated that over 400 years of work have been put into Kubernetes over just the last three years. That growth has been fueled by growth in our contributor base from less than a dozen people to 150 active monthly contributors. Now we have more than 1,500 unique all-time contributors. We have contributors from most time zones of the world, including from countries like Brazil, India, China, Germany, many, many others. In fact, anywhere you go, you're likely to find an active contributor community for Kubernetes in your time zone. Okay, maybe I'll stay at the podium. The podium might seem short. So where has this growth come from? Well, Google has been dramatically increasing its investment in Kubernetes, and the rest of the community has grown even faster. In the first six months, Google was responsible for most of the commits to the project, but now we're responsible for less than half. And we actually worked really hard to achieve that and to grow and broaden the community. Google engineers spend a significant amount of their time helping others in the community become successful on the project. Why do we spend this effort? Well, we actually found that engagement with the community yields numerous benefits. Engagement with users provides rapid feedback that drives improvements to Kubernetes. And we also help those users become successful with using Kubernetes. And that creates advocates for the project who blog and tweet about it, and they talk at meetups and grow awareness, which attracts more users. In turn, more users and more use cases attract developers who build tools and create other projects that make Kubernetes easier to use, such as package managers and chatbots, platform as a service and functions as a service. And we see an empowerment to improve the project, increases their commitment to it. Users and developers in turn attract vendors. And the vendors try to fill those remaining gaps in the ecosystem. We help those vendors integrate with Kubernetes, and that enables Kubernetes in more environments, which again facilitates more usage. This virtuous cycle has made Kubernetes one of the most popular projects on GitHub with more than 20,000 stars. So we like to say that Kubernetes isn't just open source, it's an open community. The open community encourages direct contribution and also sharing of best practices, examples, tools and more. We find that not just vendors and developers are contributing to Kubernetes, but our users are as well. For example, a co-founder of Box actually wrote the initial version of our command line tool, and they're using Kubernetes internally on their own infrastructure. Many people may contribute for personal recognition or corporate recognition, or they may just do it because it's cheaper than building their own solution. Or they may do it for the greater good because making Kubernetes better actually benefits everyone, not just Google. The community is actually cited by our users as one of the major reasons why they adopt Kubernetes and choose it over alternatives. Some say that they prefer to be part of a community where others are giving back to the community as well. That's not to say that it's been without its costs and challenges. Patrick gave a great talk about the true cost of open source yesterday. Hopefully many of you caught that. The slides are also online. And he pointed out many of these issues as well. I don't actually have solutions to these challenges. So I'm interested in hearing from other open source projects about how they deal with these. First, engaging with the community can be extremely time consuming. We help new contributors ramp up. We review their proposals and their changes. We answer all kinds of questions and do a lot more. Just responding to Slack is more than a full-time job for one person. And more than that, it's not just a nine-to-five job. A lot of people contribute to Kubernetes not for their day job but for fun. So they work in the evenings. They work on weekends. As I mentioned before, they're all over the world. We found that GitHub, while really good for building a community, doesn't scale very well to large projects. It doesn't really have good mechanisms for managing large repositories. It doesn't have tools for managing many repositories. We found that decision-making within the open community, among participants with diverse set of opinions, can lead to better decisions that work for more people in more environments. But that also can slow down progress on the project. And finally, because effort is not allocated centrally as it would be if the project were just totally controlled by a single company, we found that it's really, really important to have effective incentives for people to actually work to maintain the health of the project. And that's very critical but also very challenging. So now I'm going to hand off to Perna. Is my mic working? Yes. Okay, great. Thank you. So what makes the project work? As Brian mentioned, there are many things that we haven't figured out. But there are a few things that have been working. In particular, he showed that our contributor velocity and the velocity of commits has been growing steadily over time since the inception. We found that the most important principle that has worked for us is the principle of inclusion. By inclusion, we mean that we are a welcoming community and we welcome all perspectives and have respect for everyone in the community. This has been encapsulated in our code of conduct and it's something that as we grow, we find to be even more important. It is a challenge at times because you've got so many different opinions and we do have the pressure of release deadlines. But that's where it becomes even more important. Another aspect of inclusion is cross-organizational teams. And we call these SIGs or special interest groups. These are collaborations between different companies and individual contributors that self-form to work on a specific topic of interest. These are two examples of SIGs. SIG cluster life cycle is focused on making the installation and life cycle experience, upgrade and life cycle experience of Kubernetes easier. As you can imagine, as Kubernetes has grown, it is being installed on bare metal servers. It's being installed in all different types of clouds. And there's a lot of sprawl due to that. Users started complaining to us last year about the project becoming more and more complex to install. SIG cluster life cycle kicked into high gear and within one release, they came up with QBADM, which is a two-command installation for Kubernetes clusters. And they have now built out a roadmap that quarter over quarter is resonating with users to make that process simpler. Another example is SIG service catalog. This is also a collaboration of multiple companies. And they have really shown what can be done quickly to benefit the whole when you get disparate companies and disparate perspectives together. This SIG works on creating a standard for Kubernetes applications to consume other services. And within a quarter, they have come up with a Kubernetes native implementation for the Open Service Broker API. I think there was a talk on that yesterday from someone from Cloud Foundry. In fact, one of the members of the SIG is from Cloud Foundry and was brand new to Kubernetes community. And the SIG helped them ramp up and become effective within one release. So these are just two examples. There are over 25 SIGs and they are constantly evolving. New SIGs are being added. SIGs are being collapsed into each other. And they evolve with the needs of our users and the interests of the community members. As you can imagine, this is a great mechanism for distributed leadership. And that's the purpose of the SIGs. The decision-making body within the Kubernetes community is the SIGs. But it also has its challenges. With so many different SIGs, how do we ensure coordination between the SIGs and communication between the SIGs? We have had cases where a feature was introduced and there were dependencies on a different SIG that didn't get recognized and weren't caught in a release. And then we had to do a patch release right afterwards. So that brings us to our second biggest principle, which is something that we are working very actively on, which is transparency. By transparency, we mean that everything has to be done in the open, everything. All of our communication is on open email lists. It is through open chat channels. And Sarah is smiling at me because she is constantly pushing us to be more and more transparent. And it's not a natural thing. It's something that we have to work hard to achieve. So transparency is something that we have tried to have in all of our communication. But most importantly, in our technical work, we do that all on GitHub in open issues. All the design proposals from the start, all the way through coding and code reviews, are done in GitHub, in the open. There's no do it inside and then open source it. We don't do that. And that leads to a lot of discussions. And that has its own challenges. But one of the things that the Kubernetes community is very good at is discussions. And in fact, it is rated as number one by the count of comments per issue. It's the most communicative community. One joke that I wanted to tell was that if you look at Brian Grant's laptop, it has no privacy screen. Because everything he does is done out in the public. This has been a harder thing for me to do. I've come from the Android side of Google. And that was a community that was much less communicative and less transparent. So the transparency creates a huge flow of information that is sometimes hard to consume. This is where some of our other mechanisms come in. Number one is our community meetings. They happen every week and are led by Sarah Novotny, who is here in the audience. She tries to bring sanity. She welcomes everyone to these meetings. And then there is a demo. Every week there is a demo of something that someone has created that's brand new. And this is always very exciting because it's cutting edge innovation that's happening. But it's also an opportunity for people to give feedback and to get recognized for their work. After that, each of the SIGs reports what they're working on for the release. And that's how we've been striving to get those dependencies recognized so that the SIGs can then go off and resolve them and we don't have an issue after the release. Also focused on the release, we have burn down meetings. This is where the community gets together and decides whether a release is ready to be cut. And Linus mentioned that having a regular cadence has been very relaxing. And just in 2016, we've also established a regular cadence. There's a Kubernetes release every two and a half to three months. And that has been, in fact, quite relaxing. But we will hold a release if there's a quality issue. And that's some of the things that the burn down meetings track. Lastly, we found that these mechanisms weren't enough. And so we've been experimenting with a more open roadmap process. And that's something that I helped to lead. So the heart of the roadmap process is actually a new repository called the Features Repository. This serves as our unified backlog. And it is a publicly open backlog. So anyone, you can go there and see what we're working on and what we're about to release in the next release and potentially the release after that. Features are entered into this repo and they must be entered within the first two weeks of each release cycle. After that, the repo is frozen. And each of the issues has to go to their respective SIGs to get approval and reviewed in terms of design. And then after that, they are labeled in terms of whether they're going to be beta or stable or whatever the designation is. And this provides a bit more predictability and visibility to the community and the outside world. It feeds directly into our release process for release notes and documentation. This has actually been a big challenge with a project of this size making sure that the documentation actually captures what has been done in a way that is consumable to users. And having a centralized Features Repo has allowed us to start making sure that the documentation is complete and timely. And that's been one of the gating factors for the release. And also that drives the PR and the blog posts and so forth. The community wanted more than just a release-specific planning process so we also meet on a semi-annual basis in an unconference with the SIGs and that's a time for us to do more top-down planning to talk about the overall problems and priorities of the project. For, as an example, in 2016 we met to decide the priorities for 2017 and the top three things then came up. Number one was scaling the project. How do we make sure that it is stable and scalable? So we agreed to experiment with every other release being a stable release, a stability release, where we move Features from alpha to beta to stable. The number two priority that was introduced was around API Federation. API Federation allows our users to build new objects and customize Kubernetes in ways that are useful to them. The third priority is actually related to API Federation which is conformance definition and conformance testing. So we're going to work on that very actively in 2017 to ensure that when a user has a release of Kubernetes it's compatible with any other distribution of Kubernetes that they might encounter. So all of the above, you know, transparency, SIGs and inclusion would not work if it were not for ownership. Ownership in Kubernetes has two meanings. One is that we encourage anyone and everyone in the community to take on a role and own the responsibilities of that role. The second part, though, is equally important and it's sometimes harder, which is the respect for the role that the individual has. Everyone else in the community has to respect and defer to the person that has the role. This can sometimes be challenging. We have a lot of very experienced senior engineers and senior people in the community, but ownership means and respectful ownership means that we defer to whoever takes that responsibility and this ultimately allows new people to grow and new talent to grow in the community and gain experience. So these are some of the roles, contributors, SIG leader. There are also non-engineering roles like project management and UX and document writing and marketing. Along with the responsibility, there are rewards. There are many rewards from the community. People who do their roles, the community thanks in the form of handmade awards, but also in the form of blog mentions and PR mentions. And finally, this is something that people put on their resume and it is a career builder as they progress in the community. So of course, we haven't learned everything. There are many problems that we haven't solved, but we think that if we continue to experiment and learn together, we will hopefully be able to solve the future challenges that our growth will bring. One of the checks and balances is the concept of a retrospective. We do a retrospective after every release, openly with everyone in the community to understand what we did well and what we could do better. We also do ad hoc postmortems when things go wrong. So one of the things that's very common in Kubernetes is to get feedback and ideas for improvement from people that you may never have met that give you this kind of direct feedback in a Slack channel or in a video chat and to take that very seriously. In fact, some of my best ideas for growth have come from people in this kind of community that you would normally consider external. In Kubernetes, the notion of what is external and what is internal changes. And you get the benefit of having a global family that is passionate about the change that we are bringing. As you can see here, Kubernetes is a passion for many people. They share it with each other and they share it with their families and their kids. For me in particular, I missed the chance or didn't have the chance to work on Google search infrastructure. And I think that working on Kubernetes is perhaps an even bigger opportunity to impact the way the rest of the world is going to use distributed computing. We hope that you'll join us. Thank you.