How do you count your community size?

5:07 pm 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:

Spheres of participation

Spheres of participation

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.

4 Responses

  1. Jef Spaleta Says:

    I think where you draw the line for each ‘class’ gets really difficult.

    I saw a talk this past week which presented this sort of thing as a community pyramid to set expectations on project health.

    1% – developers:
    code/content that ships as
    parts of “releases”

    official docs, translations can
    fit in here

    9% – feedback:
    mailinglists, forums, bugs,
    testers, triage

    They close the loop between
    consumption and creation. They
    inform the development path,
    but do not choose it.

    90% – users:
    consumers who use the
    output of the other 10%

    Does that pyramid concept hold up?
    Are the healthiest projects able to “top load” their project and beat the 1-9-90 construct?

    That 90 % is a pretty touch metric to get a handle on in open projects. But can projects get a sense of that 1-9 split in the top 10% in the pyramid. Are the healthiest projects close to that mark? Can you have too many developers compared to feedback? You can certainly have too few.

    -jef

  2. Dave Neary Says:

    Hi Jeff,

    Indeed, I’m familiar with the 1/9/90 proportions. I would go further and talk about 0.1/0.9/9/90 – the 0.1 is the tiny proportion of your community that contributes the majority of the code, the 0.9 contributes the rest of the code and everything else which makes your project a nice product (translations, docs, packaging, bug fixes, …).

    I don’t think many projects beats the 1-9-90 construct – perhaps some projects which are destined for developers like, say, Zope get a slightly larger developer community (what you might call the ecosystem) compared to its user population (but then it all depends on how you define users, I guess). What some projects do succeed in doing is growing the size and variety of the 0.1 in the middle, and growing all of the other segments in consequence. Including the number of end users.

    Cheers,
    Dave.

  3. thp Says:

    cat /path/to/maemo-community-mailing-list-archives/*.mbox | grep “^From:” | sort | uniq | wc -l

    (and do the same for the other mailing lists)

  4. Safe as Milk » Blog Archive » Designing an obstance course Says:

    […] that a new contributor to your project jump through some hoops to learn the ways of the community. Communities are layered according to involvement, and the trust which they earn through their involvement. You don’t […]