Over the past decade, we have seen a shift that caught many long-time computer users and developers off-guard: The advent of apps. Up to ten years ago, there was a clear trend of distributed applications becoming webapps, and the browser was seen as the new universal program delivery interface. And, as I will explain, we now see yet another quite popular webapp, Slack, closing their interoperable, standards-adhering interface to further trap users into their controlled ecosystem.

Quasi-real-time message exchange, both via shared and private channels, has been an integral part of the set of services offered on the Internet for a very long time. The Internet Relay Chat (IRC) introduced in 1988 a network of both public and private instant messaging, with worldwide reach, allowing for thousands of simultaneous online users. Close to ten years later, as media-richness grew and the ways users interacted with computers, a much revamped extensible protocol appeared — the Extensible Messaging and Presence Protocol (XMPP). Both were developed as Internet standards, being analyzed and published as IETF RFCs, allowing for the appearance of numerous interoperable implementations, both for the client and server components.

In the late 1990s, several proprietary applications (with their corresponding protocols) also appeared in the same arena. The most popular worldwide at different points in time were Mirabilis’ ICQ, AOL’s AIM, Microsoft’s MSN. They all had their heyday, but nowadays they all share the fact of having faded away in their usage and abruptly died when their parent company decided they were no longer worth the expense.

Federated services

There is an important point to keep in focus when discussing IRC and XMPP: Both were developed from their onset with the clear design goal of creating federated communications networks. Users can connect to different servers and have their messages relayed to users connected elsewhere. The way this is done differs by protocol: An IRC network is structured as a set of independent servers, and users connect to any of those servers they want. Even more, users don’t usually even care to which one they connect. They connect to a generic address spanning all of them). Their nickname is a globally unique identifier in a network.

For XMPP, the concept of user accounts appeared. This allowed a user to receive messages even while not connected, and the server delivers those messages when they connect again. This, of course, requires a user to have a persistent identity associated with a specific server. But all intercommunicating XMPP servers forwarded messages to their specific users, those who have an account in the specific server in question. Again, XMPP allows for the federation of services into a larger network.

Perhaps the most successful media that can be used to describe federation is the good old e-mail protocol, SMTP (according to its Wikipedia article, e-mail has been used since the 1960s, and the basics for SMTP date from 1982). It does not matter which company you or I use as our e-mail service provider, or even if any of us run their own service, we will be able to exchange messages because it runs on a standards-based, federated service.

Enter the era of social networks… And of walled gardens

By 2004, today’s big social network companies started appearing, and very quickly gained presence among the Internet users. While during their growth periods both Google Talk and Facebook Chat adopted XMPP technology. After some time, both removed first some features from it — most notably, of course, the federation ability. This limited users to communicate only with others using the same service, and eventually, they completely abandoned XMPP in order to have full control of the platform. This relates not only to the message delivery, but also to the appearance and full user experience it had on the client side.

We see here the appearance of a worrisome trend: walled gardens getting gradually closed — A migration from an open platform towards a software system where the service provider has full control over applications, content and media.

Out of the personal, into the project

It should surprise nobody that communication networks are picked as work-enablement tools. This idea was pushed already in the late 1990s by ICQ, who offered a version of their client to be used within a given corporate network (and without the distractions of unrelated friends’ chatter). Several other similar offers have
appeared and faded over time.

A year ago, at the 13th International Conference on Open Source Systems (OSS2017), I attended Megan Squire’s talk, Considering the Use of Walled Gardens for FLOSS Project Communication. Her research digs into how different FLOSS (Free, Libre and Open Source Software) projects have adopted communications in walled gardens for different reasons, and how this resonate with their record of technological openness, inclusivity and diversity. I won’t try to summarize her article, as it’s a short, easy and interesting read by itself. It shows how particularly one walled garden has become dominant over many different projects: Slack.

Over the last couple of years, I have also noticed that trend. While the projects I most identify with and collaborate in have kept their traditional communication media, but I have found important groups that have really surprised me switching over to Slack.

Groups that have historically valued openness of implementation, such as specific areas of the Internet Engineering Task Force (IETF, the organization that has driven most of Internet’s standard-based technologies). Organizations that are committed to openness and access, such as Creative Commons, have mainly argued their switch to Slack with their sub-goal to attract non-technical users, which is considerably more difficult over IRC.

Further, the ACM XRDS’ official synchronous communication channel is also Slack — Of course, this does not mean the ACM endorses or favors Slack as a technology, aligning it with its goal to “advancing computing as a science & profession”, but only that, pragmatically, it provides a smooth team-working technology for its internal workflows.

Embrace, extend and extinguish

Slack has long made clear the prime experience is only achieved by using their official software. Nevertheless, one of their features has so far been a great gateway implementation (protocol translation systems of sorts, which allow to follow or take part in Slack spaces via IRC or Slack), with which projects could choose to provide a mirror of their working spaces to people who prefer said protocols. It is one of the best inter-protocol gateways I have seen so far. Of course, I am among that group of people. Do note, IRC die-hards have opposed the Slack trap for several years already.

Some weeks ago, however, Slack announced to their users that on May 15 this year, they would shut down these gateways. It greatly disappointed me, because it represents yet another edition of the dreaded “embrace, extend and extinguish” strategy of basically all companies that have managed to get a technological monopoly. What we, as the proponents of Free Software, have fought against for so many years: The ability of use whatever tools best suit your personal use case. The ability to develop, to improve, to bring tools into our personal workflows, instead of having to adjust our mindset to what an external master decided is best for us.

So, starting next May 15, I will no longer be active in any Slack workspace I have used. While I am in no position to call for a boycott, I do call you to think about the compromise to which Slack forces us, to consider what are you and your projects giving in exchange for their tools, and how far away they are from open, standardized ways of communication.