Get In It – A Guide to Contributing to Open Source Projects

I love contributing to free open source software. Throughout my career as a software developer, F.O.S.S. has helped me along. These projects are libraries in the classic sense — Athenaeums, troves of knowledge and learning. They are tools and building blocks that speed your projects toward completion. To me these open source projects represent boundless opportunity: to learn; to hone skills; to collaborate with others.

What follows are the standard tips I give to developers interested in making their first open source project contributions.

Basic Obstacles

In general, there are three obstacles standing between software developers and collaboration. In order of importance:

1. Discovering projects to which they can contribute
2. Understanding what a project does and how it works
3. Running the project in their own local environments

Basic Tricks

Most interested coders struggle more with the first item than with the latter two, so here I’ll discuss specific “tricks” you can use to help in discovering opportunities to contribute. Inside my bag of tricks:

* Code Climate (provides code quality analysis for JavaScript, Ruby, Python, and PHP)
* Test Coverage Reports (Coveralls, SimpleCov, and others)
* Github’s Activity Feed

My Code Climate trick has never failed me. Any time you see a Code Climate badge: give it a click and see what code quality issues it has. The two particular issue types clearly indicating an opportunity to contribute are Complexity and Duplication. When you find these, clone the project and get to work. If a project lacks the Code Climate badge, you can still analyze it to find opportunities for improvement. Just enter the project’s information here: https://codeclimate.com/github/signup.

Improving test coverage is another (nearly) fool-proof route to contributing to open source projects. Look for Coveralls badges with room for improvement. If the project lacks the badge: clone the project; add SimpleCov (https://github.com/colszowka/simplecov) as a dependency; tweak the project’s test configuration; then run tests to generate a code coverage report.

Refactoring and adding test coverage is all well and good, but how can you find new projects to look at in the first place? My pro-tip: follow Github users. Don’t be picky. The folks you follow will expose you to projects. To learn more about Github’s Activity Feed and how it helps with discovering opportunities to contribute, check out How to Have a Good Time with Github.

Examples:

* Bringing fluent/fluentd-ui’s Code Climate score up to a 4.0
* Refactoring mbulat/plutus to reduce some tricky duplication
* Bringing gocardless/coach’s test coverage up to 100%

None of these contributions required a keen eye or any intimate knowledge of the projects themselves. I simply used the “tricks” outlined above.