working title:

THE BIG KONTACT KOLAB INTERVIEW

First of all can you explain who you are and what is your role in the Kolab/Kontact project?

Tobias Koenig: My name is Tobias Koenig, I do KDE development since 5 years and since 3 years I'm the maintainer of KAddressBook.

Cornelius Schumacher: My name is Cornelius Schumacher. I started my KDE career by contributing to KOrganizer and I maintained it now for something like five years. On aKademy I passed on KOrganizer maintainerhsip to Reinhold Kainhofer. I also do various other things for KDE, one of them is trying to take care of kdepim generally.

What is Kolab and what is Kontact and how do they relate to each other?

Tobias Koenig: Kolab is a groupware server which was concipated as a replacement for MS Exchange. It consists of well known OpenSource software like Apache, CyrusIMAP, OpenLDAP and Postfix and can handle the storage of emails, contacts, events, todos and notes.

Kontact is part of KDE and integrates the main KDE PIM applications (KMail, KOrganizer, KAddressBook, KNotes) in one GUI. So it has the appearance of MS Outlook/Evolution but the advantage that all components can still run as standalone applications.

Cornelius Schumacher: Kontact is the integrated KDE Personal Information Management application. It supports access to various groupware servers. One of them is the Kolab server.

Kolab logo

How did the Kolab project start?

Tobias Koenig: Martin Konold, a former KDE developer, gave a talk on LinuxTag 2002 in Karlsruhe, which described a groupware solution build upon Open Source Software, which can be used as replacement for Outlook/Exchange.

At the same time, the BSI ("Bundesamt fr Sicherheit in der Informationstechnologie") was looking for such a solution to migrate their desktop systems to GNU/Linux. There was an invitation to bid and a lot of companies from out the OpenSource community attend. At the end a company group (Intevation GmbH, Klarävdalens Datakonsult AB, Erfrakon) got the contract. Erfrakon started to implement the Kolab server, Klarävdalens was responsible for the KDE based client software and Intevation managed the whole project.

Well what exactly does a Kolab server do? Because sharing folders on IMAP isn't a new concept.

Tobias Koenig: Well, Kolab is nothing more than a stupid but very fast data storage. The contacts, events and todos attached to mails which are saved in IMAP folders. Of course Kolab also offers a web based administration frontend, but the actual logic of managing contacts, events and todos is handled in the Kolab clients.

I heard about Kroupware and Proko2. What's with the names? How do these (appearingly separate) projects relate to each other?

Tobias Koenig: The contract between BSI and the company group was called 'Kroupware', it consists of Kolab1 and a KDE client, which was mainly a modified KOrganizer with embedded KMail. Proko2 is the name of the follow project, which uses Kontact as client instead of the hacked KMail.

What are your plans for Proko2? (new features wrt Kolab1)

Tobias Koenig: Well, everything is mentioned on the web page ;) [ bernhard and bo should know most about it ]

How many companies are involved with the Kolab project? I see the names Klarävdalens Datakonsult AB, Erfrakon PartG, Intevation GmbH and Toltec passing by. Can you eleborate a bit on your cooperation?

While MS Outlook uses their legacy TNEF format and it isn't capable of working properly with ical. How did you guys find a solution for that?

Tobias Koenig: Kolab1 used iCal format to store calendar information in IMAP folder, the conversion between TNEF and iCal was done by the Binary InsightConnector for Outlook clients. In Kolab2 the storage format was switched to XML, because iCal can handle a lot more data than the converted TNEF. So to let work Kolab clients and Outlook clients together properly, a new format was needed which matches the capabilities of both clients. The new XML based format is well documented, so 3rd party developers can easily integrate their software with Kolab2.

Citadel/UX, a BBS system claims to be Kolab compatible these days. Does this mean we can use Kolab compatible clients with Citadel like Kontact?

Cornelius Schumacher: Citadel/UX is quite interestinging because it has a long history and is a mature server system. There once was a KDE client for it which used KOrganizer as calendar component. I would love to see some more interaction between the Kontact and the Citadel/UX developers.

One problem we have with groupware servers is that there are no really accepted standards for them. There are several drafts for standards and quasi standards set by implementations, but there is no generally accepted standard how to access groupware servers. It would be great if we could work into the direction of something like a common way to access groupware servers. We did some very small steps but there is still a long way to go. I expect that this becomes more important in the future as the current situations isn't really beneficial for anyone.

The people at Citadel/UX claim that maybe the biggest most contribution would be your well-designed specfication and not the software itself. That's a rather peculiar statement. How do you feel about this?

Kolab stores mail folders using the Cyrus "maildir" format. Citadel stores everything in Berkeley DB. It seems you are using IMAP to access files on the server, which uses the filesystem and returns you that file. Why tell me .. why didn't you use a database engine for this like Citadel/UX does?

Tobias Koenig: The most optimized data base systems for files is the file system, so why using an additional data bases system upon it? Like already mentioned there is no logic in the server, all filtering and searching is done on client side. The left functionality of storing plain ascii files can be handled very fast by the IMAP server, so there is no need for a database engine. Beside this scalability feature this concept also allows an easy backup handling because backup tools for text files already exists and it's quite easy to play back a backup by just copying some files. Have you every tried to play back a backup of a database engine?

13 - A lot of people complain about the installation procedure of Kolab. Has the situation improved. Why was it such a pain to install anyway? Was this because of the openpkg format?

Tobias Koenig: For Kolab1 the installation procedure was really a PITA but this has been improved for newer versions and Kolab2 will be installable by simply executing one shell script. The reason was not the OpenPGK format, it's used for Kolab2 as well and has a lot of advantages. I guess the main reason was the limited time frame given by the Kroupware contract, so the developer didn't put much resources in implementing an installer but tried to get a stable Kolab version finished.

14 - Will Kolab in the near future be able to integrate more with an enterprise authentication system for single-sign-on (Openldap, Samba with LDAP support) (Maybe if you have Kerberos/Heimdal set up as well).

15 - Will Kolab have a mailman interface one day? Any plans for that?

Tobias Koenig: It's not planned yet because it's not part of the Proko2 contract. Nevertheless it's possible from the technical point of view, so voluteers are already welcome :)

16 - Which clients can work with Kolab and which platforms do they work on?

17 - Does the webclient Horde has the same level of functionality as the other clients?

Tobias Koenig: Shared folders are missing IIRC.

18 - The Toltec Groupware connector which the Outlook clients can use to connect to the Kolab server. What does the plugin do exactly and does the user notice its usage?

19 - People on the MS Windows platform can use the Kolab server through the use of the Toltec connector. What would be a compelling reason to use Kolab instead of let's say Exchange?

Tobias Koenig: Kolab is fast, Kolab2 will have the same functionality like Exchange and it's Free Software, that should be enough reasons to migrate :)

20 - How did you work out the differences between clients as Outlook and Kontact. Examples:

Tobias Koenig: The connector between Kontact and Kolab will handle this and save the additional fields, so no data be loosed.

21 - Also very interesting topic would be the cooperation with the Free Software project KDE. How did that work out? How were decisions being made wrt implementations?

Tobias Koenig: The cooperation is quite well, most staffers from the company group come from the Open Source community, so you can talk and work with them like with every other Open Source developer. There were also two meetings, organized by Intevation GmbH, where KDE-PIM developer and people from Klarävdalens Datakonsult AB attend to discuss the further steps for integrating Kolab support in the official KDE release. An evidence for the success of these meetings is, that KDE 3.3 will come with full Kolab2 support.

Cornelius Schumacher: I'm speaking from the KDE perspective and have to say that it was an interesting challenge. I really appreciate that the Kolab projects explicitely include integration of the client code into KDE development. In practice there have been some problems because the Kolab people actually didn't have enough time to do this integration in a smooth way, but in the end, I think, we can be happy that the Kolab client finally has arrived in KDE.

It's a general problem how to handle integration of third-party code into KDE as there are a couple of different interests which have to be balanced. Commercial contributors usually produce a lot of code which might be hard to properly review for Free Software maintainers doing this job in their spare-time and which is developed with a different goal in mind as the code coming from inside of the project is. The most important point is to talk with each other as early and as much as possible. There have been a couple of personal meetings between Kolab and KDE people and they have shown to be extremely valuable.

IRC-CS: that's the unique thing about Kontact, that it has managed to integrate the existing applications, both on a technical and a community level.

22 - Do you have examples of organisations using Kolab? (would it be smart to mention them?)

23 - Which distributions ship Kolab these days.

Tobias Koenig: It's only included in Mandrake10 IIRC.

24 - Where do you see Kolab (and KDE) going in the enterprise sector and what would be a compelling reason to use/switch to Kolab?

25 - It seems that Bynari is working on a IMAP implementation for their Insight Connector which will actually store calendar data directly in IMAP rather than merely synchronizing with it. Sounds like the same deal as with Kolab. Are there any differences?

Tobias Koenig: The concept is the same and the original idea of Kolab was in fact inspired by the Bynari groupware solution.

26 - Did other projects show any interest in Kolab? Maybe Mozilla(Thunderbird) and/or Evolution?

Tobias Koenig: Not really. The Mozilla developers seemed not to be interested at all and Ximian liked to sell their ExchangeConnector, maybe this will change now after Novell has published the connector under GPL.

Kontact logo

27 - As Kontact is the Kolab client on the KDE platform how did Kontact happen? Which parties were involved? Any sponsors involved maybe?

Tobias Koenig: Kaplan, the predecessor of Kontact, was developed before anybody thought about Kolab. It was designed as

Cornelius Schumacher: Kontact actually has a long history. It started as an experiment in 2000 under the name Twister, was reintroduced in 2002 as Kaplan and finally started to become what it is today in 2003. Maybe the biggest single step to make Kontact happen was Don Sanders porting KMail to providing a KPart for integration in Kontact.

The nice thing about Kontact is that it only is a very thin integration layer on top of the existing PIM applications which doesn't sacrifice the ability of the application to run stand-alone. So most integration is happening in the applications themselves and not in the Kontact framework. Details about the technical and social aspects of the Kontact as application integration framework can be found in the paper I presented at the USENIX conference 2004 (http://www.kontact.org/files/kontact_freenix_paper.pdf).

28 - What groupware servers does Kontact support?

Tobias Koenig: Currently Kontact can use Kolab1 and eGroupware as groupware server, support for Kolab2 and OpenGroupware is work in progress.

Cornelius Schumacher: In addition to Kolab it supports eGroupware and the SUSE Openexchange Server. It also supports iCalendar over HTTP. That's what Apple iCal does. It's hardly groupware, but it's useful for a lot of nice things (see e.g. http://www.icalshare.com). There also is some basic support for Exchange and OpenGroupware, but that isn't ready for production use.

Kontact now also supports Novell GroupWise. Thanks to the quality of the KDE framework it took us only a week to implement the basic functionality.

We will certainly see support for even more groupware servers in the future.

29 - What happened to support for Exchange2000 calendering in Kontact? [http://www.microsoft.com/sharepoint/]

Tobias Koenig: At the moment we have a halfway working solution for calendaring with Exchange2000. Since Ximian has released the source code of their Exchange connector it would be quite easy to write a connector for Kontact as well, but it seems no KDE developer is willing to do so ATM...

Cornelius Schumacher: It's currently unmaintained. There is not missing much, so if somebody would step up and take care of this code we would have Exchange support in Kontact in no time.

30 - Why did you choose to reuse existing applications like KOrganizer, KPilot, KMail, KAddressbook, KNotes, KNode, etc .. for Kontact and not building a new application from scratch.

Tobias Koenig: KMail is the best OpenSource email program existing IMHO and with KOrganizer and KAddressBook we already had two other important parts of a PIM solution, so why should we start from scratch? KDE offers with KPart, XMLGUI and DCOP an uncredible cool framework which made it quite easy to integrate these applications without throwing away existing and well tested code, so it was clear that's the way to go.

Cornelius Schumacher: The existing applications are all great on their own. They have healthy code bases and developer communities. To throw this away for a new application written from scratch would have cost us many years of development effort. As the KDE component technologies make it so easy to integrate the applications there is no doubt that the Kontact approach is the right way.

31 - What kind of syncing technology is used now in Kontact? What happened to kandy?

Tobias Koenig: For KDE 3.3 we'll provide KitchenSync as a syncing framework for Kontact and every other KDE application. KitchenSync is plugin based, so every developer can implement its own plugin to add syncing support for new mobile devices.

The development of Kandy has nearly stopped, as soon as the KitchenSync API will have been stabilized, Kandy will be rewritten as a KitchenSync plugin.

Cornelius Schumacher: We have KPilot, which does a really nice job synchronizing Palm OS devices with KDE, and KitchenSync. KitchenSync is supposed to be the future all-purpose syncing solution, but it still has a long way to go before that becomes reality.

Kandy is on halt for a long time. It does work for me, but for a lot of phones it doesn't. I still plan to integrate it into KitchenSync at some time. That's also the reason why I didn't spent much time on it as a stand-alone application anymore. A few weeks ago I recieved a large patch for Kandy. So it looks like it could get some live on its own again.

32 - Are there any plans to integrate other syncing technologies so it can sync with other type of handhelds then just Palm pilots. (think SyncML)

Tobias Koenig: Of course, there is already a halfworking plugin to sync devices with the Qtopia/OPIE environment and support for SyncML is also work in progress.

Cornelius Schumacher: There is some work going on in this area. I'm also trying to follow the activities in other projects. There might be some opportunities for working together with other projects on some common syncing framework (e.g. the OpenSync initiative on freedesktop.org), but it's hard to keep track of what's happening in these areas. There are just too many and too special  projects.

33 - How is kitchensync progressing and how will it adress syncing (in the future). What possiblities does it offer?

Tobias Koenig: Over the last month KitchenSync development was nearly stopped because the lack of time of the developers. At the moment Cornelius Schumacher and Holger Fryther try to implement the last important missing feature and then we have to make the GUI a bit more userfriendly.

With the Qtopia/OPIE, MultiSync and SyncML plugin we'll be able to sync nearly all kind of mobile devices. PIM data from Palm Pilots can be synchronized with the KDE desktop via kpilot but it's planned to integrate it into KitchenSync for KDE 4.x.

Cornelius Schumacher: KitchenSync is supposed to become a generic syncing framework which can easily be extended by plugins for support of any specific devices. The KDE 3.3 release contains an initial version which is able to synchronize addressbooks and calendars between KDE desktops. There is more to come, but as syncing is a really hard and ugly problem it's not progressing as fast as we all would like to see.

34 - What does Kolab and Kontact project need the most now?

Tobias Koenig: I'm not entirely sure what the Kolab project needs, but developers and user for testing are always welcome. Kontact needs a lot of usability improvements, with the help of OpenUsability.org we are currently working on it, further help is always appreciated.

Cornelius Schumacher: Contributors. There are so many nice ideas which could be implemented, if we only had some more people doing actual work. The KDE framework makes it possible to do development in an extremely efficient way. It's amazing to see how far we have come with Kontact when taking account how few people we are and that most of the work is done in our spare-time. That's only made possible by the high quality of the framework and the unique spirit of the KDE community. It's inspiring to work on Kontact and it's also a lot of fun. Everybody is welcome to join us and share the experience.

35 - Where can people get more information about Kolab and Kontact

Tobias Koenig: Both projects have web pages which you can use as start point for information. Furthermore you can contact the developers directly for questions or ask them in IRC.

Cornelius Schumacher: See the web.

    http://www.kontact.org
    http://www.kolab.org

    FAB: It seems that already a client existed for Citadel/UX 
         http://www.shadowcom.net/Software/infusion/screenshots.html