The previous chapter discussed participants' motivations for joining and contributing to an open source project. Any number of motivations may compel someone to participate in an open source project. Some may be extrinsic (like promise of monetary compensation for their contributions); others may be intrinsic (like an altruistic desire to contribute to community-developed software). Whatever the nature of these motivations, community managers and architects need to understand them—because when they do, they can better design their projects and communities to be more rewarding for current and future participants—and better encourage the forms of contribution they most wish to see. In this chapter, we’ll discuss various models and mechanisms for encouraging, incentivizing, and rewarding the kinds of behavior most helpful to a thriving open source project and community.
Open source community managers and architects strive to create places where participants feel valued for the contributions they make. When contributors feel as though their work matters, they’re more likely to continue contributing to a project, enhancing the community and impacting its culture as they do. Contributors derive the most value from participating in an open source project when the project satisfies or otherwise rewards their motivations for contributing in the first place. For community architects, the crux of the challenge in creating rewarding contributor experiences is aligning participant motivations with various models and mechanisms for rewarding project contributions.
But not everyone contributres to open source projects for the same reasons. For example, recent research on motivations for contributing to open source projects suggests that altruism and kinship-seeking impact contributor motivations more significantly than they did a decade ago. Moreover, participants report that their motivations for continuing contributions to a project aren’t always the same as their motivations for initially contributing to a project. Someone may join a project in order to contribute a patch her employer wanted to see adopted upstream, but remain in the project after identifying project participants as a peer group and developing a sense of kinship with members. Building open source communities involves responding to contributors' continually shifting motivations for participating with new activities and opportunities from which they might derive value, incentivizing them to continue contributing.
Not every contributor to your open source project will develop a deep level of investment in the project. You won’t always be able to convert infrequent, casual contributors into consistent, repeat contributors—nor should that necessarily be your goal. More important is understanding how participants' contributions align with or reflect their motivations for making those contributions—and responding accordingly. As researcher Ann Barcomb writes, "People who contribute to boost their CV or to fix an irritating bug are less likely to continue once their need is satisfied." Alternatively, however, these periodic contributors (or what Barcomb calls "episodic contributors") often seek low-complexity, easily explainable, and quickly addressable issues—the very kinds of issues long-time contributors would love to see others solve so they can focus on other matters. Community managers therefore shouldn’t strive to create experiences they believe will motivate everyone to join and contribute to the project as much as they should work to understand participants' own motivations for contributing to projects, then architecting project experiences that activate and satisfy those motivations, leading (presumably) to greater engagement. This is critical not only because it puts community members and their needs first, but also because it allows contributors with varying degrees of time, resources, knowledge, and skill to engage a project in ways that feel comfortable for them—and feel rewarded in just the same ways others might.
Strategies for acknowledging and honoring various contributions to an open source project are called that project’s "reward models." The more reward models your project constructs, the better it can engage participants with differing motivations for contributing. As we’ve already noted, everyone contributes to projects for different reasons, and the most popular projects are those that make contributors feel rewarded, valued, and respected for their contributions—whatever form they happen to take. Generating those feelings in contributors is a great way to build your project’s reputation as a rewarding, welcoming place. But always remember that your community’s reward models will incentivize the very practices they reward; when people understand how a community recognizes and honors its participants, they’ll engage in the behaviors they observe a community celebrate in this way. Community managers and architects should therefore always think carefully and act deliberately when establishing and modifying a project’s particular reward model. What they reward—either intentionally or unintentionally—is what they’ll be encouraging people to do more of.
In what remains of this chapter, we’ll outline some of the more popular reward models open source projects use today. As each of these models aims to connect with a certain set of motivations participants may have for contributing to a project, we’ll elaborate situations in which a particular model might be most useful.
Some open source communities feature point, badge, and leaderboard systems that allow participants to track and publicly display a history of contributions to a project. For example, a community might maintain a list of "top contributors" or contributors "most active this month" in order to generate lighthearted competition that spurs project contribution. To do this, it might assign point values to project activities it seeks to elicit (fix a typo in documentation, submit a patch, assist a new user in a forum, etc.), then reward people who engage in those activities with the corresponding points (which, when tallied, determine contributors' ranking on the community leaderboard). In fact, some code-sharing and collaboration platforms provide this kind of "leaderboard" functionality as a feature; GitHub repositories, for example, feature an Insights tab that highlights a project’s most active contributors. Alternatively, a community might create unique digital tokens or "badges" contributors receive when they’ve completed particular activities or accrued a certain number of points (see the Fedora Project for a popular example of this reward model).
Point systems, badges, and leaderboards chart and publicly identify contributions, rewarding participants by visualizing the magnitude of those contributions. This reward model is useful for connecting with contributors motivated by a desire to showcase their technical prowess (it lets them telegraph the depth and breadth of their contributions), even document their history with a project as a means of building a public resume. In short, it’s one way to help contributors develop their reputations in a community. It’s also useful for maintainers who wish to easily identify and further engage with a project’s most active contributors.
But leaderboard systems might also be demotivating for participants. "Contributors who enjoy competition and like to engage in activities counted for the leaderboard’s scoring, the desire to be on the leaderboard can inspire increased participation," writes community metrics expert Georg Link. "However, contributors who participate in ways that don’t get counted in the scoring would not have any chance of showing up in the leaderboard and might be discouraged by it." Link explains that leaderboard systems only reward the activities project maintainers choose to reward—an implicit statement about which types of contribution it deems more valuable than others. And all potential contributors have the time, talent, or resources to contribute in precisely those ways. "Consequently," Link says, "leaderboards can worsen the issues open source faces regarding creating a welcoming and inclusive environment [as] only a specific subset of contributors can be rewarded by leaderboards, regardless of how well they are designed."
You might reward contributors by gifting them various items that signify their affiliation with the community. For example, you might consider giving shirts, hats, stickers, or keychains featuring the project’s logo to participants in order to enhance their sense of connection with the project. If your community features a leaderboard-style reward model (see previous section), it might tie receipt of a particular branded item to some achievement on that board ("receive a community-branded t-shirt when you’ve collected 100 participation points"). This reward model is especially useful when you want to connect with contributors who derive a strong sense of identity from participating in the project and associating with its community. In this way, receiving items that allow them to publicly express their affiliation with an important peer group—or signal their status within that group—might motivate them to contribute to a project.
This reward model often requires substantial resources, however. The work of packing and shipping branded items to members of a global community can be time-consuming. Moreover, production and distribution of branded materials can involve significant monetary expenses.
Community spotlights and awards help you showcase the people who make your communtiy great. Some open source communities publish occasional blog posts or run video series to spotlight contributors who have made significant impacts on the project. For instance, they might feature a monthly "Meet the Contributors" or "Community Spotlight" series that highlights key contributors, allowing them to tell the community more about themselves. Other communities might develop an annual award series, recognizing a "Contributor of the Year" or "Most Valuable Maintainer." The project might then feature award winners at events or in featured interviews posted online.
Because this reward model involves opportunities for gaining visibility, it’s useful when you know participants are motivated by a desire to enhance their personal reputations and grow their professional networks. The model is also particularly useful for attracting and retaining diverse contributors. Communities spotlighting contributors from under-represented groups provide a way for new, potential contributors from those groups to "see themselves" in their projects and feel more confident joinging them. Moreover, when communities allow members themselves to nomiate, vote for, and honor their peers, they reinforce communal values and strengthen social bonds. So implementing this reward model can also help you connect with contributors who see community participation as a way to form bonds with others, to feel a sense of group belonging, and to feel connected to a purpose.
Note, however, that choosing to showcase certain contributors creates the impression that those contributors embody the principles and enact the behaviors your community finds most valuable—and that more contributors should aspire to emulate them. Additionally, communities that implement this reward model might be accused of "playing favorites" or creating an insular culture. To mitigate this, you may wish to formalize and publish a basic process by which your community selects members to spotlight or receive awards.
One simple way to reward contributors to your open source project is to grant them additional rights, responsibilities, and privileges in the project. This might include, for example, appointing them as project maintainers, nominating them for a steering committee, elevating their permissions in the project’s code repository, or allowing them to take charge of the project’s social media account. In this way, contributors who feel most connected to a project can deepen their investment in it and enhance their sense of responsibility for its success.
This newfound sense of empowerment can also spark key community evolutions. For instance, as members of the Open Organization community neared the project’s fifth anniversary, they "began to feel … stagnant," as "[c]ore contributors—many who had been with the project from its inception—began feeling like their efforts weren’t having the impact they should have been. They were searching for new ways to grow, stretch, and move the project forward." The project knew it "faced a challenge of social economy" that prompted it to ask critical questions, like "What are contributors investing in the community? Why? What were they hoping to earn, or feel as a result of their precious investments (investments of time, energy, passion, and crucial knowledge work)? And was the community structured to catalyze, recognize, and reward those investments?" So the project created new maintainership permissions and installed longstanding members in them, providing key contributors with more influence over the project’s future.
Note that this reward model involves incentives with far-reaching and potentially irreversible consequences, as rescinding rights and privileges that you’ve granted to contributors can be difficult.
Sponsoring contributors' travel to (even accommodations at) industry events or professional conferences is another way to reward participation in a project. As project members deepen their investments in a project and community, they will frequently seek opportunities to speak about the project in these contexts—and to meet, share with, and learn from contributors from other projects.
This reward model is therefore especially appropriate when you know that a contributor is motivated by a desire to expand a professional network. It’s a way to invest in contributors' personal and professional development, recognize that their participation in the project is part of their overall plan for self-improvement, and invite them to assume a more public-facing role assisting project growth.
Of all the reward models we’ve surveyed so far, this one likely requires the most resources. Simply put: it can be monetarily expensive. It’s also a labor-intensive reward model, as it often requires complicated logistical work (purchasing, scheduling, coordinating, etc.) on behalf of project maintaners or other leaders.
This chapter has explored the importance of community reward models, strategies for acknowledging and honoring various contributions to an open source project. Community managers and architects construct compelling community experiences when they help communities implement reward models that resonate with contributors' motivations for participating in a project. This chapter also described multiple reward models and discussed benefits of drawbacks of each. The more reward models a community can feature, the greater its chances of channeling enthusiastic participation from contributors with various backgrounds, motives, and talents. In the next section, we’ll examine how to deepen contributors' engagement with a project.