Why did Slack win out over IRC? (2018)
vice.com
vice.com
That said, I've succeeded in gradually getting some of my friends onto Riot/Matrix. To be clear, I did it without much technical/ideological evangelizing or being obtuse, just on the basis of them wanting to talk to me and in our social group. But Riot is also at least nice-looking, multiplatform, has modern features etc. Things that are still annoying:
1. Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot. (I understand that developers may choose to do different in their communication)
2. Entering into 1/1 conversations. I still don't know/remember how to reliably do it with a new person, always did it by trial and error by trying to invite in ways X and Y etc. It probably requires finding the opt-in into email invitations in the configuration by each participant. I understand these are some anti-stalking measures, but God is it annoying.
The thing I haven’t figured out is... why would people find this hard to understand for chat, but not for email? Everyone uses email, and everyone knows they can send an email to whatever email address they want no matter who their provider is.
Telephones are the same way, too. You get a phone number from whatever company you want and can use it to call people no matter what provider they’re using.
I’m not convinced that open/federated protocols are inherently more difficult for people in general to understand.
But yes, the analogy with cell phone providers is useful. With this analogy, who would still tie their social media profile to a single provider?
You choose your phone provider by looking at the top 3 or so established providers and the choice is usually made on price or other signing incentives. With your ISP you just pick from a couple ISPs that serve your area. With email you just pick GMail or whatever your work gives you.
All of these decentralized chat systems just need to act centralized. Have Matrix.org just be the matrix server that people sign up on and let the fact that other providers exist just be something that comes naturally. Have Mastadon be the StatusNet server but casually interface with other servers.
What seems to kill these projects is that the group positioned to own the market actively shoots themselves in the foot in an attempt to not become too big.
Let the protocol be an implementation detail. Sell the provider as a service.
> I’m not convinced that open/federated protocols are inherently more difficult for people in general to understand.
We may be disagreeing on the hierarchy of the goals. I think the priorities here are:
1. That the protocol is open and decentralized from the operator perspective (which is ensured in the case of Matrix).
2. That many people use it.
The #1 should be important for an opinionated minority pushing everyone else. The good thing is, non-technical people usually don't have much brand loyalty in these things. It's purely perceived convenience.
That the majority of people understand and care about #1 may or may not be realistic. I see it as partially another cause. Today, we have much of de facto centralization in email while the protocol is still decentralized. It would be nice to push chat to a more or less similar state and work from there. (I would also gladly see decentralization and inter-operation of many things enforced by law, but this is even more pie in the sky.)
Still, certainly your analogy can be used in communicating with people. But the main thing I'm trying to achieve is #2, getting them on board anyway.
Consider email for example: I think the main reason it's stuck around with us for so long is that we're at the point where being reachable by email is just expected. With everyone using email, someone trying to replace it with a centralized option would need to get everyone on board, while someone who wants to interoperate with email in general doesn't have that issue.
ISPs and phone companies are similar; nobody's going to start one that can't interoperate with the others nowadays. The public wouldn't stand for it, even if they couldn't explain why in terms of the underlying protocols.
While I would certainly love it if we could get people to care about open protocols, I think getting enough adoption of an open protocol would really be sufficient, so long as it's not easy for one big player to lock it down. (Google Talk for example; it was XMPP, but Google was the only player that mattered then as far as the public was concerned. Matrix is in a better position than that now.)
I see you haven't worked in corporate IT very much. You're missing the comparison too, Riot isn't the service, it's the client, and there are a crapload of people in the corporate world who "aren't computer people" and for whom Outlook is email. Or AOL. Or Gmail. Whichever email client they encountered first, that is email to them.
They know they can email people at different companies, they just don't know or care that many of those people are not using the same client.
A lot of these are one time decisions though. Once I install a client and configure it, then all I have to do for subsequent uses is to start the client and it will automatically connect to the server, set my nick, and join the channels I was in.
With Slack, you still have to create an account, find a workspace, join channels or get invited to them, etc. But once that's done, then you just need to open the Slack client and log in and it will load up the page, much like an IRC client does.
> 1. Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot.
Ugh, this is depressingly on the nose. As someone who loves choice in his software it's hard to admit that most people are beyond not caring and it is legitimately a negative factor for a lot of people to have to pick.
Yes, Slack borrowed some of the better features from IRC, which helped drive its popularity, but very, very few companies that are currently paying for Slack would have considered IRC to be a reasonable alternative.
Want to send a file to someone? Drag and drop, done. No hassle and it works for everyone, in the same way, without having to explain anything, use an external website, install a dependency, or change a setting.
Same as with Discord, these modern chat clients support richer content, have nicer looking UIs, better UX which draw more people in.
It's more fun to code bots for them because you can make them do amazing stuff, as the output doesn't just have to be plain text, but it can also be rich content like charts, embeds, propmts that can trigger multiple actions by selecting a reaction emoji, you get the idea.
Just overall a great, low friction and _modern_ experience.
* 24/7 presence, the reply was "you can do that with a bouncer"
* backlog, the reply was "you can do that with a bouncer"
* full text search, the reply was "that's up to the client implementation"
* file sharing, the reply was "it's already possible with XDCC"
and so on and so forth.
Basically, it's not that Slack is great, it's because IRC as a whole just refused to adapt to what users actually wanted/needed.
People only care if there's not enough resources.
(although, that's not technically true since irccloud does all the things you just mentioned)
Slack is a closed-source for-profit SaaS, ruled by a single benevolent company.
IRC is an open protocol-specification with a multitude of clients, servers and networks.
You couldn’t find better apples and oranges for comparison if you tried.
But we're talking about reasons people ended up choosing slack over something like IRC (or, really, any open protocol instant messaging specification).
The grand-parent comment raises good points, people want these things, being connected and reachable while not being connected to the server with any client and having a context later on. These are problems that can be solved but nobody has put effort into making a sexy product to do it. (and monetising that kind of product might be troublesome)
Again we are comparing a product to a protocol.
I’m just pointing out that this is not a reasonable comparison.
There were multiple web-enabled IRC bouncers (closed products) which would be easy to use for anyone, including non-techsavy people.
But evidently the majority of IRC-users were fine without that and preferred the traditional client-server-protocol realm.
It’s akin to comparing SMTP with chrome.
You have to include the clients and surrounding infrastructure.
Yes but then you're not using IRC, you're using IRCCloud. Its features are independent from the backend that is used; they could switch to Matrix or XMPP or a proprietary protocol for that matter, and the features would still be there. You can't expect the one you talk to to have IRCCloud and tell them "just search in the conversation history, it's there" because the protocol doesn't allow it.
The GP's answer is correct, Slack does a lot of useful things by default. That's why people like installing Ubuntu or even Debian but don't want to take time to setup an Archlinux or a Gentoo anymore: it's fun, but if I just want to do something other than tuning my install I'm not going to consider those distributions.
Now, the question is, does that mean that LFS or any bare distribution "lost" to, say, Fedora ? No, because they are meant for different needs. I'd say it's the same for IRC: it's best suited for people who are not interested in the full history and want to talk to people in a synchronous manner, people for whom text is a more than good enough solution and aren't necessarily interested in binary exchanges, people who like pseudonymity, etc
There’s no difference from this over using weechat relay.
All those clutches exist to support the deficiencies of IRC, which only proves the initial point: IRC in its current form doesn't do enough, and that's why Slack, with all of those features out-of-the-box, "won".
IRC The protocol is not competing with slack. The IRC ecosystem is. And yes, it lost.
In short, make the relay/bouncer part of the server itself, and tell clients to connect with the relay protocol, not the IRC protocol. If there were some common standard for this second part that would actually be a great thing.
And IRC is a horrible transport protocol because it handles errors by dropping messages. SMTP has both message-ids and explicit confirmation response to make sure that as long as server comes up, eventually, the message will be delivered exactly once. IRC does not; so it is simply not appropriate for the cases where each message matters.
It's obvious why Slack wins for businesses: Because it gives businesses greater control and legibility over their employees' work habits and decision-making. DCC or any other P2P connection is anathema to this sort of control.
Users want different things. They want both plain text and rich text, and similarly, they want both plain chat and rich chat.
Oh, and aside from all of this, there is a working group [0] which publishes proposals for modernization of the IRC protocol. Adoption rates are low, but perhaps that should tell you something about what users actually want.
I think it tells you that everyone who wants rich chat (which is most people, btw) already left for Slack or Discord.
I also use slack btw, and discord, and matrix too, so I fully understand the importance of a backlog, and having server caching for files is much more convenient than using an additional sharing site.
IRC is not perfect, but for what it does is pretty nice. Having a customizable backlog per-channel would solve most of the issues you have with reconnects and people's expectation. I'd love this backlog to be short by default though (<10m).
X/DCC is plainly annoying and it just breaks too often nowdays. Server assist, even for 1-on-1 sharing would be very useful. Sharing one image with a group of people while working on something is really, _really_ useful and having a common way of doing it that integrates with the chat is very helpful. Reasonable limits and auto-expiration (matching the backlog length or even shorter) would also be very useful.
We know what introducing file sharing does to a chat though. Instant memes pop up. I love how IRC channels look compared to all modern equivalents: just boring text, and minimal text formatting. If file sharing is added, I wished it would never be with inline formatting to keep it the same.
I don't care for search. Storing info in these chat mediums is a horrible, _HORRIBLE_ way to reference anything. Short backlogs are the only way to enforce people to store valuable content where it belongs. Searching through the backlog would then be no different than what irc clients already implement (simple look-back).
Keep in mind text-only chats are so compact that having a full day worth of backlog and downloading that from a cold-cache is still cheaper than getting a single inline animated gif. Just for reference.
I hate slack threads and how people tend to use them. I wished people would simply create ephemeral chats instead.
I find all matrix clients to be absolutely horrendous for exactly the same reasons. They become cesspools of memes and repository of information that are terrible to use. Honestly, the best way to use matrix seems to be gomux, or weechat via a matrix plugin, simply because these clients _ENFORCE_ a certain kind of usage that keeps the TEXT in the chat in the center. Sadly, both are incredibly limited. Cannot get ephemeral channels to work on weechat (which would be the "modern" equivalent of a query with multiple parties). Channel discovery is horrible.
But the backlog does help a lot for reconnections. So does the built-in file sharing.
It seems that the userbase of matrix has a different concept of what a chat should be, and that's why I still prefer IRC for now.
> Frankly, it reminds me a lot of XHTML vs HTML5. I buy all the arguments XHTML had, I like the vision it had for the internet. It also wasn't what actual end-users valued, and something that offered that won out because it provided more value, even if it didn't pursue the same vision.
The things that IRC is missing, as listed above, could easily have been added.
In my opinion, Slack has "won" over other clients because of UX: it's extremely easy to sign-up, understand, and use productively. Plus, even large orgs (ours included), can use the free version if they're OK with having chat history disappear after a few days/weeks.
I think another benefit to slack is you can come back to it and see the history. IRC is ephemeral unless you stick to a single device and leave it running. That's impossible for a mobile phone.
It frustrates me that some large projects (ex Ansible) who insist on all discussions there, and explicitly ignore things like GitHub issues.
It's always weird to me that IRC didn't evolve like email with something like IMAP.
As long as you pay the price.
And the kind of companies that value self-hosting will usually want this to be set up inside the company's internal network. So you'll have a bunch of firewall issues to get through, otherwise good luck getting your users to connect to some non-publicly-accessible server from their phones.
Other comments talk about how Slack nailed the UX for users to join a Slack workspace. But they also nailed the UX for getting a workspace set up in the first place.
(Well ok the whole idea of separate accounts per workspace thing is a bit of a mess, but they nailed everything else)
Have you used Hipchat or Lync?
just pointing out the desired level of control is possible with an IRC server, contrary to what the comment I replied to said.
IRC anope-style email verification simply requires that you are able to initiate a TCP connection to the IRC server. If you can do so, you can have a verified account. This kind of "public" is vulnerable to harassment as you describe.
Slack additionally requires an invitation by a workspace owner for all new users who wish to join, excepting only domains where the owner permits users to join without invitation using a special invite link. Anyone who invites harassers will find themselves under Slack's microscope as well. Owners who enable automatic invite approvals for e.g. @gmail.com or @throwaway.com that result in harassment can expect to find themselves banned by Slack and their Slack shutdown. While in theory this kind of "public" could be abused to some degree, it does not permit the 'anonymous' abuse that IRC's kind of "public" does.
If an IRC network was set up to require that existing users put their reputation on the line for new users, and in cases of harassment both the new and existing user were banned, then that would be a far more tenable system than what we have today. There's nothing that requires this to be unique to Slack. It just happens that Slack is willing to turn users away if they don't like it, and so as a result their network is baseline safer than virtually all IRC networks — such as Freenode.
“Reactions”, custom emoji, ease of integration (webhooks), and ease of signup are the things I hear quite often.
Regardless of that, Slack is a complete and easy to understand solution. IRC is a collection of unknowns where each user ends up with a different implementation and may not be satisfied with where they end up.