Zulip – Open-source, threading-based Slack alternative
zulipchat.com
zulipchat.com
- 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.
I wonder what would have happened if they used the tech to build a chat application instead of an email-killer.
(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.
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.
How does Zulip handle file uploads and images?
Do feel free to give it a test drive on https://chat.zulip.org on the stream `#test here` to get a feel for it. :D
Good question. Uploading an image from slack iOS app takes forever and most of the time don't succeed.
It's not a network issue since other apps manage just fine.
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.
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.
Works well, although some people are put off by the similarity to Twitter #sigh
When a user is forced to add a tag for a message, you're more likely not to get anything tagged and therefore decrease the utility of search.
So you're going to start auto-assigning a tag, maybe based on their last message, which brings you back to channels / topics / chatrooms.
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)). :)
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.
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
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.
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.
Also, there's a native desktop client on the way for Rocket.Chat, called Ruqola. Qt based, so all the platforms.
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.
There are also native language-specific wrappers for that API, for example in python[1], which lets you write a bot in 5 lines:
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)
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).
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.
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.
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.
> 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.
Regarding electron/react native - no worse than Slack, I guess (as far as resource usage, etc goes).
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.
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.
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.
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.
[1] https://get.slack.help/hc/en-us/articles/202288908-Format-yo...
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?
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.
GP: Could you post some information on the issues with containers?
[1] https://zulip.readthedocs.io/en/stable/production/install.ht...
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.
And if you don't want to host the data with someone else, you can self-host.
Yet it seems engineering at Slack hasn't improved much over the last couple of years.
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.
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.
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.
Have a nice weekend!
So far main complain was not being able to create a gif custom emoji :)
topics can't be deleted
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).