Eat your heart out nss000 
https://lwn.net/Articles/532665/
https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato
Hopefully that means we will see feature and code parity in both OpenOffice and LibreOffice soon - The current change in license allows new contributions to be swapped interchangeably between both office suites. That means I can continue using my clearly superior LibreOffice and you can use your OpenOffice. 😛
Seriously, I'd take OpenOffice over Microsoft Office anyday.

https://lwn.net/Articles/532665/
Last May, IBM announced the completion of its long-awaited contribution of the source code for its "Symphony" OpenOffice.org fork to the Apache Software Foundation. More than six months later, there is no freely-licensed version of Symphony available, and some observers, at least, see no evident signs that any such release is in the works. A look at the situation reveals gears that grind slowly indeed, leading to tension that is not helped by some unfortunate bad feelings between rival development projects.
Apache OpenOffice (AOO) and LibreOffice are both forks of the old OpenOffice.org code base. There is not always a great deal of love lost between these two projects, which, with some justification, see themselves as being in direct competition with each other. That situation got a little worse recently when de-facto AOO leader Rob Weir complained about talk in the other camp:
I'm reading FUD, from the usual misinformed suspects, saying that the "IBM donation to AOO is pure marketing fluff" and "IBM faked the donation of the Symphony code" and "IBM did not donate anything". I can certainly sympathize with leaders of communities that can only be held together by irrational fears. It is not easy to maintain that peak level of paranoia.
Rob raised the idea of putting out a corrective blog post, but the project consensus seemed to be to just let things slide. Clearly, though, the AOO developers were unhappy with how the "usual misinformed suspects" were describing their work.
The specific suspect in question is Italo Vignoli, a director of the Document Foundation and spokesperson for the LibreOffice project. His full posting can be found on the LibreOffice marketing list. His main complaint was that the Symphony code remained inaccessible to the world as a whole; IBM, he said, did not donate anything to the community at all. This claim might come as a surprise to the casual observer. A quick search turns up Apache's Symphony page; from there, getting the source is just a matter of a rather less quick 4GB checkout from a Subversion repository. Once one digs a little further, though, the situation becomes a bit less clear.
The Apache Software Foundation releases code under the Apache license; they are, indeed, rather firm on that point. The Symphony repository, though, as checked out from svn.apache.org, contains nearly 3,600 files with the following text:
* Licensed Materials - Property of IBM.
* (C) Copyright IBM Corporation 2003, 2011. All Rights Reserved.
That, of course, is an entirely non-free license header. Interestingly, over 2,000 of those files also have headers indicating that they are distributable under the GNU Lesser General Public License (version 3). These files, in other words, contain conflicting license information but neither case (proprietary or LGPLv3) is consistent with the Apache license. So it would not be entirely surprising to see a bit of confusion over what IBM has really donated.
The conflicting licenses are almost certainly an artifact of how Symphony was developed. IBM purchased the right to take the code proprietary from Sun; when IBM's code was added to existing, LGPLv3-licensed files, the new headers were added without removing the old. Since this code has all been donated to the Foundation, clearing up the confusion should just be a matter of putting in new license headers. But that has not yet happened.
What is going in here is reminiscent of the process seen when AOO first began as an Apache project. Then, too, a pile of code was donated to the Apache Software Foundation, but it did not become available under the Apache license until the first official release happened, quite some time later. In between there unfolded an obscure internal process where the Foundation examined the code, eliminated anything that it couldn't relicense or otherwise had doubts about, and meditated on the situation in general. To an outsider, the "Apache Way" can seem like a bureaucratic way indeed. It is unsurprising to see this process unfold again with a brand new massive corporate code dump.
There is an added twist this time, though. In June, the project considered two options for the handling of the Symphony code dump. One was the "slow merge" where features would be taken one-by-one from the Symphony tree; the alternative was to switch to Symphony as the new code base, then merge newer OpenOffice.org and AOO features in that direction instead. The "slow" path was chosen, and it has proved to be true to its name. Rob noted 167 bug fixes that have found their way into AOO from Symphony, but there do not appear to be any significant features that have made the move at this point.
One assumes that will change over time. The code does exist, the Foundation does have the right to relicense it, and there are developers who, in time, should be able to port the most interesting parts of it and push it through the Apache process. One might wonder why almost none of that work appears to be happening. If the project was willing to do the work to rebase entirely on top of the Symphony code, it must have thought that some significant resources were available. What are those resources doing instead?
Rob's mention of "larger pieces that will be merged in branches first" points at one possible answer: that work is being done, we just aren't allowed to see it yet. Given the way the AOO and LibreOffice projects view each other, and given that the Apache license gives LibreOffice the right to incorporate AOO code, it would not be surprising to see AOO developers working to defer the release of this code under their license for as long as possible. It would be embarrassing for LibreOffice to show up with Symphony features first, after all.
On the other side, it is not at all hard to imagine that some LibreOffice developers would be happy to embarrass AOO in just that way. Their complaint is not that IBM did not donate the code; what really makes them unhappy is that LibreOffice cannot take that code and run with it yet. It must certainly be frustrating to see useful code languish because the AOO project and the Apache Software Foundation are taking their time in getting around to putting it under the intended license. But IBM chose a channel for the release of this code that puts its ultimate fate under the control of those entities; there is little to be done to change that.
Competition between software projects is not necessarily a bad thing; it can motivate development and enable the exploration of different approaches to a problem. Thus far, it is not clear that the rivalry between AOO and LibreOffice has achieved any of that. Instead, it seems to create duplication of work and inter-project hostility. The grumbling over the Symphony source, which, meanwhile, sits unused by anybody seems like another example of that dynamic. With luck, the AOO developers will find a way to release the bulk of Symphony as free software, but one should not expect it to happen in a hurry.
https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato
Movement I: The Contribution.
IBM Lotus Symphony is an IBM licensed derivative of OpenOffice, offered at no charge, which IBM enhanced for their customer and corporate use. Symphony was developed with OpenOffice.org technology, essentially a fork of OpenOffice. Last May IBM decided to end that fork and combine their development effort with the Apache OpenOffice project. IBM contributed the source code for Symphony to Apache, via a Software Grant Agreement (SGA). (An SGA is an agreement by which a code base developed outside of Apache is contributed to Apache under specified licensing terms.) Since the areas that IBM improved Symphony are also areas of interest for OpenOffice users, and for 3rd party products based on OpenOffice, the Apache OpenOffice project was glad to receive this contribution.
Once the Symphony contribution was received and checked into the Apache OpenOffice version control, the discussion to determine the best way to use this new code. The two primary options discussed on our mailing list were:
Make the Symphony code the new base for Apache OpenOffice. Then merge back into Symphony the code improvements that had been made in Apache OpenOffice 3.4.
Continue with the existing Apache OpenOffice 3.4 as the base and merge features from Symphony into that code.
There were good arguments for either approach, and we had a spirited discussion. The main points were:
Using Symphony as the new base would have required careful review of that code base, and months of additional work to bring it up to Apache IP requirements. Essentially we would need to redo much of the work we had already done with the OpenOffice code that Oracle had contributed via their SGA. This would have been more disruptive to other, non-IBM, OpenOffice developers, but would have brought the distinguishing Symphony features to a release faster.
Merging Symphony features into OpenOffice would be less disruptive, but would be a slower path to integrating Symphony features, and would require more attention from IBM, since they know the Symphony code best.
In the end the consensus was to go with the 2nd option, merging Symphony code into OpenOffice. This brings the Symphony code, feature by feature, bug fix by bug fix, into OpenOffice, where it is integrated, tested, reviewed, etc., in smaller chunks, as it works its way toward release. Doing it this way is less flashy. There is no 'big bang integration" where everything happens at once. But that was the point, to avoid the disruptions of a radical change in the code base.
Work on the "slow merge" has been ongoing since last summer, in parallel with work on Apache OpenOffice 3.4.1. Our use of Apache Subversion facilitated this kind of parallel development, where one group focused on the 3.4.1 release in a "branch", another group of developers started to bring Symphony enhancements into the "trunk".
Movement II: Many Bug Fixes
Expect to see a lot of bug fixes in Apache OpenOffice 4.0, especially in the area of Microsoft interoperability. The Symphony team reviewed their IBM bug reports from Symphony and pulled out the most important ones that were already fixed in Symphony. They then tested Apache OpenOffice, to see which of these bugs still existed in OpenOffice. For the ones that still were in OpenOffice, they merged in the fix from Symphony. This was a very efficient approach to a targeted merge and led to many fixes, include the following so far (and we're still months away from release):
Hopefully that means we will see feature and code parity in both OpenOffice and LibreOffice soon - The current change in license allows new contributions to be swapped interchangeably between both office suites. That means I can continue using my clearly superior LibreOffice and you can use your OpenOffice. 😛
Seriously, I'd take OpenOffice over Microsoft Office anyday.
