A quick look at the Kubernetes commit log suggests that interest in contributing to the open source container engine may be fading. That quick, superficial look, however, would be incorrect. Wildly so.
What that decline in commits to the core Kubernetes engine actually shows is that Google and the growing Kubernetes community are doing nearly everything right to ensure its long-term success.
SEE: IT leader’s guide to making DevOps work (Tech Pro Research)
Core no more
In the olden days, platforms acquired power by adding functionality to the core. Many a startup found its fortunes destroyed, for example, by Microsoft making that functionality into a feature of Windows. That was then, this is now.
Kubernetes, already impressive in its own right, is particularly so in how it has managed new functionality. That commit log is tapering off partly because, as Ant Stanley has noted, it’s “a sign of the project maturing and stabilising, not a drop off in interest.” “For many infrastructure projects,” Christopher Schmidt adds, “this would be an extremely healthy graph.”
He’s right, but that graph is “healthy” for another reason, too. That reason is how the Kubernetes clan thinks about the core platform.
SEE: How to build a successful career as a DevOps engineer (free PDF) (TechRepublic)
As Kubernetes developer Jaice Singer DuMars has highlighted, “With things like the cloud provider extraction, we’re trying to get things out of core, not in.” What?? Cloud Native Computing Foundation executive Chris Aniszczyk concurred, adding that “a lot of the exciting stuff is happening outside of the Kubernetes core repo. Things like CSI have been explicitly been developed outside the core repo.” Kubernetes, in short, doesn’t have to have all the good things (like Istio and Helm, for example) as functionality tightly bolted into the core. It’s a platform. The point is to allow other things to grow around it, as Jesse Ezell called out.
This means, in other words (DuMars’, in this case), “Kubernetes has become the epicenter of a thriving ecosystem, but the cloud native journey has many other exciting waypoints.”
Now if only all platform teams thought this way.
A better way
Let’s be clear: This decentralized approach to platform-building is not typical. Most companies (and open source projects–OpenStack, anyone?) can’t help themselves–it just seems easier and more efficient to increase the gravitational pull of the core, sucking in surrounding satellites. This, however, is a really bad way to foster community.
Kubernetes, by contrast, seems to be doing everything right when it comes to community. This is a big reason the project displaced earlier entrants to the container orchestration market like Mesosphere and Docker. It’s why everyone is hitching their container fortunes to Kubernetes, from cloud giants like AWS and Google to data infrastructure vendors like VMware and Oracle.
Which is why we should applaud Google, the original creator of Kubernetes. Google does many things well, but getting the Kubernetes community recipe so right for so long is incredible.
It’s also why we should remind, AWS, which has become increasingly active in open source, to take a page from Google’s book and learn how to both launch and foster open source projects. It has a great opportunity to do just that with Firecracker, a lightweight virtualization technology for running multi-tenant container workloads. The open sourcing of Firecracker came from Amazon’s Lambda and Fargate teams, AWS’ Matt Wilson pointed out, a sign that open source is starting to run deeper in Amazon’s DNA.
This is good, especially as AWS strives to meet criticism that it takes much but gives little to open source. Google’s initial and ongoing involvement with Kubernetes, and how it set up the Kubernetes core to facilitate but not control follow-on innovation, is a great example to follow.