So corporate users can set up an IRC server; a network of per-user bouncers for offline state maintenance; an internal file hosting network for uploads; a bunch of server-based logging stuff and a central search repository to check history; train every middle manager to be an IRC server admin in order to add and remove people from channels for new projects; somehow intervene to disable DCC and other methods users could use to circumvent server-side logging; maintain their own fork of an IRC client in order to implement inline code, images, website previews, etc; break IRC's protocol in their client and server to allow text in excess of the maximum line length; and separately find a SAAS video/audio chat vendor or roll their own...
... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.
They could easily pay someone else to handle all that stuff just like we do with HTTP servers. We're not talking about the service, we're talking about the protocol.
> 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.
... all to save $7/month/person (or less for some competitors like MS Teams) because Slack is, like, too proprietary.