Please help us spread the word on Roundcube Next

[Georg C. F. Greve]

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 <greve at fsfeurope.org>
Member of the General Assembly
http://fsfe.org/about/greve/
http://blogs.fsfe.org/greve/
http://identi.ca/greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20150616/186d2180/attachment.sig>