First and second impressions of Kolab as a groupware server

It is itself built from many standard open source technologies including Apache, PHP, Perl, IMAP and LDAP. The names may not be familiar but the value behind the design is sensible. By re-using standard compontents, kolab plays to the existings skill sets of those who manage it. This makes it easier to customize and extend if necessary.

On the desktop, it was easy to set up Kontact clients to integrate with the Kolab server. From the start screen of the program there was a link to follow which lead me to through a wizard to complete the process.

Yet, for these benefits, Kolab didn't feel like a good fit. While Kolab was easy to install, it actually installed 120(!) new packages to complete the process, and starting about eight new to run continuously. While building in everything that would be needed for a large deployment, it felt like too big a hammer for the simpler task at a hand.

For a specific example, Kolab accomplishes a shared calendar through a concept called a "shared folder". First I had to discover this, since I don't usually think of a calendar as a folder. This folder is actually an e-mail folder that the calendar program pays attention to, but the e-mail program basically ignores. That seems like an odd solution to me.

My first impression of contact sharing with equally cumbersome. I was looking for a solution which each member should share contacts freely with others. Kolab appeared to only share contacts that were managed through it's own interace. To add a new contact, it seems users would have to use Kolab's web-based interface rather than a standard desktop addressbook person. Again, I could see how this could work well for sharing a central corporate directory, but wasn't what I had in mind for a small business solution.

Other alternatives for small business calendar and contact sharing

At Summersault, we have a simple way related:to share digital calendars among a team of five, including Mac, Windows and Linux users.

Simply, we use different desktop software, but they share two features: First, they export the standard ICal format. Second, they allow subscribing to multiple remote calendars, so we can all subscribe to the other calendars without the need for a central server.

I plan to explore an option more along these lines for my next project.

I'm hoping to find an equally simple solution for contact sharing.

Two approaches seem promising to consider: Evolution is a desktop PIM suite that has the ability to allow users to share contacts be providing everyone write access to shared LDAP server.

Thunderbird is the mail program the team is already using, and it would be nice to keep using it if possible. If LDAP write access could be added to Thunderbird, it could be the ideal solution here.

Now a second look, a couple weeks later.

When I last looked at Kolab as a groupware server, I came away feeling it was not a good fit, in part because the storage model didn't make sense to me.

After further consideration, I've come around. Storing all the data in an IMAP server actually makes a lot of sense. I took the liberty of starting a page on the Kolab wiki detailing why.

Kolab can quite readily share all kinds of groupware resources, including calendars and contacts, through shared IMAP folders. It's not necessary to involve an LDAP server for this, nor is it even necessary for users to use this set of IMAP folders for their e-mail, if simple a sharing scheme is sufficient.

In summary, I discovered the Kolab can scale down as well as up, and it was easy to set up this way. It just took a little patience to read the documentation and understand the design.

In the process, I've also become very impressed with Kontact as a groupware client. Not only does it work well with Kolab, it appears to work well with several other groupware servers.

Several of these other groupware projects put a focus on providing a web-based interface to all the data. I already have favorable first impressions all the options that I looked at.

As a professional web-database programmer, exploring these options further appeals to me because it may mean I have a greater ability to understand and modify the systems myself if I chose to.

Apparently my adventure exploring groupware isn't over yet!

One thing has become clear: there are fewer and fewer reasons to chose Exchange and Outlook as a solution, as alternatives exist that are lower cost, have the features and compatibility and are based on open source and open standards.