“Do I literally just fork a repo and claim an issue?”
A friend recently asked me for advice getting started contributing to open source software. My friend has some extra time and is motivated to help out. My friend’s desire to do some open source contribution is a bit like a desire to write a novel: “Ok, I want to write the next great American novel. What should I write about?”
Luckily there are some general guidelines that anyone can follow to make a meaningful contribution to open source software.
Read the guidelines for contributors
Open source software repositories often publish guidelines for contributing in a document called
CONTRIBUTING.md, see for example: puppet’s CONTRIBUTING.md.
Be aware that guidelines for contributing may be included as a section in the
README, or in a wiki associated with the repo.
Find an issue or create one
Run into a bug when using open source software? Boom there’s your issue.
Browsing the Issues tab on an open source software repository can be a great way to find work that needs doing. It can also tell you if the issue you’re about to create has already been found by others.
Don’t be discouraged if the issue you intend to create already exists, that means that you may have reproduced an issue on a new platform. At the very least, you’re not alone, and adding the feature or fixing the bug mentioned in the issue will benefit others.
Make sure you’re not reproducing issues that already exist. Issues are about communicating work that needs to be done, so it’s best not to muddy the waters in order to respect people’s time and effort, and keep communication efficient.
Commenting on an existing issue with information about reproducing the bug on your specific platform may be helpful. Simply adding a “+1” increases the signal to noise ratio. So think twice before adding unnecessary comments.
Start a dialogue
If you’ve found an issue or created one, start a dialogue:
- Say you’re interested in working on the software
- Propose a solution (if you have one in mind)
- Ask for folks with more experience whether your solution makes sense
If folks with more familiarity and expertise say your approach looks good, go for it. Heed the advice and alternative solutions offered by those more experienced with the software.
It never hurts to show up and say, “Hey, I’m unfamiliar with this library but I’m interested in helping. Could you direct me toward resources that would help me address this issue?”
Be respectful of other people’s schedules
Keep in mind that everyone involved will likely be volunteering spare time to work on this open source software. Don’t expect instantaneous responses when you start a dialogue.
Look for a project with a lot of recent activity in commits and issue discussion or one that has a Slack, HipChat, or Gitter if you feel like you need more available feedback or guidance.
Don’t worry about getting scooped
If a bug that you intend to work on gets fixed, great. A problem you had is no longer there. Use the fixed version of the software and move on. There will always be another bug for you to fix down the line. And hopefully now you’re familiar with the contributing guidelines and you’ve started to interact with the community around your open source software of choice.
Part of respecting other people’s schedule and being willing to start a dialogue around the open source work you will do involves remaining patient. Remember to be patient in all your interactions around open source software.
You and your fellow contributors to open source software are working toward the same goal: improving the software. Don’t worry about getting scooped.
Low hanging fruit
If you’re intimidated by a repo with a large number of issues, look for low hanging fruit:
- Can you update the dependencies?
- Can you improve the setup documentation on the way toward working on a larger feature improvement?
- Can you add any missing tests?
It can be easier to contribute to software you use every day.
- What bugs have you recently had to fix in libraries that you use daily?
- What feature have you had to implement for your own use that a library you use does not provide?
Remember that you’re communicating with other people behind keyboards for this project. Remaining respectful, courteous, and communicative can go a long way toward a successful first contribution to open source software! Check out my open source contributions from last year’s Hacktoberfest and get excited to make your own.
Open Source contributions from PromptWorks Staff
There have been occasions we have created software tools for clients that staff has published as open-source. Below are two examples of software the staff has made available: