Please help us spread the word on Roundcube Next

Wed Jun 17 15:04:29 UTC 2015

Dear Paul,

On Wednesday 17 June 2015 11.58:57 Paul Boddie wrote:
> So can it work with other, widely-deployed components such as different mail
> systems? Yes, I am aware that it requires work. Yes, I am aware that it is
> not interesting to Kolab Systems. 

Quite the contrary. 

It is crucial to Kolab Systems to ensure this is always possible.

But supporting each and every possible combination of configurations out there 
in our own setup tooling is beyond the scope of what is possible for Kolab, as 
you have also experienced.

And once you also need to take existing system orchestration solutions into 
account which may already be in use the task at hand is ultimately tantamount 
to reinventing generic system orchestration. That seemed badly advised.

So instead we made a conscious choice to provide a "simple standalone default 
installation" to get things working out of the box for those who "just wanted 
to get it running for up to a couple hundred users", and otherwise give people 
the components in a way that they can use the orchestration they are already 
using and/or are familiar with.

Anything else brings you back full circle to either re-inventing the wheel, or 
limiting the option space for the components in play. That complexity is a 
direct result of the flexibility and versatility, which in turn are mandated by
the need to offer more than just a niche solution.

The "simple standalone default installation" is a way to hide that complexity 
from the "normal" user. But once you open that box, and start to modify part 
of it, the complexities come into play.

And yes, we understand this can be overwhelming.

The mythical man month applies to all of this. Which is why orchestration and 
configuration management systems look the way they do. They don't pretend to 
guess to know all that you want to do. They just give you the tools to apply 
your knowledge to the specific situation in a sustainable way.

> Sure. But I rather got the impression that without any real dialogue,
> significant improvements (or fixes) would not get adopted, 

It is true that substantial changes to Kolab that potentially affect a large 
number of users don't get adopted without first having had a chance to review, 
understand and discuss them.

> Yes, well I did that for a while. The tooling involved OBS, which is a non-
> starter for Debian "proper" (to put it charitably)

FWIW, the choice for OBS was not uncontroversial within Kolab Systems, but our 
community had voiced that preference. And we unfortunately did not have a 
better solution at hand although we are well aware that OBS is not perfect.

So we ran with it as best we could for the community and even spoke at the 
recent openSUSE Conference with which we co-located the first Kolab Summit 
about where we see the biggest potential for improvement of OBS and contribute 
upstream as best we can in order to improve it for everyone.

As a user of that technology it might also have seemed easier to just run off 
into our own corner and build a simpler thing that only did what we needed it 
to do. 

But that isn't really how we think Free Software should work.

> Oh, and being someone who believes in the merits of collaborative
> documentation, I tend to have my own ways of measuring the vitality of a
> project's community by looking at wiki edit histories, because they not only
> indicate how many real edits they get, but they also indicate how seriously
> the project in question takes the administration and maintenance of such
> resources. 

Most of the documentation has moved to docs.kolab.org some time ago for a 
variety of reasons, including that it can be generated from git, with all the 
advantages for branching, editing & merging on a consistent set of information 
in distributed fashion.

That said we would love to re-launch wiki.kolab.org and suggested that since 
it was filled largely with information for deprecated major versions of Kolab 
that it would just be set to read-only and we start from scratch in a new 
setup.

Because some people in the community insisted that it would be necessary to go 
through the entire Wiki and transfer it by hand instead, but then weren't 
willing to step up and make it happen, that process stalled.

And we're as unhappy about that as you are.

The moment someone steps up and offers to do the work I am certain we'll 
happily let that person take over this task, providing them with all the 
necessary infrastructure and encouragement.

But it is also possible that ultimately we may just have to do this ourselves, 
in which case I am sure some people will criticize that we just do this for 
the "corporate" interest of Kolab Systems. 

> But I don't personally care: given a choice of not being a productive
> contributor to "the vision" (with its supposed best practices and
> technologies) or improving my own level of knowledge and having the
> satisfaction (and, it must be said, frustration) of providing an
> alternative solution, I'd choose the latter every time.

That is fair enough, ideas and principles need to compete.

Your working on a project to compete with Kolab is entirely fine, of course. 

It's a big field, with a large number of competing solutions out there. 

So I wish you much success with that, since I would much rather have more Free 
Software competitors than proprietary ones because I believe the world will be 
far better off if there is a variety of Free Software solutions to divide the 
market amongst themselves.

As it is right now, none of the actual Free Software solutions has gained 
sufficient scale to make a deep enough dent into the proprietary market. 

In fact there are several "faux open" proprietary companies which in one case 
even buy up Free Software companies as they grow -- effectively still a 
concentration toward proprietary.

So perhaps you'll succeed in case we won't.

All the best,
Georg

-- 
Georg C. F. Greve <greve at fsfeurope.org>
Member of the General Assembly
http://fsfe.org/about/greve/
http://blogs.fsfe.org/greve/
http://identi.ca/greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20150617/ee804d36/attachment.sig>