The better Office alternative: SoftMaker Office bests OpenOffice.org

OpenOffice.org 3.1: Pretender to the throne
OpenOffice.org 3.1 is the latest incarnation of the free open source community's most visible business productivity suite. A close cousin of the legendary StarOffice commercial product from Sun Microsystems and the source of numerous variants, including IBM Lotus Symphony, OpenOffice.org is frequently cited as the most viable competitor to Microsoft's ubiquitous Office platform. However, the suite has consistently failed to make significant inroads with IT, prompting OpenOffice proponents to concoct all manner of excuses for why it keeps falling short (see "Why is Microsoft Office so hard to kill?" for examples).

With the release of version 3.1, OpenOffice.org advocates are hoping that the latest round of feature enhancements and performance improvements will help the suite break through with IT decision makers. A quick perusal of the release notes would seem to offer reason for optimism. First off, OpenOffice.org 3.1 is faster. It now takes less time to launch the individual applications, and such components as the Calc spreadsheet receive additional tuning to improve the performance of various common functions. Calc also receives some much needed usability tweaks, including better sheet renaming (just double-click the tab label and start typing) and improved sorting that respects column headers. Likewise, Writer receives a new commenting system and better file locking so that it plays better in a mixed OpenOffice/Microsoft Office network environment.

In fact, Microsoft Office interoperability is one of the major themes for version 3.1, with new import support for documents, spreadsheets, and presentations in Office 2007's native Open XML file format. However, as I discovered during comprehensive lab testing, that support remains mostly skin deep. Complex Word documents, with lots of embedded charts and drawings, still trip up Writer, while Excel workbooks with external data links are rendered impotent by Calc's lack of connectivity to critical back-end resources.

[ Compare how OpenOffice.org 3.1 and SoftMaker Office 2008 handled our complex Office documents. ]

I evaluated OpenOffice.org 3.1 under the 32-bit version of Windows Vista with Service Pack 2. Installation of the suite was straightforward, with the setup program automatically establishing file associations between OpenOffice's component applications and various data file types, including Microsoft Office. However, when I attempted to test these associations by launching a Microsoft Word 2003-formatted document, Write completely botched the import process. Numerous embedded AutoShape drawing objects were distorted beyond recognition, while hanging indents in the document's bulleted lists were improperly aligned. Even simple things, like preserving boldfaced headers in a table, were broken by Writer's quirky import filter.

The final straw was when I attempted to save the document, then reopen it under Word. I found that, after a pass through Writer's export filter, the drawing objects became further mangled, while the placement of various section and paragraph headers had been skewed to the right. Worse still, when I attempted to import the same file in Word 2007 format -- one of the new capabilities touted by OpenOffice.org 3.1 advocates -- Writer thrashed the document, replacing all of the embedded charts and drawings with a bunch of indecipherable text crammed into the top few lines of the first page.

Curious to see if these problems were isolated to Writer's import/export filters, I tried saving the document in Open Document Format (ODF) from within Microsoft Word, then opening it inside of OpenOffice. Again, the document was rendered incorrectly, with several chart objects missing and various formatting anomalies quite visible. Resaving the ODF document in Writer, then reopening it in Word showed that the data loss was indeed permanent: The missing charts were nowhere to be found, while the aforementioned malformed bulleted lists and other layout errors remained.

Moving on to Calc, I discovered that importing an Excel workbook with external SQL links meant severing all ties to the back-end SQL Server that served up the raw data. Instead of a dynamically updateable range of cells, I was left with a bunch of static values. Worse still, saving the document in Calc, then reopening it under Excel caused the link configurations to the original SQL data source to be permanently lost. Given the complexity of many real-world custom Excel solutions -- financial services firms are known to run multigigabyte simulations on their front-line trading workstations -- such a hatchet job by OpenOffice's import/export filter is potentially catastrophic.