Game Over? Probably. I've been expecting Massachusetts to publicly revise the ODF mandate to include OOXML ever since Louis Gutierrez resigned in early October of 2006. That was as clear a signal that ODF had failed in Massachusetts as anyone needed.
The only surprise is that it took the new CIO, Beth Pepoli so long to make the announcement that OOXML would be recognized as an officially recognized open XML file format going forward.
Andy UpDegrove of course does his best to downplay the significance of this announcement. But how can this not be the deathnell for ODF?
The failure of ODF in Massachusetts has resulted in a world wide recognition that it is impossible to implement ODF.
This is exactly what happened to ODF mandate legislature in California. The CIO's in California uniformly rejected both ODF legislation and Sun's hapless effort to set up an ODF Pilot Study based on what had happened in Massachusetts. If Mass couldn't implement ODF, than they saw no reason for them to try.
And it does come down to "implementation".
Most people think the implementation of ODF is as easy as downloading OepnOffice and converting your legacy docuemnts to ODF as they are used. Simply fix the artifacts of conversion in process, and never look back. OOo is free. So what's not to like?
Well, the problem is that the world has fifteen plus years of building business processes, line of business integrated applications and other client/server integration on top of the MSOffice application suite. These business processes are bound hard to MSOffice.
So the barrier for OpenOffice and ODF is twofold. Any implementation of ODF must overcome both the binary documents conversion barrier, and, the MSOffice bound business process barrier.
The cost and disruption of a rip out and replace migration to ODF is impossibly high! Yet that's the only solution ODF vendors offer governments.
Is there a way around this impossibly high dual barrier? Yes, but it involves the use of internal ODF plugins for MSOffice.
This should not come as a surprise because the internal plugin route is exactly how Microsoft migrates existing docuemnts and business processes to their XML. The internal ODF plugins are simply clones of the Microsoft OOXML plugin, installed through the MS XML Compatibiltiy Kit.
Massachusetts came to this conclussion after conducting a year long ODF Pilot Study. Before the Study was even complete, Massachusetts IT realized the impossibility of the dual barriers. They issued an unprecedented Request for Information concerning the possibility of a ODF plugin for MSOffice. One that would be able to "internally" convert documents so transparently and with such high fidelity that there woudl be NO DISRUPTION to existign business processes.
Which means that the ODF internal plugins for MSOffice had to match the performance of the Microsoft internal OOXML plugins!
Incredibly, this can actually be done. Where ODF failed in Massachusetts is not with the internal ODF plugins, but with the support of ODF vendors for da Vinci, which was the only internal plugin willing to go the ODF Communtiy route Louis Gutierrez desired.
So now we have the Massachusetts and Denmark both recognizing OOXML and ODF as open XML file formats. More will follow. The problem with this "recognition" is that the Microsoft OOXML plugin is the only cost effective (free) and NON DISRUPTIVE way for existing MSOffice bound workgroups and workflows to move to XML.
The truth is, ODF vendors and communities left governemnts with no other choice but to go with OOXML as the only way to migrate existing systems to XML.
Sad, isn't it? ~ge~
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.
Page Comments
The only surprise is that it took the new CIO, Beth Pepoli so long to make the announcement that OOXML would be recognized as an officially recognized open XML file format going forward.
Andy UpDegrove of course does his best to downplay the significance of this announcement. But how can this not be the deathnell for ODF?
The failure of ODF in Massachusetts has resulted in a world wide recognition that it is impossible to implement ODF.
This is exactly what happened to ODF mandate legislature in California. The CIO's in California uniformly rejected both ODF legislation and Sun's hapless effort to set up an ODF Pilot Study based on what had happened in Massachusetts. If Mass couldn't implement ODF, than they saw no reason for them to try.
And it does come down to "implementation".
Most people think the implementation of ODF is as easy as downloading OepnOffice and converting your legacy docuemnts to ODF as they are used. Simply fix the artifacts of conversion in process, and never look back. OOo is free. So what's not to like?
Well, the problem is that the world has fifteen plus years of building business processes, line of business integrated applications and other client/server integration on top of the MSOffice application suite. These business processes are bound hard to MSOffice.
So the barrier for OpenOffice and ODF is twofold. Any implementation of ODF must overcome both the binary documents conversion barrier, and, the MSOffice bound business process barrier.
The cost and disruption of a rip out and replace migration to ODF is impossibly high! Yet that's the only solution ODF vendors offer governments.
Is there a way around this impossibly high dual barrier? Yes, but it involves the use of internal ODF plugins for MSOffice.
This should not come as a surprise because the internal plugin route is exactly how Microsoft migrates existing docuemnts and business processes to their XML. The internal ODF plugins are simply clones of the Microsoft OOXML plugin, installed through the MS XML Compatibiltiy Kit.
Massachusetts came to this conclussion after conducting a year long ODF Pilot Study. Before the Study was even complete, Massachusetts IT realized the impossibility of the dual barriers. They issued an unprecedented Request for Information concerning the possibility of a ODF plugin for MSOffice. One that would be able to "internally" convert documents so transparently and with such high fidelity that there woudl be NO DISRUPTION to existign business processes.
Which means that the ODF internal plugins for MSOffice had to match the performance of the Microsoft internal OOXML plugins!
Incredibly, this can actually be done. Where ODF failed in Massachusetts is not with the internal ODF plugins, but with the support of ODF vendors for da Vinci, which was the only internal plugin willing to go the ODF Communtiy route Louis Gutierrez desired.
So now we have the Massachusetts and Denmark both recognizing OOXML and ODF as open XML file formats. More will follow. The problem with this "recognition" is that the Microsoft OOXML plugin is the only cost effective (free) and NON DISRUPTIVE way for existing MSOffice bound workgroups and workflows to move to XML.
The truth is, ODF vendors and communities left governemnts with no other choice but to go with OOXML as the only way to migrate existing systems to XML.
Sad, isn't it?
~ge~
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.