Microsoft adds “Save as ODF” to Office 2007 Service Pack 2

Updated. April 28, 2009. Office 2007 SP2 is available for download. For more information: https://blogs.technet.com/gray_knowlton/archive/2009/04/27/office-2007-service-pack-2-kiosk.aspx

For those of you who have been following the file format issue for a while, you'll recognize today's action by Microsoft as another significant step forward in enabling interoperability. This hopefully sends a signal (again) to our customers that we are committed (like all successful software businesses are) to addressing the needs of people who use our products by providing choice and interoperability. (Read more, Read even more)

If you missed the announcement, it roughly said the following:

Microsoft Office functionality will be updated to include ODF, PDF and XPS support:

  • Microsoft Office 2007 Service Pack 2 will include both "Save as ODF" and "Save as PDF and XPS" functionality.
  • The next major release of Microsoft Office, currently codenamed "Office 14," will update its support for IS29500, the specification that resulted from the ISO process.

Microsoft will contribute to the future evolution of the ODF and Open XML specifications.

  • Microsoft will join the OASIS ODF Technical Committee
  • Microsoft will participate in the ISO/IEC JTC1 SC-34 committee responsible for the maintenance of Open XML (IS29500)
  • Microsoft will participate in the ISO/IEC JTC1 SC-34 committee responsible for the maintenance of ODF (IS26300)
  • Microsoft will participate in the ISO/IEC JTC1 SC-34 committee responsible for interoperability between IS29500 and IS26300

Microsoft will contribute to the developments of other document format standards:

  • Microsoft will participate in the standardization of XPS underway in ECMA
  • Microsoft will participate in future maintenance of PDF in AIIM
  • Microsoft will work to promote interoperability with Open XML and UOF, the Chinese national document format standard

A lot of the folks who read the blogs are (rightfully) consumed with the "why?" question… or perhaps even the "Why now?" question. I'd like to take a little time to explain both. I think I can help add some context about why this decision was made, and why we think now is an appropriate time to take these steps.

There are really two central catalysts for these actions. One of these is the feedback we have received from the regulatory environment. There is a high degree of interest in our working with other software vendors to improve information exchange through the use of standardized technologies. In addition, we remain committed to promoting interoperability in our products which means creating the technology bridges necessary for the successful exchange of data with other solutions.

The second catalyst is how these advancements will help drive success in our business. Folks will offer theories across the spectrum about what Microsoft is "trying to do" or what these actions "mean." I'd like to offer a very simple rationale to explain why this is a net positive for our business, and to illustrate some of the thinking about our timing for the adoption of ODF.

Success in our industry (like a lot of other industries) boils down to successfully addressing the needs of customers. By offering greater choice for file formats, our products address more scenarios and provide greater flexibility in enabling specific solutions. From a pragmatic standpoint, adding ODF to Office allows us to re-focus Office on product capabilities rather than a debate about file formats. We're quite comfortable when we compete in the marketplace on these merits.

A natural follow-on question seeks to understand why we would bother with Open XML when we could have just supported ODF from the beginning and moved on…

(I'm oversimplifying a bit here, but) questions about compatibility and moving legacy content forward were very important to our customers, and we were already well down the road with XML-based formats that were designed to represent legacy content. Because ODF side-stepped the compatibility question, we were left to solve (continue solving) that challenge elsewhere; the aversion to dealing with legacy content created a real problem for customers who want to transition to more open file formats.

Speaking very plainly, business continuity is one of the most important drivers of software purchasing decisions. The goals of Open XML with regard to compatibility and preserving legacy content are things that we simply could not do without.

Those who have been involved with Microsoft Office for many years will remember the problems created when Microsoft essentially "flipped the switch" on a new document format for Office '97, offering little consideration for compatibility with existing applications. This had a negative effect on our business, and we were not keen to repeat the mistake. In many standards committee meetings, compatibility was regarded as a "factor," but in reality, the list of things that rank higher in importance is very short.

Open XML is a necessary, worthy standard; it is unique in its intent to address this problem. We will sustain our investment in Open XML through participation in ECMA and ISO, as well as in the development community. We are also committed to having a high-quality implementation of ODF. We accept the responsibility of driving toward interoperability with other products and platforms. We will work with supporters of Open XML, ODF, PDF and XPS to achieve interoperability.

Achieving meaningful, successful interoperability involves participation in the evolution of the standards as well as conducting public forums on real-world implementation issues. In our early testing we are observing that every product implementing these standards has some level of variation from the written spec. If you've been around standards for a while, you'll know this is common, and requires dialog to establish best practices & patterns. This is our reason for joining the OASIS, AIIM and ISO committees, as well as our motivation for hosting public forums like OpenXMLDeveloper.org to discuss our implementation of the formats. These are environments where we hope to learn as much as we contribute… we now get to the real work of enabling interoperability rather than theorizing about its potential in committees. I know the work will be challenging, but I am hopeful that this will ground the document format standards conversation in real-world implementation conversations, where we can uncover and resolve issues that make products share data with greater success.

Just some technical notes (and to tee up future posts) Office 2007 Service Pack 2 will incorporate support for ODF 1.1, to align to the other significant products and policies that support ODF today. SP2 will also support PDF 1.5, and the ISO standard PDF/A. These PDF versions are intended to maximize compatibility with the existing base of installed PDF viewing applications.

Office 14 will update our support for IS29500. The timing for this might seem strange, but I do hope the rationale is clear. ODF 1.1 is a completed specification. The final version of IS29500 is not published today. While we do support a significant portion of IS29500 already, the BRM changes and other issues raised in public forums will inform us on how to best move forward with IS29500… and it gives me a little time to address the compatibility considerations that will be an important part of any file format related changes in Office. ODF has a potential upside in expanding interoperability, but as always, business continuity requirements will have a significant effect on our approach to these file format changes. Our customers will accept nothing less…