So I'm disappointed. And not just on behalf of open documents, but on behalf of the CIOs of this country, who are now caught between a rock and a hard place, without a paddle to defend themselves with if they won't to do anything new, innovative and necessary, if a major vendor's ox might be gored in consequence.
After the impressive lobbying assault mounted over the past six months against open document format legislation, I expect you won't be hearing of many state IT departments taking the baton back from their legislators.
And who can blame them? If they tried, it wouldn't be likely to be anything as harmless as an open document format that would bite them in the butt.
Gary Edwards (343)
marbux (24)
Jesper Lund Stocholm (9)
mazyar hedayat (4)
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, "
And second, in a situation like this, it is a cop out for
legislatures to claim that they should defer to their IT departments to
make decisions on open formats. You don't have to have that good a
memory to recall why these bills were introduced in the first place:
not because state IT departments aren't a good place to make such
decisions, but because successive State CIOs in Massachusetts had been
so roughly handled in trying to make these very decisions that no state
CIO in his or her right mind was likely to volunteer to be the next
sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to
make responsible standards-related decisions where huge sums of vendor
revenues are at stake is scarcely a career-enhancing pastime. CIOs
should be entitled to stay out of harm's way, and try their best to
serve the public's interests the best they can. Where that can't be
done, legislatures should protect them, and keep them safe from the
types of unwarranted threats and attacks that Carol Sliwa reported on
in a series of public-records request-based stories at ComputerWorld last December.
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
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:
ODF Vendors believe that governments will bit the bullet and mandate
ODF despite the high cost and impossible disruption to critical day to
day business processes. ANY compromise solution, like an ODF plugin
for MS Office, mitigates the anti trust motivations behind legislative
mandates, letting CIO's off the "rip out and replace" hook. A hook
that promised some really fat "services" based profitability.
interoperability with MSOffice applications and file formats only
serves to help Microsoft maintain their monopoly. This thinking even
has a name, "Holding the SAMBA Line". Meaning, any kind of
compatibility-interoperability effort that goes beyond the SAMBA
Windows networking protocol helps Microsoft maintain their monopoly.
Which is to say, legislatively mandated "rip out and replace" is the
only approach acceptable to big ODF Vendors.
XML file format specification problem, and therefore something entirely
under the control of big ODF Vendor Sun. And Sun is intent on tying
ODF to OpenOffice only feature sets. A determined effort that is the
root cause of ODF's infamous ZERO Interoperability problem.
::: The interoperability of plugin converters and translators is
entirely dependent on the applications and file formats involved. The
issues are as follows:
the constraints of MSOffice application feature sets and, the
in-memory-binary-representation that documents must be converted to
before the MSOffice applications can work on them.
adequate measure of flexibility to handle the needs of MSOffice
features and accompanying in-memory-binary-representation
requirements. These needs fall into the problematic ODF category known
as "compatibility with existing file formats". It is an essential
aspect of any application level "interoperability" initiative.
Microsoft refuses to release the blueprints / documentation of their
legacy binary file formats needed for all conversion efforts -
including the unique application level in-memory-binary-representation
model that internal ODF plugins must deal with.
Technical Committee has many ramifications, not the least of which is
maintain the "catch 22 - caught between a rock and a hard place"
situation internal ODF plugins are trapped in. There are three
methods Sun uses to defeat or diminish efforts to improve the
pathetically poor, ZERO "compatibility-interoperability
and, "let the translators deal with it".
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.
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~