That really depends on which direction you want to take. Web? Userinterfaces? Database? Games? Image Magicking? Running your own webserver without your boss knowing?

Well, if it's building a webserver completly in Perl, i certainly could use some help in Maplat ;-)

Here are some questions most project maintainers will ask you. Don't be afraid to answer them (and really be honest, you are answering for yourself as well as for the maintainer...). They are not designed to weed you out, they just help the project maintainer assign you (ever growing) tasks that
a) you can handle and
b) are usefull to the project and
c) make sure everyone has a lot of fun doing it and
d) give you the appropriate help in getting you started without wasting your time explaining stuff you already know.

• What would be your favourite assignment (Programming, documentation, public relations, user support, graphics, sound, videos, hold conference talks, ...?)
• What would you have accomplished in, let's say one or two years? Both for the project and for yourself in relation to the project
• How much time do you plan on spending on the project?
• How much projects have you done so far (and which one are they)
• Worked on open source projects before?
• How about source code managment software (git, mercurial, subversion, ...?
• Ever worked with a database before?
• What is your prefered way of communication?
• Which timezone are you in?
• How will you react when one of your patches is not accepted?
• Does the project actually have problems that you want to work on in your spare time?

When joining a project, you should also think of the size of the team as well as its structure.

On projects with a big team you can probably pick out a very small problem, work on that under supervision, "work your way up" and specialize in a certain area.

Smaller projects (like Maplat) where there is a very small core team (...me, to be exact) are much more demanding, since every team member should learn a much broader spectrum of tasks over time. Note: I didn't say "has to know" but "should learn". On the other hand, in a smaller team there is much less change any of your contribution gets rejected - simply because there is less chance that someone else has come up with a better solution. Although, in a smaller team, the project maintainer(s) probably have much more time to look at your code and ask you to fix that glaring bug before the patch gets commited.

Also, take a look at the projects "political" structure. Is it democratically organized where major decisions are voted on? Or is the project run by one or more maintainer(s) (aka the "core team") and he/she/they decide what's gonna happen or if the patch gets accepted? In my opinion, both are valid ways to go - it just depends on the circumstances.

So, at least in my humble opinion, "cool" is just a minor decision factor when joining (or creating) a project. Of course the ability to brag that my somethingorother runs on thousands of computers, shuffles millions of dollars worth of stuff around or is used by n Fortune-500 companies is certainly cool.

But even if the project you are currently working on only runs on like 5 completly unimportant laptops and just reminds coworkers to wake up and go to their not-so-well-earned lunchbreak... as long as your having fun writing and supporting that software, you choose the right project.