Tips and tricks for becoming an Open Source contributor
Open source is software whose source code is open — in other words, it can be accessed by anyone. It is a way for anyone to find a group of collaborators on a technical project. People join open-source projects to connect with the community, to learn technical skills, to help create software they care about, and even, in the case of a few projects, to earn swag.
Employers may evaluate software job candidates based on their contributions to open-source projects. Many recruiters are even looking for potential candidates on GitHub. So, contributing to open source can even help you land a job. On your resume, you should list any project you significantly contributed to and the main contributions you made. This can help give employers a feel for the technologies you know and highlight your skills as a team player.
Only some open source software is free software — software anyone can change and redistribute without limits. However, all free software is open source. Contrary to what some people believe, free and open-source software can be sold.
You might choose a project based on what technologies it is built with, what the software is used for, and the quality of the project. Learn the project structure, including the documentation, release frequency, package format, maintainers, contributors, and who accepts pull requests. You should also look into open and recently closed issues, how many there are, how long they take to turn around, and why. You want to look at the quality of the source code, including code coverage by tests and whether the test framework is up to date. All this information will help you assess the quality of the project.
One way to find projects is on the open-source platform directly. GitHub is the main location of good open-source repositories, although there are others such as Bitbucket. Based on your previous GitHub activity, such as repositories you’ve marked with a star, repositories you’ve viewed, repositories you’ve contributed to, and your projects, you will also get a list of projects that may be right for you. You can also subscribe to the GitHub newsletter to get an email feed of recommended projects.
To get more accurate search results and feeds on GitHub, you can change the likes you’ve given to other projects. To do this, go to your GitHub profile, click “Repositories,” and then click “Stars.” Then you can remove stars from projects.
There are other ways to discover projects, outside the platform. Perhaps you already use the technology, or you read about it in an article, or you heard about it in a tech talk. Or a friend told you about it. A number of external sites and apps, such as Goodfirstissue, Up For Grabs, and Sourcegraph, can also help you find open source projects.
The project’s popularity is reflected in the number of GitHub stars it has, the number of watchers, and the number of forks. Other labels, such as open issues that require help and help-wanted, may tell you more. The programming languages used to build the project are visible in a graphic, and other aspects of the technologies such as the programming framework may be described in the documentation.
There may be two or more similar projects in terms of language and technology, but their structures will differ. Only one project may have a wiki for hosting documentation, and only one project may have continuous integration (CI). You may want to build on the more-developed project, or if the less-developed project looks promising, take some ideas perhaps and add to that project.
No matter how mature the project is or how many contributors, open-source projects always need additional hands on deck. Perhaps sections of the project need to be updated to be compatible with newer technologies, features need to be added or changed, or bugs need to be fixed. Even the largest and most active projects will have open issues, no matter how many maintainers and contributors there are.
Participating in an open-source project is not only about submitting code but is about doing anything to help the project grow. Anyone interested can participate in an open-source project, including those who do not have programming skills.
When you dip your toes into contributing to the project, you probably don’t want to get too ambitious too soon. Start by keeping your pull requests small. Also ensure you are consistent with the project’s format, by reading CONTRIBUTING.md for instructions if such a file exists. If such a file does not exist, you might want to propose creating one. Review the last ten pull requests and model the format of your pull request after these.
A partial list of ways to contribute:
- Building a new feature. This might be one of the first things people think about when listing ways to contribute to the project. Especially if the feature catches on, it is also one of the best ways being involved with an open-source project can improve your credentials. However, it is not always the best approach for any given contributor. Adding a new, completed feature requires you to thoroughly understand the project’s priorities, so you can be working on one that matters to the project as a whole. It also requires you to write thorough code, tests, and documentation, as well as understand any interfaces well enough to keep them easy to use.
- Reporting bugs. This is the easiest way to participate in the project, as one need not be a developer. It is also one of the most important tasks. Simply download and install the software, start using it, and note any bugs. Then, if these bugs have not already been reported as issues, create new issues that these bugs exist. This will alert developers that the bugs need to be fixed.
- Answering questions. Sometimes, issues are used not to report bugs but to ask questions. Open issues may be used as a forum where people ask and answer questions, such as “How do I use this feature”?
- Creating documentation. This also does not necessarily require programming knowledge, although it requires good writing skills. Go through the documentation of the project and see what is missing or needs to be improved. Then try to fill in the gaps. Often, for example, the License file has misleading or irrelevant information. The License file should contain registration information that allows a registered user to open and access a piece of software.
- Translating documentation, programs, and interfaces into different languages. Many projects use translation services, such as translation systems based on web services or the gettext-compiled MO files. You can also translate into a foreign language that would help expand the project’s userbase or programmer community.
- Starting discussions and making suggestions. If you have an idea of how to improve the software, such as adding new features or changing old ones, you can create a new issue or share your thoughts on an existing open issue to make it into a discussion. You can also provide feedback on others’ ideas. A project that has a discussions section is unlikely to accept open issues unless you first participate in the discussion.
- Adding tests. Many projects have features that are missing the unit and other tests.
- Improving infrastructure. Many projects face infrastructure issues such as continuous integration and continuous delivery (CI/CD), or developing a website or a landing page. You can contribute to these. Improving configurations, in fact, can be a good first contribution to the project.
- Resolving existing open issues. This often, but not always, requires programming knowledge. For example, some issues may involve fixing or improving documentation, and many involve writing code. Simply go through the list of issues and find ones you would like to help resolve. Sometimes, issues are duplicated and you can dedupe. Sometimes, there is a discussion on the issue ticket where you can participate.
- Suggesting issue labels. If the project does not have issue labels, you might want to suggest a labeling system.
- Evangelism. You can spread the word about the software on social media and tell your audience how the software works, what issues it helps solve, and why it is preferable to others. This is an important way of growing the community around the software project.
Set up Git, the version control system used by GitHub, with the instructions here. You do not want to use your corporate GitHub account for personal commits, or vice versa. If you decide to change your email address in GitHub, all your contributions will be deleted.
Forking means taking the source code from an open-source software project and developing an entirely new program. Often, it is the result of a deadlock in an open-source project that is so insurmountable that all work stops. In this context, a fork is a process that generates a copy of itself. A fork may also be merged back with the main repository in a pull request. Or, it may even replace the main branch of the project as the one where maintenance primarily occurs.
A similar approach is to create a new repository by cloning the old and creating a branch inside it. Although there would be no indicators the repository is a fork, it would have the legal status of one.
While forking lets you change anything without waiting for the maintainers, it also removes you from the community of the main project. Or, if some community members join you, splitting the community may decentralize it. It may also be difficult to identify the author of the project, the idea, and such. Furthermore, creating forks litters the project’s ecosystem.
In your README file, you want to describe the changes you made to the original repository. This will clarify whether other contributors can participate, and how.
Maintaining an active, multi-user project is the gold standard for being an open-source contributor. If you do this, the project becomes your responsibility. Should it be widely used or popular, you become accountable. One day, you may wake up implicated in a disaster. One incorrect pull request that you accept may cause serious problems for companies using similar technology.
There may be several maintainers in the project who divide the workload and responsibilities. Typically, maintainers accept patches, develop new features, resolve issues, answer questions, fix bugs, release new versions, update the environment, design and monitor continuous integration, and sort out security issues.
Open source enables you to break out of the technologies and community you were placed in, and choose your own. These empowers technologists to take their careers into their own hands. While it seems at first blush that the contributors are working for free, over time, this is not the case. In reality, they gain marketable skills and become more valuable from their experience.
This article was written with Serghei Iakovlev, Director of Development at airSlate, based on his tech talk. Serghei’s talk was translated into English by Olha Osadchuk.