Open Source Groupware checklists

TuxIn the last months and years I had to deal with various requirements people have regarding groupware ecosystems. Open Source solutions have matured in this area and this article highlights some needs, but also some common pitfalls.

Preface

In these days there are many excellent Open Source groupware solutions out there. Two well developed solutions I saw in several productive environments are Zarafa and Open-XChange. Both of them are ready to replace Exchange in various productive setups, and I have seen both being deployed successfully as either Exchange replacement or even as a fresh groupware installation for growing offices and working groups.

Also the connection to the mobile world is common as well these days – thanks to z-push and the likes. Yes, there are some licence issues and I would prefer to use a CalDav solution. But ActiveSync works with open source tools pretty well.

However, there are still weaknesses in the Open Source groupware ecosystem. A big one is the Open Source fat client. Most of the clients (Evolution, Thunderbird and Kmail) do not work flawlessly with the currently available Open Source groupwares. Most of the services these days move to web clients anyway, but it is sad to see that there is hardly a well working groupware server fat client setup out there.

For example, in my personal working spaces I do need to sync Evolution with Zarafa, and KMail with OX. And in both setups there are components which do not work at all.

The needs

To better estimate the quality of a groupware solution here is a list of what such a solution should be able to provide:

  • Multiple address books and their synchronisation.
  • Multiple calendars and their synchronisation.
  • Different user rights per calendar.
  • The ability to overlay different calendars on the client side.
  • E-Mail-Invitations for appointments.
  • Free/Busy lists for other users, visible in the calendar view.
  • Collision handling whenever the problem comes up.
  • Centralized web interface for all components,
  • Support for sync of ToDos.

There is no need that one server does that all on its own. The address book could be delivered by ldap, and there are good calendar servers out there like DAViCal.

But even if this list does look pretty normal, some of the points are not covered by the solutions out there. For example: You cannot share multiple calendars with your Zarafa server and your mobile phone without using some ugly hacks. Also, the collision handling is often automatically, the user does not even notice any problems. Another problem is that hardly any solution can sync ToDos properly. And, of course, hardly any of the solutions out there supports Linux based fat clients properly.

Some common tests and problems

But even if a groupware solutions states on paper that it fulfills all the mentioned needs, it might fail in the day-to-day routine. Thus here are some quick tests and common problems which can be checked on demo or test installations to get a first impression:

  • Are multiple-day, recurring events synced correctly?
  • Are multiple-day, recurring events still correct after changed again and again on both sides?
  • Create a calendar with 40k entries, and sync it. How long does the re-sync take after some changes?
  • Are ToDos synced together with their due dates?
  • Let user B alter calendar entries of user A and check if these changes are properly synced.
  • Create a collision on purpose: is the problem solved or is the entry doubled? Is the user notified of the collision?

As mentioned, this list is just to get a first impression. If you are going to become serious about a new groupware, you have to analyze your workflows, and test the groupware ecosystem against these. I must say that most often the biggest challenge actually was to comprehensively identify all workflows! So don’t underestimate the importance of that, and how much time that task takes.

And, with all these tests: keep in mind that sometimes flaws only begin to show under heavy load. Don’t test with two calendar entries and one address book entry and be happy because that minimum setup works!

The solution

As with most real world setups, you should work two-fold: first, check what features you really need, and compare them against the stated features of each groupware ecosystem. Afterwards, pick the survivors and test them against the workflows you have in your daily routine. Don’t trust and hope.

14 thoughts on “Open Source Groupware checklists

    1. Kevin, Kolab does offer quite some of these features. However, the old version used the Horde framework, and many customers didn’t feel good about that due to security concerns. And with newer versions Kolab comes bundled with many other components like the directoriy server. I yet have to see a setup of Kolab 3 for example using an existing LDAP. It just seems hard to integrate Kolab into an existing ecosystem.

      But, I am currently involved in a project where we do evaluate Kolab 3 as the solution, yes.

    2. The new version uses Roundcube as its web interface and it looks and works great.
      The packaging has also been improved greatly, as in no longer requiring installation of everything into a special directory but integrating into distribution’s package system.

  1. Indeed, I surveyed all open source groupwares a couple of years back and concluded that Kolab was the only serious contender. The only weakness in Kolab is its dependency on Kontact. Kontact in itself is excellent, the problem with it is that cross-platform support has been slow to mature. I am not sure Kontact is stable on OSX or Windows yet.

    1. I am not sure what you mean with dependency on Kontact. Kolab is the groupware which is best supported by Kontact and Kontact is most likely the client with the best Kolab support, but neither does that imply that other clients are incapable of supporting Kolab nor that their support would be always inferior

    2. If dependency on Kmail is the only weakness, then it has no weaknesses :-).
      Some other projects with groupware-features are Horde and Tikiwiki. However, setting up a working Horde installation is like LinuxFromScratch

    3. Kolab can also be used with Thunderbird afaik. Also, there are Outlook Connectors, so there is not really a need for Kontact, or is there?

    1. I only highlight Open-XChange and Zarafa because I saw them in productive use cases. There is currently a Kolab project starting off, but its simply not done yet. I hope that I will be able to share some insight into that project once it is done.

Comments are closed.