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 _______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
