Not sure why I would want to self host what is effectively a phone system. I have actual products to build. We could ease time self hosting source control as well -- to what end? I have members of the team spending time (and thus money) setting up something that pleases people philosophically but really adds zero value -- in fact, it actually costs money (through very expensive developer time.)

I don't get the point of complaining about Slack. It works great, it's simple to use and it has an amazing feature set. IRC is pretty terrible. Try doing a drag and drop file transfer. Try using markdown. Try displaying images inline.

I don't get what the problem is with closed source Slack. Do we avoid the phone company because their software is closed source? There comes a point where this FOSS obsession sort of jumps the shark. Worrying about a 'walled garden' for a chat tool is kind of silly. If it bothers people so much, create a FOSS Slack with the ease of use and setup and maybe people would be more interested. But anything that requires me to 'self host' something that amounts to a service means that is a bad use of time. I can pay the Slack guys to maintain chat while my devs work on maintaining our products. IRC is terrible. Try and get someone from your marketing department to use IRC. The neck beard and almost hipster pontification about the 'bloat' of Slack is kind of ridiculous. We have better things to worry about. Slack works on all my devices perfectly. I have a searchable log of everything. I don't have to think or worry about anything. It's simple and works. Until there's a viable alternative that exceeds Slack's ease of use, that's what I recommend people use.

> IRC is terrible.

I didn't mention IRC in my comment :)

It's interesting how you compare Slack with a phone company. There are important differences between Slack and a phone company. 1. If you give me your phone number I could be talking with you in a few seconds without me even knowing the name of our phone company. 2. You could decide to change your phone service provider and (in some countries) even keep your number.

How would you do these things with Slack? Slack is great, and I like it, but it could stop being great at some point in the future.

(Yes, I realize that Rocket.Chat user couldn't chat with Zulip user, for example. That's why I'm excited about efforts like https://matrix.org/.)

I agree with you: it's expensive to self-host. [1] But when it is possible to self-host, you could hire a specialized company to host the chat system for you. And - if you are careful - you can later switch your chat-system-hosting provider if you want.

[1]: That's what https://sandstorm.io is trying to fix, by the way.

> Not sure why I would want to self host what is effectively a phone system

That's an interesting parallel. I suppose it would technically be possible for a company to out-source their internal phone system to an external third-party using VOIP. But I've never seen it done and I don't know how I would persuade a CTO that it's a good idea to make internal communication reliant on the Internet.

Yet companies are falling over themselves to out-source internal IM... why?

> Not sure why I would want to self host what is effectively a phone system.

Because you work in an industry were security matters. Such as banking, healthcare, government, government contracting, or any business with more than a couple hundred folks.

Because you provide support and want to customize / integrate that with rest of your data/systems to provide superior service to customers.

Let's chat: no mobile, no push notifications. Very fancy and not so useful UI (imho).

Don't know others yet, thanks for the list.

Rocket.chat has web, iOS, Android, Windows, Mac, and Linux clients, with push notifications.

I haven't figured out how to get the iOS client to connect to a custom chat server. It seems to only support the main rocket.chat server.

Unless things have changed, you have to recompile the mobile apps with the address of your own server and distribute them yourself.

> Update. And I would love to see a modern federated chat protocol to take off. Something like http://matrix.org/.

XMPP?

On my last evaluation, I found the two most interesting to look at matrix and tox.chat. But in the context of a slack-alternative, matrix is definitely the one to look at. Also has an IRC bridge: https://github.com/matrix-org/matrix-appservice-irc

As for XMPP, I think it is still entirely viable as an alternative to using a brand new protocol and brand new clients and servers. But if you want solid off-line messaging, server-side logging and scalable group chat -- there aren't any out-of-the box combination of free/open servers and clients that will work, as far as I've been able to figure out. I assume one would want a solid command line client, solid gui clients for Windows, OSX, Linux/BSD, Android, iOS and Windows phone, along with a good web client.

I don't think you can pick-and-choose a XMPP server and clients that will provide all that, today. It is certainly possible to make that, standing on the shoulders of various open projects -- but the effort would be anything but trivial. I'd be happy to be proved wrong, though!

Unfortunately XMPP didn't take off. Notice how it's nowhere near as ubiquitous as email and web standards. Also notice how nearly all modern chat services don't support XMPP. I'd argue there are technical reasons for this situation. Try searching for "XMPP" in this thread for details.

Except WhatsApp and until recently, Google Chat / Hangouts.

Yes, thank you. But none of them support XMPP federation (only Google supported it the past).

And I would add Facebook to your "until recently" example.

These services don't want federation. At all.

XMPP is an awful soup of incompatible servers and clients, though.

You can also host your own Rocket.Chat instance on their infrastructure by going to https://rocket.chat/deploy. There you can deploy it as https://[your_instance].rocket.chat which is pretty cool.

Matrix looks interesting!