IRC is terrible for work collaboration. I say this as a long time IRC user. Conversations are not searchable, and if you're offline you are unable to follow along with what's going on with your colleagues. To make it anywhere near usable, you need to run IRC bouncers, chat loggers, search indexers .. at that point, just use something made for collaboration.
1) IRC doesn't support any form of message threading. There's some user conventions like "username:" or "@username" to direct a message to a specific person, but there's no way to make a clear distinction between multiple conversations in a channel. (You can make a new channel for the conversation, I guess, but that's even more hostile than usual to other users trying to follow along.)
2) IRC doesn't support messages longer than ~400-500 bytes. There's an internal hard limit of 512 bytes per line in the IRC protocol, and part of that gets silently consumed by fields like the server hostname and channel name. If you try to send a longer message, it's silently truncated. (Your client will probably echo it back as if it all went through, but other users will see it truncated.) Trying to discuss anything longer than a single line of text typically requires users to post it to an online "pastebin" - adding another external tool you need to make IRC work.
3) There's no reliable, standard way to transfer non-text content on IRC. DCC is unreliable, slow, requires one or both users to set up their firewall to allow incoming connections (!), and only transfers files to one user at a time. All of this combines to make IRC incredibly awkward for discussing audiovisual content, like graphical designs or audio/video. Sure, you can upload screenshots or videos to another web site and post links to IRC - but that's yet another external tool you have to bring in.
4) User authentication and authorization in IRC is incredibly crude. The protocol is built around the understanding that users can change their username at any time (!!), with systems like NickServ bolted on after the fact to "protect" names. User permissions are tied to a user's presence in a channel; private channels are implemented with a single shared password. All of this is "good enough" for a lot of social IRC networks, but completely unsuitable for a business setting which demands a higher level of assurance.
I see only the 4th point as a real problem, which could be solved by fragmenting the network more, like connecting a server to it and not connecting the user directly (UI must reduce the visual noise of netsplits that should be a lot more frequent this way).
The other 3 are UX matters, 2nd point cracks me up because hexchat could split a message in batches of privmsg's eleven years ago, spam control is totally local (so being banned for spamming isn't a given), servers can nowadays buffer a lot of text and throttle messages, albeit bandwidth is mostly free.
Being them UX matters, they aren't worth much, thus IRC will remain broken because there are like two thousands IM competing software that dealt marvellously with those problems.
1-3 are features. Keep chat messages short. Use git or NFS for sharing files. 4 can be solved by putting the server behind a VPN that does better (2FA) auth and then custom NickServ backed by your auth
100%. No need for bouncers, search indexers or chat loggers.
Real time communication should be used for real time communication. Send me an email if it's async, or call me if it's urgent and I'm not available via normal RTC channels. People want Slack etc to be an everything client, which is why we have the gross bloat we have.
Also, you spend a day off and if the channel is active, it's a chore trying to get back on track if the team does not have better suited communication methods. Quasi real time discussion on a bug is great, but it's better to add the final findings on the ticket/PR. Same for features, draft up a doc afterwards. Slack and the lack should be considered transient and important information put on more permanent and more brows-able forms (Wiki, document repo, ticket system,...).
It’s not a feature. People use it this way and expect a history and search feature. It’s the way it is. Not providing a feature is not a feature. It’s an inconvenience at best, and a lack of respect at worst when you present it like people are doing it wrong.
I was sort of on the fence for whether to keep using IRC, for years. I used to have Trillian and later Pidgin as a multi-network chat client, and when using one of those, it makes perfect sense to idle in IRC channels. Then the networks got so complex that multi-network clients no longer worked, and now everything sucks and I have to open 3 different browser tabs (Google, Slack, Discord) on my workstation, iPad, laptop, etc to keep up with what's going on with my work clients, and remember not to close them. Even with the mobile apps, messages are often delayed or don't generate proper notifications.
Without a doubt, the modern era is worse than the experience I had in the 2000s. But, it's true that threaded conversations make it easier to collaborate. Email and voice calls used to work fine for that, though.
Meanwhile, I discovered https://thelounge.chat/, and since I have to open too many browser tabs already, what's one more? I'm pretty happy with it. It fills in the missing features of IRC like sending files and images, and being a bouncer.
IRC is brilliant for text minded development tho. Hanging out in an irc channel, you're likely to see most people just idle their clients with screen or whatever. I've seen project channels simply publish logs of the chat, and every client I used could log text. Private channel creation is trivial as is messaging.
I have only been able to load a discord "page" or whatever maybe once or twice so I don't know if discord style chat is better or not. IRC I can run on a potato lol
I find IRC to be easier to search than the alternatives. I can use standard grep and regexps on my logs, sometimes logs from multiple channels at once. While many other services only support substring or word search, with their custom dialect for time boundaries or author matching; and are slower due to scale.
If you start a company and spend a non-trivial amount of your time, effort and money into handcrafting and customizing a perfect IRC server, that company is going nowhere.
If you know IRC well enough to want to mandate it for your company, you can probably set the server up in an hour or three. You can then install https://thelounge.chat/ and have your employees log into that for browser and mobile apps vs. native IRC clients.
What money would it require? Any leftover PC from the last 15 years can run the server.
Aggressive delegation to third parties is how we end up with all these complex services. A chat system, a ticket service, a git interface, should be pretty trivial to install and maintain. And consistent too.
Worked at Red Hat, the amount of anger around decommissioning our internal IRC servers was HUGE (and hell, even then, half the company was using/happy with GChat, the other half on Slack. People who actually paid attention to both were very minority).
Loved having IRC at Red Hat from a nostalgia perspective but it was a total disaster from a business standpoint.
Also, at red hat, we’d complain to the whole company about paper towels vs air dryers in the bathrooms, so naturally the complaints about losing IRC would be expected! It’s refreshing to be at a place where I can make a decision without getting second guessed and derailed by someone totally unrelated to what I’m doing.
Worked at a few places that did just that. One used SIP phones for actual voice chat. Liked it very much.
To respond to the sibling comment: we had text files on a share that we could actually grep. Far better than the inexact, incomplete search functionality that seems to have become normal these days.