KDE Dot News recently spoke with some prominent people from the Kontact and Kolab projects. We talked about how both projects got started and how they have evolved. Enjoy the first part of this two-part 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 have been doing KDE development for 5 years and since 3
years ago I've been the maintainer of KAddressBook.
Cornelius Schumacher: My name is Cornelius Schumacher. I started my KDE career by contributing
to KOrganizer and I have maintained it now for something like five years. At aKademy I passed on KOrganizer maintainership to Reinhold Kainhofer. I also do various other things for KDE, one of them is trying to take care of kdepim generally.
Steffen Hansen: My name is Steffen Hansen, I work for Klarävdalens Datakonsult AB and
have been on the KDE project more or less since the beginning. I am
the lead developer of the Kolab server.
Bernhard Reiter: I am a managing director of Intevation GmbH, which is a Free Software company. For Intevation I coordinated the Kroupware and Proko2 contracts.
What are Kolab and Kontact, and how do they relate to each other?
Steffen Hansen: Kolab is a Free software groupware solution. The components are the
Kolab server and Kontact, which is the KDE Kolab client. There is also a Kolab web client in the works.
Tobias Koenig: Kontact is part of KDE and integrates the main KDE PIM applications
(KMail, KOrganizer, KAddressBook, KNotes) into one GUI. So it has the appearance of MS Outlook/Evolution but
the advantage that all components can still run as standalone applications. Kontact supports access to various groupware servers and one of them is the Kolab server.
Bernhard Reiter: Kolab consists of several components:
- Kolab Solution Architecture
- Kolab Server implementation
- Kolab Client implementations (especially the KDE Kolab Client)
So I would say the current Kontact can act as KDE Kolab Client.
How did the Kolab project start?
Tobias Koenig: Martin Konold, a KDE developer, gave a talk on LinuxTag 2002
in Karlsruhe, which described a groupware solution built upon Open Source Software that can be used as
replacement for Outlook/Exchange.
Bernhard Reiter: I have to comment on Tobias here. The Kolab Server
was not designed to replace MS Exchange. We addressed this question in our Kroupware FAQ:
"So no, it's not a goal to build a replacement for Exchange
or Outlook. On the software side we have assembled a solution that
solves some typical asynchronous groupware tasks like group
calendaring. Our usage of standards like disconnected IMAP and the
iCalender format is a new, innovative approach."
What exactly does a Kolab server do? Because sharing folders on
IMAP is not a new concept.
Steffen Hansen: Correct! The server uses well-known and available free software
components like OpenLDAP, Postfix, Apache and Cyrus IMAP server plus some
custom code to glue it all together.
The features you get from the Kolab server in addition to just using the
individual components (mail, web, imap,...) are:
a) Central configuration. The tweakable configuration parameters, user
database and so on are stored in one central place: The LDAP
database. Centralised administration of the Kolab server is done
through a web-based interface.
b) Multilocation support. Because of a) it is possible to set up
multiple Kolab servers that share configuration and user database. It
works by the use of LDAP replication. I see this as a very nice
feature for both supporting multiple weakly connected locations and
for being able to scale up to multiple servers to support huge
numbers of users.
c) Groupware specific functionality. The Kolab server contains code
that does automatic appointment handling for group and resource
accounts on the server. It also creates and manages freebusy lists for
I heard about Kroupware and Proko2. What's with the names? How do these
projects relate to each other?
Tobias Koenig: The first project was called 'Kroupware',
it consisted of Kolab1 and a KDE client, which was mainly a modified KOrganizer with embedded KMail.
Steffen Hansen: 'Proko2' (which stands for "Project for Kolab2")
had a main focus of enhancing usability of the client and adding features to the server to allow
groups of people to collaborate, do server based virus scanning, the
multilocation feature and so on.
Bernhard Reiter: The names refer to two contracts to deliver a groupware solution.
Our companies did this with Free Software and started Kolab.
Kolab is a Free Software project and thus has potentially
different players and goals than what the contracts might say,
so we needed to come up with names to decouple this
and being able to openly talk about it.
For example we did not want to overpower the
naming of the client done by the KDE community.
How many companies are involved with the Kolab project? I see the names
Klarävdalens Datakonsult AB, Erfrakon PartG and Intevation GmbH passing by.
Can you eleborate a bit on your cooperation?
Steffen Hansen: These three companies combined their efforts
to create a crossplatform groupware solution. But we need to mention a few others as well:
Radley Network Technologies is a South African company that make a
plugin called Toltec Connector for Microsoft Outlook. It allows Outlook
to use IMAP for mail and groupware data. Radley's has put a big effort
in adding the Kolab-specific features to the Toltec Connector to allow
it to interoperate with the Kolab server and other Kolab clients. Among
other things, this includes support for reading and writing the XML
format that Kolab clients use for internal storage of groupware data.
Communication between clients is done with iCal/vCard.
A fifth company also deserves mention here: CodeFusion. Like Radley's,
they are also based in South Africa. CodeFusion offers professional
Kolab support, they have helped out with implementing some
server-features and they also work on the web client.
Microsoft Outlook uses the legacy TNEF format which is not capable of working properly with iCal. How did you guys find a solution for that?
Steffen Hansen: Well, let's first make a distinction between the format used for
communication and the format used for storage. Both Kolab1 and 2 do indeed use standard
iCal for inter-client communication (ie. sending invitations
etc.). Kolab1 also used iCal as the storage format to store your
calendar etc. on the imap server. Unfortunately is has not been
possible to create a solution that allows Kontact and Microsoft
Outlook to share the same storage based on iCal. iCal is too flexible
in some respects and not flexible enough in others. Therefore Kolab2
uses an easy to read/write and well documented XML format for the
Creating our own format has been frowned upon by
some, but I really think that it has been a big help for us to have
our own format that we could tailor to our specific needs to be able
to make both the KDE client and Outlook 'happy'. For the end user, the
visible result of using this new format is that he/she can switch back
and forth between Outlook, Kontact and the web client without having
to import and export data between them.
Citadel/UX, a BBS system claims to be Kolab1 compatible
these days. Does this mean we can use Kolab compatible clients like Kontact with Citadel?
Bernhard Reiter: As far as I remember they are not fully compatible with Kolab1 because
free/busy handling, directory server architecure and lack of legacy
support make it slightly different. Apart from that you probably
can use it with Kolab1 clients.
Cornelius Schumacher: Citadel/UX is quite interesting because it has a
long history and is a mature server system. There once was a KDE client for it which used KOrganizer as the 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 for access to 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 make some very small steps but there is
still a long way to go. I expect that this will become more important in
the future as the current situation isn't really beneficial for
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. Tell
me.. why didn't you use a database engine for this like Citadel/UX does?
Steffen Hansen: We strongly believe that you need a storage mechanism that fits the problem to
be able to scale up. Mail messages are variable sized independent
pieces of data stored in a tree-like folder structure. This looks a
lot like a filesystem to me. For an example, look at the statistics for
Carnegie Mellon (the home of cyrus imapd):
I seriously doubt that you can scale that high with a database-based solution.
Using mail messages for storing calendar information might seem odd at
first, but it is actually quite nifty. Having one calendar entry per
mail makes it easy to merge data when you have manipulated your
calendar from several places. Also, conflict detection/resolution can
be done nicely with this approach.
A lot of people complain about the installation procedure of Kolab. Has
the situation improved? What made it such a pain to install anyway? Was
it because of the OpenPKG format?
Tobias Koenig: For Kolab1 the installation procedure was really a pain
but this has been improved in newer versions. Kolab2 Server is 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 and
the developers didn't put much resources into implementing an installer but tried to get a stable
Kolab version finished.
Steffen Hansen: Now the server installation has been streamlined a lot. After
fetching the install script, all you need to do is this:
[wait while it builds and installs]
[follow on screen instructions for initial setup]
/kolab/bin/openpkg rc all start
[now the Kolab server is running. You can go to the
webgui and create users and so on]
Will Kolab in the near future be able to integrate more with an enterprise
authentication system for single-sign-on? (for example OpenLDAP, Samba with LDAP support and maybe
if you have Kerberos/Heimdal set up as well).
Steffen Hansen: I can not make any promises, but this is something that has been on
our own wishlist for some time.
Will Kolab have a mailman interface one day? Any plans for that?
Tobias Koenig: It's not planned yet. Nevertheless it's possible from the technical point of view, so volunteers are already welcome :)
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 MS Exchange?
Steffen Hansen: Using a Kolab server instead of MS Exchange buys you better scalability,
higher reliability and a soft migration path away from proprietary software
on the desktop (because you can gradually introduce Kontact and it
will share data with Outlook).
Tobias Koenig: Kolab is fast! Kolab2 will have the same functionality as
Exchange, and it's Free Software.
Another very interesting topic is the cooperation with the Free Software
project KDE. How did that work out? How were decisions being made with regard to
Tobias Koenig: The cooperation went quite well, most of the staff 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 three meetings, organized by Intevation GmbH,
where KDE-PIM developers and people from Klarävdalens Datakonsult AB attend to discuss the
further steps for integrating Kolab support into the official KDE release. Some evidence of the
success of these meetings is that KDE 3.3 was released 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 project
explicitely includes 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 has finally arrived in KDE.
It's a general problem of 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 from the code coming from inside of the project. 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.
Although free and well known software applications are used, some of them
need to be patched before they can be used for kolab. Components that need
patches are: apache, cyrus imapd and amavisd-new. This makes it almost
impossible for distributors to integrate kolab. How is the kolab project dealing with this? For details see: http://wiki.kolab.org/index.php/Kolab-major-app-patches
Is there any intention to use apache2 instead of apache?
The 'LDAP Account Manager' http://lam.sourceforge.net/
seems a nice application for kolab. Any change that it will be used in kolab?
> Is there any intention to use apache2 instead of apache?
Kolab 2 does not make any heavy use of apache specific features so going for Apache 2 in the future is no big issue.
We depend on Apache 1.3 for Kolab 2 mainly because it is stable and supported while there are still known issues with Apache 2 and PHP.
I'm really happy that there are finally some groupware solutions appearing for unix. Thank you very much for this interesting interview!
Still, I have some questions:
- There once was an idea to set up a kolab-server for the kde-community. One could integrate bugs, mailinglists, resources, todos, schedule kde-meetings and all that stuff. Also, one could probably stress-test kolab quite well with this setup. Why didn't this ever happen? Because of the costs?
- I understand that putting all data into a single database might be a little too much. But since I've never understood (and even grown to hate) LDAP, I am wondering why all the configuration-data that now lives in LDAP wasn't put into a database, like mysql?! What are the disadvantages?
- When I tried kolab at version1, it took me a couple of days to find out that the data stored with the kde kolab client is the same data that is accessed with the webinterface, but the outlook/toltec connector uses its own set of data and is NOT synchronized with the webinterface or the kde client. Thus, kolab1 was useless for me. I understand this has changed with kolab2?
In the second interview, I would really appreciate to hear about the synchronization plans. IMO, Syncing is one of KDEs really confusing areas. There are so incredibly many pieces of code meant to synchronize something (opensync, wince-sync, kitchensync, kpilot, multisync, kde-resources, kandy and all their friends) without a plan on how to bring it all together. Whats going to happen?
> I am wondering why all the configuration-data that now lives in LDAP wasn't put into a database, like mysql?
I guess it depends on your LDAP configuration, there are SQL backends, arent't there?
No, this hasn't changed with Kolab2. There is still no web interface which can access the same data like Kontact or Outlook which is probably mostly due to the concept which requires that any client keeps an offline IMAP4 cache of the complete data and per user.
So writing a web client is basically the same like writing a new groupware server from scratch _plus_ all the Kolab syncing stuff on top.
This is nonsense. There is a webclient under development. Basic functionality is avaliable, but it will take time to complete the features. The webclient is able to access the same data as the other clients. Everything else would be against the concept to have one server accessibla with different clients.
The question was whether Kolab2 _has_ a usable webclient (one which works for more than 50 appointments in a folder), and it doesn't (if its in development for _Kolab3_, all the better!).
And apparently the development has stalled (a webclient needs to implement offline IMAP to be useful with Kolab and that is probably out of question for something like Horde).
Anyway, tell us if there is a webclient for Kolab which actually works in practice. The concept seems to be strictly focused on fat clients.
> a webclient needs to implement offline IMAP to be useful with Kolab
Why would that be needed?
The webserver is part of the Kolab service it has direct (over loopback interface) access to the other services such as the IMAP server.
Because its part of the Kolab concept for clients, read it? Besides the IMAP4 protocol doesn't allow for range queries (like gimme all events from this monday to friday) as required for a web calendaring client, so live access is a no-go.
> Because its part of the Kolab concept for clients, read it?
No, that's why I was asking.
Might still be possible without, usually clients are on a remote machine where reducing network operations matters.
> Besides the IMAP4 protocol doesn't allow for range queries
Well, unless I am complete mistaken on what offline IMAP is, it is still IMAP, only using a local cache. All the query logic has still to be implemented on top of that.
So my guess is that caching greatly improves performance but is not necessarily required (technically).
>lives in LDAP wasn't put into a database, like mysql?! What are the disadvantages?
Nothing lives in LDAP, because LDAP has no storage. It is strictly an access protocol. LDAP allows you to change out the storage mech. . If you like you can use DBM, DBM, or flat-file, without changing the client or the protocol. If this goes down the DB path, then it is locked in. No scaling. No flexability. Think MS solution.
While I have not seen kolab2, kolab1 used imap to handle the sync. Good idea.
> - There once was an idea to set up a kolab-server for the kde-community.
> One could integrate bugs, mailinglists, resources, todos, schedule
> kde-meetings and all that stuff. Also, one could probably stress-test
> kolab quite well with this setup.
> Why didn't this ever happen?
Due to lack of resources (mainly a decent server with a good connectivity).
As soon as server plus bandwidth is available I am more than happy to provide a maintained Kolab Server to the community!
> - I understand that putting all data into a single database might be a little
> too much.
What kind of data are you talking about?
> But since I've never understood (and even grown to hate) LDAP,
> I am wondering why all the configuration-data that now lives in LDAP
> wasn't put into a database, like mysql?!
The biggest advantage of LDAP is that it is a network access protocol while MySQL is a product with proprietary protocol network clients. Another plus for LDAP in the Kolab design is that it features a simple, efficient and reliable replication protocol.
Using LDAP as the access protocol says nothing about the storage technology.
Actually most LDAP servers use some kind of (relational) database in the backend.
> What are the disadvantages?
Relational databases are incompatible to each other and many clients including Kontact, Mozilla, Microsoft Outlook and Lotus Notes know how to retrieve information like addressbook data via LDAP but they are not capable to talk to a MySQL db.
> accessed with the webinterface, but the outlook/toltec connector uses its
> own set of data and is NOT synchronized with the webinterface or the kde
> client. Thus, kolab1 was useless for me. I understand this has changed
> with kolab2?
Yes, with Kolab 2 all Kolab 2 clients (PHP, KDE, Windows) use the same new Kolab 2 storage format. Basically this new format is a set of iCalendar attributes encoded in valid XML including an XML Schema (Relax-NG).
The new storage format was intentionally created in order to allow for the usage with shared folders. Multiple different clients can have simultaneous read and write access to the same folder and its objects.
> In the second interview, I would really appreciate to hear about the
> synchronization plans. IMO, Syncing is one of KDEs really confusing areas.
I agree that synching is currently confusing. For the Proko2 project we limited ourself initially for syncing with the Palm Pilot for the KDE platform. With MS Windows/Outlook any existing OL-based synching solution keeps working so plenty of choices are available. We currently have no plans for synching support via the webclient.
hey i use US locals cause I want kde in American English but I want my kweather to display temperatures in celsius. I didn't see anything about it in kcontrol accessibility and stuff, only how to change to metric system. Anyone?
thanx in advance
Looks like you can't choose Celsius without 'metric'. The code that decides whether to use C or F does it based on KLocale::Metric (kdetoys/kweather/metar_parser.cpp:437). Doesn't make much sense, but then again, measuring in body parts lengths doesn't make sense to me, either. At least, the U.S. are in good company: Liberia and Burma use imperial units, too. :-)
Well, I think that I would prefer to have american with metric standard.
(I am American who spent too much time in a lab).
I wonder, if it is possible to simply create a setting for it (I do not know the Locale code).
> I would prefer to have american with metric standard.
US + metric is no problem. It's US + imperial + Celsius that doesn't work now.
How is kweather set to US (F)?
Great program...as is KDE and LINUX!!!
Thanks Fab for this very nice interview.
Kolab looks like a great project but the weak point is marketing. Intevation should make some effort before the release of Kolab2 to revamp the Kolab website, have a much clearer message to what Kolab is about, scrap all the stuff about Kroupware, Proko2 that are more internal cooking that something you wan't to communicate on.
I don't know which is the best between OpenGroupware and Kolab but OpenGroupware has clearly much better marketing.
Actually the Kolab server and OpenGroupware.org are complementary. Since Kolab server is just a Cyrus server / Postfix MTA plus an LDAP setup, OpenGroupware can use it as a regular backend. There are setup guides for that on the documentation website of OpenGroupware.
Then of course is the question why one would want Kolab server at all since all those daemons are standard on any current distribution anyway, including polished configuration interfaces (like YaST for example). The requirement to turn of the system daemons maintained by your favorite distributor in favor of packages patched by "someone" seems rather outdated?
Please read the concepts behind the groupware solutions before posting. Both solutions target the same areas, but the technical concepts are different. It is correct that the integration of Kolab in a universal services machine (ftp, http, mail, cvs, whatever) is difficult, but Kolab is made for larger installations where you'll have dedicated Kolab server anyway. There you won't worry about other deamons.
I've read about that, too. From the paper it looks like Kolab is targetting fat-client installations (web interface near to impossible due to offline IMAP4 requirement) with 100.000 and above (overkill for installations <1000?). On the other side the only reference which uses Kolab seems to be the German BSI which sponsors the whole project. BSI might be some hundreds of users at best and certainly doesn't count as a "larger installation".
Are there actually any _large_ Kolab installations? I suppose it would be really great if some references (besides BSI) would be posted in the followup article! So far it sounds like a university research project and I guess people wanting to switch from Exchange are curious about real world examples!
PS: for a large installation I would rather ensure that the mentioned services are maintained by one of the bigger Linux companies which have sufficient resources to ensure proper QA, like in SLES 9 or RedHat AS (or Debian if you want to go for free).
>BSI might be some hundreds of users at best and certainly doesn't count as a "larger installation".
The german authorities do have "a few" hundred thounsand employees...
The German "authorities" do not use Kolab, only BSI is known to actually use it (as mentioned, some deployment examples would be cool for the next article). The current Linux migration guide for German authorities list a lot of groupware servers.
BTW: Besides there are no really "big" German authorities given that this is a federal republic with a lot of smaller ministries (usually some hundreds of users, only sometimes a few thousand). Quite different to for example France where you have huge ministries (with more than 100.000 employees in a single location).
> Actually the Kolab server and OpenGroupware.org are complementary.
I know that this information can be found on the OpenGroupware website though it is incorrect. Kolab 2 is a substitute for traditional database driven groupware solutions.
> Then of course is the question why one would want Kolab server at all since
> all those daemons are standard on any current distribution anyway
Kolab has many advantages compared to OpenGroupware.
Just consider scalability, security, offline support and support for MS Outlook clients for example!
I still believe Evolution is a way better solution for an enterprice, it has the Exchange pulggins and a Windows version is on the way and the next version will be plugginable.
Kontac is more oriented to the home users.
In KDE 3.4 Kontact features Exchange support as well. Furthermore a port of Kontact to Windows should be much easier and faster to do than porting Evolution to Windows for various reasons (Actually some parts of Kontact have already been ported to Windows).
"Furthermore a port of Kontact to Windows should be much easier and faster"
Sounds good in theory, but we all know this will never be done.
Since most of KDE already runs on windows. Like this.
And the goal is to do it even better.
Using Cygwin, you must be joking! I don't think that KDE apps are easier to port than gtk+ apps, eg GIMP works just fine on Windows.
If I remember right, there are also issues with Qt on Windows, doesn't this require licensing costs?
The first link shows it works NOW, with Cygwin. As are more than you can say about the alternatives. Except Athera who actually uses the a modified KOrganiser as callendar part:-)
As for porting to windows, you have to compare KDE to Gnome and Qt to gtk+. Then let the numbers speak, Qt applications clearly outnumbers gtk+ ones.
Had you actually tried the links, the second link would have shown you a working port of the GPL Qt to windows. Already used to port applications, not simple ones at that.
I think "me"'s point is that it is as easy to port a GTK or Qt application with Cygwin.
The real issue is when making a native binary port without using some sort of virtual machine environment.
Compiling a native binary of Kontact in Windows would require Novell to buy Qt licenses and that's probably why they have followed the path of using Evolution, even if it is harder. The issue is not technical, it's practical, that's "U"'s and other's points.
Anyway, personally, I couldn't care less about free software being ported to Windows.
Compiling a native binary of Kontact in Windows would require Novell to buy Qt licenses
That would be the fastes way, another option would be the route they are taking with GTK+, porting Qt/Free to Windows, or more accurate, finishing the ongoing portin effort.
After all the current cygwin stage is only considered an intermediate step towards a fully native Win32 port of Qt/Free.
The work in porting to Cygwin is not in the GUI part in any case, so the toolkit does not really matter. The fact is that the Qt port is already functional.
If the problem are for Novell to buy a few Qt licenses for their developers, you are right the issue is not technical. But it's also far from practical, it's political. In this case tho, I'll guess this is more like some kind of backroom program than a Novell strategy, since Novell already have a successful Groupware solution on windows.
> Sounds good in theory, but we all know this will never be done.
The PIM developers seem to think different:
>> Waste of time. Kontact/KMail etc. are KDE integrated apps.
What does that supose to mean?
No idea, I was referring to Ingo's posting.
I do not understand why Novell does not buy Trolltech and make Qt LGPL for Linux.
I think this would solve many problems because as far as I read is Qt technical much mature and better crossplattform than GTK+.
So instead of tinkering with GTK+ for other platforms they could save time and could concentrate their efforts on developing Kontact and port it with less effort to Windows.
And maybe this would also attract more developers developing applications in C++ for Linux instead of using C with GTK+.
OK - maybe I'm a bit offtopic now.
> I do not understand why Novell does not buy Trolltech
Maybe because Trolltech has currently no interest in being bought?
Evolution is as buggy as hell, and has got more so over the past three or four years. Porting the thing to Windows is rather pointless and will create an absolute ton of new work and bugs. I don't think they realise how much work it will be. It also raises serious questions as to how Novell's desktop migration to Linux is going.
" Evolution is as buggy as hell"
Then you should check your distro or pc, my Evo installation is rock solid and is fast.
Kontact by the other hand keeps crashing on me, I dont really care cause I don't find it mature enough to using at work anyway.
Your comment shows that you haven't understood at all what Kolab and Kontact are about. And if Evolution is really that cool, it should be easy to provide support for the Kolab server beside of the Exchange suppport.
I don't know, they are already to busy with the Novell Groupware.
And I know what Kolab is and what is pretending to do, but honestly, I dont think it will be successful, why? simple, it is QT based, that mean, if you want to implement, lets say, a pluging for it in your own enterprice you have to pay to Troll Tech for the developers tools, and that's at least $1,500, and no, not every enterprices like to opensource they technique, and even so, according to QT licence you must pay if you are getting benefits of QT in your enterprice, that's why I think it won't be adapted, not for enterprices and surely not by countries.
First, it's written "Qt". Then, assuming you talk about the client side who forces you to write your plugin with Qt?
That's why is not a viable solution, if I have to use a third party tool for writing plugins for it, I don't see the point of using it at all, if I use the Qt tool kit, then it is at least $1,500, those are two big showstoppers for Kolab.
I guess you are mixing Kolab and Kontact here. Kontact is Qt based, but as far as I know there is no Qt requriement when developing a Kolab client.
> not every enterprices like to opensource they technique
They don't have to distribute their code as long as they use is purely internally
> and even so, according to QT licence you must pay if you are getting benefits of QT in your enterprice
No, you are mixing that with the Qt/non-commerical licence for Windows.
Qt/Free as available on Unix/Linux and OS X is at least licenced under GPL and GPL does not allow such a restriction.
>> No, you are mixing that with the Qt/non-commerical licence for Windows.
Exactly, and since 90% of the world pc users use Windows, they are atached to this license, that's the big problem.
I fail to see the problem.
Kolab runs on Unix/Linux systems, the communication with the server does not require Qt, so there is no need to use Qt on Windows if you want to access the Kolab server.
Very likely the most used Kolab client under Windows is currently Outlook with one of the connector plugins.
>>> Very likely the most used Kolab client under Windows is currently Outlook with one of the connector plugins.
That's the answer I needed, thank you.
> Very likely the most used Kolab client under
> Windows is currently Outlook with one of the
> connector plugins.
You've just reached his point. :D
His point is that Kolab can't be successful because he thought it would put a Qt dependency on its usage, which it does not as I explain and what he acknowledge.
So this means we have reached the point where we both agree that Kolab is going to be successful because it can be used by a number of different clients on different systems, even allowing the use of already deployed clients and just changing the PIM server.