In the article “Why you should contribute to open-source” Shalin Mangar lists some of the benefits of participating in an open source project.
However, there are a large number of open-source projects out there; indeed, quite a few tools have multiple active implementations. How does a new contributor choose a project to contribute to?
The process I usually suggest is:
- Start by choosing a domain of interest—an area which you would be comfortable spending a few years of your life learning about.
- Short list two to five interesting open-source projects in this domain.
- Research the functioning of each project using the check list given later in this post.
- Narrow your list down to one project that matches your values.
- Dive in and start!
Whether this is compilers, operating systems, GUI tools, Web 2.0 tools or something else, you should choose a domain that fascinates you.
Search for existing open-source projects—collaboratio`n sites like Freshmeat or SourceForge can help you find an active project in the area you are interested in. Sites like ohloh.net can help you guage the project’s activity levels and other vital statistics.
Spend some time examining each community. Visit their home pages and browse their code. Keep a look out for the key values held by the community. The following set of questions could help get you started:
What is the quality of the project’s source code and documentation? Is doing work to a high standard a value in the community? What will you learn by reading their code?
Warning signs: incomprehensible code, documentation that is sparse or poorly written, or that is out of sync with the code.
What are the project’s communication channels? Do they maintain public archives of their communication? What is the signal to noise ratio observed on their channels? What tone of communication is commonly seen?
Warning signs: snooty behaviour towards newbies, excessive bureaucracy within the project, contributions being silently dropped.
What are the project’s development processes like? For example, they have a culture of performing code reviews? Do they use a ticket tracking system? What kind of automation do they use?
How open is decision making in the project? Do you see evidence of outside input being welcomed? How do conflicts get resolved?
Warning signs: private communication channels between select developers, small groups of developers taking ad-hoc decisions without input from the other stake holders, frequent conflicts that escalate.
What is the project’s maturity? Are there experienced hands around to act as mentors? Do you see evidence of such mentoring on the project’s communications channels?
How active is the project? Projects that show a steady (or steadily increasing) rate of progress over a long period are usually in healthy shape.
Who is behind the project?
Some open-source projects are dominated by people employed in a small number of companies. Such projects run the risk of sudden death when corporate priorities change, as happened to the OpenSolaris project, one of the best operating system projects of its time.
Look at the profiles of the key developers; keep a look out for projects that lack sufficient diversity.
- What is the licensing of the project? Some projects use permissive licenses like the Apache license, while some prefer the more restrictive GPL. Are you comfortable with the license being used?
Write down what you expect to gain from participating in the projects in your short list.
Some of the reasons people participate in open-source are:
Wanting to contribute and make a difference to society.
Wanting to learn and become an expert in some aspect of computing.
For some, open-source provides a creative outlet that their employment does not provide.
For some, open-source is a way to join a community—they value the company of people sharing a common interest in a domain.
Use your values as a guide to selecting the project that would fit you the best.
Hopefully the suggestions above would have helped you narrow down to one, attractive open-source project. Your next steps would be to dive in and learn your way around the project’s code. Pick a bug to be fixed, or a small feature that needs implementing.
Good luck, and happy hacking!