Connecting the dots

Is the Failure of ODF in Massachusetts related to the question, “Is Open Source Dying?”

eWeek has posted an interesting series of articles, “Is Open Source Dying from 1,000 Cuts? Among these is a good “connect the dots” story from Michael Hickins, “Is Open Source Dying?

Michael makes the interesting comment: “State and local governments have latched onto the idea that having their documents hostage to a single vendor, no matter how well-intentioned, might not be such a good idea. Dell recently jumped on the Linux bandwagon and is offering Ubuntu on its PCs. And Microsoft's attempt to have its partly-proprietary OOXML (Office Open XML) format rubber-stamped by a friendly standards body hasn't gone as smoothly as expected. ”

“But behind the scenes, things are not quite as rosy. The Commonwealth of Massachusetts ..... broke important ground by mandating that state agencies switch to open-source platforms. There's just one problem: They can't seem to manage the transition. Sources close to the situation tell me that former state CIO Peter Quinn's resignation happened at least in part because of delaying tactics by vendors who publicly support open source but do their best to scuttle it behind the scenes”.

I wonder if Michael knows just how close he's coming to discovering a dark ODf suspicion that seems to grow by the day. Are big ODf vendors supporting ODf? Or are they trading away ODf Interoperability and implementation for sweet sweet deals with Microsoft?

Could the same thing be happening throughout Open Sourcedom?

I'm hardly alone in my thinking that once again, Sir Richard Stallman has been proven right. The big vendors are trouble. If not today, then likely at some point in the future when the interests of open source communities come into conflict with corporate interests.

Whether we're talking LiNUX, OpenDocument, or patent indemnification - interoperability deals with Microsoft, big vendors are willing to trade the efforts of open source communities as if they were just strategic corporate assets. It's not that big vendors mean opens source communities any harm. It's simply that they treat collaborative efforts in the same way they regard all corporate asset investments. Something that can be used for corporate advantage when the opportunity arises.

Everyone one of the big ODF vendors, with the exception of Google and Oracle, now has or is involved in an interoperability deal with Microsoft.

Sun cut their deal in 2004, and ODF interoperability has never been the same. Novel cut their deal in 2006, and now LiNUX vendors everywhere are being offered plump deals that require them to support and ship the Novell OfficeOpenXML Translator plugin for OpenOffice. The MS-Novell deal promises to put IBM hardware back into competition with Sun, and could be an explosive boon to the PowerPC 6 line of processors. The ability to run Microsoft applications is that important. Even if it is through a VM over SuSE LinNUX.

So far the tech media has focused on the patent indemnification – son of SCO aspects of the Microsoft interoperability deals. The patent threats however involve both LiNUX and, LiNUX desktop darling OpenOffice – which is also the OpenDocument champion. Time to connect the dots indeed.

The 2004 MS-Sun deal indemnified StarOffice, while leaving OpenOffice, the open source version of that same code base, hanging out to dry. Fast forward to the 2006 MS-Novell-IBM deal and we find that the Novell Office version of OpenOffice has been indemnified! Including both Windows and LiNUX versions. Very cool. That ends any thoughts Sun might have had about monetizing their $175 Million investment in the OpenOffice/StarOffice code base by invoking MS patent claims against OpenOffice as a pretext for migrating the entire OOo install – ODf user base to StarOffice.

The interesting thing to note is that with the continuing wave of Microsoft interop deals, we have all these big ODF - LiNUX vendors now supporting the full conversion of OpenOffice to a OfficeOpenXML application.

There's a list of links documenting Novell and Sun support for OfficeOpenXML here.

Meanwhile, many of these same big ODF vendors declined to support the ODF Plugin for MSOffice that the future of ODF in Massachusetts was riding on! After conducting a year long ODf Pilot Study, Massachusetts concluded that ODf plugins for MSOffice were the only way they could make the transition to ODf.

No doubt the plugin approach Massachusetts proposed was in serious conflict with the big vendor business plans behind the many desktop alternatives that bombed in the Pilot Study. So where Massachusetts was trying to figure out how to overcome the MSOffice bound business process barrier to successfully implement ODf, the big ODf vendors were more worried about their heavily invested corporate assets and plans. The thought of leaving MSOffice on the desktop, even if the documents and business processes were in fully compliant ODf, was too much for the big ODf vendor business plans to bear.

With Microsoft bringing on the political pressure, and eventually succeeding in cutting off his budget, Massachusetts CIO Louis Gutierrez had no choice but to turn to the big ODF vendors for support. Thinking that there was no way these vendors would ever let ODF fail in Massachusetts, Louis believed he could overcome the budget problem. He was wrong about the big ODf vendors. They left him hanging.

Shortly after Louis Gutierrez was notified by his selected group of big ODF Vendors that they would not support his community effort to develop an internal ODF plugin for MSOffice, Louis resigned. Of course, the ODf plugin was a comparatively small part of projects impacted by the lack of an approved IT budget. But the impact was big. They had serious HomeLand Security projects hanging in the balance because of Microsoft's determination to stop ODf.

The failure of ODF in Massachusetts has had global ramifications. In California the CIO's asked the question as to whether or not it's even possible to implement ODF? They all know about Massachusetts and the Pilot Study. In Europe, the IDABC has set out to create their own non big vendor - non big vendor standards consortia file format; a highly interoperable fork of ODF called ODEF; "OpenDocument Exchange Format". No big vendors, no ISO, no OASIS, no Ecma, no big vendor standards consortia of any kind were invited to the ODEF table.

So here we have the strange situation where the same big ODF vendors who declined to support an internal ODF plugin that would be able to convert 500 million MSOffice bound desktops to ODf, and save ODf in Massachusetts, are supporting OfficeOpenXML solutions. These same big vendors are making sweet sweet deals with Microsoft, agreeing to provide MS OfficeOpenXML ready versions of OpenOffice.

On the one hand they are against an ODf plugin for MSOffice. And on the other hand they are rushing to provide the OOXML plugin for their shipments of OpenOffice.

Doesn't make sense until you realize two things. The first is that the Microsoft anti trust settlement allowed Microsoft to commercialize the very same interoperability critically important to the goal of creating competitive markets for information technologies. It's hardly surprising that sooner of later Microsoft would be weaving that interoperability into the push and pull deal making fabric of these marketplaces exactly to stifle any threat of competition. First up; ODf and LiNUX. Once the first big vendor fell, the rest were doomed.

2004. Not a good year for ODf and Open Source.

~ge~

Politics is only part of the problem

ComputerWorld: Microsoft legislatively TKO’s open document formats. At least stateside. by ZDNet's David Berlind -- ComputerWorld has a five-page report this morning detailing how Microsoft has managed to score a technical knockout of open document formats (not necessarily the OpenDocument Format) in five out of six states. The story sheds a bit of light on how closely (and in some cases quickly) vendors are working with legislators to sway public [...]

Sorry David, politics is only a small part of the problem.

The question we should be asking is why State CIO's and IT divisions are not backing the legislative proposals? It's not the lobbying that is killing ODF. It's the lack of support from IT departments responsible for the challenge of implementing ODF solutions if the legislation is ever approved. The silence of the CIO's is deafening.

One has to wonder why? I've had more than a few conversations with CIO's and their IT warriors, and there is no lack of enthusiasm for ODF. They would implement ODF in a heartbeat if they could. No legislative mandate necessary.

Of course, it seems not a week goes by without a major ODF vendor announcing some sweet interoperability - patent protection deal with Microsoft. But where's the beef?

Even at the ISO-OASIS ODF Technical Committee level, where the essence of interoperability with MS Office lays within the broader structural enhancement requirements of "compatibility with existing file formats and application interoperability", these issues have been pushed aside as being "out of bounds", "out of scope", "outside the charter", and "that's a problem for converters and translators-let them solve it".

The marketplace of CIO's and IT warriors in California, Massachusetts, Belgium, Denmark, NATO, and throughout the EU IDABC are consistent in their demands. Provide them the interoperability tools they need to migrate existing documents and business processes to ODF, and it will be done. No legislative mandates needed.

There are three quotes i've seen batted about that pretty much say it all:

• ...... "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"

• ...... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?"

• ....... "Under those conditions, is it even possible to implement OpenDocument?"

The challenge for OpenDocument isn't at the legislative level. Nor is it at the International Standards level. No, the challenge for ODF is at the implementation level where there is a serious lack of MS Office compatibility tools and solutions needed to make that difficult transition to ODF.

So we are left with the real world question of whether or not the "demand side" of the information technology equation can get from where they're at today, 500 million desktops bound to MS Office workgroup-workflow processes, to where they would like to be tomorrow? Which is ODF.

Sadly, ODF doesn't get to start with the world as a clean slate. Otherwise this decision would be simple and done. With no amount of political lobbying able to stop real world uptake. ODF wouldn't even need legislative proposals.

But that's not the case. Hardly. With upwards of 500 million workgroup desktops bound to MSOffice bound business processes, we are a long way from the 1995 office suite "feature set" wars of yesteryear. All the new and innovative features sets in the world aren't going to help ODF office suite applications crack into those MS Office bound business processes. What's needed instead is an all out - no compromise focus on compatibility, interop, and convergence issues.

The documents and business processes that make these critical day to day workgroup-workflow tasks possible are going to transition to XML. The question is, "Which one? ODF or MS OOXML?"

Where the rubber meets the road, the challenge for ODF is that of matching doc for doc, proc for proc, the non disruptive cost Microsoft offers with their OfficeOpenXML plugin.

The real world doesn't have the luxury of evaluating OpenDocument and OfficeOpenXmL based on the expert level of proper XML, open standards governance, IPR encumbrances, or reuse of existing XML standards. No, instead they have a bigger problem of getting existing documents and business processes into XML. And from there they can move into SOA, SaaS, and the Web 3.0.

So CIO's are forced by the everyday reality of MSOffice bound business processes to demand from ODF solutions three primary characteristics:

• .... Compatibility with existing file formats (MS Binaries/HTML/XHTML/RTF)

• .... Interoperability(application level - including existing apps like MSOffice!)

• .... Convergence (the portable XML document as the end user interface into information systems that span desktop-server-device-web)..... If your tied to the desktop, you're dead. But if your an XML file format tied instead to something like the Vista Stack, well, you've got a shot as long as the other guy remains a no show.

• .... Harmonization (the worst of all compromises; the successful implementation of the above three characteristics, but on terms dictated by MOOXML.

These are serious questions the ODF community has to come to terms with if the demand side of the equation is to have some sort of choice other than OfficeOpenXML.

That's not to say that the demand side is sitting still. No way. Check out the EU IDABC "Advanced eGovernment" Conference held February 28th-March 1st, 2007 in Berlin. They've got their own "optimized for interoperability" proposal known as ODEF - The Open Document Exchange Format.

You've got to read this stuff to believe it. No big vendors need apply. No ISO either! I take that as a swipe at both the big vendor standards consortia, OASIS and ECMA.

The EU IDABC has even gone so far as to identify the "interoperability break points" that can be found throughout ODF and OpenOfficeXML: the "optional" methods of implementation.

There is a famous quote from the infamous Doc Searls that goes like this, "Open source is where the demand side has taken over their own supply".

Could it be that we are now witnessing the same thing with Open Standards? One has to wonder.

Meanwhile though, The OpenDocument Foundation has made the decision to go with the marketplace - to stick with the demand side. If the EU gives us the ODEF spec, we'll provide them with an ODEF version of our da Vinci plugin for MSOffice. As applications (and application converters :)) move to ODEF, i have no doubt OpenDocument will jump to make whatever compatibility-interop-convergence changes needed. And that would be a good thing.

A very good thing,
~ge~