Why Slack is inappropriate for open source communications

Dave Chaney has written a nice blog post detailing why Slack the chat tool is inappropriate for open source projects to use.

The reasons to prefer something other than Slack for open source project communications are:

  • Slack is closed source
  • Slack requires paid memberships, especially when integrations start to be used
  • Communications within Slack stay within Slack, they cannot be linked to the outside world (that’s a walled-garden, anti-open Web attitude, it makes sense in a corporate setting but not for open source projects).
  • Slack favours real-time communication, even while it tries to promote asynchronous communication

His recommendation?

Instead of closed, synchronous, systems I recommend open source projects stick to asynchronous communication tools that leave a publicly linkable, searchable, url.

The tools that fit this requirement best are; mailing list, issue trackers, and forums.

I’ve mentioned Zulip as an alternative before because it does have some great features and besides, it’s licensed under a free/open source license.

On Hacker News, you can see a lively discussion about this topic.

The lead developer of Zulip chimes in with a thought-provoking response to the blog post, suggesting that Slack isn’t the real problem (though it is a contributor):

…even with “asynchronous” media like email, bug trackers, or forums, often people reply basically immediately (within minutes or maybe hours), just like you can in chat, and it might be hours or days before everyone has a chance to see the conversation and respond.

The problem is that the messages have no organizational structure beyond the channel. In Slack and friends, there’s no easy way to see what _actual conversations_ happened while you were away, and it’s really hard for a channel to discuss multiple things, so conversations either die or become hard to read when someone starts talking about something else. Combined, this means you have to (1) read _everything_ in order to know what happened and (2) be continuously online in order to participate effectively. This may not matter if your community is super low-traffic, but if you have hundreds or thousands of messages being sent daily, this effectively excludes everyone who doesn’t have a LOT of time to spend on the chat community.

The solution in Zulip is to have threads for conversations, and it is possible to view discussions outside of Zulip with public URLs so it isn’t a walled-garden of conversation. Highly recommend checking it out.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s