Bricklin: OK, so where are the ODF developer kits?

When spreadsheet co-inventor and now Software Garden CEO Dan Bricklin saw my blog about how ODF could be the new frictionless document DNA of the Internet, he called to say he thought I was right and went on to say that there's just one thing missing before ODF can really take off.

One of the things that has made Microsoft fantastically successful is the way the company's development tools make child's play out of developing Windows applications.  In true ecosystem fashion, if more developers develop Windows applications (because they're so easy to develop), then more users will want Windows because they know that's the platform with the biggest library of applications.  And the more people who use Windows, the more developers who are drawn to that growing user base as an easy target to sell their applications to. 

This ecosystem phenomenon isn't restricted to Microsoft or Windows.  Back in the 1980's, Novell's NetWare dominated the local area network operating system (NOS) market for the same reason.   When I was an IT manager back then, one of the reasons we standardized on NetWare was because of all the third party applications and utiltities that were available for the NOS.  With more third party apps, more support from server vendors, more  resellers, etc., so compelling was the NetWare ecosystem to us that it caused us to look past the technical superiority of Banyan Vines, a better NOS with almost no ecosystem.  Java is another ecosystem.  Three years ago, in an interview with then Sun fellow Rob Gingell, I learned how Sun viewed the Java ecosystem as though there were three planets on an orbital path: developers, volume, and applications.  That orbital path is the vicious cycle.  For many platforms, it has spiraled up.  For some, like the Palm OS, it has spiraled down.

If you followed any of what I've written so far about the recently OASIS-ratified OpenDocument Format where the sky is literally the limit when it comes to the types of applications that read or write ODF formatted documents (ie: not just productivity apps, but Web-based wikis, e-mail, and just about anything that generates formatted text), then you can see that ODF is literally the seed in the ground that's just waiting for some water to turn into an ecosystem. ODF will no doubt achieve some success as more large organizations like the Commonwealth of Massachusetts and the Danish Government  settle on it as the standard format for saving and retrieving public documents. 

Unlike with proprietary formats such those for Microsoft's Office, like other open standards such as HTTP (the Web), the open standard nature of ODF means that developers (proprietary, open source, or otherwise) don't have to agree to anything in order to build applications that support ODF. 

[Sidebar: OK, there's one hitch: if you're a develper, you don't want sue one of the developers of ODF like Sun for ODF-related patent infringement.  So far, Sun says it doesn't think it has any patents that read on ODF.  Just in case it does, the company has released a very broad patent non-assertion covenant that basically says "even if we have any ODF-related patents, it doesn't matter becuase you can use any of the patents we have (that's right any of Sun's patents) to make your software ODF-compliant." However, as is very often the case with software licensing -- especially open source software licensing where intellectual property holders are basically giving something away -- there are terms of mutually assured destruction if you sue the intellectual property benefactor for patent infringement related to the material being licensed or given away (in this case, ODF).  So, if you do sue Sun, you also relinquish your rights to operate under its patent non-assertion covenant.]

OK, back to developers pretty much not having to agree to anything. One of the reasons that Massachasuetts and the Danes like ODF (perhaps you should take it under consideration too) is because they know that it can have its own ecosystem. Developers may naturally gravitate to it the way they did to HTTP (the Web) because of how open it is.  If the specification is really useful, openness like that generally leads to a wave of innovation (as it did with the Web).  But, with OpenOffice.org pretty much being the only mainstream application supporting ODF at this point, the ODF seedling has yet to sprout (it's still early: version 1.0 of the specification was only recently finished and even more recently, submitted to the International Standards Organization). 

So, what's the water that will give it life?

According to Bricklin, it's the same water that has drawn so many developers to Windows -- an application developers' library that any developer can use to easily snap ODF-compliance into their applications.  With Windows for example, the very reason I wrote my own email processing application to work inside of Outlook is because of the way Microsoft's library of programmable Outlook classes do all the heavy lifting (creating separate instances of the inbox, navigating items, opening/closing/sending/deleting e-mails, etc.).  If I had to write them from scrath, I would have given up. Now, it's up to the big ODF supporters  (a.ka. Microsoft's competitors) like Sun, IBM, or even some whipper-snapper developer/entrepreneur to get something that does all the ODF-compliance heavy lifting into the hands of developers. Those somethings are the ODF libraries.  As long as no libraries exist and developers have nothing but a 706-page specification to parse through, ODF is going to have a tough time "hockey sticking" (if you laid a hockey stick on graph, the shallow angle of the blade represents the slow take off but the steep angle of the stick part is where the market really takes off).

Since the early eighties when the Visicalc spreadsheet software that he and Bob Frankston co-developed were partially responsible for the PC revolution, Bricklin (and Frankston) have moved onto other projects.  One of his current projects is ListGarden. an RSS creation tool (developed in PERL) for those who don't have it built into their own content management systems.

During the phone interview, Bricklin told me:

For interchanging data, we already have something like RSS. But when you actually write something into the data store that eventually creates the RSS item, what format am I going to write it in? Right now, the output is basically undeditable stuff (HTML).  What if it was editable?  My current format is wiki-like.  If we ever needed to import and export stuff from or to ListGarden (if it was appropriate), I would definitely consider ODF.  The problem though is that there are no libraries for me to use.  But, if someone would give me an ODF library to use --  the same way I'm using FTP and HTTP libraries for PERL developers to enable ListGarden for those protocols -- that would make it much easier for me as well as other developers to add ODF compliance to our applications.  Having that sort of ODF library would be wonderful because then I'd know that I'd be able to interoperate with word processors and all the other ODF-compliant software that's out there.

Bricklin isn't partial to ODF.  He said that if Microsoft had the right libraries so that he could use PERL to do the same thing with Microsoft's Office XML Reference Schema that he might do with ODF (if the right ODF libraries were available), he would be happy to incorporate MS-Office compatability.  But, not only don't those libraries exist, Microsoft's license to its schema prevents him from incorporating Office schema support into his software.  That's because ListGarden is licenced under the GNU General Public License (the GPL), a license that expressly permits sub-licensability (something Microsoft's license doesn't allow). 

While on the phone, Bricklin openly consider the range of applications that might sprout up if the right ODF libraries existed:

Even if we only use it as an interchange format, ODF would be valuable.  For example, imagine if all documents were backed up to the ODF format. Because of how open ODF is, they'd be assured of being accessible for a very long time by a range of tools.  You could also have stand-alone spell checkers and grammar checkers. 

Indeed, the possibilities of what can be done because of how open ODF is -- including open source developers releasing open source-based ODF libraries -- are only limited by the imagination.  Not only are the applications somewhat limitless, so to are the underlying platforms.  For example, to the extent that the libraries are done using  programming languages like PERL, Python, and Java that are inherently cross-platform, developers of ODF-compliant applications can just as easily make their software available to users of the various "thick" platforms (including Windows, Mac, and Linux) as well as thin one's like the Web. Now, the only three questions that remains are:  Who will release such ODF toolkits?; For what languages? and When?

[Editor's note: Dan Bricklin notified me I had a few transcription errors in my original quotation of him.  The current quote reflects several corrections that he sent to me via e-mail].