Please help us spread the word on Roundcube Next

[Paul Boddie]

On Tuesday 16. June 2015 20.47.53 Georg C. F. Greve wrote:
> Dear Paul,
> 
> On Tuesday 16 June 2015 16.50:15 Paul Boddie wrote:
> > Thank you for responding! I understand that you aren't able to respond to
> > specific points and have to watch your statements given your position.
> 
> That's really not so much the concern as a 24 hour limit in the day and the
> fact that I'm already spending ~12 of them per day on doing my part to
> ensure we can pay Free Software developers to write more Free Software.

Indeed, I feel like I spend rather too much time on side issues like this, but 
then again I cannot let some things go past without comment.

[...]

> > Can the one solution in its own realm (such as mail handling) be
> > incorporated into Kolab?
> 
> I guess there is always a first time for everything.
> 
> In my experience the specific strength of Kolab is that it makes a minimum
> of assertions in terms of what exists in local preference and
> infrastructure and is deliberately build as a loosely coupled swarm of
> micro-services that through networking and orchestration provide the Kolab
> functionality.

I am well aware of what the Kolab suite is, having had to stare at the 
dependency tree over a period of months, and having had to figure out why 
various advertised parts didn't work out of the box. Indeed, it was while 
facing down the despair-generating prospect of reworking one of those micro-
services to be something that more than a couple of people could bear to work 
with, knowing that such efforts would be off-limits, that I made the decision 
to have nothing more to do with it all.

[...]

> So I can understand complaints about Kolab being complex, about too many
> options to configure, about too much flexibility, and consequently also the
> difficulty in providing upstream contributions that cater to that
> philosophy, which requires a good grasp of the overall architecture in
> some cases.
> 
> But this is certainly the first time I heard it called "monolithic."

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. Yes, I even figured it out for one particular 
system that is deployed as the default on a major GNU/Linux distribution 
(guess which one). But did I perceive there to be a sustainable avenue of 
contribution? No. Maybe someone else has figured it out by now and will blog 
about it, because that seems to be the level of contribution the project wants 
from outsiders.

[...]

> We've always been happy to work with Debian to get things into the
> upstream.
> 
> But as our architect explains in this post
> 
>   http://lists.kolab.org/pipermail/devel/2015-January/015217.html

I read this at the time.

> the flexibility and micro-service nature of Kolab is what makes that
> process a lot harder than it is for monolithic applications, and it will
> require a champion from the Debian side who is willing to try and work
> through this with us while avoiding to enforce the Debian approach on all
> other platforms.

There has been a degree of interest in getting this done, KDE library issues 
notwithstanding, and various components do already exist in Debian, although 
it doesn't help when Kolab is (or was, at one point) depending on something 
equivalent to a development snapshot of one of the dependencies (and a pretty 
important one at that).

Actually, getting the smaller things into Debian shouldn't be that bad, 
provided that other people see the merit in them, adopt them, and eventually 
get round to doing the packaging work. But that means that they need to be 
exposed as worthwhile projects *in their own right*, not mere components in 
some larger - yes, monolithic - vision.

> Solving this complexity well is not a small task, and I am sorry that it
> has ended up frustrating you to the extent you feel compelled to vent that
> frustration on this list in a different context.
> 
> Personally I would be extremely happy if we found a good way to work with
> Debian to get things into the upstream by providing input and context as
> well as the bigger picture we're seeing.
> 
> But while we firmly agree the best place for Kolab packages would be in
> Debian proper, it seems that most Debian users and developers are happy
> enough to use 3rd party repositories and do not consider the benefit of
> upstream packages sufficiently large to put in the effort.

In my opinion, if your Debian users and developers don't appreciate the 
benefit of "proper" packages, you're getting the users and developers you 
deserve.

You know, I actually start to feel a little bad about "venting", but suddenly 
I remember having the realisation that I would eventually end up writing off 
all of my investment in Kolab. And then I feel like I should have been more 
openly critical a long time ago, if only to bring about the change in attitude 
that would convert aspirations about working with Debian into executable 
actions.

When getting software into Debian means actually using the systems that Debian 
requires to manage, build and deliver that software, someone has to set off on 
the path to make that happen. At the same time, other people have to accept 
that the workflow will no longer involve bizarre tools that conveniently push 
out questionable-quality installables for various systems. Otherwise, it's all 
rather like aspiring to go to the Moon by strapping on some wings and 
flapping.

> > This is the response I expected, really, and it more or less paraphrases
> > what I wrote before.
> 
> I don't think it does.
> 
> What I was writing was specifically about where and why and according to
> which criteria Kolab Systems would spend its own resources, which is
> largely based on maximizing the common good for Free Software as best as
> we can.

I am not telling Kolab Systems how or where to direct its efforts. It says a 
great deal, in my mind, that any treatment of the issue of project governance 
or organisation is almost always handled in such a way that the person 
bringing it up is portrayed as somehow holding Kolab Systems to ransom. Then 
again, I accept that governance is a hard problem and that the big transitions 
from corporate to community governance tend to come after corporate failure 
(with a few cases coming to mind).

> That third parties do not get to dictate the priorities for resource
> spending at Kolab Systems or what its architect considers the technically
> best and most sustainable approach to solving a particular problem does
> not mean Kolab Systems gets to determine what others are working on.

Sure. But I rather got the impression that without any real dialogue, 
significant improvements (or fixes) would not get adopted, including (as I 
already noted) in things that do not matter at all to the delivery of 
solutions by Kolab Systems. At that point, each party can of course go off and 
do their own thing, and the external party will end up patching out larger and 
larger portions of code that they would rather not see again but which remain 
in the product because changing it would be "bad for business".

> In fact we cannot dictate anyone else's priorities, nor do we make any
> attempt to do so. But if people want to do things differently, they should
> step up and be willing to do the work. For which Kolab Systems even
> provides infrastructure, tooling, process, and encouragement.

Yes, well I did that for a while. The tooling involved OBS, which is a non-
starter for Debian "proper" (to put it charitably), the process involved no 
dialogue and occasional tracker-sweeping for minor patches to fix obvious 
bugs, and the encouragement involved "patches welcome". One figures out at 
some point that one is merely playing on someone else's lawn.

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. That the Kolab Wiki is principally a receptacle for spam speaks 
volumes:

https://wiki.kolab.org/Special:RecentChanges

I believe I offered my support - yes, I've actually maintained various 
flavours of wiki, so it isn't just words and no actions - but again the 
community is not to be trusted with anything so important, even if it's a 
rusting hulk gradually sinking under the weight of neglect. (And if your 
opinion is that the above doesn't matter because casual visitors do not see 
the spam, or that "its just old stuff, why bother?", then I don't feel like 
explaining why it actually does matter.)

> And yes, forking has both benefits and costs, although in my experience
> most people tend to overestimate the benefits and underestimate the costs.

I don't underestimate the costs. That's why I stopped doing anything with 
Kolab altogether.

> So if someone aims in a direction that is incompatible with the direction
> everyone else (including, but explicitly *not* limited to Kolab Systems) is
> working toward then I can understand why people would be suggesting to
> perhaps work more collaboratively and join efforts for the common good.

And why I even bothered to start this particular discussion, and why I don't 
feel too bad for "venting" after all, is that when I see things like the above 
statement, having tried to suggest fairly inconsequential improvements to the 
software, and having sought to improve it in a relatively uncontroversial 
fashion in good faith, I get the impression that people are being accused of 
not working collaboratively for the common good if they do not sign up to this 
particular vision.

Since ceasing to track Kolab, I have worked on software in the same general 
field whose objectives and abilities are modest. I am sure that should I make 
this available, it will be met with derision in certain circles because people 
will dislike various technical choices and because it doesn't uphold "the 
vision" (and because people like their zero-sum games). 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.

I support the further development of Roundcube, and maybe the point is this: 
if there were an initiative to get backing for "Kolab WebApp" and not a 
separate project, I wouldn't support it. There's a lesson in there somewhere 
that you are, of course, free to ignore. I am genuinely sorry that I have to 
put this so bluntly.

Paul