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. > Sure, but technical people ultimately are the ones deploying services for > other people, whether as application service providers, within > organisations, or as advanced end-users. Of course. But they can only deploy software that exists. > What if an organisation has a Free Software mail infrastructure that just > happens to be something that isn't the solution decided upon by Kolab? Is > the "one solution that does the job well" monolithic and dictate every > detail or does it take advantage of existing solutions, interoperability, > and so on? 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. We take particular care in making the minimum number of assumptions, and to never limit the option value of each individual component such that Kolab can be seamlessly integrated into virtually any environment. So as far as collaboration solutions are concerned, Kolab is the antithesis of a monolith, really. That flexibility and the goal to provide clean, generic, robust solutions to the individual aspects at hand are also what makes Kolab complex. 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." > but it is interesting that a Free Software competitor of yours is > also aiming to deliver a desktop-level experience via the Web with their > product. (My mention of Debian packages applies to that company, so you may > know exactly who I mean.) There is a lot of companies in this space. Most of them are open in name only. But if it is who I think you are referring to I noticed its users have asked to please replace the web interface by the Kolab interface, or rather, Roundcube. And yes. They, too, would be welcome to participate in Roundcube Next. We're repeatedly working even with direct competitors for the good of the larger Free Software ecosystem. A good example for this is Syncroton. > But anyway, I don't need convincing that a good user experience is > beneficial and persuasive in getting people to use Free Software. (What I > often disagree with is what people regard as a good user experience, but > that's usually me taking issue with people who think the answer is "the > Mac" and who have a narrow and limited historical perspective on user > interfaces.) Good user interfaces are not as much a matter of opinion or taste as many technical people believe. And especially Apple adoption has been driven by design and user experience against a dominant monopoly that people were familiar with. That is no small feat. You are right, though, that trying to imitate Apple won't get you to do the same to them. Free Software will need to find its own visual language and user story. > Here, I meant Debian "proper", not mix-and-match Debian. When I mentioned > the mechanisms by which people maintain their infrastructure, the > distribution channels are principally those mechanisms. Moreover, by > getting into Debian "proper", a higher level of quality assurance typically > applies (cheap shots about high-profile mistakes in Debian > notwithstanding), which has always been a problem with Kolab in my > experience. 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 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. 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. > 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. 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. 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. And yes, forking has both benefits and costs, although in my experience most people tend to overestimate the benefits and underestimate the costs. 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. > But as I noted before, I regard Roundcube differently from the other Kolab > projects, perhaps because it has its own origins and needs to maintain an > indisputable independence from the Kolab product. Thank you for seeing and saying that. Provided that Kolab Systems contributed >95% of the code within Roundcube for the past years that should say a lot about how we operate. The same is true for other projects where we contribute, such as Cyrus IMAP, KDE and so on. It's always the same people, living by the same principles. And that is indeed what I would call best practice. Otherwise I think we would also find it hard to routinely work with direct competitors, or have Fastmail join the Roundcube Next effort despite their service easily being seen as a direct competitor to Kolab Now. That said, we think it is great that Fastmail is rapidly contributing more and more to Free Software through Cyrus IMAP, JMAP and now also Roundcube Next, and we're happy to work with them in that process for the benefit of all of society. We invite everyone else to do the same, proprietary or not, competitor or not. > With regard to Roundcube Next, I wish the project every success. Thank you very much -- this means a lot to me. Any help you can provide in spreading that word would be most appreciated, because I really do not want to surrender this domain to the large proprietary clouds or play catch up for the next decade. Roundcube Next is the idea to get ahead of the curve, and provide that technology which can solve this problem well, for service providers and integrated solutions across the board. For that to work, we need as many people and groups to join that effort. Best regards, Georg -- Georg C. F. Greve <[email protected]> Member of the General Assembly http://fsfe.org/about/greve/ http://blogs.fsfe.org/greve/ http://identi.ca/greve
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
