I strongly agree with both criticisms of using Slack for open source, and I am impressed that Dave wrote this post, given that some of those criticisms apply to his own product.
However, I think the proposed solution of relying on mailing lists, issue trackers, and forums is the wrong solution.
Support for synchronous communication is not the problem with using Slack/IRC/etc. for having discussions in open source organizations. After all, 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.
It doesn't have to be this way. Nothing prevents creating group chat software that handles both synchronous and asynchronous communication well. In particular, Zulip is built around a simple threading model that solves both of these problems. In our own chat.zulip.org community, people constantly contribute valuable commentary or feedback to a thread that started a few days and hundreds of messages ago. And I can come back from a week's vacation, and skim the 5000 messages that might have happened while I was gone, and easily reply to all the threads where I have something to add.
(As a sidenote, it's easy to post permanent links to conversations in Zulip, which we use regularly in the Zulip issue tracker to point to the original discussion that led to a given proposal. But the important problem isn’t the link part, it’s separating the conversations from each other: without something like Zulip's threading, reading chat logs can be a slog).
Other things I like about it:
- e-mail addresses in addition to nicknames
- working full text search over everything
- plenty of well thought out keyboard shortcuts
- high quality production tooling (they even have Nagios checks, out of the box!)