A community of technology community managers, leaders, and builders.

Synchrouous vs Async communications in communities (or Slack vs email/forums)


#1

Early open source communities have long established rules stating that if something is not discussed on the mailing list, it never happened. Lately though, I’ve seen a trend emerging in large open source communities where live and real-time meetings are being privileged over asynchronous discussions (i.e. email.)

Evidence #1: OpenStack community

It’s a very large and differentiated community. While developers use mailing list a lot and use IRC weekly meetings mainly to iron out controversies, all development-related decisions are taken on async tools like email and gerrit reviews (used for code and changes to governance policies.) Most working groups in OpenStack instead use mailing list mainly to send notice of incoming meetings: almost no conversations are held via email, most decisions are taken during real-time meetings (IRC or voice) and results are rarely reported or discussed at length on email.

Evidence #2: WordPress community

The “Get involved” pages for Community, Marketing, Design, Meta all refer to Slack as the main medium for conversation. Many groups hold weekly meetings on Slack, and write summaries on Make blogs with the P2 theme.

The effects on myself and my close circle of friends is that privileging real-time conversations in communities leads to detachment and disengaged contributors. For example, meetings on IRC or Slack only allow participation to those in a compatible timezone: holding meetings at times convenient for residents in Europe, US West and Asia is impossible. Even if logs are public, archives easy to read, I find that chiming in a conversation that happened when I was not online is not worth it. And publishing only a public summary, with the implication that if I want to join and contribute I need to join next week’s meeting is not exactly smooth. Over time this can only lead to a decreasing pool of engaged contributors.

Have you seen similar trends in other communities, where real-time interaction is privileged over async communication in a forum or email? Is that a good thing?


#2

At Eclipse, we have forum, mailing list, Mattermost, and Bugzilla. Each project and working group has its favorite tool. Bugs on bugzilla are of course used for issues, but also for features and improvements discussions. Live meetings can also be done for small groups on Skype or Hangout. Mailing lists are still heavily used.

I would say that having meetings in Mattermost and just write a summary on Bugzilla or mailing list help a lot to have a cleaner tracking of decisions and discussions. Plus, Mattermost archive the discussion in dedicated channels, and this is more convenient than IRC to retrieve if needed.

In short, the resume of the live discussion is the equivalent of the approved answer on Stackoverflow: all the noise (comments, other answers, …) is less visible. And it highlights the good content and the best users.

The issue with technical communities like Docker, Openstack or Eclipse is that you don’t play with that on Saturday evening. People contributes because this is their job. However, you can post a blog with your Ubuntu laptop about your hobby: this is not the same market, users, contributors.

You have to take that in account. When I was working at Bonitasoft, I had quite the same issue: BPM is not very fun. The main issue I had to solve at the time is that in mailing list and forums, this is very difficult to find the important post: you have to read everything, and this is very annoying.

So we moved from a classic forum to a Q&A à la Stackoverflow: asynchronous but highlights key content/users. We produced dedicated tutorials for specific questions and use case. It helped us to gather our users on our community website instead of other tech websites. Then, we rewarded the most active users: featuring on the blog, specific high quality swag (poster, mugs, t-shirt, stickers, …), meeting them IRL when possible (when a consultant goes in their area), free access to support, and more. This way, the “average” contributors could “follow the leaders”.

Also, this is very important to organise conventions, events or meetups so people can meet in real life. And if possible sponsor important people of the community. Canonical does that for Ubuntu (UDS in the past, UbuCon, …) and we do that too at Eclipse, with the EclipseCon, Eclipse Days, and other local events. This help a lot to build relationship, nurture the leaders of the community, and find new contributors.

One last point: we are now in an change of generation: mailing list was the top 20 years ago, and some early open source developers are now project managers or retired. The new generation of developers grew up with live messaging, modern tooling, …

You really need to think about new ways to contribute and attract people. In a way, each community has its own communication stack and you must adapt it from time to time.


#3

Thanks for bringing in your experience. I agree with you that there is a generational change and I welcome the new generation and the modern tools. What I am trying to estimate is what the long term effect of a prevalence of real-time messaging tools have on online communities.

You mention Eclipse live meetings posting summaries on bugzilla/email. OpenStack and WordPress do something similar: real-time meeting, followed by a summary. While that may look an innocent approach, I fear it can fracture a community. Scenario: a team meets every Monday at 8am Pacific time. People in California who commute to work are unlikely to join, people in Asia are sound asleep, leaving some people in Europe and East/Central US with a convenient time. The meeting happens, the summary goes up a few hours after. What incentives does someone in Asia or Europe to add something to the conversation many hours after it happened? Maybe they could add a point, but for example, how would they know if that was already debated and dismissed during the real-time chat? Reading the full log of a chat can be annoying, so I believe the overall effect is chilling community growth.

One thing I want to address, where you say:

The issue with technical communities like Docker, Openstack or Eclipse is that you don’t play with that on Saturday evening. People contributes because this is their job.

There are different jobs, and I can speak with a fairly good understanding of the case of OpenStack: the job of a Red Hat developer working full time to add features and fix bugs of Nova upstream is a radically different job than that of a devop person deploying Nova for a public cloud operator. Both are professionals working on the same piece of technology but their time to participate in community discussions are radically different. And both actors would benefit immensely from participation in many of the same conversations.

Now, these are my impressions and I haven’t done much analysis yet on the effects of a predilection for real-time interactions within communities. For those, I would expect to see clusters of most active people in the same time zones, maybe higher churn of active members due to burn-out (over longer periods of time), splitting of communities across different geographic areas. I’m not even sure any of these would even be problems necessarily… I’m just curious :slight_smile:


#4

how would they know if that was already debated and dismissed during the real-time chat?

Reading the full log of a chat can be annoying

  • That’s part of the success of Stackoverflow: answers are highlighted, and most answers are written by someone from an other country than the author of the question, and sometimes hours/days after. You should use an adapted tooling. P2 is also a good solution, and you should have a look at Tuleap or Gitlab too.
  • That’s why it is very important to create opportunities to meet in real life: a hackaton at an event is the opportunity to fix bugs in real time, to meet, have a drink together, and it creates links between people. Then, they feel that they are part of a community, and engage even more.
  • IRC has been used by Linux developers for years, for private, team and general discussion. Slack and Mattermost are just IRC 3.0, the IRC for the new generation. But this really not a new issue.
  • Reading the history of an email thread is even more annoying if you missed the beginning. Reading and commenting the resume of the live chat, this is more efficient. Maybe you should add an extra step, like a vote after the resume, to let a chance to other people to comment and participate.
  • For non native english speaker, this is very difficult to speak fast enough to participate to a live discussion, so again, commenting the resume is a good opportunity.

Actually, this is more about respecting and welcoming contributors with different cultures and origins. Open Source should also mean openness at large, but this is not yet true in all communities.

A few articles to read on this topic:




#5

the job of a Red Hat developer working full time to add features and fix bugs of Nova upstream is a radically different job than that of a devop person deploying Nova for a public cloud operator.

This the difference between developers, and end users. And I agree, in general, developers in open source don’t listen enough to their end users: they consider most of the time that they should/could contribute if they want/need something. And end users feel that developers don’t listen to them. Trying to change that is a big challenge.

Personal example: How many time an open source developer told to me that I should learn how to code and do it myself?

Again, this is specific to technological products/projects. The end user of Gimp or Inkscape are artists, not developers. However, with Eclipse or Openstack, this is from engineers for engineers. At Eclipse, everybody is a developer: the contributor, and the end user who use the IDE. This is confusing.


Thanks to for being the kind sponsor for this forum!