http://getkaiwa.com/ is another Slack alternative that uses an XMPP backend, which IMO is much better than a custom backend. So far the only open source Slack clone I've seen that uses an existing standard for the backend
There are a slew of developers who tangled with XMPP and came away with very negative, well-founded reasons to dislike the protocol. Do you want XMPP because it is a standard, or you also have a contrary experience to these developers?
And links [4] and [5] have a lot of people piping up saying they like XMPP just fine.
To be fair to XMPP, I strongly suspect it is a protocol trying to solve a very large, very messy problem space, and too many developers are trying to wrestle with it "raw" in its totality, unaware that for their specific problem domain, they only need a subset, and a specialized protocol/library that exposes only that subset to them. It's almost as if too few understand that XMPP is kind of the assembly language (or microcode?) of its problem domain, and most people need a $High_Level_Language_of_Choice instead.
I just like jabber because it's a standard. I have an app on my phone that'll do Jabber already. There's a lot of server software already out there to host Jabber, it's pretty robust, all we need is a reasonable frontend for desktop
The counter to that—and no doubt a factor for many like Slack—is that when you use a custom protocol/API you get to control the whole experience. You don't have to deal with bugs in third-party clients, wait for clients to get emoji support, and can control the look-and-feel (many of the Jabber apps I've seen aren't great).
This is obviously not ideal for everyone, but I suspect that outside of tech that using a custom client is possibly even a plus.
I'd rather have it the other way around: start from a solution that works (like Mattermost) and progressively plug XMPP into it. Mattermost and its friends have the huge advantage of having everything built-in and well working together, and if you take a good look at it XMPP should be more like a "compatibility protocol" on top of a working solution.
Mattermost v1.1 (ships Oct 16) has incoming webhooks support with samples (www.mattermost.org/webhooks/), and we're planning outgoing webhooks v1.2 (Nov 16), which provides the ground work for XMPP
https://rocket.chat/ built with Meteor and with WebRTC videocalls, is another great open source alternative... The list of current and upcoming features is quite impressive:
There's a lot of standards out there. Open is better than closed, and standard is better than ad hoc, yes...but that doesn't mean XMPP is automatically the best solution.
I'd honestly be more interested in seeing Mattermost try and write a really solid solution, and then work to standardise their protocol.
