Despite Some Teething Pains, ODF’s Vendor-Neutral Approach The Best Way Forward
Despite some portions of the standard that appear to be underspecified and the inconsistent implementation I recently wrote about, the vendor-neutral approach offered by the OpenDocument Format remains the best way to achieve the freedom from vendor control that we seek. Other approaches, such as the “this format is based on implementation X” approach, leave most competitors playing eternal catch-up, while customers and end-users have little choice but to get the format originator if that format is important to them.
Despite whatever complaints or grumbles you may hear, we all know that—except for people employed by a leading vendor—we bear the incompatibilities and the unspecific portions, while hoping that the next version of the standard (and the next version of ODF-compatible applications) will get a little better. And now that the leading vendor of office software is preparing to enable native support for ODF, I expect it to get even better.
For me, at least, it was never about replacing Microsoft Office, but about the freedom to choose whatever product will best meet my needs at the time. When you are supporting users, then it is even more important to have multiple compatible choices, because there is always something that product X does not handle correctly, but product Y does handle correctly. And when you are the person who is asked to open some legacy file format whose original application’s vendor has decided that earlier versions are unsafe, you will come to depend upon the ability to utilize a competing product to open it.
Now, as we work toward that improved compatibility and specificity, we also need to work toward a wide variety of tools and uses to help make ODF-compatible products better for end-users. Something similar to what Brian Jones and his team have been writing about recently would be a good way to continue the work Bob Sutor did with “Dr. ODF” a couple of years ago.
Another project that I think would be very helpful would be to mirror as many (federal and state) government-hosted word processor, spreadsheet, and presentation documents as possible, except for converting them into fully-functional (work-alike and look-alike) ODF files. Obviously, it would have to involve a very trustworthy group (running active-code from unknown entities on one’s computer is highly discouraged).
One more project that would really be helpful is to produce human resources and recruitment software that accepts .odt (ODF text document format) files as well as the Microsoft legacy binary formats. During a job search, one sees “send your resume in Word DOC format” on nearly every opening. If the software could handle ODF documents equally well, a huge impediment to ODF adoption would crumble pretty quickly. Perhaps this is best implemented as a zero-price plugin for existing applications, but it would have to work without the warning dialogs that characterize the use of ODF plugins in Microsoft Office.
I felt that it is important to record this now, lest readers get the impression that I am becoming discouraged, disenchanted, and potentially venemous. It was enough that members of the former foundation were disillusioned over the process they encountered in the ODF TC at OASIS. I will grant that, if CDF ever does come to fruition as an office document format, Sam Hiser will seem prescient. (Personally, I hope it does, but in the meantime, ODF remains our best path forward.)