There are many solved problems in open source. Groupware is not one of them.
How else would you explain the number of migrations that fail on average in groupware? The Swiss canton of Solothurn is just one example among many as a result of groupware vendors who have given up and transitioned to Outlook or the web to meet their needs. Kolab does things differently. For one, Outlook will never be the client for the Linux desktop. And, the web is a good answer for a lot of things, but not all.
The city of Munich is another good case to look at; they successfully completed a Linux migration that has saved them millions of Euros. But now, the newly elected mayor and his deputy have made the news by publicly considering a migration back to Windows. To explore this further, let's first ignore for a moment that the City Council would need to approve any change in strategy and has renewed its dedication to LiMux. Let's also ignore the fact that the City employees do not consider it a good idea to go back to Windows.
So, what was it that prompted LiMux to be put into question in the news?
If you guessed that Office interoperatbility may have something to do with it, you would be right. As long as there are competing standards there will be incompatibility between the dominant vendor and the rest of the market. Document exchange remains a constant issue that is ultimately only solved at the political level. This particular problem is not technical and the UK has recently demonstrated that they will choose open documents as the standard format to deal with it.
The other main criticism with their use of LiMux was the lack of an integrated groupware system. Until today, the city of Munich is using the same stand-alone calendaring and email systems it had used when it was still fully operating on Windows. Updating these systems had a lower priority than the migration to LiMux then. But an upgrade is underway now. And, the solution they chose is agnostic to the desktop platform and will service LiMux and Windows alike. The primary difference made by another migration would likely be due to the perils that come with any migration, such as additional costs and delays.
In other words: The very problem used to criticise the LiMux desktop is already being solved. By Kolab, the same collaboration solution used for over 10 years at the German Federal Agency for IT Security (BSI). It's particular strength? The ability to service highly heterogeneous environments in a secure, scalable, and controlled fashion. As the only groupware solution on the market with a true native client that is available for Windows and Linux, it can deliver consistency for users across platforms. And its web client is so user friendly and powerful that its stand-alone webmail component Roundcube is the world's most popular web mail application, with more than half a million installations worldwide. The native connectivity for Mac OS X applications will be less important for the city of Munich. But its robust mobile phone integration is precisely what the mayor has understandably come to expect from a modern installation.
Work on the solution is, of course, never done. The recent Kolab.org 3.3 release has given special attention to usability. We also had to think about how to ease the transition from the old calendaring system with a user concept almost diametrically opposed to today's applications. Whereas modern systems are largely email and invitation based, the old system does not "invite" people. It adds events to their calendars as open invitations. Email plays almost no role in this, and it is not actually integrated with the system. To make it more interesting, the old system has shaped user expectation and patterns. Such as a default policy of each user being able to see any other user's calendar. And, while previously only some users had a calendar, in the future all users will have one. So we're talking anywhere in the realm of 40,000 to 120,000 shared calendars depending how users are set up.
That is by no means an easy scenario to address and an interesting challenge. We have come across installations where despite a virtually unlimited amount of computing resources, Microsoft Exchange was failing and ultimately replaced by Kolab. But those installations had fewer shared folders than the city of Munich. Fortunately Kolabs architecture supports these requirements. But, making this usable and breaking existing user habits and patterns as little as possible is a different matter, entirely. So, we fundamentally changed the way in which users navigate calendars to processes that users should find familiar. It's ultimately based on quick search within sessions and favourites for regularly accessed calendars across sessions. And because we like consistency, Kolab applies that logic to all groupware data now.
To facilitate the transition, the Kolab team is also adding views of open and declined events within the calendar as well as a whole lot of automation under the hood by virtue of policies that allow updates to propagate, implementation of organisational policies as to who can invite whom, and a range of improvements in the resource management realm. Now it is possible to invite non-unique resources and get confirmation from the first available resource of the pool—because you may not care which of the four identical projectors you get assigned, as long as you have one for your presentation. Resources now also get their specific invitation dialog with a resource finder that let's you see the resource's calendar.
Much of this has been on the wishlist for users in the city of Munich for a long time. The new system will combine an approach that protects habits and user patterns, as well as offering new, long desired functionality and more flexibility. Like, the ability to attach notes to emails and sort them through tagging. Or, a complete task workflow including assignments and email-based delegation and acceptance. And because Kolab Systems has the strongest possible upstream focus, adding new functions was always done looking at the bigger picture. So, in fact Kolab now supports full semantic cross item relationships under the hood and is constantly working on further improvements.
From the calendaring improvements came one of the most powerful features yet, the Calendar Quickview. When quick-searching for a user, a single button allows you to open a dedicated view that will show everything that user has agreed to provide to you. Whatever their internal folder structure, whatever their Access Control Lists (ACL), you'll see what you are entitled to see. And where you are not entitled to see details, you get the free/busy view merged in. It's very much a user centric approach that perfectly complements the general free/busy system.
As mentioned before, the city of Munich still has legacy Windows PCs for certain applications which can make full use of the web client. But, all of these new features are being provided also through the Kolab Desktop Client based on KDE PIM. That client will be made available for both the upcoming LiMux release, as well as Windows. So all city employees will have a consistent application for all their groupware needs, in addition to the web client.
So whether the city of Munich decides to continue down the path of LiMux success, or try its luck again with Windows, the groupware problem will be solved. Kolab will do its job in either scenario. And that may just be the deciding factor to convince all users of LiMux. Because once the pain goes away, so does the need for a scapegoat.
7 Comments