Are you interested in getting involved with the Kubernetes community, but aren't sure where to start? This blog post aims to help remove the ambiguity associated with contributing to an open source project as big as Kubernetes while providing some anecdotal experience to give you an idea of what contributing to an open source project such as Kubernetes can look like as a beginner.
By detailing my experience as a contributor, I hope to inspire you to take that first step to begin your path as an open source contributor. You can contribute to Kubernetes regardless of your background or years of experience. Everyone's contributions are an important and valued part of the open source community. Below, I detail my experience as a contributor and outline key steps anyone can take to become involved.
Contributing to an open source project such as Kubernetes takes many forms: submitting code PRs, updating documentation, triaging issues, reporting bugs, improving tests, reviewing code, reviewing Kubernetes Enhancement Proposals (KEPs), and participating in Kubernetes release management. Kubernetes exists and thrives thanks to the countless hours spent by current contributors and future contributors like you.
I was first introduced to Kubernetes when I was asked to write a trade study on solutions a company I worked for could use to containerize our services and manage them with a container orchestrator. With the knowledge of what Kubernetes could do, at my next job I was able to start actually using Kubernetes when I noticed inconsistencies in the way some apps were maintained and operated, and suggested containerization as a solution. This allowed me to explore the Kubernetes repository, and while doing so I came across an issue that seemed like a good first contribution.
I had always been interested in contributing to open source projects, and felt that if I started contributing to Kubernetes I’d get more knowledgeable about distributed systems. Nothing gets you more experience with something than writing the code for it, which is how I became involved in Kubernetes and why it’s so valuable for others to do the same.
Here are some of the first steps to take to start contributing to Kubernetes.
Typically, when you are a new contributor to any open source project, you should look for any relevant documentation for contributors. Usually, this is in the form of a CONTRIBUTING.md file or something similar. The README at the root of a repo is also a good place to start. Any project looking to foster a community of contributors should have this information easily accessible to new contributors. Another thing to consider is the means of communication that the developers on that particular project or sub-project use. For example, Kubernetes relies heavily on Slack and mailing lists: subscribe to the slack channels and email lists that interest you most, especially for the areas of Kubernetes you plan on contributing to.
As a complete beginner to Kubernetes in general, as well as a person with no experience contributing to the Kubernetes codebase, I jumped right to the CONTRIBUTING.md file. It’s well documented and pointed me right to the necessary documentation to set up my environment to begin development.
Another way to contribute is through documentation updates, which is a common way for new contributors to get in an open source project other than contributing code changes. One interesting path that I’ve participated in recently is the Kubernetes release shadow program, a program in which those new to Kubernetes release management can take part in to work on one of many different sections of the release. I worked on the Kubernetes Enhancements for 1.20. The task I was given was to review and track all Kubernetes Enhancements Proposals (KEPs), with the help of a few other shadows and a lead. This gave me a lot of insight into the KEP process and allowed me to work with quite a few contributors in the process. I highly recommend this path to anyone looking to jumpstart their network and impact within the Kubernetes community.
Becoming a Kubernetes member is a consequence of contributing frequently and working closely with at least 2 different existing members with reviewing capabilities for a particular project within the Kubernetes repo. In other words, contribute a lot to 2 different areas within the Kubernetes project, and find a person you can work with closely from each. Over time, as you gain experience and have some PRs under your belt, ask these people if they could sponsor you to become a member.
A major benefit of becoming a member is being able to assign yourself issues and have more influence over certain areas of the code you’re working on. Another tangible benefit of being a member is receiving Kubernetes Common Vulnerabilities and Exposures (CVEs) as soon as they are recognized by the community. This was valuable to the DigitalOcean Kubernetes team as we receive information on these security vulnerabilities before the general public, allowing us to thwart undesired attempts at compromising our platform and ensuring our customers stay protected while using DOKS and other Kubernetes based products on the DigitalOcean platform.
The membership I possess also presents many opportunities, like being able to co-maintain the kubernetes-sigs/cluster-api-provider-digitalocean project and being able to sponsor a coworker of mine for Kubernetes membership. The value of Kubernetes membership has not only benefited me, but also my team, DigitalOcean, and the DigitalOcean community at large.
There are many obstacles that can prevent progress in contributing to Kubernetes or slow you down. The main hurdle is getting your first code contribution in. Due to the tremendous number of contributions on a daily basis and the limited number of reviewers, some PRs can sit for months or longer. The way to deal with this is to make sure you are contributing code that is actually needed. You can ensure this by tying it to an existing issue or creating an issue to get consensus from the owners of the code you want to contribute to that it is an actual issue, and keeping the approvers/reviewers of that area of code involved in what you plan to contribute.
Remember, drive-by commits may not get reviewed as quickly as you expect. Maintainers of a project can only do so much and hold so much context. It’s your job as a contributor to make your PR as reviewable as possible. Provide well-written, thoughtful descriptions for your PRs. If it’s a huge change, make sure there’s agreement on the change and break it out into multiple PRs as needed. Respectfully ping the maintainers in the appropriate slack channel if time has lapsed since you’ve made the PR and respond to comments on your PR in a timely fashion.
Another obstacle I see in new contributors is ego. A lot of the time, an issue that is new to you isn’t new to others, so it is important to hear them out and proceed in civil discourse. Don’t go into any situation thinking you have all of the necessary information to proceed with a PR, and listen to others' input and take it into consideration when providing/updating your solution for whatever issue you’re working on. If people ask for updates and you don’t agree with them, ask for clarification on the suggestions until you both are satisfied with the outcome. The beauty of open source is the ability to collaborate with others and make iterations on a product to lead to a net positive for the project being worked on. Remember we’re all on the same team, and don’t take things personally!
After reading this blog post, you should walk away knowing how to start contributing to Kubernetes, how it benefits you and your career, how to become a Kubernetes member, and how to overcome obstacles you may encounter. In a world where cloud is increasingly popular, companies like DigitalOcean are always in need of people in tune with the cloud native community. Kubernetes is a very accessible way of getting to be a part of this amazing ecosystem built on love, respect, and collaboration with one another!