[Kolab-devel] On the road to Kolab 3.0

[Georg C. F. Greve]

On 12.12.2011 11:02, Del wrote:
> I actually prefer having KVM set up locally. I already run Kolab in 
> KVM
> alongside other virtual servers anyway, so I am very happy with your 
> design
> choice there :) Testing is where I would start, but depending on the
> circumstances I may contribute in various ways.

That would be excellent!


> Everybody involved with Kolab really, meaning those of us who would 
> like to
> see Kolab fly, and spend our time and efforts trying to make it 
> happen. From
> what you are saying it sounds like the extensions to Roundcube will 
> not be
> accepted upstream, meaning that the maintenance and development
> responsibilities will be solely on the shoulders of Kolab-devs.

Who are those kolab-devs you're talking about that have been supporting 
Horde?

This is a serious question, because Intevation/KDAB/Kolab Systems had 
to carry virtually 100% of the load of Horde, with the upstream 
community not being very cooperative or interested in working together, 
leaving us stranded on a deprecated branch that we were maintaining 
ourselves, with one part time developer. This developer was busy most of 
the time struggling with the complexity of Horde, mostly working on 
repair-jobs which often ended up breaking something else, and had little 
time to do anything else. On top of this, the QA load on Kolab Systems 
by Horde was immense. My estimate would be that around 80% of all server 
issues were ultimately Horde issues, so it was very costly to maintain.

Simultaneously, the lack of usability and modern interface of the web 
client was the No 1 complaint for the Kolab Server.

There is *no* customer of ours that says they'd like to see Horde 
maintained by now.

Of course we'll gladly build up a Horde-Side of things again if we see 
market interest. But without an actual perspective that maintenance of a 
Horde client will become at least self-sustaining it is not something we 
can afford to do ourselves.

At the same time, Roundcube is a much leaner concept & approach, with 
an active, engaging, embracing community that is pushing this forward. 
Email & address books are undoubtedly central to the Kolab Client, and 
can be developed and maintained with an upstream that is actively 
seeking to work together and share the load. For the calendar we have 
some upstream projects with which we can collaborate, and we contribute 
back to these projects as well. As to the Kolab specific components, 
yes, we will have to maintain those ourselves.

But the basis on which that support can stand is much broader already, 
and the modular approach taken by Roundcube has really proven to be very 
good to work with.

So it's already cheaper to develop & maintain, we get much better 
upstream cooperation than ever before, and there are more people who can 
work on the code base.

The result is a client that has attracted comments from "Very nice" all 
the way to "That is one sexy motherf***!" with noticeably improved 
performance providing the cherry on top of the icing.


> Indeed. There are some patches to include Samba functionality, but 
> that only
> underlines the point. I am pretty sure easy and flexible set-up og 
> LDAP, if
> attained, will be a major selling point for Kolab. Low threshold 
> admin tools
> for LDAP is missing in general.

Yup.

So we want to make this another strength of Kolab, and the 
configuration API approach with a RESTful interface is likely to make it 
much easier to extend the administrative capacities, as well as the 
ability of other frontends to configure Kolab.


> It is the client I am thinking of, which has been the standard
> web-client for Kolab for quite some time now.

Understood. But while not so interesting, my suggestion would be to 
look at the framework to understand why these steps and the current 
development cycle are indeed necessary. The result will be that of 
course Horde can still be used as webclient, but it is no longer 
necessary to have and maintain the entire Horde stack for even the basic 
server-side functions.


> Thanks for the pointers to welcome contributions.

There are more, in fact. But those came to mind quickly with regards 
the web interface.

Something else people might want to look at is to include the ownCloud 
[1] interface into the Kolab Web Client based on Roundcube. ownCloud 
already supports LDAP, so we can hook this up to a single authentication 
source, and provides some nice aspects in terms of file storage & media 
player and so on. The result would be something I'd personally love to 
use.

And yes, I have more ideas, in case you're interested. ;)

Best regards,
Georg


[1] http://owncloud.org/

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