The primary challenge for open source projects is finding the best way for contributors to collaborate
One of the primary challenges open source projects face is how contributors communicate with each other. There are many choices: forums, chat channels, issues, mailing lists, pull requests, and more. Which one should we choose to use, and how should we do it?
Unfortunately, projects are often reluctant to make binding decisions and instead choose “all of the above.” This leads to a fragmented community: some people use Slack/Mattermost/IRC, some use forums, some use mailing lists, some exist in issues, and few people can read all these channels.
In the organizations I help build internal and external communities, this is a common problem. Which channel do we choose, and for what purpose? Also, when can we say no to one of them?
This is what I want to explore in depth here.
Structured and Unstructured
I’m not a smart person. Therefore, I tend to break problems into smaller parts so I can understand them better. Similarly, I tend to break down the various choices in a situation into smaller parts to better understand their purpose. I use this method for communication channel selection as well.
I think there are two major categories of communication channels: structured and unstructured.
Structured channels have a very specific focus in each individual communication unit. Examples include: GitHub/GitLab/Jira issues. An issue is a very specific piece of information about a bug or feature. In the series of discussions that follow after the initial issue post, the discussion is usually very focused on that specific topic and will have an outcome (such as a bugfix or a final plan for a feature). The outcome is usually reflected in the status (such as “FIXED,” “WONTFIX,” or “INVALID”). This means you can understand the beginning and end of the communication without reading the middle.
Similarly, pull/merge requests are structured. They focus on a specific type of contribution (usually code). After the initial pull/merge request, the discussion is very focused on one outcome: making the contribution meet the requirements and merging it into the codebase.
Another example is Q&A posts like StackOverflow/AskBot. These posts start with a question, then are edited and replied to provide a precise answer to that question.
Through these structured mechanisms, there’s usually almost no deviation from their original structure. You won’t see people asking others what their children/cats/dogs/family are doing in issues, pull requests, or Q&A topics. Going off-topic is unacceptable in the community, and this is part of the power of structured media: it’s focused and (usually) efficient.
Conversely, unstructured media includes chat channels and forums. In these environments, there’s usually a topic (such as the theme of a channel or subforum), but the conversations are much less related to a specific outcome or conclusion, and may generally be more broad. For example, in a developer mailing list, you’ll see a series of discussions including general questions, ideas for new features, architectural debates, and discussions related to the community’s own operations. Each discussion hopes to keep participants focused, on-topic, and productive. But as you can imagine, this is often not the case, and such discussions may deviate from a productive outcome.
The Impact of Recording
Besides the subtle differences between structured and unstructured communication, the impact of what is recorded and how it’s searched is also important.
Typically, all structured channels are recorded. People can refer to previous bugs, questions from StackOverflow can be reused over and over. You can search for things, and even if there’s a lot of discussion, FAQs, pull requests, or questions, they’ll be updated to reflect the final conclusion.
This is a key point: we want to be able to quickly and easily dig up old issues/questions/pull requests, etc., and link to them and cite them. A key part here is that we turn this content into citable material that can be used to educate and inform people about past knowledge. As the community grows, our structured communication becomes a knowledge base that can inform the future through past experience.
Unstructured communication is getting worse. On one hand, forum searching is usually simple and efficient, but they’re certainly full of unstructured conversations, so what you’re looking for might be buried in the discussion. For example, many communities use forums as support tools. While this is a more powerful platform, the problem is that an answer to a question might be in reply #16 or #340. With more and more information sources (like Twitter) bombarding us, we’re becoming increasingly impatient with reading large amounts of material, which could be a problem for unstructured media.
An interesting special case is real-time chat. Historically, for many years, IRC paved the way for real-time chat, and for most IRC users, there was little (if any) thought of recording these discussions. Indeed, some projects (like Ubuntu) recorded IRC logs, but this is usually not a useful resource. As my friend Atwood once told me: “If you have to search for something in chat, you’ve already lost.”
While IRC falls short in recording, Slack and Mattermost are better. Conversations are archived, but the problem remains: why would you want to find a point someone made in a sea of chat messages? Other channels are better for citing previous discussions.
However, this does create an interesting opportunity. Chat has a consistent benefit over other media in showing what kind of person someone is. Structured channels, and even unstructured channels like forums and mailing lists, rarely encourage small talk. But chat does. In chat, you ask: “How was your weekend?”, “Have you seen this game?”, and “Are you going to see Testament, Sepultura, and Prong next week?” (Okay, maybe I’m the only one asking that last question.)
So, while real-time chat may be less efficient than the previous methods, it does enhance relationships between people.
What Do You Want to Drink
So, back to our original question about open source communities: which one do we choose?
While the answer will vary for different projects, I want to think about it on two levels.
First, you should generally prioritize structured communication. This is where tangible work gets done: issues/tickets, pull requests, Q&A discussions, etc. If you have limited resources, then focusing on these channels can produce efficient community output with less time and money expenditure.
Second, if you’re keen on building a broader community that can focus on engineering, advocacy, translation, documentation, etc., then it makes sense to explore whether to introduce unstructured channels. Community isn’t just about getting work done; it’s also about building relationships and friendships, supporting each other in work, and helping people grow in the community. Unstructured communication is a useful tool.
Of course, I’ve only scratched the surface of a big topic. But I hope I’ve provided some analysis on how to evaluate and choose the value of communication channels. Remember, less is more: don’t be tempted by the illusion of having all the channels, otherwise you’ll get a fragmented community, like an empty restaurant.
May the Force be with you, and let me know how you’re doing. You can contact me through my website and email jono@jonobacon.com.
(Image: Opensource.com)
About the Author:
Jono Bacon is a leading community manager, speaker, author, and podcaster. He is the founder of Jono Bacon Consulting, providing community strategy/execution, developer workflow, and other services. He previously served as community director for GitHub, Canonical, XPRIZE, and OpenAdvantage, and has provided advice and consulting to many organizations.
Reprinted with permission: Developer Relations »
