Please understand that the FOSS world has many communities, many different standards of coding and varying philosophies. You seem to be correlating a program's license with coding standards and etiquette for participating, that isn't always the case.
Let's look at two of the biggest communities going right now, which would be the GNU Project and the Linux kernel. I'm not leaving out BSD, I'll get to that, I'm just addressing your questions in (mostly) the order that you asked them.
The GNU project, owned by the Free Software Foundation gives us a lot of stuff:
- The GNU operating system (shell, core utilities, desktop / window manager, basic productivity tools, etc)
- The GNU General public license, The Lesser GPL and the Affero GPL.
GNU has a very high set of coding standards (some say these standards are too complex), however GNU software is notorious for building and running on a variety of systems and architectures. To get a feel for how they do things, have a look at the GNU Hello, World! program. The fact that a "Hello, World!" implementation is actively maintained should tell you something.
The FSF doesn't just handle the needs of the GNU project, they are also advocates for what they feel are essential freedoms that every computer user should have. They are in the trenches of the patent wars, closely involved with the EFF and SFLC and frequently organize campaigns against technology products that they feel take essential freedoms away from computer users.
If you want to work on a GNU project, a great way to start is to go to their front page and look for some projects that need a new maintainer. Or, you could start off by fixing bugs and sending patches. Just realize that they are a very idealogical community, so take care to read about the things that they are passionate about. For instance, it is unwise to call a GNU program "Open Source" on a GNU mailing list, they much prefer the term "Free Software".
Linux is developed under the umbrella of the Linux Foundation. They give us:
- A shiny new kernel every few months
- Standards to help tie together all of the various operating systems that use the Kernel (such as the LSB)
- Outreach programs to help get Linux developers behind the proprietary iron curtain for better hardware support in the kernel
- Advocacy of open source and open standards
Unlike the FSF, The Linux Foundation is not quite what many would consider political. Yes, they are vocal regarding technical issues that face programmers these days (such as patents), but they are seldom if ever antagonistic.
Kernel development is described by kernel developers as a meritocracy. While some doubt that such a system could be real, one does need to thoroughly vet the technical decisions that they introduce in any patch. If you send in great code that follows their guidelines, your patch (or perhaps a revised version of it) will probably be accepted if it solves a real problem. A great place to start is kernel newbies. Pick up some janitorial work in whatever sub system interests you and develop a good relationship with its maintainer - then set your eyes on bigger fish if you want.
Kernel hackers prefer that you keep idealism and politics off the list, they generally see this as noise. From time to time, the FSF will propose changes to the GPL. When this happens, you might see a side bar discussion on what kernel hackers think of it.
Now, both projects use the GPL, however Linux never moved to GPL3. The FSF requires copyright assignment from all contributors, Linux does not. GPL3 was just too restrictive for kernel folk, so it was never adopted. Still, the point is - just because a project uses the GPL doesn't mean GNU standards apply.
Understanding the various OSI approved licenses and their intrinsic compatibility issues is something that everyone working seriously with Free/Open software be doing. The GNU project maintains a pretty comprehensive GPL compatibility list that highlights quirks in certain licenses that might also render them incompatible with others. The key thing to remember here is that when mixing code, even with 100% compatible licenses, the most restrictive license must prevail.
This leads us to the vibrant BSD communities, who focus on giving us well written and reliable software while attaching the least amount of restrictions. If you have ever enjoyed the security of OpenSSH - you have OpenBSD to thank.
There have been rifts between the BSD and GNU communities, because BSD code was used and improved in a GPL project, but those improvements could not be reciprocated because it would mean the BSD camp having to inherit the additional license restrictions.
Any Linux/GNU distribution is a combination of software from all camps. Just try to offer improvements back to them under the license that they prefer.
In short, proprietary companies tend to say "Sharing is evil!", BSD folks tend to say "Sharing is NOT evil!" while GNU folks tend to say "NOT sharing is evil!". It's important to realize the distinction.
Finding a place to start is as easy as finding an interesting problem to solve, within a community that best suits your personality and goals. Remember that a choice in licenses isn't always idealistic, it is also very much strategic. Take care to not make assumptions based solely on the license that any particular project is using.
