My research group at Stanford uses Zulip for instant messaging. I like it A LOT more than Slack. I'll list a few of the features I think most contribute to why Zulip > Slack (IMHO). Also, I'm not affiliated with the maintainers of Zulip at all. I am just a big fan of their software :).<p>- Zulip has something called a "topic" which is basically a Slack thread but with a name/subject-line. Unlike Slack threads though, every message you send <i>has</i> to be sent in a topic. Zulip makes it much easy to context switch between these topics too. Ever have a situation in Slack where two people are discussing something in a channel instead of using a thread or DM? That isn't possible in Zulip.<p>- The Zulip UI offers a lots of nice features compared to Slack too. For one, you can see the number of unread messages in each topic directly from the main page. Zulip also supports multi-line messages so you don't have to send a bunch of message one right after the other to break up text, you can add line breaks directly to your message.<p>- Zulip has a "message drafts" features which is nice when you want to draft a message (or multiple messages), but will send it later. Zulip will hang onto your drafts until you need it.<p>- Zulip has full markdown support. You can format links, images, and tables (which are all especially nice when using bots) using standard markdown syntax.<p>- Zulip has full color syntax highlighting when embedding code-snippets into messages! It has support for basically every programming language I can think of (including brain-fuck!).<p>- Zulip has support for latex equations in messages.<p>- Zulip is open-source! You can use the version of Zulip hosted at zulipchat.com or you can deploy your own Zulip server by grabbing the source code from github (<a href="https://github.com/zulip/zulip" rel="nofollow">https://github.com/zulip/zulip</a>).<p>- In the time since I have switched from Slack to Zulip (about 1 years ago now), Slack has gone down 3-4 times and has had other connectivity issues; Zulip had maybe 1-2 minor interruptions that I can think of in that time.
Our team has been using Zulip since 2013, and I provided one of the testimonials on the site. I’m happy to answer any questions about our experience.<p>Our engineering team tried alternatives to Zulip (Slack, Mattermost, and others) during the period when Zulip’s future was unclear and it was receiving very little support. We preferred Zulip enough to switch back to it even though the mobile apps were basically non-functional (they’re now supported again).<p>The “killer features” for me were:<p>- Topic-based threading, which allows multiple conversations to occur simultaneously without having to creat a new stream (Zulip’s equivalent to channels) every time. This also makes it easy for me to contribute to a conversation hours (or days) later and have everyone else understand what I’m talking about.<p>- Relatedly, he ability to mute topics I don’t care about but see everything else within the stream.<p>- An intelligent global view that makes following multiple conversations at once easy
Since nobody mentioned Zulip's REST API yet, I'll do. There is one, and and it is really good.<p>There are also native language-specific wrappers for that API, for example in python[1], which lets you write a bot in 5 lines:<p><pre><code> import zulip
client = zulip.Client()
def onmsg(m):
print ("at %d, %s said: %s" %
(m['timestamp'],
m['sender_email'],
m['content']))
client.call_on_each_message(callback=onmsg)
</code></pre>
[1] <a href="https://pypi.org/project/zulip/" rel="nofollow">https://pypi.org/project/zulip/</a>
I used Zulip while at Akamai. At the time, Zulip was a Boston-based start-up and I believe some engineers at Akamai had a connection to engineers at Zulip. It wasn't used throughout the whole company, but it did have a significant user base and was growing.<p>My experience was so positive that I've continued to evangelize it at other companies since then. The acquisition by Dropbox was definitely disappointing, but the fact that they managed to open source the code and have since started providing a service is very impressive.<p>The most important feature of Zulip is threading. It doesn't make a big difference for a very small organization, but it is a huge win for larger organizations. Not only does it make it easier to organize information, it allows you to improve the signal to noise ratio by muting specific topics of conversation. I remember being both very excited for Slack's thread implementation and then soon after the release very disappointed. It feels like an after thought and doesn't improve a fundamental problem with Slack, the exponential growth of channels as new users are added. There is a little more upfront learning required to use Zulip, but it is vastly outweighed by the benefits. And don't forget that Slack has a learning curve too, especially for those that aren't as technically savvy (e.g. markdown, Slack commands, bots).
Finally, people rediscover the UI of Usenet (<a href="https://en.wikipedia.org/wiki/Usenet" rel="nofollow">https://en.wikipedia.org/wiki/Usenet</a>) and improve on it, getting rid of bare text and adding ways to attend specific users with @JohnDoe.<p>I think you could almost (Usenet doesn’t do closed groups) run this on NNTP, if you run some server that detects those @JohnDoe tags and creates messages in a “messages for John Doe” group, and write a client that handles Markdown.
Tried to convert some non-techie business types to using Zulip. Was really difficult to get them to understand streams and threading. Perhaps the project just needed more political will and buy-in, but ultimately the instance on DO ended up a ghost town. To be fair, these users don't use any of the alternatives, either.<p>I was super excited to find out that it's built using Django. It wasn't too hard to get running on VM using the install instructions.<p>edit: one downside with a self-hosted instance and the android app was that you need to send Zulip (the company/org) copies of your app secret to enable push notifications. When we were demoing, the way to do this was through an email(!) which seemed poor security, but it seems things have changed since then and there is now a Django management command to achieve this.
This looks cool. I think it could resolve some of the noise at the company I work for. For example, a lot of #javascript-specific chat happens in the #developers channel, but we have a #javascript channel. This is actually really annoying. I think people would more easily recognize they should put the message into #javascript if they could clearly see the dev -> javascript stream structure. Hopefully anyway. There's no way our company would migrate to Zulip though.<p>> Zulip has modern apps for every major platform, powered by Electron and React Native.<p>I'm not sure the underlying technologies matter to most users. This might not be good marketing, but I don't know. I know someone could have chosen to use this language with reason but figured I'd put it out there just in case.
An alternative to Zulip is Twist - <a href="https://twistapp.com" rel="nofollow">https://twistapp.com</a>. (I'm not affiliated with them at all; just a fan.)<p>They have a proper native (as in not Electron-based) Mac OS X app (probably other platforms, too, but I haven't checked), which launches almost instantly and consumes a very reasonable amount of RAM. It's definitely worth a look.
Google Wave was ahead of its time, and maybe needed a UX make-over, but still. I also think reddit taking a lot of traffic from classic "forums" was also an indication that people want proper threading.
Can anyone chip in with comparative experience between Zulip, Slack, Mattermost etc? Any subset will do.<p>I'm not too interested in a "chat vs email" sort of discussion, just "If you've decided you want chat, which products are worth looking into?"
I'm using it in a startup after some great reviews here on HN. the ability to have threaded ("topics") is absolutely superior to Slack.<p>We used slack in other start-ups before and it was always a leading to <i>'notification fatigue'</i>, as soon as the team grew to more than a few people, and even worse when non tech users were asked to all collaborate.
Does it support a full range of markdown or similar in comments?<p>Slack's asinine take on Markdown [1] is one of the things driving me away from it. Our organisation intensively uses Markdown via Gitlab and other products and being stuck with the half functional version in Slack is extremely annoying.<p>[1] <a href="https://get.slack.help/hc/en-us/articles/202288908-Format-your-messages" rel="nofollow">https://get.slack.help/hc/en-us/articles/202288908-Format-yo...</a>
Wasn't able to find link to source code on the website.<p><a href="https://github.com/zulip/zulip" rel="nofollow">https://github.com/zulip/zulip</a>
Zulip seems to be trying for "a better Slack", down to the (disgusting) pricing model centered around keeping your message history hostage.<p>I have no need for a slightly better Slack. I can see how your topics make it slightly better to find message, but how do I find topics once there are hundreds of them? How do I find unrelated issues that popped up in a thread, like they tend to do in human conversation, and that people didn't bother to make into a new topic?
I love slack, and I also love open source alternatives to services I value! It’s not likely we will move off slack any time soon...however I greatly appreciate having innovative options! Looks great, keep it up!
On the downside, if you are self-hosting, Zulip requires a dedicated server (or VM). There are some efforts to make it run in a container but nothing that works really well.
Does it also hold my chat history hostage? I can totally understand the business model behind it, but for me it's also really the most valuable component. I want full monopoly over my chat history (meaning also the the chat app developer doesn't get to see it).
If Slack could solve their persistent issues, I wouldn't necessarily spend effort to move to Zulip.<p>Yet it seems engineering at Slack hasn't improved much over the last couple of years.
Last year I was looking for a tool where one team could provide chat support to customers - of course the customers should have their own space, in tulip this would be organizations. Zulip comes with some good UI ideas for a chat system, the multi-organization experience was not so great.<p>Unfortunately it was not possible to have users take part in several organizations - so each support team member would need to have one account in each organization - that gets messy really quick.<p>I do not think that this is a very edgy use case, but it is an indicator of some underlying design limitation. Having users limited to 'org' does not seem to make sense - instead it is obvious that one wants to have users and groups and some sane way to fine-tune rw permissions and visibility between groups and objects that groups create.<p>I was wondering if such an obvious limitation in the basic design was somehow induced by the use of Django. A programmer with some DB design experience would have spotted that quirk in a very early stage. I understand that Django traps new users into these kind of constructs with its obscure db layer - this is the microsoft principle - 'hiding complexity' in the end leads to hiding knowledge and makes people produce problematic results.<p>It is a good example of how the use of a framework can destroy a good software idea. Hopefully some people with good db knowledge can fork the frontend and build a better backend for Zulip - obviously Elixir would be a good fit with its soft-realtime channels for this kind of communication software.<p>Zulip is still good enough for more simplistic use cases, but you could use any php chat system out there without the incredible installation and maintenance overhead that python brings in - absurd over-complication seems to be another symptom of the framework disease, people just do not seem to know that they are in the 'absurd zone' because they have never seen how it can be done in a much easier way.<p>The tools you use make up your view of the world, so you can not understand what people with other tools are even talking about as long as you do not try them. A good lesson for every developer to stay open-minded and not let productivity pressure eat your learning and research time.
I love Zulip, the UI looks (to our biz team at least) less modern, but its productivity features outweigh this.<p>So far main complain was not being able to create a gif custom emoji :)