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.

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.