A guide to understanding Open Source projects, the various ways you can contribute, the talent and time required, and how to set goals for yourself. This article focuses on contributions of code, such as via pull requests or issue submissions, to open source projects.
Contributing to an open source project is a great way to give back to the community, both individually and as part of a team. We’re here to help people new and old get started with open source, so that more people can begin to share their own skills and knowledge with others. Since open source is such a big topic, this guide contains only the basics: how and where to look for opportunities, how to setup your development environment, and how to find the resources you need for contributing code.
Create your own open source project
Every project should start with an identified need. If you feel that existing projects on GitHub or Bitbucket don’t offer the functionality you would like to build, then create your own open source solution. Besides an initial project draft, you should consider the following set of questions:
- What skills do you need for your project?
- How much time are you willing to spend on your project?
- What problem(s) does your software solve?
- How many potential users are there for your product?
Opening an issue
You should usually open an issue in the following situations:
- Report an error you can’t solve yourself
- Discuss a high-level topic or idea (for example, community, vision or policies)
- Propose a new feature or other project idea
Tips for communicating on issues:
- If you see an open issue that you want to tackle, comment on the issue to let people know you’re on it. That way, people are less likely to duplicate your work.
- If an issue was opened a while ago, it’s possible that it’s being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
- If you opened an issue, but figured out the answer later on your own, comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
An important step to do before contributing is to sign the contribution agreement. While you can always write a piece of code, attach a LICENSE file and state it is open source, the reality is generally a bit more complicated than this.
What if your repository has multiple LICENSE files spread in different directories? You should really apply the license conditions to each file. But that may not be enough.
So, to contribute to an open-source project you are generally required to sign an UCLA (User Contribution Agreement).
Note that those UCLAs varies according to the maintainer of the project. Some may ask you to assign them the copyright of your contribution. This means they will own the code and you will not be able to use it on your own anymore.
However, many serious projects just ask you sign an agreement that you release your contributions under the open-source license of the project itself. You will retain the copyright, so you will be able to use your code as you like, including in proprietary projects and sell it (note: your code, not the code of the project!).
You UCLA signing will simply assure the code you released is open source and everyone can use it under the terms of the open-source license itself.
Contribute to existing open source projects
You can find many projects you are free to participate in on GitHub – a developer-oriented platform with a simple but essential set of functionality. GitHub attracts developers with public APIs, a sleek and frequently updated UI, gists (Git repositories) that allow you to share pieces of code or even whole applications, and much more. You can contribute to free software in many ways. Developers can fork projects, make changes to code, and send pull requests. And quality assurance is always appreciated. Sometimes developers are too busy or too lazy to check the quality of their code. So go ahead and report a bug or try to fix it – your help is appreciated.
You can reach the hottest GitHub projects by following the “Trending” link. And in order to make your search more relevant, use advanced search: select the language you would like to code in and choose “best match” criteria. Best match ranks projects according to relevance, taking into account the number of forks (which represents how actively the project is updated) and stars (“likes”, in the language of Facebook). Most projects have known issues (however, some don’t) with labels like “bug”, “discussion”, “security”, or “refactor”, or other labels according to the level of difficulty: “easy”, “medium”, “hard.”
Don’t waste their time (and yours)
Let me finish talking about a few things not to do, but unfortunately it is very common and always ends up in a waste of time.
The first thing is to propose technological changes only because you know that technology and the project uses a different one. “Terraforming” the project to your skill set is a temptation that everyone has, and indeed many people really think that proposing changes to their favorite stack is a smart move to do. It is not.
If the project was done in that way was because other people work and appreciate that technology stack, and it could be even better than the one you already know.
To make things worse, in those case you may even end up in religious wars saying your proposal it is “better”, hence alienating the favor of those people who choose the current stack in the first place and worked on it.
The second thing not to do is to contribute “architectures” or “requirements”, but not code, and expects other people will implement it. While in certain cases it can be useful, if you act this way you are basically treating the open-source project developers as your consultants and you are the client. Except you are not paying for it.
The general rule is that if you give requirements you should also be willing to implement it.
Finally, do not contributes typo fixes… only. It is certainly useful. But you really do better to do that as part of larger and more significant work, otherwise you will look like the schoolteacher that wants to correct others while you are basically unable to do anything better.
So, start from a bug fix not from typo fixes. Unless, of course, you take the task of fixing typos in the whole documentation, that is a different and significant effort.
Engaging with the open source community is a great way to learn how open source projects are run and put your skills to use in an environment where everyone is willing to help you.