Book review: People Powered

Jono Bacon knows something about communities. He wrote the book on it, in fact. And now he has written another book. People Powered is a guide for how companies can create and curate communities.

I often see companies try to start what they call “communities”. In reality, they are ways for the company to get free labor that provide no real benefit to the the participants. But it doesn’t have to be that way. A community that doesn’t benefit the sponsoring company is not likely to continue receiving sponsorship. But if there’s no benefit to the community members, the community will not thrive. Only when everyone involved gets value from the community will the community be vibrant.

A community mission is different than your business vision, but tightly wound around it.

All too often, books like this prescribe the One True Way™. Bacon does not do that. He fills the book with many things the reader should do, but he also makes it clear that there are many right ways to run a community, just as there are many wrong ways.

People Powered is a starting point, not an answer. As I was reading it, I thought “this is a good set of recipes”. Further on, Bacon used the same metaphor. Curse you, Jono! But it’s an apt metaphor. The book presents advice and knowledge based on Bacon’s 20 years of community management. But each community has specific needs, so the reader is encouraged to selectively apply the most relevant parts. And in the tradition of open source, plans should be iterative and evolve to meet the changing needs of communities. Like any good cook, the recipe provides a starting point; the cook makes adjustments to taste.

If I could sum up People Powered in two words, I would pick “be intentional.” Given two more words, I’d add “be selective.” People are often tempted to do all the things, to be all things to all people. And while that may be in the future of a community, getting started requires a more specific focus on what will (and more importantly, what won’t) be done.

People Powered is full of practical advice (including a lot of calls-to-action to find resources on jonobacon.com). But it also contains more philosophical views. Bacon is not a psychologist, but he has made a study of psychology and sociology over the years. This informs the theoretical explanations behind his practical steps. It also guides the conceptual models for communities that he lays out over the course of the book. And to prove that it’s a Jono Bacon book, it includes a few references to behavioral economics and several to Iron Maiden.

I really enjoyed this book. Some of it was obvious to me, given my community leadership experience (admittedly, I’m not the target audience), but I still got a lot of value from it. Chapter 9 (Cyberspace and Meatspace: Better Together) particularly spoke to me in light of some conversations I’ve had at work recently. People Powered is an excellent book for anyone who is currently leading or planning to lead a community as part of a corporate effort.

People Powered (affiliate link) is published by HarperCollins Leadership and was released yesterday.

Disclosures: 1. I received a pre-release digital review copy of People Powered. I received no other consideration for this post (unless you purchased it from the affiliate link above). 2. Jono Bacon is a personal friend, but I would tell him if his book was awful.

If you want a diverse community, you have to stand up for marginalized members

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.

Don’t give gatekeepers a foothold

Gatekeepers are a problem in communities. They decide — often arbitrarily — who can and cannot be members of a community. Are you a true Scotsman? A gatekeeper will tell you. And if there’s something they don’t like about you, or they’re feeling particularly ornery, they’ll keep you away from the community.

Gatekeeping is a problem in open source communities. More experienced (or just louder) contributors set a bar that new contributors cannot meet. This is bad for folks who want to contribute to the project, and it’s bad for the project’s sustainability.

A recent Opensource.com article asked “What is a Linux user?“. In the initial version, it left open the possibility that if you’ve only used a Linux desktop that doesn’t require a ton of tinkering, then you’re not a real Linux user. Fortunately, the comments called this out quickly. And the author, to his credit, did not hold this view. He quickly updated the article.

The revised article does a much better job of closing the door on gatekeeping, but I would rather it have never run at all. By engaging in debate on the question, you give it validity. It’s best to deal with gatekeeping by not even acknowledging that the question is valid.

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.