Kolab: David and Goliath
Groupware is a tough domain to break into. With competition from giants the likes of Lotus Notes and Exchange, how can an open source offering, like Kolab, ever hope to compete?
Groupware is an overused and ill-defined term, so you have to make clear what it is you’re talking about. It’s often taken to mean any software that allows users to work together on common projects over a network. Such programs usually package together email, a shared calendar, task management, an address book and document management as a minimum. Just about any organisation that uses a computer these days needs some sort of groupware on their systems. If you use a computer on the planet Earth, you’re probably aware of two groupware programs that dominate the market, namely Microsoft Exchange and Lotus Notes. Between them, these entrenched players can boast hundreds of millions of users around the world and the backing of some of the wealthiest technology companies in existence. It’s a tough domain to break into and not one you might automatically associate with open source software.
Nevertheless, it’s in this domain that Kolab has positioned itself. Kolab is just one of a number of collaborative software applications, both proprietary and open source, which fight to be noticed on a crowded stage. How on earth can a participant in this market hope to distinguish itself, not only from the giants of Microsoft and IBM, but also from a sizeable pool of other more similar players?
Entering the groupware domain can be fraught with difficulty if you wish to see any significant usage of your application. In such a well-established realm, where proprietary technologies have long reigned supreme, how can users be convinced to leave their current applications behind and take up an alternative?
Imagine this was your groupware product. You know that users, through desire or necessity, often want to keep using their familiar old systems and will resist change. Any proposed alterations to their setup must therefore cause minimum disruption or risk being rejected; key features must remain intact and the disruptive effects of migration should be few. You basically need to entice users away from the world of Exchange in favour of your product. It needs to provide the same feature set and it had better offer compatibility with Exchange, or an easy migration path at least.
Many free and open source (FOSS) products are in this very position. A popular strategy that emerges is to retain Outlook as the desktop client (sometimes offering web and phone interfaces too), but connected to new back-end systems. By building on FOSS technologies, and by virtue of its smaller size, a company attempting this should be able to offer an alternative at a cheaper price than a full-blown Exchange installation. Sounds reasonable, yes?
Kolab’s alternative strategy
As it turns out, customers with tight IT budgets may go for it, as would smaller clients with humble requirements and an even humbler bank balance. However, groupware users who are more financially flush are apt to stay with Exchange, paying a premium for the warm feeling of ‘reassurance’.
“In short,” argues Paul Adams, “this approach is basically a race to the bottom. You can hoover up the smaller customers but the bigger ones will stick with Exchange.”
Dr Adams is the chief operating officer at Kolab Systems, the professional organisation behind the Kolab groupware. He and his colleagues believe they know how to avoid this downward race and achieve real success in the FOSS groupware domain. And it’s not just idle talk – it’s the strategy on which they are driving the development of Kolab.
Kolab Systems was formed in 2010 to provide services around Kolab, as well as leadership of the development community. Prior to this, the software had been commissioned by the German government in 2003 (see page 60 boxout ‘Profile: Community and Company’). Accordingly, FOSS issues were given a high priority from the start. The CEO of Kolab Systems, Georg Greve, has been outspoken on issues of freeness in groupware and other so-called ‘open source’ alternatives.
“Often they turn out to be open core,” Greve explains, pointing out the disappointing mix of proprietary and open source. “But there is another, bigger problem. Outlook is based on the Windows platform. And while the web clients give some level of platform independence even for Microsoft Exchange itself, there are many scenarios where web clients are just not good enough.” We still live in a world where users insist on the rich client experience. If the rich client is Outlook, available only on Windows and Mac, that poses real problems for users of a free operating system.
In light of all this, Kolab’s strategy is somewhat different from its competitors’. Kolab itself is still clearly groupware, but it’s trying to distinguish itself in different ways. I first learned about Kolab’s alternative approach when I briefly helped them set up their new community website in 2011. You can better appreciate this approach when you realise the nature of Kolab’s architecture.
“Kolab is not a single monolithic application,” Adams explains. “When you deploy the Kolab server, you’re actually deploying several independent services. The job of the Kolab code is to make all these work together.” These are programs like OpenLDAP, Postfix, Cyrus and OpenSSL.
Hence, Kolab’s developers are not trying to compete on the terms of the entrenched market leader; the Kolab back-end has nothing to do with an Exchange server at all. Instead, Kolab provides its own server, one which makes extensive use of open standards and can boast of being 100% FOSS. The server uses IMAP as its underlying protocol (not just for email storage, but other information too, like tasks, calendar events and contacts) and configuration and user details are stored in LDAP directories using Kolab’s own, published XML format. Other open formats are supported too, like iCal and vCard.
By glueing several independent programs together, the developers of Kolab make extensive use of open standards. Of course, this can make their job more difficult, but it pays dividends. As well as the obvious modularity, there’s the interoperability which makes Kolab a fertile ground for innovation. For instance, at a recent development sprint, Kolab engineers collaborated with OwnCloud developers to work on integrating OwnCloud functionality into Kolab, a possibility thanks in large part to modularity and open standards.
And it’s not just on the server that Kolab deviates from the norm. Kolab’s tagline is ‘Five platforms. One groupware,’ a reference to the rich-client support on no less than five different platforms, including Linux, Windows, OS X, Maemo/MeeGo and Windows Mobile. But, as already mentioned, achieving a consistent cross- platform user experience is a challenging thing to do. What’s Kolab’s answer to this problem?
Kolab’s client is actually based on Kontact, which itself is a KDE-based application. For several years now, it’s been possible to run
Qt-powered applications on a wide range of operating systems, meaning that Kolab’s client is as consistent and widely supported as Qt allows it to be. Nevertheless, a web- based client is available as well. In fact, the recent release of Kolab version 3.0 might make all this rich-client vs web-client talk quite redundant, because the new release sees Roundcube becoming the application’s default web interface. While web-based mail clients typically aren’t enormous fun to use, Roundcube has been making a big name for itself thanks to a highly fluid and responsive interface. Its judicious use of AJAX makes the browser-based experience much closer to traditional rich-client applications.
Kolab races along
So how is Kolab faring in the race? Is it, too, destined to serve only small customers, making do with the crumbs off Exchange’s table? Its makers claim not, although they’re frustratingly unable to cite specific examples, as much as they’d like to brag.
“We can’t reveal names,” admits Paul Adams. “Large organisations see their choice of groupware as a strategic advantage and so prevent us from advertising them as users.”
The best he can do for now is cite certain tricks up Kolab’s sleeve which are essential for attracting big users. Chief among these are the flexibility on offer and the scalability that results from it. When I worked with the community, the developers often boasted how a Kolab sysadmin has lots of options when it comes to evolving their system. Because Kolab is made up of loosely coupled parts, components can be spread out over several machines. The mailboxes, the storage folders, the authentication server etc; these could all be deployed on different machines and maintained separately. This allows an organisation to scale their deployment with a fine level of control, increasing power or space to individual services. The standard approach to scaling – purchasing new boxes as demand increases, installing a separate copy of the whole server on each one and then managing incoming requests via load balancing – seems like overkill beside Kolab’s method. It’s on these grounds that Kolab’s developers claim its suitability for a wide range of users, from small clubs and societies right up to enterprises and governments.
And speaking of elite users, there’s one other attribute of Kolab that makes its developers beam with pride, and that’s security. For big business and government, security of data is paramount. When they use groupware, they want it to be as hard as possible for an attacker to gain unauthorised access to user data. Kolab’s approach makes this very difficult indeed (not surprising when you learn that Kolab’s first major user was the German Federal Agency for IT Security). Storing data the standard way – on a server-side database, like MySQL – means that the data store has an admin account that can automatically access all the contents. Therefore, the danger always lingers that a cracker compromises this account and so gains access to all an organisation’s data.
This danger isn’t present for a Kolab installation, because a central database administrator simply doesn’t exist (although a MySQL database is necessary for certain components to store application data). Instead, all of the user’s data are stored in IMAP folders under the auspices of a Cyrus server and are accessed via services. To get at their data, a user must authenticate against a service. Thus, if a cracker manages to compromise an account, they would only be able to access the data belonging to the compromised user. Without a central admin account, the cracker cannot gain themselves sweeping access to user data.
At the moment, the Kolab community are busy with their latest major release. Kolab 3 has just been launched and brings a raft of improvements to existing features. Version 3 also aims to make Kolab more easily integrated into an existing setup; it will happily work with an existing LDAP system rather than its own, should you be migrating.
Other changes include the internal data format, switched from Kolab’s own version (XML based on iCal and vCard) to xCal and xCard. One of the developers’ other devotions, security, also gets a boost from the improved mobile synchronisation. Users will be able to have different credentials on mobile devices, so that the main credentials aren’t compromised in the event of a device being lost.
The final release of Kolab 3 was made available on 15 January and the community are now aiming for a six-monthly release cycle. Meanwhile, the race to offer FOSS enterprise groupware will continue.
This article was originally published in Linux User & Developer 123. You can get our latest issue, and subscriptions, from our online shop.