How did you get involved with your open source community?

Question

It seems that the normal progression to join projects is to contribute for a while, earn the trust, then get accepted as a member of the community (i.e. having commit access).

Now, I already apparently know "the best way" of how to get involed, in a manner of speaking; this is not my question; what I was hoping to attain is: How did everyone else get involed? Surely not everyone has gone down the "find a project and submit patches" route - or have they? I dont happen to know anybody in the open source community, so I'm just itching to know...

Perhaps you already knew someone in a community and just fell into it? Maybe you were getting frustrated with some bug and started contributing regulary as a result? Maybe you did just spot a project on SourceForge...

Update:

It seems that the most common reason is simply scratching an itch, to quote singpolyma: "Looking for a project to contribute to is often not the right way." Instead, you should join the open source community by contributing to a project that you already know and use.

Important:

Please, please, please: Tell me about your specific experience, no general answers please. Also, answer only if you are either a project member or a patch contributor. Please do not give advice on how to join a community, this isn't the kind of answer I'm looking for. If you would like to give advice on joing a community, please answer in this other thread.

Great Answers:

• Mark Harrison talks about Tcl, cx_Oracle, kap and orapig
• singpolyma talks about DiSo and Greasemonkey
• Pax talks about contributing to GnuCash because of his wife

Related:

• How to get involved in an open source project
• How Open Source Projects Survive Poisonous People (And You Can Too)

Answer 1

My personal anecdotes:

1. I got involved with the Tcl community when it was first starting out in 1991 or so. The mailing list and later the usenet newsgroup were pretty important to connect with people. I specialized in user evangelism and teaching, and eventually ended up writing two books about the subject. One of them is still in print after ten years: http://www.amazon.com/dp/0201634740

2. Now I use a lot of Python, and really like the cx_Oracle package. Again I was active in the mailing list, and contributed a few patches.

3. I've made a couple of software packages available that I had written for work. By making them open source, I was able to get some nice contributions back, and since they were not the "secret sauce" of my employers at the time, they didn't mind sharing the code. The two most popular packages were

   http://sourceforge.net/projects/kap/ The Kinetic Application Processor -- this was built when I was working on the China Internet backbone.

   http://code.google.com/p/orapig/ - OraPIG, the Oracle Python Interface Generator -- it generated Python code to call APIs defined in the database, and includes an XML-RPC database interface.

Advice:

Instead of looking for projects to join, try contributing to projects you already use.

It's often difficult to jump into the "core" development, because (a) on a big project, that might be a pretty big chunk of code to understand, and (b) there are probably a core group of people already working on it.

So, suppose you like a certain piece of software and want to start contributing, you can start working around the edges. Here's a couple of concrete tasks that will help you to become integrated with the group.

• write some test cases for bugs to add to the regression test suite.
• browse through the bug database and find a bug to work on. This might be the best way to get into the core development.
• look at the feature request database and see if there's a small task you can work on.
• look for "user doc" requests... a lot of them involve writing example code which you can provide.

Good luck!

Answer 2

I joined DiSo and Greasemonkey.

The best way I've found to get involved is to get in early in the life of the project, or just be very interested. With DiSo or the various github projects I'm on, it was the former, with my Greasemonkey contributions, the latter.

Looking for a project to contribute to is often not the right way. Use stuff and find out what you want to build/fix, then do that.

Answer 3

I did a little bit of patch work on GnuCash since my wife restarted work part-time recently after our kids were a little more grown up.

I would've rather had my eyes ripped out with a hot poker than re-install Windows but GnuCash was missing something that [a certain other accounting package] had so I told her I'd get it added.

As it turns out, they took my patch and made it a lot better before putting it in (to the point where maybe 1% of the final patch was my stuff) but at least we can now use GnuCash instead of that proprietary stuff. They were also incredibly responsive - from patch submission to patch availability was only a week or so and it was in the product three weeks later.

I also once investigated getting a patch into the process accounting in the Linux kernel but the effort required far outweighed my needs :-)

I don't contribute on a regular basis, more as-needed (find your itch and scratch it). There are some who make a hobby of it but I'd rather be spending my spare time with the kids and, unfortunately, my employer won't pay me to contribute elsewhere.

That last bit particularly galled me since:

• the Linux patch would have greatly assisted our product (and a lot of others).
• it was change in behavior of another of our products that degraded the usefulness of our product.
• the solution was fairly simple, conceptually (the effort required was testing since a problem would have been high-impact [task switching] and very pervasive [everyone using Linux]).
• it would have been quicker to code up the patch than the workaround we eventually implemented.
• the workaround is a kludge (p'tooee).
• now, nobody in the world has the benefit of our patch (including us).

Answer 4

TODO: Please share an anecdote, if you dont mind.

The way people normally get involved is:

• you use the FOSS product in your day to day work
• you notice a problem or a missing feature
• you mail the maintainer to ask if this bug/missing feature is real
• the maintainer says yes, this is a bug/missing feature
• you decide to try to fix/add the bug/feature
• you code like mad
• you submit a patch to the maintainer
• the maintainer laughs in or face or says "thanks very much!

If you repeat the last few steps a few times, the maintainer will probably give you commit access to the project's RCS repository, and then you can really become dangerous. But the bottom line is that it is up to you to do something i.e. write some code - merely being "interested" in a project is not enough.

Answer 5

What I did was pretty simple; I opened one.

I have been joined by one permanent developer, and other two who donate code behind the scenes. The project is in very early stages, so not many users have downloaded it.

Answer 6

What really helps an open source project is having a plugin architecture.
It's much easier to contribute a simple plugin for eg. a file format than to try to add something to the Linux kernel. This makes it a lot quicker and easier to build a community.

TODO: Please supply an anecdote.