10 ms·

I don't really get why there is so many Slack alternatives coming up these days. On every post like this there is tons of comment linking to other Slack altern

by volent 11y ago

I don't really get why there is so many Slack alternatives coming up these days. On every post like this there is tons of comment linking to other Slack alternatives, it's not like this is gonna be _the_ Slack-alternative. Here is a non exhaustive list : RocketChat : https://news.ycombinator.com/item?id=9624737 https://news.ycombinator.com/item?id=9624737 Let's Chat : https://news.ycombinator.com/item?id=9040841 https://news.ycombinator.com/item?id=9040841 Friends : https://news.ycombinator.com/item?id=9461504 https://news.ycombinator.com/item?id=9461504 Gitter : https://news.ycombinator.com/item?id=6739074 https://news.ycombinator.com/item?id=6739074

jsmthrowaway 11y ago
Slack's success inspires derivatives and, in this case, a direct copy. Review the screenshots. Before you get excited about Mattermost as the hosted Slack you've been waiting for, think hard about the AGPL licensing.
- nzseth 11y ago
  Why would that be a problem?
  - jsmthrowaway 11y ago
    I haven't worked for a company in four years that permits the installation of AGPL software because the ramifications are still unclear and largely untested. MongoDB asserts, for example, that just using MongoDB doesn't require you to do anything, even though the license text is in clear contradiction to the assertion. I do not think MongoDB understands its own license. Chris DiBona has spoken in public about Google's reasons, but he was kind. I cannot discuss other experience I have publicly, so I'd simply suggest doing some research on the large unknowns in deployment of AGPL software underneath a proprietary Web service somewhere, and then think about all the integrations you'd wire up to something like a Slack derivative. I am not a lawyer and would strongly suggest consulting one before using AGPL software anywhere in your infrastructure, at all.
    - drummer32 11y ago
      I don't understand you reasoning at all. What could be the problem with using a chat software that is released under AGPL?
      - jnbiche 11y ago
        Because almost certainly engineers will want to integrate an on-premises system into their existing system, and that will trigger the AGPL for all the systems that are network-connected to the AGPL system. Unless you are sure that your engineers will know to not try to integrate the AGPL software with any of your existing systems, I agree that people should just stay away.
        1stop 11y ago
        No it won't... It will at most trigger the AGPL for the integration off that system... which is it's proprietary no one will ever want... hence no one will ever sue you to release it. Are Tinfoil hats on sale or something?
        jsmthrowaway 11y ago
        No, just folks with a little more legal experience than "potentially and willfully violate the terms and spirit of a license because we assume nobody will ever sue us," which also doesn't scale beyond a team of two. Not enough people take license compliance seriously. (Your comment an example.) Just to communicate the impact here, getting compliance wrong can result in significant legal liability. You and I are both unqualified to dismiss it or discuss it.
        zephod 11y ago
        I find it interesting that you're getting consistent downvotes for saying the same thing my startup's legal counsel has repeatedly said about the AGPL: Be extremely careful. Assume nothing and write defensively, because the nature of an "integration" is too vague to risk a company's infrastructure. I get the impression others here are happily screwing around with AGPL integrations with nothing to lose.
robmccoll 11y ago
Does anyone know if these or any others have native desktop and/or mobile clients?
- sneak 11y ago
  Or, more importantly, GApps OAuth/SAML SSO?
DonHopkins 11y ago
As long as Gitter was copying Stewart Butterfield, they should have named it "Gittr".
grizzles 11y ago
Anyone know which of these has an easy integration component for chatting with web visitors?
kidsil 11y ago
For me, only Gitter makes perfect sense. Because it's based on GitHub repositories, I can see why this should be used instead of Slack.
lmm 11y ago
So many slack alternatives are coming up because slack is really good. It's that simple.
- richmarr 11y ago
  ...and because so few people apparently realise that's Slack's value is in the quality execution, which can be copied by a decent team (but takes a phenomenal team to beat).
  - Touche 11y ago
    As far as I can tell Gitter is owning the space for open source projects, so there are definitely niches here.
    - richmarr 11y ago
      Yeah, I expect there are, maybe Gitter can leverage their OSS adoption to their advantage. I don't know their product or approach well enough to comment.
  - thebaer 11y ago
    Genuine question: what did/do they execute on so well? I've only read about them having a great launch strategy.
    - richmarr 11y ago
      In my view; product design & build quality. Yammer were already doing most of what Slack does. Tiny Speck took that and UX'd the shit out of it until it was a joy to use.
      - thebaer 11y ago
        Gotcha, it's the first corporate chat app I've used outside of Skype, so I guess I don't know how bad it was, ha. I've personally had trouble with how unintuitive Slack's UI can be sometimes, when it seems like they're just trying to find places for all their features. But it's gotten ridiculously better in their last redesign.
javiercr 11y ago
It's like back in 2010 when everyone was building free / open source Basecamp clones.
- jdp23 11y ago
  Yeah whatever happened to all of those?
  - jessaustin 11y ago
    Whatever happened to Basecamp itself? I used to hear about it all the time...
    - darkr 11y ago
      Last I heard they had 6 million active users (vs 1 million in 2012).
      - contingencies 11y ago
        ... by what definition of active, and what definition of users? Surely you would define such a SaaS by revenue or number of customers rather than users, which allows you to fluff up your number by claiming every individual at every client organization is a user ... even if those accounts are automatically generated by some onboarding process then ignored.
StavrosK 11y ago
Has anyone used a self-hosted one they were satisfied with? Which one?
- DoubleMalt 11y ago
  We are pretty happy with let's chat.
  - StavrosK 11y ago
    Thank you, that looks very nice.
  - hhaidar 11y ago
    Hah, this is awesome to hear. Are you using it with ldap/kerberos auth?
    - DoubleMalt 11y ago
      ldap, works like a charm
- mrmondo 11y ago
  Let's chat looked great but we were a little put off by mongodb and something else that escapes my mind right now so we ended up sticking with OpenFire for our XMPP server / chat rooms for the time being although it certainly has it's share of bugs.
  - StavrosK 11y ago
    Ah, an XMPP server is a good choice for IM for us, although I can't get the team to stick around in the channels for very long. Maybe that's a culture problem, though.
    - amandine 11y ago
      I would blame UX there :) In my mind a collaboration tool should not be a burden, if people let it down, it means it's not appropriate. Hence the success of Slack: people realised collaboration can be made easy and real-time without being a pain. And wrt self-hosted chat servers, you can have a look at some implementations of Matrix (http://matrix.org http://matrix.org): there is an opensource a ref implementation of a server (https://github.com/matrix-org https://github.com/matrix-org) and then a bunch of clients at different level of glossiness, for web, iOS and Android (http://matrix.org/blog/try-matrix-now/ http://matrix.org/blog/try-matrix-now/) available. Or you can build your own if you feel like it :) Fully decentralised and persistent communication. No full blown collaboration tool but public & private chat rooms with the ability to exchange files and do 1:1 voice & video calls (group call is in the pipe).
it33 11y ago
Mattermost team here, We think choice is good, and open source reduces the cost of creating more choice.
- pjc50 11y ago
  Choice itself is also a cost, beyond a certain point. The more alternatives, the harder it is to evaluate them all properly.
  - icebraining 11y ago
    That's not really a problem, you just a number of them you can evaluate (say, 10), either from some recommendation list or randomly, and ignore the others. The end result will be the same as if those others hadn't existed at all.
- orkoden 11y ago
  I actually prefer todays web video to having to install RealPlayer, Quicktime, Windows Media Player, Flash player, Shockwave player just play video on the web. Choice is not always good.
  - deleted 11y ago
    [deleted]
  - michaelbuddy 11y ago
    Actually now you have the choice of web video utilizing codecs that came from all the companies producing the software you mentioned above, and the evolution from them to the capability we have today, be it codecs or browser support. the new openness of it created the choice you prefer now.
akhilcacharya 11y ago
But this one is written in Go!
- it33 11y ago
  Go is awesome!!
jmkni 11y ago
I guess it's because it looks like a pretty easy application to build. 'Looks like' being key there.
- gukov 11y ago
  https://scotch.io/courses/building-a-slack-clone-in-meteor-js https://scotch.io/courses/building-a-slack-clone-in-meteor-j...
  - amelius 11y ago
    Chat programs are the hello world programs of the era of the social web.
ara4n 11y ago
There's no harm in having loads of options - you just get a Darwinian survival of the fittest for which app works best. Competition is healthy. The thing that sucks is that as end users we end up having all our chats and identity fragmented over all these different silos - be they selfhosted ones or proprietary SaaS. There's no way I'll rely on MatterMost or any of the above unless I can access my existing communities (be they on IRC, XMPP, Slack, HipChat or whatever); adding yet more fragmentation into the mix helps nobody. This is why it's vital to have an open standard for decentralising the conversations between all these different islands that kills fragmentation whenever a new one pops up. And it's actually beneficial to new contenders like MatterMost as it could help them onboard users into their UX and app without having to start new conversations and contacts. [Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]
- bad_user 11y ago
  You mean XMPP federation? Nobody wants to implement that because companies like Slack, Atlassian, Google, Facebook, Microsoft, Apple, etc are interested in lock-in primarily.
  - lez 11y ago
    "Nobody" is an exageration, since Gitter, RocketChat, Mattermost, Friends, and Let's chat DO want to implement that.
  - wslh 11y ago
    I hope the open source community learned a lesson with Slack and other offerings. The trick is the user experience. Slack is a trivial piece of code to reproduce (not their business).
  - heavenlyhash 11y ago
    Lots of people -- in that list, even -- started with XMPP based systems. They all move away. At first, I also thought this was an open and shut case of interest in lock-in. Now, I'm not going to say that isn't true, but it's also worth considering that XMPP... just isn't that good. Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to admit: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work. I can't honestly fault anyone who started with XMPP and then rapidly started looking to get off. Examples: - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...). - multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages. - there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering. Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture". Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features. I want an open chat protocol. I thought XMPP might be the one. Then I actually looked at it. Tried to write something with it. XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this. (N.b. These complaints are a shameless repost from another not-very-old thread about chat where XMPP was also raised: https://news.ycombinator.com/item?id=9718784 https://news.ycombinator.com/item?id=9718784 .) I've since looked at matrix.org ... and I'm really impressed. The standard is completely reasonable. It's the first federated chat standard I've seen proposed that actually has loose timing systems that's both available during a partition and can reach consistency afterward (messages list their last-seen messages, and so act like vector clocks, an accepted good solution to problems in CAP territory). You could actually take two systems with clock skew and have them reach a single, reconciled view of the world, even after netsplits. And practically speaking... man, go look at their list of clients. Despite being a relatively young project, matrix has clients on every major platform -- as far as I can tell, this is better platform coverage than XMPP, and better feature parity within those clients since critical things like message IDs are actually baked into the spec. I really suggest giving matrix a look. There's a lot going right over there.
colordrops 11y ago
One of the reasons there are so many alternatives is that many of us have been begging Slack for a self-hosted version for over a year and they are completely ignoring our requests. We want to give them a lot of money but apparently they don't want it.
- pbreit 11y ago
  I don't think it would make much/any sense for Slack to deliver a self-hosted version. First, it is growing like crazy right now. And second, that would be a totally different animal in terms of coding, maintaining, supporting, marketing, etc.
orkoden 11y ago
A great RFC instead a dozen incompatible startups would be the best thing since IRC.
- fixxer 11y ago
  The best thing since IRC is IRC.
  - geofft 11y ago
    Slack has the advantage of maintaining message history server-side instead of client-side, so you can catch up on things you missed without running a client in a screen session (or a bouncer, or a logger, or...). This functionality is part of the core protocol. Is there a similar standard for IRC? If not, then IRC is serving a different use case.
    - tadfisher 11y ago
      It's trivial to log IRC, but it is hard to integrate server-side log display and search with prebaked clients.
- jerf 11y ago
  I'm not aware of any particular feature that doesn't fit into XMPP with a couple new namespaces at most. And before you get too down on XMPP, bear in mind that anything that standardizes half-a-dozen chat clients will end up pretty nasty on its own, too. It all looks simple when you're a user of the client, but under the hood chat systems get... "interesting". In the apocryphal Chinese curse sense.
dbecker 11y ago
I recently switched from a company using HipChat to a company using Slack, and the differences seem mostly cosmetic and immaterial. Are the differences between these various chat programs big enough to affect user experience or productivity? What distinguishes one from the next?
- joesmo 11y ago
  You mean that slick, plaid UI with neutral, low key colors doesn't enhance your productivity? That's the whole reason I moved from HipChat to Slack.
- davis_m 11y ago
  One of the biggest differences for us was the option for a self hosted solution with HipChat. Both companies are fairly open about accessing user communications without any sort of permission or audit trail. Being able to self host it ensures that Atlassian or Slack employees aren't dropping into our chats.
  - dirtmerchant 11y ago
    Check the fine print. Even with the self-hosted version, Atlassian is scraping the chat data for analytic purposes. This was confirmed by Atlassian support via a HIPPA audit at my last gig.
segmondy 11y ago
10,000 message limit for free version. You might have sensitive information you need contained in your network. It get's expensive very fast.
JustSomeNobody 11y ago
Probably the same reason there's a new javascript framework every week. Some people think it's cool and want to build their own. For better or worse.
jakejake 11y ago
I think when developers see a simple, successful product they say to themselves "hey, I could do that!" So we wind up with a thousand to-do apps. Slack is a step or two in complexity beyond a to-do app. Simply copying a product like slack is not that difficult. Building an "amazing" version of a product while re-inventing small details is the clever part.
Cymen 11y ago
Slack is non-optimal for open source projects because each project will require you to have yet another Slack account. It also isn't IRC-like. With Gitter, you can be on multiple projects at once in one client UI. So different use cases mean a different product might be better. Particularly if business concerns limit how one can use existing products.
niutech 11y ago
That's because Slack is slow. There are even more lightweight open source Slack alternatives described here: http://browsingthenet.blogspot.com/2015/05/slack-is-so-slow-here-are-5-lightweight.html http://browsingthenet.blogspot.com/2015/05/slack-is-so-slow-...
restya 11y ago
As you have mentioned many chat system... We thought about adding chat module to our open source trello clone called Restyaboard http://restya.com/board/ http://restya.com/board/ Do you think if this will not be useful addition? Or what chat system among above will be useful to integrate?

by volent 11y ago

jsmthrowaway 11y ago

Slack's success inspires derivatives and, in this case, a direct copy. Review the screenshots. Before you get excited about Mattermost as the hosted Slack you've been waiting for, think hard about the AGPL licensing.

nzseth 11y ago
Why would that be a problem?
- jsmthrowaway 11y ago
  I haven't worked for a company in four years that permits the installation of AGPL software because the ramifications are still unclear and largely untested. MongoDB asserts, for example, that just using MongoDB doesn't require you to do anything, even though the license text is in clear contradiction to the assertion. I do not think MongoDB understands its own license. Chris DiBona has spoken in public about Google's reasons, but he was kind. I cannot discuss other experience I have publicly, so I'd simply suggest doing some research on the large unknowns in deployment of AGPL software underneath a proprietary Web service somewhere, and then think about all the integrations you'd wire up to something like a Slack derivative. I am not a lawyer and would strongly suggest consulting one before using AGPL software anywhere in your infrastructure, at all.
  - drummer32 11y ago
    I don't understand you reasoning at all. What could be the problem with using a chat software that is released under AGPL?
    - jnbiche 11y ago
      Because almost certainly engineers will want to integrate an on-premises system into their existing system, and that will trigger the AGPL for all the systems that are network-connected to the AGPL system. Unless you are sure that your engineers will know to not try to integrate the AGPL software with any of your existing systems, I agree that people should just stay away.
      - 1stop 11y ago
        No it won't... It will at most trigger the AGPL for the integration off that system... which is it's proprietary no one will ever want... hence no one will ever sue you to release it. Are Tinfoil hats on sale or something?
        jsmthrowaway 11y ago
        No, just folks with a little more legal experience than "potentially and willfully violate the terms and spirit of a license because we assume nobody will ever sue us," which also doesn't scale beyond a team of two. Not enough people take license compliance seriously. (Your comment an example.) Just to communicate the impact here, getting compliance wrong can result in significant legal liability. You and I are both unqualified to dismiss it or discuss it.
        zephod 11y ago
        I find it interesting that you're getting consistent downvotes for saying the same thing my startup's legal counsel has repeatedly said about the AGPL: Be extremely careful. Assume nothing and write defensively, because the nature of an "integration" is too vague to risk a company's infrastructure. I get the impression others here are happily screwing around with AGPL integrations with nothing to lose.

robmccoll 11y ago

Does anyone know if these or any others have native desktop and/or mobile clients?

sneak 11y ago
Or, more importantly, GApps OAuth/SAML SSO?

DonHopkins 11y ago

As long as Gitter was copying Stewart Butterfield, they should have named it "Gittr".

grizzles 11y ago

Anyone know which of these has an easy integration component for chatting with web visitors?

kidsil 11y ago

For me, only Gitter makes perfect sense. Because it's based on GitHub repositories, I can see why this should be used instead of Slack.

lmm 11y ago

So many slack alternatives are coming up because slack is really good. It's that simple.

richmarr 11y ago
...and because so few people apparently realise that's Slack's value is in the quality execution, which can be copied by a decent team (but takes a phenomenal team to beat).
- Touche 11y ago
  As far as I can tell Gitter is owning the space for open source projects, so there are definitely niches here.
  - richmarr 11y ago
    Yeah, I expect there are, maybe Gitter can leverage their OSS adoption to their advantage. I don't know their product or approach well enough to comment.
- thebaer 11y ago
  Genuine question: what did/do they execute on so well? I've only read about them having a great launch strategy.
  - richmarr 11y ago
    In my view; product design & build quality. Yammer were already doing most of what Slack does. Tiny Speck took that and UX'd the shit out of it until it was a joy to use.
    - thebaer 11y ago
      Gotcha, it's the first corporate chat app I've used outside of Skype, so I guess I don't know how bad it was, ha. I've personally had trouble with how unintuitive Slack's UI can be sometimes, when it seems like they're just trying to find places for all their features. But it's gotten ridiculously better in their last redesign.

javiercr 11y ago

It's like back in 2010 when everyone was building free / open source Basecamp clones.

jdp23 11y ago
Yeah whatever happened to all of those?
- jessaustin 11y ago
  Whatever happened to Basecamp itself? I used to hear about it all the time...
  - darkr 11y ago
    Last I heard they had 6 million active users (vs 1 million in 2012).
    - contingencies 11y ago
      ... by what definition of active, and what definition of users? Surely you would define such a SaaS by revenue or number of customers rather than users, which allows you to fluff up your number by claiming every individual at every client organization is a user ... even if those accounts are automatically generated by some onboarding process then ignored.

StavrosK 11y ago

Has anyone used a self-hosted one they were satisfied with? Which one?

DoubleMalt 11y ago
We are pretty happy with let's chat.
- StavrosK 11y ago
  Thank you, that looks very nice.
- hhaidar 11y ago
  Hah, this is awesome to hear. Are you using it with ldap/kerberos auth?
  - DoubleMalt 11y ago
    ldap, works like a charm
mrmondo 11y ago
Let's chat looked great but we were a little put off by mongodb and something else that escapes my mind right now so we ended up sticking with OpenFire for our XMPP server / chat rooms for the time being although it certainly has it's share of bugs.
- StavrosK 11y ago
  Ah, an XMPP server is a good choice for IM for us, although I can't get the team to stick around in the channels for very long. Maybe that's a culture problem, though.
  - amandine 11y ago
    I would blame UX there :) In my mind a collaboration tool should not be a burden, if people let it down, it means it's not appropriate. Hence the success of Slack: people realised collaboration can be made easy and real-time without being a pain. And wrt self-hosted chat servers, you can have a look at some implementations of Matrix (http://matrix.org http://matrix.org): there is an opensource a ref implementation of a server (https://github.com/matrix-org https://github.com/matrix-org) and then a bunch of clients at different level of glossiness, for web, iOS and Android (http://matrix.org/blog/try-matrix-now/ http://matrix.org/blog/try-matrix-now/) available. Or you can build your own if you feel like it :) Fully decentralised and persistent communication. No full blown collaboration tool but public & private chat rooms with the ability to exchange files and do 1:1 voice & video calls (group call is in the pipe).

it33 11y ago

Mattermost team here, We think choice is good, and open source reduces the cost of creating more choice.

pjc50 11y ago
Choice itself is also a cost, beyond a certain point. The more alternatives, the harder it is to evaluate them all properly.
- icebraining 11y ago
  That's not really a problem, you just a number of them you can evaluate (say, 10), either from some recommendation list or randomly, and ignore the others. The end result will be the same as if those others hadn't existed at all.
orkoden 11y ago
I actually prefer todays web video to having to install RealPlayer, Quicktime, Windows Media Player, Flash player, Shockwave player just play video on the web. Choice is not always good.
- deleted 11y ago
  [deleted]
- michaelbuddy 11y ago
  Actually now you have the choice of web video utilizing codecs that came from all the companies producing the software you mentioned above, and the evolution from them to the capability we have today, be it codecs or browser support. the new openness of it created the choice you prefer now.

akhilcacharya 11y ago

But this one is written in Go!

it33 11y ago
Go is awesome!!

jmkni 11y ago

I guess it's because it looks like a pretty easy application to build. 'Looks like' being key there.

gukov 11y ago
https://scotch.io/courses/building-a-slack-clone-in-meteor-js https://scotch.io/courses/building-a-slack-clone-in-meteor-j...
- amelius 11y ago
  Chat programs are the hello world programs of the era of the social web.

ara4n 11y ago

There's no harm in having loads of options - you just get a Darwinian survival of the fittest for which app works best. Competition is healthy. The thing that sucks is that as end users we end up having all our chats and identity fragmented over all these different silos - be they selfhosted ones or proprietary SaaS. There's no way I'll rely on MatterMost or any of the above unless I can access my existing communities (be they on IRC, XMPP, Slack, HipChat or whatever); adding yet more fragmentation into the mix helps nobody. This is why it's vital to have an open standard for decentralising the conversations between all these different islands that kills fragmentation whenever a new one pops up. And it's actually beneficial to new contenders like MatterMost as it could help them onboard users into their UX and app without having to start new conversations and contacts. [Disclaimer: Matrix.org is such a standard, providing an open HTTP API for decentralised chatrooms, and I work on it.]

bad_user 11y ago
You mean XMPP federation? Nobody wants to implement that because companies like Slack, Atlassian, Google, Facebook, Microsoft, Apple, etc are interested in lock-in primarily.
- lez 11y ago
  "Nobody" is an exageration, since Gitter, RocketChat, Mattermost, Friends, and Let's chat DO want to implement that.
- wslh 11y ago
  I hope the open source community learned a lesson with Slack and other offerings. The trick is the user experience. Slack is a trivial piece of code to reproduce (not their business).
- heavenlyhash 11y ago
  Lots of people -- in that list, even -- started with XMPP based systems. They all move away. At first, I also thought this was an open and shut case of interest in lock-in. Now, I'm not going to say that isn't true, but it's also worth considering that XMPP... just isn't that good. Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to admit: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work. I can't honestly fault anyone who started with XMPP and then rapidly started looking to get off. Examples: - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...). - multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages. - there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering. Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture". Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features. I want an open chat protocol. I thought XMPP might be the one. Then I actually looked at it. Tried to write something with it. XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this. (N.b. These complaints are a shameless repost from another not-very-old thread about chat where XMPP was also raised: https://news.ycombinator.com/item?id=9718784 https://news.ycombinator.com/item?id=9718784 .) I've since looked at matrix.org ... and I'm really impressed. The standard is completely reasonable. It's the first federated chat standard I've seen proposed that actually has loose timing systems that's both available during a partition and can reach consistency afterward (messages list their last-seen messages, and so act like vector clocks, an accepted good solution to problems in CAP territory). You could actually take two systems with clock skew and have them reach a single, reconciled view of the world, even after netsplits. And practically speaking... man, go look at their list of clients. Despite being a relatively young project, matrix has clients on every major platform -- as far as I can tell, this is better platform coverage than XMPP, and better feature parity within those clients since critical things like message IDs are actually baked into the spec. I really suggest giving matrix a look. There's a lot going right over there.

colordrops 11y ago

One of the reasons there are so many alternatives is that many of us have been begging Slack for a self-hosted version for over a year and they are completely ignoring our requests. We want to give them a lot of money but apparently they don't want it.

pbreit 11y ago
I don't think it would make much/any sense for Slack to deliver a self-hosted version. First, it is growing like crazy right now. And second, that would be a totally different animal in terms of coding, maintaining, supporting, marketing, etc.

orkoden 11y ago

A great RFC instead a dozen incompatible startups would be the best thing since IRC.

fixxer 11y ago
The best thing since IRC is IRC.
- geofft 11y ago
  Slack has the advantage of maintaining message history server-side instead of client-side, so you can catch up on things you missed without running a client in a screen session (or a bouncer, or a logger, or...). This functionality is part of the core protocol. Is there a similar standard for IRC? If not, then IRC is serving a different use case.
  - tadfisher 11y ago
    It's trivial to log IRC, but it is hard to integrate server-side log display and search with prebaked clients.
jerf 11y ago
I'm not aware of any particular feature that doesn't fit into XMPP with a couple new namespaces at most. And before you get too down on XMPP, bear in mind that anything that standardizes half-a-dozen chat clients will end up pretty nasty on its own, too. It all looks simple when you're a user of the client, but under the hood chat systems get... "interesting". In the apocryphal Chinese curse sense.

dbecker 11y ago

I recently switched from a company using HipChat to a company using Slack, and the differences seem mostly cosmetic and immaterial. Are the differences between these various chat programs big enough to affect user experience or productivity? What distinguishes one from the next?

joesmo 11y ago
You mean that slick, plaid UI with neutral, low key colors doesn't enhance your productivity? That's the whole reason I moved from HipChat to Slack.
davis_m 11y ago
One of the biggest differences for us was the option for a self hosted solution with HipChat. Both companies are fairly open about accessing user communications without any sort of permission or audit trail. Being able to self host it ensures that Atlassian or Slack employees aren't dropping into our chats.
- dirtmerchant 11y ago
  Check the fine print. Even with the self-hosted version, Atlassian is scraping the chat data for analytic purposes. This was confirmed by Atlassian support via a HIPPA audit at my last gig.

segmondy 11y ago

10,000 message limit for free version. You might have sensitive information you need contained in your network. It get's expensive very fast.

JustSomeNobody 11y ago

Probably the same reason there's a new javascript framework every week. Some people think it's cool and want to build their own. For better or worse.

jakejake 11y ago

I think when developers see a simple, successful product they say to themselves "hey, I could do that!" So we wind up with a thousand to-do apps. Slack is a step or two in complexity beyond a to-do app. Simply copying a product like slack is not that difficult. Building an "amazing" version of a product while re-inventing small details is the clever part.

Cymen 11y ago

Slack is non-optimal for open source projects because each project will require you to have yet another Slack account. It also isn't IRC-like. With Gitter, you can be on multiple projects at once in one client UI. So different use cases mean a different product might be better. Particularly if business concerns limit how one can use existing products.

niutech 11y ago

That's because Slack is slow. There are even more lightweight open source Slack alternatives described here: http://browsingthenet.blogspot.com/2015/05/slack-is-so-slow-here-are-5-lightweight.html http://browsingthenet.blogspot.com/2015/05/slack-is-so-slow-...

restya 11y ago

As you have mentioned many chat system... We thought about adding chat module to our open source trello clone called Restyaboard http://restya.com/board/ http://restya.com/board/ Do you think if this will not be useful addition? Or what chat system among above will be useful to integrate?