The Community of One

I had the good fortune of being present for Jono Bacon’s excellent community session at OSCON a few weeks ago. (The 40 minute version, not the 15 minute keynote version with which he was wholly dissatisfied.) As the open source model matures, community management as a discipline is maturing with it, and Jono did an excellent job of bringing together some of his own best practices in a concise and useful presentation. He promised to have his deck uploaded soon, so as soon as he does, I’ll link to it.  (Jono: hint hint.)

One of the most interesting slides in that deck, and for me one of the most personally resonant, was a page that arrayed all of the potential responsibilities of the community manager — a grid of words that took up the entire page. Words like growth and transparency and process and conduct and governance and buzz, and lots more besides. An intimidating array of words, really.

As we chatted afterwards, the would-be founder of a small niche project talked about the pains of getting people to engage in his project, and how he could possibly keep track of all of those community tasks while he was busy slinging code, and in that huge array of potential responsibilities, where should he start? How should he grow beyond a Community of One?

It was a great question, and it set me to thinking for days afterwards.

At first I thought, “it’s most important to articulate your needs.” And it’s true: articulating your needs is very important. People can’t help you if they don’t know what you need, and mostly, people don’t have time to guess. So it’s very important to have, at the very least, a visible list of “things I’ll be doing next.” A good, updated TODO somewhere prominent in the repo, perhaps.

But what if no one is looking at that TODO?

So then I thought, “it’s most important to be vocal.” And it’s true: being vocal is very important. People won’t follow you if they can’t find you, and the only way people can find you is if you talk about what you’re doing. Which doesn’t come naturally to a lot of people. So it’s very important to blog about what you do — to celebrate your victories and ruminate on your challenges.

But what if no one is interested in your victories and your challenges?

Which brought me, finally, to this:

It’s most important to be solving a problem that really matters to other people.

The oft-quoted chestnut about open source development is that it’s all about developers “scratching their own itch,” and of course this is absolutely true — but community only happens when other people have that same itch.

Maybe that’s not the most encouraging advice — “gee, you should have better ideas!” — but I think it really is at the heart of successful communities. Successful communities are passionately engaged in the pursuit of the same goal. If that goal isn’t an audacious goal, with some power to stir the blood, it’s just harder to engage people in its pursuit.

Which means that you should seek out other people who might share your problem, or even a problem like it, and you should talk to them about your ideas.  Such a simple thing — and so hard to do.

It’s hard, of course, because we cherish our own ideas.  It’s hard to listen to people shoot holes in those ideas. And they will — will they ever. Even with legitimately good ideas, you will always find people who will say “no”, often quite stridently. That’s okay. Remember that your goal is to find the people who say “yes”, or “maybe”, and if you can find even one or two people who passionately agree with your idea, that’s enough to justify continuing towards your grand solution.

And if you don’t find those one or two people? Well, it is possible that you’re way ahead of your time, and that you should continue to track your idea relentlessly — but I myself, in similar circumstances, have often found it useful to ruminate on the words of the great Richard Feynman:

“The first principle is that you must not fool yourself — and you are the easiest person to fool.”