Why is Slack winning?
By: Hisso Hathair
Tags: Slack, Platform Economy, Platform Thinking

The company behind Slack started life as “TinySpec”, initially founded to build a massive multi-player game named Glitch. To support messaging between players, Glitch used a built-in IRC server which also maintained an index over the messages. When the game wasn’t hitting growth targets, the developers pivoted to launch this as a standalone product: the “Searchable Linked Archive of Company Knowledge” (SLACK) (source).

In a way, they stumbled upon a solution to an imperfectly solved problem.

And IRC had problems. Broadly these problems fell into two areas: the (1) User experience (UX); and the (2) Developer experience (DX).

User Experience

Your perception of the IRC user experience depends on the type of user you are. Technical people generally liked it, and even today many express a preference for the IRC way of doing things. For “ordinary end users” (your mum, dad and CEO), IRC was joyless:

Getting started was hard. Engineers understood how to get started. Everyone else was left out. File sharing was a PITA. It was a pain to set up, and a security hazard to use. IRC could not catch you up on the messages you missed. It wasn’t part of its design philosophy.

There were smaller things: threads, emojis, and GIFs are all things Slack has that you wouldn’t find on IRC. Clients were also pretty ugly. It shouldn’t matter, but it does. Slack’s care and attention to fonts, glyphs and good design is self evident. The average IRC client looked like it was designed using either a typewriter or crayons.

Looking back, that first point was the real killer. To get started, a user had to

Select an IRC client. Choose, from the dozens available, which was right for you. Join an IRC server. Again — dozens available. Or should we set up our own? Beg your IT department to allow your client to connect to that IRC server, because it’s blocked by the firewall. Argue with your IT department. Lose the argument, install the software on a personal device, and then tether that to your 3G phone.

If you were lucky, a developer or engineer would help. They could set up an IRC server on the company network, resolving a lot of the connectivity and security issues. But then they had to contend with…the Developer Experience.

Developer Experience

For developers, systems engineers and other technical users, IRC was a bit more accessible. They tend to enjoy a variety of client application options for example, rather than perceive choosing one as a cognitive burden. But if you asked that same technical user to also run the IRC server, they had quite a few things to think about:

Security was hard. The protocol had a long history of insecure-by-design issues. You could install and run your own IRC server, but then you were on the hook for maintaining it and applying patches, etc. Programming it was not trivial. There were lots of bots and lots of ways of automating things, but that meant there was no “one right way” to learn and so you had a lot of trial and error learning. Senior and experienced developers tend to discount the learning curve involved, as well as the effort involved in sorting through which of the 3–5 IRC client developer libraries available for your preferred language was right for you. Culture was hard. “Netsplits” and “botwars” and anti-social behavior was a real turn off for enterprise IT departments. The protocol developed a reputation for being “where hackers hung out to engage in illegal activity.” Consider this a “branding” problem, but it was still a problem.

The tech user had a difficult choice: use an existing IRC server network (no maintenance, but attendant firewall and culture issues); or install an IRC server (no firewall problem, but now a maintenance overhead). And any automation requests (e.g. “When a support ticket is raised, can IRC be used to let the support team know?”) had to be handled with a custom integration, which then also had to be maintained.

The Slack Approach

TinySpec had already begun to expand their IRC server to “plug the gaps” in what they needed. That’s the advantage of building on open source — you can scratch your own itches. What the developers realized, and took advantage of in their pivot, was that it wasn’t just TinySpec that was feeling itchy.

Reborn as Slack, they made their chat app do a few things differently.

The User Experience is smooth:

It can run in a browser. No software to install, no IT department to convince, no business case to write, no firewall exemptions to argue for. Just hit a web page and go.

It’s free to get started. Small teams can use Slack for free indefinitely. When you need to pay, it’s just a credit card transaction.

You can extend it yourself, even if you’re not a developer. Want to be notified when a Jira ticket is raised? You can do it!

The Developer Experience is easy:

Slack handles the hosting, security, logging, etc. All the boring stuff is “just there”. There’s no maintenance overhead.

Most of the automation and integration your users are going to ask for are already there.

Worst case, you can code something custom. There’s one API, and it’s incredibly simply to use. And well documented.

Finally, it works as a platform. It has an API, and a lot of existing tools that can talk to it. I can get Jira posting updates to a channel in 3 mouse clicks. If there is not an existing plug-in, there’s a consistent and well documented API I can use to plug the gap.

Now you can do the same thing (and arguably a lot more) in IRC — but it will take longer. Not just to find or build it — you now have the responsibility of running it. The best you can hope for is that everything works and no-one notices. The worst is that you’re responsible for the company’s latest data breach and you’re fired. But when Slack leaks data — it’s their fault.

Slack is not without its pain points. It’s just that most end users and decision makers don’t notice them.

Why Slack “wins”

Every one of those UX and DX problems with IRC above have workarounds. For example, sr.ht (or Dropbox) could be used to facilitate file transfers. Organizations could set up Shout to give users a web based IRC interface. There’s even a cloud hosted version. But the problem here is one of discoverability. The on-boarding experience with Slack is so much easier — there’s no research to do on workarounds for limitations, because the Slack service model has everything I need built in. It might not be a “better” technology — what it is though is a better experience. Slack is more Accessible.

It’s more accessible for users, and it’s more accessible for developers — at least the kind of developers you find being over worked and stressed out in large enterprise IT departments.

Slack is beating IRC because it is more accessible, with a vastly superior user and developer experience.

Sources: