Developer and user communication channels

In a project’s early days, you don’t need separate communication channels for users and developers. In fact, you probably don’t want to separate those audiences. Karl Fogel explains this well in Producing Open Source Software:

Among early adopters, the distinction between developer and user is often fuzzy; to the extend that the distinction can be made, the ratio of developers to users is usually much higher in the early days of the project than later on.

Karl Fogel

But as the project grows, the community has to decide whether or not to maintain unified channels or separate them. How do you decide?

Reasons to stay unified

Simplicity is perhaps the best reason to keep channels unified. It’s less infrastructure to run or pay for. It also lets people avoid having to decide if a topic is user- or developer-focused. The line is blurry, so avoiding that cognitive overhead makes it a little easier on your community members. And what starts out as a user conversation often morphs into a deep development conversation.

Just like topics aren’t cleanly one or the other, members of your community aren’t cleanly one or the other. For most projects, you can consider developers to be a subset of users. So just because someone is a developer in your project, that doesn’t mean they’re acting in the developer context at that moment.

Finally, unified communication means access. Users get to see developer conversations, which might nudge them into becoming a contributor. And they can get help from people who know the code best: those who rote it. Developers can see the problems users face and learn how to improve the software.

Reasons to separate

Access is both a blessing and a curse. If developers are constantly distracted by users, they’ll never get any development done. Of course, helping users is also an important activity. But not one that needs to be done by everyone all the time.

Noise is an issue, too. Even on separated channels, many of the messages are of no interest to any given person. On a unified channel, there’s even more to ignore. This can be overwhelming and end up driving people away from participating.

My opinion

My preference is to keep developer and user communications separate. A little bit of friction can help keep everyone in the conversations they’re looking for. But you want it to be more of a garden fence and less of a fortress wall. If you can easily move the conversation when it becomes clear that it’s in the right place — or if you can quickly bring additional people in — that’s a big bonus. This is where a platform like Discourse shines over mailing lists.

This post’s featured photo by Anton Kraev on Unsplash.