Ms. Neelie Kroes Commissioner DG COMPETITION Bourgetlaan 1 1140 Evere Bruxelles/Brussel SUBJECT: Suggestions for Interoperability Undertaking The Hague, September 28th 2009 Dear Commissioner Kroes, We read with interest the article in several media published last week1 where you were quoted as saying that the Commission is near to closing a deal on a number of issues in the case against Microsoft. We think that this inquiry is of great importance, and that restoring a level playing field in this area is essential for the future ambitions of Europe. On behalf of OpenDoc Society we would like to respond to the "Interoperability Undertaking"-proposal2 from Microsoft that was made to the European Commission, hoping that this will be of help to you in finding effective remedies to the issues that matter most in this case. OpenDoc Society is an international member-based not-for-profit organisation headquartered in Europe, with individual and organisational members around the planet. Our organisational members range from large software vendors and open source communities to small and medium sized enterprises, from (also European) government organisations to academia and research, and from education and cultural institutions up to special needs groups, registered charities and the military. Our goal is to promote best practises for productivity applications, most notably in the area of open standards, document exchange and processing. In this document, we will respond to the Undertaking from our expert knowledge in this domain and make a number of proposals to improve that document in order to make it effective given the purposes it is drafted for. We hope you will forgive us the sometimes deeply technical nature of these comments. From our perspective it seems that good progress has been made in several other areas of the European Commission's investigation, e.g. in the browser part where the use of web standards will soon be the default. Yet, in the field of productivity applications (probably economically and societally the most important area) many serious issues unique to that domain are still likely to remain if the Undertaking were to stay limited to the current proposal. These issues may not be the most eye-catching in this situation where different investigations are on top of each other, yet they are essential if we want real solutions that work for the customer and for the market. Office file format lock-in is probably the single strongest impediment to customer choice in IT. In the area of personal productivity applications we have a long way to go before the market can restore itself to health, because issues are densely interwoven across different levels and across time. With the current proposals it is unlikely that we will see a level playing field: the use of open standards (even those with a large traction in the market, such as ODF) does not stand a fair chance, which hampers choice and makes real competition almost impossible. That in turn will remain to have a huge effect on the IT market in general for many years to come. It is to be commended that Microsoft is thinking about giving people an active choice to choose ODF as their default file format. But in contrast with the browser it is only currently promising this for a very small minority of their users – excluding an estimated 80% of users that use a version other than the last version of their Office for Windows product. While Microsoft has been delivering 'Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats' adding support for its newly developed (non-standardised) Office 2007 for Windows file formats3 for all its legacy versions on all platforms for a number of years, ODF would be supported only on Office 2007 SP2 for Windows and subsequent versions. In fact, in versions before Office 2007 for Windows ODF is currently still not officially supported under warranty, even though the software to do this has been available for years in an outsourced project coordinated and funded by 1 http://www.nytimes.com/2009/09/23/business/global/23kroes.html 2 http://www.microsoft.com/presspass/presskits/eu-msft/docs/Microsoft_Interoperability_Undertaking.doc 3 These 'final' legacy formats were created midway the drafting of ECMA 376, the precursor to IS29500. The differences with both these formats are not publicly known. OpenDoc Society ÷ Wibautstraat 150 ÷ 1091 GR ÷ Amsterdam The Netherlands ÷ [email protected] Microsoft. Also there has not been any sign of supporting ODF for Microsoft Office for Mac, let alone its legacy versions. Its free Office Viewers for the Windows platform don't support ODF as of yet. We consider that 'second class citizenship' of ODF to be extremely harmful to choice and competition. We note also that the actual proposed 'file format ballot screen' has to undergo significant scrutiny, because the actual wording and interface usability can have a huge impact on the outcome. Our organisation is very willing to help the Commission and Microsoft strike the right chord in this respect. There are of course many other issues. To this day there are still no complete specifications of Microsoft's legacy formats (from the various historical binary formats to the Office 2007 for Windows default file formats).4 The amount of documentation compared to the available specifications for ECMA 376 and IS29500 is rather small, and many embedded elements are not even covered in those – posing a risk with regards to patents. Since there is also no authoritative mapping of the Office for Windows file formats on ODF or even on ECMA 376 or IS29500, fully reliable real-world interoperability with current and historical Microsoft products remains impossible. Providing a smooth transition between old and new file formats is a key element in realising a migration scenario where applications supporting a new standard interact with existing applications. Writing an implementation to reliably support the legacy Microsoft file formats is currently like hitting a moving target in the dark, and often involves trial and error in the black art of software reverse engineering. Since there are no official test suites for the legacy file formats, competitors can verify nor prove to customers they handle these formats in the right way. The absence of complete specifications and mappings to standards (and vice versa) and the lack of a test suite puts other implementations at a major disadvantage in any practical scenario which involves interaction with older Microsoft products – which still have a dominant market share by themselves. At an implementation level there is still much to be desired in the current Office 2007 for Windows implementation of the ODF standard. Currently Microsoft Office 2007 for Windows fails to retain all revision history information when saving to an ODF file. There is no practical reason for this, and fixing that unnecessary information loss is crucial to the Microsoft user base that want to make the switch to application-independent and future-proof ODF. In addition, Office 2007 for Windows behaves without much respect towards other ODF applications - destroying many data elements on import which the ODF specifications say should be kept. This effectively disables many of the innovative uses of ODF and foreshadows immediate incompatibility with future versions of ODF. This is a good demonstration of the fact that the promise as made under the 'General Provisions' in the 'Interoperability Commitments' of the Undertaking will not suffice: the publicly available implementer notes for ODF published by Microsoft state that these elements are not supported, and that would be sufficient according to the principles (set out under point 8 of the Undertaking). The fact that the Office 2007 for Windows software is able to handle custom XML as part of its Office 2007 for Windows native file format proves that this behaviour is unnecessary. Clearly, a complete, faithful and trustworthy implementation of ODF by Microsoft matters a great deal – one only needs to make a small step aside in this dossier to look at the browser case where barely noticeable implementation deviations from the standard in Microsoft products had immense effect on the outcome of the browser war. With regards to future versions of the ODF standard we are also concerned about the huge delay in supporting any new ODF version. Please note that the next expected updates of the standard will contain functionality such as OpenFormula spreadsheet formula's which are essential for the professional market and already now offer full interoperability with many products already on the market. Any delay in full support by Microsoft has a huge impact on the market. The Undertaking proposal talks about waiting for nine months after publication by ISO in order to support it. Since Microsoft participates in OASIS within the ODF technical committee, there is no reason why they should wait for final ISO publication before supporting a new ODF feature. Currently, Microsoft already like most vendors has chosen in its current implementations to support a version of ODF published only by OASIS (ODF 1.1) rather than wait for the adoption of ISO of that same standard which is now in the pipeline. Note also that in the case of IS29500, no such caution to await the publication of the standard was taken by Microsoft (even shipping the product before the standard was halfway finished) with as a result the severe differences between Office 2007 for Windows file formats, ECMA 376 and IS29500. Unless Microsoft commits to the same type of caution for all of the file formats it supports, this would put ODF at a definite disadvantage. The fair solution is to require that within a period of nine months after a feature is approved in either OASIS or ISO it is implemented by Microsoft in all relevant products.