Picking communication tools for your community

Communication is key to the success of any project. The tools we use to communicate play a part in how effective our communication is. Recent discussions in Fedora and other projects have made me consider what tool selection looks like. Should Discourse replace mailing lists? Should Telegram replace IRC? I’m not going to answer those questions.

There’s no one right tool, just a set of considerations to think about in selecting communications tooling. Each community needs to arrive at a consensus about what works best for their workflow and culture, and keep in mind that the decision may attract some contributors while driving others away.

In this post, I’m going to broadly lump tools into two categories: synchronous and asynchronous. Many tools can be used for both to a decent approximation, but most will pretty obviously fall into one category or the other. Picking one tool to rule them all is a valid option, but be aware that it immediately favors one category of communication over the other. And keep in mind that for large projects, some sub-teams may choose different platforms. That’s fine so long as people who want to participate know where to look.

Considerations for all tools

Self-hosted or externally-hosted. Do you have the resources to maintain the tool? If you do, that’s a way to save money and maintain control, but it’s also time that your community members can’t spend working on whatever your community is doing. Externally-hosted tooling (either free or paid) might give you less flexibility, but it can also be more isolated from internal infrastructure outages.

Open source or proprietary. This is entirely a value judgement for your community. For some communities, anything that’s not open source is a non-starter. Others might not care at all one way or another. Most will fall somewhere on the spectrum between.

Federated or centralized. Can the community connect their own tools together (e.g. like with email) or is it a centralized system (like most social media platforms)? The trend is definitely toward centralized systems these days, so you may have to work harder to find a federated system that meets your needs.

Public or private. Can outsiders see what you’re saying? For many open source projects, public visibility is important. But even in those communities, some conversations may need to take place in private or semi-private.

Archived or ephemeral. Do you want to be able to go back and see what was said last month, last year, or last decade? Some conversations aren’t worth keeping, but records of important decisions probably are. Does your tool allow you to meet your archival needs?

Considerations for synchronous tools

Sometimes you really need to talk to people in real time.

Mobile experience. It’s 2019. People do a lot on their phones, especially if their contribution to your community happens during their workday or if they travel frequently. What is the mobile experience like for the tools you’re evaluating? It’s not just a matter of if clients exist, but what’s the whole experience. If they disconnect while on an airplane, do they lose all the messages that were sent in their absence?

Status and alerting. What happens if someone stays logged in and goes away for a little bit? Do they have the ability to suppress notifications? Is there any way to let others know “I’m away or busy, don’t expect an immediate reply”?

Audio, video, and screen sharing. Sometimes you need the high-bandwidth modes of communication in order to get your full message across (or just shortcut a lot of back-and-forth). Does the tool you’re looking at provide this? Is it usable for those who can’t participate due to bandwidth or other constraints?

Integrations. Can you display GIFs? The ability to speak entirely in animated images can be either a feature or a bug, depending on the community’s culture. But if it’s important one way or another, you’ll want to make sure your tool matches your needs. Of course, there are other integrations that might matter to. Can your build system post alerts? Does the tool automatically recognize certain links and display them in an particular manner?

Considerations for asynchronous tools

Of course, you’re not all going to be sitting at your computer at the same time. People go on vacation. They live in different time zones. They step away for 10 minutes to get a cup of coffee. Whatever the reason, you’ll need to communicate asynchronously sometimes.

Push or pull. Email is a push mechanism. Your message arrives in my inbox whether I’ve asked it to or not. Web fora are a pull mechanism. I have to go check them (yes, some forum tools provide an email interface). Which works better for your workflow and community? Pull mechanisms are easier to ignore when you want to step away for a little while, but they also mean you might forget to check when you do want to pay attention.

Is it a ticket system? I haven’t really talked about ticket systems/issue trackers because I don’t consider them a general communication tool. But for some projects, all the discussion that needs to happen happens in GitHub issues or another ticket tracker. If that works for you, there’s no point in adding a new tool to the mix.

The resurgence of the web forum

I saw an interesting thread on Twitter recently. The Ghost community shut down their Slack instance in favor of a forum. Yes, those mainstays of mid-aughts online socialization seem to be making a comeback. And I get it. As much as I appreciate Slack for work chat, it’s kind of a pain to use socially when you have a lot of groups.

I’ve written before about the downsides of Slack for communities. But in that, I was thinking more of the individual perspective. John’s thread brings the group perspective to mind.

As communities grow, it’s harder for people to feel a sense of belonging. Slack’s fast pace and emphasis on the moment make it hard to step away. Indeed, in a large community using the free version, you lose history pretty quickly. This is true of other group instant messaging, too, of course. But there’s a reason you don’t see a lot of thousand-person chat rooms (or dozen-person group texts). Many-to-many communication gets noisy quickly.

If a community’s messages are largely of the question-and-answer variety, forums make a lot of sense. Keeping the answers near the questions makes it easier for future visitors. Both the questions and answers become easier to find. Of course fora have their own issues. You have to remember to go to the website and check for new messages (or else get a barrage of emails that you’ll ignore anyway). But it goes to show that technology is cyclical. And even good products can fade as the newness wears off.

Twitter’s public roadmap: I’ll believe it when I see it

Full disclosure: I own a small number of shares in Twitter.

Trello is a very important tool in my workflow, so I read their blog for tips and news. I started reading a recent post by Leah Rider and everything was fine until I saw this:

As one of the most dialed-in companies to the pulse of the people, Twitter…

I’m sorry, what? Twitter is notoriously bad at knowing what people want, be they users (an edit button and less harassment), developers (the ability to develop apps), or investors (I’d settle for breaking even at this point). Twitter may be where the pulse of the people is expressed, but that doesn’t mean the company has a clue.

The post goes on to say

Through a simple public Trello board, Twitter is redefining their relationship with the developer community and setting a precedent for other platforms.

If Twitter wants to define a relationship with the developer community, they could start by having one. The only reason I maintain a Twitter client is because Twitter drove away the original developer. Twitter’s rise was due in part to the ecosystem of great (and not-so-great) third-party applications. Twitter was a platform that people could build off of.

That’s no longer the case. Many features are not available via the API. Polls and GIF searches are two that come right to mind. It takes more than a public Trello board to have a community. And the Trello board isn’t even impressive. It is publicly visible, but not editable. What’s worse, the last update was almost a month ago. The last activity before that was over two months ago.

So if Twitter is ready to develop a robust third-party app ecosystem again, that’s great. It can only benefit the platform. But you’ll forgive me if I wait to see some evidence before I believe it.

The tradeoffs of Slack for community projects

When my employer adopted Slack, we saw benefit immediately. Conversations are searchable, file sharing is easy, and oh how I ? /giphy. It’s a great tool, but I don’t like it for open communities.

Slack was designed to be a company’s internal communication system. For that purpose, it’s great. It was not designed to be an open platform. For example, it is basically impossible for users to manage harassment.

Most people have one employer at a time. That’s not the case for hobby and interest communities. I have five unrelated rooms on Freenode IRC that I’m regularly in. For the most part, I manage that in one place. But each Slack instance I’m in might as well be a separate universe.

That’s not to say Slack is all bad. It is much easier to learn and use than most IRC clients. This is a significant benefit to non-technical communities. Creative Commons, for example, saw a large uptick in community participation after moving to Slack. Slack allows for a richness of community culture to develop in ways that text-only formats don’t.

But for me, particularly with open source communities, the less-than-public nature of Slack teams is a negative. People can’t join the communities they don’t know about. And if they can’t lurk quietly (by reading transcripts or joining the server anonymously), will they feel safe jumping in? There are lock-in considerations as well (my free software readers have probably been waiting for me to get to this point) that I think I’ll address in a later post.

Each community has to decide what is best for them. Like any other technology, Slack has pros and cons. The important thing is to weigh them before making a decision.

What counts more for community: labels or actions?

I was recently in an argument on Twitter (I know, I know). The summary is that there was disagreement on whether stated party affiliation or cast votes were more indicative of the state of the body politic. We didn’t arrive at a consensus, but it got me thinking about open source communities.

Communities are notoriously difficult to pin down. Where are the boundaries? Is a person a member of a community when they (or someone else) decides to apply that label to them? Are they a member when they make some overt participation effort? Is it a mix of both?

In general, I tend to think that if it looks like a duck and quacks like a duck, there’s a pretty good chance it’s a duck. That is to say a person is a member of a community if they participate in the community, even if they don’t self-assign the label. For example, if someone considers themselves a political independent but they vote for Democratic candidates 80% of the time, they’re probably a Democrat. Similarly, someone who frequently answers questions in an open source project’s IRC channel or mailing list is a member of the contributor community, even if they don’t think they are (perhaps because they’ve never contributed code).

This isn’t to say that communities shouldn’t welcome people willing to self-assign membership. Unless someone has behaved in a way to warrant exclusion, they should be welcomed and encouraged to become active participants. That doesn’t necessarily mean giving them full access, though. I still consider myself a contributor to Fedora Documentation, even though I haven’t really made a contribution in a while. I still have commit access to the repo, but if someone decided to suspend that, I’d understand.

There’s not a good answer here. How a you define community is largely context-dependent. It’s worth considering how we define the boundary.

left-pad exposed the real problems

During halftime of Super Bowl 49, “Left Shark” became an instant pop culture phenomenon. Last week, an 11-line software package called “left-pad” became an instant tech culture phenomenon.

In you’re not familiar with what happened, here is a basic summary as I understand it: the social network/chat company Kik approached a developer and threatened him with lawyering if he didn’t remove or rename his “kik” NPM package (the package was in no way related to Kik the company). When the developer refused, Kik went to NPM, who acquiesced and reassigned ownership. As a result, the developer pulled all of his packages, including left-pad, from NPM.

Normally, this wouldn’t get much attention. However the Node.js ecosystem apparently favors many small packages, such that you end up with single-function packages like left-pad. Many NPM packages either depend on left-pad or depend on packages that in turn depend on left-pad. This led to, as some people hyperbolicly said, the Internet breaking.

Much of the discussion has focused on the technical matters. The NPM ecosystem is the subject of a great deal of ridicule. The opinion isn’t unanimous, but ridicule is the prevailing sentiment. And rightfully so, but not for the reason being discussed.

The real problem with NPM isn’t the numerous tiny packages. The problem is with how the ecosystem is apparently managed. Breaking dependencies by “unpublishing” packages is not something a mature ecosystem allows. Removing a package without consent because another developer wants to use the name is a terrible way to build and maintain a community.

The other bad part is how Kik’s lawyers were able to make all of this happen. Trademarks are not universal. Just because Kik has trademarked the term in the context of a messaging platform, that doesn’t mean the term can’t be used in another context. Maybe in this specific case, there’s infringement here. I’m not a lawyer or a judge. But the way it was handled was not at all suitable. As Ben Thompson said, “lawyers overreaching on trademark were the Mentos to an open source absolutist’s cola.

It’s a bit unfair to pin this on “an open source absolutist”. Azer Koçulu may or may not be an open source absolutist, that’s irrelevant. Lawyers tossing threat grenades and ecosystem managers not protecting the ecosystem are more important than the number of packages or having trivially-small packages.



GitHub as a community management platform?

GitHub is the dominant platform for hosting open source code. It’s hardly ubiquitous, there are other hosting services and many projects self-host. Nonetheless, it’s the go-to place for many FLOSS projects and has lowered the barrier to contribution. Arguably, it’s brought the barrier too low.

At least, that’s my interpretation of an open letter to GitHub published on Thursday. Signed by dozens of project maintainers, the letter identifies troubles that often arise on the GitHub platform and offer suggestions for fixes.

The issues raised in the letter are legitimate, and they’re expressed quite reasonably for something published on the Internet, but they highlight what GitHub is and isn’t. GitHub is a source code management platform, it is not a community management platform.

That’s not to say it can’t be. GitHub is great for what it does, but it could be even better. Managing code is easy; managing contributors and other community members is not. For GitHub to take the next step in promoting open source software development, it needs to provide tools that aid in community. That includes bug and issue tracking, communication (mailing lists?), and other features that turn a project’s users into community members.

Licensing and open source communities

At FOSDEM 2014, Eileen Evans gave a talk entitled “Licensing Models and Building an Open Source Community“. The talk is basically a discussion how Evans changed her mind about the suitability of permissive licenses in vibrant open source communities. She proposes that a vibrant community requires excellent technology, suitable governance, and a license that the community perceives as fair.

A decade ago, Evans was working at Sun and considering what license to use for OpenSolaris. The decision at the time was that because copyleft licenses require downstream changes to be returned to the community (in the sense that they remain freely-licensed), copyleft licenses are necessary for a healthy community.

In the intervening years, many projects have adopted permissive licenses. The GPL family is no longer the majority license, according to several surveys. Vendor participating in open source projects favored strong copyleft until around 2006, but the preference has shifted toward permissive licenses. A survey of GitHub projects showed the MIT license with a dramatic lead over the next-most-widely-used license.

Based on this, Evans concluded that permissive licenses can, in fact, be used

Is that still true today? Projects are increasingly using permissive licenses. MIT dominates GitHub. Vendor engagement (participation in projects) was toward strong copyleft until ~2006 when permissive licenses take over. 5x increased in contributors to CloudStack after changing from copyleft to permissive. Permissive licenses may be used to build a community.

Of course, there are few who would take the position these days that permissive licenses can’t be used. Even noted copyleft advocate Bradley Kuhn can be heard agreeing on the video, though he points out his view that copyleft licenses make for better communities. Perhaps the question should be phrased as “what kind of communities develop?”

In conducting research for my thesis, I came across a study that showed copyleft licenses were associated with higher user engagement, but permissive licenses were associated with higher developer engagement. This makes sense, since not all developers develop FLOSS. A developer who isn’t developing FLOSS would probably be more drawn to a project where the license was conducive to proprietary downstreams.

Evans’ anecdote about the increase in contributions to CloudStack when it switched from copyleft to permissive licensing may or may not tell us something. It may be purely coincidental. An increase in the popularity of the project or of cloud computing generally may have driven the change. And of course, there’s more to a community than the number of committers.

I suspect that the license itself may be less important than the overall governance model. It’s certainly an area that merits further research.

File a bug!

The ability for users to submit patches is often touted by advocates of open source software. “Patches welcome!” is a common refrain on mailing lists. Even if someone lacks the ability to diagnose and fix an issue, they can file a bug in the project’s system. Indeed, there’s an unwritten social expectation that users file a bug.

Sadly, these are often just empty words. “Patches welcome” can be a seemingly-polite way of saying “your problem is not important to me. Go solve it yourself and I’ll accept your solution.” And telling a user to go file a bug can be equally dismissive, especially if the bug-filing process is unpleasant.

I certainly don’t mean to imply that all or even most open source developers use these phrases as a polite cover for their disinterest. There are jerks, of course, but I suspect most developers genuinely want bug reports and patches. Last week, a very busy developer replied to a mailing list post with a terse “file a bug.” Now, I happen to know this particular developer and I know he’s keenly interested in fixing bugs. On this day, he was swamped and didn’t have time to get to the issue right away. Suspecting from the original email that the user who reported the bug wasn’t deeply technical, I took the liberty of reproducing the issue and filing a bug with the details.

Would the person who originally reported the issue have filed the bug done so if I hadn’t? We’ll never know, but I do know that he didn’t by the time I did. After creating a Red Hat Bugzilla account, selecting the right options, and filling out the bug report, he’d have to hope the developer meant it and that he bug would get fixed. As anyone who has been around a while can attest, just because a bug is filed, that doesn’t guarantee it will be fixed in the next few years.

One particular bug that I filed sticks in my memory. It was undeniably a bug, I attached a patch to fix it, and yet the bug remained untouched through several Fedora releases. Granted, it was a relatively minor issue, but if I weren’t involved with the project, I’d have been pretty put off by this. Of course, no one owes me a fix, but as Chris Siebenmann noted, if there’s a social obligation to file a bug, there’s also a social obligation to deal with the bug.

This morning,I asked on Twitter if anyone had what they’d call a “positive” bug reporting experience (as opposed to simply a not-negative experience). I was pleasantly surprised when several people chimed in to say they had. Small projects were generally the ones that drew the good responses (Jordan Sissel was mentioned by multiple people).

So what makes for a positive experience? Rapid acknowledgement and resolution were mentioned several times. Those who replied mentioned courteous and helpful interactions (e.g. asking constructive questions, filing an appropriate bug when the original bug was mis-filed). @phrawzty summed it up well: “Most importantly, however: good intentions were assumed. I never felt treated like a dangerous outsider.”

This is an area wide open for study (and I may end up doing just that), but in the meantime projects should consider how they present themselves. Large projects with more resources should make an active effort to devote some time to bug handling as a community outreach effort (I suspect large projects have worse bug experiences, in part due to the fact that nobody owns the process). When you say “patches welcome” or “file a bug”, consider what you’re really saying and if people will take it the way you mean it.

(Thanks to those who provided feedback: @cpj1, Matt SimmonsMatthew General, Patrick Cable@phrawzty, Rick Waldron@SysAdm DreddThomas Ballinger, @Twirrim, and anyone else I failed to mention.)

elementary misses the point

A recent post on the elementary blog about how they ask for payment on download created a bit of a stir this week. One particular sentence struck a nerve (it has since been removed from the post): “We want users to understand that they’re pretty much cheating the system when they choose not to pay for software.”

No, they aren’t. I understand that people want to get paid for their work. It’s only natural. Especially when you’d really like that work to be what puts food on the table and not something you do after you work a full week for someone else. I certainly don’t begrudge developers asking for money. I don’t even begrudge requiring payment before being able to download the software. The developers are absolutely right when they say “elementary is under no obligation to release our compiled operating system for free download.”

Getting paid for developing open source software is not antithetical to open source or free (libre) software principles. Neither the OSI’s Open Source Definition nor the Free Software Foundation’s Free Software Definition necessarily preclude a developer from charging for works. That most software that’s free-as-in-freedom is also free-as-in-beer is true, but irrelevant. Even elementary touts the gratis nature of their work on the front page (talk about mixed messages):

100% free, both in terms of pricing and licensing. But you're a cheater if you take the free option.

100% free, both in terms of pricing and licensing. But you’re a cheater if you take the free option.

Simply put, the developers cannot choose to offer their work for free and then get mad when people take them up on the offer. Worse, they cannot alienate their community by calling them cheaters. Of the money the elementary receives, how much of it goes upstream to the Linux Foundation, the FSF, and the numerous other projects that make elementary possible? Surely they wouldn’t be so hypocritical as to take the work of others for free?

An open source project is more than just coders. It’s more than just coders and funders. A truly healthy project of any appreciable size will have people who contribute in various ways: writing documentation; providing support on mailing lists, fora, etc.; triaging bug reports; filing bug reports; doing design; marketing (including word-of-mouth). This work is important to the project, too, and should be considered an in-kind form of payment.

It’s up to each project to decide what they want in return for the work put in. But it’s up to each project to accept that people will take from all of the choices that are available. If that includes “I get it for free”, then the right answer is to find ways for those people to become a part of the community and contribute how they can.