How do you build a successful community that attracts contributors? Two
talks at OSCON offered very good advice on the topic: "Secrets
of building and participating in open source communities" by Drupal
founder Dries Buytaert, and "Junior
Jobs and Bite-sized Bugs: Entry Points for New Contributors to Open
Source," which was co-presented by Mel Chua of Red Hat and Asheesh
Laroia of OpenHatch. Both presentations
offered some worthwhile insight and tips on building community.
To be sure, these weren't the only talks focused on the fine art of
community management. However, Buytaert's talk seemed worthwhile to attend
because it's obvious that Drupal does enjoy a healthy community of
contributors, and the "junior jobs" presentation seemed worthwhile because
it was focused on practical techniques for dealing with an obvious problem
for any community, rather than being of the hand-wavy motivational
community talk variety.
Secrets of Building Communities
Given that community management is a well-covered topic, one might be
skeptical about a presentation that promises to teach "secrets" of building
community. And, indeed, Buytaert's presentation was less revelatory than
the title suggested. But Buytaert did, in fact, offer very useful advice
and insight into the success of Drupal that might well apply to other
He started with a rundown of Drupal's success so far. According to
Buytaert's statistics, Drupal sites account for about 1% of Web
sites. Drupal is downloaded about 300,000 times per month, and Drupal.org
sees about 1.5 million unique visitors per month. He also said that Drupal
has more than 6,000 modules. All of which point to a project that's doing
something right, but what? Buytaert offered several pieces of advice or
wisdom for the audience.
First, Buytaert advised that there's no "quick rich" formula to build a
community. When growth does happen, the second tip was to embrace growing
pains. Buytaert pointed to an incident with Drupal in 2005 when Drupal's
server was pushed to its limit and couldn't handle the traffic it was
receiving. Buytaert said that it made the Drupal community stronger, and
that "communities are always a bit broken. Nothing better than
Next, he offered two pieces of concrete advice: provide the right tools,
and provide a architecture of evolution. He suggested that any project
should have a modular design, and favor accessible technologies like PHP
and MySQL (if appropriate) rather than languages or technology that are
perhaps better but less accessible. Drupal has succeeded in part because
PHP and MySQL are so commonplace. Would Drupal have flourished to the same
extent if it was written in Perl and used a less popular database?
Buytaert offered one unusual "secret": build a commercial ecosystem.
But he also suggested that projects
needed to "find a higher purpose" while striving to make money. For
instance, he offered Drupal's goal to democratize online publishing, and
Mozilla's goals for an open web. Both initiatives that have powered a
commercial ecosystem, but still meld well with open source communities.
Enabling Bite-sized Contributions
Laroia and Chua have a fair amount of experience working with new
contributors. Chua spends a great deal of time working with the Fedora
community. Laroia works on OpenHatch, a
project that helps connect new contributors to projects by breaking bugs
and projects down into small and introductory chunks.
The start of the Junior Jobs presentation was slightly unorthodox. Chua
and Laroia asked the audience to be "productively lost" and explore some
project sites looking for the the bug tracker to find bugs to work on or
other resources that a new contributor might seek out. The audience, about
20 people, gathered in pairs or small groups and checked some popular
project sites like Sugar Labs, the Fedora Web site, and other mainstream
open source projects.
The audience, predictably, discovered that finding the way around open
source project sites for contributor resources was not always a simple
exercise. Even when a contributor can find the bug tracker, it may take a
translator to help them understand the information. One example given was
the "UNCO" status in GNOME's bugtracker, which wasn't immediately obvious
as "unconfirmed" to some of the audience at the talk. New contributors are
not going to experience the sites like longstanding contributors who know
where to look — and probably have deeply buried resources bookmarked
for fast access.
Part of the problem is that tools and documentation that are helpful to
experienced contributors may not be so useful for newbies. As an illustration,
they talked about cookbooks and the difference between a cookbook useful
for new cooks and one useful for an experienced cook. It might be necessary
to explain "rolling boil" and what it means to "fold" an ingredient in to a
mix for a beginning cook, but but such explanations are only frustrating to
an experienced cook.
Looking for pointers for your project? In talking with Chua and Laroia
after the presentation, they offered Dreamwidth
as a prime example of a project that does well in attracting new and
diverse contributors. Chua also pointed to Drupal's Dojo for its classes on how to
get started with Drupal contribution, and the Fedora How
to be a successful contributor document. Chua also noted that each
community has to forge its own path:
You can't point to specific
wiki pages and say 'these words are all you need to make it easy for new
contributors to join' - it's about the human dynamics of the community, and
that's hard to capture in static form.
The overall message of this presentation should be heeded
by any project that looks to attract contributors who are new
to contributing to open source projects. Breaking down tasks into
"junior jobs" or easy-to-tackle bugs is fine, but that's only so useful if
the sites are difficult to navigate or the bugtracker is confusing.
Chua recommends thinking of FOSS contributions more broadly:
It may be helpful to think of FOSS contributions as being towards
not just a codebase but a *community* that includes and is centered
around a codebase — so you can patch the code, but you can also
patch the tests and docs and processes and how the technology you're
building and the people you're building it with interact with the rest
of the world.
Over all, the dominant message of the presentation was to communicate
with new contributors and try to anticipate how newcomers will view your
project. As Laroia said during the close of the talk,
"Communicate. It can't make things any worse." While not a
definitive guide to community management, it's a good first step.
to post comments)