Thanks! If I read https://www.recurse.com/blog/90-zulip-supporting-oss-at-the-... correctly Dropbox has helped to open source it but will not dedicate engineers to it. In that case it is interesting that you'll have to sign a Dropbox CLA to contribute https://github.com/zulip/zulip#contributing-to-zulip. But even with that, the code is under Apache 2, it is great that Dropbox took the time to properly document everything and open source it. At GitLab we now bundle Mattermost and we're working with Rocket.chat to bundle that. I wonder what the demand for Zulip is, it looks really full featured.
Sytse, we use gitlab enterprise edition at packetzoom (Our VP eng is a major gitlab contributor). We'd love nothing more than have a proper chat system with good native clients. Slack has excellent UX and mostly decent native clients but the pricing and/or holding our chat logs hostage has always bugged me.
Please consider integrating zulip. Though even without gitlab integration, we'll still try it out anyway.
Although Zulip is far ahead of other open source solutions we are leaning towards Rocket Chat. Javascript and Meteor are the most popular language and framework so it would be easier to contribute. It is not who is ahead now but about speed of development.
Zulip is very heavy, they recommend 4GB for a production installation. This is due to the 15 workers that are not multi-threaded (GitLab has multi-threaded background workers).
We're proud that people can run GitLab on a Raspberry Pi 2. Forcing people installing the whole GitLab suite (GitLab itself and chat) to have a 8GB server is not acceptable. We're still hoping for multi-threaded unicorn foreground processes in GitLab so we can run it on 512MB.
By the way, Rocket Chat has 'native' clients on Android and IOS, although I think they use webview inside them.
Posting this in a few places since it came up N times on this thread: I opened https://github.com/zulip/zulip/issues/34 to track optimizing the server-side memory consumption. :)
