Friday, June 08, 2007

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~

5 comments:

Unknown said...

Uh oh. There's more from ComputerWorld's Eric Lai:

"State's move to open document formats still not a mass migration"

Use of ODF remains minimal on government PCs in Massachusetts

Read em and weep

Unknown said...

Hey, this is cool. I just got a note explaining how Novell was able to mount their OfficeOpenXML MS-Cleverage Translator plugin in OpenOffice!

Very cool. It also means we could develop an ODEF version of da Vinci for OpenOffice. If we had to that is.

My guess is that when ODEF applications and application converters start showing up, Sun will swallow hard and provide native ODEF capabilities in OpenOffice.

Just guessing here, but the EU IDABC could quickly come up with exactly the enhanced for interoperability ODEF through some rather simple enhancements to ODF. Not a "fork" of ODF, but a "folding" of ODF into ODEF. Much the same way as ODF folds in other XML standards and reuses them ; like HTML, XHTML, CSS, XForms, SVG and RDF/XML.

OpenDocument Foundation members have in the past submitted specific ODF 1.2 enhancements to achieve exactly the kind of compatibility - interop ODEF seeks. It's a one page hit list describing how to handle all the problem areas.

Our favored list of interop enhancements, submitted by über document expert Florian Reuter, is surprisingly similar to that recently proposed by the MS-Cleverage Translator project!

We've also provided ODF with our -interoperability eXtensions- proposal listing six generic elements to augment the ODF 1.0 Section 1.5 universal generic methods.

A little bit of work stripping out the OpenOffice/StarOffice application specific stuff, remove the OpenOffice/StarOffice constraints on RDF/XML metadata, and then some attention to the problematic optional implementation areas, also known as "interop break points", and tada; we would have a credible ODEF.

Of course, that leaves the problem of governance.

Whatever the EU does with ODEF, the one thing they can't do is turn this important work over to the big vendors.

The demand side needs to govern entirely the open standards they design and mandate. Otherwise, things will quickly collapse back into the cloudy miasma they're trying to escape. The miasma where big vendors control both the applications and the standards consortia.

If the demand side wants interoperability, they need to take over governance of open standards.

Hey, maybe there's a GPL3 for open standards governance?

Just a thought,
~ge~

PS :: What an awesome job Novell did with the OfficeOpenXML Translator plugin for OpenOffice!

If they can do this with something as monstrous and vendor/application specific as OfficeOpenXML, certainly it can be done with ODEF!

Incredible work Novell!

Anonymous said...

Garry, I agree with you that there will have to be some improvements made as the formats are integrated into business and government enterprise users.  In particular, I note that Microsoft's propaganda wing keeps hitting the same few points about spreadsheet formulas and implementation differences between OOo and KOffice as well as the StarOffice/OpenOffice.org specific things.

The more that these things can be overcome, the less there will be for the propaganda mouthpieces to point out.

One area that we need to seriously look into is high-quality libraries to handle the full-spectrum of ODF files (as well as "legacy" formats like .doc and .xls).  These need to be available for such languages as Java, Ruby, Python, Perl, PHP, and dot-net languages. These need to be available with demo code and independent CMS implementations.

Alfresco can use OOo as a transformation engine, but I do not believe that is good enough.  This needs to be integrated into the CMS and its workflows, so that users immediately gain the benefits of being able to upload .odt and .doc files, click a button and download .odt, .doc, or .pdf; along with timestamped versioning of files and easily-configured sharing and access control.

When such capability is built-into the CMS, then Alfresco and other CMS applications can add whatever ODEF compliance is necessary without depending upon Sun to provide it.

One thing I see a lot of is MS Office users desiring to export to PDF, but not having the budget for Acrobat.  MS Office may be the organization's chosen office suite, but something like a PDF-enhanced, legacy-compatible, fully-ODF-capable server application that gives this ability to all users is going to be a "killer app" that even Sharepoint cannot match (given MSFT's opposition to ODF). There are also a lot of people searching the Internet for a way to convert between legacy MSFT formats and ODF.

By the way, Sun needs to drop the whole username signup thing if they want people to adopt their converter. Make it as easy as pie, and many organizations will find ODF springing up internally.... Call this unintentional format conversion, but it is one of the ways that Microsoft overthrew WordPerfect, and it will be necessary if we are to return ownership of files to their creators.

The big thing, I think, is that while all of this goes on, we need to get enterprises to hold off from downgrading to MSOffice 2007.  If two years go by without many OOXML documents, sheer necessity will move adoption of (at least) ODF converters.

Paul E. "Marbux" Merrell, J.D. said...

Gary, you said: "The real world doesn't have the luxury of evaluating OpenDocument and OfficeOpenXmL based on the expert level of proper XML ..."

IBM apparently agrees: Adapting legacy systems for SOA (last visited Mon 11 Jun 2007) ("Because most companies have a significant investment in their legacy infrastructure, management is typically not open to ripping out and replacing legacy systems, regardless of the level of shortcomings evident in the infrastructure. Rewriting or significantly modifying large portions of a legacy environment is neither practical nor realistically accomplishable in a reasonable time frame.")

Until such time as ODF or ODEF can offer ultra high fidelity (non-lossiness) in interactions with the Microsoft-bound business processes, they are ineligible for participating in those processes.

Anonymous said...

Do want to know the magic of online games, and here you can get more mabinogi gold. Do you want to have a try? Come on and cheap mabinogi can make you happy.You can change a lot mabinogi money for play games. And you can practice your game skill. Playing online games can buy mabinogi gold. I often come here and buy it. And you can use the mabinogi online gold do what you want to do in the online game.

What do you know maple mesos. And do you want to know? You can get mesos here. And welcome to our website, here you can play games, and you will get cheap mesos to play game. I know maplestory mesos, and it is very interesting.Do you want a try, come and view our website, and you will learn much about maple story mesos.