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

[Georg C. F. Greve]

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. 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.

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


> 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.

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.

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 kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20111011/5bb84682/attachment.sig>