Community Building

A couple of months ago I blogged about the challenges faced by community projects. Something one of my friends who works on a mutual community project with myself and others wrote has driven me to write a little bit about what works well with community projects, because what he wrote resonates with a lot of my experiences:

[Our] volunteers come from varied backgrounds. Our earliest graphics work and page layout was done by someone going to medical school (cutting and slicing cadavers in the morning and slicing and dicing page-layouts/photographs at night). Our resident layout maestro who has a knack of determing browser bugs via impressive test-case reduction is an economics graduate. There are the usual suspects who have some paperwork by which they claim to know Computer Science 🙂 but they are very much a minority.

When I read this, I couldn’t help but also think of the Mozilla community, which is comprised of a hugely diverse set of people with varied backgrounds and interests, but all of whom share a common goal. When you look at a project like Firefox (or really any community project), I think there are two major (and related) barometers of its health:

1. The ability of a project to draw contributors from outside its immediate field
2. The ability of a project to harness the capabilities of its contributors and channel it into useful activity

The first of these has to do with the pull that a project has on people who have no intrinsic connection to it. One of the reasons that Firefox has been so successful is that it has drawn people who would not ordinarily be interested in a web browser and made converts out of them. Not only has it made converts, but converts who believe strongly enough in the software that they are willing to donate their time in order to make it better. It’s pretty easy to convince a developer that tabbed browsing is a great idea, but a lot more difficult to convey the same message to others. Yet, to a large extent Firefox has succeeded in this; and it has certainly succeeded in drawing active contributors, many of whom have never taken part in an open source project before (or any software project for that matter).

The issue of contributors aside, why has growth slowed from how quickly it was growing before? Because for the majority of web users, a web browser is boring. Users don’t care what program you enter the URI into, as long as the page loads. Apathy is now the biggest the biggest barrier, because now we have to win over the segment of users for whom computers are not a passion, but simply a tool (or even worse a chore). How does one win over the masses of people for whom anything to do with computers is executed from rote memory, rather than any sense of intuitive understanding (don’t underestimate the size of this group). Do we even want to cater to this group? I don’t really have a good answer for either of these questions.

The second barometer, how a project harnesses the eagerness of its potential contributors is really the crux. My understanding of Firefox contributors is that you can categorise them into four broad groups:

1. Highly skilled, paid contributors
2. Highly skilled, unpaid contributors, who donate significant amounts of time
3. Less skilled, but enthusiastic and eager to learn unpaid contributors, who donate significant amounts of time
4. Less skilled (or unskilled) unpaid contributors, who want to help in a small way that doesn’t require a large commitment

As always, the first three groups combined do the lion’s share of the work, but are always outnumbered by far by the fourth group. The first three groups can work without hand-holding and still work productively. It is the fourth group who need channeling. Because they want to help out in the short-term or just as a one-time thing, they often do not have an understanding of the project, and thus their genuine efforts are misdirected. As a worst case scenario, their attempts to assist can actually hinder the first three groups from going about their work. I remember during early 2004 when Firefox was picking up steam, all of a sudden Bugzilla’s “Today’s Bugs” lists became a swamp of rubbish, and significant efforts were required to parse through and sort out the useful from the garbage. A perfect example of misdirected efforts—people trying to help but actually hampering progress.

The situation has improved significantly. Efforts have been made to channel contributions to where they are most helpful, and as a result Reporter and Hendrix now exist. Systems such as these not only channel efforts to where they are required, but also provide useful information in aggregated form to the skilled contributors who are in a position to act on the feedback. When channeled in this manner, the fourth group of contributors become enablers. They provide supplementary data that helps the skilled contributors to triage problems and improve the product.

How well the capabilities of these passerby contributors is harnessed can make the difference between creating a group of enablers and creating pandemonium.

Going back to where I began, I think it is clear that variety amongst contributors is a hallmark of success. However, with variety comes a necessity to actively manage contributions so that they are complementary to each other.

The original post that sparked this one is part of a relatively new blog that talks mainly about the technical considerations that have gone into creating a community website and server infrastructure.