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

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 bcentral.com -- 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 OpenOffice.org (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.