Safe as Milk

How do you count your community size?

April 1, 2009 5:07 pm Dave Neary community, gnome, maemo

Way back in the Maemo Summit in September 08, Jay Sullivan put up a slide which talked about spheres of participation in Mozilla.  I threw together a rough approximation of what was in that:

Communities are like onions or planets, with, at their core, the leaders who set the tone and direction for the community. Around this core,many more people contribute to the project with their time and energy, with code, artwork, translations, or with other skills. And beyond, we have forum members, mailing list participants, people on IRC, the people who gravitate to the community because of its vision and tone, and who make the project immeasurably better with their enthusiasm, but who individually don’t commit as much time, or feel as much ownership of the project, as those I mentioned before. Finally, the there is user community, the people who benefit from the work of the community, and which is orders of magnitude bigger.

The boundaries between these levels of involvement are diffuse and ill-defined. People move closer to the center or further away from it as time goes on. A core maintainer gets married, has a child, changes jobs, and suddenly he doesn’t have the time to contribute to the project and influence its direction. A young student discovers the community, and goes from newbie to core committer in a few months.

But the key characteristic to remember is that at the inside we have people who have gained the trust of a large part of the community, and significantly, of the other members of the community at the core. Contribution breeds trust, and trust is the currency upon which communities are built.

Last week as OSBC, I heard different companies claim that they had very large communities of developers, but when I asked about this, they meant people contributing translations, signed up to user forums, downloading SDKs, or developing plug-ins or extensions. When I bore down a little and asked how many were committers to the core product, the impression I got was always the same: very few – because these companies, built up around a niche product, build their business case around being the developer of the product, they require copyright assignment to the core, and becoming a core committer is difficult, if not impossible, if you don’t work for the company behind the project.

So I ask myself, what is the best way to count the size of your developer community? Do you include the orange ring, including translators, documenters, artists, bug triagers and developers who submit patches, but aren’t yet “core” developers? Just the red ring, including maintainers and committers to core modules? Or would you also include all those volunteers who give of their time to answer questions on forums and on mailing lists, who learn about and evangelise your product?

For a project like GNOME, I think of our community in the largest terms possible. I want someone who is a foundation member, who comes along to show off GNOME at a trade show, but has never developed a GNOME application, to feel like part of the GNOME community. I consider translators and sysadmins, board members and event organisers a vital part of the family. But none of these set the direction for the project – for that, we look to project maintainers, the release team, and the long-time leading lights of the project.

I think that you need to separate out the three distinct groups. Your core developers set the direction of the project. Your developer community might include extension developers, documenters, and other people who improve the project, but who do not set the direction for the core (some companies might call this their “ecosystem”). Finally, we have the contributor community, which includes people signed on to mailing lists and forums.

When considering how viable a community project is, calculate the bus factor for the red bit, your core developers. Is there one core maintainer? One company hiring all of the core developers? Then the risk involved in adopting the project goes up correspondingly. The breadth of your contributor community will not immediately fill the gap left if all the core developers disappear.