Here are a few things I've done with Leiningen, my Clojure build tool:

* Start "low-hanging fruit" threads after every release explaining simple ways people can contribute.

* Create a HACKING guide describing the overall architecture and flow of the project. Include style guidelines and instructions for submitting patches.

* Give people commit rights as soon as possible. I've adopted the "one accepted patch, and you're good" policy from the Rubinius project. Yes, this means unqualified people will have the power to make ill-informed commits directly. But in practice people tend to behave when you give them responsibility. Evan, the Rubinius lead, has had to perform less than ten reverts in the three years he's used the policy.

I've been a Fedora Project contributor for about two years and it's been great. They have a lot of very different ways of contributing and a lot of different projects.

I contribute to the Infrastructure team; almost all of Fedora's infrastructure is built and maintained by the Fedora community. There are a lot of apps, APIs and they all communicate with one another: build service, accounts system, updates management, package database etc. Most of them are python TurboGears apps.

I'm also a package maintainer and that's another great way to learn how different open source projects work and interact with upstreams. Being a package maintainer is a lot more fun and challenging than it would appear. It's also a great way to find out other projects to contribute to.

There's a lot of information about contributing on this page: http://fedoraproject.org/wiki/Join and you can feel free to ask me more here or in private.

Before contributing, check how the developer team reacted to patches in the past -- there are teams that tend to ignore them.

Most often developers will happily help you if you have specific questions about the code.

Start with small patches or isolated modules that don't take the core developers too long to review and adapt to their "style".

Adhere to the project's coding style.

In any case, one bit of advice that I'd like to throw out there that isn't usually suggested: Follow up on the patch. After sending it in, check up on it. Make sure the folks behind the project are happy with it (else it might sit and gather bitrot while waiting for someone to fix it up). If/when it is committed, look the commit over. Is it an exact commit, or did the developer who committed it modify it somehow (formatting, to use a different method, etc)?

This way, if (or likely, "when," if you're serious about this) you submit a second patch, it'll be slightly better -- slightly more likely to be committed, slightly less effort for the dev to review, etc.

This is very important. If you're a systems/C hacker then my recommendations will be a lot different than RoR or Python.

I have minor patches in a lot of different projects so I can give you a feel for which ones are beginner friendly (good coding style, maybe some documentation, friendly people) and which ones may be a bit more of a chore.

If you got on the Tahoe news group or IRC and said "I would like to contribute to the project" (after reading up about what it does), someone would point you in the right direction. I imagine that is true of most mid-sized open source projects.

1. I stumbled upon the project pre 1.0, loved it's ideas, but my javascript wasn't good.

2. I checked out the code and loved the style.

3. I started hanging around in IRC where the core developers chatted about decisions and problems.

4. I read the source code and when I wasn't sure why some code was like it was, I asked in the channel. Either someone of the team explained why it's that way, or committed my minor suggestion.

5. That way I learned more and more about the language and the project. My suggestions became better. I loved to see my suggestions being picked up and used in the wild.

6. Eventually I got commit rights (though that wasn't important to me)

My advice is to just go for it. Join the IRC room, talk with the people. Help with bugs or documentation. It's easier to get involved than you might think, there are never enough people working on such projects.

You will be welcomed by the community!

(Disclaimer: I happen to contribute to Colloquy. In this case, it just means that I'd be delighted to look over any patches that anyone has. :)

Join the forum related to your Linux/BSD distro of choice and check out the project page and see what needs help and what needs work. See if there's anything you're interested in already and go with that. If not, a good project to join would be bug tracking; for an example see the corresponding project from Fedora:

https://fedoraproject.org/wiki/BugZappers

Or Debian:

http://www.debian.org/Bugs/

Follow the directions, get your feet wet and eventually, if not from the very start, ask for a mentor already in the project and ask questions of them. Follow the project #IRC for a while and you'll get a good feel for where the work is needed. If you graduate into more technically challenging projects while at the same time being beneficial to the project, you will surely learn a lot and hopefully gain some invaluable experience.

My first open source project was a PHP script called "DBMailer" that I wrote when I had been programming for only a few weeks. I'm sometimes embarrassed that it's still floating around the internet with my name on it, but I learned a lot from the feedback I got from it at the time.

I wrote a blog post a while back with some do's and don't's for both contributors and maintainers, maybe you'll find it interesting:

http://njclarke.com/posts/how-to-do-open-source.html

Good luck, and stay enthusiastic!

Havoc Pennington (GNOME guy) wrote "Working on Free Software" in 1999 to explain why. In my opinion every word there is still valid today, with possible exception of CVS.

http://ometer.com/hacking.html

And you see, it was called "free software" back then, not "open source project". Sigh.

I think there's a lot to be said for practicing your skills on your own so that you have a reasonable level of practice before trying to contribute to other projects.

http://openhatch.org/

repeat

http://railscasts.com/episodes/50-contributing-to-rails

http://railscasts.com/episodes/113-contributing-to-rails-wit...

Second step is to use it, if you havent used it already. You wont be able to contribute to a software which you havent even used by now.

And when you use software, you will have little ideas to improve it. Or little bugs that annoy you.

Third step is diving into the source code, understanding the codebase and actually doing the changes. At this step, you might need to communicate the authors. This is an imporant part.

You can usually find developers on mailing lists and/or irc channels. Use these tools to contact authors and ask for their help. Dont be afraid, you are not supposed to do it all by yourself without asking anything. On the conterary, asking developers assures that you're doing it the right way. However, you should ask smart question. This one makes differrence. (Read Eric Reymond's article about this.)

Last step, is giving the patch to authors. if the project uses a proper SCM, you will be able to produce a patch easily. Send the patch to authors and wait for their response. Some projects have reviewboards which you can post your patch there and wait for their review.

Now, depending on the project, the path you go may differ. Dont bug developers too much. Dont hurry. Be friendly with them. Be Patience.

Also, this website is created for this exact purpose: http://openhatch.com

(Some projects have JuniorJobs, which are easy tasks for newcomers to start contributing, if you havent already found 'what' you want to do)

Once you find a project you're interested in, find them on irc. Don't be too pushy, hang out and try to pick up on the dynamic. That doesn't mean you should be silent, just don't be annoying.

A great way to catch up on an existing project (the earlier you get on board btw, the easier it will be to start) is to start helping out with testing. A lot of programmers don't enjoy writing automated tests (which they should be writing first anyways), so that stuff usually gets left to someone to clean up. An ancillary benefit of which is that you can learn a ton about a project by adding tests.

The only other thing you'll probably need some experience with kind of across the board is version control. Experiment a little with git/svn so that you aren't intimidated by submitting patches (version control can seem intimidating before you've worked with it, but most of the time it's pretty basic).

Start by installing Drupal, then learning how to checkout code from the CVS repository, then how to apply patches, how to review patches, and finally you can apply for CVS access to contribute back your own code.

I'd be happy to mentor you if you want to give it a shot.

Even if you can't solve the issue, just reproducing it and reporting your findings can be very helpful! Also make sure you read any contribution guidelines for the project if available.

You will also need version control-fu, whether it's Git, Mercurial or SVN or whatever the project is using. You need to be able to use it, at least the basics to make a patch.

Most importantly have fun and be nice! :)

- checkout the code from GitHub http://github.com/beza1e1/later

- use the "later" executable itself to find out, what issues are unresolved (e.g. "Web frontend")

- get familiar with the code base and especially the plugin architecture

- write some code (with whatever IDE or editor you like)

- send me a message, when you have something to look at

- after some reviewing (and probably changing) we can merge your code into the mainline

- Congratulations!

Look for projects that make it easy to contribute and have reasonable documentation.

Being always on the lookout for great people, I'll toss our project contributor's page here to see if you are interested (hehe) and show what I mean http://wiki.amahi.org/index.php/Contribute :)

http://thinkrelevance.com/blog/2008/05/23/refactotum-overvie...

What open source tools are you using yourself? Have you ever found some bugs in some of them? Or missed some feature? Then this might be a good place where you could start: Just implement that feature or fix the bug. If you don't really know how to provide your patch to them or where to start: Just speak with their devs; in most cases, they will be glad to help you out.

Some other questions you should maybe ask yourself:

Do you prefer to work in a very big project (KDE or so) or would you prefer to work in a very small one? You will find OSS projects of all sizes, even often just of a single guy/girl where you could ask to join him/her. The experience you will get might be quite different depending on the size of the project. I think, but that is also hard to tell, that it maybe might be more fun in a smaller team (because then you know everybody and you just need less bureaucracy). You will also find quite a lot of dead projects, i.e. projects where there is no active developer anymore. The old maintainers of such projects will be very happy if you tell them that you want to revitalize that project.

What type of project should it be? Some tool? A webbrowser (Chromium, Firefox)? A game? A whole Linux distribution (Debian, Ubuntu, Gentoo, ...)? A window manager (KDE, Gnome, E17, ...)? Depending on that, the programming experience you will get will also differ quite a lot. I have found that developing a game will often lead to the most wide range of experience and knowledge. (I have written an article about that: http://www.openlierox.net/wiki/index.php/Why_game_developmen... )

Where I am at it: I am one of the leads of the OpenLieroX project and of course, we can also need some help. :) We are a quite small team (3 devs basically) and have a quite huge codebase right now (about 300k loc -- could need some cleanup, though). Just for the purpose to tell people where to start, we also have a small article: http://www.openlierox.net/wiki/index.php/Contribute_to_the_s...

In that article, I also describe some further ways how you could get more experience at coding. Another way might be to start your own project from scratch, maybe together with some friends (or ask here or elsewhere for some strangers who might join you). However, this might be a quite difficult taks. Often, you are overestimating what you can do and the project will become quite big and often stay unfinished forever.

OpenLieroX started as an almost dead project. It was closed source in the beginning (called LieroX), then the original developer (just a single guy) stopped the development. And he did the right thing: Before letting the project die, he released the source code. And there is where OpenLieroX started. First there were two separated projects, one by me, one by another guy but once we have heard about each other, we also did the right thing and merged to one single new project.

In practical terms, you can just start hacking on the code yourself which will normally be available from a version control system somewhere, but when you've made changes you'll need to submit patches for consideration to the project maintainers at first. If you're unsure what format to use, just email to ask. For projects hosted on github you can just fork the project there which will make it technically easier to get patches back into the main branch. As you build up trust with others involved in the project you'll be able to get commit access to the project repository and make changes yourself.

As for IDEs etc, each project will have conventions and project metadata (makefiles, project indices etc.) suitable for a specific setup, so figure this out when you've picked a project and work with what's already in place as much as possible.

[edit] One other thing: it will be really hard to get started - getting up to speed with how a new piece of software works is difficult at the best of times and most projects aren't designed to make this easy. Persevere, as once you've got to grips with layout and conventions and got to know the other contributors things will become much easier.