Slack: the chat tool we love to hate?

Every week or so we have a discussion somewhere on Slack in which a member complains about some aspect of the service (this week was the lack of message retention; last week was rendering; the week before was message retention, …). This usually turns into a bunch of people suggesting alternatives and getting shot down because of perceived technical deficits in whatever platform is being suggested.

I promised in one of the previous gripefests that I’d put this up here: the thing that bugs me about these conversations (besides their frequency and their predictability) is that we never actually get to listing the features we as a community want in a real-time chat system. All we get is “X doesn’t do Y, therefore we won’t consider it” – but the default is using a system that doesn’t do Y, or Z, or A, …

So here’s the thread I promised to start last week. It is to hash out a prioritzed list of desired technical features for a real-time chat system, not to propose alternatives to Slack. Without knowing what’s important, we can’t explore options that meet the majority of the users’ needs.

So, have at it. Again, requirements only, please. No solutions at this point.

So far (I will add or create new polls as people suggest other features, so scroll down to make sure you’re seeing all the options):

  • web-based client
  • os-specific client
  • mobile client
  • free
  • Markdown support
  • LaTeX (or derivative) support
  • OAuth support
  • 2 factor auth support
  • long (unlimited) message history
  • file upload capability
  • giphy integration
  • open source
  • ability to access through most reasonable corporate firewalls

0 voters


Since we can’t edit polls after 5 minutes, as we come up with new features, please create a poll in the comment:

[poll type=multiple]
- option one
- option two
- option three

Note that since polls require a minimum of two options, if you don’t have two things to propose, just create a(n obvious) dummy option.

1 Like
  • Bot support (reasonably easy to hook in bots, github, gitlab, wiki, imgur, etc.).
  • Null Option DON’T CLICK. (Seriously, don’t do it.)

0 voters

  • per-channel notification settings
  • arbitrary channels
  • threading
  • Julia code highlighting
  • moderation controls
  • private channels
  • private DMs
  • “team”/“org”-level message search
  • resizable text

0 voters

  • ability to edit/delete messages after posting
  • inability to edit/delete messages after posting (opposite of above)
  • effective finite lifetime of messages (ephemeral)
  • achieve old messages
  • custom emoji
  • ability to read scroll back of messages posted before you joined channel

0 voters

I guess we should leave the polls open for another week or so, and then close it down and analyze results…

1 Like
  • Ability to self-host
  • Hosting available
  • Full data export

0 voters

  • emoji reactions to messages
  • dark mode
  • single sign in to multiple forums

0 voters

For each of these last 2 small polls they have a small problem that they are short enough that someone may not care about any of those 3 features but they can’t express that because you can’t submit a vote with none of the options selected. So basically the results could be off as people who count none of those 3 things as important are being excluded from the tabulation of the results.


If we tally all the polls as if they were one, the absolute numbers will be correct (well, with some error due to different exposure), even if the relative bar fills in each poll individually gives the impression of more support. If anything, some options may appear less supported than they’d otherwise be given perfect visibility, rather than more, as it seems to be your concern.

There is a disadvantage of exposure for later polls, but that can’t be avoided unless we re-poll. I’m not sure it’s worth doing that, but if we do then my feeling is that we should have folks do a forced 1:N ranking for the top N options, ignoring any results below some very low threshold.

(What I had been planning on doing was getting the absolute number of votes for each option by multiplying the percentage by the number of voters, and then ranking the options by those products. That way we’re not biasing polls with larger numbers of respondents, and “I don’t like any of these options” responses still count.)

1 Like

I plan on closing the polls this week, so please get your votes in if you haven’t already (and tell your friends!).


As promised, polls are closing. Results soon.


Results here:

I’d suggest including a column for, which works over the Matrix protocol.

Also, there’s a sizeable list of features in this comparison of Matrix-compatible clients. It could be interesting to include at least some of them in the table, for completeness (even though they shouldn’t be counted for the final score since the community didn’t vote for them).

Finally, I’d suggest changing the sharing definitions of the spreadsheet to allow any viewer to comment, without having to request edit access. That way people can provide helpful info in-place in a convenient and still fairly safe way.

1 Like

Good idea. Done.


I do really like and matrix chat. I’ve been using it for about a year now and it’s even gotten significantly better over that time.

That said, I’m sure either of gitter or zulip would be fine. I have to say I find the UI of gitter to be… offputting. Admittedly I have no good justification for that whatsoever, maybe I just have to get used to it. I’m wondering if other people feel the same way? If it’s not, I probably just need to get used to it.

It’s funny though, if there ever was proof that slack is terrible it’s this spreadsheet. It’s clearly the worst option there (I might argue that IRC is a slightly different use case).

I really hope everyone will get on board with whatever the decision is and that this will be a successful migration.

Couple of random thoughts:

I don’t think the spreadsheet really proves “good” or “terrible” (or anything in between*). It simply measures, as objectively as possible, each platform’s ability to meet the most popular technical requirements as determined by this completely unscientific survey. The comparison isn’t done yet. Red means “it doesn’t meet”, green means “it seems to meet”, and white means “neither @iamed2 nor @sbromberger has evaluated that criterion yet”. If you’d like to help evaluate, send me a private message. We could use 1-2 more folks who are committed to objective evaluations.

Whatever gets decided, a group of people will be unhappy. I do not think there is any way around it. (The goal is to minimize the unhappiness, or at least maximize the number of people who will tolerate whatever’s eventually decided.)

That said – and this is not directed at anyone in particular – I’m really hoping that this thread (right here) doesn’t start into a “X is better than Y” discussion. Whether or not The Community changes platforms is beyond the scope of this little poll.

Finally, I don’t have any idea how we come to any decision as to what to use. This seems to be a stewardship issue, but… what? Is there a formal process for proposing a change? Do we risk fragmenting the community? That would be a bad outcome.

*Edited to add: the only thing this poll proves is that at least 13 of you either can’t read or are smart-alecks.


This is almost certainly true. I would be unhappy is we switch, only because I’m in slack for several other things (including work) and have been for several years. I’m used to it. Then again, I probably send too much time in slack, so I’ll be unhappy if it doesn’t change.

Since many people will be displeased no matter what, having something objective is the only good criterion. I will point out that one response that’s missing in the survey is “I don’t care about features, I just don’t want to change.”

The survey wasn’t about “what should we do”, and deciding whether to switch is a different decision with different factors. The information here may inform such a decision but will not be interpreted as a desire to switch to a product with more green boxes.