June 2009

It’s really the Drupal community and not the software that makes the Drupal project what it is. Fostering the Drupal community is actually more important than managing the code base.”

Dries Buytaert, Drupal Project Lead

From the outside (and often times from within, too), the success of healthy open source projects defies all logic. Scores of individuals from all over the world, all of whom have different skill levels, use cases, experience, native languages, and time zones, collaborate together in order to help make a project succeed.

How is it that all of this chaos comes together and creates something wonderful and useful? What lessons can be taken from how open source projects work and applied to our practical, daily lives and organizations?

This article will attempt to extrapolate some of the experience gleaned from being immersed for over four years in the Drupal project. Drupal is an open source website building tool which has transformed from a small hobby project in 1999 to a robust framework powering hundreds of thousands of websites today. Behind the buzzwords "social publishing" and "content management framework" there lies a diverse, passionate, and vibrant global community. We present some of the key ingredients to the community's success, many of which can be applied to any organization.

Create a Great Community and Great Code Will Follow

The overriding mission for a healthy open source project is retaining and growing its base of contributors. The label "contributor" applies not only to the project's developers, but also to those who report bugs, review fixes, answer support requests, design interfaces, provide translations, help with marketing and evangelism, and write and edit documentation. Contributors are the lifeblood of any open source project as they drive the project forward.

It is vital to establish a fundamental understanding within the community that each of these types of contributions is an integral part of the overall project's health. Many key individuals who are driving forces within open source projects got their start by fixing typos in documentation or answering other users' support questions. A culture that values a well-written tutorial as much as a well-written application programming interface (API) is much more likely to attract and retain newcomers than a culture that values seasoned developers, or the marketing team, at the expense of everyone else.

Open source projects vary in their leadership models, from a “Benevolent Dictator For Life”–-a single project lead who has the ultimate veto on any decisions–-to more democratic, consensus-based systems, and everything in between. Often, leaders within an open source project spend most of their time encouraging and empowering individuals to drive the project forward themselves and then, to a large extent, get out of the way to let them work. Teams are encouraged to grow organically, thus spreading the work of leading the project around to a multitude of highly driven individuals. The term “cat herder” in used to reference the difficulty in managing a community of strongly independent individuals, each with their own motivations. As much as possible, decisions are made in the open, with active participation from as wide a swath of the community as possible, since a diverse range of opinions will naturally result in a more robust solution.

Empowerment: Transforming “Them” Into “Us”

The ultimate goal is to make it as easy as possible, and to provide as many ways as possible, for a “user” to cross the threshold into a “contributor.” Once this threshold is passed, several interesting things tend to happen. Individuals become more engaged and concerned about the project's future. Working directly with other contributors causes them to improve their skills and be exposed to new, horizon-expanding concepts, leaving them thirsty for more. They begin to form friendships and professional relationships with other contributors, strengthening their bonds within the community. Often, contributing can directly or indirectly lead to paid work which acts as another long-term retention tool.

So how does a project help users cross the contribution threshold? The most straight-forward way is to actively seek out and eliminate barriers to contribution. A driven member of the community must never encounter a situation where she wants to help the project improve and is told she does not have permission to do so. She must instead be given encouragement, pointed toward helpful resources, and paired with others in the community who have a similar itch. This allows her to complete work that is important to her, increasing her sense of ownership in the project, and to forge relationships with other contributors along the way, increasing her sense of kinship with the community.

It is important to make a distinction between barriers to contribution and the community processes that help guide those contributions. The goal is not complete anarchy, but zero on-ramp to get started. Processes should be specifically engineered to help support the long-term viability of the project.

In the Drupal project, as in most open source projects, improvements to the software may be contributed by anyone, but they are only added to the core software after the changes are peer reviewed. Aside from the rather obvious benefits that this process has on the quality of the contributions, the effect this peer review requirement has on the community is three-fold:

1. It actively fosters an environment of mentorship. Experienced contributors are highly motivated to help newer contributors to understand more complex areas of the software because it directly benefits them to do so. As they gain experience, new users become better equipped to help in the review.

2. It helps keep the overall community's IQ level high, as members are constantly exposed to areas of the software they may not have seen before. This naturally occurs because often the easiest way for a contributor to get their changes reviewed is to review someone else's in exchange. It also actively works to prevent less desirable and community-damaging personality traits from manifesting themselves. After all, people won't get the peer reviews they require to accomplish their goals by being arrogant, insulting, and demeaning towards others.

3. It is extremely helpful to document in as many mediums as possible (text, audio, video, interactive classes, etc.) the options available to people who want to help, and what methods they can employ to be most effective. The sooner a frustrated user realizes that there is only a collective “we" where each contributes whatever they can to make the project better, the sooner the transformation into contributor can take place. Users then learn to channel their frustration into an effective force for change.

Fight the Disease of Perfectionism

Many people are filled with trepidation about the idea of contributing to an open source project. The same peer review process that lends itself to building a strong community and great software can be terrifying to newcomers. Ironically, some of the people most affected by the paralysis of perfection are developers, the people in the best position of power to directly make sweeping improvements to an open source project. After all, thousands of people will be using their code and other developers will be carefully inspecting and evaluating its inner-workings. The discovery of an obvious bug or inefficiency by another developer can be easily interpreted as personally damaging to perfectionists, even when the intent is to make the code, and its contributor, better.

The natural problem-solving methodology for perfectionists tends to be withdrawal from the community and working quietly in isolation until they believe they've achieved something that is immune to criticism. This brings with it a whole host of problems, including:

1. Perfectionists never truly believe that their work is immune to criticism, because they can always find something that can be improved. In practice, their work can get permanently trapped in "analysis paralysis" and never see the light of day.

2. In the rare cases where the perfectionist feels that the ultimate, “immune to criticism” state is achieved, they can develop a deep emotional attachment to their contribution. This can lead to the perfectionist growing irrationally defensive, and rejecting or dismissing useful critique from their peers.

3. Working in isolation eliminates transparency, and removes the ability for other contributors to help. In a worst-case scenario, the larger community has already developed a solution to a problem in parallel by the time the perfectionist is finished, leading the perfectionist to extreme frustration, particularly if coupled with a deep attachment to their own solution.

4. Working offline until perfection is achieved naturally leads to fewer interactions with the larger open source community. These interactions are absolutely key to a contributor establishing their own expertise and personality within the community, which in turn directly impacts how well they are received by others. These interactions are also key to helping others understand the proposed solution so that they may provide reviews in the future.

It is vital to establish a strong culture of “release early, release often” where people are encouraged to throw solutions against the wall and find out what sticks. This results in increased visibility for individual contributors and a lack of attachment to any one solution so that the best possible solution is found.

Fighting perfectionism does not equate to compromising in quality. Perfectionists can still contribute improvements that are up to their enormously high standards, and the project still benefits. The key difference that separates healthy perfectionist contributors from unhealthy ones is the participation in a collaborative problem-solving process, rather than an introverted one. The community's processes should reward those who do the former, while encouraging those who do the latter to change their approach.

Back to the Real World

We have identified some elements of successful open source communities as well as some pitfalls to avoid. How does this information relate back to the practical, day-to-day lives of those managing businesses?

Focus on the people, not the product. A team that enjoys working with one another will naturally be more productive. Take a "mental health" check of the people on your team. Is there animosity brewing between two or more groups that could be solved by them working more closely together? Is decision-making in the hands of a single individual, hampering the feeling of ownership by other, capable people? Resolving these kinds of issues should take precedence over anything else.

Eliminate barriers for those who want to make improvements. Where not absolutely necessary for security or legal reasons, fight red tape in all of its forms. Remember that a frustrated person is often best poised to lead revolutionizing changes for the better as they have the motivation. Get the road blocks out of their way and empower them to get to work.

Fight the stagnation of perfectionism by encouraging collaboration. Put processes in place that help prevent perfectionists from getting trapped in their own heads, and get them working with others instead. Not only does collaboration help achieve a more robust solution, it can be used as a mentoring tool to help raise the collective IQ of your entire organization.

By applying some of the same principles that make open source communities successful, business owners can leverage some of the tremendous benefits of open source within their own organizations.

Share this article:

Cite this article:

Rate This Content: 
1 votes have been cast, with an average score of 5 stars