blm: Hi, I couldn't find your email at your homepage (which is apparently non-existant, looking too much default ;), so I hope you will read this through the recentlog or so. And this could be interesting for other people as well.

You say that noone wants you in their project, but that's not how most free software projects work (at least the bazaar-like ones, and I suggest you to prefer those especially when taking off). You do not ask people to let you join their team. You join it and integrate to it smoothly by sending patches. Most projects are based on meritocracy - your virtual "position" in the virtual team is based on your merit for the project. More you bring in, the more credit you get and the more people listen to you.

So, you do not look for projects with team willing to accept you. You look for projects which are exceptionally interesting for you, which give you some motivation for working on them (be it ideological, fascinating technically or scratching own itch).

From these, you choose those where you have clear idea what to contribute and of course you choose projects which aren't technically over your head, be it code complexity, insane coding style, being too low-level or the code is simply too big for you (it takes too long to update, compile or grep on your machine). But do not be too afraid; of course when you are newbie Perl coder you do not start by hacking Perl6 internals, but do not be afraid to peek into Mason. Remember, you get from the newbie level only by experience and hacking someone else's code is often much more valuable than coding something from scratch.

Actually, often the best way to start is to fix some easy bug. Do not get afraid by looking at the code. It could grin at you and make obscene remarks, but it can't harm you. It is laid on the canvas of your screen, waiting to be read, understood, grasped and touched by your fine coding hand. It is too big and takes too long to understand? Keep yourself focused.

First, be sure you skim over the documentation, both user and dev (if there is any). Then, you can look around briefly, but do not try to read everything, just try to see how is the code generally organized and how the grand scheme of things looks like; this step is optional. And then, do not look left, do not look right, look ahead and stay focused. Try to find the exact location of the code you will need to work on - grep the sources. Grep for the irritating error messages, grep for likely related keywords, patiently go through the results and identify the victim. Then look what causes it - be sure you at least generally grasp what the routine does (do not be afraid to look at the functions it calls, just do not descend too deep; grep - or better, use ctags), grep for the callers and work straightly towards the fix, not spending too much time on the non-involved code which is just distracting you. So, the synonym for getting oriented in the codebase and understanding the code is <kbd>grep</kbd>. You get used to grepping and the code holds no mystery to you.

So, you fix the bug (ok, we skipped a lot now, but that's already up to you; I told you to find something easy ;). Now you make the patch (google it if you don't know how to make a patch), the devs will prefer you to do that against the very latest version, preferrably from their CVS or SVN or whatever are they using; but usually, patch against the latest release will do too, if you are too afraid. So, you submit the patch and wait until it gets integrated. Do not be afraid to take the criticism; learn from it, absorb the conventions used by the project, be sure to look how they actually changed the patch before integrating it. Sometimes, the patch gets ignored; you either don't care and let it stay forever in the mailing list archives, googlable for anyone, or you care and push it; just do not push too hard, resent it once per week or so and eventually someone will at least tell you what's wrong. Again, absorb the criticism, adapt yourself and your patch. You don't like the way the project operates? First work your way up with the patches, you either see why is it good for the project or chagne it. Or, if you really think they are stupid, you care enough, your contribution is big, and the project is small, you can fork.

So, that's how it usually works. To sum it up - you choose the project which is exceptionally interesting for you and not over your head, and start by doing some simple patch. When understanding the codebase, grep is your best friend, and you focus only on the bit of codebase relevant to you. When submitting the patch, you learn from the criticism and do not get turned away by absence of a warm and enthusiastic response.