Last fall, I received an email from Adam Kennedy, someone I didn't know at the time, announcing that his company (Phase N, an Australian Perl development shop) was preparing a converter that would enable Microsoft Office users to convert their files into ODF format. He promised to let me know when a press release would be issued making that fact public, which he did. I wrote about that news on October 20 of last year in a blog entry called (Dead Heads take note) If the Thunder Don't Get Ya, then the Lightning Will: Open Source Victoria Opens Back Door to Office.
The press release announcing the development project of the converter (called "OpenOpenOffice" read in part as follows:
Open Source Victoria, Australia's government-funded open source industry cluster, has formed an alliance with Phase N to develop an open source solution to bring Open Document Format capabilities to Microsoft Office users.
Called OpenOpenOffice or O3, it will allow Microsoft Office users to read and write Open Document Format (ODF) files. ODF is the next-generation standard for storing and interchanging office documents such as word processor files, spreadsheets and slide-show presentations. ODF is supported by many of the office productivity suites on the market, including OpenOffice.org, Sun's StarOffice, Corel Office, Abiword, KOffice and others.
Adam and I exchanged a bit of email on and off thereafter, but I hadn't heard from him in awhile until yesterday, when I got an email letting me know that what had been more in the nature of an informal email to Tim Vavarcheck at the Massachusetts Information Technology Division (ITD) had somehow ended up being treated as a formal response to the ITD's RFI, and consequently had been listed at the ITD Website as such.
Adam went on to provide some interesting additional information on the challenges involved in creating a truly useful plugin, and on what they concluded was the best approach to employ in creating one. When I asked he also kindly gave me permission to include his observations for the benefit of those that have spent some time digesting the various responses I referred to in my prior blog entry, and are interested in the technical aspects of document converters.
Here’s what Adam had to say:
To provide a further update, the OpenOpenOffice project has also since reached the predetermined end-of-life condition (that of a “real” standalone plugin). That condition, on the agreement of all involved at the start of the project, was the production of a sufficiently advanced “real” plugin, which would provide a far more convenient solution than the server-based approach. The ODF has now fulfilled that condition, and we are happy that the server approach is no longer required.
The project was started in the first place because it appeared obvious that a solution based on a complete installation of OpenOffice was ugly, and that a SOAP-plugin connecting to a remote server which provided the OpenOffice translation was a relatively quick way to solve the problem that people seemed to be missing. The idea was too compelling to ignore.
I note with some satisfaction that Sun itself has realized this now (separately or because of us) and their second proposal would appear to be a direct re-implementation of ours.
From the testing we were able to do on our pre-production implementation (which as I mentioned proved too difficult to install for us to consider a release) the methodology does indeed appear completely valid.
The entire exercise has, I think, served as a useful warning that often it is MORE important that any given solution is trivially procurable (i.e. easy to install and setup) than that the quality of the solution itself is high.
If I come by anything else of interest on the topic of converters, I’ll pass that along as well.
For further blog entries on ODF, click here
subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)