This is another argument against using proprietary SaaS solutions for such crucial purposes as business communication. There are free open source alternatives which give you full control and privacy: Mattermost, Riot.im, Rocket.chat, Let's Chat.
In >15 years what I have seen is that OSS comes with a huge cost of attention - that you'd be better off focusing on your business need.
Running most of these OSS even at a medium employee count scale is a full-team-commit-nightmare. It essentially means your it department now needs a specialist who will be able to handle your org quirks, remember the tweaks and keep baby sitting it. Not to mention many OSS teams (I don't know about the above listed) are ever so sneakily introducing enterprise clauses about usage in their EULA.
I don't want to name names, but even with paid software we are seeing this problem everywhere in trying to host: But at least here, we got the actual developers and experts on a call who can walk us through why x employees are fine and x+1 nukes their system.
This is what happens when you over-engineer things.
IRC is not perfectly good or it would still be used.
IRC doesn't do that, true, but there's a bunch of ways around it.
> saves history, has notifications, search
Trivial to implement in the client.
> IRC is not perfectly good or it would still be used
IRC is still used. Almost everything any fancier messaging protocol does can, and has, been implemented as a client-side feature with little hassle.
... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
> maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc
These already exist. No need to maintain a fork unless you want to add features that don't exist in it. And since IRC is so trivial a protocol, that's not even hard.
> break IRC's protocol in their client and server to allow text in excess of the maximum line length
You don't have to break shit. Just split lines into multiple messages and piece together messages from the same user when they were also the last one who said anything, or use a character that means "message continues", or any of probably a dozen other ways you could implement that on top of the already existing protocol and that will still gracefully degrade on clients that don't support it.
I'm not saying that a service that takes existing ideas and makes them easier for people to use is bad, I'm saying that the open protocol people are calling for already exists, but because they have tech-brain they'd rather build a completely new protocol because it's more fun.
[0] Not literally, I have no idea what it uses.
Edit: spelling
You can use paid services, or not. It's up to you, but they all interoperate.
That’s not even wrong because nowadays almost all software comes with some OSS contained. So the non oss set is basically empty. I wonder if HN comes with a huge cost of attention because it runs on some OSS lisp?!
It's about how the service handles change (e.g. options to use the old interface etc.) that make the difference and not open source or proprietary.
There are many examples in FOSS that made user interfaces arguably worse and you have a hard time dealing with it, if you still need/want to run the newer version for other reasons.
In an open-source thing, with this sort of productivity-harming breakage, you could worst-case just pay a random freelancer to fix it for you. You don't have that option with Slack.