Can this free software company secure the future of Linux for the city of Munich?

No readers like this yet.
Organizations coming together like a puzzle

Opensource.com

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.

User profile image.
Georg Greve is co-founder and CEO of Kolab Systems, a full Open Source Groupware ISV. He has been in the industry for some time with a strong focus on software freedom and Open Standards. Previous endeavours include working on the OOXML standardisation process for Google, authoring the Brave GNU World and founding and presiding over FSFE between the years 2001 and 2009.

7 Comments

Great post! The key to resolving incompatibility issues is deciding on standards: standard document format, standard processes, etc. Then finding a tool that can accept the available formats, which users have access to, until the entire organization has completely converted and standardized on the decided format. For example, LibreOffice can read most Microsoft Office formats as well as the open formats. Yes, there are exceptions where some Excel or VBA formats may not translate. However, if these documents are converted to PDF, Linux users will be able to view them. Not an expert on Groupware so that's great that you've enlightened us on what's feasible.

P.S. (Please delete my first comment on this post.)

As the only groupware solution on the market with a true native client that is available for Windows and Linux...Just wanted to point out that the IBM Notes client runs on Windows, Linux, and Mac and offers application development in addition to email and calendar.

Java clients are native clients to the Java stack, not the underlying platform. With all the security implications this provides.

In reply to by JohnInPA (not verified)

That's complicating something that doesn't need to be complicated; java or not, Lotus is multiplatform for windows / linux / mac. Nobody else makes that distinction (for example, by calling it "native to the python stack". As well, php (used by roundcube) is not exactly more secure than java. Just trying to be fair here :)

In reply to by greve

Java is a full virtual environment, much like a virtual machine. And multi platform isn't necessarily the same as native on a platform. If one were to follow that logic, Outlook might also be "native" to Linux by virtue of a Windows virtual machine running on the desktop. And Lotus isn't the only solution native to the Java environment.

As to security: Only one of Java or PHP is responsible for 91% of all Indicators of Compromise. Hint: It isn't PHP.

http://www.eweek.com/security/java-primary-cause-of-91-percent-of-attac…

Because while PHP allows bad programmers to write very insecure applications, the language itself provides a *much* smaller attack surface than Java does.

In reply to by localdevjs (not verified)

An interesting article we're it not that we ran into a few very bad snafu's with kolab, Including being cuzzed out by jvm on irc time ago because we didn't understand the very complicated (but it has it reasons) LDAP implementation. the final answer we got was : "sorry if you want it done well you will have to pay, not going to explain you everything" . Not soo friendly and while its opensource and we all work with some degree of ideals (and while i fully understand people need to make a living) politeness and working together wouldnt be a bad thing. As a result we had to throw everything kolab out as that kind of attitude is not welcome at all. Domination by cleverly making a open-source product so complex the only way out is to hire the authors isn't really open-source either . its clever marketing lately done a little to much by some companies.
Sad it could have been a good product but the attitude ruins it completely for us jus tour two cents, maybe others have more luck.

I'm sorry to hear you've apparently chosen to go back to the proprietary world.

We've come across the expectation of free consultancy and support a couple of times over the years, so it's possible our technical team have not been quite as courteous as you were expecting in explaining that it would be extremely unfair to all users and customers that contribute to and support the development of Kolab by neglecting their tasks in favour of answering user questions on an IRC dedicated to coordination between developers.

Also, groupware is a complex problem.

If you want a generic solution that does NOT lock you into a particular path of technology or limits your abilities, some level of complexity is the price you pay. Which is why we've put extensive efforts into providing documentation for those with the necessary basic skills and education on the individual standard system components without duplicating their individual documentation since we don't think we could or should be doing a better job at documenting postfix (to take one example) than the postfix team itself does.

For those with a more casual engineering background we created a simplified setup with a set of sane default choices for those that just want to get running quickly. On top of that we're working with the distributions to get better packaging upstream, and simplify installation on a variety of platform-administration modules.

So indeed a lot of effort is spent on reducing complexity, although we realize that effort will never be enough to allow 100% of the population to set up and run their own server.

Especially since everyone's requirements tend to be slightly different. And understanding the individual requirements of every installation and setting up all components, such as the directory service, exactly as desired for that installation remains an expert task that will sometimes take substantial time and effort depending on how specific or peculiar the requirements are.

And while we prefer to spend our time on things that help ALL users and customers, we WILL gladly help individual users and customers with their problems.

But time so spent is not available for anything else, including improving the solution for all the other users. So indeed such time will need to be paid in order to ensure the many don't pay the price for the one who is not inclined to abide by the same rules as everyone else:

You can spend your time to build up the skill, solve your own problems, and contribute back with your time and knowledge. Or you can enable those who have spent that time and built the solution to advance it further for your own and everyone else's benefit.

That's a couple choices more than any proprietary solution would give you.

Which is one of the ways in which Free Software / Open Source empowers people.

But with great power comes great responsibility, including the responsibility to respect the professional time of others.

In reply to by alana mercant (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.