In this post, I’ll outline some first steps to start contributing to an open source project and describe how I made my first contribution to the Jenkins X project.
Contributing to open source is a fantastic way to learn, meet new people and join a community.
However, contributing to an open source project might seem daunting. It need not be! When approaching a new open source project, simply focus on the first step. Generally, this means reading over the project’s documentation, including exploring its website. You don’t have to spend a lot of time doing this, but it will be valuable for you. You’re likely to learn more about the technology, the project’s development goals and the project’s own contributing guidelines.
As you read over a project’s documentation, it’s almost certain you’ll find errors: a broken link, grammatical errors, or outdated, incomplete information. Welcome to open source! It’s important to remember maintainers and core contributors of most open source projects are extremely busy, and sometimes do open source work in their spare time. The number of core contributors is often shockingly small, even for very large open source projects. Also, good documentation is hard and needs to be continually updated and, like most writing, benefits greatly from fresh eyes.
If you fix errors as you find them while reading through a project’s documentation, the time cost to you is minimal and your contributions are likely to be merged in. You’ll make your first pull request (PR) to a project quite quickly and soon become a contributor. These contributions to a project might seem minor, but they are valuable. Small positive changes add up. Good documentation is vital to a project’s success. Every positive change you make improves the experience of every individual who approaches the project after you.
With open source, as with most of life, I like to keep in mind this dictum by Ralph Waldo Emerson:
To leave the world a bit better … is to have succeeded.
My first contribution to Jenkins X
I approached the Jenkins X project with the above mindset and soon found something to fix. My first contribution to the Jenkins X project was merged within 24 hours: Success!
This was quite fortuitous as contributing to the project wasn’t my focus when I started reading the documentation. As a web developer interested in best practices for building and running applications with a microservices architecture, I heard about Jenkins X, how it was built from the ground up to be a CI/CD platform for Kubernetes, and wanted to find out more about the project.
While perusing the Jenkins X website, I noticed the main text on the page had a tendency to overlap with a navigation table on the right-hand side of the page. I played around with different browser widths, on pages with different layouts, and the site responded beautifully, changing its layout to best display the site’s content given the width of the browser. The progressive web app advocate in me was thrilled. There aren’t many websites built to be so responsive, enabling them to be viewed well on different screen sizes. In fact, the only glitch in the layout was the one I had originally seen, and it only appeared on larger screen sizes. From how the site was behaving, I was pretty sure the cause of the bug was a media query gone awry; all that remained was for me to find it and fix it!
First, I raised an Issue to describe the behavior and added screenshots to provide examples:
Then I forked the Jenkins X repository containing the source code used to build the documentation and website for Jenkins X. I cloned the fork on my machine and spun up the application locally. To do so, I needed to install Hugo, a static site generator written in Go. Happily, both Hugo and Jenkins X have good documentation, so the process of building the website locally was smooth. From there on, it was a matter of hunting for the media query that was creating the bug in the layout. For this, I relied on my previous experience building responsive web sites, which is a great example of how you can approach a new open source project and start contributing right away by fixing whatever errors and bugs you find using the skills you already have.
I was able to contribute quickly to the Jenkins X project by leveraging what I already knew how to do. This is quite a relaxed and validating way to approach making your first contributions to a project. The Jenkins X community swiftly approved my PR and merged it in, which felt great!
I leveraged my web developer skills to make my first contribution to the Jenkins X project, but you can bring the skills you have; the key thing is to have a willingness to contribute. There’s lots you can do: edit the docs to improve them, fix a broken link or offer to help translate the documentation!
And that’s how you can get started as an open source contributor: contribute in some way that makes a project a bit better and… success! Then keep going: delve further into the codebase; work on issues labeled “good first issue”; join the community’s communication channels; ask questions; keep fixing things; learn more, build more.
Enjoy the journey and we’d love to see you in the Jenkins and Jenkins X communities!