Contributing to open source projects

Amit has written from India asking how to start participating in open source projects.

I am a software developer from India and recently came through your article on "How improved hardware changed programming". It was good reading it. I wanted to know more about open source projects & how to get involved in it. I read that you contribute to a couple of them so thought of asking you about your experience and how did it help from a developer's perspective.

My experience with code contributions to open source projects is mainly in the field of Php libraries and frameworks. This is not a coincidence as I am more stimulated to make contributions to projects I personally use: if I had to give one advice to choosing an open source project to participate in, I would recommend selecting a project you actually use at the Api level (interfacing with their source code or with their binary interface with your own code).
It's not an egoistic choice, although you would clearly benefit from your improved knowledge of the project internals, bugs that have been fixed and new features that have been introduced thanks to your work. It's more a synergistic approach.
Employing an open source project at the user level (in the case of standard applications) gives you a picture of its overall features and maybe an involvement with the supporting community, which is not a deep vision of the project goals and inner workings. But your contribution will be by far more valuable and simple if you start with contributions to codebases you already know "intimately". I would never try to contribute to Pidgin with code, because even if I run it all the time for instant messagging, the time I would spend in a field not related to my work it's probably not worth very much, as there is a steep learning curve and the learning process is limited to a field I'm not interested into (and thus am likely not to enjoy.)

I contribute to Zend Framework and Doctrine (Php projects), and almost all of my patches are derived from discovering a bug or an incomplete behavior in part of the library and wanting to fix it once and for all. For the uninitiated, a patch file is a text file written in particular formats for modifying a codebase while sending only the set of changed lines of code. It may be the case that some projects use different collaboration models (Git push and pulls for example), but usually these models are automated processes built on juggling patches around.
It's important to get patches upstream, to the official maintainers, so that they can decide if the change fits the vision and the guidelines of the project (for instance backward compatibility), and include it in subsequent releases. This is an example of advantage of valuable contributions: you do not have to patch your copy of a library every time a new release comes out. Conversely, everyone that downloads the original project will benefit from the improvements (hoping that little bloat is introduced.)

Besides the code contributions, there are several ways to help open source projects whose code you're not familiar with:

• writing end user documentation and tutorials that help the spread of the application.
• Signalling bugs and providing more general feedback about the user experience.
• Writing translations for the user interfaces: while nearly every developer speaks English, other languages are rare and if you happen to know Slovak, you may help.
• Even small donations are useful if you feel like contributing somehow but you do not have time. Money usually goes towards web hosting for the project to remain accessible to everyone.

Summing it up, there are many ways to contribute to open source projects, with and without writing actual code. Every respectable project has a Contributing page dedicated to provide you with a few pointers to start out and meet the maintainers: look for it and see how you can give back to an application that eased your work many times.