Dear all,
In the spirit of full disclosure, let me start by pointing out that I am CEO and - along with other employees, some of whom you will also know - shareholder of Kolab Systems AG (https://kolabsystems.com) and that Kolab Systems has been the driving force behind Roundcube for the past years.
Kolab Systems has also agreed to help the Roundcube Next team in its aim to refactor and build the next technology generation.
So I am not neutral.
That said, I genuinely believe it is extremely important for the Free Software community to get behind Roundcube Next and help us push it forward, as well as bring others on board with it.
The longer story is here: http://blogs.fsfe.org/greve/?p=676
TL;DR, Part I: As a community we *require* technologies that compete with Google Apps, Office 365 and the likes in features, convenience, UI/UX, yet provide full control and freedom to users.
TL;DR, Part II: Application Service Providers should get on board with that push *right now* because otherwise they will find themselves forced into becoming re-sellers for Office 365 and Google Apps -- and increasingly unable to compete with their features & networking effects.
Some already understood this, and have joined the Roundcube Next community, such as cPanel (http://blog.cpanel.com/on-to-the-next/), Tucows, and now also Fastmail (http://blog.fastmail.com/2015/06/05/fastmail-supports-roundcube-next-develop...).
But there are many more providers using Roundcube today who have not joined, nor have they contributed in the past. For them it should be obvious to join.
And then there are those that have their own home-brew interfaces (such as Fastmail) who get the unique opportunity to become part of a new, growing community that will create a technology that will make them fully competitive against the "big clouds" in 18 months from now.
Unfortunately, most of them have not realized this yet.
So unless your provider is cPanel, Tucows, Fastmail or Kolab Now, all of who are part of this already, please encourage them to step up and join the community to push for Roundcube Next.
Direct link for your convenience:
https://www.indiegogo.com/projects/roundcube-next--2/x/4658765#/story
Best regards, Georg
Hello Georg,
Just provided a little contribution, as I also see the need and importance of this project. However, I don't like the campaign platform which was choosen. Payment is exclusively in the hand of Paypal, which I try to avoid. However, it is done now.
Best Regards, Volker
On 06/06/2015 12:13 PM, Georg C. F. Greve wrote:
Dear all,
In the spirit of full disclosure, let me start by pointing out that I am CEO and - along with other employees, some of whom you will also know - shareholder of Kolab Systems AG (https://kolabsystems.com) and that Kolab Systems has been the driving force behind Roundcube for the past years.
Kolab Systems has also agreed to help the Roundcube Next team in its aim to refactor and build the next technology generation.
So I am not neutral.
That said, I genuinely believe it is extremely important for the Free Software community to get behind Roundcube Next and help us push it forward, as well as bring others on board with it.
The longer story is here: http://blogs.fsfe.org/greve/?p=676
TL;DR, Part I: As a community we *require* technologies that compete with Google Apps, Office 365 and the likes in features, convenience, UI/UX, yet provide full control and freedom to users.
TL;DR, Part II: Application Service Providers should get on board with that push *right now* because otherwise they will find themselves forced into becoming re-sellers for Office 365 and Google Apps -- and increasingly unable to compete with their features & networking effects.
Some already understood this, and have joined the Roundcube Next community, such as cPanel (http://blog.cpanel.com/on-to-the-next/), Tucows, and now also Fastmail (http://blog.fastmail.com/2015/06/05/fastmail-supports-roundcube-next-develop...).
But there are many more providers using Roundcube today who have not joined, nor have they contributed in the past. For them it should be obvious to join.
And then there are those that have their own home-brew interfaces (such as Fastmail) who get the unique opportunity to become part of a new, growing community that will create a technology that will make them fully competitive against the "big clouds" in 18 months from now.
Unfortunately, most of them have not realized this yet.
So unless your provider is cPanel, Tucows, Fastmail or Kolab Now, all of who are part of this already, please encourage them to step up and join the community to push for Roundcube Next.
Direct link for your convenience:
https://www.indiegogo.com/projects/roundcube-next--2/x/4658765#/story
Best regards, Georg
Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
Hi Volker,
On Monday 08 June 2015 10.56:42 Volker Dormeyer wrote:
Just provided a little contribution, as I also see the need and importance of this project.
Thanks a lot for that!
However, I don't like the campaign platform which was choosen. Payment is exclusively in the hand of Paypal, which I try to avoid.
I fully share your dislike of PayPal.
If anyone knows better crowd funding platforms that should have been chosen instead (and that allow participation of non-US companies) I'd be happy for the pointer.
Best regards, Georg
However, I don't like the campaign platform which was choosen. Payment is exclusively in the hand of Paypal, which I try to avoid.
I fully share your dislike of PayPal.
If anyone knows better crowd funding platforms that should have been chosen instead (and that allow participation of non-US companies) I'd be happy for the pointer.
Hi, in case it helps:
I read this article in Linux Format a couple of years ago:
http://www.techradar.com/us/news/internet/the-power-of-crowdfunding-how-to-m...
Last page give several options. Some months later linuxvoice was born from indie gogo.
FSF started doing for GNU media goblin and now have some sort of system in place.
In libreplanet Aaron and others are working on https://snowdrift.coop/ which might be better for long term goals.
Now the problem might be that there are famous ones that have broader reach, smaller ones focused on some communities such as the platforms that are free software themselves. First pages of the techradar article shows some points.
Go Kolab and round cube!
Hello,
* Georg C. F. Greve greve@fsfeurope.org [2015-06-09T09:09+0200]:
If anyone knows better crowd funding platforms that should have been chosen instead (and that allow participation of non-US companies) I'd be happy for the pointer.
Notwithstanding other possible showstoppers, visionbakery.com offers SEPA bank transfer for european donors. Visionbakery is a Leipzig based crowdfunding company. :)
Best regards, Georg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Just FYI: I contacted the German hoster "uberspace" (think they have a mostly "nerdy" userbase) which i use for webhosting and informed them. Good Luck and thanks for your work!
DK
On Thursday 11 June 2015 20.04:20 wrote:
Just FYI: I contacted the German hoster "uberspace" (think they have a mostly "nerdy" userbase) which i use for webhosting and informed them. Good Luck and thanks for your work!
Awesome, thank you so much -- and you're very welcome!
Best regards, Georg
On Saturday 6. June 2015 12.13.46 Georg C. F. Greve wrote:
That said, I genuinely believe it is extremely important for the Free Software community to get behind Roundcube Next and help us push it forward, as well as bring others on board with it.
The longer story is here: http://blogs.fsfe.org/greve/?p=676
TL;DR, Part I: As a community we *require* technologies that compete with Google Apps, Office 365 and the likes in features, convenience, UI/UX, yet provide full control and freedom to users.
Since this message was posted to the discussion list, I think we deserve a discussion about this. ;-)
First of all, I completely support the further development of Roundcube to meet the expectations of its audience, and I already think it does a good job of offering an attractive and functional Web-based e-mail client.
I also agree that the competition to Roundcube includes cloud services such as those mentioned above *in addition to* the existing proprietary solutions that tend to be deployed in organisations. I have personal experience with the arguments that are raised around the procurement of such solutions, and I have seen largely baseless claims made about Roundcube in order to legitimise competing products, so it is only right that Roundcube see off such underhand practices not only with advocacy but also with robust functionality.
TL;DR, Part II: Application Service Providers should get on board with that push *right now* because otherwise they will find themselves forced into becoming re-sellers for Office 365 and Google Apps -- and increasingly unable to compete with their features & networking effects.
There are pressures from several directions on end-users, organisations and on providers. It is true that providers will experience pressure to resell such proprietary services that are hostile to interoperability and heterogeneity (although some will gladly embrace the opportunity out of laziness and lack of vision, like large sections of the Norwegian IT industry, for example), and it is important to provide options for those who do not wish to abandon their independence. But we shouldn't forget the other groups.
It is also the case that end-user organisations experience pressure to move to, say, Office 365 through legacy purchasing decisions, dubious bundling and bulk-purchasing agreements, coercion by partner organisations (where those partners may advocate everybody joining the cloud service in question to make things "easier"), and the following of fad and fashion by people in key decision-making positions. Some of the processes that occur here can be quite corrupt in themselves, even without any vendor involvement.
End-users experience the most frustrating form of pressure: the done deal. People in organisations are frequently left out of a decision-making process that leads to them being pushed into using solutions they do not like or that are not in their best interests. Consequently, one reads numerous accounts of dissatisfaction with a given organisation's chosen solution that somebody decided was best for everybody.
In your blog article, you wrote the following...
"Open Source has managed to catch up to the large providers in most functions, bypassing them in some, being slightly behind in others. Kolab has been essential in providing this alternative especially where cloud based services are concerned. Its web application is on par with Office 365 and Google Apps in usability, attractiveness and most functions. Its web application is the only fully Open Source alternative that offers scalability to millions of users and allows sharing of all data types in ways that are superior to what the proprietary competition has to offer."
Naturally, we have to accept the veracity of your claims around Kolab here, although I am sure that there are other organisations producing Free Software that might offer their own perspectives on some of the above. But what I think is worth discussing further is the means of adoption of these solutions.
You also wrote the following...
"Fully Free Software, that solution should be the generic collaboration application that could become in parts or as a whole the basis for solutions such as mailpile, which focus on local machine installations using extensive cryptography, intermediate solutions such as Mail-in-a-Box, all the way to generic cloud services by providers such as cPanel or Tucows. It should integrate all forms of on-line collaboration, make use of all the advances in usability for encryption, and be able to grow as technology advances further."
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. Meanwhile, it is interesting that you do not appear to mention OwnCloud, perhaps because you do not regard it as a competitor or as a possible solution for some enterprises, but here I can only speculate.
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. Of course, there will be some businesses who want to offer a solution and who will adopt that solution on a completely fresh basis. Others will happily migrate from something else and take on the necessary infrastructure upgrade. But there are organisations who do not want to purge their infrastructure of existing, working solutions, change key components or introduce a completely different operating system distribution.
Here, I get the feeling that some groupware vendors may consider that the luxury afforded to Microsoft extends to them, too, but in general it does not and will not: such is the temptation of homogeneity and its supposed convenience, the likelihood of proprietary infrastructure already being present to satisfy the demands of petulant decision-makers and special interests, and the phenomenon where it is impossible to introduce a Free Software office application that closely resembles the proprietary office software people are already using without hearing all about "training costs", while at the same time an unintuitive upgrade to that proprietary office software merits widely-offered training at great expense. The incumbent almost always enjoys benefits that others do not.
What I want to know is how organisations can build on their existing Free Software infrastructure within your vision, how organisations can augment their infrastructure through mechanisms that deliver the existing infrastructure, and whether it is possible to adopt technologies on a piece- by-piece basis instead of having to consume lots of things that have to be switched off or "configured out".
I have a confession to make here: I have some experience on the matter of getting Kolab into people's hands via the mechanisms they already use, as well as some experience with the notion that they might not want to use every last component of the solution, and in the end I decided that my time was better spent doing other things. Is Kolab available in Debian yet? I think it highly likely that one of your competitors (for which a degree of disdain seems to exist within the Kolab ranks) will get their own solution packaged and delivered via Debian long before Kolab is, if the latter ever happens at all.
And perhaps that brings me to a point that is pertinent both at the level of the initiative described in your messages and at other levels...
Some already understood this, and have joined the Roundcube Next community, such as cPanel (http://blog.cpanel.com/on-to-the-next/), Tucows, and now also Fastmail (http://blog.fastmail.com/2015/06/05/fastmail-supports-roundcube-next-deve lopment/).
[...]
So unless your provider is cPanel, Tucows, Fastmail or Kolab Now, all of who are part of this already, please encourage them to step up and join the community to push for Roundcube Next.
If what you want is people's money, you probably don't need any advice or opinions from me about getting it. But on notions of community, where a community is more than a collection of individuals and organisations that have pledged donations in a funding campaign, I see cause for concern.
I do not follow Mailpile enough to be able to say whether it has a development community, but one can see that the heroic efforts of the instigators are probably not being multiplied by a significant amount by community involvement (although this may have changed in recent months). Money, if substantial enough, can pay salaries and get things done, but it isn't a substitute for a viable community. My previous observations of the Roundcube community is that it is more visible and enjoys more outside participation than other Kolab- related efforts, but it would be of great concern if genuine community- building efforts did not occur while the opportunity exists for them to have a decent result.
A viable community could also mitigate any concerns about "classic" Roundcube. As I noted above, there are people who will happily make bad things up about Roundcube and Free Software in order to make the easy procurement decision that their bosses want to happen in favour of proprietary software. I have no idea what the roadmap is like for Roundcube as a whole, but there is plenty of experience available within Free Software communities that should inform the strategy and help avoid the mistakes of the past (especially given that some people in your employ have been heavily involved with KDE, for example).
You also wrote this...
"Just as Kolab Systems will keep driving the commercial ecosystem around the solution, allowing application service providers (ASP), institutions and users to run their own services with full professional support. And all parts of Kolab will remain Free and Open, as well as committed to the upstream, according to best Free Software principles."
I have no idea about the "commercial ecosystem" and how successful it is. Again, I will have to take your word for how well it is going, and hope that Free Software is holding its own. But the "best principles" part is worth a closer look.
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". While I can understand people wanting to take full responsibility for what they deliver to their paying customers, I had to deal with two simultaneous messages: "don't fork Kolab", and "patches are welcome"! Ultimately, I felt that the resulting effect was equivalent to being trolled.
When one cannot even improve a component that was supposedly thrown over the wall as a gift to the community to get them going, being something that is not even used to serve paying customers, one realises that there is no real basis for dialogue. And without dialogue, a true community cannot exist. Now, such functionality will inevitably migrate into separate projects, and if, in such cases, Kolab cannot be an upstream for people's work, the challenge then is to cultivate a proper community that embraces such separate projects. My personal conclusion is that groupware is indeed best done as separate projects, anyway, not as a collection of highly-interdependent entities. But my impression was that outsiders were merely being allowed to play with toys on someone else's lawn (and yet be told to keep off the grass, perversely enough).
Kolab existed in two previous major versions before the current one. I think a lot of people assumed that there had been continuity and that it was thriving, when I now suspect that this was not the case for some time, and those investigating it for potential deployment presumably came to an unfortunate conclusion that possibly taints the current offering even now. Did somebody declare groupware "done" and "won" for Free Software? There is also plenty of experience in Free Software communities of showcase projects and complacency that drives people to look elsewhere.
I don't believe in "too long, didn't read", even though I often write too much and could always edit my writing down to something more concise, but what I really want to know is whether there is an appetite to encourage a thriving environment providing choice and convenient adoption in Free Software groupware for end-users, developers and implementers, or whether we are just going to be picking winners again and end up in the same situation in ten years' time.
Thank you for your considerable attention!
Paul
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:
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.
And yes, I did not explicitly mention all users of Roundcube.
Mostly because there are too many, and any kind of list would of course be incomplete. That is not to exclude anyone specifically. In fact we've been talking to ownCloud as well as Mailpile, and the expectation is that we'll all be staying in close touch throughout the Roundcube Next effort.
And of course we appreciate their public support, e.g.
https://twitter.com/MailpileTeam/status/600597877128310784
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.
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.
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.
http://opensource.com/life/15/3/user-experience-open-source-future
might provide an interesting reading in that regard.
For Roundcube Next we actually have some extremely capable UI/UX and design resources on board to create something that is not just powerful, versatile and technically solid, but also beautiful and offers a great user experience.
What I want to know is how organisations can build on their existing Free Software infrastructure within your vision, [...]
Making sure that is possible is indeed one of the overarching design parameters for the Roundcube Next effort -- and a reason why we want to get others involved.
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.
If what you want is people's money, you probably don't need any advice or opinions from me about getting it. But on notions of community, where a community is more than a collection of individuals and organisations that have pledged donations in a funding campaign, I see cause for concern.
Of course a community is more than people who pledged money.
Community arises from contribution, involvement, participation. In the professional world, time and money are close relatives. So it is one form of contribution -- but not necessarily the most important one. And if people want to contribute time, that is also very welcome.
Just because you have money does not mean you'll have community. But it means you already have buy-in and personal investment into your goal, which is not a bad starting point for further community building to begin.
Which is exactly what Aaron Seigo and Thomas Brüderli will be working on.
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.
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.
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.
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!
All the best,
Georg
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
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
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
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.
And once you also need to take existing system orchestration solutions into account which may already be in use the task at hand is ultimately tantamount to reinventing generic system orchestration. That seemed badly advised.
So instead we made a conscious choice to provide a "simple standalone default installation" to get things working out of the box for those who "just wanted to get it running for up to a couple hundred users", and otherwise give people the components in a way that they can use the orchestration they are already using and/or are familiar with.
Anything else brings you back full circle to either re-inventing the wheel, or limiting the option space for the components in play. That complexity is a direct result of the flexibility and versatility, which in turn are mandated by the need to offer more than just a niche solution.
The "simple standalone default installation" is a way to hide that complexity from the "normal" user. But once you open that box, and start to modify part of it, the complexities come into play.
And yes, we understand this can be overwhelming.
The mythical man month applies to all of this. Which is why orchestration and configuration management systems look the way they do. They don't pretend to guess to know all that you want to do. They just give you the tools to apply your knowledge to the specific situation in a sustainable way.
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.
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.
But that isn't really how we think Free Software should work.
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.
Most of the documentation has moved to docs.kolab.org some time ago for a variety of reasons, including that it can be generated from git, with all the advantages for branching, editing & merging on a consistent set of information in distributed fashion.
That said we would love to re-launch wiki.kolab.org and suggested that since it was filled largely with information for deprecated major versions of Kolab that it would just be set to read-only and we start from scratch in a new setup.
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.
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.
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.
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.
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.
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.
All the best, Georg
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
On Wed, 2015-06-17 at 18:27 +0200, Paul Boddie wrote:
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.
Hi Paul, I have not really followed this discussion and I am not related to Kolab in any way except for the fact I have known Georg (not for business related stuff) for a long time and I vaguely know what Kolab is.
However I do have a lot of experience in integrating disparate components into a cohesive project (FreeIPA) and I can tell you why it is difficult to support the flexibility you mention.
In FreeIPA too we settled on a specific directory technology (which totally coincidentally happens to be 389ds), and a specific Kerberos implementation and DNS implementation and so on. In theory we can support multiple implementations, but in practice we can't, and the reason is that the glue that makes all this components work together such that they actually work and provide a usable experience to users is more nuanced than you may think, and goes beyond the mere "standard" protocols.
It is already hard enough for a dedicated team to stay on top of the ever changing (and improving) underlying components that have been chosen. Adding the ability to glue together completely different implementations (with different bugs and quirks, different configuration methods and options, and different features-sets) is a whole 'nother level.
As sad as it may be, products that "integrate" existing components into a cohesive solution must choose a target and develop against it, and take the best they can from the components they choose.
It is possible that in time the underlying components evolve in such a way that the chosen one is not the most ideal anymore. In those cases it is possible to swap for another, but again it usually means rewriting the glue to deal with this new component and ditch the old one.
This is the life of the 'integrator', flexibility is, somewhat, sacrificed in the name of usability, maintainability, deploy-ability and stability, all features most users value a great deal, whether they come from the community or as paying customers.
My 2c, Simo.
On Wednesday 17. June 2015 19.27.45 Simo wrote:
On Wed, 2015-06-17 at 18:27 +0200, Paul Boddie wrote:
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.
[...]
In FreeIPA too we settled on a specific directory technology (which totally coincidentally happens to be 389ds), and a specific Kerberos implementation and DNS implementation and so on. In theory we can support multiple implementations, but in practice we can't, and the reason is that the glue that makes all this components work together such that they actually work and provide a usable experience to users is more nuanced than you may think, and goes beyond the mere "standard" protocols.
It can be difficult, certainly. First of all, you have to understand what the solution is actually doing, and here it helps to have it documented. Then, you need to understand what mechanisms it is using to do it, and whether what you want to use supports those mechanisms. I accept that there are things that Kolab components use from various solutions that other solutions may not provide, or at least do not provide in exactly the same way. (From memory, I can think of some ACL-related stuff in the directory support, and things like metadata attributes in the mailbox support.)
It is already hard enough for a dedicated team to stay on top of the ever changing (and improving) underlying components that have been chosen. Adding the ability to glue together completely different implementations (with different bugs and quirks, different configuration methods and options, and different features-sets) is a whole 'nother level.
As sad as it may be, products that "integrate" existing components into a cohesive solution must choose a target and develop against it, and take the best they can from the components they choose.
Going from a specialised solution that works to something more general may not buy the implementers anything, and there isn't always a demand for it, either. I can accept that.
It is possible that in time the underlying components evolve in such a way that the chosen one is not the most ideal anymore. In those cases it is possible to swap for another, but again it usually means rewriting the glue to deal with this new component and ditch the old one.
Well, Kolab was, at the last point at which I checked, heavily tied to Cyrus and 389-ds in that swapping them out for other things requires a degree of component rewriting, which I did actually attempt, but it involves going through a fair amount of code spread over many places within at least one server component. I mentioned monolithic before now, and it always seems to get a laugh, but I am reminded of the monolithic kernel versus microkernel debate when I see such modularity issues.
(Of course, in this age of "patch gymnastics" and the magic merge, the topic of modularity doesn't get as much attention as it used to, but that's another story.)
This is the life of the 'integrator', flexibility is, somewhat, sacrificed in the name of usability, maintainability, deploy-ability and stability, all features most users value a great deal, whether they come from the community or as paying customers.
Sure, no-one is against the virtues you mention. I was mostly taking issue with the mechanism through which such things might come from the community, because there was actually an interest in doing the tiresome work of supporting other systems and components, and doing so in a way that might actually improve the robustness of the software (which can also be a well- understood benefit of modularity). You have undoubtedly read what I have had to say about that.
Paul
P.S. Interestingly, there was someone asking a few times about Kolab working together with FreeIPA. Maybe you could give them some advice about it because they couldn't seem to get it to work last time I looked.
On Saturday 6. June 2015 12.13.46 Georg C. F. Greve wrote:
That said, I genuinely believe it is extremely important for the Free Software community to get behind Roundcube Next and help us push it forward, as well as bring others on board with it.
The longer story is here: http://blogs.fsfe.org/greve/?p=676
[...]
Direct link for your convenience:
https://www.indiegogo.com/projects/roundcube-next--2/x/4658765#/story
May I ask if anyone knows what happened with this? I was looking for recent information, of which there is very little, and found this article:
http://www.phoronix.com/scan.php?page=news_item&px=RoundCube-Next-Silent...
Has the project any chance of continuing to completion with the funds that were raised, or will it be up to the Free Software community to "push it forward" by doing the work that was going to be covered by the campaign?
I am sorry if my questions are inappropriate in any way.
Paul
On 06/06/15 12:13, Georg C. F. Greve wrote:
Direct link for your convenience:
https://www.indiegogo.com/projects/roundcube-next--2/x/4658765#/story
I
notice XMPP chat and WebRTC are mentioned in the list of 10 features: can you confirm if the WebRTC calling feature (#4) will use XMPP and interoperate with standalone XMPP clients like the standard Jitsi desktop client?
Or will your XMPP support use SIP or something non-standard behind the scenes?
Which other projects will you use behind the scenes (for example, will you use Prosody as the XMPP server) and how much work will be upstreamed to those projects?
Will smaller organizations be able to install Roundcube Next as a standard Debian package (or suite of packages) on their own server?
Regards,
Daniel