I remember the early days of Twitter. It was great, as there were many different clients, both native apps and web-based ones. There was lots of innovation in the ecosystem and, in fact, the ‘pull-to-refresh’ feature that’s now baked into every social app on a touchscreen device was first created for a third-party Twitter client.

Twitter then, of course, once it had reached critical mass and mainstream adoption, killed off that third party ecosystem to ‘own the experience’. It looks like Slack, the messaging app for teams, is doing something similar by turning off support for IRC and XMPP gateways:

As Slack has evolved over the years, we’ve built features and capabilities — like Shared Channels, Threads, and emoji reactions (to name a few) — that the IRC and XMPP gateways aren’t able to handle. Our priority is to provide a secure and high-quality experience across all platforms, and so the time has come to close the gateways.
A number of people weren't happy about this, notably those who rely on the superior accessibility features available through IRC and XMPP. A software developer and consultant by the name of JC Brand takes Slack to task:
We all know the real reason Slack has closed off their gateways. Their business model dictates that they should.

Slack’s business model is to record everything said in a workspace and then to sell you access to their record of your conversations.

They’re a typical walled garden, information silo or Siren Server

So they have to close everything off, to make sure that people can’t extract their conversations out of the silo.

We saw it with Google, who built Gtalk on XMPP and even federated with other XMPP servers, only to later stop federation and XMPP support in favour of trying to herd the digital cattle into the Google+ enclosure.

Facebook, who also built their chat app on XMPP at first allowed 3rd party XMPP clients to connect and then later dropped interoperability.

Twitter, although not using or supporting XMPP, had a vibrant 3rd party client ecosystem which they killed off once they felt big enough.

Slack, like so many others before them, pretend to care about interoperability, opening up just so slightly, so that they can lure in people with the promise of “openness”, before eventually closing the gate once they’ve achieved sufficient size and lock-in.

I’m definitely on the side of open source people/projects here, but it’s worth noting that the author uses the post to promote the solution he’s been developing. And why not?

There’s a comment below the post which makes, I think, a good point:

I'm betting this decision wasn't made by the same folks who were at Slack (or Facebook, Google, etc) and thought adding support for the open protocols was a good thing. I bet the decision is a product of time over any attempt to trick anyone. Over time people change roles, leave, and slowly new leadership emerges. Outside pressures (market growth, investors) require a change in priority and the org shifts away from supporting things that had low adoption and ongoing maintenance cost.

So I don’t think it’s as malicious as the author implies (Bait and Switch) as that requires some nefarious planning and foresight. I think it’s more likely to be business/product evolution, which still sucks for adopters and the free net, but not as maleficent. Just, unfortunately, the nature of early tech businesses maturing into Just Another Business.

Indeed.

Source: Opkode