Het einde van ODF ?

Het einde van ODF ?

De grenzen van OpenDocument Format worden onmiskenbaar bepaald door de harde realiteit van door Microsoft Office gepenetreerde bedrijfsprocessen. Maar wat betekent dat nou eigenlijk voor interoperabiliteit in de vooral door FUD (Fear, Uncertainty en Doubt) van alle belangrijke oorlogvoerende partijen gedomineerde bestandsformatenstrijd ?

Eerst ODF.

Ondanks het groeiende acceptatieniveau wereldwijd voor het formaat, lijkt de strijd grotendeels gestreden – en niet ten faveure van ODF. Massachusetts heeft publiekelijk het mandaat voor open formaten aangepast om de ECMA-standaard 376: Office Open XML (OOXML) daarin een plaats te geven. Dat zat erin sinds in oktober 2006 Louis Gutierrez als CIO van Massachusetts opstapte. Dat was een duidelijk signaal dat ODF in Massachusetts niet zou slagen. De enige verrassing is dat de nieuwe CIO, Bethann Pepoli, er zo lang over zou doen om de aankondiging te doen dat OOXML officieel als een open XML-formaat zou worden erkend. Op 2 augustus gebeurde dat ook: OOXML krijgt dezelfde status in Massachusetts als ODF.


Hoe bepaald kan worden dat OOXML een open formaat is, terwijl de Microsoft Open Specification Promise geen andere ontwikkelaar toestaat om het formaat te implementeren, lijkt mij enigszins vreemd. Het lijkt een veilige gok dat de beslissing is gebaseerd op politieke en praktische overwegingen en niet of nauwelijks op een juridische analyse van de kwalificatie van OOXML als een open standaard. Pepoli zei: 'the state needs to pick up the pace in adopting XML-based formats and we think now that to have both formats will make it easier'. Maar Pepoli zei wel dat de adoptie van OpenXML niet onomkeerbaar is: 'Someone could submit a comment and we could make a review of ETRM and make changes'. Die veranderingen zouden kunnen leiden tot de eliminatie van OOXML in de uiteindelijke versie van het eisenpakket. Maar gezien de zeer gepoliticeerde situatie in Massachusetts en de technische barrières voor de adoptie van ODF lijkt een dergelijke verandering niet voor de hand te liggen.

Maar een mysterie blijft waarom Massachusetts ervoor gekozen heeft om OOXML aan de open standaarden toe te voegen, als zelfs Microsoft Office zelf geen bestanden kan genereren in dat formaat. OOXML is een eenrichtings-importformaat voor Microsoft Office, een kreupele subset van Microsoft's eigen XML-formaat (MO-OXML). Als een overheidsorgaan uit Massachusetts een tender zou doen uitgaan voor applicaties die ECMA OOXML-formaten zouden moeten kunnen lezen en schrijven, dan kan Microsoft Office zelf niet eens in aanmerking komen. Blijkbaar is dat feit nog niet doorgedrongen in Massachusetts.

Andy Updegrove hoopte in zijn blog begrijpelijkerwijze dat publieke druk op Massachusetts het voorstel om OOXML toe te voegen aan het eisenpakket zou doen mislukken; hij is nu zeer teleurgesteld dat dat niet gelukt is. Maar de overwegingen in Massachusetts zijn wel de wurggreep waarin ODF gehouden wordt. Het mislukken van het invoeren van ODF in Massachusetts zal resulteren in de erkenning dat het onmogelijk is om ODF te implementeren in bedrijfsprocessen die zo strikt gebonden zijn aan de implementaties van Microsoft Office. Het is niet voor niets dat vijf staten in de Verenigde Staten, waaronder Californië, ODF verplichtende wetgeving hebben afgeschoten. Ondanks de massale druk van SUN en IBM die probeerden een 'rip out and replace' implementatie van ODF af te dwingen.

Veel mensen denken dat implementatie van ODF even eenvoudig is als het downloaden van OpenOffice.org. Dat de conversie van de bestaande documenten naar ODF zonder problemen vol-automatisch plaatsvindt. OpenOffice is gratis. Dus: wat houdt iemand tegen ?

Het probleem is dat de eisen op organisatieniveau hoger zijn. Er is zwaar geinvesteerd in geautomatiseerde bedrijfsprocessen, waarin de kantoorautomatisering in veel organisaties zo goed als cruciaal is. Er is in de meeste situaties geen mogelijkheid om een handmatige inspectie uit te voeren op de geconverteerde documenten. Een vlekkeloze integratie van applicaties is nodig, en de bestaande organisatorische documenten zijn zo goed als volledig opgeslagen in Microsoft's binaire formaten. De betrouwbaarheid van documentenconversie dient zeer hoog te zijn. Vanwege compliance-overwegingen eist de wetgeving een 100 % betrouwbaarheid in de migratie van binaire documenten naar XML. Er bestaat geen 'archief'-wet die niet eist dat opgeslagen documenten accuraat worden behouden. Wat nog veel belangrijker is: er bestaat in de meeste bedrijven meer dan 15 jaar ervaring in het bouwen van bedrijfsprocessen met volledig geintegreerde applicaties en andere client/server integratie, op basis van MS Office. De afhankelijkheid van die applicatie is bijna 100 %.

Een klassieke 'vendor lock-in', met een waarlijk, formeel nooit uitgesproken monopolie.

De barrière voor ODF applicaties en ODF is dus dubbel. Elke implementatie van ODF moet de binaire formaten van Microsoft converteren en vervolgens in staat zijn om in de voorheen aan MS Office gebonden bedrijfsprocessen te integreren, zonder corruptie van de gegevens. De impliceert een vlekkeloze interoperabiliteit, zonder verlies van gegevens, wat in de OASIS ODF Technical Committee als 'high-fidelity migration and business process use cases' is aangeduid.

De kosten en de verstoring die een 'rip-out-and-replace' migratie naar ODF op bedrijfsniveau teweegbrengt, zijn onvoorstelbaar hoog. München bijvoorbeeld besteedde meer dan 3000 euro per werkplek aan de migratie van MS Office naar OpenOffice.org, waarbij het grootste deel van de kosten toe te schrijven valt aan de conversie van bestanden en het vervangen van processcripts in applicaties. Toch is 'rip-out-and-replace' de enige oplossing die ODF-leveranciers aanbieden aan bedrijven en overheden met integratie- en migratieeisen van hoge betrouwbaarheid. Een van IBM's eigen experts in service-oriented architecture stelde het volgende: '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'. De verantwoordelijken voor ODF binnen IBM hebben die uitspraak blijkbaar nooit opgevangen.

Want IBM en SUN blijven de belangrijkste vertegenwoordigers voor de 'rip-out-and-replace' migratie naar ODF. Ze gaan er blijkbaar vanuit dat goede ondersteuning voor ODF in MS Office de levenscyclus van dat product verlengt. Zij vergeten blijkbaar het feit dat interoperabiliteit van hoge betrouwbaarheid de sleutel is voor de infiltratie van ODF applicaties in bedrijfsprocessen gebonden aan MS Office.

Is de dubbele barrière te slechten ? Ja, maar beide oplossingen zijn niet direct acceptabel voor grote gedeelten van de gebruikers. De eerste oplossing is het gebruik van een interne ODF-plug-in in MS Office. De tweede oplossing is pragmatischer en verwijst naar het gebruikmaken van een andere ISO-standaard voor het behouden van documenten op langere termijn.

De eerste benadering, een Office plug-in, is dezelfde manier als waarop Microsoft zelf bestaande documenten en scripts voor bedrijfsprocessen migreert naar de eigen MO-OXML-formaten. Interne ODF plug-ins zijn klonen van de MO-OXML-plug-in, geinstalleerd door het MS Office 2007 Compatibility Pack in vroegere versies van MS Office. Dit is op zich geen probleem. Maar de grote ODF-applicatie verkopers weigeren om de enige bestaande interne plug-in die de ODF Community wilden betrekken bij het werk, Da Vinci , te ondersteunen. Door die weigering kan geen interoperabiliteit worden gerealiseerd met andere ODF-applicaties als OpenOffice.org. Dat is omdat Sun, dat het ODF standaardisatieproces controleert, OpenOffice zo heeft geprogrammeerd dat het dergelijke ODF-conversies niet accepteert.

Overheden maken dus zowel ODF als OOXML tot open standaard: ze hebben geen andere keuze. Zoals de situatie nu is, is de interne OOXML-plug-in de belangrijkste argumentatie tegen de ODF-leveranciers. Deze plug-in biedt immers mogelijkheid om op een kosteneffectieve en niet-verstorende manier over te stappen op XML (ook al is dat dan een MS-XML, dat niet volledig compatibel is met allerlei XML-standaarden).

De ODF-leveranciers hebben de grote fout gemaakt bedrijven en overheden geen keus te laten.

De tweede benadering is wat complexer:

  • gebruik OOXML om de binaire bestandsformaten uit het verleden te converteren naar XML.
  • converteer deze bestanden naar PDF/A (de ISO-standaard voor langdurig te bewaren documenten).
  • gebruik in de dagelijkse praktijk de converters naar ODF, een goede bestandstandaard voor de dagelijkse procespraktijk. Dit wil niet zeggen dat afscheid genomen moet worden van MS Office, vanwege de Da Vinci plug-in.
  • converteer alle bestanden die voor langere tijd (= langer dan 1 jaar) moeten worden bewaard naar PDF/A.
  • indien gewenst: bepaal het moment van transitie naar ODF-based Office-suites.

Het lijkt erop dat vooral binnen de Europese Gemeenschap het geduld met de grote leveranciers (SUN, IBM, Microsoft met name) op is. Op een conferentie begin maart 2007 hebben de lidstaten een aantal eisen aan de industrie gesteld. De uitkomsten kwamen hierop neer: zowel ODF als OOXML zijn niet acceptabel, Microsoft en de grote ODF-leveranciers dienen samen te werken aan de ontwikkeling van een enkel geharmoniseerd bestandsformaat, waarbij ODF de basis dient te leveren. De 'simpele' conclusies: 'There is a general dissatisfaction with the perspective of having competing standards. There should be one format for one purpose. (Administrations should be able to standardize (internally) on a minimal set of formats). No incomplete implementations, no proprietary extensions. Products should support all relevant standards and standards used should be supported by multiple products. Conformance testing and document validation possibilities are needed in order to facilitate mapping/conversion. Handle the legacy/safeguard accessibility'.

De EG dreigt nu een convergentie tussen ODF en OOXML af te dwingen in een Open Document Exchange Format (ODEF). Interne plug-ins (voor alle office-applicaties) kunnen ODEF realiseren; het is de enige manier waarop los van de grote leveranciers de bovenstaande eisen in applicaties kunnen worden gerealiseerd.

Wat wél duidelijk is geworden in deze bestandsformatenstrijd is dat standaardisatie-organen als ECMA, OASIS en ISO hebben gefaald om de belangen van de softwaregebruikers te beschermen tegen de belangen van de leveranciers om incompatibiliteit in stand te houden. Ze zijn speelbal geworden van de grote bedrijven, die vaak als sponsoren van de betreffende standaardisatie-werkgroepen optreden. Het wordt tijd om die afhankelijkheid te beeindigen.

juli 2007-maart 2008

Share This:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.