Weak communities and strong forks
The fork is very valuable to customers when, as in OpenOffice, its community can't sustain dissension.
Proprietary vendors sometimes point to the possibility of open-source fragmentation as one of its great weaknesses believing, as they do, that the vendor should always control its own destiny. What such vendors fail to see is that a community's right to fork a project is actually its greatest strength. The fork is the community's most valuable tool for ensuring the ongoing health of the project.
OpenOffice.org is feeling this now, as a cumbersome community process has led prominent members of the OpenOffice community to lay down the law (er...the fork) and declare independence, as Kohei Yoshida does:
If Sun insists on rewriting all the work I've already done just to ensure that they own all the code in OO.o, even though it is legally permissible to integrate my code under a pure LGPL license as an external component, then perhaps I need to re-think my relationship with the project. Because that would be a clear sign that the goal of this project is no longer to work with community developers (i.e. those who contribute code, not talk) and create a vibrant open-source project where contributors feel they are making a difference, but to take advantage of free labor to further the corporate goal of Sun Microsystems, by protecting vigorously Sun's total ownership of the code base as well as the development process in their entirety.
Michael Meeks insists that he doesn't want to fork OpenOffice, but the OpenOffice will need to seriously change in order to retain valuable developers like Meeks, Yoshida, and others. A community that has the license of a community but not the processes and collaboration of a community is destined to fork (as Compiere learned when it gave way to Adempiere).
This is one of the great things about open source: if licensed properly, code is never truly 100% owned by any particular vendor, even if they own the baseline copyrights for it. Code is where the community is. With a proprietary vendor, community is mostly a sham, window dressing around the periphery of a product to help drive more value for the vendor but no freedom from the vendor. Every road leads to the vendor, not away from it.
Who cares? Well, I met with the CIO of one of the world's largest law firms yesterday in New York, and he told me about how one of his favorite (proprietary) vendors fell on hard times, and how he was trapped by its insolvency: he couldn't get the code out of the company, and so now has to replace the product. A community around that same code, but licensed under and open-source license, would have helped. It wouldn't be a panacea, perhaps, but it would have offered other, robust options besides to dump the code.
In the case of OpenOffice and other projects that span multiple companies, I believe Eclipse offers the right way to build a community. For the good of OpenOffice and, hence, for its own good, Sun should set OpenOffice free. Let a community manage it, a community that includes Sun as a valued contributor.