Calendar sharing in the XXIst century

This post is a bit of a rant, and I think it will resonate with people who have chosen to use online and shared calendars that are not provided by either Google or Microsoft. I will write it from the beginning: I still cannot believe we cannot achieve proper calendar interoperability in 2016. Again, if you are using Google Calendar or any calendar syncing and sharing technology provided by Microsoft, you may actually ignore this issue.

I have made the choice not to use the services provided by these two vendors, because I wanted to use open standards both for the calendar format and the synchronisation protocol. From the point of view of the Calendar output format, things have petty much settled down: almost any calendar software or service can import and export calendars under the ICal format. ICal is itself a proper open standard that has been developed by the IETF consortium and enjoys a very broad adoption. One of the most famous implementations of this standard is Apple’s Calendar, but as I wrote above, you may also use the ICal standard with Google Calendar, Outlook.com, Outlook itself, Claws, Evolution, Kolab Now and the Kolab server, the Horde stack and a many others. The problem, however, is that using an output format to share calendars with other applications or other people quickly turns out to be impractical. ICal is relatively easy to implement and knows no major technical issue; what it does not do however, is what should make a calendar useful: it does not update over time. Everytime a calendar gets edited and therefore updated, one would need to export it again via ICal, then send it to another user or another system, so that the new ICal file may be imported (again) into the other calendar.

I guess it’s workable enough if one were to work with very fixed calendars that change once every semester; but beyond that use case, calendars tend to get updated many times a week if not a day in a business as well as a family context. In order to work with these calendars in a smooth and effective way, the preferred way is to use synchronisation protocols. Microsoft has the famous ActiveSync protocol, which is widely used but not an open standard; other services such as Google or Apple usually will not disclose their protocols but will provide both the cloud storage, the web interface and the application (capable of working offline) for various platforms and devices. The alternative, yet thoroughly open standards based, is to use the “sister” standard to ICal, which is CalDav. CalDav is the standard protocol to sync calendars between different devices and between a server and clients. It is a true open standard and its maintenance is handled by the CalConnect Consortium. CalDav is by no means something that is out of the way: a whole breadth of services such as Kolab Now and Fast Mail rely on it to let their users sync between their calendar servers and their devices. Even better: there are commercial API services acting as middlemen between cloud silos that use CalDav to extract calendar and contacts and move them from one service to another: SmoothSync, Fruux and Cronofy for instance are on this market. CalDav is recognized as the “lingua franca” of the online calendar world.

But the point is this one: It is 2016 and shared calendars that should be simple and straightforward are both complex and obscure. People should not think twice about what to use: they should be able to share their calendars seamlessly, post it online, move from one provider to another with very little hassle. Instead of this most are locked in and when they want to move to another provider the notion that they should learn about the various calendar sharing protocols is simply outlandish.

There is more, and unfortunately it gets worse. The Apple stack does shine in its default calendar client, the eponymous iCal. It handles both iCal and CalDav very well. When you are on Android however, it gets… complicated. There are surprizingly few calendar applications able to handle CalDav; in fact, one first needs to install DavDroid (free on the F-Droid app store, available for a fee on Google Play Store), fill in its calendar credentials and then… nothing. Everything works well with DavDroid of course, but it is just not enough as it is by no means a calendar application, “only” a software enabling the support of CalDav and CalDav-capable calendar services on Android. Unless you’re using Samsung or Lenovo/Motorola, chances are your Android terminal won’t ship with a calendar out of the box. There are several of them available on the Google Play Store and the F-Droid app store: not all of them are CalDav ready and several of them can either handle local calendars or are front-ends for Google Calendar. The other shoe drops when one realizes that even Emacs is actually not that effective beyond its own local calendars (native and org-mode) and its Google Calendar client(s).

In short, running and using a shared calendar on a variety of devices, Android, MacOs & iOS, Linux and Windows is simply a crazy and somewhat absurd odyssey. In the end it is the freedom of choice and interoperability that are at stake; not that running an online and shared calendar based on open standards is not possible (Kolab Systems does that very well): it just does demand commitment, uncanny motivation and talent. The reason for this is complex, but the result is that sharing calendars online in 2016 still seems a very advanced technology. At the age of big data and software containers, it shouldn’t be. I guess life has its ways of reminding us of how frail we are as creatures and human organizations….