Can someone point me to a good comparison of Matrix, Mattermost, Zulip, Rocketchat, IRC and XMPP (say, Prosody) or explain what niche each fills if they are not competing.
Assuming for a small company with a dozen employees, all of whom sometimes work remotely.
Let me take a crack at it. This is highly opinionated and probably biased.
IRC is reliable, can be forced into encrypted client-server communications, and has the fewest client-side features. The strength is the number of available clients and the primacy of channels (rooms). File-sharing is available but not a focus. There are lots of bot libraries.
XMPP is reliable, the server can mandate client-server encryption, and has some client-side features including simultaneous appearances (being one person logged in through several devices) and better one-to-one chat than IRC. File-sharing is an optional add-on. There is no good iOS client that I know of; mobile clients tend to be bad at requesting history.
Mattermost, Zulip and Rocketchat I have the least experience with; they all seem to be very popular with small groups of users but are complex to install and have very few clients.
Matrix is promising. It does one-to-one and chat rooms smoothly, server config is pretty easy, and you can have the server mandate client-server encryption. There are lots of clients that all seem to be in mid-alpha development. If it survives a year or two, I think it will be widely adopted.
> XMPP is reliable, the server can mandate client-server encryption, and has some client-side features including simultaneous appearances (being one person logged in through several devices) and better one-to-one chat than IRC. File-sharing is an optional add-on. There is no good iOS client that I know of; mobile clients tend to be bad at requesting history.
ChatSecure works on iOS and has history fetching features (MAM), for Android there is Conversations.im, IMHO the best XMPP client to date.
> Mattermost, Zulip and Rocketchat I have the least experience with; they all seem to be very popular with small groups of users but are complex to install and have very few clients.
At least for Mattermost I have to disagree with the "complex to install". All you need is a sql database (MySQL/MariaDB or Postgres), for production you then also should put a reverse proxy in front.
With "very few clients" you are referring to client software, correct?
History has always been a major concern for me with IRC and XMPP. IRC has no support (though I think there's an upcoming standard that does), and my (admittedly several years old) experiences with XMPP weren't good in that regard either.
I work on Zulip, so will only attempt an answer for that. Zulip is designed to scale team chat past when you're getting 1-200 messages a day.
With an IRC- or Slack-like communication model, waking up to 100+ new messages every morning is a big drain on time and energy. Also, once a channel starts getting 100+ messages a day, it stops being useful for real communication. If someone starts a conversation at 10am, and you come by after lunch, it's hard to respond in context.
You can see how Zulip solves this problem on the Zulip community server, https://chat.zulip.org (send test messages to "#test here", follow the code of conduct, etc., it's a live server). Feel free to PM me there if you set things up and have any questions/feedback.
To address a previous post: Zulip, Mattermost, and Rocket.chat all take about 5 minutes to install, so I wouldn't worry too much about that. Zulip and Rocket.chat also come with SaaS versions if you don't want to run your own infrastructure.
Last I looked, only rocket.chat had a sane, minimal docker-compose setup that worked for getting started. I'm not thrilled about the mongodb dependency - but my overall impression of rocket.chat was very good. And the rest api is well documented and easy to work with.
It may be that zulip has "scaled down" a bit now - when I looked, it seemed you got the complexity of serving 10k users even if you only had 100s.
(Not meant as a dig at zulip, I think it's awesome that the project was made open source!)
Assuming for a small company with a dozen employees, all of whom sometimes work remotely.