A few months ago, this Hacker news item sparked a lively and—fittingly, for a discussion about this topic—asynchronous discussion about the role of group chat systems in open source projects and distributed companies. At Alley, we use Slack. We’re very happy with it, and it’s a really important venue for the expression of our company culture. However, I should probably take this opportunity to confess that I was the main holdout against adopting Slack and leaving behind our self-hosted IRC server back in 2013.
This topic is very near to my heart, in fact. It’s quite normal today to meet business colleagues, friends, and, of course, romantic partners online first and in person second. It wasn’t nearly as normal in the 1990s, when I was a kid chatting about computer games on IRC with fellow nerds (some of whom are now close in-person friends!) For me, IRC was the one and only venue for distributed group text chat on the Internet for a long time before Slack arrived on the scene.
The Drew DeVault post that sparked the Hacker News discussion makes an argument that I have a lot of sympathy for personally. IRC is an open standard. Codified in 1988, it predates HTTP itself by four years, and modern IRC servers can still support a client released ten years ago. The way IRC works is entirely consistent with the requirements of most open source projects: that all cards be laid on the table and no one person or entity have proprietary control over the process.
For this reason, it’s a bit disorienting to see comparisons between Slack and IRC as if they were two competing entities, like Coca-Cola and Pepsi, with equivalent wills to outdo one another. I’ve never seen any communications from the Slack team itself indicating that they intend to crush IRC. They actually offer an IRC interface to their service, though it obviously lacks features included in the official client. When I first encountered Slack, I saw it as an obvious attempt to take care of two main features that one would otherwise have to solve ad-hoc with IRC: the ability to read chat that transpired while you were offline, and the ability to automatically keep logs of activity. Everything else, for me, is icing. What Slack did for Alley Interactive was make the distributed chat culture we already had more accessible to our team.
Among the more high-profile detractors from this perspective is Isaac Schuleter, creator of npm.
Most of the arguments for using IRC vs Slack are equally valid reasons to live under the highway vs in an apartment, and vice versa.
— Isaac Z. Schlueter (@izs) November 3, 2015
The crux of this argument is simply that Slack is easier to use and more optimized for business collaboration, and therefore, it fosters a more vibrant culture of collaboration and interaction. This is where I disagree. At Alley, we were doing this for years before Slack. We would indoctrinate even non-technical team members in the arcane art of using a text-mode terminal IRC client inside screen and built logging into our hubot-based chat bot (which we still use — we just changed the connection protocol from IRC to Slack).
Was all that stuff hard to use, clunky for experts and often confusing for novices? Yes, it absolutely was. When Slack offered us the chance to fix some of those problems for a modest fee, we took them up on it. Even I ultimately relinquished my ardor for IRC. Moving to Slack, however, did not change our company culture or the way we approach the role of text chat for distributed teams. From day one, we encouraged our team to treat our chat system the same way they’d treat a physical office: mostly a place for work, but also a place to socialize, connect, and bond with your teammates. When the excellent quality of the team you work with is a major benefit that the company offers, it’s crucial to have that space. Slack just made it a little more convenient.
If Slack went out of business tomorrow, we’d move back to IRC. Or maybe somewhere else. But we’d still keep our bot, and our sense of humor.