It’s been a little while since I tackled ODF in any sort of detail, and several people have dropped me notes remarking on this fact. Considering that, and the ODF related announcements that have been trickling out, I thought I’d take the opportunity to do another ODF Q&A.
Q: First, and most importantly, what’s with the dearth of ODF commentary? You’ve been relatively silent on the subject in recent weeks – why?
A: There are two real answers to this: first, there are other bloggers – notably Andy Updegrove – that are doing an outstanding job covering ODF related news. They’ll keep you more up to date than I possibly could, given that ODF is but one of many technologies that I cover. Second, there hasn’t been a whole lot to discuss, at least from the perspective of the angles that I cover, mainly vendor and developer interests. I feel as if I’ve discussed in sufficient detail the technical aspects of the format, at least until we see some further exploration of the programmatic manipulation the format permits. As I discussed recently with an SI member of the ODF Alliance, I’m now waiting to see evidence – or a lackthereof – of traction.
Q: So is it fair to construe your silence as evidence that the ODF is not gaining traction?
A: No, certainly not. While there are many who are pessimistic about the chance that the ODF will gain traction, I remain fairly open minded about its prospects.
Q: Who’s pessimistic about it?
A: Well, while at the Intellectual Property conference in Connecticut earlier this week, I had occasion to have lunch with some analysts from a much larger firm. One of these expressed some frustration with the ODF debate, contending that for all the hype the format was generating in the press, he saw very little interest or demand in it from his customer base. He believed that they had very little desire or incentive to disrupt the Microsoft status quo, and therefore was relatively negative on the opportunity in front of the ODF. Needless to say, I don’t agree.
Q: Why? Are you seeing substantial interest?
A: Well, it’s not really that, though from what I’m hearing we may see some very interesting announcements come out of the EU and – possibly – the US within the near term. As mentioned above, apart from Massachusetts, there haven’t been many high profile, major wins for the ODF crowd to crow about in recent months. It is instead the status quo basis to the other analyst’s argument that I take exception to.
Q: How so? What do you believe is inaccurate about the status quo? Isn’t it true that the Microsoft Office install base has a remarkable inertia, a resistance to change?
A: Absolutely, yes. But that’s conflating format with implementation, which I believe is a mistake. While the Office application itself may indeed be the status quo for the foreseeable future – hence the importance of the recently announced plug in, which I’ll get to in a moment – the format itself is not. Even for businesses and governments that decide that Microsoft Office is their platform for the foreseeable future, a transition of format is inevitable. Office 12, as has been well documented, will herald the entrance of a new default file format – the Office Open XML format; Microsoft’s ODF alternative. While support for the old binary formats will be present, there’s no question that it’s being deprecated in favor of XML based alternatives. So whichever path office productivity customers choose – be that Microsoft or its competitors – a format transition is likely to be in the cards at some point in the future. I’ve believed for some time that a plugin for Office that supports ODF was inevitable; Microsoft has even acknowledged in conversations I’ve had with them that third parties could very well deliver such functionality.
So given the fact that Office itself may very well support ODF as a format, and the fact that customers are likely to have to make a transition away from the binary format at some point anyhow, it doesn’t make sense to me to discount ODF out of hand on the basis of inertia.
Q: Let’s talk about that plugin, then – I’m assuming you read about it on GROKLAW?
A: I did indeed, off a link from Slashdot, I think. But the plugin itself is, in my mind, potentially very significant. I say potentially because not having tried the plugin, I can’t speak to how faithful the plugin is to the content authoring process – i.e. how much of the work done in a Microsoft spreadsheet, for example, can be accurately output to an ODF formatted file. I’ve contacted Gary Edwards requesting a version of the plugin for testing, and while I don’t have access to one as yet he’s been kind enough to get me on the list of evaluators. But even should the plugin only provide, say, 75% fidelity to Microsoft Office, it’s still a big step in the right direction.
Q: Why is that?
A: Because it begins to divorce format from implementation, which is critical to the process of evaluating the formats (and the applications) fairly. As long as choice of format is restricted on a platform basis, the selection process will always be unduly influenced by unnecessary technical factors. That’s why I’ve thought that a plugin was inevitable; whether it came out of France as once rumored, or from the Australian server-side approach, someone was very likely to find a means of outputting ODF from Microsoft Office – thus mitigating the ubiquitousness of Microsoft Office.
Q: What do you make of the David Berlind’s piece concerning the manner in which the ODF plugin folks appear to have reverse engineered Microsoft Office? Is that an issue?
A: As I told one reporter this AM, I’m not qualified to issue an opinion on that one because I’m not a lawyer, and two because I don’t have enough information on precisely what was reverse engineered. I will say, however, that this would not be the first time that Office related assets were reverse engineered; the binary formats, for example, have been subject to that process previously.
Q: Any thoughts on whether the plug in would be good or bad for Microsoft?
A: Given that I’ve consistently recommended that Microsoft support the ODF alongside its own format within the Office product, it won’t come as any surprise that I believe that Office support for ODF is potentially a very good thing for the folks from Redmond. And while they’ve allowed for the possibility that this could occur before, I doubt very much that they’re excited about it. If they saw the same opportunity that I did, why would they not simply support ODF within the product, much as they do RTF?
Q: What about the ISO certification – does it play a role in the adoption process?
A: Certainly – the question is to what degree? My initial reaction was that it’s a positive for the ODF, but not one likely to change dramatically the balance of power. Not a tipping point trigger, in other words. If what I’m hearing from other vendors is correct, however, I may be underselling the importance of the certification. It’s significant for the EU in particular, from what I’m told. So while I still believe that it’s a valuable validation of the viability of the format itself – not to mention a differentiator, at least temporarily, from the Microsoft alternative format – I’m not entirely convinced it alone is a game changer. This is what I told one ODF interested party when he asked whether or not I planned to do a Q&A on the subject.
Q: What other news have you heard about the ODF?
A: Well, if you recall, I’ve been talking for a while about ODF being interesting precisely because it’s more than a mere office productivity file format – it’s a programmatically manipulable container. Some have responded that this was already possible with the Office binary formats, via COM objects, but I don’t buy that because everything I’ve heard about that indicates that that process is too difficult. The lack of support for this functionality within obvious applications such as messaging and collaboration platforms validates this belief.
But with ODF, as well as it’s Microsoft alternative, we’re entering into an era in which office productivity assets should be eminently decomposable. Here’s what I said about this before:
What’s brand new with the advent of the ODF and its Microsoft counterpart the Office Open XML Formats are the implications vis a vis the ability to manipulate documents programmatically. With the advent of these formats, we could see the advent of far more intelligent messaging, workflow, etc systems because they’ll have the ability to deconstruct these documents at very granular levels.
To many of you, no doubt, that’s just a bunch of meaningless technical babble, so here’s an example that may make it more real: you know how organizations have been bitten in the past by sending out documents that, unbeknownst to them, included all sorts of unflattering or embarrassing comments and markup? With the previous generation of binary office formats, there wasn’t too much you could do because the documents were opaque to any application besides the ones that produced it. The new XML based formats, on the other hand, are essentially zip containers with a bunch of XML components in them. What if before you emailed someone external to the system, the messaging server could deconstruct the document into various pieces, remove any comments or markup, then reconstruct the document without touching the content? That’s what the kind of document manipulation made possible by the transition from binary to XML formats.
That’s just one example, of course; there are likely hundreds if not thousands of other such scenarios buried within corporate workflow and routing procedures. This is, in part, what ODF advocates such as Gary Edwards and Sam Hiser mean when they talk about the format as a “Universal Transformation Layer.” What’s been interesting, however, is that in the probably half a dozen conversations I’ve had with messaging/worklow/etc providers over the past couple of weeks, I’ve heard a lot of enthusiasm for the ODF itself, but little in the way of plans – NDA or otherwise – to fully leverage the XML nature of the format.
Sooner rather than later, however, I expect one or more of the messaging/workflow/etc providers to actively embrace the ODF – and it would be foolish to believe that Microsoft doesn’t have plans in this regard for its MSXML format. The interesting question for many vendors will be – how might the new XML formats overlap – or not – with electronic forms?
Interestingly, the comments example cited above resonated on a call I had this morning, in which a vendor described receiving contract proposals in Word that contained hidden markup detailing presumably confidential legal interpretations and the like.
The important point, as noted above, is that that is but one example. Think of mashups: Google simply provides an online mapping service, and creative developers figure out how to layer in real estate listings, Chicago crime data – even sex offender addresses that might be local to you. Is it unreasonable to expect similar creativity around office productivity documents? I don’t believe so, and I’ve been told to expect some public announcements on this subject in the near future. Will bring you more on those when I’m able.
Q: Any other last minute items to discuss?
A: Just that Google’s been pretty quiet on the topic since acquiring Writely, but I’m wondering if there aren’t some ODF possibilities within the Google Calendar. Something like, oh, export the agenda view to an ODF file. No word on that yet, but I’m going to be watching closely, as that might be the first true sign of a Google Office.
No Comments