Becoming a new contributor to open source software is one of the biggest obstacles I watch people hit regularly.
I've seen a hundred false starts from recent grads and even people who have been working in tech for years. The obstacle is consistent, but the solution isn't always simple.
Anyone who tries to give you a canonical recipe to get involved with any OSS community is fooling themselves – and you. But there are some general things you might be able to implement to help you get past the barriers to entry.
1. Get some context
Over the past two weeks, I've contributed to a few repositories within the Cloud Native Computing Foundation.
I didn't start contributing just because I wanted to have my name on the repositories, but if that's your motivation, I won't shame you. My contributions were motivated by a desire to help close some gaps, which I noticed would be tedious for the existing maintainers and contributors.
I became aware of the gaps because some of us at Sonatype are helping create educational content related to Security Slam, a three-week-long event hosted by the Linux Foundation.
It was quickly clear to me that this is a tedious process for maintainers to do alone, so it was a prime opportunity to contribute.
Tedious tasks like this are common to open source communities year-round. If you keep an eye on community channels to spot them when they arise, these are prime entry points for new open source contributors.
Given this effort was being made across the CNCF ecosystem, I reached out to a single repository within the Argo project to see if I could help implement the recommended security standards. Since I already had some familiarity with the community that maintains the repo, I decided that was a great starting point.
2. Start a conversation before contributing
"Pull requests are welcome" is a very common phrase in open source projects, but there is maintenance work associated with every pull request. It is not uncommon for maintainers to struggle to keep up with all the recommendations and changes being proposed by the community.
So in order to respect the maintainers, I opened a discussion on their GitHub repository to make sure I would be working on something the maintainers found valuable.
I put as much detail as possible in the discussion thread and got a detailed response the next day. They encouraged me to join their Slack channel, where I was able to discuss the issue in more detail and refine my course of action.
3. Track the work before doing it
This is closely related to my previous point, but it's still important.
I spent half an hour crafting a GitHub issue to track the work, which may seem like a lot… but it has several benefits.
-
By spending time articulating the problem and proposed solution, I had an opportunity to find gaps in my understanding before getting started.
-
By making my "to-do list" public, I created space for others to provide suggestions and input to help me contribute better.
-
GitHub issues can be linked to by PRs and other issues on different repositories. This creates a sort of spider web of information that can all be viewed from the central issue.
4. Do the work, one step at a time
The GitHub issue I created had a checklist of things I envisioned needed to be done in the codebase, so I created a pull request for each one.
By segmenting the pull requests into small bite-sized pieces, the reviewers could quickly respond without taking a lot of time from their regular schedule.
5. Resolve checks, answer questions, apply feedback
This is an overloaded list item, but it's basically one thing.
A mature repository will have automated checks designed to help the project stay tidy. Many repos will have checks to ensure you've provided a standardized PR title and description.
Reviewers will often ask questions or provide suggested changes. Sometimes the questions won't result in any requests for changes, but the process of questioning is valuable nonetheless. Respectfully answer questions and strongly consider every suggestion that is made.
6. Follow through
To really serve the community (and gain reputation benefit for yourself, if that's your goal) be sure to look for a natural next step after your work is complete.
In my case, I am continuing by helping other repositories in the project complete their Security Slam goals.
In your case, you may want to take the experience you just gained and look for other tasks in the community that are interesting to you – or you have the skill/insight to help with.
