Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled
 Microsoft trounces pro-ODF forces in state battles over open document formats.




Andy believes that it is the failure of state legislators to do their
job that accounts for these failures.  He provides three reasons for
this being a a failure of legislative duty.  The most interesting of
which is claim that legislators should be protecting CIO's from the
ravages of aggressve vendors. 




The sad truth is that state CIO's are not going to put their careers on
the line for a file format after what happened in Massachusetts.





Andy puts it this way, "
  



While Andy's analysis is correct, the question remains, "What do we, the supporters of ODF, do about this?"



Personally i think it was wrong to to take the legislative mandate
route to begin with.  It's anti trust by different means.  And if the
Department of Justice and the highest courts in the land can't stop
Microsoft, how can we expect a bunch of back benchers to be
successful?  The recidivist reprobates from Redmond were able to buy
themselves what amounts to a presidential pardon!  After that awesome
show of force, quashing the meager efforts of the ODF back benchers is
comparatively trivial.  And there is that chill of "getting Quinn'd"
Microsoft sent down the spine of every CIO the world over.

  

Although many will think it's unfair, i believe the only
way ODF can succeed is that of beating Microsoft's XML file format,
"OfficeOpenXML" , in the marketplace.   This will no doubt require a
radically different approach to the issues of "compatibility, interoperability and convergence" than that which has long prevailed at the Sun OOo/SO dominated OASIS ODF Technical Committee. 



A legislative mandate for ODF is in effect a mandate that MS
Office be "ripped out and replaced" by some version of Sun's
OpenOffice/StarOffice source code base.  This is both unconscionably
disruptive and costly.  Munich and Finland have tried the rip out and
replace approach, with the cost well in excess of $3,000 per desktop!



So even if there was a legislative mandate, someone has to
come up with money to pay for the disruption and cost of "rip out and
replace".   The simple truth is that CIO's can't realistically
implement ODF even if the legislative mandates were successful!



Even IBM has finally come around to this point:
"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."

http://www.ibm.com/developerwor

ks/webservices/library/ws-soa

-adaptleg/

The Massachusetts approach to solving this problem was
to issue a Request For Information (RFI) concerning the feasibility of
a ODF plugin for MS Office.  The RFi was the result of a year long
"Pilot Study" that concluded it was impossible to implement ODF through
either a "rip out and replace" approach, or, a gradual integration of
OpenOffice* into existing MS Office bound workgroup-workflow business
processes.  Impossible!



The problems with the ODF plugin for MS Office approach are many:

• Invoke the ODF Charter, claiming compatibility-interoperability efforts with non ODF applications and file formats to be "out of bounds", "out of scope", "outside the Charter", "the converters problem, not our business", "Microsoft's problem",
  and, "let the translators deal with it".

• Bind ODF to OpenOffice specific feature sets, fighting off "compatibility-interoperability
  "
  enhancement efforts by arguing that such changes would greatly inhibit
  the ability of OpenOffice to implement new and innovative features.  In
  essence, forcing OpenOffice to clone MS Office features.
  

• Whenever Sun does
  compromise, the interop flexibility is put into the ODF specification
  as "optional".  Meaning, OpenOffice can fully ignore the
  interoperability enhancements needed by plugin based converters and
  translators.  And that guarantees the breakdown of interoperability
  between MS Office ODF and the primary ODF reference implementation,
  OpenOffice.  These "optional" implementation requirements are also know
  as "interoperability breakpoints". 
  Many believe that these interop breakpoints are designed into ODF and
  MS OfficeOpenXML to insure that the dominant applications are able to
  maintain their dominance against any marketplace threat.
  
  

Government CIO's are confronted with
an impossible situation.   While they clearly and overwhelmingly
support the internal ODF plugin for MSOffice approach, the big vendors
on both sides of the equation are able to block needed improvements at
the file format "standards" level; and, at the application implementation "market" level.



On the one hand Microsoft is telling CIO's that they had to
design their own XML file format because ODF does not consider
compatibility with existing binary file formats to be a worthy
objective (true); and, that ODF is entirely inadequate and unable to
capture the full range of MSOffice features.  Microsoft correctly
argues that ODF is based exclusively on the OpenOffice feature set.  
And that Sun controls the ODF TC process.



Microsoft's claims about ODF are true except for one
extraordinary factor; the Phil Boutros "universal generic" section 1.5
of ODF 1.0.   This section of ODF 1.0 does provide all the flexibility
needed for ODF to fully handle everything and anything MSOffice bound
business processes and binary file formats can throw at it.  The
problem is that section 1.5 of ODF 1.0 is "optional".  OpenOffice only
implements a small subset of this section (paragraphs and spans),
totally breaking any hope of interoperability with MSOffice ODF!


At
the ODF Technical Committee, Sun continues their determined effort to
block, inhibit and thwart any efforts at improving interoperability
except on terms dictated by OpenOffice application specific features. 


Yes, Sun has responded to market demands for an ODF
plugin converter for MS Office.  But since that converter is "external"
to MS Office, the conversion is a one way process.  MSOffice documents
can be converted into OpenOffice/StarOffice ODF.  The problem is that
the documents can't be converted back into MSOffice binary without a
frustrating, business process killing corruption of fidelity. 


This is of critical importance to CIO's since it is the
MSOffice bound business processes that block ODF implementations.  The
only way to implement ODF without totally disrupting existing business
processes is perfect a high fidelity "roundtrip" conversion process. 
This can only be done through the design of "internal" ODF plugins for
MSOffice.  And these plugins produce completely legit and compliant ODF
documents that Sun refuses to interoperate with at the application
level of OpenOffice.



So what to do? 

There are indications that IBM is
getting ready to make a major push on ODf interoperability.  Perhaps
this is because IBM's ODF ace, Bob Sutor, attended the
February 28th-March 1st 2007 EU IDABC "ODEF" Conference in Berlin.  ODEF stands for "Open Document Exchange Format"
, a new XML file format designed to be highly interoperable and fully
compatible with our legacy situation.  A situation where upwards of 500
million MSOffice bound desktops dominate workgroup-workflow critical
day to day business processes. 

C'mon IBM.  If you can't move the rock, move that hard place!

~ge~