Enterprise Adoption and the Kubernetes Community
VMware sponsored this post.
If you’re reading this, you most likely already know that Kubernetes has taken enterprise software by storm. Across the world, clouds, data centers, Raspberry Pis, and laptops are running Kubernetes, and developers are deploying and managing containerized workloads using its control plane.
Kubernetes is an open source project hosted by the Cloud Native Computing Foundation (CNCF), which in turn is part of the Linux Foundation. The engineers, designers, product managers, and documentation writers who have built Kubernetes have done so across the boundaries of organizations and countries. This community of people who work together do so without first-line managers or a traditional corporate structure to organize people and processes — so reinforcing positive and professional behavior, across organizations, across countries, and across cultures, becomes crucially important.
As enterprises move to depend on Kubernetes, they are also taking on a dependency on the health of the Kubernetes open source project, which in turn depends upon the community of people who are building it. Currently, the signals for the health of that community are strong. Companies across the globe have teams of engineers who once consumed open source software but never contributed back. That’s changing as increasingly more of them are now using, updating, patching, and adding features to upstream Kubernetes and related cloud native projects as part of their regular daily coding practice.
Creating an Open, Welcoming, Productive Space
When you take a step back and think about what you need for an open source community to be successful – clear standards, professional behavior, a way to problem solve and discuss architectural issues and prioritize features – having a defined way to make sure that all participants understand what acceptable behaviors are is a basic requirement of being able to expand a community. One way the Kubernetes project has laid the foundation to be an opening, welcome, and productive space is by adopting a code of conduct. Having an open source code of conduct that members can read, ratify, and learn from is the most democratic approach to clearly communicating expected behavior for project participants.
The Kubernetes community organizes itself into Special Interest Groups. These SIGs pursue their “special interests” as a group, and members of the public can start participating by joining a mailing list, collaborating on Slack channels in the Kubernetes Slack, and checking out their GitHub repos for meeting notes and code. SIGs also sponsor subprojects (long-lived and more narrowly focused) and working groups (which are time-bound and cross-functional).
The Contributor Experience SIG
One proof point of the community’s commitment to helping new people get engaged and contributing is that the Kubernetes project has created a Contributor Experience SIG, which has the mission to improve the quality of life for all Kubernetes contributors. This group is the place to go if you have a question, if you can’t figure out how to get a pull request merged, or if you have an idea for quality-of-life improvements. This group also organizes new contributor workshops at the 101 and 201 level. By educating potential new contributors, presenting code walkthroughs, and giving architecture overviews, these workshops help you learn how to get started with and join the community. SIG Documentation and SIG Usability also hold important supporting roles to this shared mission.
One improvement the Kubernetes community will tackle is via the newest SIG, Usability. This SIG (disclaimer: I am a co-chair) seeks to work to understand the users of Kubernetes, as opposed to the creators of Kubernetes. As an open source community of creators, there’s always a solid chance we are building for ourselves, the super users, rather than the end-users who are not building Kubernetes itself. SIG Usability is going to kick off several efforts around user research, jobs-to-be-done studies, and baking in better defaults, all in an effort to both understand and serve our end users better. (And if there are any user researchers, designers, or other interested parties reading this, please join us!)
Proactively Encouraging Diversity and Vibrancy
I would be remiss to mention the lack of diversity in enterprise software development, open source communities in general, and Kubernetes specifically. While some people cite debunked theories of diverse engineers being uninterested in participating in software development or open source, we have the data to know that isn’t true. What is true is that open source has historically been deeply unwelcoming to people who did not fit in the physical and intellectual molds cast by individual project creators. Lack of diversity can be seen as the canary in the coal mine — when an environment is toxic, people who stand out make easy initial targets, and are chased out. But the toxicity negatively impacts and hurts all members of the community.
With decades of bad behavior in our past, it’s going to take active and proactive steps to encourage the vibrant and safe and productive space that all bright and motivated people can create in. Today, most spaces only have reactive approaches — you have crossed this line, and there are consequences. We need to move to a proactive approach — this is who we are, and this is how we work together, and this is how we are continually improving quality of life for everyone. This is something the Kubernetes community is actively looking to do with efforts around contributor experience, usability, having shared and posted expectations of professional behavior via a code of conduct, and more. It’s also something we need to track, measure, and learn from our community, continually checking in to see how we are doing, and how we need to improve.
Collaboration in Action: The Cluster Lifecycle SIG
Another good proof point to a well-functioning community is cross-organization interest and collaboration in the Cluster API work coming out of the Cluster Lifecycle SIG. Cluster API seeks to solve the lifecycle management of Kubernetes clusters and to unify how clusters are created, upgraded, scaled in and out, and spun down. Engineers and architects from Google Cloud, Microsoft, New Relic, Red Hat, VMware, and more have come together to create a common toolchain to replace tools each company had already had to build internally for various efforts and projects. Making the Kubernetes community a space where these kinds of cross-collaboration efforts can happen, reducing rework and low-value-add proprietary work, gives enormous value to users of Kubernetes, who can now use upstream best-of-breed tooling that makes it safer and more reliable to use Kubernetes itself. In turn, these companies benefit because they all have products and services that run on the Kubernetes ecosystem, so the safer people feel adopting them, the more valuable those tools and services become.
At the end of the day, enterprises don’t want drama in their software dependency trees. They don’t want a group of people becoming disenfranchised and leaving, or being unable to make progress, or threatening to fork, because that detracts from the value of a common abstraction everyone can collaborate on and integrate with. They want a smooth, professional, non-partisan space where many people with different drives, goals, and backgrounds can be productive. The Kubernetes community has done some innovative organizational efforts in its drive to create this space. We’ve still got a lot of learning to do and improvements to make, but the space exists for that to happen as the community continues to evolve and grow.
CNCF and The Linux Foundation are sponsors of The New Stack.
Feature image via Pixabay.