How To Find the Right Open Source Project To Get Involved With

An anonymous reader writes Writing on Opensource.com, Matt Micene shares his thoughts on getting started with an open source project. "I came back from OSCON this year with a new fire to contribute to an open source project. I've been involved in open source for years, but lately I've been more of an enthusiast-evangelist than a hands-on-contributor to an open source community. So, I started some thinking about what to do next. When I was involved in projects before, it was due to a clear progression from user to forum guru to contributor. It's a great path to take but what do you do if you just want to jump into something?" Matt goes on to lay out several steps to help new contributors get started.

Comments

Problem oriented

[Anonymous Coward]

Find a problem you want solved, then find the tool that appears to solve the problem. Find out why the tool doesn't solve the problem adequately and improve on it.
If no tool is available, start a new project.

Re:Problem oriented

[rasmusbr]

Just remember that you will probably have many moments when you think that the tool doesn't solve the problem adequately, when in reality the tool does actually solve the problem adequately if you know how to use it. The real problem then is that the tool comes with inadequate documentation, or that it needs more or better tutorials and sample projects for novice users.

Make sure the project wants you

[Anonymous Coward]

There is a utility that I use very often and thought could use a couple of feature additions and bug fixes. I coded these, taking great pains to ensure that my additions were clear, matched the preexisting coding style, and adequately commented. I sent a patch to the utility's developer, only to be told that he works on the project for his own pleasure, but doesn't have the time or inclination to look at contributions from other developers. I suspect that quite a few single-project *nix utilities are like this. Before writing any code, make sure that patches are welcome.

Re:Make sure the project wants you

[arielCo]

I thought that's what forking was for - you roll your own version, advertise it, and the original author may be persuaded to incorporate your changes. Worst case, you have two project cross-pollinating (e.g. mplayer / mplayer2 / mpv, ffmpeg / libav, TWiki / Foswiki).

A matter of perspective

[lennier1]

In my case it was because I'm a lazy bastard. I needed e bug tracking module (exception details are turned into a unified format to report to a bug tracking server) and I came across one that was already 95% of what I wanted, so I simply contributed enhancements until the final 5% were covered.
The same thing got a former colleague of mine involved in the Firebug project until he became a regular contributor.

How to get paid to work on open source

[bzipitidoo]

I'd rather hear about how to get paid to work on open source. The article talks a little about convincing your current employer to donate some of your time to a project. But first, you need an employer.

Then, your job has to have some down time. I've never had a job in IT with any down time at all. There are always bugs to fix, features to implement, fires to put out, and management to report to. Management is always pushing for more, questioning numbers and estimates or just simply cutting time, to the point that a deathmarch becomes a certainty.

try SLASH

[slashdice]

beta.slashdice manager here. We're desperate for open source (ie, unpaid) programmers. No experience necessary! (or even desired). Make an immediate impact by editing directly on the production servers without testing or pointless code review meetings. Your choice of editors - vi, emacs, ed, pico, joe, or whatever happens to be installed on the server.