Same, love Zulip but slack seems too entrenched at the moment. I'm hoping that OSS communities continue adopting it and using it instead of slack though.
I might be living in a different Europe than you but from what I see around my Slack is very pervasive and Teams is only used for video meetings because companies are already on office365.
Nothing but hate for the chat/collaboration features…
We used to be on Zoom for video meetings, then it lost favor due to fears of industrial espionage (the encryption crisis, etc.) and via Office 365, Teams snuck up. Initially as a Zoom replacement only for video meetings, too, but lately folks seem to be discovering the other functionality and it's creeping in.
Zoom's ugly as hell, but the Linux client has long been fairly reliable. Teams meanwhile is plagued by issues that don't seem to affect some other Electron-based apps or Chromium. During meetings it'll start out fine, then a minute in it'll suddenly use microphone. Opening any settings views tends to knock audio out of working state, too. Their official forums are full of threads on this, and support people suggesting crazy mitigations such as running it as root (admin user).
The most recent release seems to be from September 2021, which is positively ancient for something based on a browser engine and using it to display complex content from remote hosts.
Big companies where IT is considered a cost center and day-to-day users have no say in their tools will be using Teams, partly because they have no choice but also because for a lot of them the standard is already Windows and "Skype For Business" and they legitimately don't know how much better other tools are.
In smaller companies where day-to-day users have a say in their tools, Teams would absolutely not fly, especially when said users most likely have experience with better tools such as Slack.
If I'm being honest, Teams and Slack are both about as bad as each other. Threading in Slack in particular is so bad as to be an active productivity killer.
I don't know how long ago you used teams, but that feature has been active for a while now. Since that was your main complaint, maybe you will like it now.
that was the cherry on top / the straw that broke the camel's back.
Overall sluggishness and long loading times were probably the main problem.
Zulip seems to be the endgame team messenger for us. Once you embrace the thread-first paradigm the old-school Slack/etc. single-thread approach is just too noisy.
if you want to see something amazing watch the CPU usage when somebody posts a high-framerate animated GIF into a slack channel, it can suck down 70% CPU usage and a massive amount of battery on almost any laptop. The idea that a primarily text based chat client can consume 70% CPU on a quad-core, 10th gen core i7 is amazing.
Working in quite the prominent big tech in Europe. 7k+ slack members. We abuse slack. inter-team daily work, intra teams coordination. Squads / topic q&a's, code reviews. Tribe based knowledge transfer, feedback, and many lulz. Of course an army of bots /webhooks about metrics, usage tresholds, alarms, even customer specific channels with automated bot support.
All the platforms have wonderful apps, even the web fallback is feature complete, and a breeze to use.
The ecosystem of 3rd party integrations and apps is just incredibly big...
All of this works consistently, probably more than 99.99 of uptime, and almost never we had any service disruption.
It's extremely poor on Windows too: I've never seen an app pin all my cores and hit the power limits causing a tailspin to 400 MHz on a modern machine before.
the only reason companies use slack/teams/gmail is because those services understand the data belongs to their clients (the employer) and will provide ways to access private chats/change ownership of private documents/etc with zero trouble.
I was genuinely shocked to learn that slack admins can configure it so that certain folks can read private chats. Once that became known, most of my team offloaded to discord/keybase (at a previous gig with toxic leadership).
I use it at work, well it's a nice thing. But the only thing that is annoying, if I want to copy text by double clicking, it adds the sender to it. (E.g. If I want to copy $COMMAND, "$SENDER_NAME: $COMMAND" is copied into the clipboard)
I tried using Zulip, nobody else wanted to use it because it was so clunky.
I appreciate what they're trying to do but as someone who's been using internet based chat for 30 years (oof), I don't think its going to catch on until you can turn off the "thread only" mode.
I think the "thread-only" feature is the biggest selling point, it's niche-y by default.
Zulip is the meeting point of a hackernews/reddit-like board, real time chats and mailing lists. UX and UI needs work, but the base concept is its main feature.
I participate in two different zulip's, the microsoft rush one and the functional programming one and I always felt Zulip was the best choice for technical discussions.
Threads discourage spam and off topic, searching discussions and topics you care about is simpler. If you come from 3 decades of IRC it gets time to get used to, but it's great in everything IRC is unfit.
Thread mode is the selling point for us. I’ve been in various chats since late 90s, and threads aren’t exactly a cookie-cutter IRC thing, that other chats are doing, but it does wonder for organizing the flow of inforamtion
Thread only is the biggest reason to use it outside of FOSS, but the UI design and overall experience could use some work. It's not bad, but for apps like Zulip that are different from what people are used to, it can make a big difference.
I'm not going to lie -- I was forced to use Zulip because the Redhatters on the Quarkus team use it for their community chat.
At first I thought it was terrible, but after a while it grew on me.
The thread-first design makes it a lot easier to navigate, and you can optionally choose the "standard" chat view where all the threads + replies are lumped together in a channel's stream.
I kinda like the idea of 'resolving threads'. You could create a temporary war room for a particular issue then close it as needed. Although I doubt our company is big enough where it makes sense to segregate beyond job divisions.
I used Zulip for a while in one of my communities and quite liked it. It could use a lot more polishing (maybe the newer versions are better in that regard), but it brought a lot of innovation to the table compared to something like Mattermost, whose only goal is to be a pixel-by-pixel copy of Slack.
Zulip is fantastic. It mixes the paradigms of IRC and email while providing a clean interface that runs beautifully in a browser. The Rust language developers use it and I couldn't imagine any better way to keep up with the volume of so many discussions across so many teams.
However, the mobile app could use a whole lot of polish. I rarely use chat apps on my phone, but if I did then I wouldn't have nearly as good an impression of Zulip as I do.
This is arguably one of the biggest strengths of Matrix: there are a zillion clients for almost every imaginable platform, and lots and lots of libraries so integrations are a breeze. You don't need to violate the ToS (discord), get API keys/permission and agree to conditions (Slack), and so on, in order to do your own implementation.
Governments (including military), health care, and large enterprise have been moving to Matrix. It's enough of a threat that Slack had to get off their asses and actually "innovate" some cross-slack messaging.
Threading and more integrated A/V is what's missing, and both are supposedly in the works, but they seem to be perpetually "coming soon"...
Sure, I like federation and I think it would be nice if Zulip were federated (maybe it is, I actually don't know!). My comment is just about the user experience, though.
I really wanted to love Matrix but it just doesn't cut it yet. I hope it gets there in the coming years, rather than go the way of XMPP, but atm, I can no longer in good conscience try to convince people to give Matrix a shot, if it fails at covering the most basic use case: reliable communication.
There aren't as many clients as you think, and the majority of them are quite bad. The only client with any firepower behind it is Element, and the UX is really not great there, and there are a lot of critical bugs that have been open for years, with nobody with enough knowledge of the codebase able to go in and fix these (especially with E2E encryption). As far as I can tell, their $30 mil raise has gone into focusing on enterprise instead.
Matrix bridges are buggy and decaying because the main ones are maintained by basically one guy who's now focusing on building proprietary products around his work (fair enough).
This is irrespective of the whole federation side, which is also buggy, and until the setup/maintenance cost of running your own homeserver (pure P2P federation and homeserver-agnostic identities have been TODO for years!), it's not gonna catch on. Even today, Matrix is hardly decentralised -- compare the matrix.org homeserver with literally the sum of all other homeservers and you'll see.
WOOT !!! Zulip is amazing and this is a big release.
In particular, the source code and dev process are truly delightful, and I've painlessly made all sorts of custom mods to it, from UI to backend. Most systems of its size are "open source in name only" but not Zulip.
We use this at work and its so good at keeping things in track! We never loose any conversations. Compared to Teams this is so good. I would pick this any day over Teams/Discord where things get lost all the time.
I got introduced to Zulip through recurse center (which still uses Zulip). I prefer it over slack, mostly cause i check the recurse Zulip once in few months and the threaded conversations make it so easy to follow and skip topics.
Really wish my workplace used it instead of slack :(
Nice to see Zulip is still around! I was the Zulip evangelist at a previous company, but sadly was never able to get buy-in from senior leadership on the advantages of a real-time chat system. I contributed a couple of integrations that I'm happy to see are still active. :)
My lesson from that project was that there can only be one canonical communication system due to the network effect, and that communication will naturally gravitate to whichever system senior leadership is using.
Years later the company settled on Slack instead, driven by a new exec.
Hah, this is funny. We have, that I know of, five "canonical" communication systems that are all big enough to survive because of network effects and corporate sponsorship in different parts of the company.
The public access feature looks sweet...and I was able to use it to access demos of the upcoming redesign of the Zulip web application.
Do any alternatives offer this ability to see content without having to sign up for an account?
Slack et al are walled gardens because none of their content is publicly available...forums are the opposite, but they lack the real-time dynamic of chat.
This public access feature from Zulip seems like it might bridge the gap nicely.
Regarding threading generally: perhaps it's just me and my Usenet habits, but I find threads really helpful in keeping a chat channel relatively 'clean'.
However trying to get conversations to actually occur in them seems to be an uphill battle with other (non-techy?) people, and often things 'degenerate' into a stream-of-consciousness series of messages.
Is it just that I'm atypical in preferring them? Do 'normal' people have a hard time with (understanding) them? Other?
For better or worse, I think Slack’s approach of opt-in threading is effectively the default at this point. If users’ (technical or otherwise) mental model assumes that messages can get sent to a channel, but the software only allows messages to be sent to a thread, that disconnect could result in lots of unexpected behaviors.
For what it’s worth, I personally prefer Slack’s approach over Zulip’s - I think threading is a really important feature, but requiring it for every message creates excessive and unnecessary friction.
I think if you could type a message, and it could use some heuristic to determine a sensible thread title for you automatically, that would improve the experience quite a bit
Yeah, I think that would help a lot. I think I’d personally go a step further and make thread titles optional, I generally don’t think they add much value over just reading the first message in the thread.
Even with that change, though, I’d still rather have threading be opt-in. Not every message fits well into exactly one thread.
Personally I’ve found the ability to move messages between / split threads (topics) helps a lot with this in Zulip. We moved from Slack, and those that struggled with threading there mostly picked it up over a few weeks.
Dont know about others, but at my $Corp its the other way around. Business keeps pushing and making various channels and threads and stuff in Teams
They're basically doa. Maybe they'll see a bit of traffic when they are made and like 1 day after, but otherwise they're almost immediately abandoned.
One of our architects posted a diagram in the Files tab in a specific teams channel. 2-3 people actually looked and downloaded it. Everyone else got it when it was posted as an attachment to the group chat we were having.
Most people just gravitate to direct messages, myself included. Its not that threads/channels are hard to understand. Its simply that most people cant be arsed to use them and have no interest in following different topics/channels/threads for what they want, thats why even they do use Teams / Threads / w.e (worked with a client that did), you'll have _a lot_ of duplicate threads ... people would rather make a new one that search for whats there.
The main differentiator of Zulip IMO is the threading model. Instead of chat rooms with multiple un-separated concurrent conversations taking place, every message* must start a topic or be placed in one (topics are like the subject line in an email). You can still look at the room and see all of the topics at once, but you can also focus in on a single topic. And it remembers your read progress at a per-topic level, so it's quite feasible to catch up on chats asynchronously. Basically Zulip brings the best things about mailing lists to chat.
*: you can now turn off the topic requirement, in which case messages go into a "no topic" topic. But not using topics kind of defeats the purpose of using Zulip IMO.
Perhaps it's the "free tier" hosting (I don't have enough time or desire to figure out self-hosting) leaves a lot to be desired. Images are sometimes slow to load and the image upload from a phone is a little bit janky, especially compared to Slack.
I primarily use it for a sort of photo sharing log with my fiance, and I convinced her to do it for "open source," so perhaps I'm not the intended audience.
Dropbox bought this and then open sourced it, right?
Did they buy the company only for talent, and not the product?
Why didn't Dropbox try to actually use it to compete with Slack? Teams is terrible, but integrated. Slack is better, but isolated from good video/storage. It does seem there's room for a third option.
I'd love to work somewhere that uses Zulip over Slack, for the product itself, but particularly because I believe it has a good chance of coming with a more mindful communication approach than your average Slack shop. Anyone hiring?
90 comments
[ 4.5 ms ] story [ 167 ms ] threadFor a good example of how great Zulip can be: the rust-lang zulip instance is a shining example.
https://forge.rust-lang.org/platforms/zulip.html
... which is frustrating, because its Linux desktop app is still quite poor and buggy in the basics.
Nothing but hate for the chat/collaboration features…
Yeah, Teams is the worst of them in every dimension.
Atlassian (Confluence/JIRA) otherwise.
Sorry about Jira. :)
Zoom's ugly as hell, but the Linux client has long been fairly reliable. Teams meanwhile is plagued by issues that don't seem to affect some other Electron-based apps or Chromium. During meetings it'll start out fine, then a minute in it'll suddenly use microphone. Opening any settings views tends to knock audio out of working state, too. Their official forums are full of threads on this, and support people suggesting crazy mitigations such as running it as root (admin user).
The most recent release seems to be from September 2021, which is positively ancient for something based on a browser engine and using it to display complex content from remote hosts.
Then again Microsoft sites don't seem to work with security keys in Firefox either.
On MacOS it behaves pretty ok. Once you get used to the weird double text box.
Big companies where IT is considered a cost center and day-to-day users have no say in their tools will be using Teams, partly because they have no choice but also because for a lot of them the standard is already Windows and "Skype For Business" and they legitimately don't know how much better other tools are.
In smaller companies where day-to-day users have a say in their tools, Teams would absolutely not fly, especially when said users most likely have experience with better tools such as Slack.
Teams however… the search functionality where you can find the message but can’t jump to it so that you can see the rest of the conversation.
I actually scrolled up for some 5 minutes non-stop once trying to get to the conversation like that
A quiet (?) teams seems to behave better than the absolute crapshow of slack 'apps' at my current gig.
All that being said, I do kinda like the outlook calendar app, means I never have to go to office.com anymore ;)
All the platforms have wonderful apps, even the web fallback is feature complete, and a breeze to use. The ecosystem of 3rd party integrations and apps is just incredibly big... All of this works consistently, probably more than 99.99 of uptime, and almost never we had any service disruption.
It definitely pays for itself.
the only reason companies use slack/teams/gmail is because those services understand the data belongs to their clients (the employer) and will provide ways to access private chats/change ownership of private documents/etc with zero trouble.
I was genuinely shocked to learn that slack admins can configure it so that certain folks can read private chats. Once that became known, most of my team offloaded to discord/keybase (at a previous gig with toxic leadership).
try it again on that server?
I participate in two different zulip's, the microsoft rush one and the functional programming one and I always felt Zulip was the best choice for technical discussions.
Threads discourage spam and off topic, searching discussions and topics you care about is simpler. If you come from 3 decades of IRC it gets time to get used to, but it's great in everything IRC is unfit.
At first I thought it was terrible, but after a while it grew on me.
The thread-first design makes it a lot easier to navigate, and you can optionally choose the "standard" chat view where all the threads + replies are lumped together in a channel's stream.
Great product, thanks for all the hard work =)
day 1: why do I need another app/website/etc
day 2: ok fine, but what's with the threading?
day 3: whoa, this is pretty nice.
day 4: <feature request>
day 5: <feature request is live>
day 6: mind blown
However, the mobile app could use a whole lot of polish. I rarely use chat apps on my phone, but if I did then I wouldn't have nearly as good an impression of Zulip as I do.
Governments (including military), health care, and large enterprise have been moving to Matrix. It's enough of a threat that Slack had to get off their asses and actually "innovate" some cross-slack messaging.
Threading and more integrated A/V is what's missing, and both are supposedly in the works, but they seem to be perpetually "coming soon"...
There aren't as many clients as you think, and the majority of them are quite bad. The only client with any firepower behind it is Element, and the UX is really not great there, and there are a lot of critical bugs that have been open for years, with nobody with enough knowledge of the codebase able to go in and fix these (especially with E2E encryption). As far as I can tell, their $30 mil raise has gone into focusing on enterprise instead.
Matrix bridges are buggy and decaying because the main ones are maintained by basically one guy who's now focusing on building proprietary products around his work (fair enough).
This is irrespective of the whole federation side, which is also buggy, and until the setup/maintenance cost of running your own homeserver (pure P2P federation and homeserver-agnostic identities have been TODO for years!), it's not gonna catch on. Even today, Matrix is hardly decentralised -- compare the matrix.org homeserver with literally the sum of all other homeservers and you'll see.
In particular, the source code and dev process are truly delightful, and I've painlessly made all sorts of custom mods to it, from UI to backend. Most systems of its size are "open source in name only" but not Zulip.
Really wish my workplace used it instead of slack :(
My lesson from that project was that there can only be one canonical communication system due to the network effect, and that communication will naturally gravitate to whichever system senior leadership is using.
Years later the company settled on Slack instead, driven by a new exec.
Do any alternatives offer this ability to see content without having to sign up for an account?
Slack et al are walled gardens because none of their content is publicly available...forums are the opposite, but they lack the real-time dynamic of chat.
This public access feature from Zulip seems like it might bridge the gap nicely.
However trying to get conversations to actually occur in them seems to be an uphill battle with other (non-techy?) people, and often things 'degenerate' into a stream-of-consciousness series of messages.
Is it just that I'm atypical in preferring them? Do 'normal' people have a hard time with (understanding) them? Other?
For what it’s worth, I personally prefer Slack’s approach over Zulip’s - I think threading is a really important feature, but requiring it for every message creates excessive and unnecessary friction.
Even with that change, though, I’d still rather have threading be opt-in. Not every message fits well into exactly one thread.
They're basically doa. Maybe they'll see a bit of traffic when they are made and like 1 day after, but otherwise they're almost immediately abandoned.
One of our architects posted a diagram in the Files tab in a specific teams channel. 2-3 people actually looked and downloaded it. Everyone else got it when it was posted as an attachment to the group chat we were having.
Most people just gravitate to direct messages, myself included. Its not that threads/channels are hard to understand. Its simply that most people cant be arsed to use them and have no interest in following different topics/channels/threads for what they want, thats why even they do use Teams / Threads / w.e (worked with a client that did), you'll have _a lot_ of duplicate threads ... people would rather make a new one that search for whats there.
Is Zulip as featureful as Slack? You can do a lot with and in Slack these days.
the synapse daemon is not overly complicated to set up in a non-federated configuration.
the official matrix client is pretty good, there are also a wide choice of other matrix protocol clients people can use to connect.
*: you can now turn off the topic requirement, in which case messages go into a "no topic" topic. But not using topics kind of defeats the purpose of using Zulip IMO.
I primarily use it for a sort of photo sharing log with my fiance, and I convinced her to do it for "open source," so perhaps I'm not the intended audience.
You’re spot on.