ODF Plug-ins and a Microsoft Promise of Cooperation

Earlier this week, the Massachusetts Information Technology Division (ITD) issued a Request for Information (RFI) titled "OpenDocument Format Plug-in for Microsoft Office Suite."   Almost immediately, Pamela Jones posted word at Groklaw  from Gary Edwards that the OpenDocument Foundation had completed just such a plug-in, and would be responding in detail to the ITD shortly.  There will surely be other responses as well, as I have received email over the past several month from other groups embarked on the same project, some as far afield as Australia.

The RFI itself has some interesting aspects as well.  Rather than a formal  Request for Proposals, the RFI is instead a message to the greater IT community asking for assistance, not only from those that may be creating tools, but from those that may simply be aware of something interesting that is going on.  Specifically, what the ITD is looking for are tools that can assist it in its conversion to software that supports the ODF-compliant office software.  The page at the ITD procurement Website where you can view the RFI in ODF, PDF or (yes) Word format is here. 

As a result, if you are involved in a relevant project, or know of one, I would encourage you to check out the RFI and supply any information that you may have that could be useful.  Whether or not you have anything to offer, though, the RFI makes for interesting reading, and I'll now point out a few reasons why.

First of all, the RFI begins with the required trappings of the government contracting process, but also utilizes a refreshing community-based approach, as signaled by the email that I (and presumably many others) received pointing me to the RFI.  That email closed with the following:  “As we are interested in gathering information about all current and potential efforts in this area we would appreciate any assistance you can give us in getting the word out to as many interested parties as possible. Thanks in advance for your help.” 

More specifically, the introduction of the RFI states as follows:

Through this Request for Information, the Commonwealth seeks information pertaining to the existence or development of a “plug-in component” or other converter options to be used with Microsoft Office that would allow Microsoft Office to easily open, render, and save to ODF files, and also allow translation of documents between Microsoft’s binary (.doc, .xls, .ppt) or XML formats and ODF. Respondents responding to this proposal need not be on state contract.

Clearly, such a component would be useful in multiple ways, most particularly by allowing those with disabilities to continue to use Word, pending further progress on improving the accessibility of ODF compliant office software, while their co-workers convert to an ODF-compliant environment.  Similarly, when the ITD deals with state municipalities and others in the outside world, such a plug-in would be useful on an ongoing basis for swapping files received, and converting documents for sending out.

Many of the questions in the RIF that follow are predictable, dealing with issues such as ease of use and installation, available features, proof of conformance to ODF, level of user training required (if any), total costs of ownership, and availability schedule. Others are more intriguing, such as question III.P, which asks  “What external (sponsor, investor, customer) resources that are not currently available or committed to the respondent would be necessary to achieve the functional release timeframes described above?” hinting (perhaps) that the ITD might be willing to underwrite some measure of development costs in order to expedite development, and to influence included features.

But by far and away the most interesting of the 23 included questions are the following:

R.    How much and what kind of cooperation from Microsoft would be required of a team creating an ODF translator plug-in that was very well integrated with Microsoft New, Open, Save, and Save As functions? 

S.    What kind of technical information would the respondent require from Microsoft in order to successfully develop an ODF translator plug-in that was very well integrated with Microsoft New, Open, Save, Save As functions?

In other words, would the cooperation of Microsoft be required in order to achieve the technical requirements of the ITD, and if so, what type of cooperation?

If the answers come back “yes,” either as a necessity, or in order to get faster and/or more satisfactory results, then the question that necessarily follows is whether Microsoft would in fact be willing to cooperate in order to make it easier for existing customers, such as the ITD, to migrate to competing products?  If not, would third parties (such as the antitrust authorities of the European Union) mandate such cooperation?

The answer would seem to be that Microsoft might find it difficult to say no, given the statements made by one of its spokespersons in recent days.  On May 3, multiple journalists reported the following quote from a statement issued by Jason Matusow, Microsoft’s Director of Standards Affairs, upon the announcement (reported first at this blog) that ODF had received an overwhelming vote of approval in ISO/IEC: 

There are hundreds of industry-specific XML schemas used right now by industries spanning health care, real estate, insurance, finance and others. ODF is yet another XML-based format in the market….The ODF format is limited to the features and performance of OpenOffice and StarOffice and would not satisfy most of our Microsoft Office customers today.

Matusow’s statement is curious in a number of ways:  First, as he knows, there are multiple other products that support ODF, such as IBM’s Workplace Managed Client and KDE’s KOffice suite (see my interview comparing the KOffice product to other ODF suites).  Second, ODF, as he also knows, is not an industry-specific schema.  He is correct, of course, that  XML-based formats have been widely developed and adopted, comprising a wildly successful way to help manage and use data.

Most significantly for current purposes, however, is what Matusow said next:

Yet we will support interoperability with ODF documents as they start to appear and will not oppose its standardization or use by any organization. The richness of competitive choices in the market is good for our customers and for the industry as a whole.

Surely this would include cooperating with developers of the type of plug-ins that the ITD is seeking, for the good of Microsoft’s customers and the industry as a whole. 

For further blog entries on ODF, click here

subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)

Comments (5)

  1. R.    How much and what kind of
    cooperation from Microsoft would be required of a team creating an ODF
    translator plug-in that was very well integrated with Microsoft New,
    Open, Save, and Save As functions? 

    S.    What kind of technical
    information would the respondent require from Microsoft in order to
    successfully develop an ODF translator plug-in that was very well
    integrated with Microsoft New, Open, Save, Save As functions?

    I (re)searched the topic of MS Office filters at least twice. Once I was plainly interested in a way to add file format to the WinWord. Second time, when OOo1 arrived, I was more interested in topic from interoperability POV.

    So what have I found? – NOTHING. BLANK. VOID.

    With all buzz around how customizable and extendable MS Office is, Microsoft have never ever released specs on how to write plug-in for open/save (filter) into another file formats. IOW, API is closed and not published. (*) There are even no clues on how to license it. No wonder, all filters shipped with MSO are developped inhouse by Microsoft.

    So guys, I think, you better be readying yourself for another quarrel with MS.

    (*) From financial POV, some may argue, filter API is MS Office. We all know well all the financial incentives of keeping that API closed.

    • There is a huge market for Word add-ins, including document conversion add-ins  which allow users to open, render and save out to various formats. All these folks need to do is find a good COM add-in developer familiar with the Word object model. I don’t see why you think Microsoft should be expected to assist them, they provide the app and the extension model, 3rd party developers provide the add-ins. It’s this type of 3rd party developer model that helps the Windows ecosystem flourish.

      For a list of existing 3rd party add-ins that support document conversion, visit Microsoft’s Office Online Marketplace.

  2. There is a huge market for Word add-ins, including document conversion add-ins  which allow users to open, render and save out to various formats. All these folks need to do is find a good COM add-in developer familiar with the Word object model. I don’t see why you think Microsoft should be expected to assist them, they provide the app and the extension model, 3rd party developers provide the add-ins. It’s this type of 3rd party developer model that helps the Windows ecosystem flourish.

    For a list of existing 3rd party add-ins that support document conversion, visit Microsoft’s Office Online Marketplace.

    • “For a list of existing 3rd party add-ins that support document conversion, visit Microsoft’s Office Online Marketplace.”

      Microsoft actually controls who gets listed in the Office marketplace. One of the requirements to be listed is that the component/application must require an instance of an MS Office application installed and running, therefore cutting the legs of any third partie who has developed solutions that do not need MS Office instances at all, i.e. an alternative.

      As for a Open/Save plugin in MS Word, it’s achieved by hooking the Office-specific Open/Save dialog, and Office-specific menus. Nothing new here, it’s typical Windows programming and there are resources all over the web (look for “API hooking”). A public API is not needed.

      Stephane Rodriguez

Comments are closed.