Before a Slack-using company would switch, the competitor would need to support many/most/all of the integrations that the company is using. You've really only got two chances to win Slack's customers: the point before they seriously adopt Slack, and the point in the future where Slack does something stupid like jack prices way up or suffer a serious breach.
Something like: there are all kinds of email integrations, user-specific and group-specific setups, etc. at companies. How can Slack ever compete?
The answer was that Slack was so much better for many companies that it made sense to suffer the pain of switching.
The company that beats Slack will likely be 10x better communication software or something very similar but distributed much more effectively (maybe Microsoft Teams in the enterprise).
Running two chat systems side by side, on the other hand, is a huge pain. There really is a pressure to get everything migrated and the old one turned off.
We lost a law suit once because a [not native English speaker] wrote "the bearing will fail with disastrous consequences", he meant the shaft would need to be replaced, but when a fire started in the area of the bearing that email was part of discovery and the jury decided the bearing was at fault for the fire not the user failing to clean the area which was our story. (legal would rather I not give you the case to read for yourself)
Chat tends to be less formal than email, thus more opportunity exists for something that is easy to take out of context. By not allowing saving chat logs we ensure they they will never get to court.
We have strict rules that emails must be deleted after a few months (unless we legally need to keep them). Any information in the email that is worth keeping longer than that is put in a formal system where legal can examine the words to ensure they won't be taken out of context and used against us.
Having it broken down by system is a pretty practical approach.
It's something I feel quite strongly about: chat should not be archived. There should be no backscroll; being not around when people are talking means not being part of that conversation. Chat messages have no value beyond the moment. Any chat implementation that assigns importance to messages beyond the current conversation is wrong.
For the rest... It was like peeking into an alien world. I've been maintaining an open source application since 2004, and I've had various day jobs, but managed to build it out into my day job the past couple of years. I've never had the startup itch :-) Just let me build up my userbase, my income stream and my contributor team, and I'm happy.
Persistent chat is one of the biggest values of Slack or Discord or Mattermost, and one of the big reasons I'll take it over IRC any day.
Persistent chat that you can join and read the backlog of is incredibly valuable. It becomes an asynchronous communication medium, rather than a synchronous one. And it's much richer and lower-friction than email.
Similarly, I'd disagree about friction, but I can see how that might be cultural/personal preference - none of the chat systems I've used provides good-enough tracking of "I still need to take care of this" compared to email clients with a few flags.
What's the value in removing this? I regularly look back to see what was discussed, it allows easier integration across timezones. I don't want to have to be around late for my American colleagues, or have to shift the conversation to large cc'd email. For chat I am involved in, why do you think I shouldn't be allowed a history of what I have talked about with people?
We must use chat very differently, because I don't understand this.
The number of times I've found answers to problems ("How do I X? Why can't I get Z to work with vagrant?" etc) by searching through Slack channels, or viewing pinned messages that explained something (or had a workaround/fix for a problem) is huge. This has been especially helpful when joining a team, where searching the archives can be the first step in finding answers.
A lot of what we chat about could safely be ephemeral, but there's a significant amount of company / team knowledge which can be searched (or pinned). The friction necessary to have people put answers in Confluence (or similar) is high enough that often the answers (or discussions around them) are either never written, or not updated later.
Great article, very informative. Thank you for the effort.
Nothing new here of course, tech shops have been doing it for decades. Centuries even maybe.
See also: certification programs.
If you think that’s too risky, legally, an alternative could be to provide example code showing “to do X in Slack, do this on our API”. If your tool gets some traction, a third party wrapper might show up.
So my view is that until Microsoft get their act together, Teams is not a serious contender to Slack. Companies can get it
"free" together with their Office subscription, but most developers won't use it until it works decently on their development platform of choice.
But I think your point about MS getting rid of Skype for Business in favor of Teams is the most important one. Once that happens, which MS has stated publicly, Teams will become a necessary app for MS to support, since enterprises won’t tolerate MS not having s chat service in O365.
I've been thinking about giving zulip a whirl with one of our smaller teams at work, and see how it compares to slack. Quite a few items on the "why zulip?" page really resonate with me.
Maybe not in the US, where APIs are under copyright, but outside it could work...