Ha a teljes kompatibilitás a cél, akkor sajnos nem elég ismerni a szabványt, 1000 példa van arra hogy OOXML szabvány nem elég, meg kell nézni, hogy néz ki az adott dokumentum a MS Office-ban, és az alapján implementálni. Azzal a nehezítéssel, hogy az MS Office forráskódja nem tanulmányozható szabadon. Biztos lehet fordított esetet is találni, bár nem jellemző, hogy valaki ODF szabványra alapozott teljes irodai csomagot fejlesztene az eddigi implementációktól függetlenül. A LibreOffice kb. jelenleg az egyetlen projekt, amely az ODF szabvány fejlesztésében érdekelt. Nem tudom, ebben a helyzetben mi vendor lock-in és mi nem. LibreOffice nem csak egy vendortól érhető el, és szabadon módosítható is. Azt hiszem, hogy a gyakorlatban nem szokott az a kérdés felmerülni, hogy vendor lock-in-be kerülök-e, ha ODF-re és LibreOffice-ra alapozom az irodai dokumentumok kezelését.
Az ODF szabvány bővítése leginkább az OOXML interoperabilitás miatt szokott történni. Például kiderül, hogy Excelben lehet a munkalapfüleket színezni, LibreOffice-ban meg nem. Érkezik egy megkeresés, hogy ez kell. Első lépés a dokumentummodell bővítése, aztán az OOXML import és export, aztán – ez policy – az ODF export és import, mert az ODF a natív formátum, abban mindent kell tudni menteni. Utána jön, hogy ezt az extra attribútumot, amire eredetileg nem gondoltak az ODF szabványban, be kell nyújtani, és hosszú évek múltán bekerül. Addig ha mondjuk a Gnumeric akar színes munkalapfüleket importálni LibreOffice által készített .ods-ből, akkor megnézi, hogy milyen attribútumot használt erre a LibreOffice.