Sun's Schwartz says AJAX to play a role in OpenOffice. Here's my bet on how.

A few weeks back when Google and Sun started dropping hints that the two were on the verge of co-announcing something big, the odds-on favorite was some sort of AJAX-based version of OpenOffice.org

(OO.o).  Even after the announcement was over and the press and analysts were walking away shaking their heads asking "That's it?  Nothing else?," the obsession over OO.o and the possible AJAXizing of it has continued to get attention despite the fact that nothing of the sort has been announced by anybody.  And it won't be.  In fact, it will never be.  Sun president and COO Jonathan Schwartz practically said as much in his most recent blog (see OpenOffice.org, AJAX, and Common Sense).  But did we really need Schwartz to tell us that you can't take a full-blown front office suite where the majority of the code runs on the client and make it run in a browser?

It's one thing to take client/server applications where the client can easily get away with using nothing but forms  to interact with a server that's doing the lion's share of the data processing (usually involving a database) and to browserize it the way Salesforce.com has browserized Customer Relationship Management.  It's another to take a 100 percent client-side application that, in producing highly unstructured data goes way beyond forms, and figure out a way to move most if not all of the processing over to a server.

Forms are an integral part of the Web and there couldn't be a better example of overkill than the one where one throws a bloated client at a client/server application where the client's responsibility is something as simple and lightweight as forms.  Browserizing forms applications makes perfect sense.  Google has done a terrific job using AJAX to browserize e-mail.  No surprise there.  E-mail is basically a form.  It's also a client/server app.  Some of the processing (ok, most) was already done on the server.  Come to think of it, e-mail can't exist without a server.  Today's full-blown front office applications can and do. 

So, what role, if any, can AJAX play in the OO.o ecosystem? Perhaps some hints lie in Schwartz's blog where he says:

Could these apps I mention, above, be enhanced with better network connectivity, more collaboration, and better integration into your daily life? Absolutely.....So if you want to know what the future portends for OpenOffice.org, that's a fine place to start (and AJAX will likely play a role).

What Schwartz doesn't say is as important as what he says.  If you were an OO.o user that wanted OO.o better integrated into your daily life, and you wanted to use OO.o to collaborate with other people,  and you wanted OO.o to have better connectivity, then what would you be integrating with, collaborating over, and connecting to?  Imagine if you were able to integrate into any device we have access to (anywhere, anytime), collaborating over any document, and connecting to any storage repository?  Schwartz talks a lot about value and if Microsoft Office teaches us one thing, it's that we're largely being deprived of its full potential by virtue of the fact that it doesn't do any of those three things very easily. 

For example, find four friends, and amongst the five of you, give one a Blackberry, another a Pocket PC, put two other ones at Web terminals in different locations and sit yourself at a Windows PC with MS Office. Start by creating a document that all must contribute to, edit, and approve and give yourselves an hour to get it done.  After your first attempt, let your friends take turns starting the document (after all, one key to collaboration is that anyone can kick the process off).  OK, let's be fair to MS-Office.  If you try the same exercise with OO.o, you'll get the same results.  But thanks to technologies like AJAX and standards like the OpenDocument Format, the opportunity for liberation exists.

Considering all of the things that have already been accomplished in this day and age of the connected world, it's shameful for something that, in theory seems so simple, to be in practice barely possible (and even then, only very painfully so). 

So, how can AJAX play a role in making OO.o better on the integration, collaboration, and connectivity fronts?  Schwartz may have left us guessing, but the answer is rather obvious to me.  The challenge isn't in using AJAX to browserize OO.o.  The challenge is to use whatever languages are appropriate to create peers with which OO.o can easily interact.  This is one reason Schwartz writes (in boldface) "The language in which a product is written has nothing to do with the value it conveys."  

In the course of getting a BlackBerry, a PocketPC, a Web Terminal, and a Word Processor (the one in MS-Office or OO.o, doesn't matter) to successfully collaborate with each other, the choice of a single language is irrelevant.   In fact, it's impossible. The BlackBerry uses Java.  The PocketPC uses a .NET Compact language (could be C# or VB.NET), and the word processors are done in C and/or C++.  What is relevant is that they can all interact on as rich a level as possible with the same documents located in repositories of collaborators' choosing. 

Much the same way that more Web sites make browsers more useful, and the way more Bittorrent servers make Bittorent clients more useful, AJAX will make OO.o more useful because, by virtue of solutions that we haven't seen or heard of yet (some of which will undoubtedly come out of the Sun-Google relationship), the number of people (aka: the size of the community) who can interact with OO.o-generated documents at any time, from any place, using any browser will probably be greater than the sum total of all users who have both OO.o and Microsoft Office. 

More importantly, although they will be enablers, neither AJAX, nor OO.o (nor Java for that matter) are responsible for this sort of document and collaboration liberation.  For that, look no further than the OpenDocument Format (ODF) with which the newly released OO.o 2.0 is compliant and with which future ODF-compliant peers, be they developed in Java, AJAX, C/C++, Perl, or whatever, will be able to interact.  Will they be able to do to an ODF document what a full blown office suite can do?  No.  Will they be able to offer the sort of interactions that will suffice for basic business document creation, storing, retrieval, editing, and collaboration?  Clearly, at some level, yes.  What level exactly?  It's hard to tell. In coming up with its user experience for e-mail, Google (in its Web-based GMail) sacrificed return receipt. So far, the sacrifice doesn't seem to have bothered many people.  In terms of working with ODF-compliant documents, a Web terminal that supports Java may be more capable (in terms of what it can do with an ODF-compliant document) than may a plain Web terminal where AJAX is as rich as the platform gets. For every device, there will be sacrifices.  They'll be worth it.

And, to all you scrooges out there who are so quick to shoot down something we should have had years ago, perhaps you should consider how much better off we are with the monolithic way things are today.