Hi Rob, On Tuesday 22 January 2013 02.01:59 Rob Sheldon wrote: > 1. I'm wary of relying on Really Huge Packages Of Stuff.
That's understandable and in fact I think you'll find we agree. It is why Kolab has deliberately been designed as a set of components that can see individual upgrade & replacement with rolling releases. ;) > 3. I'm working on building services in VPS environments. There are > pretty clear advantages to that, but a major downside is severe resource > constraints. At this time I can't figure out how many users I could > support on Kolab with just 1G RAM. About the same number of users you could support with Roundcube. Typical bottlenecks for Kolab are the IMAP server (and disk I/O for that) and the actual client usage, so the number of people connected to the web frontend or the ActiveSync connector if you are offering that. > 4. And finally, I really dig the RoundCube project, I'd hate to see it > gradually become a subset of a larger project, and I think there are > other people who will have reasons for not wanting to switch to > something like Kolab (or Horde). Understood, and agreed. But I think may have a somewhat skewed picture of Kolab if you think it bears similarity to Horde. And just because Kolab is also working intensively with Cyrus IMAP, for instance, that does not mean Cyrus is becoming a sub-project of Kolab any more than Apache has been a sub-project of Roundcube. In the end it's a network of communities that work together, and we've been extremely careful to leave all the design decisions to the Roundcube community, and help where we can to move things forward. Much like anyone else who contributes to Roundcube, although you are of course right that we've contributed a lot over the past years and I understand that can also be cause for concern. I'm just not sure what else we could be doing to dispell those concerns, to be honest. Contributing less seems a bad option in which everyone loses. In the end it boils down to trust. The people who are involved in Kolab have long careers in Free Software, and are known to be good citizens in our community. Building these reputations took us years and we can only offer our own credibility and encourage people to work with us to find out for themselves. > For those people, and me, and my customers, I think a slick calendar plugin > for RoundCube would be a huge bonus, and if I can do one little thing for > the RoundCube project by getting the calendar plugin up and working and > fully production tested against a MySQL backend, along with a howto or other > documentation afterwards, I'd like to do that. Calendaring is a complex beast. More complex than people realize, typically. It only gets really useful once you have the whole sharing & ACLs figured out, the whole invitation handling over email and of course the nightmares that are posed by time zones and platforms that do not respect some of the standards. Some of that is present in the Roundcube Calendaring modules, but other functionality comes from the underlying Kolab libraries. You are of course welcome to write new libraries that do the same thing. Chances are the end result would be a lot of work, and support fewer users on a VPS, though. There are benefits to forking and parallel evolution, of course. But there are also benefits to collaboration. So if you wanted to work together, you'd be very welcome. Best regards, Georg -- Georg C. F. Greve Chief Executive Officer Kolab Systems AG Wondering whether Kolab is for you? Zürich, Switzerland Find out at http://kolabsys.com/try e: gr...@kolabsys.com t: +41 78 904 43 33 w: http://kolabsys.com pgp: 86574ACA Georg C. F. Greve
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
