• No support for server-side history, and all that comes with that (usable mobile clients, offline messaging and push notifications to mobile clients, persistent presence in channels, search, editing/deleting messages, auditability, etc). Bouncers are a poor solution, as they aren't part of the IRC server and integrate awkwardly, if at all, with clients.
• No support for attachments. (DCC SEND isn't a solution; not only does it require direct IPv4 connection between users, but it doesn't work at all in groups.)
• Poor user authentication. Connection-time auth solutions like SASL are poorly supported; after-connection auth like NickServ is hokey. Support for federated (non-password) authentication is practically nonexistent.
• Short - and unpredictable - message length limits (typically around 500 bytes).
• Crude permissions system.
Why don't you grow your own food? Why don't you just write your own payment processor?
I used to think this way until I started a company with employees. My opinion on the matter changed almost instantaneously.
1. One does not simply set up their own "X". Setting up X takes time and you will also have to manage it, which also takes time (and is harder to anticipate when you are fully responsible for managing it).
2. As someone making decisions on this type of stuff (eg a founder, executive, head of IT, etc), maintaining something like X is a poor use of your time and not something you want to have to even think about. So you'll be paying for it anyway even when it's "free" by having an employee maintain it or sacrificing your own time on it.
3. You may trust yourself to be able to maintain it properly, but if you delegate it to an employee, the math changes. Now you have to hire someone you can trust to do a good job maintaining it and who is willing to do that kind of work. And you need to consider things like "what if that person quits/retires/gets sick" and "what if they get hacked or go rogue" and "what do I do when they go on vacation"?
4. Businesses have a lot more requirements of their communications software than just communications. If an employee loses a device or gets hacked you need to easily revoke access to everything, so you probably want to use SSO/an identity provider to make that easy. If you get sued you need to have a way to do legal discovery.
5. If you run into a bug or make a mistake, and introduce downtime or lose chat history, you just lost a lot of productivity or valuable info - operating things like this reliably is expensive, whereas having a support contract really reduces tail risk/provides peace of mind.
So if your option is to pay someone $10k for something like chat that Just Works (99.99% at least), and you are actually trying to build/operate a business and not just play around, something like $10k for chat can be an amazing deal compared to the true costs of doing it yourself. You pay someone some money and barely think/worry about it anymore, done.
Proprietary chat apps on the other hand go bad like cheese. When they start out there is a honeymoon period where they know they have to perfect onboarding because otherwise people won't use it, but once it gets a critical mass they fire the engineers and stop fixing bugs and keeping up with a changing environment.
The story is "want to try a meeting with Zoom?" and people would say "it's got to suck right?" and you'd reply "it works as well as Skype did 10 years ago" and then they try it and say "Wow!" but you know ten years from now it will be legendary that Zoom sucks and there will be something new that people are comparing to what Zoom used to be.
There ought to be a law mandating chat interoperability, Facebook Messenger could actually have a longer shelf life if you could talk with Microsoft Messenger because competition and the threat of exit would keep them on their toes.
For IRC I use Quassel which fills in all the missing gaps quite smoothly but it's on the user to set that up. Thus it's not for everyone.
At work we used to have irc servers around though because it allowed us to speak freely without HR constantly looking over our shoulders. But sadly the cybersec team hates these with a passion.
That fundamentally doesn't work on IRC, as it's message-oriented (like XMPP, which has some elaborate bolt-ons and hacks to implement history that actually work ok), not history-oriented like e.g. Matrix.
Also IRC doesn't store message history, which is kinda a really important thing.
Myself, I needed something IRC-like, which was open-source, and mobile friendly, so I tried Mattermost team server for a few years. What turned me off over time was that it required manual upgrades. I would have preferred something which was a nice, tidy Debian package.
Now I've turned to the prosody XMPP server instead, which is a standard Debian package (and now upgrades itself, if and only if, there are security problems, with Debian's "unattended-upgrades"). It runs on a $5US/month VPS. Setting up all the SSL stuff, and firewalling rules - as it uses multiple ports - did take a few days to figure out!
PS: A similar discussion around merits/demerits of IRC was recently on mastodon here: https://hachyderm.io/@miah/112649146585492861
I made a couple of related comments (WRT prosody, and Mattermost Team server): https://c.im/@sbb/112673859554591548 https://c.im/@sbb/112673727757562126
Slack, etc. pricing is a rounding error for most companies.
Emoji.
Search.
Pictures.
Screensharing.
Voice calling.
Video calling.
Web clients which can join video/audio calls.
Smartphone apps.
Push-Notifications.
Colours.
Embedded inline Office365 documents, in the case of Teams.
Meeting invites built-in to Outlook, in the case of Teams.
Click thing in Teams, opens in Edge browser with the Edge sidebar open to the Teams chat place where you clicked, for context.
Email notifications of things said in Teams chats.
Integration with company directory for looking up who people are.
IRC is for people whose reaction to those is to complain or sneer about how they don't want them.
It's the UI/UX you mention that seems to be the bigger blocker.
In my experience IRC was the preferred platform among software developers for a long time. Setting up a persistent shell and bouncer and managing your logs was common and preferred. It was how a good deal of the, small at the time, open source world ran (this is the 90's up through the aughts).
I recall that started to change when Slack and other alternatives started breaking into the market. A newer generation of software developers didn't care for IRC and the UI/UX around it. Open source, open protocols, free (as in freedom) software didn't matter to this generation.
And as management and executives got more interested in micro-managing developers we needed to include non-technical folks into our chat systems... which is where the UI/UX argument struck again: our friends in HR, management, etc couldn't be expected to setup their own irssi + screen client, log rotation, notifiers, etc; writing and hosting custom bots to integrate with systems became a chore and lost art, etc.
Now we have to run multi-gigabyte, resource hogging clients to post memes and emojis. But at least it's easier to administer and get folks on board. At the cost of all your data belongs to Slack I guess.
You do get a lot out of Slack than chat though. Forms, integrations, workflows, huddles, etc. It's a different ballgame from early to modern Slack.
I mean, you seem to understand what's wrong. IRC is meaningfully worse to use than Slack/Discord. So people use stuff that's nicer to use.
> but that could probably be fixed pretty easily and tacked on to the existing messaging infrastructure?
If it were easy, it would have already been done. "The UX isn't great" isn't a recent discovery, it's something that's been known for a very long time.
I regularly use two messaging platforms: Discord, and Element. The former is proprietary and the latter is open. Element is meaningfully worse to actually use. And it's still the best Matrix client I personally have used.
> The pricing for Slack
You've answered your own question there. Because "pricing" an open (as in RFC defined) IRC server is significantly more difficult than "pricing" a proprietary protocol.
So the "companies" follow the money, and setup their own proprietary silos.
Many s/w projects still maintain support channels on IRC.
The migration to proprietary support mechanisms isolates a number of users. Mozilla in particular is much more difficult to interact with since migrating away from IRC.
I've also worked for a company that ran it's own XMPP chat server. XMPP chat clients allow file attachments, see messages from times when client is disconnected (without a bouncer), integration of voice and video chat, whiteboard, etc. Pretty much everything slack, discord, etc offer.
This question is similar to why do companies use the cloud, when most of the time they could just run a server. My biased opinion: laziness. Mostly the laziness of following fashion instead of the technically superior solution.
Meaningfully FOSS communities are better served by Zulip or Matrix.
You can either lie and say it is (but get called it), try to change what IRC is for everyone else (good luck, the open servers don't want your features and consider lack of history a feature not a bug, but it is a "bug" from an enterprise perspective), or create something new out of the old system. Then you get Slack again.
Or you can make a largely from-scratch system (Discord) that resolves these problems from the start rather than trying to patch over something that doesn't actually do what you need.
Or you can try to make a new protocol (XMPP, Matrix) that tries to resolve these and hope people build compatible clients and servers and don't fork it in a way that breaks compatibility.
Whenever I sign up a new customer, they get a slack channel where they can talk with our team. By far the best way to do this is to connect our slacks. With anything else they'd have to log in to another system or download a new client which means it won't happen.
I would love to try any of the other open source improved chat solutions out there. But the network effect, alone, keeps me on a paid plan.
https://slimsag.com/2024/slack-to-destroy-history-of-free-co...
It really depends on your needs. IRC can work just fine, and all the "problems" become features. Decentralized everything, free choice of clients, extensible via bots, hosted or managed networks are available.
If you wanted to build your own chat thing, maybe base it on XMPP instead.
I would wager it is a generational thing also.
I don't understand what was wrong with Jabber.
IRC is akin to watercooler conversations: people who are around may hear what you say and they may join the discussion, but they don't have to. People who are not around are not expected to ever hear about the conversation (though a colleague could repeat it to them later).
When you talk to colleagues behind a whiteboard, you don't expect everything that was said to be recorded. At the end of the discussion, if deemed necessary, you take a picture of the whiteboard and/or write a summary that you save in a persistent place (typically you send the summary to the participants by email).
Now, in 2024, people (especially tech-savvy people, in my experience) have a hard time living with "old school" technology. "Why should we use email in 2024? Does IRC still exist, though it was invented before I was born?". The IRC UI/UX could have been improved a ton, but people have a different philosophy now. They expect everything to persist, they want official communications to feel like WhatsApp (or Snapchat or TikTok, depending on the age) interactions. Many people reaching university now don't know what a "file" is on their system: they just access "stuff" through "apps".
IRC fundamentally doesn't work like the modern chat apps that modern people are taught to use. You can't add threads to IRC and still call it IRC, because you will end up talking to people who don't have threads and it will break either your or their UX. You can't add reactions for the same reason, or history (because you will expect them to see all your messages, and they will assume that it is fine to miss most of them).
TL;DR: IRC is great, and I love it. Nothing is wrong with it. It is just not being used because that is not how (most) people interact anymore. It does not explain why modern chat apps seemingly must be poorly-written ElectronJS abominations, though. Probably it's cheaper to develop and users just don't give a damn.
Search: half-remember some conversation from months/years ago? It's right there, in the app.
Persistent history: onboarding a new employee? All of the company's past communication is there to browse and search (see above point).
Inline file attachments: need to share a small file or a screenshot with someone? Drag it into the app and they can get it at their leisure. No need to mess around with DCC send or uploading to Google Drive and sharing a link, it's right there.
All of these could be solved with IRC (in fact, Slack was initially built around IRC) but they require extra infrastructure and tooling and development to make it seamless, and that takes extra development and hosting costs.