Pros: Server maintenance is blissfully minimal. Message threading that actually works. No server issues or downtime in the past 4 years. (Every time I see a HN "Slack is down" posting, I smile to myself and continue my work day...) It runs great for ~50 employees on an AWS t3a.large instance. Importing all the company's previous messages from Slack worked perfectly.
Cons: If you have people used to Slack, there will be resistance / a learning curve. Knowing, "when do I create a topic?" takes practice. The mobile and desktop apps are not as polished as Slack's. Not as many integrations as Slack. You have to know enough to manage and secure a server yourself.
The Zulip devs accept Github donations, btw, if anyone cares to support their work. (We do; no affiliation other than we're happy to have a private, self-hosted alternative.)
edits: punctuation and adding that instance was a ".large"
Zulip has a nice spin on the way discussions work with their concept of "topics". It lends itself well to how we conceptualize the discussions across our development teams, without unnecessarily creating many ad-hoc temp channels (something we'd have done on Slack). We're liking it thus far. That being said I do need to check why it's using about 35 gigs of RAM on our server.
(edit: actually it's now down to 17 gigs)
https://zulip.readthedocs.io/en/latest/production/requiremen... is a useful reference for folks interested in memory requirements for a self-hosted Zulip server.
Note that my experience is almost exclusively with the web client. My small amount of experience with the mobile app is that it's much less polished.
The biggest selling points of Zulip, from the POV of the people who put it in place and truly loved it, were that it’s free/OS software, it has explicit threads as a first class citizen, and that it’s very configurable. All those things are true.
The day-to-day use was painful, though. It was riddled with UX problems, e.g., forgetting state between restarts, inconsistent hotkey support, multi-action use paths for common cases, frequent full reloads of its web view. I’d much rather use vanilla IRC than Zulip.
Slack is just enough of a shim layer on IRC, and with good usability. It has threads, and in use it’s not a problem that you can’t name them like Zulip. The integrations are nice to have (e.g., type `/zoom` to start a Zoom meeting) but not a big deal. The UX is clear and predictable and (mostly) stays out of my way.
I'm sorry to hear you had a bad experience with Zulip. If you can share details on the UX problems you had, perhaps in https://zulip.com/development-community/ where we can have an extended conversation, I'd be very appreciative. I personally review every issue reported in zulip, and some of the specific problems you cite are not unfamiliar and surprising to me. Specifically:
* I'm not aware of a plausible explanation for Zulip frequently doing full reloads of the web view. Zulip's core design is to live-update everything [1] and there's only a handful of code paths that can trigger a full reload (the most common being when the server version was updated, and in that code path, the client has an algorithm where it waits up to 30 minutes for a moment when your window is idle and not focused to reload to get the updated version, to minimize the chance of disruption). * I'm also not sure what what state might be forgotten between web client restarts; almost all of our client UI updates happen via the client asking the server to change something, and the client updating via the same server-client push mechanism that updates other clients (the main exception to this is sending messages, where local echo is important for UX reasons). And at least the server-initiated reloads are designed to preserve your precise scroll position, compose box state, etc., and that's been true since ~2013. (Though we did fix a couple bugs where compose box state was not properly preserved in the last year).
I know you're not using Zulip currently, so your memory may be imprecise, but any additional detail that could help us reproduce what you experienced would be awesome!
[1] https://zulip.readthedocs.io/en/latest/subsystems/events-sys...
One major quirk of the interface is that can be difficult to, at a glance, identify what topic/dm you are actively on, which has lead to a handful of "Oops, what was supposed to be a DM" message deletes.
In comparison, I hate having to use Slack every day today. It's slow as shit, whenever I type a keystroke too fast (e.g. editing a previous message) it always gets into a weird state (usually edits the message before last and messes up the edits) and it encourages rapid-fire, thoughtless replies. Search also sucks and it's impossible to find anything. I fucking hate Slack.
I'm not sure if it was just our setup, because when I checked the official Zulip web chat, I had the same problem.