SoftMaker bests OpenOffice as Microsoft alternative

In the kingdom of business productivity, Microsoft Office reigns supreme.

Microsoft Office's dominating position atop the word processing, spreadsheet, and presentations heap seems virtually unassailable. Its file formats define an industry, and its component applications are often synonymous with the underlying tasks they perform.

That's not a presentation file you're displaying -- it's a PowerPoint deck. You don't punch numbers into a spreadsheet; you update your Excel Workbook. And if you're going to send out that memo company-wide, better make sure it's attached as a Word doc.

People talk about switching Windows versions all the time. However, few souls are willing to walk away from their current version of Office for fear of losing interoperability with their peers, a fact that makes dislodging this sprawling, well-entrenched entity all the more daunting -- though many alternative productivity suites and SaaS offerings continue to try such as Google Apps.

So it was with an eye toward the all-important requirement of seamless interoperability that I evaluated the latest and greatest that the competition has to offer. In the following sections, I take a look at OpenOffice.org 3.1 and SoftMaker 2008 to determine if these suites have what it takes to stage the ultimate palace coup and bring down the king once and for all.

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. Its predecessor, OpenOffice.org 3.0, registered more than three million downloads on its first week out. 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.

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.

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.

I could go on quoting examples, but suffice to say that OpenOffice.org 3.1's interoperability features were wholly inadequate. When the application thought it could successfully render an object, it often mangled it beyond recognition. When it became confused by, for example, an unfamiliar chart type or an unsupported configuration parameter, it simply discarded the extraneous data. It's the kind of half-baked file format compatibility that keeps IT personnel awake at night.

Bottom line: OpenOffice.org 3.1 failed to deliver on its promise of better Microsoft Office interoperability. It severely mangled our Microsoft Word and Microsoft Excel test data files, and no amount of new features or targeted performance improvements could overcome this critical deficiency. Factor in OpenOffice's other well-documented warts -- buggy Java implementation, CPU-hogging auto-update system, quirky font rendering -- and it's easy to see why the vast majority of IT shops continue to reject this pretender to the Microsoft Office throne.

SoftMaker Office 2009: An underdog with bite

If OpenOffice 3.1 is the