On forking and contributor agreements
Forks, and threats of forks, are natural parts of the open source paradigm. Since, by definition, anyone can get the source code and redistribute their own version of the code, one might wonder why forks don't happen more often. One big reason is that the free/open source model requires a community to function well. "It takes a village," is nowhere more true than open source. And, communities don't just spring up overnight. They gradually build and gather momentum and strength over time.
For this and other reasons, forks generally don't happen unless the participants are highly motivated. Maybe they don't like the way the project is heading, or maybe they think they can do a better job writing the code or setting the priorities of the project (project governance, licensing, etc.). Sometimes forks go nowhere, sometimes the two versions get merged back together later, and occasionally the forked version becomes the de-facto "official" version while the original withers away. Natural selection weeds out the winners from the losers in the competition for developer mindshare and end users. It's messy and inefficient, but to paraphrase Winston Churchill, "it may be the worst system except all the other systems that have been tried from time to time".
As I've mentioned before, contributor agreements give the project stewards considerable leeway in deciding on which license to use when they distribute the software. Without a central copyright holder (or co-holder) it's very difficult to change the license, for example to move from LGPLv2 to LGPLv3.
On the other hand, a central authority has what some might consider to be an unfair advantage under some licenses such as GPL. They can make proprietary versions (like Star Office), but others cannot. Thus they're in a unique position to satisfy the desire of many customers (esp. the ones with deep pockets) that prefer the perceived safety of proprietary licenses and don't mind paying for it.
Non-proprietary developers might find this hard to understand, but having worked on both sides of the fence I've seen it in action. Take my next-door neighbor for example. He's a VP at a major pharmaceutical company, and we've had many conversations about open source over the years. His company is very reluctant to use free and open source because of stringent validation requirements that their tools have to pass. But if you were to wrap up that same code in a proprietary solution, validate it, stand behind it, support it, and charge big bucks for it (sometimes millions), they wouldn't blink an eye.
When an extremely non-permissive copy-left license like GPL or, to a lesser extent, LGPL, is involved, contributor agreements are almost necessary to play in this space. Sure, there are exceptions (*cough* Linux *cough*) but this hybrid model seems to me to be a nice bridge between the pure-proprietary mode these big software vendors have operated under in the past and the purely free and open modes of the utopian future. Especially if you're lucky enough to be the holder of that copyright and the steward of that project.
If you're not so lucky and you find yourself a competitor to the steward (for example Novell or IBM vs. Sun) you have a harder decision to make. Do you go to all the trouble of making your own version of the software, either a fork or a complete rewrite (ala Harmony) just to wrest control from the current steward? You better have a darned good reason, and be willing to stick with it for the long haul. Right now the dispute over one minor component of Open Office (the author didn't want to sign the contributor agreement) does not seem to rise to that level.