Comment by sytse
11 years ago
So Zulip was acquired in March 2014 http://techcrunch.com/2014/03/17/dropbox-acquires-zulip-a-st...
You mention considering to turn it off. Is open sourcing it a way to keep the project going? Any idea how many people at Dropbox will be tasked with maintaining it?
Just to clarify, most users of Zulip were using the central cloud service (zulip.com). Kevin's experience is from one of the Zulip customers who had "Zulip Enterprise" (aka a Zulip server in their own data center -- which is also the basis of the "self-hosted production server" installation process you see now is based on). So "turning it off" in this case refers to their discussions about their internal deployment, not the Zulip cloud service (which is still running for existing Zulip users today).
I think my blog post covers pretty well why we open sourced Zulip: https://blogs.dropbox.com/tech/2015/09/open-sourcing-zulip-a....
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.
4 replies →
yes, please! really like to see that