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 :).
- 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 has 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.
- 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.
- 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.
- Zulip has full markdown support. You can format links, images, and tables (which are all especially nice when using bots) using standard markdown syntax.
- 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!).
- Zulip has support for latex equations in messages.
- 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 (https://github.com/zulip/zulip).
- 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.
My research group (at MIT) also uses Zulip for messaging.
While I agree with everything jremmons said (hi john), it's important to note that their mobile apps are so bad that they're basically unusable - there's a particularly aggravating bug in the iOS app where if you don't open the app for a while, it forces you to load and scroll through days of messages to read the most recent ones.
> every message you send has to be sent in a topic. ... 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.
After some short period of playing with Zulip with a colleague of mine I found this feature to be confusing, at least for new users: it is way too easy to disregard the concept of topics and start writing to the random topic that happens to be selected in user's client atm, and in the end the conversation mess keeps being a (slightly rearranged) mess.
This is where the topic editing feature comes into play; any user can change the topic of a message sent recently, and if someone posts something in a wrong topic, it can be moved to a different topic.
Also, after a while this paradigm grows on you and by forcing you to think of a relevant title for your conversation, it forces you to have more cohesive conversations in my view.
And, lastly, it is possible to send messages without any topic (it defaults to (no topic)). :)
I’ve been wondering about this. Instead of topics, why not use hashtags? I know in Slack the hashtags indicate the channel, but they don’t need to. So instead of having set topics, you could just add a tag to messages to indicate the topic.
When a user is forced to make a decision on something like ‘topic’ just to send a quick message, you’re more likely to get randomly assigned, meaningless topics. Random hashtags, on the other hand, are no big deal. Because you have to actively search for the ones you want.
This has been the paradigm since Web 2.0 and it seems to have worked pretty well.
Random topics are no big deal in Zulip either. You can either a) edit the name of the topic at any time if needed or b) create a new topic as topics are cheap
I'll also add that one of my favorite features is the vim-like keyboard shortcuts. It makes navigation very quick, and I love being able to easily quote an entire message by just hitting `>`. The full markdown and keyboard shortcuts are fantanstic to have.
I loved google wave -- it was great and ahead of its time. I think it was a major mistake that google let it go and that the apache wave foundation never got it going. it is too late now but really a greatly missed opportunity.
(2) It tried to be an all-in-one comm platform, and because of that it excelled in none of what it tried to do.
(3) Poor UI performance was the death sentence of it. If you can't use it fluently, it's not good for real-time. Poor UI design did not help, on top of that.
It was an interesting experiment, but not all experiments end up with a successful product. I hope the ideas will be unearthed at some moment and reused with a greater effect.
Real-time email is a contradiction in terms, as (at least for me) being asynchronous is one of the main defining features of email. Essentially any chat app, from IRC to Slack, can be called "real-time" email. To me, the phrase "real-time email" sounds like calling a submarine an "underwater car".
IMs hit the sweet spot between fully real-time (like the phone) and fully async (like paper mail).
The UI is built for efficient real-time communication, but the underlying data model (the log, notifications, statuses, etc) allows for very easy async communication.
I think someone could make a great product by just adding IM-like UI features on top of an existing email backend. Email is pretty fast these days to work as mostly-instant communication.
I agree! Check out https://delta.chat. I use it every day for emailing. Subject lines are the ellipsized first words of your body and every message is a new email.
slack threads suck I might look into Zulip though, this seems interesting. Having subchatrooms compiled into one giant chatroom is also how I organize my gmail as well. So you have the option to look at individual rooms or just one room to see the same content
I wish it had color text input support. At my last job, they were looking to replace IRC with RocketChat, and that was a big let down. I even submitted a PR for "Colored Markup" (https://github.com/RocketChat/Rocket.Chat/pull/8639/commits)
The use case at the last job, was that I had an IRC bot that had a lot of stuff to deal with support stuff, like DNS configuration for the Hosted Exchange offerings (2010 and 2013 were offered), and it would do colored text for good and bad configurations. Just made it easier to point out the issues.
Well, IRC clients allow for more customization for the end users, RocketChat - there was very little. The dev team didn't want to add hacks on to it and would only update when RC would release a new version.
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.
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).
The “killer features” for me were:
- 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.
- Relatedly, he ability to mute topics I don’t care about but see everything else within the stream.
- An intelligent global view that makes following multiple conversations at once easy
Our company wants to migrate from Skype for Business to either Zulip, Mattermost or Hipchat. As todays news hit, we removed Hipchat from out list.
Our questions are:
1. Does the Zulip desktop app for Linux store messages for offline reading?
2. Do you use it on-prem or cloud based? (if on-prem did you by the enterprise support?
3. Do you have any video or screen sharing software in use with Zulip? We are looking into the recommended on-prem Jitsi. Also is doesn't offer much group/channel management beyond moderators and guests.
Based on the evaluation we did at my last job, I'd remove Mattermost from the shortlist and replace it with Rocket.Chat. Open Core sucks and functionality is about the same between the two.
Also, there's a native desktop client on the way for Rocket.Chat, called Ruqola. Qt based, so all the platforms.
1. No experience with the Linux client but I see another reply answering your question.
2. We have used cloud-based from the beginning and never had issues. Zulip's uptime is fantastic. There may have been one or two minor issues during the five year time period that we've used them.
3. We tried out the Jitsi integration when it was first introduced and it works fine but I don't think anyone at our company uses it since we have Google Apps for Business so everyone just uses Hangouts if we need video / voice.
1. No,the Zulip desktop app as of now doesn't store messages for offline reading.
2. Both on-prem and cloud based options available.
3. Zulip uses Jitsi integrations by default.
I’m an iOS user so can’t speak specifically to Android. The mobile app experience isn’t as strong as the desktop browser experience but works reasonably well.
I will say that the mobile app experience has been improving very rapidly so it’s going in the right direction. For a while the poor mobile experience was Zulip’s biggest drawback but they’ve made huge strides.
It's unusable on Android. Messages arrive days late at time and other mission critical issues. I have contacted the Zulip team about it and they acknowledged Android app still needs work, web is most stable.
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.
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.
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).
We are getting enormous value from using zulip topics between just 2 people.
Myself and my cofounder use Zulip effectively as 'WhatsApp with topics'. We can chat to each other on a variety of things, and they're easily retrievable, searchable and persistent.
For example, one of our topics is 'interesting articles' where we send HN Links etc. that the other might be interested in. They can be separated from other conversation but it's easy to go back and scroll through them when you've got some time to kill.
Finally, people rediscover the UI of Usenet (https://en.wikipedia.org/wiki/Usenet) and improve on it, getting rid of bare text and adding ways to attend specific users with @JohnDoe.
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.
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.
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.
I've heard this difficulty a few times so it must be valid, but I find it really surprising. It's such a close analogy to email subject lines that I would have thought that most people could get their heads round it quite quickly.
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.
> Zulip has modern apps for every major platform, powered by Electron and React Native.
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.
I've recently reconnected with some friends, by way of a slack channel. The channel is exclusively meant for idle chat, and even there, if I ignore it for a day, I come back to 200+ unread messages, including actually mildly important stuff that I missed lost in the noise (friend being in an accident). I can totally see how Zulip's approach can fix this...
Regarding electron/react native - no worse than Slack, I guess (as far as resource usage, etc goes).
An alternative to Zulip is Twist - https://twistapp.com. (I'm not affiliated with them at all; just a fan.)
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.
We've used Mattermost for a small amount of time and then migrated to Zulip (company of about 50 people). Zulip's threading model is what sets it apart. It might take sometime to get used to but once you do you don't want to use anything else. Mattermost is primarily a Slack clone while Zulip is its own category. I think Slack style chat works best if everyone is working on the same thing; like a 5 man startup. However with more people working on all kinds of different things Zulip's model works better.
> 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?"
There are a lot of hybrid products though that either integrate chat into email, or make products that feel like email but are really chat. Zulip looks like it has some overlap with the latter category.
Redkix, which just got bought by Facebook today and shut down, is also in that category. That's actually a more interesting story than the Slack acquisition imho.
My company has used Zulip, Slack, Mattermost and tried Ryver as well. Zulip has been by far our favorite. I listed some of my favorite features in the parent thread.
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.
We used slack in other start-ups before and it was always a leading to 'notification fatigue', 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?
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.
Zulip seems to be trying for "a better Slack", down to the (disgusting) pricing model centered around keeping your message history hostage.
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 think I should clarify some of the stuff you're saying:
1. Zulip has been in development since August 2012 (1 year before Slack was released), so is not trying to be a better Slack.
2. Anyone can host their own Zulip server, and have control for all their data.
3. For anyone wanting to migrate from the hosted instance to on premises (self-install) can easily get an export of all their data that they can directly import into their other instance.
4. This is anecdotal but so far, Zulip's full text search has worked well in finding messages from over an year ago easily.
If you don't like their service model, just run your own host. Zulip is open source, apache licensed and available on github. I haven't tried it for a couple years, but it was easy to get running in a VM last time I tried.
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.
We (the Zulip core community) recently adopted the main third-party Docker implementation for Zulip (now https://github.com/zulip/docker-zulip), and have been hard at work on cleaning it up and making its documentation high quality.
It's not at the level of polish we want it to be yet (which is why we recommend the "dedicated machine/VM" installation flow, which is super polished). But we expect the Docker setup to be quite nice in a couple months.
It may not have a fully supported docker container, but it should work just fine in an LXD container. I think their installation instructions ask a dedicated machine only because their installer installs packages at the system-level.
What kind of kernel-level stuff does it do that requires you to use a full VM? Stuff like this should be an apt-gettable package, not something for a container or even VM...
I think GPs point was that it requires a full system/machine onto which you can install it, be it VM or bare metal (which doesn't look too involved, based on the documentation[1]), but that it won't work as/in a container.
GP: Could you post some information on the issues with containers?
Well, requiring a dedicated machine is what the docs say, and it's what the installer presupposes. Sure you could make it work on box that is already hosting other sites or applications but you might need to do a lot of stuff manually.
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).
You can export your data in a nice JSON format; our exports are complete enough that you could fully migrate your organization from one Zulip server to another using them.
And if you don't want to host the data with someone else, you can self-host.
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.
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.
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.
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.
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.
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.
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.
> Last year I was looking for a tool where one team could provide chat support to customers
Although there's the superficial similarity that they both involve "chat", customer support is actually a very different problem to solve than what Zulip (and Slack and all its other alternatives we're talking about today) is focused on. It's no surprise that Zulip wouldn't have the features you need, and it's definitely not somehow an overarching indictment of the Python ecosystem.
But I did not make an "overarching indictment" based on a requirements-feature misalignment. That was just the starting point for taking a closer look.
Do your analysis of the users permissions design of that software and ask yourself how would you do that or compare to other systems and you will understand what I mean.
Also I was writing about unnecessary limitations possibly introduced by framework usage - and this was just a friday afternoon virtual water cooler talk, certainly not a scientific thesis. And certainly I do not want to go for war about it with anyone, that was just a little reminder for younger programmers to never stop asking questions about the tools they use.
You can create a GIF custom emoji in Zulip, you just needed to resize them correctly using some tool before uploading. There is an open PR that will eliminate the need to resize the GIF before uploading.
Thanks a lot! I found the PR and as I was told I opened pandora's box... now our creative department will be resizing and uploading party parrots gifs :))
Yes, they do, if all the messages are read in the topics. Then it shows a "more topics" if you want to go back further. However, it will display all the topics with unread messages in them (even if this is more than 5).
If you're ending up with a lot of unread topics you don't care about, the answer is to mute that topic (you can mute a single topic without muting the whole stream, which is awesome but a lot of people I've worked with didn't realize you could do this).
- 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 has 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.
- 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.
- 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.
- Zulip has full markdown support. You can format links, images, and tables (which are all especially nice when using bots) using standard markdown syntax.
- 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!).
- Zulip has support for latex equations in messages.
- 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 (https://github.com/zulip/zulip).
- 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.