When I think of Microsoft's grip on the desktop market -- the one that's been so hard to break -- two products come to mind (neither of which is Windows). The first is Microsoft Office.
Even though there's a version of Microsoft Office for the Mac, the demand for Office ultimately wags the Windows dog by the tail (to the benefit of Microsoft). And, as most people know by now, there's been no shortage of news on the break MS-Office's grip front, particularly in the context of the Open Document Format (ODF): an open productivity suite file format standard that has caused Microsoft to make its own file formats far less proprietary (for a Massachusetts/ODF status update, check out OASIS general counsel Andy Updegrove's most recent blog). The one-upsmanship in this small but growing cottage industry could very well eat larger companies alive. The theoretical result -- being able to work with electronic office documents (ODF or Microsoft-formatted) without the need for Microsoft Office -- could level the playing field and ultimately weaken Microsoft's franchise. Based on how much people actually like Office (me included) Microsoft could still win handily if it wants to in a comply with standards compete on implementation world.
While office documents have been enjoying most of the limelight recently, there's another Microsoft stronghold that's traditionally been much more fortified against would-be competitors than MS Office ever was and it too is beginning to take some some heat: e-mail and calendaring. Back in the very old days, after Microsoft acquired Network Courier (I used to run several Network Courier-based e-mail systems) and turned it into Microsoft Mail (this is pre-Exchange days), it also began work on MAPI (Messaging Application Programming Interface) (Tom Evslin where are you? Oh, there you are.) Among the many design goals of MAPI was the integration of e-mail and calendaring into a single client/server protocol.
The two (e-mail and calendaring) are really a match made in heaven. Since two of the key things that groups do are communications and meetings, they belong together. It also makes perfect sense technologically and contextually. For example, to receive an invitation to a meeting via email and to be able to RSVP that invitation without having to switch context out of email (for example, having an "accept" button right on the email) is right from a user experience perspective. Email and calendars are also the two data types that people most want to replicate from email and calendaring servers to a variety of client-side technologies including software on their PCs, PDAs, smartphones, etc. In other words, one server to do both (email and calendaring), one piece of software in each of our client side devices to take delivery of that email and calendaring data, and one pipe (the email/ calendaring protocol) through which to pass that data back and forth between the end points. Anybody who has had to access their email/calendaring system (eg: Exchange Server or Lotus Notes) via POP3 or IMAP knows all to well how much it stinks to lose the calendaring part of the email/calendaring combination (POP3 and IMAP are for email, not calendaring).
So, when very early in the game, Microsoft's MAPI protocol covered both email and calendaring (and with the only real competition at at the enterprise level being Lotus Notes which early on worked off a protocol called VIM), it was no surprise that organizations started to adopt it en masse. And as Outlook (the client side part from Microsoft) became a good email/calendaring solution on its own (capable of replicating data to and from other devices such as iPAQs and BlackBerries), Microsoft's email and calendaring solutions took root to the point that the barrier to switching to something else (particularly if that something else doesn't offer both email and calendaring) makes the switch either too costly or pointless. Today, Microsoft's Exchange email and calendaring server remains one of the important reasons that organizations remain committed to other Microsoft technologies such as its operating systems (Exchange Server only runs on Windows) and Active Directory. Now that there are some organizations looking to route out their reliance on Exchange Server and all that it depends on, there are solutions on the market that make migration possible without forcing companies to do painful swap-outs on the client and server sides at the same time (eg: Novell's Ximian Evolution and Scalix's very AJAXian Linux-based email/calendaring solution).
But now, somewhat out of the blue, comes a blog entry from TechCrunch's Michael Arrington (the one that inspired me to write this one) that spotlights the upstart of a new cottage software industry (replete with a listing of providers): AJAX-based calendaring systems. This week, he's writing about SpongeCell. Next week, it could be someone else. Even more interesting is the innovation that's taking place around "platforms" like AJAX and Ruby on Rails. Says Spongecell's home page:
No complicated tools. Just send new events or queries to firstname.lastname@example.org. Send "next" and we'll reply with the details of your next appointment. Add us to your phone's address book.
Now, maybe this sort of solution isn't nearly as good as tying your Windows Mobile 5.0-based smartphone to your Exchange Server, but the innovative thinking regarding simplification of what can otherwise be a fairly complicated process is the sort of thinking that gets traction with the masses. That there's a list of other providers each with their own spin on how to make group and Internet calendaring much easier spells trouble for the established providers such as Microsoft and IBM (via its Lotus division). The problem isn't that their solutions aren't as good (or better in other respects). It's that they simply aren't as nimble. The pressure to innovate and the one-upsmanship in this small but growing cottage industry could very well eat larger companies alive should any one of their innovations catch on like wild fire the way Flickr for example caught everyone in the online photo business by complete surprise.
"So, it's just calendaring" you say. "It's not e-mail and just like you said David, it's the merger of e-mail and calendaring that makes solutions like those of Microsoft and IBM so compelling." Right. Well, I agree. Going back to POP3 and IMAP's limitations to e-mail, if you just have one side of the email and calendaring duo covered, it might not be long until you feel like an technological amputee. I've tried to figure out ways to fudge it. For example, using my email/calendaring client to serve as the integration point of POP3 and iCAL in a way that simulates what I'd normally get through Exchanges or Lotus Notes. It's not worth the effort. But now, with email providers offering API access to their email services and calendar providers providing API access to their calendar services, it won't be long before there are a host of mashups out there that blend the two in a way that we can have our cake and eat it too. Have our cake in that our email and calendaring is tightly integrated without needing a proprietary technology to do it for us. Eat it too in that those solutions will offer us new innovations -- like the aforementioned idea of SpongeCell's -- that are addictive, but on a much more frequent cycle than any of the established providers could ever meet.
And that's the uh-oh! moment that IBM, Microsoft, and even others like Novell (with its Groupwise) should be having right now, let alone the proverbial aha! moment.