Desktop Linux and the "Killer App"

Before the mid winter holidays, I read an article stating that calendaring was the "next killer app". My memory of the article was a bit fuzzy as to details: I was not at work for three of those weeks, and wasn't even near power for one of them. But that line bumped around in my head, and I kept thinking that it was silly: Calendaring has been the Achilles Heal of Linux for years, as far as using Linux as a full time desktop replacement goes. It is much easier to use Linux at home, where I control the app stack of the glass house.

Re-reading the article now, I see it was really about the next generation of calendaring (and Google looks like they have plans here, so this might or might not be another AJAX tour-de-force getting ready to happen.)

Let me back up a second though. In the early 1990's, I was involved in at least two major projects. One was that I hooked BMC to the Internet. The other was that I ran the corporate email and calendaring servers. I was also the VM system programmer and an OS/400 system programmer: I have always been a generalist I guess, but those were not as germane to this discussion.

Email was separate from calendaring then. The calendaring solution tunneled it's appointments to each other via the email infrastructure, but the clients were separate. There were technical problems with this: the email stored everyones email in the same monolithic storage area: essentially one large file, and it had to be maintained to stay fast, or really, to even stay *up*. High levels of calendar traffic fragmented this storage quickly. This was as much a problem with the way the email infrastructure worked as the way the calendar client worked. 

No one disliked the calendar application per se (even if they didn't like going to all the meetings it said they should be at :)  ). Even to this day, it had some feature / function better than what we have today, such as the way it handled conference rooms and video projectors and what not. But what some people wanted was for email and calendaring to be in the same client. I have never really understood why that mattered so much, but it clearly did and does. By the late 1990's we had MS Outlook clients running against MS Exchange servers, Email and calendaring were together  and all was right with the world. 

Unless you were a Linux desktop user of course. Email was easy. Linux has had real working solutions for email for years. I use Thunderbird / IMAP against MS Exchange most days. It is fast. it has great SPAM filtering, and 1.5 has inline spell checking. Calendaring is another story though.

Early in the days of Ximian Connector for Evolution, I paid to get a copy, and I ran a Linux version it supported (Mandrake)  Other than being a bit slow, it worked pretty well. I migrated to using Evolution for most everything. It was a bit too Outlook 97-like to be a totally happy place to be, but it worked. I also played around with Kmail via IMAP and Korganize via their Exchange plugin. For calendar downloads it worked great. For interacting with LDAP for the address book, or uploading meetings to MS Exchange from Korganizer... not so good.

Then, Novell bought Ximian, Novell open sourced Connector, and I have not had a good stable version of Evolution ever since. Closest I can come is Fedora Core 2 with Evolution 1.4.6  Next closest is FC4 with the current 2.2.2-5.  I am not sure why, but my theory is that most of the people writing Evolution Connector don't have an MS Exchange server they can test it against. Or at least they have only one, and MS Exchange, with it's various ways of being set up, and complex interactions with Active Directory.. well, it would be pretty hard to set up all the permutations. FWIW I have submitted all my Evolution Connector failures on FC4 and OpenSUSE, so hopefully this might change in the future. I know from email I have received from other folks reading my other postings in this area that they have found FC2 or FC4 don't work for them with their MS Exchange server but FC3's does. This is the basis for my thinking that it is site dependent  and implementation specific. For all I know, there are thousands that never see the problem. In my test lab I never do.

I say failures: what are they? I get one of two things:

1. A nasty message stating that the Evolution Connector / Storage has failed, and the client stays up, but can't see any storage.
2. A freeze where it's running, but it is not updating the email or any other new traffic as they arrive. I see stuff that it already knows about, but new stuff is just ignored.

And in every case, the calendar is *slow*. But I am willing to have a slow calendar to not have to switch desktops all the time. I am sure the average user looking to use Linux as a desktop replacement would not be.

Here is a funny part. I crash the MS Exchange server from time to time. But only when I use MS Outlook 2003 for calendaring (which, from a look and feel point of view I like much better the O97/O98/O2000). Or Outlook's web access calendar. But not when I use Evolution or Korganizer. This has meant, somewhat oddly that I have to stay on Outlook 2003 or Outlook Web Access, because on the offhand chance if it crashed while I was using one of the others, they would more than likely think the non-standard clients were the problem. 

I keep asking myself how it is so that any client (no matter which) can crash a server: that does not seem right. Should not the server say "Hey! bad client bits! I'm skipping them" or something a bit more... graceful?

To calendar right now, I run XP as a VMware guest, and Outlook 2003 under that. It works pretty well, but my poor laptop is running pretty hard all the time to keep up with it all. Thank goodness the T41 is such a stout machine. In a way, this "Killer App" is killing me.

I see that Mozilla is looking to launch a project to marry calendaring into Thunderbird called Lightening. And I see Ubantu is looking to build a .mac like service that includes among other things calendaring (which in turn is using the Hula project).  Then there is the PIM project Chandler that includes calendaring functionality, but has been on the slow boat for a while. Citadel has a calendar too, as do Open-Xchange and Kolab and many others

While interesting to consider, none of these projects appear to include any idea of interaction with existing calendars like those on an MS Exchange server. or Lotus Notes. or Groupwise. For obvious reasons: They all want to be standards based: things like iCal and CalDEV. I completely agree with the idea of being standards based: but this does not allow for smooth transition over time. It is a push-pull: You have to toss what you have. Didn't Intels Itanium misstep teach us anything (now Intel is even pulling the hardware assist for X86 from the chip)? Customers are not going to easily just toss everything wholesale, unless you have a situation something like a the city of Munich in Germany. Or a new business playing heads up ball when you build up the first time. Businesses normally have timelines and investment projects and focusing on their core business and passing their SOX reviews.

MS Exchange buries it client to server communications in extensions to MAPI and various RPC calls that they would have to reverse engineer to work with. It can be done: OpenOffice as I have said before works better with .doc than Word does for me. SaMBa is amazing of course, and SMB is no easy protocol to figure out.. But it is a lot of time consuming work. The closest we have right now are things like Evolution Connector and KDE's Korganizer, and they don't seem to be getting alot of work in this area right now. On the other hand, I just noticed KWord opens OpenOffice 2.0 .odt documents now! Cool!... but I digress...

So I circle back to where I started: I run a Linux desktop, but I have the MS Windows guest. I'd like to only have to run it when I am testing MS Windows specific things. But I run it all the time because that is how I have to calendar at the moment. It's OK for me as semi-power user, but it has kept broad adoption of a Linux desktop from occurring in my opinion. You have to change out your glass house and get all your apps standardized on open standards *first* to make a Linux client easy. The good news here is that Linux is making real inroads in the glass house, so over time this will probably happen. And those who are using AJAX to webify everything are going to make the client irrelevant at their place. And you could look at Codeweavers as a way to run a client side transition. I have used it since it first came out and it always amazes me to see Internet Explorer or Outlook running "natively" on Linux.

In any case, I think calendaring has been the killer app for years and years.