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

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

Summary: 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.

SHARE:

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].

Topic: Software Development

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

Talkback

10 comments
Log in or register to join the discussion
  • Universal file format has been done

    The Amiga IFF file format was used for documents as well as sound and graphics. There were tools and an ecosystem around IFF too. Of course it was a BINARY format . . .
    Roger Ramjet
    • IFF you must know...

      Actually, the Amiga IFF format was far more influential than most people realize. During the late 80's, Microsoft and IBM (when they were a lot more buddy-buddy) created an IFF "clone" called RIFF, to be used in Windows and OS/2. RIFF was nearly identical to IFF--so similar that IFF parsers could walk the structure of most RIFF files.

      You've never heard of a RIFF file, you say? How about WAV or AVI? Those file formats are RIFF-structured.

      Nevertheless, IFF (and RIFF) are binary formats, as you mentioned. No one but a masochistic geek would try to make sense of an AVI file using Notepad. No, the forseeable future is XML-tagged data, which is why ODF and MS-OXF hold promise.

      Kudos to Bricklin for once again noting that developer support is the single most important ingredient in a standard's success.
      ejsawyer@...
  • Acorns

    Well, if you're looking for the beginnings of support for ODF, a good place to start is SourceForge. Where, interestingly, I find AODL:

    [i]AODL is a .net library resp. framework written in C# which help the developer to generate documents in the OASIS Open Document Format without any knowledge about the ODF XML schema.The ODF is the standard format for many office suites e.g OpenOffice 2.0.[/i]

    Well, it's something -- created 04 October. On Freshmeat, there's [i]Docvert[/i], a PHP program to convert OpenDocument files to MSOffice. Brand-new, created 13 September.

    So, it looks like Massachusetts has gotten some mindshare already even if the projects aren't exactly ready for prime time.

    Meanwhile, keep in mind that since OpenOffice.org and KOffice are thoroughly open (LGPL and GPL respectively) there's [b]lots[/b] of highly reusable code there. From what little I've seen of the two codebases, my own preference would be KOffice since their stuff seems generally "cleaner" in the sense of being more of a comprehensive reusable set of libraries, but that's very much IMHO and YMMV.
    Yagotta B. Kidding
  • Stephen O'Grady

    Stephen O'Grady says one big plus of ODF is its programmability.

    http://www.redmonk.com/sogrady/archives/001036.html

    See especially the long comment by ODF technical committee member Gary Edwards.
    Eduardo_z
  • It takes a coder to understand coders...

    This is essentially what I wrote earlier today (<a href="http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=14148&messageID=284413&start=-37">http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=14148&messageID=284413&start=-37</a>). Bricklin is 100% right. One reason why coders don't mind working with Office, is because methods to programmatically access its functionality is baked right into Microsoft languages. Furthermore, it's easy to extend, since its macro language (VBA) is close enough to VB to capture that huge pool of coders out there.

    I didn't seriously try working with XML until I tried out .Net. Why? Because all other languages made XML a pain to deal with. Sure, they were more than happy to read in an XML document. But I had to transverse all of the nodes myself and manually add them to a data structure if I wanted to work with them. .Net makes it as easy as calling one function, and it fills an object with data. Even better, it uses the exact same object that is used for database access. So there's a heck of a lot less for me to learn!

    Another area where ODF fails dismally (indeed, most FOSS software fails here, notable exceptions are BSD, Apache, and Perl) is DOCUMENTATION. ODF simply hands you that 706 page spec and says "have fun buddy". That sounds a lot like a recipe for hard work to me. I started writing code, because it seemed a lot easier than the alternative ways to way money (digging ditches, changing tires, stock boy, etc.).

    To make a long story short, ODF absolutely will not fly until someone releases an ODF toolkit that is well documented and easy to work with. It needs to have methods to load an ODF file from a stream or from a file name. It should also have baked in handlers to allow me to give it a protocol and URL, and load from there. It should have some converters built right in (.ToWord(), .ToHTML(), .ToBLOB(), .ToCLOB()). It should have built in methods for at least 80% of common tasks that an application would use (.Find(), .Replace(), .FindAttribute()). It should have a presentation widget that can be placed in a program, both with and without full editing tools. This toolkit should be available on all major platforms, and be accessable from all major languages (Java, C/C++, Perl, .Net Framwork, Ruby, Python, and then some) with the exact same methods and parameters, to reduce the cost of using it in many different projects.

    Give me this toolkit, and it is suddenly trivial to adapt existing code (wiki, email, blog, RDBMS, etc.) to make use of ODF. Without this toolkit, only the foolishly brave will use it.

    J.Ja
    Justin James
  • Abiword, Koffice, Text Maker, IBM Workplace, et al.

    Abiword already has a plugin for Open Document, Text Maker(Beta) http://www.softmaker.com/english/tm_en.htm, EZPublish, and KWord (Since June) all already support it. There is more support for the format already than just OO and Star Office.

    Scribus can import it also.

    Then again there is the Open Document Viewer (Oh the Irony) http://visioo-writer.tuxfamily.org/EN/index.html

    IBM Workplace and Corel WP Office are suppose to support it by 2007.

    A lot of this is FUD. SDK slowing adoption- my left toe! If all these FOSS and Small software companies can support it without a SDK then MS Developers should be able to also. The problem isn't a lack of SDK. the problem is they don't want to support it.
    Ed_Meyers
  • A true story

    Just today I get a call from one of our manufacturing managers. It seems they have a excel spread sheet that they use to do some calculations on inbound orders carried over our internet connections. These orders are in xml format and they have thus far been opening the documents and rekeying the elements into the documents so they can feed the data to the manufacturing systems. They asked me how we can automate this process so they can quit rekeying thd data.

    The manager sent me the spread sheet so I said what the hell lets open it in open office and see what it can do with it. Well a few of the macros do not run so I open them up and modify them to work under the new open office. I save a new copy of this document in ods format, I put a few tags in the document where they want to auto input the data. I saved it to disk in ods format and unzip it to look at the contents. Well low and behold there is a content.xml document. I open it up with
    a editor and I see my fields.

    Ok I copy it to the web server that handles the inbound orders, I coded up a couple of php functions that use the content of the old document and creates a new content.xml on the fly while the orders are comming into the system. I did all of this in less than 20 minutes time, no documentation other than looking at the saved ods file. No loading office to automate, no speed problems just plain wrote the data to a ods complient file so that manufacturing does not have to rekey data.

    Bottom line a library might be cool but it is far from a necessity. The format is xml and it is darn trivial to manipulate and or create new documents based on the open document format.
    jjanks
  • Wow

    For someone just being hired into the tech industry, but having been a geek since I was old enough to sit on a chair and play with my dad's IBM XT, the revolutionary nature of ODF and what it means for my, my organization, and the tech world at large is something to wow at. I've seen revolutions like these before from the outside, when they are already started, such as HTML/the web and advertising-supported internet related content, but I've never been a part of it from before it really took off.

    The only question I have is, would anyone care to make a timeframe estimate for when this technology is going to explode into its true potential? I want to start using it, and to be able to convince my employers to use it, but when am I going to be able to convert my MS documents to ODF? When am I going to be able to open any formatted text document with my copy of OpenOffice? When when when?

    I can't wait.
    technodolt
    • Now

      [i]The only question I have is, would anyone care to make a timeframe estimate for when this technology is going to explode into its true potential? I want to start using it, and to be able to convince my employers to use it, but when am I going to be able to convert my MS documents to ODF?[/i]

      Would today be too soon?

      [i]When am I going to be able to open any formatted text document with my copy of OpenOffice? When when when?[/i]

      Which flavor of "formatted text?" The ones I use come right in.
      Yagotta B. Kidding
  • Some found here

    Here are some developer tools http://opendocumentfellowship.org/Resources/DeveloperTools, with more to come, hopefully.

    [Edited by: admin on Oct 20, 2005 9:32 AM]
    nhussein