Google has pulled off a very difficult feat: It open sourced Kubernetes and then stepped out of the way of its success.
A year ago, Kubernetes began to pull away from the container orchestration pack. Today, the distance between it and its next-nearest competitor has grown. The reason for that growth was, and is, community. What is most surprising about Kubernetes, however, is how well it has done with community, despite being hatched within the bowels of a large, and largely secretive, company: Google.
The big get bigger
Kubernetes was shaped over 15 years inside Google. Though Google has long been an active user of, and contributor to, open source projects, Kubernetes was one of the first substantial examples of Google revealing the secret sauce behind its operations. Even so, standard operating procedure for the vast majority of corporate-sponsored open source projects is that they're announced to much fanfare (within their own PR team), attract little to no outside involvement, and wither away into ignominy.
Not so, Kubernetes.
The Kubernetes community is roughly five times as large as the next-nearest competitor, Apache Mesos, with more than 1,350 contributors to Kubernetes, collectively delivering over 47,000 commits. There are also over 1,500 job postings for Kubernetes-trained professionals, up from roughly 250 a year ago, indicating a groundswell of enterprise support for the project. Given that Kubernetes was born at Google, it's not surprising that the top three contributors to Kubernetes are all from Google (or, in the case of Brendan Burns, were at Google until mid-2016). But, just as surprising is how much of Kubernetes is being developed outside Google.
SEE: Why Kubernetes could be crowned king of container management (TechRepublic)
One way to look at this is by comparing Google's total contributions to that of other major enterprises. While it's true that Google still registers 31% of all code commits (as of the latest release), that number has consistently dropped with each release: 52%, 48%, 44%, 38%, and 31%, respectively.
Now look at the independent developer population growing up around Kubernetes. Developers not formally affiliated with a corporate sponsor ballooned their percentage of commits during this same period: 20%, 27%, 27%, 31%, and 37%. This independent category has not only diminished the relative percentage of Google's commits, but it has also cut into commits from the second largest corporate contributor, Red Hat (12%).
Not that either Google or Red Hat will complain. Community, after all, is critical to Google's strategy of releasing code that will lead more developers to run that code on its cloud, and community is also what makes open source projects valuable to Red Hat's business strategy.
So, what does Kubernetes do particularly well to attract such continued community growth?
Getting real about community
As I've noted before, not many companies can take their hands off the steering wheel when seeding an open source project. Google, to its credit, has; while Docker has struggled to rally a community to its overly corporate rival. Community also flocks to good code that solves significant problems. Check and check for Kubernetes.
As important as these are, the smaller details are what I find so appealing in Kubernetes' community outreach.
Heptio's Jorge Castro, for example, has called out how Kubernetes makes it easy to engage with other Kubernetes developers through face-to-face SIGs. Those SIGs are critical, Google's Chen Goldberg has insisted:
Everything in the Kubernetes community is operating around SIGs. They decide what features they want to work on. They discuss roadmap strategy. They triage issues towards the release. They make decisions. That's the most important thing. When a community is so big, we have to grow leadership and distribute it.
Coupled with this, the project's Github page walks newbies through the optimal way to start contributing. Such documentation is, according to the Kubernetes community lead Sarah Novotny, intended to accelerate the "mean time to dopamine," or positive experiences with Kubernetes involvement.
SEE: Why Kubernetes may be a bigger threat to Amazon than Google's cloud (TechRepublic)
As Novotny outlined, this also involves structuring the project in a distributed, non-hierarchical fashion. Kubernetes' leadership team has been "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," similar to MySQL and Linux. This allows a broad ecosystem to build around Kubernetes core without having to get broad buy-in for what may be particular needs at the periphery.
Great code is not enough to make open source thrive. Great community is even more important. By encouraging an ethos of openness, Google has set Kubernetes free from its control, while benefiting from its continued involvement. Few companies manage to pull this off, but Kubernetes is proof that it can be done, and done well.
- The cloud war moves to machine learning: Does Google have an edge? (TechRepublic)
- Google finally gives developers access to its cloudy secret sauce (TechRepublic)
- Why Kubernetes may be a bigger threat to Amazon than Google's cloud (TechRepublic)
- Why Kubernetes could be crowned king of container management (TechRepublic)
- Google wants to commercialize database Spanner, but MongoDB or Cassandra could be safer bets (TechRepublic)