The Symphony team reviewed their IBM bug reports from Symphony and pulled out the most important ones that were already fixed in Symphony. 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".Įxpect to see a lot of bug fixes in Apache OpenOffice 4.0, especially in the area of Microsoft interoperability. Work on the "slow merge" has been ongoing since last summer, in parallel with work on Apache OpenOffice 3.4.1.
#Lotus symphony code#
But that was the point, to avoid the disruptions of a radical change in the code base. There is no 'big bang integration" where everything happens at once. 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. In the end the consensus was to go with the 2nd option, merging Symphony code into OpenOffice. 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.This would have been more disruptive to other, non-IBM, OpenOffice developers, but would have brought the distinguishing Symphony features to a release faster. 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. 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.There were good arguments for either approach, and we had a spirited discussion. Continue with the existing Apache OpenOffice 3.4 as the base and merge features from Symphony into that code.Then merge back into Symphony the code improvements that had been made in Apache OpenOffice 3.4. Make the Symphony code the new base for Apache OpenOffice.The two primary options discussed on our mailing list were: 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. (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.
#Lotus symphony software#
IBM contributed the source code for Symphony to Apache, via a Software Grant Agreement (SGA).
Last May IBM decided to end that fork and combine their development effort with the Apache OpenOffice project. Symphony was developed with technology, essentially a fork of OpenOffice. IBM Lotus Symphony is an IBM licensed derivative of OpenOffice, offered at no charge, which IBM enhanced for their customer and corporate use. Learn how the Apache OpenOffice volunteer community is doing this, and how this will benefit users of OpenOffice as well as developers who build upon OpenOffice. Interoperability, performance, accessibility improvements, as well as exciting new user interface elements are in the works.
Improvements, courtesy of IBM and their Lotus Symphony effort. The symphony is about to begin.Īpache OpenOffice will soon have some new features and other The house lights flash Please take your seats.