Getting what you bargain for
The best way to assure that you get proper ODF support throughout your IT portfolio without any surprises, is by making support for the standard an integral part of your procurement process. By adding ODF support as a requirement at the start of each process, vendors know what they are expected to deliver and will only make bids or business offers taking ODF support into account - and will deliver accordingly.
If a vendor solution claims ODF conformance but is misrepresenting actual support, your contracts and the conditions you set at the time of procurement will help you get what you bargained for. If ODF support still needs significant work at the time of deployment, the vendor is actually contractually bound to deliver it according to clear requirements.
Boilerplate text for procurements
When you have to specify these requirements, it can be challenging to find the right wording for it. Below you will find boilerplate text for requiring ODF support.
You are free to use this text for any purpose, such as a tender document or procurement specification. If you have any suggestions for improvement, please let us know.
Special considerations for open source
Using open source software has some legal differences compared to solutions under proprietary conditions when dealing with procurement. Extensive legal analysis conducted by the European Commission (original text revealed that it is not considered procurement when open source software per se is acquired ("downloaded") and implemented by an organisation itself (without a service or support contract).
This means that organisations are legally free to use any open source solution without a formal tender procedure and without any delay. The fact that the software can be tried and used for free prior to any financial commitment is made, places open source applications at least at the legal level on an equal footing with legacy software already deployed in the organisation.
Once downloaded, additional support and services such as training or development may be acquired either separately or together. Depending on the total value of a contract, a tender may or may not be necessary. Because of the open source nature, there is no monopoly on providing any these services and so an organisation can choose suppliers based on quality, pricing, or other criteria it may determine itself. This allows organisations who choose specific open source solutions to solve their problem, to work fast and efficient. An organisation can take the initiative itself, and create a level playing field for its own IT application.
When to require ODF 1.3?
When an application, product or service is procured that is part of an information lifecycle dealing with revisable documents (texts, spreadsheets, presentations). This lifecycle involves creation, viewing, changing (including revisions), exchanging and/or archiving.
ODF is an open standard for storing and/or exchanging text documents (ODT), spreadsheets (ODS), charts and presentations (ODP). ODF is the successor of deprecated vendor specific formats such as .doc, .wpd, .xls and .ppt, which are no longer actively maintained. ODF is an XML format that is standardised by the OASIS consortium and which was subsequently adopted by ISO/IEC JTC1 SC34. ODF is suitable as a full-blown on-disk format for each of the types of documents mentioned, and can theoretically be used throughout the entire information life cycle. In the final phase the revisable version may be complemented by a version of a document in PDF. Whereas PDF is a simple 'digital printout' of a document and contains a frozen representation of its contents, a document stored in the ODF format will retain the entire functionality that it has during editing - including all metadata, calculations in (embedded) spreadsheets and diagrams, user defined fields, revision history, accessibility information and digital signatures. A PDF version of a document is intended to be a static version with a specific number of pages, a condition which is specifically not applicable in the case of 'living' office documents. A PDF version of a document therefore cannot be used by the recipient or processing application to for instance validate if the formula behind a certain calculation was in fact correct. When a document contains revision information ("change tracking"), this information is stored in a way so that each individual change may be reviewed and potentially approved or rejected.
In some cases information is best stored in PDF, while in others ODF is by far the preferred option. This not only depends on the producing end, but also on potentially unknown requirements at the receiving end. Making both formats available in parallel (whenever possible) is both a very flexible and user friendly option.
Where it concerns generating, importing, viewing, editing and storing revisable text documents, spreadsheets and presentations (including keeping track of changes to the document so they can be reviewed and individually approved) the application that is procured should be able to reliably work with documents that adhere to the current version of the OpenDocument Format standard (ODF 1.3) with full functionality and without loss of information.
Goal of the question
To determine whether an application or product supports the ODF format at the required maturity.
Examples of positive answers
Yes, our application/solution uses ODF as its default format and complies in full and without any restrictions regarding any of the requirements around ODF.
By using 'third party software' through a plugin or add-in our application is able to read, create and revise documents according to the ODF 1.3 standard. If the end user selects ODF as its default format, he or she will have no restrictions on the functionality of our software based on an incomplete implementation. We are not aware of any loss of information that would occur to documents edited or reviewed by our solution, provided that they conform to the ODF 1.3 specification.