There's a newish (last few years) "team communication" platform called "Slack" that most tech (and many non-tech) people use to communicate in asynchronous text, images, voice, and video in business teams - particularly geographically distributed teams - and increasingly, in various communities of interest, many of which are globally distributed. If you haven't seen it, think of it as the all-in-one successor of email, video calls, and text messaging.
The reason many groups use Slack is because they've made it relatively easy to sign-up - at no up-front cost - to create a "Workspace" for their company team or community. Slack is well known (heavily marketed) and the expedient choice for many.
IRC - more open, but not equal
In the past (and even now) some more hard-core techie groups sneer at Slack, preferring the more traditional (and fully open source) Internet Relay Chat, or IRC, technologies. As someone who's used both IRC (for a couple decades) and Slack, I can tell you they're not equivalents, particularly not for non-technical users.
To give you some idea of what I mean:
- Conversations in IRC are not persistent unless an individual participant sets up an external system to record them (it's not baked into IRC). By default, conversations that go on while you are not logged in are missed altogether and are irretrievable (short of someone else sending you their recordings).
- IRC is text-based - there's no multi-media presentation - no images, no website pre-fetches, no video or audio snippets, and even emoticons don't work on every client.
- It's not as easy to get useful info about other users or engage as easily in direct messages (and have those communications retained for historical reference).
- IRC doesn't integrate video conferencing.
- If you're mentioned in an IRC conversation when you're not participating in the conversation, you're unlikely to get any notification (email, sms, etc.) alerting you to that fact.
- IRC makes it more cumbersome to attached files for conversation participants' reference.
- You can't as easily search the entire corpus of past conversations and find references to important bits of discussion after the fact.
- It's harder to participate in IRC via mobile devices - the user experience just isn't as polished.
- Unlike IRC, with a rich messaging system like Slack, you can even reference specific posts via URL.
- Like IRC, there're a rich means for integrating external systems with it using "bots" among other things (although I'm not sure about how up-to-date IRC APIs are)
Until recently, with Slack, you could even integrate "legacy" IRC with the channel - yes, the Slack "experience" is far more polished, graphical, and most users would say "user friendly". Moreover, even though conversations are persisent - you can (usually - more on that below) go back and see what you've missed - you can participate in the conversation from nearly any computing platform (stationary or portable) in use today.
Proprietary Bites
Recently, however, the leadership at Slack, which is a proprietary product by a Venture Capital (VC) funded corporation, decided it wasn't in their interest to continue allowing integration with IRC systems.
Many organisations and groups used this integration to allow people (particularly old school technologists), who preferred freedom and proven open source tools over this closed Slack upstart, to participate, at least to a minimal level. But no longer - Slack unilaterally put the kibosh on that.
Another interesting fishhook in the Slack business model is their "freemium" service - by far the majority of Slack's "customers" use the service at no cost. This gratis offering has some (not very well known) restrictions. At the time of this writing (of course, it's all subject to change at Slack's discretion) free channels are limited to 10 integrations, but the most important limitation is that free channels are limited to a history of 10,000 messages. Any messages older than the most recent 10,000 "fall out" of the channel's archive. They can no longer be referenced, or found in searches. I understand that private Direct Messages between channel participants also count towards this 10,000.
What this means is that many communities - particularly those coordinating open source software projects (among other "open" endeavours) - who would never be able to pay the current Slack "premium" per-seat prices of USD8/month per user (discounted to USD6.67/month if you pay a year in advance) to preserve their full message archives - are quietly losing their community histories: their accumulated conversations and collective decision making. This is a tragedy I suspect few will recognise until after it's too late.
There are other proprietary competitors to Slack - Discord, Microsoft Teams, Yammer, and others - they all suffer most of the same disadvantages, depending on their current business models (which, of course, can and do change on a whim of the business).
The Free and Open Source Slack Alternatives
One thing Slack has going for it that many would-be competitors don't is a "wad of cash" to spend on marketing. Most people working in tech have at least heard of Slack. Far fewer realise that there're are a bunch of quite advanced "rich messaging platforms" that are entirely free and open source software (FOSS). Mattermost, Rocket.Chat, and Zulip are three of the most advanced integrated messaging platforms, and each has many integrations and client applications for various computing platforms, just like Slack. Even more ambitious is the Matrix project, which has defined an open rich messaging standard, with its Riot client and Synapse reference server.
While none of these FOSS contenders has the financial resources or "mind share" of Slack, all have thriving communities coalescing around them. All have full suites of client applications, integrations with a huge array of external services and tool chains, and all are advancing and improving at a breathtaking pace.
Like Slack, many of these FOSS contenders can be purchased as "Software as a Service" offerings, however, unlike Slack, they can also be self-hosted or hosted by a trusted 3rd party provider- because they're FOSS, anyone can set up their own "instance" of any of the FOSS options. What's more, the FOSS options don't tend to place arbitrary limitations on what their users can do, with which services they can integrate, or how much messaging history is stored, and they are unlikely to issue capricious fiats like Slack's "no more IRC integration". If one of these FOSS companies, say Rocket.Chat, did... the community who valued that feature could simply fork the Rocket.Chat codebase and continue on like nothing had happened, and the Rocket.Chat company would have to compete... against its own older code, but updated to have the features that its users most want...
Slack's Lead is Narrowing
What's more, these projects recognise Slack's current pre-eminence in this space. They combat it using the "wrap around" integration model - they allow their services to "bridge" with Slack channels, making it possible for users of their service to participate fully in Slack channels without ever using Slack directly.
I have developed substantial experience using both Slack (due to some of the open source communities in which I participate selecting that as their community messaging platform) and Rocket.Chat, one of the FOSS alternatives. Having used a variety of clients for both Slack and Rocket.Chat, I find them on a par for most purposes, and each is better than the other in some circumstances. Of course, being open source, the Rocket.Chat options are improving at a remarkable rate as an increasingly large community of users lend a hand to improve it. My own humble contribution is this "Howto Implement RocketChat with Docker Compose" post (not only does it help you install the full Rocket.Chat stack on USD5/month commodity hosting in an easy-to-maintain way, suitable for hundreds of users, you also get Wekan in the bargain if you want it).
Based on my experience with other FOSS rich messaging platforms like Mattermost and Riot, it seems that many of them are doing very well, building vibrant open communities around themselves, which is all they need to achieve "critical mass" and eventually gain (and maintain) parity with Slack and one another. Because of their "integration-friendly" nature, these FOSS contenders will each become crucial to parts of their community who have invested a lot of energy in their integrations and workflows which depend on those technologies, and they'll be a far more reliable "free" partners than Slack, who based on their corporate nature, and recent past practices (the aforementioned IRC integration ban), will likely pull the rug out from under those who've come to depend on them, for better or worse. I assume that Slack's business model is to get large swaths of the software development world (both open and closed) to develop that dependence on them, and then to "monetise" that relationship by starting to reduce the scope of their free tier, and leverage the sunk cost of these many independent entities to compell them to start paying Slack monthly per-user fees.
Network Effect? Nope.
Many open communities, when capitulating and opting to use Slack, claim: "it's where people already are". They're implying it's a "network effect" platform like Facebook, Twitter, Github, Disqus, or Meetup.com... yet, strictly speaking they're mistaken.
Network effects come from the idea that the value of being part of a network increases as more people join the network... And that's not what Slack is. Every Slack channel is it's own independent network. Slack does not benefit from the network effect.
There's an overhead to every new Slack channel that one is invited to join: the need to create a new user (unrelated to any previous users), a new password, and a new persona. The only practical advantage to sticking with Slack is that users already using Slack don't have to download/install new apps if they don't want to work within their browser. That's a fairly marginal advantage.
Open communities opting for Slack fail to realise that, by choosing to join their community, participants are buying into the communication systems that community uses. As such, communities have both the opportunity and the obligation to select a suitable communication medium for their members - that selection frames that community's discussion and sets subtle but very clear expectations about that community. Is it culturally pure and consistent, or is it muddled and pragmatic (at the expense of its principles)?
You don't encourage open by choosing closed
As I've said many times before, I always feel very sad when I see communities that champion "open" - open source software, open data, open government, open standards, open educational resources, open licensing - adopting Slack. The reason is described by one word: prefiguratism - I defined it in a previous blog post. Simply put, prefiguratism says that you best achieve your ultimate aims - and create a robust, well aligned culture - by using means compatible with those aims. So just like it's hard to, say, use privilege to achieve equality, or bombs to achieve peace, it's difficult to achieve openness using closed tools. Put another way: expedience is the enemy of principle.
Given the incredible (and rapidly improving) FOSS rich messaging platforms now available it seems to me to be painfully jarring for any open-focused community - particularly those with a technically capable membership - to adopt Slack over one of those open platforms. Seems inappropriate to me that, to participate in a community dedicated to increasing openness, one has to accept Slack's proprietary software terms and conditions and the privacy and freedom impositions that entails... The more those of us in open communities encourage the adoption of tools that implicitly support our goals, the more rapidly they'll match and surpass their closed competitors, in every way.
Update 2018-04-27: today, I heard that France's government has decided to adopt Riot + Matrix as its standard internal government chat platform. And I understand that the Canadian government is testing Rocket.Chat...
Update 2018-05-02: another open community's tale-of-Slack-woe-and-misery.
Update 2023-09-21: since writing this essay, we've spent a lot of time using and maintaining our own Rocket.Chat systems. At the time I wrote this, I thought it was the most mature of the options, and as I said, Matrix was far more ambitious in the communication problems it was trying to solve and wasn't sufficiently mature to be compelling. That has since changed. For the past year or so, we've been running our own Matrix server (Synapse) and Element web client (I also use Element and Schildichat on Android, both excellent) which provides amazing functionality. It is also fully federated, meaning that people don't have to join our server (i.e. log into our instance) in order to participate in our rooms - they can use any other Matrix account. We have video and audio calls set up, plus proper end-to-end encryption (which is why law enforcement around the world is adopting it over the proprietary alternatives).
Add new comment