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.
A week ago, I wrote an entry called ODF, MS and Mass: Now you see the dots (and now you don't). Today I'll look at some more dots, both clearly visible and obscure, and see how many I can identify and connect.
While a quarter-page ad on the editorial page of the Boston Globe costs far less than a $30 million in-kind software donation to Bay State schools and universities, it's a good bet that the ad titled "Working Together Better by Design" that appeared in yesterday's Globe has something to do with last week's generous contribution. Since the ad urges the Massachusetts Information Technology Division (ITD) to adopt Microsoft's Open XML format, then by the transitive property of mathematics (which, as you will recall from middle school, teaches that "if a = b, and b = c, then a = c"), there's a connection between that $30 million donation and the ODF policy of the ITD.
Certainly there's nothing subtle about the goal of yesterday's ad, which concludes:
The promise of interoperability is a vision we share with officials of the Commonwealth of Massachusetts. We look forward to the commonwealth's consideration of Open, XML-based format standards as one path toward bridging technical and organizational boundaries and advancing the capabilities of the state's information assets now and in the future. We are committed to working with all of our customers to realize the full potential of information easily exchanged.
The text of the rest of the ad tracks the currently displaying essay at www.Microsoft.com/issues. That essay incorporates many of the corporate talking points that I have noted before, and focuses on the high value of interoperability - and particularly of achieving interoperability "by design," from the beginning of the design cycle. It also notes the recent formation by Microsoft of an Interoperability Customer Executive Council, the importance that Open XML will play in achieving interoperability by design, and Microsoft's submission of Open XML to Ecma.
My topic tonight is a set of RFI responses that surely must be an oxymoronic first: they make fascinating reading(fascinating? RFI responses?). Moreover, they offer the opportunity to go on something of an Easter egg hunt for anyone that wants to pick and prowl through them looking for this surprising bit of information or that, or who wants to weigh what is unsaid (and guess why) as much as to assess what has been claimed, and whether the respondent can actually deliver. Oh - and there's the occasional polemic thrown in as well.
What's all this about? Well, as I reported in early May, the Massachusetts Information Technology Division (ITD) posted a "Request for Information" (RFI), soliciting information on plugins to convert documents created in ODF compliant formats into Office documents. The goal was to find the kind of conversion tools that could ease the ITD's transition of its more than 50,000 desktops from a primarily Microsoft Office-based environment to one that would rely only on ODF-compliant software. Absent such plugins, it would not only be necessary to convert all of those desktops simultaneously, which would be a much larger and more expensive endeavor than doing a more orderly phase-in, but the entire switch-over would need to await adequate accessibility features for the ODF suite chosen for deployment. But with such tools, normal desktop upgrades could be switched over to new desktops preloaded with ODF software, and training on all new programs could proceed in an orderly and efficient fashion.
Yesterday the ITD posted the, six from software vendors - and one from Microsoft.
The six plugin responses make for are an interesting read, and it would be very time consuming to thoroughly report on all of the interesting concepts, suggestions and hints that can be found in them, as well as to highlight the differing conclusions that each submitter offers (for example) on the degree and type of assistance that would be needed from Microsoft. If you're in to such things, you can have quite an Easter egg hunt browsing through what can be found here, how it is presented, and how various developers come out.
First, let’s put the Microsoft grant in context. There is nothing unique about such an action by Microsoft, and many of its competitors make similar donations (here are some examples of programs maintained by IBM and Sun). The generic reason …
An hour or so ago Sun Microsystems made good on an earlier pledge to issue further "non-assertion covenants" (NACs) in support of open standards. In doing so, Sun has taken an important step in helping propagate and popularize a useful new tool to facilitate the implementation of open standards. The new NAC appears here, and relates to the OASIS Security Assertion Markup Language (SAML) V2.0 standard. Simultaneously, Sun is announcing a separate NAC relating to two other specifications co-developed with Microsoft: Web Single Sign-on Metadata Exchange Protocol and Web Single Sign-on Interoperability Profile.
These new NACs are modeled on the earlier commitment delivered by Sun to OASIS in connection with ODF. You can find a detailed analysis of what that NAC promised in this earlier blog post (Sun's Simon Phipps describes it here), which contrasted the Sun NAC to one issued shortly thereafter by Microsoft with respect to its XML Reference Schema (since submitted to Ecma, and now referred to as Open XML). The Microsoft NAC is further examined here.
The reason all of this matters is that an NAC has a number of distinct advantages over a traditional open standards commitment, and offers a way to streamline both the standards development, as well as the standards implementation, processes. Here's why.
It's now been more than a week since Microsoft announced that its licensing discussions with Adobe had fallen apart after four months of negotiations. Microsoft's statement was sparse, although a few additional details could be picked up from Brian Jones' blog. A few day's later, Adobe's PR firm released a few comments in an email blast, indicating that Adobe might have no more to say on the matter. All of which left many (including me) speculating on what may or may not have happened.
Adobe changed its mind (barely) on June 12, and posted a statement in the pressroom section of its Website that added little additional detail to inform the public what in fact is going on.
While others have a variety of concerns relating to this chain of events, mine is very limited: standards are created, and rely, primarily on a system of trust. If someone violates that trust, it shakes the entire infrastructure to its core. Did that happen here? Nobody knows, except Microsoft and Adobe, and so far neither of them is talking. Until one of them does, the incident casts a serious pall over the viability of the standard setting system. Why? Because if Adobe is seen to have violated the rules with impunity and suffers no consequences, then what reason is there for anyone else to honor their commitments?
All of this could be cleared up quite easily, by either party making one of the following simple statements:
1. Microsoft sought to license only those elements of the PDF specification that lie within the ISO/IEC specification with respect to which Adobe made its RAND declaration.
2. Microsoft sought to license more than those elements.
Item:
Having the latest computer technology is great. But what e-government users from the public sector as well as citizens really want is software interoperability. Unfortunately IT managers still only pay lip service to such interoperability, concludes a European project assessing today’s open-source movement.
So reads the lead paragraph of an article called FLOSSPOLS, launched to support Free/Libre/Open Source Software policy support in Europe. The summary continues as follows:
“Open standards provide independence, not traditional vendor lock-in. They are good for users, purchasers and government from both the economic and competition standpoint,” says Rishab Ghosh, from the Merit/Infonomics research institute in The Netherlands.
Given how often the words "open source" and "open standards" are bandied about in the technical press, it surprises me how little many in the open source community seem to care about the second half of this pairing of related tools. It's especially surprising since open standards don't need open source, but open source, like all other software does need open standards. That's reason enough for the open source community to want to know more about them.
Standards wars are not usually considered to be very newsworthy outside of the technical niche in which they occur, but occasionally there's a breakout story that receives much wider attention. A recent example was the frontal assault of multiple countries directed at wresting control of the root directory of the Internet - a small but very important standard - from the United States. That skirmish completely monopolized press coverage of the Tunis meeting of the World Summit on the Information Society (WSIS) last November.
But before that, there was an even higher level confrontation, this time over a close-range wireless networking standard. That dispute involved the IEEE 802.11 standards family commonly referred to as WiFi, on the one hand, and a Chinese-origin standard called WLAN on the other. More particularly, it involved a security protocol (called WAPI) included in WLAN that China contends provides superior security protection than does WiFi.
The original WiFi-WAPI conflict arose from the announcement by China that only WAPI-enabled equipment could be sold in the Peoples Republic of China beginning in 2004, which would reverse the situation from one requiring Chinese manufacturers from paying high patent royalties to companies like Intel to one where Western vendors would find themselves in the opposite position.
Publicly, Intel and other chip vendors announced that they would refuse to sell microprocessors in China if the requirement was imposed. Privately, they headed to Washington for help, since of course they had no desire to lose access to so vast a market. The dispute worked its way up through diplomatic channels until ultimately then-Secretary of State Colin Powell became involved. Eventually, China postponed the effectiveness of the home-grown standards requirement.
But what had been brokered was only a truce, and not a final resolution to the dispute. Now, that dispute is flaring up again, and it is the Chinese standards delegation this time that is calling in the diplomatic corps to engage with the opposition.
For a week now, the IT world has been scratching its collective head over the breakdown of PDF licensing negotiations between Microsoft and Adobe. At issue is why Adobe has allowed OpenOffice.org and Apple to bundle native support for saving documents in PDF format without any economic hooks, but apparently is requiring Microsoft to charge its customers more for Vista if this new release includes the same capabilities - even though PDF is a standard that should be available to all on the same terms.
There are, I think, two logical explanations. One is relatively straightforward, while the other represents a convoluted and little-discussed weakness in the traditional way of creating standards. In this entry, I'll describe both possible explanations, but I'm betting that the convoluted alternative will prove to be the explanation for what is happening here.
Let's knock off the easy explanation first, which relates to exactly what it is that Microsoft would like to license from Adobe. At one end of the spectrum, Microsoft may only be interested in licensing those Adobe patent claims that would be infringed if Microsoft were to write software to implement the PDF specifications that have been adopted as standards by ISO/IEC. Next up the value chain would be wanting to license the actual code that Adobe itself uses in Acrobat to save documents in the PDF format (not too likely a scenario, given that Microsoft has written a few lines of code over the years). And finally there would be a Microsoft request to license additional features that are included in Acrobat, but which are not described in the ISO/IEC standard. Such "proprietary extensions," as I discussed in my last blog entry, can be quite desirable - as Microsoft is well aware.
In the first case, Adobe would have an obligation to license the patent claims to Microsoft on RAND terms (on which more below). But in the latter two cases, Adobe would be fully justified in imposing whatever unique requirements it wished on the extra code and/or patents, as the case may be, since it is not bound by the specific undertakings it entered into with AIIM (the actual standards body that developed the PDF standard, and then submitted it to ISO/IEC) with respect to actual code or any additional functionalities.
So the first possibility is simply that Microsoft wants more than Adobe is required to give it under its standards-related undertakings.
In this third in-depth interview focusing on ODF-compliant office productivity suites, I interviewed Erwin Tenhumberg, Sun's Product Marketing Manager, Client Systems Group (Erwin's own blog is called Erwin's StarOffice Tango). This series of interviews, and the other activities I have planned to follow, are intended to illustrate the rich environment of applications and tools that are evolving around the OpenDocument Format (ODF) specification developed by OASIS, and now adopted by ISO/IEC. (You can find the previous interview with Inge Wallin of KOffice here, and with Louis Suarez-Potts and John McCreesh of OpenOffice.org here).
Each of these interviews illustrates the unique attributes of each flavor of ODF-compliant software. KOffice is an open source component of the KDE desktop, and thus represents an interesting contrast and alternative to the Office on Windows environment. OpenOffice is also an open source suite, and is the lineal descendant of the code that formed the starting point for the ODF development effort. And StarOffice in many ways is OpenOffice. As you will read below, the same code that represents OpenOffice is utilized in StarOffice as well, which in turn is distinguished by additional value-added features, available support and conversion tools. Like KOffice, StarOffice runs on its developer's operating system — Solaris, representing another alternative to a Windows/Office environment. But unlike MSOffice, StarOffice (and KOffice) will also run on GNU/Linux — and OpenOffice will also run on FreeBSD and Mac OSX.
This series of interviews will include IBM's Workplace as well, which is already in the interview queue. I do not personally have contacts at Google Writely, Abiword, Textmaker or Gnumeric, but if you do — please tell them that I'd be delighted to run an interview with them as well, as the hope is to provide a complete, comparative picture of the entire ODF ecosystem.