LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentOSCON: Building communitiesHow 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 CommunitiesGiven 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 ContributionsLaroia 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.
Brief items Quotes of the week
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
BlueDevil: a new KDE bluetooth stackThe 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."
Neary: GNOME CensusDave 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 podium."
GNOME 3.0 release delayedThe 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 (GNOME users' 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 before too long, stay tuned.
Hibari "big data" database releasedGemini Mobile Technologies has sent out a press release 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 daily data."
van Rossum: Thoughts fresh after EuroPythonGuido 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."
Report: Python Language Summit at EuroPython 2010Tim 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."
QuteCsound 0.6.0 releasedVersion 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."
Sphinx 1.0 releasedThe final 1.0 release of the Sphinx documentation tool is out; new features include domains and support for output in the EPub format. LWN looked at Sphinx back in June.
Systemd v5 releasedThe 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."
Newsletters and articles Development newsletters from the last weekThere was exactly one development newsletter in the LWN mailbox this week; everybody else must be on vacation.
Release Early, Release Often (The Chromium Blog)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."
MediaWiki and Script Translation for the Morevna Project (Free Software Magazine)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 no-brainer." (LWN covered the Morevna Project last March.) (Thanks to Paul Wise)
Shikari: Announcing the world's fastest VP8 decoder: ffvp8The 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."
Page editor: Jonathan Corbet |
|||||||||||||