Please help us spread the word on Roundcube Next

[Paul Boddie]

On Wednesday 17. June 2015 17.04.29 Georg C. F. Greve wrote:
> 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.

It's quite possible to support other systems (Exim for mail, OpenLDAP for 
directory services, Dovecot for mailboxes, and so on), and there is a demand 
for it, but it hasn't happened within Kolab itself. All I ask is that you 
consider why this is, other than stating that it is difficult.

[...]

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

So when the "community courtesy" tool known as setup-kolab cannot be improved 
inside the Kolab project, what are us outsiders to do? I suppose a fork of 
that would be harmless, but my mistake was to start looking at some of its 
"neighbouring" code and wanting to improve that, too.

And I never had a proper dialogue beyond private conversations asking me to 
accept that my contributions, however large or small, however invasive or 
uncontroversial, would potentially go unused forever. Good luck building a 
community on those terms!

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

To be fair to your colleagues, it is possible to just ignore OBS and use 
Debian tools to get the sources, package them up according to contemporary 
Debian practices, and produce packages that stand a slightly better chance at 
being considered for Debian: this is, after all, what I spent some time doing, 
and the packages are all still available, as is the packaging.

Nobody needs to reinvent anything, but applying OBS to Debian packaging is 
attempting to reinvent Debian packaging, and as far as I know it will never 
fly within Debian. You had volunteers that wanted to go beyond OBS (and were 
told to help improve OBS, perversely enough), and yet the only progress I saw 
was various egos being deflated so that everyone could get on board with the 
idea that Kolab's forked KDE packages might stand a chance of getting into 
Debian, which was really step zero of the necessary progression along that 
path, anyway.

[...]

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

I think you underestimate how unhappy I was about it, but I'm past caring 
about it now.

I honestly hope that the "some people" weren't the same people who migrated, 
say, the Qt Project's wiki content, which I heard was nothing short of a 
fiasco. (Hint to those people: dumping raw, incompatible markup into another 
solution is an insult to the contributors who worked hard to prepare that 
content, especially if it is up to those contributors to fix it up out of 
sheer embarrassment afterwards.)

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

I can tell you now that migrating stuff hither and thither is a lot of effort 
from recent personal experience. It's arguably better to manage content 
properly where it is, if it is in a half-way acceptable Free Software 
solution. And to do such work requires it to be rewarding and satisfying for 
those involved in one way or another.

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

Indeed. (Although it is also in the "corporate" interest to have a credible 
collaborative documentation presence because that actually influences 
potential customers, believe it or not.)

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

Actually, since my level of ambition is nowhere close, I'm working on 
something that might be considered to be an alternative to a small part of 
Kolab. Indeed, there wouldn't be any reason why it couldn't be used by Kolab 
or other solutions eventually.

I would have done that within the Kolab community had it been possible to do 
so, and I was even "encouraged" in the form of actually being asked *not* to 
do so but to instead "improve" the existing code, which of course could not 
realistically be improved because it isn't for people like me to change code 
that is delivered to your customers (paraphrasing what was actually said by 
someone else, not me).

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

You know, I don't see it being about Free Software solutions competing against 
each other at all. As a developer, I don't see it being about company Y 
winning over company Z where the winner takes all, and where whatever bits and 
pieces comprise company Z's software are taken out and publicly ridiculed, 
mostly because companies Y and Z should be free to use, and to actually use, 
many of the same things.

I can understand that at the contractual level it is a different story, 
though, but I shouldn't have to care about that. (Which was another annoying 
thing, being told that I, as someone who doesn't work for Kolab Systems, 
should care about - and seek to protect - Kolab Systems' revenue streams. You 
have to pay someone to expect them to care about that.)

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

I don't really think there's much more to add from my side, so I will thank 
you for your responses and your encouragement for me to continue along my own 
path.

Again, I am sorry to express my dissatisfaction in such blunt terms, but being 
unable to reconcile my own experiences with the public portrayal of the Kolab 
project, I could no longer remain silent on the matter. My hope is that those 
enthusiastically seeking to improve Kolab from the outside on future occasions 
will avoid the disappointment of having that enthusiasm drained from their 
very being in the way that I experienced, personal flaws or unrealistic 
expectations of my own notwithstanding.

Paul