Slack has recently begun phasing out their IRC and XMPP gateways, indicating that:
[We] can make no guarantee about the security of any IRC/XMPP client (including transport encryption or data security).
along with the statement that it is not possible for them to maintain feature compatibility of their application across these various protocols and transports.
This seems to be a recurring theme amongst startups that provide messaging as a service: launch with as many 3rd party, open-protocol integrations as possible, and then once they've locked in enough traction/users/funding, slowly shut down or cripple external integrations1.
This barrier-building is gradual enough that, on each new announcement, a vocal few put up a mighty ruckus, but the vast majority of users silently accept the new norm: it doesn't affect them directly, or because it's a minor inconvenience that they can bypass easily enough (e.g. they can "just use the app" instead)2.
This kind of shift is rarely an isolated, one-time event.
Slack has great incentive to ensure that its users remain completely ensconced within their ecosystem. Giving users options on how they connect to the Slack service dilutes the experience they have carefully curated, and is perhaps not in their best business interest, even though it might be in the best interest of some of their paying users3.
Right now it's the infrequently used IRC/XMPP integrations that are getting axed, but perhaps in the future there will be limitations imposed upon their Events or RTM APIs that gradually affect the number of 3rd party integrations other than those blessed by Slack. It's happened before.
An analogue to this approach exists in the realm of political theory: the Overton Window. By iteratively enacting changes on the fringe of acceptability, one may move the window of dogmatic currently accepted policy in the direction of what is considered more controversial.
While comparing Slack's gateway integration changes to shifts of political freedom is alarmist (and extreme!) in nature, it does illustrate a point: with a gradual, perturbative approach, seemingly radical and unthinkable changes can be foisted upon almost any currently accepted norm.
Slack is, of course, free to do as they please. They are not a shadowy government attempting to slowly upend a democracy; they're just a technology company, and their primary goal is to make money for their investors.
It's just good to remind ourselves of that fact, from time to time.
I'm half-expecting Google to start shutting down POP and IMAP integrations for Gmail in the next few years. While both POP3 and IMAP are terribly old, insecure, and woefully under-featured for how we've come to use email in this decade, they both remain some of the most widely adopted and deployed protocol standards in the world. I can pick up almost any email client application that has been written in the past 20 years, and still be able to read and reply to email delivered to me via Gmail. To me, that's more empowering than any Gmail-only feature that I've lost out on by not using their bespoke API.
While they are shutting down the XMPP and IRC gateways, their HTTP-based Events API and websocket-based real time messaging (RTM) API are, as of now, untouched.
Some people would rather avoid running a browser tab or Electron app that takes up gigabytes of committed RAM, and don't really care about gifs and emojis.