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