Let me first turn this around. I actually personally tried to interact with the Slack team on how they implemented their XMPP gateway, early on. I pointed out how a relatively small missing protocol feature (server-side group chat bookmarking) was severely impacting the usability of the gateway, as it caused caused you to have to explicitly join the group chat room representing a Slack channel on every client (re)connect. In fact they violated protocol in case a client requested the list of bookmarks, causing clients to hang while connecting. It took them a year to start responding, and the problem was not fixed.

Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.

That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.

There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.

I would have welcomed Slack interacting with the community, but they didn't.

Thanks for adding more context! It's hard to get that from twitter, sorry.

Facebook and Google? They use IRC internally for technical reasons. IRC doesn't fall over. Googlers internally revolted when they were told to use Hangouts internally.

XMPP works great and I've used it at several employers. There's no technical reasons to avoid it; it really is all about lock-in and corporate planning.

I've watched Ralph struggle for years against corporate asshats. It's a real tragedy that all these companies don't participate in open standards. We shouldn't have ever expected good things from Slack.

> Facebook and Google? They use IRC internally for technical reasons. IRC doesn't fall over. Googlers internally revolted when they were told to use Hangouts internally.

I was talking about implementation of Facebook messenger, or Google hangout (which does not use XMPP), not what is used internally for communication.

Also, at Facebook, messenger is most used product internally. IRC is still used, but not that much (depends on org, infra devs use IRC more than product devs). But IRC is still essential, in case of emergencies (where you don't want to use your own product, as it may be down).

They could implement what properly? According to the tweet XMPP supports this. Slack just doesn't care.

I like the attitude of telling the truth. Compare to Torvalds.

> I like the attitude of telling the truth. Compare to Torvalds.

Care to elaborate?

I just like it when people flame and insult when it's deserved. A nice contrast to the "happy world; I get triggered by everything" stuff.

So rather than actually trying to find solutions, you prefer people to yell and shout at each other and not get anything done.

Well, they can do both.

> Otherwise, more and more projects would be dropping XMPP support.

Eve Online just abandoned their own in game chat server and replaced it with ejabberd.