If you're following an Open Source project and would like to contribute code changes, what will you need to do?
I would spend time getting to know the people first. Usually they have a IRC chatroom where everyone idles. Spend sometime getting to know the people, study the code, review the documentation, then if you feel like you are a correct fit for the project, start contributing to bug patches. Don't try to add new features at first. They won't generally be accepted.
Also watch this google tech talk about How To Protect Your Open Source Project from Poisonous People. It will teach you what not to do.
The best way to do this is introduce yourself like this "Hi, Here's a bug/feature and here's a patch that fixes/implements it."
I'm on a couple of open source projects, and there are lots of people with the best intentions to help but who never actually do anything, so if you show up with working code you will be considered much more valuable.
As previous posters have said, it's a matter for the project. You will find that some are more open to change than others. From a mechanical perspective, you will need to see if they use SVN (for example on google code) or CVS (for example on sourceforge) and determine if they use patch or some other method.
A good example of the sort of procedure you might need to employ can be seen on the gimp site: http://www.gimp.org/bugs/howtos/submit-patch.html
Note their use of Bugzilla, patch and CVS
As the creator of several open source projects, I'm on the other side of things in that I'm trying to get contributors. Here's what I would say:
Things like this used to be simple.
There was a mailing list for users and one for developers. If you see a problem and can fix it fix it and then run Larry Wall's Patch and send the resulting patch to the devs list with a quick explanation of what it does. Generally a dev with write access to the CVS (or in the real old days whose floppy the project resided on ;) ) would check things over and if your patch does what it says on the tin and doesn't break anything else it gets into the source tree proper.
These days there are many, many more projects using open development and lots of them are run by people who have never run a software project before let alone an open sourced one so things can be more tricky. Generally mailing a patch to someone doing lots of dev in the right area of the project gets the right eyes looking at it quickly even today. A browse of the online repository will tell you the folks who do the work rather than those who get their names on the front page of the web site, contact those guys first :)
A couple of other things to keep in mind:
Be certain that you actually own the code you want to contribute back, and not your employer or the client you made the modifications for. Check your employment agreement or service agreement if there's a possibility you're in such a situation.
Investigate whether there's an intellectual property assignment process that the developers prefer contributors go through. These days many Open Source projects have such assignments, so that all rights to the code in the project can be owned by the project itself and/or its sponsor.
Both of these are important when it comes to protecting yourself, the project, and anyone who wants to use or build on the project downstream from claims related to the code you wrote.
If you're looking for ways to get involved on a smaller scale (maybe to work your way up) OpenHatch has a searchable database of bugs (sorted by language/framework) as well as a great tutorial for getting started.
Another way to start is CodeTriage which has GitHub repos looking for help fixing open issues that are also organized by language.
The first thing you should do is contact the main people who run the open source project. Ask them if it is ok to contribute to the code and go from there.
Simply writing your improved code and then giving it to them may result in your code being rejected.
It depends on the project, how and where it is hosted. The best thing is to find a contact and email them or see if there is a developers mailing list.
Get chatting in IRC or browse through the newsgroups if they have one. make yourself known. You may need to submit patches to a newsgroup before you are given an account to submit yourself.
Get familiar with coding standards, patch types (e.g. unified diff) and checkout a copy of their CVS or SVN if they allow anonymous access.
Licensed under cc by-sa 3.0 with attribution required.