Question: Individual annotations vs One large annotation (conceptual riddle for the interested)

Gunnar Wrobel wrobel at
Tue Oct 11 15:38:18 CEST 2011

Quoting "Georg C. F. Greve" <greve at>:

> On Tuesday 11 October 2011 14.14:29 Gunnar Wrobel wrote:
>> Why call it "braindead"?
> Because it does not provide free/busy, web interface, mobile phone
> synchronization or anything else that makes up a groupware system and that
> people expect to have today.

But that is an unfair comparison :) I would compare Google IMAP with  
what we have with our Cyrus IMAP on the Kolab server. Of course I  
could install free/busy, a web interface and mobile phone  
synchronization for Google IMAP as a backend as well - assuming the  
Kolab format would support an annotation-less mode.

> It's pure storage with no logic, thus braindead.
>> Allow users to easily switch providers. Right now you need your own
>> Kolab server for that. Assuming there'd be Kolab hosters you'd still
>> be bound to those providers.
> ...or anyone providing virtual servers.
> That's a lot like saying "I don't like to use email, because it makes people
> dependent upon providers of servers." That is naturally true, but then there
> is a huge market of providers out there, and people can even run their own.

Administrating a Kolab server yourself is slightly more complicated  
then getting an IMAP account with any of the big providers like  
Google, Yahoo or the German, etc.

> All these options also exist for Kolab, and we're working to build a bigger
> market for providers in this, as well.

I don't doubt that but it will take a significant amount of time until  
the gap between the number of available IMAP providers and the number  
of Kolab capable IMAP providers will be closed.

>> Absolutely. I also don't want to cripple the Kolab format or limit
>> it's abilities. I would just like to support enough flexibility to
>> give the users a maximum of choice.
> But in this case maximizing choice will cripple the format, based on the
> assumption that "anyone providing virtual servers" plus "anyone providing
> Kolab services" together is not a sufficiently wide market to give people
> independence on what to do with their data.
> I don't think that assertion is true today.

Maybe this is a misunderstanding. I couldn't possibly teach the  
average computer user how to run a Kolab server in ten minutes.  
Getting an IMAP account with Google would be a different matter.

> The second assumption you're making is that people would prefer to  
> store their
> groupware data in a pure IMAP drop with zero groupware capabilities on the
> server, in particular no web interface or mobile phone connectivity.

Where did I make that assumption? Of course not. It is no problem to  
provide this functionality for any kind of IMAP server - assuming the  
Kolab format would support an annotation-less mode.



> My experience suggests this is true for less than 0.5% of today's groupware
> users, and those would be the ones who'd have no problem setting up their own
> Kolab server somewhere - so they are precisely *not* dependent upon that
> feature.
> So it's a feature for a group of users that do not need it and would instead
> prefer to take an alternative route to addressing the issue, but introduction
> of the feature would cripple the solution.
> To me that is not a compelling case.
> Best regards,
> Georg
> --
> Georg C. F. Greve
> Chief Executive Officer
> Kolab Systems AG
> Zürich, Switzerland
> e: greve at
> t: +41 78 904 43 33
> w:
> pgp: 86574ACA Georg C. F. Greve

Core Developer
The Horde Project

e: wrobel at
t: +49 700 6245 0000

pgp: 9703 43BE

More information about the format mailing list