11 ms·

If you're a community driven project or organization using Slack, then take a look at https://zulipchat.com/ https://zulipchat.com/ for something that sucks les

If you're a community driven project or organization using Slack, then take a look at https://zulipchat.com/ https://zulipchat.com/ for something that sucks less, and is open source software. I've found it much more pleasant to use and less buggy than Slack.

RobertDeNiro 7y ago
Zulip is way better when you have people in many timezones.
sergiotapia 7y ago
It's not just about chat. It's also about the integration we have set up with many different applications. I'll check this out hopefully it integrates with stuff!
mikaelmello 7y ago
Alternatively, there's also Rocket.Chat, which is also open source, you can self host it or pay for the cloud plans (which have special rates for certain kinds of organizations, such as OSS). https://rocket.chat/ https://rocket.chat/ Disclaimer: I've done a GSoC project with them last year.
Angostura 7y ago
Thank you - hadn't come across that one.
elwell 7y ago
But... we pay managed solutions like Slack so we have 100% uptime...
- SamuelAdams 7y ago
  Actually it's only two nine's, which means Slack can be down for 52 minutes every year. > 1. We purposely made our commitment to the ‘fourth 9’, viz. 99.99% uptime guarantee in contrast to the typical SLAs which tend to offer 99.90%. We believe that extra availability makes a difference: the ‘fourth 9’ is important when your team relies on Slack every day. You need Slack at least 9,999 out of every 10,000 minutes. [1] [1]: https://get.slack.help/hc/en-us/articles/204113126-Service-Level-Agreements-SLA-#001 https://get.slack.help/hc/en-us/articles/204113126-Service-L...
  - dharmab 7y ago
    99.99 is four nines, not two. https://uptime.is/four-nines https://uptime.is/four-nines
  - surajrmal 7y ago
    I think you mean 4 nines.
  - papln 7y ago
    Assuming the failures are deterministic across workspaces (is that true?) Slack has been down for over an hour for some workspaces, since the problem started at 10:54 AM EDT. What is the A part of Stack's SLA?
- mfer 7y ago
  We don't pay for 100% uptime. We pay so that we don't have to put the time into operating a service. That way we have more of our time to focus on our business problems.
  - philwelch 7y ago
    If you're willing to tolerate these kinds of outages, you don't have to spend much time operating a service, either.
    - bsder 7y ago
      The problem is the time spent talking to the users. If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc. "Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.
      - philwelch 7y ago
        While that's generally true, chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Besides, when Slack goes down all the time, your IT guys are going to have to deal with users complaining anyway.
        bsder 7y ago
        > your IT guys are going to have to deal with users complaining anyway Except that IT can say "Complain to Slack or complain to your manager that we shouldn't use Slack. Don't complain to us." This is remarkably valuable--doubly so if your management is stupid and regards IT as a cost center instead of as something useful. > chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Is that true? Take Single-Sign On, for example. That's remarkably non-trivial for IRC. I'm skeptical it's any easier for Matrix/Slack/etc.
- goobynight 7y ago
  You pay for "close" to it, but no chat app is going to have 100% uptime at scale.
  - boomlinde 7y ago
    A frequent use case seems to be internal chat for medium size companies. I’d wager that for a majority of the user base it doesn’t need to work ”at scale”. Hopefully, outages like this will serve as a reminder.
- deleted 7y ago
  [deleted]
zaphod4prez 7y ago
I am a huge fan of zulip
streamer45 7y ago
It seems appropriate to also mention https://mattermost.com/ https://mattermost.com/ as a valid Open Source alternative to Slack.
- ourcat 7y ago
  We use this at work alongside Gitlab. Works perfectly. 'Bot' scripts can also be added to do things like tell a channel when a repo has been pushed etc. Very handy.
spooneybarger 7y ago
The Pony community moved to Zulip a few months back and we've been very happy with the switch. It's far from perfect, but almost everyone who uses it regularly agrees that it's been a marked improvement as a communication medium compared to IRC or Slack.
amelius 7y ago
If you start using it using the Cloud solution, can you then later easily migrate to the On-Premise version?
- rocky1138 7y ago
  Friendly note: on-premises.
- price 7y ago
  Yep, definitely. Here's details: https://zulipchat.com/help/export-your-organization https://zulipchat.com/help/export-your-organization (I work on Zulip.)
rvz 7y ago
> then take a look at https://zulipchat.com/ https://zulipchat.com/ for something that sucks less, and is open source software. I really want to like Zulip Chat. It has everything all the alternatives have + self-hosting, but as soon as they switched to their Electron client, it has become yet another resource hog that I have to put up with. I already have to put up with 10+ electron apps slowing down my Macbook. I shouldn't have to make space for another to do the same.
- flanbiscuit 7y ago
  10+ electron apps seems excessive, what other Electron apps are you running? I think Slack is the only one I'm running (that I know of)
  - komali2 7y ago
    I would guess from my experience with my colleagues that they're running at a minimum vscode and some kind of electron git app.
  - octocode 7y ago
    I run VSCode, Slack, Discord, GitHub, and my company's own app. There are others out there that I would use but my memory pressure is already too high.
    - asark 7y ago
      Plenty of popular project management / task-tracking tools are very memory heavy too, and also so slow to load that one's reluctant to close their tab(s). Plus if I close them I sometimes have trouble finding WTF I need again. Jira, Asana, both major offenders. Can easily eat many hundreds of MB of memory. It's entirely fucking absurd for what they do and the content they deal with. Harsh (and harsher) language justified.
      - mr__y 7y ago
        While don't have any info or even anectada about the other, JIRA is even more bloated on the server side - we had JIRA hosted on premises and it was used mainly for tasks and tickets in a team of 5 people. This "metric" (team size) limits the amount of tasks/tickets that would be processed. Anyway, the JIRA itself needed 2 cores and 8 GB of ram just for that. This is really even beyond absurd.
nixgeek 7y ago
Wish we wouldn’t use such language, “sucks less” is highly subjective and your opinion but we don’t need to disparage Slack in order to make a point that alternatives like Zulip are available. Seems like especially poor tone on an outage thread... “Don’t kick them while they’re down” or something?
- dharmab 7y ago
  "suck less" is a specific software development philosophy https://suckless.org/philosophy/ https://suckless.org/philosophy/
  - monsieurbanana 7y ago
    It's also not what op meant.
  - dropmann 7y ago
    If the original commenter would have meant that, he probably would have recommended using https://tools.suckless.org/sic/ https://tools.suckless.org/sic/ and not some web application which is categorized as "stuff that sucks" See: https://suckless.org/sucks/web/ https://suckless.org/sucks/web/
- allana 7y ago
  2GB of RAM use for 6 open tabs in Slack is pretty awful, their desktop client has set the bar to compete with Slack on performance very low. This abusive resource usage has created a dislike of Slack among a subset of its users.
  - timdorr 7y ago
    They actually just fixed that in 4.0: https://slackhq.com/introducing-a-more-efficient-slack-desktop-experience https://slackhq.com/introducing-a-more-efficient-slack-deskt... I'm currently sitting at 400MB total usage (including helpers) for 4 workspaces.
    - 7y ago
itp 7y ago
I've spoken before about how much I like Zulip. I don't know if it's any more stable or available than Slack, but I do like that the fundamental concepts exposed by Zulip actually encourage focused, productive conversation (something that always feels like a losing battle in Slack).
cvburgess 7y ago
Has anyone tried Twist ( https://twist.com/ https://twist.com/ )? It looks a lot like Zulip but with a nicer UI. I think it is crazy that Slack has not invested more in first-class threaded, context-aware conversations.
- NickBusey 7y ago
  Tried it. While the interface looks 'nicer' at first glance, it fits far less content on the screen. It also had more of an email-y vibe while Zulip has more a chat-y vibe, which I personally prefer. Beyond that, Zulip is open source and self-hostable, while Twist is not. Side note, we have a chat about self-hosting set up on Zulip at https://homelabos.zulipchat.com/ https://homelabos.zulipchat.com/ with 85 members and growing. It's been great for new users to be able to come in and catch up on old discussions in a way that isn't possible with non-threaded platforms.
  - cvburgess 7y ago
    That's great to know! I look forward to trying Zulip at some point, it seems to get a lot of love in this thread.
gnulinux 7y ago
My company uses Zulip and I'm very happy with it.
qaute 7y ago
Some other open Slack alternatives I know about include: Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementations, gateways to everything, and just out of beta. Zulip[2] (as mentioned), Rocket.Chat[3], Mattermost[4]---Slack clones. open source, developement open to pull requests to various degrees, can pay to have hosted in cloud or get support. Non-free or qualitatively different solutions include Discord, MS Teams, and the original IRC, I guess. Apologies for any inaccuracies or omissions; I'm not an expert in the space. [1] https://matrix.org/ https://matrix.org/ [2] https://zulipchat.com/ https://zulipchat.com/ [3] https://rocket.chat/ https://rocket.chat/ [4] https://mattermost.com/ https://mattermost.com/
- graphememes 7y ago
  None of these will: - "replace email" - "increase productivity" - "centralize communication" None of them. Not a damn one. I've worked at over 20 startups, there has never been a single case where any of these claims are true. They purchase one of these damn chat clients, and it becomes the biggest timesink the entire organization has every. single. time. But, you know what? You can't get rid of it. Everyone has it. Nobody wants to change off of it. So what do they do? Introduce other methods of communication through other apps. So no. It doesn't reduce it. If anything it increases the noise. Also, you think you make the right choice in the beginning. It seems great, your 7-50 people organization works fine. Wait until it's over 300 people, 1000 people. It becomes an absolute nightmare. Slack is probably the worst for 1000 people organizations. It was horrible at 150, then at 300 you start seeing people fight each other over rooms.
  - wtetzner 7y ago
    Honestly, chat at an organization only seems to replace phone calls, and only partially. Which is not a bad thing, but I'm not sure it's even a good idea to try to replace email.
- buboard 7y ago
  Question about the requirements of those alternatives (and slack i suppose). Zulip for example says if you have > 100 users you need a machine with 4GB RAM and 2 CPUs. Why does a chat app need a lot of processing power? I guess most of the messages are simple text, and IRC could handle thousands of users ages ago. What is the processing used for ?
buboard 7y ago
Thanks! Is it easy to integrate with existing user base?
- price 7y ago
  Not sure if this answers the question you have in mind, but it's easy to migrate your data (users, channels, their membership, message history, etc.) from Slack to Zulip: https://zulipchat.com/help/import-from-slack https://zulipchat.com/help/import-from-slack (I work on Zulip.)

RobertDeNiro 7y ago

Zulip is way better when you have people in many timezones.

sergiotapia 7y ago

It's not just about chat. It's also about the integration we have set up with many different applications. I'll check this out hopefully it integrates with stuff!

mikaelmello 7y ago

Alternatively, there's also Rocket.Chat, which is also open source, you can self host it or pay for the cloud plans (which have special rates for certain kinds of organizations, such as OSS). https://rocket.chat/ https://rocket.chat/ Disclaimer: I've done a GSoC project with them last year.

Angostura 7y ago

Thank you - hadn't come across that one.

elwell 7y ago

But... we pay managed solutions like Slack so we have 100% uptime...

SamuelAdams 7y ago
Actually it's only two nine's, which means Slack can be down for 52 minutes every year. > 1. We purposely made our commitment to the ‘fourth 9’, viz. 99.99% uptime guarantee in contrast to the typical SLAs which tend to offer 99.90%. We believe that extra availability makes a difference: the ‘fourth 9’ is important when your team relies on Slack every day. You need Slack at least 9,999 out of every 10,000 minutes. [1] [1]: https://get.slack.help/hc/en-us/articles/204113126-Service-Level-Agreements-SLA-#001 https://get.slack.help/hc/en-us/articles/204113126-Service-L...
- dharmab 7y ago
  99.99 is four nines, not two. https://uptime.is/four-nines https://uptime.is/four-nines
- surajrmal 7y ago
  I think you mean 4 nines.
- papln 7y ago
  Assuming the failures are deterministic across workspaces (is that true?) Slack has been down for over an hour for some workspaces, since the problem started at 10:54 AM EDT. What is the A part of Stack's SLA?
mfer 7y ago
We don't pay for 100% uptime. We pay so that we don't have to put the time into operating a service. That way we have more of our time to focus on our business problems.
- philwelch 7y ago
  If you're willing to tolerate these kinds of outages, you don't have to spend much time operating a service, either.
  - bsder 7y ago
    The problem is the time spent talking to the users. If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc. "Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.
    - philwelch 7y ago
      While that's generally true, chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Besides, when Slack goes down all the time, your IT guys are going to have to deal with users complaining anyway.
      - bsder 7y ago
        > your IT guys are going to have to deal with users complaining anyway Except that IT can say "Complain to Slack or complain to your manager that we shouldn't use Slack. Don't complain to us." This is remarkably valuable--doubly so if your management is stupid and regards IT as a cost center instead of as something useful. > chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Is that true? Take Single-Sign On, for example. That's remarkably non-trivial for IRC. I'm skeptical it's any easier for Matrix/Slack/etc.
goobynight 7y ago
You pay for "close" to it, but no chat app is going to have 100% uptime at scale.
- boomlinde 7y ago
  A frequent use case seems to be internal chat for medium size companies. I’d wager that for a majority of the user base it doesn’t need to work ”at scale”. Hopefully, outages like this will serve as a reminder.
deleted 7y ago
[deleted]

zaphod4prez 7y ago

I am a huge fan of zulip

streamer45 7y ago

It seems appropriate to also mention https://mattermost.com/ https://mattermost.com/ as a valid Open Source alternative to Slack.

ourcat 7y ago
We use this at work alongside Gitlab. Works perfectly. 'Bot' scripts can also be added to do things like tell a channel when a repo has been pushed etc. Very handy.

spooneybarger 7y ago

The Pony community moved to Zulip a few months back and we've been very happy with the switch. It's far from perfect, but almost everyone who uses it regularly agrees that it's been a marked improvement as a communication medium compared to IRC or Slack.

amelius 7y ago

If you start using it using the Cloud solution, can you then later easily migrate to the On-Premise version?

rocky1138 7y ago
Friendly note: on-premises.
price 7y ago
Yep, definitely. Here's details: https://zulipchat.com/help/export-your-organization https://zulipchat.com/help/export-your-organization (I work on Zulip.)

rvz 7y ago

> then take a look at https://zulipchat.com/ https://zulipchat.com/ for something that sucks less, and is open source software. I really want to like Zulip Chat. It has everything all the alternatives have + self-hosting, but as soon as they switched to their Electron client, it has become yet another resource hog that I have to put up with. I already have to put up with 10+ electron apps slowing down my Macbook. I shouldn't have to make space for another to do the same.

flanbiscuit 7y ago
10+ electron apps seems excessive, what other Electron apps are you running? I think Slack is the only one I'm running (that I know of)
- komali2 7y ago
  I would guess from my experience with my colleagues that they're running at a minimum vscode and some kind of electron git app.
- octocode 7y ago
  I run VSCode, Slack, Discord, GitHub, and my company's own app. There are others out there that I would use but my memory pressure is already too high.
  - asark 7y ago
    Plenty of popular project management / task-tracking tools are very memory heavy too, and also so slow to load that one's reluctant to close their tab(s). Plus if I close them I sometimes have trouble finding WTF I need again. Jira, Asana, both major offenders. Can easily eat many hundreds of MB of memory. It's entirely fucking absurd for what they do and the content they deal with. Harsh (and harsher) language justified.
    - mr__y 7y ago
      While don't have any info or even anectada about the other, JIRA is even more bloated on the server side - we had JIRA hosted on premises and it was used mainly for tasks and tickets in a team of 5 people. This "metric" (team size) limits the amount of tasks/tickets that would be processed. Anyway, the JIRA itself needed 2 cores and 8 GB of ram just for that. This is really even beyond absurd.

nixgeek 7y ago

Wish we wouldn’t use such language, “sucks less” is highly subjective and your opinion but we don’t need to disparage Slack in order to make a point that alternatives like Zulip are available. Seems like especially poor tone on an outage thread... “Don’t kick them while they’re down” or something?

dharmab 7y ago
"suck less" is a specific software development philosophy https://suckless.org/philosophy/ https://suckless.org/philosophy/
- monsieurbanana 7y ago
  It's also not what op meant.
- dropmann 7y ago
  If the original commenter would have meant that, he probably would have recommended using https://tools.suckless.org/sic/ https://tools.suckless.org/sic/ and not some web application which is categorized as "stuff that sucks" See: https://suckless.org/sucks/web/ https://suckless.org/sucks/web/
allana 7y ago
2GB of RAM use for 6 open tabs in Slack is pretty awful, their desktop client has set the bar to compete with Slack on performance very low. This abusive resource usage has created a dislike of Slack among a subset of its users.
- timdorr 7y ago
  They actually just fixed that in 4.0: https://slackhq.com/introducing-a-more-efficient-slack-desktop-experience https://slackhq.com/introducing-a-more-efficient-slack-deskt... I'm currently sitting at 400MB total usage (including helpers) for 4 workspaces.
  - 7y ago

itp 7y ago

I've spoken before about how much I like Zulip. I don't know if it's any more stable or available than Slack, but I do like that the fundamental concepts exposed by Zulip actually encourage focused, productive conversation (something that always feels like a losing battle in Slack).

cvburgess 7y ago

Has anyone tried Twist ( https://twist.com/ https://twist.com/ )? It looks a lot like Zulip but with a nicer UI. I think it is crazy that Slack has not invested more in first-class threaded, context-aware conversations.

NickBusey 7y ago
Tried it. While the interface looks 'nicer' at first glance, it fits far less content on the screen. It also had more of an email-y vibe while Zulip has more a chat-y vibe, which I personally prefer. Beyond that, Zulip is open source and self-hostable, while Twist is not. Side note, we have a chat about self-hosting set up on Zulip at https://homelabos.zulipchat.com/ https://homelabos.zulipchat.com/ with 85 members and growing. It's been great for new users to be able to come in and catch up on old discussions in a way that isn't possible with non-threaded platforms.
- cvburgess 7y ago
  That's great to know! I look forward to trying Zulip at some point, it seems to get a lot of love in this thread.

gnulinux 7y ago

My company uses Zulip and I'm very happy with it.

qaute 7y ago

Some other open Slack alternatives I know about include: Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementations, gateways to everything, and just out of beta. Zulip[2] (as mentioned), Rocket.Chat[3], Mattermost[4]---Slack clones. open source, developement open to pull requests to various degrees, can pay to have hosted in cloud or get support. Non-free or qualitatively different solutions include Discord, MS Teams, and the original IRC, I guess. Apologies for any inaccuracies or omissions; I'm not an expert in the space. [1] https://matrix.org/ https://matrix.org/ [2] https://zulipchat.com/ https://zulipchat.com/ [3] https://rocket.chat/ https://rocket.chat/ [4] https://mattermost.com/ https://mattermost.com/

graphememes 7y ago
None of these will: - "replace email" - "increase productivity" - "centralize communication" None of them. Not a damn one. I've worked at over 20 startups, there has never been a single case where any of these claims are true. They purchase one of these damn chat clients, and it becomes the biggest timesink the entire organization has every. single. time. But, you know what? You can't get rid of it. Everyone has it. Nobody wants to change off of it. So what do they do? Introduce other methods of communication through other apps. So no. It doesn't reduce it. If anything it increases the noise. Also, you think you make the right choice in the beginning. It seems great, your 7-50 people organization works fine. Wait until it's over 300 people, 1000 people. It becomes an absolute nightmare. Slack is probably the worst for 1000 people organizations. It was horrible at 150, then at 300 you start seeing people fight each other over rooms.
- wtetzner 7y ago
  Honestly, chat at an organization only seems to replace phone calls, and only partially. Which is not a bad thing, but I'm not sure it's even a good idea to try to replace email.
buboard 7y ago
Question about the requirements of those alternatives (and slack i suppose). Zulip for example says if you have > 100 users you need a machine with 4GB RAM and 2 CPUs. Why does a chat app need a lot of processing power? I guess most of the messages are simple text, and IRC could handle thousands of users ages ago. What is the processing used for ?

buboard 7y ago

Thanks! Is it easy to integrate with existing user base?

price 7y ago
Not sure if this answers the question you have in mind, but it's easy to migrate your data (users, channels, their membership, message history, etc.) from Slack to Zulip: https://zulipchat.com/help/import-from-slack https://zulipchat.com/help/import-from-slack (I work on Zulip.)