It's amazing to me that Slack has been so successful, considering how so many other alternatives exist.
I've found several very annoying bugs in the OSX Slack client, and each time I wait a few months before trying it again, yet more bugs continue to occur.
It's impossible to un-join a team via the OSX app, or to remove a team that you partially created. Also, updates frequently force a logout and the password reset procedure is quite clunky.
I finally realized that the web version works pretty well so now I just use that when I need to use Slack.
I know this makes me sound old, but I really wish popular open source projects would just stick to IRC as it just works and doesn't require any proprietary client (and isn't trying to turn into video chat, screen sharing, etc.) Or I suppose I wish Slack would make its ecosystem available via IRC.
> I know this makes me sound old, but I really wish popular open source projects would just stick to IRC as it just works and doesn't require any proprietary client (and isn't trying to turn into video chat, screen sharing, etc.) Or I suppose I wish Slack would make its ecosystem available via IRC.
I'd say you'd be far from the only one. The thing that Slack really brought was an improved onboarding experience, but I have a (probably somewhat vain) hope that protocols will win over corporate controlled walled gardens.
Matrix[1] / Riot[2] are really promising and I really hope we settle on something like that sometime down the road.
[1]: http://matrix.org/
There is also Mattermost. An open source Slack.
We recently did a test run for Mattermost to see if it's a better fit for us than Slack.
This is a note to others who may be considering the same. Specific needs will vary greatly across teams/companies.
We found Mattermost web client to be ok, however phone apps and integration coverage are both poor by comparison to Slack. We also found running, securing, and maintaining our own server to be roughly as or more expensive than using Slack.
I'm hopeful the Mattermost project keeps momentum to improve. Currently though it doesn't quite seem in the same league.
This will likely always be the case with open source chat solutions.
Developing clients is hard. Especially good UIx and complex feature sets across a zillion platforms like Slack does. A lot of their day I bet these days is simply tracking down obscure bugs on certain platform combinations and trying to keep feature parity between everything working properly. I think most of us can stipulate Slack does a decent job there - or at minimum is far better than the competing (open) solutions.
I really wish there was a Slack alternative where I could purchase a really nice unified frontend and simply connect to an open protocol backend such as IRC or Jabber or whatever. This was the original intent behind IRC as well - back in the 90's there were a number of shareware style IRC clients developed for Windows - and you saw some interesting protocol hackery to make some more graphical features work.
I have yet to see open source really truly compete in the "client" arena, save for an exceedingly few notable exceptions. However, it excels at the backend where you will have developer interest and competence - and the long tail of possible bugs (and user competence) is a much more sane problem to tackle.
No, I do not expect this to ever exist for obvious reasons :)
There's connectors to Mattermost from IRC, XMPP, Slack, Discord and many other services: https://github.com/42wim/matterbridge
There's a wonderful Pidgin plug-in (https://github.com/EionRobb/purple-mattermost) that even has its own installer to bundle Pidgin itself (https://github.com/Brightscout/mattermost-pidgin-client)
Here's a Terminal client for Mattermost written in Haskell (https://about.mattermost.com/galois-releases-matterhorn/).
Also, we've upgrade the polish on Mattermost UI for our 4.0 release this month: https://about.mattermost.com/mattermost-4-0/
Agree good UI/UX in open source is hard, I think there are two challenges: a) Attracting top UI/UX talent, b) Having a project that prioritizes UI/UX.
That said, I would also propose that what has already happened is not impossible.