Could ODF be the Net's new, frictionless document DNA?

Could ODF be the Net's new, frictionless document DNA?

Summary: Between the way the recently OASIS-ratified OpenDocument Format (ODF) was approved as the Massachusetts standard file format for productivity applications, and the way it was submitted for consideration as a global standard to the International Standards Organization (the ISO) and the way the thin-client discussion has suddenly moved front and center again, could we be on the verge of an ODF-inspired document revolution?

TOPICS: Software

Between the way the recently OASIS-ratified OpenDocument Format (ODF) was approved as the Massachusetts standard file format for productivity applications, and the way it was submitted for consideration as a global standard to the International Standards Organization (the ISO) and the way the thin-client discussion has suddenly moved front and center again, could we be on the verge of an ODF-inspired document revolution?  Could ODF serve as the frictionless DNA that allows any thick or thin  authoring tool to create, edit, and exchange documents of all types?

I was reminded of these question over the past weekend when the need arose for two of my friends and I to collaborate on some documents, the contents of which are currently strewn across 40 or so e-mails that have been passed between us over the last two weeks.   There is no single contiguous thread from which to easily assemble any of the final documents we need and John rightly recognized that we were damning ourselves to thought reconstruction hell if we headed any further down the mutually destructive path.  That's when Bill asked if anybody had access to a Sharepoint Server.   It's also when the ODF document revolution light bulb went on. What do they call those?  Moments of clarity?  Epiphanies?

Sharepoint is a software product from Microsoft that can serve as a collaborative repository for documents that workgroups like me and my two friends can use to more easily work on single bodies of text rather than the fragments we feel so compelled to pass around in email. It's particularly useful to shops that are committed to applications like Internet Explorer, Word, and Outlook because of how well it integrates with them.  For example, while Sharepoint handles collaborative challenges like document check out, check in, e-mail notifications (of changes), and version control in the background, it looks like just another folder to save files too for users of Word in the foreground.  Even better, Word knows that there's something different about Sharepoint (compared to your hard drive) and it gives you an opportunity to annotate the document with a note that others can see when browsing a Sharepoint repository.

We're familiar with Sharepoint here at ZDNet.  Approximately two years ago, Microsoft asked if we might want to test it to help grease the wheels of the highly collaborative and document centric business process that was ritual here as it is for many publishing companies.  Documents would be written, re-written, edited, re-edited, and eventually published (online).  The process involved multiple people, all of whom needed to see the changes as they were taking place and included the columns I used to write for ZDNet.  For the duration of the test, Micrososft handled to the hosting of our test Sharepoint server on -- it's online Small Business Center.  Ultimately, we ditched the solution.  Although we probably could have tried harder to make it work, Sharepoint really required a bit of customization before we would have derived real value from it.  For us, in it's "stock state,"  the performance was slow and the user interface was kludgy (even when accessing though Word).  Eventually, we dropped back to email.  

As solutions go, using Word with Sharepoint was a relatively thick, and largely un-Weblike solution, requiring a Windows Server and Sharepoint on the server side and Windows and Microsoft Office on the desktop side. So, when Bill asked if anyone had access to a Sharepoint server, a flood of memories came back to me.   "Such a thick solution?  That's so, uh, yesterday" I thought to myself.  I also recalled my interview with Userland CEO Scott Young who, earlier this year, told me:

"The market is changing and the differences that exist between the older style or more traditional content management systems and the way the Web blog publishing capabilities that Manila offers, is going to have a dramatic impact on the lightweight end of it."

The one thing that always struck me as being the hidden beauty in blogs is how most bloggers are authoring HTML-based Web pages without really realizing that's what their doing.   In fact, in the daily course of blogging I do, I almost never stop to think about the fac that I'm really Web authoring.  Essentially, every blog entry is another document and the blogging infrastructure takes care of all the tough Web authoring challenges like publishing to the Web server and content navigation.  And voila, not just a blog...but an entire Web site.   Even better, most blogs don't need anything more than a browser for authoring and have a WYSIWYG interface.  When it comes to authoring and distributing documents with some basic formatting and structure --underline, boldface, fonts, indents, bullets, hyperlinks, etc. (the stuff most business documents are made of) -- it doesn't get much more lightweight than that.

But, one thing blogs aren't very good at is collaboration.  At least when it comes to developing a document. They're a good way to share ideas across organizations, but less than ideal when it comes to collaborating on single instances of documents.  To collaborate on documents in lightweight bloglike fashion, what's really needed is a similar Web authoring tool -- one that hides the fact that the writer is actually Web authoring but that allows others to join the fun on the same document.  I guess you could do this with Word, save it to HTML, share it across e-mail, Sharepoint, or some other collaborative infrastructure (there's always Microsoft's Groove too), and then eventually publish it to the Web for veiwing across an organization.  But wouldn't it better if you could shed all that weight, do everything through a browser (so the organization already has intsant access) and touch the bits that are practically sitting on the wire (the Internet or Intranet already)?  Of course it would.

Enter wikis (I've heard it prounced two ways: wee-kees, wick-ees, let me know what you think). 

Dan and I have covered Wikis before on Between the Lines (here for example) and I've spent a fair amount of time working with several Wiki products.  And, if you have any doubt about the future of wikis in the enterprise, perhaps you should take note of SAP's recent injection of $850,000 into online Wiki technology provider Socialtext.   Socialtext isn't alone.  There are several other online WikiSPs (wee-kisps; wiki service providers) including JotSpot, XWiki, and Wikispaces and there are several open source-based wiki solutions that you can host yourself.  The world's best example of the power of wikis is, of course, the Wikipedia -- an online encyclopedia that anybody on the Internet can contribute to, one that's far better than any commercial encyclopedia (online or in print) despite the unedited nature of many of the entries.  More importantly to the point I'm about to make, every entry in the Wikipedia is a document. One with nice formatting.  One that anyone in the world can contribute to using nothing more than a browser. One that doesn't require any heavy duty tools or conversions to get it on the wire where everyone can see it.

So, as you can imagine by the way I'm extolling the virtues of wikis, I recommended to John and Bill that we skip the complexities of something like Sharepoint and go with a wiki instead.  But which one of the Wikisps should we go with?  Since John likes to tinker with open source anyway, he might want to host a wiki solution himself.  But, when deciding amongst the various wiki options, one of the challenges is that wikis are in some ways like word processors all over again.  Sure, they can all output the same pretty HTML page (much the same way WYSIWYG word processors can output the same pretty paper page). 

But, when it comes the control of document formatting, there is no official standard wiki  markup language thats supported by all wiki solutions.  Just like with word processors, wikis use their own user-friendly markup language instead of HTML tags because of how non-user firendly raw HTML is.  For example, how to toggle boldface on and off or how to indent.  Much the same way many organizations are trapped by Microsoft Office after accumulating thousands of documents stored in its proprietary formats, organizations that adopt wikis today may encounter a similar lock-in problem if, somewhere down the line, they decide they want to use a different wiki solution. 

The problem isn't  as bad as it is with front office productivity applications since all wiki documents are ultimately rendered in HTML.  But under the covers, from one solution to the next, the markup language that's used to author and edit wiki documents is not 100 percent compatible from one solution to the next.  Interchanging documents from one to the other, should the need arise, involves pain points.  Via telephone, Joe Kraus, CEO of wiki solution provider Jotspot agreed and told me that Jotspots's customers are already asking for specific conversions between Jotspots native XHTML-based storage format and those of other document authoring tools. But, without lingua franca that old document authoring tools can treat as their common denominator, there's a huge barrier to interchanging documents between wikis and other document authoring tools such as word processors.

So what's the solution?  ODF.

ODF isn't just for front office productivity applications (word processors, spreadsheets, etc) as has been often implied by the way it is so often tied to (sidebar: it will be supported by other MS-Office substitutes as well; for example solutions from IBM and Corel).  There's no reason, for example, that, regardless of what proprietary markup languages the different wiki solution providers use to put a pretty face on Web authoring, that they cannot natively store those documents in the XML-based ODF.   Come to think of it, what documents can't be stored in ODF?  What about browser-generated documents that are authored in GMail, Yahoo Mail or even blogs?  Once a few key providers of these different document authoring tools decide to natively store their documents in ODF, then the ODF format could enter a viral stage that turns ODF into the underlying DNA to anything capable of generating text.  Were this to happen, Microsoft would have no choice but to support ODF (something it's apparently considering) since at that point, it would not only be odd man out, the number of ODF-compliant documents being generating by all the ODF-compliant authoring tools in total would begin to catch up to Microsoft's file formats.

The net result is that it doesn't matter whether your a fan of thin or thick client computing.  If for example, you want to author your wiki documents with an ODF-compliant word processor, no problem.  Much the same way Word can save to Sharepoint, your ODF-compliant processor should be able to save to your SocialText workspace (logins and passwords all automatically taken care of, if you want).  What if your colleague is working on a thin client and wants to make changes to that document using SocialText's markup language?  No problem.  Because SocialText can, under the covers, manage the conversion of ODF to its markup lanaguage and back again, everything automagically works. 

What if you're like John, Bill, and me, with 40 or so formatted documents locked up in Gmail? No problem. Technically, going back to Scott Young's points, as part of the broader document revolution/global-rethink that needs to take place, we should have had the foresight to not use e-mail as the starting point for our collaboration anyway.  But, if applications like Gmail have the ability to export e-mails to an ODF-compliant repository through the Internet, then the penalty for our lousy decision to use email in the first place is greatly ameliorated.  In fact, the more ODF-compliant solutions that establish such standards-based linkages to other repository, the more friction free the flow of ODF-compliant documents becomes.  In contrast, Microsoft's proprietary formats are anything but friction free once you try to move them into non-Microsoft solutions. For example, even with Word's HTML export capability,  it's extremely difficult to use Word as an authoring tool for ZDNet's Wordpress-based blogs.  So much so that we don't even bother to try anymore.  If ODF was the underlying DNA, all the pain points go away.

The implications of such a concept are critical to organizations like the Commonwealth of Massachusetts that are looking to settle on a single document standard across a huge population of users.  For example, today, if one of Massachusetts' 173 agencies runs into the same problem that my friends and I ran into, they, as of January 1, 2007, will have the additional requirement of making sure that any documents they collaborate on are ODF-compliant.  By virtue of the new statewide standards, Sharepoint isn't as compelling as an option any more because it doesn't integrate nearly as tightly with non-Microsoft solutions as it does with Microsoft ones (and the Microsoft ones don't support ODF).  So, imagine if all the wikis begin to support ODF.  Suddenly, all of the state's agencies are free to pick from any one of the wiki solutions if they decide they want a lighteight, efficient, browser-based document collaboration tool that not only complies with the ODF specification, but that makes all of their public documents instantly accessible via the Web. 

So, what does a wiki provider like Jotspot CEO Joe Kraus think of the idea?  Said Kraus in my phone interview with him this morning, "I don't know what the technical challenges are, but from a market point of view, it's a very interesting idea."  Referring to the way it would cut back the number of translators he'd need to write in response to the customer requests he's already getting, Kraus said, "Not only would itbenefit customers, it would benefit vendors. It opens up the whole ecosystem." 

Finally, on the heels of Massachusetts' decision to set ODF as the statewide standard document format for saving documents created by productivity applications (PDF is also a state standard), ODF has been bad mouthed for being technically insufficient when compared to other similar file format technologies such as those from Microsoft.  But, as I noted in a blog I wrote earlier today, the open nature of ODF assures the world that if there are any technical deficiences in the specification, that innovation is very free to rise to the challenge of solving the problem.

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Pronunciation

    Who better to check with than WikiPedia? :

    [i]A wiki (IPA: /wiːkiː/, "weekee" [1]) is a web application that allows users to add content[/i]
    Yagotta B. Kidding
  • Genie's out of the bottle...

    Awareness of ODF has exploded over the past two weeks. If even a fraction of CIOs who've been paying attention to the tech news contacted reps from their office suite provider (i.e. Microsoft), there's no way it will not be supported...and soon. Because every open-source and many other commercial vendors are going to be (or have already) added support. There are way too many advantages to an standardized and open document format, and the momentum is going to be impossible for Microsoft to stop. The pain has always been there, even internal to MS: every time they changed their format, they've had to provide converters, leading to all the options in the Save As dialog box. The days of not being able to read your own raw data without the original tool of creation are gone. The genie is out of the bottle.
    • One more thing...

      Look at all the organizations involved in this:

      That's some widespread involvement, even international. And that spells momentum. Proprietary formats are done. Incredible...exciting even.
  • DNA? useful to know what is

    ..without going to look for
  • Google any serious subject

    And you'll find half of the first page are PDF documents. ODF has a tough uphill climb against Adobe's now-ubiquitous standard.
    • Agreed - but only for "read only" documents

      Adobe's PDF is not the target here - MS Office is. For documents intended for editing and/or collaboration, ODF is going to have a much easier time of it than in the pure "read only" competition against PDF.

      The momentum is just starting to build - once people and organizations start to realize the benefits of ODF for collaboration, it will become the de facto standard for sharing of documents which are not pure "read only" documents.
      IT Makes Sense
      • Business wants read-only

        I disagree. The reason for Adobe's success is that businesses prefer published documents that are unalterable. "Working," editable documents are fine between developers, but published documents are where the rubber meets the road.
  • Re: Could ODF be the Net's new, frictionless document DNA?

    Not unless they increase the speed of it. Hmm 98x slower than Excel? And you say Sharepoint is slow.

    BTW David, do you have a fetish with the MA decision? After all, you haven't stopped ranting about it from day 1. I enjoy your enthusiastic approach to everything based on the Web (which is a debate for another thread), but I really cannot see companies who might have thousands of documents stored in proprietory formats suddenly deciding to change everything over to OpenOffice (or an equivalent ODF based Office suite), simply because ODF is "open". The only institutions that require open standards tend to be governments etc, and they simply do not make up a large percentage of the corporate market. Add to that the inherent speed problems that come from XML based formats and I can see lots of reasons to stay with current formats (Office, PDF etc).

    Mind you, I like the idea of in-house servers. The internet simply cannot beat a LAN.
  • Thick or Thin Argument

    David, I think the "Thick or Thin" argument has gone on long enough. Why not a system designed to start thin - a network PC & gateway - and then allow the addition of new appliances with embedded applications that make the system "thicker"? Yes, this is self-serving because we have a vested interest in such a system, but doesn't it make more sense?

    An enterprise wouldn't have to decide who gets a thin client and who gets a thick one. Everyone would get the base unit and then additional appliances could be added if and when necessary. The appliances would also provide far simpler SMS (system management services).

    A service provider, say a cable co, could deliver the base to every subscriber and then send out new appliances to meet changing needs or technology. Far more efficient than rolling trucks to swap boxes. Just a thought.
  • Friction

    The major friction point I see, although it's only extraneously related, is for the huge organizations that have thousands and thousands of documents that are already stored in the MS Office format. Is there going to be a new overnight industry for 'Document Converters', people who go out and convert from one format to another because the currently employees of these companies either don't have the know-how or the time to do so? Or do you think that Microsoft is going to come up with some easy way to convert from their proprietary format to ODF?

    It seems as though ODF can do everything that you say it can, but will people use it? Will organizations make the shift? It's cost efficient in the long run, but what about the current capital it takes to get the ball rolling? These are questions that someone is going to need to face, whether it's a third party who finally manages to make a true MSO-ODF converter that you can use as a crawler on a local network, or a company that hires out people to spend hours and hours of each day working tirelessly on converting the docs over. Or maybe MS will become altruistic and just make ODF the main format of Office, and auto-convert every opened document into ODF from the MSO proprietary format.

    • Re: Friction

      You are absolutely correct - success will be dependent on an easy transition.
  • Did the crack dealer have a sale yesterday?

    "The world's best example of the power of wikis is, of course, the Wikipedia ? an online encyclopedia that anybody on the Internet can contribute to, one that's <b>far better than any commercial encyclopedia (online or in print)</b> despite the unedited nature of many of the entries." (Emphasis mine)

    This is the same Wikipedia that featured a picture of Senator Palpatine (evil Star Wars emperor) in the entry for Pope Benedict XVI, right? Sure, Wikipedia is amzaingly comprehensize - I have spent hours following link after link in it. But the sad reality is that most people who write in it are going to be biased fanboys.

    More importantly, this entire article assumes the following premises:

    1) A critical mass of software providers will start supporting ODF, with the probably exception of Microsoft.

    2) A critical mass of software users will use ODF-supporting applications.

    3) A critical mass of software providers will NOT make proprietary extensions to the ODF format for their own application's needs.

    4) A critical mass of software providers will not just use 100% standards compliant ODF files, but will then add in filters, formatters, etc. to their software that gives it automagical, cross-application usability in a way that is almost as (if not more so) seemless, transparent, and "just works" as Office products do this (not even because all applications compete with Microsoft, but because Office is the gold standard for this functionality).

    Now, let's look at current reality:

    A) "Once a few key providers of these different document authoring tools decide to natively store their documents in ODF, then the ODF format could enter a viral stage that turns ODF into the underlying DNA to anything capable of generating text." Why in the world would a software engineer add in another data layer, one which is most likely incompatable with his presentation layer? "Hey John, I've got a great idea. You know how we need to take text input from the customer and display it as HTML, and store it in the database? I was thinking that it would be a great idea to take that text iput, convert it all to ODF format, then shove that ODF document into the database, find a way to search through the ODF documents in the database (as opposed to the text we used to store there), then extract the ODF document from the database, convert it to HTML, and display it to the users!" Give me a break. Do you know how much slower it is to search through BLOBs and CLOBs in a database thatn text?

    B) ODF is not an optimum format. It is XML based, which is significantly slower (see George Ou's recent articles regarding the subject). XML is an amazing format, in that it is both disk-space wasteful, and CPU wasteful. I cannot think of any other format off of the top of my head that manages to accomplish this feat.

    C) ODF is a complex, overly-heavy format. The specification, in PDF format, is 706 pages long.

    Basically Dave, there's really no simple way for anyone to add this format to their applications. The Microsoft family of products is wildly sucessful, in large part because everything snaps together for the end user. More important, the Microsoft family of products covers just about every application out there. When a new type of application comes out, Microsoft is quick to buy or build a product to meet that need. Sure, it may be slow, buggy, and insecure, but when you buy Microsoft, it all works well with itself. What you're saying, that if "everyone else" stndardized on ODF does make sense. It would allow everything that supported it to snap together just like Microsoft product do. And quite honestly, the end users don't care if their data is in Office or ODF formats, as long as it works.

    But the developers care. Reading your articles, it is pretty clear to me that you don't know too much about coding, or the mindset of the people who actually write code. Here's a good example: CGI. When people first started to write server-side Web applications, way back in forever ago land, CGI was really the only way to do it. It didn't take long for CGI to be developed, because the CGI system didn't do too much. On the other hand, CGI was kind of nifty because of just that; a CGI program was any piece of code (a binary, a shell script, whatever) that your webserver could execute. CGI had it's flaws. For one thing, the script had to return an entire HTTP transaction. You had to read the HTTP specification and understand it to be able to write CGI code. Sure, we always associate Perl with CGI, but there was a bunch of CGI code written in C. Heck, you could have Emacs handling your CGI if you really wanted to. But then one day came along a bunch of systems that handled the HTTP protocol for you, automatically generated & managed sessions, etc. JSP, ASP, PHP, all basically did the same thing. Within moments, no one wanted to write CGI scripts anymore. Why? Because they had new systems that handled everything automatically. Have a language or system that takes 75% of the work off of the coder, and lets the coder focus on their logic and not things like setting the MIME type of the response is going to be a hit.

    This is what ODF lacks. Are there freely available components that can be used in most major langauges that automatic the loading, saving, sorting, displaying, etc. of ODF files? Are there any languages with ODF support built in? XML didn't take off until JSP, PHP, ASP, and the major databases had built in support. Is there a nice, simple (and not-CPU intensive!) way to translate ODF into HTML? If not, forget about it. Because your only other option would be to dump the XML onto the user, and then dump a disgustingly huge XLST on them (remember that 706 page PDF? Imagine what the XLST looks like), and then laugh as the user's computer attempts to parse even the most minute ODF document. And even then, all you've done is given them a read-only document in a web browser, so you might as well have used PDF.

    What about other applications that need to add other information not in the ODF specification? Are they going to have to add a proprietary extension to ODF, or supply a secondary XML definition, or what? The ODF specification doesn't cover every imaginable circumstance.

    What about when the specification changes? Even if there is a simple little ODF loader/saver/displayer component that's easy to program with, all of the coders would need to get the update and recompile it.

    Your suggestion here is laughable, at best. It relies on way too many critical masses occuring, and three of them are programmer related. Sure, if this was, say, RSS, where it is a new technology, all you need are programmers to create the code, and users will use the apps. But what you want involves everyone tossing out all of their existing code and re-writing from the ground up, just so their product plays nicely with a competitor's product. No way is that going to happen.

    Justin James
    • help

      One thing that will likely help ODF a lot is that there is a big push to SOA, and the first principle of SOA is to convert everything to xml.
    • Never mind the crack dealer - what about the customers?

      There are a number of flaws in your argument. On the plus side, your share the same tunnel vision as Micro$oft as maybe employment with them is an option.

      You say "Why in the world would a software engineer add in another data layer, one which is most likely incompatable with his presentation layer?". The answer is that it is not up to the engineer. If the customer wants ODF then you had better give it to him or he will take his business elsewhere.

      "ODF is not an optimum format. It is XML based, which is significantly slower". This is true, but this whole discussion is NOT ABOUT EFFICIENCY. Massachuestts has a simple choice, either they can have a format that opens quickly but might not be supported in 5 years, or they can have a format that opens more slowly but is readable in 50 years time. It's a no-brainer that readability outweighs speed.

      "ODF is a complex, overly-heavy format. The specification, in PDF format, is 706 pages long" - and this affects the customer in what way????? That's a technical issue. It's for techies, not customers.


      "Sure, it may be slow, buggy, and insecure, but when you buy Microsoft, it all works well with itself"

      So, we should keep buying slow, buggy, insecure cr*p because if we use something else then this rubbish might fall over? Would you buy a car on that basis? Suppose I wanted to buy XXXXX's television but I would have to change my video recorder, DVD, Hi-Fi and satellite system to brand XXXXX as well just to make the telly work. Would I stick with brand XXXXX? Of course not.

      "But the developers care." - But the customers don't. Customers pay the bills. Developers run up the bills. Tell a businessman that it is a fight between paying customers and his developers and see which he fires first.

      Get your focus right - Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer, Customer.


      • But the customers HAVE spoken...

        ...and voted again, and again, and again, and again, and again, for the Microsoft solution. Berlind's article is an hypothesis, not based on any groundswell of customer desires. Please go take a poll among computer shoppers at the local Best Buy and ask "What's your opinion of ODF" and count the percentage of blank stares.
        Rodney Davis
      • Customer Like Slow Apps? Think Long Term?

        Hmmm, what customers are those?

        You concede that the XML solutions are inefficient but have long-term benefits. Guess what, customers, like all humans who have been studied, prefer immediate positive results (app opens in two seconds in an application they are familiar with) and care little about uncertain long-term negatives (some day I may not be able to open that document.)

        Opening a document with a "funny" file extension (unless you're a Mac Luddite) in a funny-looking application is immediately a challenging (=negative) experience for most people.

        We in industry have analyzed this human behavioral suite most often in terms of safety-related behavior. See
        for an explanation. Be careful -- it's a Word document.

        You've convinced yourself that customers are non-humans ... not a good idea!
    • It'll be a smooth as butter transition

      just like websites on the internet going from html 4 transitional to xhtml 1.0. Heck, what sites are older? . . . . . . . . well, it will be easy none the less.
  • This is gonna be big, linux big

    expected to be seen on shelves everywhere, soon.
  • Simple solution now

    Here's an online collabrative writing tool you might find useful:
  • Message has been deleted.