As the program manager of the Kubernetes community at Google, Sarah Novotny has years of experience in open source communities including MySQL and NGINX. Sarah sat down with me at CloudNativeCon in Berlin at the end of March to discuss both the Kubernetes community and open source communities more broadly.

Among the topics we covered in the podcast were the challenges inherent in shifting from a company-led project to a community-led one, principles that can lead to more successful communities, and how to structure decision-making.

Kubernetes started out as an internal Google project that can be traced back to Borg, Google’s internal container cluster-management system. Launched in 2014, Kubernetes has emerged as the leading technology to deploy and orchestrate containers. Furthermore, although Google and Red Hat are the leading company contributors to Kubernetes, over 25% of Kubernetes code contributions are listed as being from “independents.”

Google turned Kubernetes over to the Cloud Native Computing Foundation (CNCF), which sits under the Linux Foundation umbrella. As CNCF Executive Director Dan Kohn puts it: “One of the things they realized very early on is that a project with a neutral home is always going to achieve a higher level of collaboration. They really wanted to find a home for it where a number of different companies could participate.”

However, giving up control isn’t always easy even when people buy into doing what is best for a project. Defaulting to public may not be either natural or comfortable. “Early on, my first six, eight, or 12 weeks at Google, I think half my electrons in email were spent on: ‘Why is this discussion not happening on a public mailing list? Is there a reason that this is specific to GKE [Google Container Engine]? No, there’s not a reason,’” said Novotny.

“There were lots and lots of conversations that looked like that initially just to remind the Googlers that by default they should be discussing this publicly if they wanted the transparency, and the openness, and the engagement from the community that intellectually they did,” she said.

Kubernetes is just one project and, as Novotny also notes, every open source project and community has its own quirks that are specific to the goals of the community and its participants. She nonetheless identifies certain core patterns and principles. It starts “with a goal of being a successful project, so finding adoption, growing adoption, finding contributors, growing the best toolset that they need or a platform that they need and their end users need. That is fundamental,” she said.

But what is success? Novotny says that it means “we want to have the right people using our tools in the right way and having an improved experience from it.”

She cites MySQL as an example of a project that created useful abstractions for users and contributors. “MySQL did this in a really awesome way by defining clearly what core was, and then having and building in MySQL —it took a while—a clean storage interface,” said Novotny.

“That abstraction allowed an entire ecosystem to flourish around MySQL meeting particular user needs. This is work that is also happening inside Kubernetes at this point. Not exactly the same, but trying to clearly define what is core and make sure that we are establishing a clean, stable, and consistent core and core set of APIs,” she said.

Closely related is the creation of easy on-ramps for contributors, something that Novotny refers to as “mean time to dopamine.” And this experience is closely related to how decisions get made and how projects and the other projects they touch are organized and governed.

In the case of Kubernetes and cloud-native projects more broadly, the relationship between projects is best thought of as loosely coupled rather than formally architected. Novotny says this is in part because she speaks a lot about Conway’s Law and how it affects projects or the broader technology ecosystem. “Within Kubernetes, we have said, ‘We’re building a distributed management container orchestration system. We should have distributed control.’ We are going to end up with a hierarchical software system if we have hierarchical control,” she said.

“As a result, there’s a lot of work that needs to be done on common interfaces. I try to avoid the word ‘standards’ because there’s an immune reaction to that word in open source currently. Although to be fair, open standards are what got us the open internet. But, we do things code first now for a lot of reasons as opposed to standards first,” Novotny said.

Ultimately, it comes down to establishing shared goals. In that way “we can work against those shared goals, say, ‘Stability of core Kubernetes is a shared goal.’ This benefits absolutely everybody,” she said.

Listen to MP3 (20:54)

Listen to OGG (20:54)