Slack smackback: There’s no IRC in team (software), say open-sourcers

Open-source software is not possible without collaboration and collaboration is not possible without communication. Collaborative communication in open source projects typically means some form of distributed chat.

In the past, and indeed the present for most projects, that has meant IRC. IRC has some disadvantages, though, and developers love a shiny new toy, which is part of the reason more than a few projects have moved to Slack, the startup attracting crazy amounts of venture investment and equally crazy valuations.

While there is nothing wrong with Slack – in fact it’s insanely good at managing and organising distributed conversations – Slack is not necessarily the best choice for open-source projects.

Indeed this is not the purpose of Slack. Slack’s intended use is to provide a single dashboard or app for all sorts of different communication tools - email, chat, Twitter and more.

Slack is not primarily for public chats. The company itself discourages this use case, which should give large open-source projects pause. But more to the point, Slack is closed-source software controlled by a single company. It’s the antithesis of open source.

In effect, moving from IRC to Slack means replacing an open protocol with decades of open source client software development and a robust distributed system for a single point of failure. Again, not to disparage Slack.

Some in open source have spoken out against Slack as a replacement for IRC, notably Drew DeVault, whose post “please don’t use Slack for FOSS projects” made the rounds in programming circles a few months back.

According to DeVault: “Slack is not a tool built for open source projects to use for communication with their userbase… It’s a tool built for teams and it is ill-suited to this use-case.”

There are essentially three problems with IRC that Slack and its imitators (more on those in a minute) solve. First, creating an account is easier. Enter an email address and password and you’re done. Slack is also already widely used; there’s a good chance a significant portion of developers looking to contribute to any given FOSS project are already using Slack elsewhere.

The second thing Slack offers is built-in support for attaching files and pasting code. While some IRC clients will follow links and pull in outside data like code snippets or images, some will not which means you can’t rely on these features being present for everyone. With IRC you need to rely on a pastebin and file upload service to handle code and files.

The other major advantage is persistent, searchable sessions. That makes it easy to see what you missed while you where away. It’s possible to do this with IRC, but not easy.

There are ongoing efforts to improve IRC, notably the IRCv3 project, but if you’re looking for a solution right now, IRC comes up short.

And there’s no question that Slack is a very well designed, easy to use chat system. But it’s closed source, which makes it a questionable choice for open-source projects. Still, if good old IRC really isn’t working any more - and I would suggest your project take some time to really evaluate that question before proceeding - there are open-source Slack imitators that can also solve some of the problems with IRC, but are self-hosted and FOSS licensed. Self-hosters with the mostest

The two closest things to Slack in the open source world are Mattermost and Rocket Chat. Both support all the popular features of Slack including inline code snippets (Rocket Chat even offers code highlighting), inline images, archived searchable conversations, easy sign up, web apps, desktop apps and mobile clients. Rocket Chat also includes support for Markdown, and Mattermost can import Slack user accounts and channel archives to smooth the transition.

Where the two differ is in the user interface and in the backend setup (Rocket Chat uses MongoDB behind the scenes, while Mattermost uses PostgreSQL). Mattermost user interface is a bit closer to Slack, while Rocket Chat seems to have taken more inspiration from full-featured IRC clients.

Both, however, are self-hosted, which means projects can get most of the advantages of Slack over IRC, but retain control of the open source tools. If the history of web services teaches anything, it’s that relying on third-party services for key parts of your development infrastructure is almost guaranteed to fail in the long run.

While Mattermost and Rocket Chat, along with services like IRCCloud, which piggybacks on IRC to offer a more Slack-like experience, can fulfil 90 per cent of the Slack experience, none of the them match Slack 100 per cent. Mattermost lacks an Android client (it’s in the works), none of them have the amount of third-party integration that Slack offers, and none of them have the install base that Slack claims to enjoy - 1.1 million “daily average users in July last year so it said. Slip into some nice, comfortable Slack

It’s the last point that open-sourcers needs to consider. Ubiquitous install trumps everything else. With more and more developers using Slack on small teams at work (as it’s intended to be used) it’s natural to want to use the same tools for other projects.

There is an opportunity here for open source, though. Setting up and using Slack may be simple but extending it is not. If more developers turn to open source alternatives there will be more developers to hack on these alternatives. More momentum means more features, more cool hacks and in the end a more useful product. This is why Apache trumps Microsoft IIS, WordPress thrives while Movable Type is a memory, and Linux is the most wildly deployed operating system on the server.

On the other side of the argument, lack of developer interest in alternatives is part of why Dropbox has no real open-source competitor, Google Docs continues to be more popular than open-source options, and Foss offers almost no competition to Skype.

Slack may be the best choice now, but investing in open source alternatives like Mattermost or Rocket Chat is the best choice for open source coders in the long term.