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.
Comments (2 posted)
I'm reminded of my sister's 3-year-old child "helping" with the
cooking: good for the kid's development, but not necessarily for
the dish and certainly not less effort for the parent. We don't
have the time to play parent to all our users and we shouldn't try.
-- Ian Jackson
So the Gnash team is broke, and has been for most of a year. This
has forced many, but not all of the Gnash developers to find paying
work, and mostly stop working on Gnash. The few of us left focused
on Gnash like to eat and pay bills.
-- Rob Savoye
Comments (3 posted)
The KDE software collection has a new BlueTooth stack
called "BlueDevil." "This release should be stable enough to be used by everybody, but were looking specially for advanced users with 'compiling skills' so we can get quick feedback and fix as many bugs as possible.
Comments (3 posted)
Dave Neary has posted the highlights
of his work
to determine where contributions to GNOME come from.
"While over 70% of GNOME developers identify themselves as
volunteers, over 70% of the commits to the GNOME releases are made by paid
contributors. Red Hat are the biggest contributor to the GNOME project and
its core dependencies. Red Hat employees have made almost 17% of all
commits we measured, and 11 of the top 20 GNOME committers of all time are
current or past Red Hat employees. Novell and Collabora are also on the
Comments (34 posted)
The much-anticipated release of GNOME 3.0—scheduled for
September—has been pushed back to March 2011 due to quality issues in
the code. The announcement was made at GUADEC
and developers' European conference), which is being held July 26-30 in The
Hague, Netherlands. There will be a GNOME 2.32 release in September along
with GNOME 3 beta. GNOME 2.32 will have the usual
performance enhancements and bug fixes along with a new control
center design, UPnP, and color management support. The extra time will be used to improve GNOME
Accessibility support, GNOME Shell, and documentation for GNOME
3.0. There should be a press release on the GNOME web site
too long, stay tuned.
Comments (28 posted)
Gemini Mobile Technologies has sent out a
announcing the availability (under the Apache license) of
"Hibari," a non-relational database, implemented in Erlang. "Hibari
is a database optimized for the highly reliable, highly available storage
of massive data, so-called 'Big Data.' Hibari can be used in Cloud
Computing Applications such as web mail, Social Networking Services (SNS),
and other services requiring storage of tera-bytes and peta-bytes of new
Comments (5 posted)
Guido van Rossum has put together a set of impressions from his recent
experience at EuroPython; they are a good read for anybody curious about
the future direction of the Python community. "This made me think of how the PEP process should evolve so as to not
require my personal approval for every PEP. I think the model for
future PEPs should be the one we used for PEP 3148 (futures, which was
just approved by Jesse): the discussion is led and moderated by one
designated "PEP handler" (a different one for each PEP) and the PEP
handler, after reviewing the discussion, decides when the PEP is
approved. A PEP handler should be selected for each PEP as soon as
possible; without a PEP handler, discussing a PEP is not all that
useful. The PEP handler should be someone respected by the community
with an interest in the subject of the PEP but at an arms' length (at
least) from the PEP author.
Full Story (comments: none)
Tim Golden has posted a report from the Python Language Summit, recently
held in Birmingham. "The PyPy guys also announced a C API bridging layer which should enable
a range of Python extension modules to work directly with PyPy. This is
only a stepping stone by way of broadening support. Brett [Cannon] suggested that
the Unladen Swallow merge to trunk was waiting for some work to complete
on the JIT compiler and Georg [Brandl], as release manager for 3.2, confirmed that
Unladen Swallow would not be merged before 3.3.
Full Story (comments: 2)
Version 0.6.0 of QuteCsound is out with a long list of new features. "QuteCsound is a frontend for Csound featuring a highlighting
editor with autocomplete, interactive widgets and integrated help. It
can open files created in MacCsound, and aims to be a simple yet
powerful and complete development environment for Csound.
Full Story (comments: none)
The final 1.0 release of the Sphinx documentation tool is out; new features
and support for output in the EPub format. LWN looked at Sphinx
back in June.
Full Story (comments: none)
The fifth systemd release is out. "This includes a fairly major interface change. After some longer
discussions on fedora-devel systemd-install is now folded into systemctl
and greatly simplified in its invocation.
Full Story (comments: 1)
Newsletters and articles
There was exactly one development newsletter in the LWN mailbox this week;
everybody else must be on vacation.
Comments (none posted)
The Chromium Blog has announced
an accelerated pace for Google Chrome stable releases. "The first goal is fairly straightforward, given our pace of development. We have new features coming out all the time and do not want users to have to wait months before they can use them. While pace is important to us, we are all committed to maintaining high quality releases - if a feature is not ready, it will not ship in a stable release.
Comments (29 posted)
Free Software Magazine looks
at the use of MediaWiki by the Morevna Project. "Putting together a
collaborative film production involves a lot of bits and pieces. Workflow
is unclear at the beginning, and has to be developed organically. That
argues against putting too much structure into the software that you use -
otherwise it would straightjacket you. Furthermore, when you're working on
an artistic project, you don't want to waste time developing (or fixing)
software that doesn't work like you need it to. So it makes sense to use
something that is well-tested. So, really, MediaWiki is a
" (LWN covered
Morevna Project last March.) (Thanks to Paul Wise)
Comments (3 posted)
The Diary Of An x264 Developer has an introduction
to ffvp8. "Back when I originally reviewed VP8, I noted that the official decoder, libvpx, was rather slow. While there was no particular reason that it should be much faster than a good H.264 decoder, it shouldn't have been that much slower either! So, I set out with Ronald Bultje and David Conrad to make a better one in FFmpeg. This one would be community-developed and free from the beginning, rather than the proprietary code-dump that was libvpx. A few weeks ago the decoder was complete enough to be bit-exact with libvpx, making it the first independent free implementation of a VP8 decoder. Now, with the first round of optimizations complete, it should be ready for primetime. I'll go into some detail about the development process, but first, let's get to the real meat of this post: the benchmarks.
Comments (none posted)
Page editor: Jonathan Corbet
Next page: Announcements>>