Open Source Howto

November 15, 2005 7:19 PM

Open Source Software developers, how did you initially start working on open source software projects?

Did you jump right in by submitting patches? Did you start out by testing and submitting bugs? Any advice you'd like to share that you wished you knew when you started?

posted by jsonic to Computers & Internet (13 answers total)

jsonic, have you read ESR's thought's on this?
posted by onalark at 7:22 PM on November 15, 2005

Response by poster: While this question is focused toward joining an existing open source project, I'd also be interested in your experiences with starting one.
posted by jsonic at 7:24 PM on November 15, 2005

Response by poster: onalark: I've read parts of TAOUP and How to Become a Hacker, and of course Cathedral/Bazaar. Does he have an essay that specifically deals with joining an open source project?

I have technical experience from years of commercial development, but I'm looking for some advice for joining open source projects.
posted by jsonic at 7:34 PM on November 15, 2005

Because you wanted some code that would do something, and the simplest thing to do was to write it yourself (possibly using someone else's code as a base). It's all about scratching an itch.
posted by orthogonality at 7:47 PM on November 15, 2005

Bug wrangling and patch checking/submitting happen to go hand in hand, and is probably the most straightforward and direct way to get involved in actual development. Also check out this new book (readable for free online) for lots of cultural insight.
posted by Firas at 7:50 PM on November 15, 2005

I started open-realty and got it moving along, although I'm no longer active in that world. Basically what happenned was this -- my landlord needed a way to list properties online and I, in need of both money off my rent and an excuse to learn that crazy php thing, decided that a real estate website system would be a good idea. (I was out of work at the time and trying to figure out what to do next... and being a developer sounded pretty sweet.)

Anyway, once it was done, I didn't really have any need to keep the code secret... and it just grew from there.

As for how to get into an existing project, I'd imagine it'd depend on the project. Do you have a particular area in mind?
posted by ph00dz at 7:53 PM on November 15, 2005

On every project I've ever contributed to (and I've contributed to many and started very, very few) I started off by using it and wishing it worked differently somehow, then scratched my own itch and submitted the change in case they wanted it, and then went from there.
posted by mendel at 7:55 PM on November 15, 2005

What Firas said, and what you've probably read from aforementioned ESR works--start at the bottom and work in from there. At least in my, very very limited, experience. I've been a fairly heavy "open sores" (oh, the wit!) user for a good 5 years now, during which time I have also been a programmer, sysadmin and CS student.

In the past few months I have actually started contributing minor bugfixes to a young open-source project. This is largely because I'm using it for my actual job (e.g. fixing its bugs are crucial for completing my paid work), instead of as a hobby, and because the project is new enough (publicly; Django has been in use internally at LWJ for two+ years in some form) and I'm on a branch, there are still bugs left which I am capable of finding and fixing myself without knowing the internals super well.

In addition to this, I am a regular on the IRC channel for the project and occasionally respond to posts on the mailing list, and have tentative plans to aid in a collaborative project using the framework. All of this combined really makes me feel like a part of the development community, albeit a minor one, and I'm positive that it will aid my growth as a developer in general and as a contributor to open source specifically.

So, going back to the top of my post--judging by this recent experience, it's very easy for me to believe that many/most OSS devs get their start in such a fashion :)
posted by cyrusdogstar at 8:02 PM on November 15, 2005

Test the waters before jumping in with both feet; you will find that some maintainers of open source software don't have enough time to do the job properly, prefer to do all the work themselves, are control freaks, etc. Submit smallish patches and see whether they actually get merged. To avoid wasting your own time, don't work on any large patches without first communicating with the maintainer to see if he/she would have any interest in your work.

If you're starting your own project, begin with the expectation that you're going to do everything yourself... because the reality is that this is quite likely. If you're hoping for others to pitch in, make it easy for them to branch off your code and run with it: use a distributed version control system (something like GNU Arch, Darcs, or Mercurial).
posted by Galvatron at 8:04 PM on November 15, 2005

Sourceforge has a Help Wanted page where projects list positions that they need people for. Most of the time these are established products with a core group of people, perfect for getting your feet wet with.

Find a project with a good roadmap, send a few emails - before you know it, you'll wonder how you got along without it.
posted by unixrat at 8:55 PM on November 15, 2005

It has been said before but I had a specific application that I wanted which no-one else had done. So I went ahead and wrote it.

Having said that, it is worth pointing out that unless your project gets very big and popular you could end up being the sole developer and bug fixer. All of my projects are mature (have been running for more than 2 years) and I get very little to no offers of help despite the fact I know a lot of people use them.

One project had 4 patches submitted by 4 different people over the space of 4 years (of which 1 totally broke other parts of the application) and I consider that to be the most contributed to!
posted by mr_silver at 6:09 AM on November 16, 2005

one thing to keep in mind is to be patient (but persistent). the pace of collaborative open-source development is much different than that of commercial software development. you may start sending in patches and it will turn out that its in a specific area where none of the active developers are focused, so it will take time for them to engage with your interest.

to answer the actual question, i got involved in open source by lurking on the mailing lists for projects i was interested in (because i was using or wanted to use the project), and then eventually stepped in to help where i saw a need.

producing open source software by karl fogel is a great book on the human side of open source development. you can read it online, and i highly recommend it.
posted by jimw at 7:30 AM on November 16, 2005

There is lots of ways to participate. Joing the mailing lists and answering questions, writing docs and tutorials are always apreciated. Advocating for the product within your professional sphere of influence is also a way to contribute.

Other than that, scratch your own itches or fix typos or watch for common requests/bugs. Follow the advice above to start slowly because you never know with most projects on how your patches will be accepted.
posted by mmascolino at 8:58 AM on November 16, 2005