InformationWeek article + some thoughts

Print Friendly

Podcast of this blog entry

David Gardner just published an article based on an interview we did this morning about the ODF Alliance and recent ODF news concerning Google and Microsoft. It is up to Google to say what they want about this, but, as I noted last night, ODF Alliance membership jumped by 20 members in the few days following the news of their membership. I interpret this as adding to the already accelerated momentum of ODF adoption as well as widespread support for helping it get implemented.

In the article I’m quoted on the cost issue. This was made very clear to me last week in London and Brussels in a way that I will paraphrase thusly: “we love the idea of open standards, we love the idea of real interoperability, we’re very happy to get away from vendor lock-in, but we really, truly adore the idea that we can save a tremendous amount of money.”

I know many of you will be thinking open source here, but the existence of commonly implemented open standards that are beyond a single vendor’s control means that there will be multiple, competitive implementations. This means better, more usable features, better security (because people will compete on this element), better performance, and lower cost. It is important to remember that ODF is just one example here. We’re going to see this repeated over and over again for other standards and in many industries.

So, to use our own example, when IBM ships the Hannover release of Lotus Notes, users will get the improvements to the Notes product and get ODF support via editors for word processing, spreadsheets, and presentations. No additional office suite product to buy.

Sometimes in my talks I make what I warn people is a pretty dumb (in the sense of being obvious) prediction: in 10 years, the office suite software market as we know it now will be dead. I simply don’t think that in 2016 anyone will say “oh, here I am at my computer, I will start up my word processor and create a document. Then I will send it to Mary, she will mark it up, and send it back to me.” And so forth.

Yes, there will people who need all sorts of features necessary to write a book. But you know what? Ten years ago we had tools that were perfectly adequate to do just that! Things like LaTeX had this power a long, long time ago. There were many other applications that could do it as well.

Most office workers do not need all the bells and whistles that are in the current office suites. When you take them out of the economic equation of paying for upgrades, you will be left with a small percentage of super power users. In my opinion, this subset will not be big enough to support the massive development efforts to drive major new releases.

Coupled with high quality open source tools, especially tools that fit into the workflow better, we will see a diminishing market for office suites as we know them today. Maybe they will still exist, but they will be thrown into other products that more directly solve a particular business problem. They will need to be a lot smaller too.

Let me give you an example. I am writing this in the post editor in WordPress in Firefox. The editor is not perfect and it has a couple of bugs that really annoy me. There are a couple of additional features I might like. But I know it will get better because there is a version 2.0.4 as well as a version 2.1 on the horizon, and they will both be free.

This is more than sufficient for me to get my thoughts across with some decent formatting, not to mention the usual HTML features like links. I can even do sizable posts that run five pages or more. Combined with CSS, I can even print beautiful documents.

I didn’t get WordPress to get this editor. It is there so that the workflow called “creating and pubishing a blog entry” has a good user interface for the “type words and sentences” part of the job. To be redundant, the document editor is just something that happens to be there to support one bit of pushing some information out.

If we throw in some of things that I have discussed in previous posts like web-based storage, local to/from web synchronization, multiple-user distributed editing with tracking, we’re going to have most of what the vast majority of people will need. All of this is stuff we can do today. No major intellectual breakthroughs required. Throw in a little AJAX too and you’ll see what I mean.

What will also happen will be the development of high quality SDKs created for ODF and some standard things you want to do with it. For more than thirty years, UNIX users have used a string of filters to process, analyze, reshape, and format information. The binary formats used by WYSIWYG office applications dulled our senses to what we used to know how to do.

All of this will lead to a collapse of the office suite market, but we’ll still see the creation of even more documents that are more widely used and, fundamentally, just more useful.

I’m going to say something here that might sound like I’m vastly overreaching but I’m becoming more and more convinced of it: OpenDocument is bringing on a Renaissance of document creation and publishing. That which we used to know is being rediscovered and combined (mashed together) with what we have learned recently.

The orthodoxy of “this is how you create office documents” is going to fall by the wayside, though there will opposing kingdoms and battles and heretics and maybe even a few heros emerging.

Sounds like fun!


3 Comments

  1. I think it would be interesting to see the major consumer and enterprise wiki providers get together and establish ODF as the standard for wiki documents. This could provide a mechanism for establishing portable wiki document templates for specific use cases or a template marketplace for verticals. If you then mix in a standard server-side wiki plug-in model (something like WSRP from OASIS) that could be used to describe and persist Ajax widgets within ODF, I believe you would end up with a very powerful collaborative and integrated web application development environment that could serve the needs of power users as well as be simplified for novice content providers.

  2. I had a long and serious think about saving web pages as ODF last night. I came to the conclusion that it essentially depended on the same matter I raised before – the support of macro-languages, which can become immensely complicated once you treated a web page as the document to be saved as an ODF file.

    How many web-based “macro” languages would one wind up with? There’s PHP, there’s Javascript, there’s ASP, there’s …

    The point is that the “macro” language would have to be a plugin, and the macro language facility in ODF would need to be a stub which the plugins could mate to.

    This would put ODF significantly ahead of MS Open XML, which as far as I know, treats MS Basic as the default macro language.

  3. I don’t see much value in saving a web page as ODF. To me the value is in the ability to persist a single device-independent document which can be rendered in multiple device-dependent markup languages. For example, I will want my wiki documents to be viewable on both my desktop PC and my smart phone. Since a wiki is all about collaboration, the same document could even be edited simultaneously on a desktop PC and a phone by different users. On a desktop device the device independent ODF wiki document would get converted into XHTML + JavaScript + CSS. On a phone that same ODF document might have to be converted into a version of WAP to be useable.

    The wiki plug-ins that I referred to in my previous comment would also have to be persisted in a device-independant descriptor format. Say WSRP was used for this wiki plug-in standard. If so, this descriptor that got persisted as an extension to ODF would include something like the portlet web service endpoint and the portlet parameters. The remote portlet would use device capabilities provided by the wiki engine to understand whether the wiki plug-in needed to be rendered as a WML card or an AJAX widget and then return the appropriate markup back to the wiki engine.

    I hope that makes it clearer why you would not want to be converting XHTML/Scripts/CSS/etc to ODF with what I had in mind. However, you would probably want to support converting popular device-independent wiki markup to ODF and back. IMO that appears to be a relatively straight forward process. Also, it couldn’t hurt rendering the ODF wiki documents and doument plug-ins as Microformats on devices where they are supported.

Comments are closed