How can OpenHatch help me contribute to free software?

by Asheesh February 25th, 2010

Stand tall

I have a secret to share with you about open source software. It’s made by regular people like you, not superhuman robots from outer space.

Most projects are humble enough to document their problems — bugs, missing features, unwritten documentation, and more — in a bug tracker. To contribute, all you have to do is find something to work on, build and share your improvement, and convince the maintainer to include it.

You don’t have to be a programmer. Lots of projects urgently need design, writing, translation, testing, or marketing help. And if you are a programmer, you’ll find there’s plenty to do.

Let’s start at the beginning.

Find something to work on

OpenHatch indexes a fair number of bug trackers in our volunteer opportunity finder. If you know how you want to contribute (for example: writing documentation or Python code), try browsing for projects that need that form of help. You can use the search box to search the full text of bugs.

Some bugs in the volunteer opportunity finder are labeled as “bite-size”. This means that a project maintainer has marked this bug as good for newcomers. They’re a great way to learn a project’s code or the open source process in general.

Go on, try it and browse for a while. I’ll wait right here.

(If you want to work on a project outside of our index, find their bug tracker and try to find something you can work on.)

Download the source code and make your changes

Once you know what you want to change, give it a shot. You’ll need to download the source code to the project in most cases, even documentation changes.

Now open up your editor and make your improvements. The project may have a README file that explains things you need to know.

Once you’ve created a new version of the material, don’t forget to test it out. If it’s documentation, make sure you used the right syntax for formatting it. Many projects use a tool to generate HTML pages out of the documentation; if you changed documentation, run that tool and make sure your improvements look OK. Projects also often include tests that can automatically verify that the program still works. Typically, the README file will tell you how to check whether your new code passes all the tests.

Share your work as a patch

Most projects like receiving modifications in the form of patch files.

If you downloaded the source with a version control tool, look for a feature called “diff” that outputs a patch. Usually it’s as simple as running a command like this:

git diff > filename

Then filename contains your changes.

(If you didn’t use a version control tool, check out Stephen Jungels’ quick guide to using diff and patch.)

Once you have a patch file, write a comment on the bug explaining what you’ve done. It’s okay to write a long comment — details are great. Then attach the patch file to the bug report.

And wait.

Convince the maintainer to include your work

If you’re lucky, within a few days, the maintainer will thank you for your work and include it into the project. If not, you should assume the maintainer is very busy. Leave a friendly note after a week or so asking for feedback.

If you choose a bug that’s labeled as bite-sized, you’re more likely to get feedback quickly. That’s for two reasons: The bug is small, so the maintainer isn’t afraid to read a long patch, and the project maintainer is probably especially open to new contributions.

As the maintainer gets to know your work, she or he might allow you to skip the whole permission process entirely, and “commit” or “push” directly to the code.

Welcome aboard!

Write a comment