Zarf Updates

I sent this message to feedback@slack.com today.

I saw yesterday that you are planning to discontinue your IRC and XMPP gateways. You are making a mistake. You should keep supporting the gateways.

That's the one-line summary. You want to keep reading?

The gateways are a valuable feature and they make Slack more valuable to users. Yes, I'm sure you have charts showing how few users connect through the gateways. And yes, the gateways can't keep up with your shiny new Slack features. But those of us who use the gateways, use them because we like them! They let us Slack in the ways that we get work done. If they vanish, Slack turns into a second-best service.

I don't despise the Mac Slack app. I have it running right now. But -- sometimes I shut it down. This is how I use Slack: a few high-priority channels in my XMPP client, and the Slack app for everything else. The XMPP client is always running; it has my most important chats ganged together in one tidy window. The Slack app is different; it's a busy free-for-all that I peek at when I have a few free minutes.

Today, Slack supports this. I can direct channels where I want them on my screen. It's flexible and it fits me. But you're telling me that in two months, I lose that flexibility. I won't lose access to my chats, but I'll lose the ability to read them how I want.

That's bad. It is a mistake.

Flexibility isn't the only issue. On your explanation page, you say you are "focused on making Slack accessible to all people". Good! Please keep working on that. But then you admit "these changes are just the beginning of our accessibility journey." Doesn't that mean you should keep supporting the mature technologies that people already use?

Similarly, the "creative integrations" you mention. It's great that your APIs support some users' needs. Probably even most users' needs. But that's not an argument for cutting off the standardized mechanisms that people are already using.

Honestly, I think you know this. Your explanation page is written with a tinge of defensiveness. "We're hopeful that [tech] will meet the majority of your needs..." ...but you know it won't meet all of them. Yeah. Your only actual argument for removing the gateways -- as opposed to apologies -- is "to provide a secure and high-quality experience across all platforms." Look: taking away a user's current platform doesn't improve their experience. It is a removal. It takes away the experience they want.

At this point you maybe want to bargain with me (and people like me). You want to say "We'll keep running the gateways for another six months -- or another twelve months -- until Slack's accessibility and APIs are good enough. Then we'll shut them down for real."

No. Still wrong.

There are plenty of web services which demand total control over how users use them. (Think of a little blue bird.) That's their brand; they protect it fiercely.

(Twitter may not block third-party clients, but it sure wants to discourage people from using them.)

I would like Slack to not be that way.

I would like to be able to use Slack however I need. No offense to the emoji, but I don't need emoji to get work done. Slack was valuable before the reaction tags, before the threads, before the shared channels. (I haven't even looked to see what "shared channels" are.) Slack was valuable because it was a simple stream of text messages shared between people. I still use it that way. And that's exactly the format that fits into the XMPP/IRC model!

It's also, by no coincidence, the format which is maximally accessible. A simple linear stream of text messages can be translated into any user interface and any platform -- mobile, audio, you name it. Morse Code if that's your kick. You can pile on all the extra features you like, and yes, a lot of people will use them. Sometimes I will use them. But some people -- maybe, now and then, a lot of people -- will stick to the simple linear stream, because it suits their technology and their needs.

Slack has to keep supporting that simple use pattern. For accessibility, for portability, for flexibility. And if it supports that pattern, it can support IRC/XMPP without much hassle.

That's my argument. Thanks for reading.