Slashdot Mirror
History of Software Forks Favors LibreOffice
jfruhlinger writes "The forking of LibreOffice from the OpenOffice.org project, followed by Oracle's donation of OpenOffice.org to the Apache Software Foundation, has been something of a bumpy road. But if history is any guide, it's the fork, LibreOffice, that might have the brighter future."
LibreOffice has already undertaken massive cleanups of OpenOffice.org code. It's pretty obvious which one will survive. Also one doesn't have a stupid TLD in the name (although the other is a bit freetard for my tastes).
I think every company that acquires an open source project could learn something from how Oracle handled openoffice.org
The uncertainty and the lack of commitment by Oracle practically forced the community to fork the project. And even after that, Oracle had a chance of do the right think and donate the name to the Open Document Foundation, but they just sat down and done nothing, LibreOffice became a strong fork, and in the end they realized an "asset" that they bought from Sun was basically worthless.
Apache will provide the LibreOffice folks with a copy of the OpenOffice code base that is under a license which removes any possible obligation they might ever have to Oracle regarding the code, unless they do something incredibly stupid (like failing to attribute or reproduce the license at all as Katzer did in Jacobsen v. Katzer). LibreOffice can choose to use that code base or not.
If we really want to lay blame, it's not just Oracle's. Sun Microsystems didn't ever achieve a viable community for OpenOffice. There were operational and technical reasons, but the one that might have been most important was the requirement to sign your copyright over to a company that might take the work private the next day, with no quid-pro-quo at all.
In 1999 or so, Danise Cooper called me to explain what Sun would do with OpenOffice. I explained at that time that they needed to have some sort of quid-pro-quo for code donors, even if it was only a covenant that Sun would keep their own development available under a free software license for some time or remove the contribution from their version. This was not implemented. It was difficult for independent developers to see a reason to work with Sun.
Bruce Perens.
LibreOffice is superior to Open Office in my experience. It is faster, It opens complex M$ Office documents and complex power point presentations more cleanly (assuming you have fonts installed.) It is a definite upgrade from OO.org. One problem. OO.org has brand recognition. Big time. It established itself as a market force. LibreOffice will need to establish that all over again.
MS themselves offered nothing drastically better over unix, novell and apple back in the days... What they offered, was a massively inferior package that was also a lot cheaper (also considering the cheaper hardware)... OpenOffice plays them at their own game here.
Cheaper is most definitely of interest to a business, $130 may not be a lot but $130 * 500 is a significant amount, especially when that cost recurs every 3 or so years and there is a huge push towards reducing cost because of the current financial climate. In fact, the cost of the software often outstrips the cost of the hardware by quite a considerable margin, which is an utterly ridiculous situation.
OpenOffice may indeed have serious bugs, but then MS also have serious and highly irritating bugs (they are even famous for it)... On the other hand, LibreOffice are looking to be far more responsive to fixing bugs than Sun/Oracle/MS ever were.
As for native formats, the native formats of OO are fully documented and open, and gradually people are starting to wake up to the importance of keeping any important data in open formats. Keeping your data in proprietary formats is a huge risk to your business, and the only problem is that the people running many of these businesses simply don't understand technology.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It must be said, though, that MS Office always offered a plain text format (RTF) so the migration path was always there. Newer formats are zipped XML [guardian.co.uk], so the point is largely moot.
Oh wow.
I'm sorry, I don't have time to give this the treatment it deserves, so I'll have to direct you to here for a start:
Microsoft Open Office XML has 6000 pages of documentation, still professionals need better documentation. Open Office XML is the largest standard that was ever put under ISO fast-track procedures.
The large amount of comments filed by national standard bodies indicates that ECMA did no proper review of the standard proposal. No one printed them yet. However the dispositions for the comments provided by ECMA for the BRM comprise another 2300 pages of bugfixes and deprecated functionality
Yeah. So XML is great, once I read the six thousand page spec. Why is this better than a binary format again? Having an open spec is helpful, but forget about open implementations -- IIRC, even Office itself isn't compliant, which causes even more problems given that if someone else, by some miracle, implements the spec properly, they still can't interoperate.
By contrast, while OpenOffice is kind of big and bloated, ODF does have multiple independent implementations, and they do seem to work reasonably well. Even if this wasn't the case, at least you don't have the problem where a bit of functionality is deliberately left unspecified -- large chunks of the OOXML format will mention something (a tag, say) and then declare its actual behavior to be "beyond the scope of this document" or "implementation-defined".
The same is true of RTF, by the way -- while normal .doc documents have enough issues between versions of Word (often OpenOffice does a better job of opening old ones), RTF does much worse. And if Office can't keep it straight, how is anyone else supposed to get it approximately right?
I don't know that I'd suggest a business keep their data in ODF, either, but it's a hell of a lot better than OOXML as far as having actual migration paths and being reasonable for third-party software to read and manipulate. The last time I actually tried working with this stuff (just extracting stuff from MS Office and converting it to more-reasonable HTML), I tried parsing the OOXML, only to realize that it was suicide without a library, no matter how small the data I needed was. Switched to ODF and it was still a project, but I could actually read the document and figure out what was going on, without having to read the spec.
But yeah, "It's zipped XML, therefore it has a migration path!" May as well say, "It's stored in bytes, therefore it has a migration path!"
Don't thank God, thank a doctor!