Please help us spread the word on Roundcube Next

[Paul Boddie]

On Tuesday 16. June 2015 14.08.06 Georg C. F. Greve wrote:
> Dear Paul,
> 
> Thank you for your thoughtful response. I'm not quite sure I can muster the
> same level of depth, but allow me some quick points:

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.

> On Monday 15 June 2015 22.28:44 Paul Boddie wrote:
> > Now, it is interesting that you mention things like Mail-in-a-Box as an
> > intermediate solution. Presumably, the "intermediate" label refers to the
> > targeted nature of that solution in that it does not seek to provide
> > support for every kind of communication.
> 
> Mail-in-a-box is specifically aimed at self-hosting.
> 
> That is something that technical people can do, and it makes their life
> easier. So I think it is a very useful project. But I would be surprised if
> it managed to get traction outside the geek world. A vast majority of
> people have neither the technical skill nor the inclination to do this
> sufficiently well.
> 
> These people still ought to be able to enjoy the benefits of 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. I haven't really looked at Mail-in-a-Box, but I did 
notice that similar all-in-one platforms are offered by partners of your 
business. Maybe I don't get what "intermediate" is supposed to mean, if any 
one thing.

[...]

> > However, where I see a problem is the way that people always decide that
> > the solution to a given problem is *one* single thing that does it all.
> 
> This is actually about one thing that does one specific thing well.
> 
> Ultimately it's an optimization problem. Ideally there will be fewer than 7
> billion individual solutions to any given problem. But it is usually
> healthy to have more than one.
> 
> Having at least one solution that does the job well, has a sane
> architecture and sufficient flexibility to serve those 7 billion users
> would be a good start.

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?

> The second solution then becomes a luxury problem.
> 
> But in the way many Free Software advocates preach fragmentation over
> cooperation, we too often end up with 10 solutions of which none is
> sufficiently complete to compete with the proprietary applications.

Who is preaching fragmentation, exactly? Sure, there are lots of calendaring 
servers, for example; you can argue that they are all insufficient (although I 
haven't really checked); you can argue that people are going off and writing 
their own instead of making the existing offerings robust and well-featured. 
But I doubt that there are many people actually advocating doing so.

> Breaking out of that cycle is what Roundcube Next is about.
> 
> Also, you are right adoption is not always driven by parameters that seem
> to be largely focused on freedom, technical perfection or even cost.
> 
> Which is why UI/UX is an essential part of making sure adoption happens.

True. Free Software projects should not make things more difficult for 
themselves than they already are. This also applies to various other aspects 
of their design and structure, hence my remarks on the way that Free Software 
companies cannot enjoy the same "red carpet treatment" that is handed out 
unfairly to incumbent proprietary software vendors.

> http://opensource.com/life/15/3/user-experience-open-source-future
> 
> might provide an interesting reading in that regard.

I particularly liked this part:

"In the enterprise software world user experiences at Google, Salesforce, 
Dropbox, and Atlassian are edging out entrenched legacy experiences."

Obviously I am familiar with Google's offerings and regard them as largely 
overrated, and as far as Atlassian is concerned, although I have seen people 
adopt their also-rather-overrated offerings, I have also seen people highly 
dissatisfied with them to the point that I felt it totally worth my time 
helping one project migrate from Confluence to a Free Software solution: a 
migration project that was originally driven by idealism but was completely 
validated by the improved user experience.

Now, I am obviously not the average person who is supposedly impressed by 
Gmail, 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.)

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.)

[...]

> > Is Kolab available in Debian yet?
> 
> Yup. It has been for some time:
> 
> http://kolab.org/blog/tobru/2013/10/25/kolab-3-debian-wheezy
> 
> We're also offering professional support on Debian for those who want it.

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.

Professional support for Debian would actually involve Debian itself, in my 
opinion. That would involve working with other organisations, though.

[...]

> > I will admit that my own efforts to contribute to Kolab were not always
> > optimal or well-formulated, but my impression was that if something did
> > not serve the direct interests of Kolab Systems, it was considered a
> > liability and not to be encouraged or entertained in Kolab "proper".
> 
> Kolab Systems is a full Free Software company, we release it all and do
> almost everything out in the open. We are also encouraging contributions
> from various parties, and are happy to work with them.

Not in my experience, but maybe I'm just too difficult to work with, or 
something. Even so, to go from enthusiasm through disengagement to the point 
that I now raise my concerns in this forum should be enough of a worry to make 
people think that it might not all be about me.

Note that I didn't delete all my blog posts about Kolab when I decided not to 
bother trying to contribute any more, and I did make it clear that people 
should be looking to others to investigate the areas that I did. People are 
free to make up their own minds about whether my work was absurd or not, and 
they should be free to observe the community involvement lifecycle I 
experienced and decide whether their own time is worth spending on Kolab or on 
other things.

> But indeed our own primary interest is in making Kolab a viable solution
> for everyone. Which means we won't prioritize contributions which break
> Kolab for large groups of users, or lead into dead-ends in certain
> installations.
> 
> We'll be happy to share with people insight on what such contributions
> would need to take into account to not cause problems for these kinds of
> users that not all contributors are aware of. And there are several
> contributors who are not working for Kolab Systems who do that kind of
> mentoring these days.
> 
> But some people prefer not to seek that input, or ignore it, which is their
> prerogative. We still enable them by providing infrastructure to run their
> experiments and make their own experiences.
> 
> I'm not convinced it would be an improvement of our practice if people went
> far beyond that and spent substantial time on supporting efforts that we
> know will cause disruption for many users - at the expense of not having
> that time available to work on improvements that will benefit all users.

This is the response I expected, really, and it more or less paraphrases what 
I wrote before. What it actually means is that if one wants to change Kolab  
in an unapproved fashion, Kolab Systems are obliged to let you do so under the 
licensing (which is good), but it will need to be done outside the planned 
Kolab community, it will end up inadvertently soliciting "don't fork Kolab!" 
sentiments, it will fail to take advantage of the collaborative potential that 
would otherwise be present, and it will fail to efficiently share any of the 
widely-acceptable benefits generated by the fork.

As far as Kolab - not Roundcube (read to the end!) - is concerned, the 
question for everyone is how invested they want to become in maintaining a 
fork of Kolab if they want to become a full contributor. Because those are 
really the terms on which people may become involved. Of course one may 
justify this situation in terms of the business, but that does not mean that 
such considerations should carry any real weight with the average potential 
external contributor, especially since you're not paying them to care about 
the business.

> But indeed if you want Kolab Systems to spend paid time on something it
> helps to show how this will benefit our users or the community in general
> since we never seem to suffer from a shortage of things we could be
> working on.

So I interpret this as meaning that you would rather have financial 
contributions than technical contributions. If not literally, then in effect, 
following from what I wrote above.

> And one of these points where such large gains for large numbers of people
> is possible is Roundcube Next -- which is why we are grateful for any help
> you and others may be able to provide!

Well, I was pleased to see various improvements in Roundcube in an area that 
was not of particular interest to myself but one which I decided to take an 
interest in, partly to demolish disinformation from a dishonest (if not 
technically corrupt) purchasing process that was seeking (sadly successfully) 
to advocate for the procurement of Microsoft products. My perception is that 
my technical contributions, had I explored the area in question and made more 
progress on patches, would have been accepted.

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. With regard to Roundcube 
Next, I wish the project every success.

Paul