I found this “Ask Slashdot” question interesting: Good Ways To Join an Open Source Project? There are several ways to look at this… why is this really a question? why is this still a question? what makes you think its difficult?

But, I’ll admit, it is a question that a lot of people have. Its kind of like asking: “How do I join a club?” Simple, you just do. But, frankly, if no one is holding a “Prospective Members Sign Up Here!” sign you can get intimidated and decide not to ask, and instead just keep showing up rather than getting involved.

There are several ways I’ve seen people get involved and done myself:

1. Just be there! Whether helping answer questions in IRC or mailing lists, trying out new releases and submitting bug reports, or just being a cheerleader to encourage developers and users (this really is an important task), just being around and being engaged is important and a good way to get into the mix.
2. Find a hole and fill it. Any project has things they’d like but don’t have. More press or exposure, more feedback, more bug reports, more users, more bug fixes, more screenshots, more documentation, more people helping with support… whether its creating a better website or fixing bugs there are things that need to be done but not enough hands.
3. Solicit assistance on a dev list. Just say “I love this project, recently started using it and want to help out, what would be useful? I have skills with…” Trust me, you’ll get suggestions! If you get a “just find something and do it” response, then you know that your really needed because they don’t even have time to delegate!
4. Testing and Porting Count! One of the easiest ways to help is to build and test something on a platform thats not “supported”. Build it on Solaris or BSD or Plan9 and then report back to the developers. “Porting” sounds scary, but generally its just a matter of making a simple tweek or two, such as #ifdef’ing a header to a different location.
5. Docs docs docs! The biggest need of projects out there is documentation. Developer documentation (“Using the XYZ API”). User Documentation (“Getting Started with XYZ”). Feature specific documentation (“How to create a new YXZ in 20 minutes!”). Implementation specific documentation (“Using XYZ with PostgreSQL Support”). No one will ever turn docs away. One of the most popular “In’s” that I’ve seen people who speak other languages is to offer to translate existing docs into (some language).
6. Coding doesn’t need to be hard! Probly the easiest way to get started coding on a project is to build it, and then go back and fix all the compiler warnings. Then try a different compiler thats more verbose than GCC (such as Sun Studio) and build it with that and fix those warnings. Lots of dev’s don’t bother to use tools like lint, so run the app through lint and fix those warnings. Come into the project submitting patches as a Junior developer, if you will, taking care of little things that the primary dev team may not have time for. Trust me, developers A) want help, and B) like patches not discussions. If you can take some burden off a developer so that he can concentrate on the new features he wants rather than the nitty gritty “It doesn’t build on…” issues he’ll come to respect and depend on you.

The most important tip is this: SUCK IT UP AND JUST GET IN THERE!

The most common reason people don’t get involved is because they do not feel empowered to do so. They want to be told to do something or, at the least, to be told that if they do something it’ll be accepted. The trouble is, the developers on a project are more like you than you realize, they have jobs and families and lives and other responsibilities… the last thing they want is someone else bugging them for things, even if those things will help him out ultimately.

Here is the golden unwritten rule of Free and Open Source software development: You be given the responsibility that you take upon yourself. Most projects don’t have Project Managers (PM’s) and don’t want them. Think about the Linux kernel. If you want to get involved the right way is to do what you want and submit it to the LKML or Linus. The wrong way is to wait for something to be delegated or ask Linus how to help… you’ll, at best, get no response, and at worse, a flame of epic proportions.

In the Enlightenment project, I’ve seen people want to help out and sit in IRC every day just hanging out wondering how to get involved and never do anything. I’ve also seen people show up and say “This is neat” and then the next day take over major portions of the project without much announcement at all. Kim Woelders, for instance, hung around for a while, I saw him here and there, but he was pretty quiet. Then one day he wanted to pick up development on Enlightenment DR16. Without any big hub-bub he fixed almost all of the issues that users had complained about but no one wanted to fix (dev had all turned toward EFL and DR17), requested CVS commit access, and released the next rev of DR16. He’s been the maintainer/owner since. No fan fare, no request, he just got in there and did it.

Raster once said something simple and yet profound: “If everyone just wrote 1 line of code a day where would we be?” Even if that line was a bad one! The point is, most people don’t even try. They aren’t “good enough”. The code is too difficult. They are unsure how to help or get empowered. Just do it. Create a new website for a project, host it on some $5 hosting site and then say that you did so on the list or via IRC… you might just end up the webmaster.

Lets be honest. It takes courage to get involved. It takes a leap and you might get burned… but honestly, who wants a developer/contributer who doesn’t have that kind of courage? If you can’t face the possibility of rejection your not going to last long anyway. Be secure in yourself. Look at where you want to be and realize that to make it happen you need to take that first big step, and know that once you do the second one will be a whole lot simpler. Actions speak much louder than words.

Finally, realize that most people like to comment, critique, criticize, and make suggestions than they like to create. Taking the 5 minutes to make a suggestion is easier than taking the 6 hours to create. Very few people want to own things. The first time you do anything its probly gonna suck, but once it exists your likely to get people interested in helping. The first plane sucked. The first car sucked. Do not be afraid to take that first step!