Ask YC: Getting Involved in Open Source
I know a lot of people say that getting involved in an open source project is a great way to pick up some useful skills from some smart people, but how exactly does one get involved in something? (i.e. how did you start out?)
11 comments
Depends what you're interests are. Documentation is usually poor to non-existent in most open source projects (at least initially). I would argue that good user documentation at an early stage can mean the difference between a successful project and a ho-hum project. I wrote the first Asterisk Management Portal Installation Guide (AMP was a precursor to FreePBX) and I can tell you that that guide made a huge difference.
If you like to code, submit patches. Your patches will be scrutinized but that will make you a better programmer. Eventually you might get contributor status if your patches/code is solid.
If you like to help people there are always novices that will ask the questions that people who have been in the project for awhile will ignore because they've heard them a million times (because there's no good documentation).
Cheers
If you like to code, submit patches. Your patches will be scrutinized but that will make you a better programmer. Eventually you might get contributor status if your patches/code is solid.
If you like to help people there are always novices that will ask the questions that people who have been in the project for awhile will ignore because they've heard them a million times (because there's no good documentation).
Cheers
Pick something you use and:
- Subscribe to the relevant development mailing lists
- Start using the development version of the software (from CVS, SVN, Git, whatever)
- Subscribe to any relevant community newsfeeds (planets, news sites)
If you're using the development version of software, you'll invariably hit horribly annoying bugs. Dig in, find the fix, generate a diff and mail it to the development mailing list. In the odd case of not stumbling into annoying bugs, the bugtracker will have a long list waiting for you. Rinse, wash, repeat.
- Subscribe to the relevant development mailing lists
- Start using the development version of the software (from CVS, SVN, Git, whatever)
- Subscribe to any relevant community newsfeeds (planets, news sites)
If you're using the development version of software, you'll invariably hit horribly annoying bugs. Dig in, find the fix, generate a diff and mail it to the development mailing list. In the odd case of not stumbling into annoying bugs, the bugtracker will have a long list waiting for you. Rinse, wash, repeat.
This is all you need to know. There are a few projects out there that are ridiculously tight-knit and don't readily welcome newcomers to the developer team, but they are rare--if you bring the code, the team will generally welcome you. Bigger projects are more likely to have people around of varying skill levels to help you get up to speed--Apache, for example, has developers at all levels working on all sorts of projects within the whole...you will find people willing to help you get your feet wet. Smaller projects might have the labor so tightly focused on one or two part-time developers that they are unwilling to take time out to help a newbie. This is probably counter-productive in the long-term, but one must realize that a lot of times folks come into projects, asking lots of development questions, primarily for one specific niche feature...they wave their hands a lot, and make a nuisance of themselves until that one feature is finished (either by them or, more likely, by someone else) and then they're gone, never to be seen again. Bigger projects have enough people willing to take the risk that you're going to come and go and the time they spent helping you get up to speed will be lost.
However, bringing the code first (even small bugfixes) insures that everybody knows you're in it because you want to make the project better.
However, bringing the code first (even small bugfixes) insures that everybody knows you're in it because you want to make the project better.
This is pretty spot-on. Find something you like to use or are interested in. If you want to get involved in coding, you should start with some minor bug fixes. For instance, Django has a separate list of "easy improvements" to encourage newbies to get involved (http://code.djangoproject.com/wiki/LittleEasyImprovements). You generally should not try and go for a major bug fix right off the bat, because if your code does not follow the convention for that project or the direction in which it is going, your patch will probably be rejected.
Coding aside, most open source projects are also hurting for things like proper documentation, testing on multiple platforms, plugins, and a good-looking accessible website, so you should just find the intersection of your skills and interests with what the project lacks and go on from there.
Coding aside, most open source projects are also hurting for things like proper documentation, testing on multiple platforms, plugins, and a good-looking accessible website, so you should just find the intersection of your skills and interests with what the project lacks and go on from there.
You just gotta do it.
Unfortunately, often the barrier to entry is high, because communication is poor. Information tends to flow through a small group, and if you're not in that group, you're out of the loop. This stopped me from contributing to Firefox for years, and my college roommate is a Mozilla employee.
But recently, I finally just got something done. Push hard, ask questions. People are often glad to have help, but pleas for general help go unheard. Direct communication is best. The guy in IRC asking questions will get ignored, but the direct e-mail, often, doesn't.
Best of luck.
Unfortunately, often the barrier to entry is high, because communication is poor. Information tends to flow through a small group, and if you're not in that group, you're out of the loop. This stopped me from contributing to Firefox for years, and my college roommate is a Mozilla employee.
But recently, I finally just got something done. Push hard, ask questions. People are often glad to have help, but pleas for general help go unheard. Direct communication is best. The guy in IRC asking questions will get ignored, but the direct e-mail, often, doesn't.
Best of luck.
If you are interested in search engines you can check out our project, http://hounder.org
The project is relatively mature and stable (three years old, deployed on some high-traffic sites). We are looking to gain some community traction, so there is a lot to do besides writing code and documentation. We definitely could use some help!
The project is relatively mature and stable (three years old, deployed on some high-traffic sites). We are looking to gain some community traction, so there is a lot to do besides writing code and documentation. We definitely could use some help!
The easiest way to get involved with an open source project is to find one you like and then hit someone up to find out more.
Depending on your interests and skill set, we're always looking for help with Miro (http://getmiro.com/).
Depending on your interests and skill set, we're always looking for help with Miro (http://getmiro.com/).
1. Notice something that bothers you.
2. Fix it!
3. Profit???
I know how you feel, I had a similar question a while back: http://news.ycombinator.com/item?id=130293. Some interesting responses. Seems like Summer of Code is good way for students to get involved.
I started by releasing Perl modules that wrapped APIs that I was using. I felt like that had less friction than joining a large existing project.
hey, were going to be going open source in a few months. would love to get you involved early on. ping me: jason [at] publictivity.com