The way it works is, projects have n maintainers with commit privileges to the repository. Contributors who are not part of the core development team submit patches to one of the maintainers, who will review it and either reject it (and probably reply back with a reason), or eventually commit it. Eventually, you may be offered commit privileges, if the maintainers consider you could be of more use to the project this way, although I think this is unusual. For example, the Linux kernel has probably hundreds of contributors but a handful of maintainers.
We were looking into making one in the Lounge section. There's just a few kinks I wanted to get out of the way and wanted feedback on but there's not a lot to go on. The site administrator also isn't involved so it really wouldn't be much different than any other open source project that you participate in.
I think you should first read on open source licenses so that you would know which path you are to take. Some licenses do not allow earning of what they have already established while other would permit you to repackage the software and sell it as your own, but with reference to cite them as base developers.
There are a lot of projects like that on the internet and sourceforge is a pretty good site to look at.
The easiest way to get involved in an open source project is to just look on your computer and pick an open source program that you use a lot, and get involved in that. That way you feel that extra bit of "awwwwww yeaaaaah" when you actually get to use something that you've implemented.
Then just email the maintainers and ask them if there's any small tasks that need to be taken care of but they don't have the time to do it.
Most projects are seriously under-involved and there's lots of usefull things that you can do, like unit-testing, writing documentation, small bug patching. Some of it can be tedious, but you got to start somewhere, and arguably, those tedious jobs are some of the most important ones in software development (albeit, much less exciting then OMG I IMPLEMENTED FEATURE XXX).
I've been adding a feature to an OCR (optical character recognition) program so that it can download images from the Internet rather than just using local files (but it's transparent, the user doesn't have to tell the program that they're passing a URL).
When I've done that I plan to modify the GNOME screen capture program so that you can enter "%y-%m-%d %h:%M:%s.jpg" as a filename and the file gets saved as "2011-06-08 15:19:30.jpg" (that would be the time the image was captured, not the time that the file was saved). I looked at the code, though, and it was quite inelegant in places, so I might just write my own instead...
I decided to do the first one by going on SourceForge, looking through all the projects, seeing one that was interesting (OCR has interested me for a while), thinking about what could be done to improve it, and then doing that. The hardest part really is adapting to the code already written, and copying the style of the original programmer(s). The second one arose from me thinking "I wonder if you can insert the time and date in the filename", and, upon discovering that you can't, thinking "That should definitely be a feature" and finally "I should add it." Another way you could find contributions to make would be to download the source code of some projects that interest you (one of my interests, for example, is pretty much anything closely hardware-related; so I would look at partition editors, overclocking tools, hardware drivers and operating systems). Then, look for a list of known bugs and try to fix them. Or open the source code in a text editor and look for things like "TODO" or "FIXME". A "TODO" indicates that the programmer intends to change something, but is too lazy to do it right now (be honest, that's the real reason ;) ). A "FIXME" is pretty much the same, except it's when something is actually broken as apposed to just being an imperfect way of doing something.