Open Source Community Growth as a User Experience Problem

Location: D138 Level: Intermediate
Average rating: ****.
(4.25, 8 ratings)

Most open source projects have a pool of enthusiastic users who could transition to effective contributors if you can phrase the invitation in a way that captures their interest and is clearly actionable. How do prospective contributors discover how to join in? What causes them to feel invited?

We begin by examining basic concepts of usability: The more steps a user must follow, the smaller the chance of success. Assumptions about prior experience shrink a product’s potential audience and create diversity problems. Feedback and clear indications of progress make users more likely to stick with a complex process.

These tenets hold true for users of an open source project trying to land a patch, submit a translation, or join their first open source community. With this in mind, we analyze four efforts to grow the community around an open source project.

We provide a friendly critique of a two open source projects’ “Get involved” processes: one that needs substantial improvement, and one that gets lots of things right. By highlighting one project’s hidden assumptions, we explain how prospective contributors can be dissuaded from making and sharing changes. We also show where Dreamwidth’s process addresses these problems.

We then review the Fedora Design Bounties, a novel outreach program run by the Fedora Design team. Unlike cash bounty programs, the prize here is inclusion in the community. This ongoing outreach effort identified and retained one new contributor per quarter in 2011.

Finally, we look at how projects such as GNU MediaGoblin and WordPress use the new OpenHatch training missions to bring new contributors up to speed. This open source interactive web app teaches common free software tools like using diff, patch, tar, version control, and IRC through short concrete tasks and instant web-based feedback. The missions have been used by more than 1000 unique people so far, helping prospective contributors gain skills without embarrassing themselves and saving veteran developers from teaching basic skills or rejecting well-meaning patches.

In open source software, contributor enthusiasm is a precious resource. This talk is not primarily about technical tools; it is about communication strategies that create or drain enthusiasm. Prioritizing friendliness to new contributors (to the short-term detriment of new software features or other goals) may require a cultural shift in a given project. However, by applying these concepts to your project’s structure, you’ll retain and engage prospective contributors, improving the health of your project in the long run. We will also discuss the changes in diversity characteristics that come from these approaches.

We look forward to a hearty discussion with the audience on how to apply these principles and strategies in their own projects.

Photo of Asheesh Laroia

Asheesh Laroia

Sandstorm Development Group

Asheesh loves growing camaraderie among geeks. He chaired the Johns Hopkins Association for Computing Machinery and taught Python classes at Noisebridge, San Francisco’s hackerspace. He realizes that most of the work that makes projects successful is hidden underneath the surface.

He has volunteered his technical skills for the UN in Uganda, the EFF, and Students for Free Culture, and is a Developer in Debian. Until recently, he engineered software and scalability at Creative Commons in San Francisco; today, he works at OpenHatch as its project lead.

Karen Rustad


Karen is a master’s student at UC Berkeley’s School of Information, with interests in Python-based web development, user experience design, free software communities, and technology law and policy. She has been involved with OpenHatch since near the beginng in 2009, contributing to the project’s design, codebase, and mission. She served previously on the board of Students for Free Culture from 2005 to 2008.

Comments on this page are now closed.


Picture of Shane Curcuru
Shane Curcuru
07/17/2012 3:37pm PDT

With many of the diverse backgrounds in most open source communities today, ways that you can allow those grumpy old coders to continue working while also allowing those community mentors and evangelists to really do this work of drawing in newcomers are key. There’s a small and effective limit to how many new/different mailing lists or other communication channels a project can use – but finding ways for the RTFM’ers to keep out of the way of the outgoing mentors is important.

Love the training missions idea. Wondering how re-purposeable it is to other project’s workflows. I.e. if we also use JIRA and Subversion (or whatever), can we simply link our project’s Get Involved site directly to the classes, or are modifications needed for perhaps our specific SVN version (or whatever)?


For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at (707) 827-7065 or

View a complete list of OSCON contacts