Kolab 3.1 adds WebDAV

Test builds for version 3.1 of the Kolab groupware suite have been released. As before, the system provides a solid mail, address book, and calendaring solution with both web-based and desktop clients available. But this release departs from the project's traditional reliance on IMAP and adds support for a number of new services built on top of WebDAV. The change has the potential to simplify deploying Kolab for many users and offices.

Kolab is a client-server groupware system. The data is stored and managed on the server and there are web front-ends available (such as the Roundcube webmail client), but the emphasis has long been on supporting outside desktop clients as well. Historically, Kolab used special IMAP folders to store contacts and calendar entries on the server, in addition to the email messages for which IMAP was designed. The project defined its own XML-based storage format that encapsulates other data types into MIME messages on the server side. It covers iCalendar events, to-do tasks, journal entries, and free/busy statuses, plus text notes, vCard contacts, and shared "resources" (e.g., conference rooms).

The Roundcube client that ships with Kolab includes plugins to utilize the non-email IMAP storage directly, and KDE's Kontact has long been the primary desktop application supported by Kolab. Support for the Kolab storage format also made its way into other groupware suites like Citadel. Many other client programs, however, required an add-on—such as SyncKolab for Mozilla Thunderbird or several proprietary connectors for Microsoft's Outlook. There are also several mobile clients for which Kolab connectors are available, although not all of them support the most recent version of the storage format, 3.0.

As one might guess, version 3.0 of the storage format was rolled out in conjunction with version 3.0 of Kolab itself, which was released in January 2013. Thus, the addition of an entirely new data access protocol for the 3.1 is all the more remarkable.

The project announced the plan in March, calling it both "the biggest and most exciting thing on our roadmap" as well as "the one people have asked us for most." Using the SabreDAV WebDAV library (in order to not "reinvent the wheel", according to the announcement), the project would add CalDAV and CardDAV access to scheduling and contact data. As the 3.1 alpha announcement explains, the old IMAP-based access protocols are not going away. The CalDAV and CardDAV functionality is implemented as a separate data access layer dubbed "iRony" by the project. The most obvious gain from the move is immediate access to Kolab server data from the sizeable assortment of existing CalDAV- and CardDAV-aware applications. The built-in Mac OS X calendar and address book fall into this category, but so do quite a few open source programs, including web-based, mobile, and desktop clients.

Kolab 3.1 is also adding support for general-purpose file storage, which will also be accessible over WebDAV. But the file storage functionality is not limited to WebDAV: the project has also implemented an IMAP-based file store, and it has worked with the ownCloud project to make an ownCloud server accessible as storage, too. The ownCloud-Kolab integration is not yet ready, but the Kolab project describes it as "trivial", as is integration with Dropbox or other cloud storage systems.

The 3.1 alphas also include the ability for multiple users to share mail folders. That is, not only can multiple user accounts read mail from a shared inbox (such as contact@example.com), but those accounts can also send messages as contact@example.com. Other changes incorporated include new administration features, like the ability to define a policy for how user account UIDs are generated, and support for managing multiple email domains within a single Kolab server.

The alpha release showcasing all of these new features is available from the project's Git repository or in packages for CentOS. Debian packages have been assembled in the past, but so far none are available for the 3.1 code.

Historically the term "groupware" tended to apply to information systems designed to support office environments, but it recent years that has changed. The public scandals about privacy breaches, surveillance, and user tracking that seem to plague every major web application service provider have served to raise the profile of open source groupware suites—increasingly, they are seen as a self-hosted alternative to relying on Google, Microsoft, and Apple for valuable web services, even if deployed only for a single user. The Kolab team is clearly aware of this shift, and cites the system's ability to serve as a private service beyond the reach of the NSA PRISM program.

Kolab has been in active development for just over ten years, and in that time it has earned a reputation for quality production in more ways than one. There are quite a few open source groupware products on the market, but many of them suffer from a lack of client compatibility, either working only with their bundled web front-end, or focusing on a small set of third-party client applications. Kolab has long offered support for a wide assortment of client endpoints, and implementing CalDAV and CardDAV access is likely to extend the reach of that assortment in a big way.

Support for these protocols is also a positive sign for CardDAV and CalDAV themselves, which in the past have been criticized as being overly complex (which, for example, gave rise to the now-abandoned GroupDAV protocol). Their slow adoption can be seen as part of a march toward compatibility among competing groupware projects, however. When all is said and done, it will be interesting to see whether this WebDAV support signals the start of a slow decline in support for Kolab's IMAP-based data protocols. But perhaps that would not be a tragic loss in the long run, as it might allow the project to expend less energy maintaining private protocols. The project does not like reinventing the wheel, after all, and as of Kolab 3.1 alpha, it is now responsible for maintaining two separate access protocols.