Communication as a Roadblock?

It’s a bit like the turning of the leaves, or the return of the swallows at Capistrano. Invariably, the wheel of community management will always slog back to the the topic of “which is the best communications platform for my users?”

In the past, and for the most part in the present and future, the answer is usually something along the lines of “whatever your community prefers.” If you have a community that does most of its communication on a mailing list and communications are active and vibrant, why change what works?

But is this don’t-rock-the-boat attitude potentially keeping some new community members away?

The problem with communications platforms is pretty simple: there’s too many of them. And each of them have a set of pros and cons that make it hard to outright dismiss each of them. We have grown far beyond the mailing lists, Internet relay chat (IRC) channels, and bulletin board platforms of the deep Internet past. But the core functionality has not changed. These are still the three core categories in which most platforms fall: mailing lists, chat, and online forums.

Software has evolved that some of these categories can be blended: Hyperkitty for Mailman adds forum-like features to mailing lists, and Google Groups lets emails get displayed in forum-like online pages, just as two examples. But basically, these three categories cover the bulk of the communication systems out there.

Within those categories there are a lot of tools. One of my teammates on our staff IRC channel listed just some of the tools he had to use to communicate with projects: Mattermost, Gitter, and Slack. Plus IRC, mailing lists, GitHub comments, and Signal.

Typically, the discussion of what’s the right tool to use ends up going like this. Someone brings up a desire to move to a new channel for their community. Lately, it’s been Slack, because—usually anaecdotally—there’s a notion out there that newer and younger developers are using Slack and it would be a preferred chat platform over something like IRC.

The response is usually: “you’re an open source project, why do you want to use a proprietary tool? Plus, what’s wrong with IRC?”

“Nobody knows IRC anymore.”

“Well, then point them to an IRC client.”

“There are no good IRC clients on mobile.”

“Does your community want to chat on mobile?”

“Um…”

And nothing gets changed.

The problem with this repetitive argument (and it’s not just Slack vs. IRC, you can insert any pair of similar tools into this discussion) is that most of the time a desire to move is done by a feeling that this is where everyone wants to go. That may or may not be the case. Is most of your community using Tool X? Or do you think they are? And (conversely) is using the tool you have already really causing friction among your community members?

The solution here is straightforward: don’t base your need to switch platforms on a gut feeling. Actually do some research. Survey your community and see what tools they are using as well as where and when? The “where and when” is an important question, because you need to find out if indeed your community participants like to use mobile. But you need to ask when, too, because some participants may not want to have mobile availability to communications so they can maintain a better work-life balance.

It will vary from community to community, but this is the crux of the argument: you need to ask first and see what current and potentially new contributors would prefer to use. Then you can determine if your current platform is actually a barrier to entry that should be changed.

Image by blickpixel under CC0 1.0 license.

n