OSCON: Building communities

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 communities.

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 suffering together."

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? Unlikely.

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:

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:

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.