Hi Im Rich Sands, the Product Manager for Ohloh.net, Black Ducks directory of FLOSS projects and people. Ohloh has been using some game mechanics since its inception to help people understand how projects compare on their development activity and popularity, and to help understand developers varying contributions to FLOSS. But Im not here today to talk about comparing projects and people to each other. Rather, Id like to focus in on how gamification can help project facilitators and evangelists to encourage both more participation, and the right kinds of participation.
So what is gamification, anyway?*This! Looks like fun, doesnt it?*Well, not really what Ive got in mind. A lot of the negative feeling Ive heard towards gamification in FLOSS is this misperception that it means turning contributions into competition, and using attention-grabbing gimmicks to hook people into doing stuff they maybe dont want to do, and ultimately fostering an unwelcome atmosphere within projects.*So what is gamification, then? It is about getting people to participate by giving them the feeling that their participation is valued and matters. It is giving people the information they need to better understand the impact of their contributions, and how they could have even more impact. And it is also about motivating people to work together to do things.
Humans are naturally competitive, and developers care how other developers and those viewing projects from the outside percieve their work. Anyone who thinks that FLOSS is somehow above that basic human instinct is fooling themselves, and missing an opportunity to both make FLOSS more engaging and fun, and to help drive forward momentum.
Gamification is not just about keeping score and establishing metrics on which developers can compete. If you can measure something, you can motivate it through gamification. That includes cooperation, learning, encouraging new people, and all the less glamorous activity that is essential to the day-to-day growth and success of a project.*Gamification is actually very familiar we see it on the web every day on popular sites and services. People use friendly competition, goal-setting, and tracking to help motivate healthy behaviors like exercise, good dietary choices, and management of chronic diseases, and sites like Strava for bicycling, Nike Plus for general exercise, and meyouhealth.com for health and well-being lifestyle improvements have proven to be effective. Most of us are familiar with Likes on Facebook, the profile completion score on LinkedIn, and social influence sites such as Klout, which help us better engage with our social circles and understand how were connected. In eCommerce, ratings and reviews and seller ratings are familiar reputation indicators that help us buy and sell stuff. FLOSS development is already gamified to a degree, with sites and tools such as ohloh.net, coderwall.com, stackoverflow.com, Ubuntu Accomplishments and Mozillas Open Badges project all letting developers gain recognition for their FLOSS work.
Gamification has become a mainstream technique, for good reason: it works to drive engagement.*It is a truism that FLOSS communities are meritocracies. But what this means in practice is that these communities already keep score, and grant status based on that score namely, committer privileges.This means that the highest performing code contributors are already recognized by peers for their work. So why is gamification needed for FLOSS projects? Because non-code contributions are much less well recognized by most communities. And because there are many ways to contribute besides writing code, and many community behaviors that could be encouraged, but arent, by the typical projects focus on code.
Many smaller projects with just a handful of contributors probably do not need gamification everyone knows what everyone else is doing. It is the larger projects with many developers and non-code contributors that could benefit most by gamification.
So if FLOSS keeps score well, what can projects gain from this approach? Here are a few ideas:*Every project has some mundane bookkeeping-like tasks that need to be done, Things like:Reviewing and responding to pull requests and patches from non-community members who want to influence the projectWeekly Puller award highlighted on the front page of the project.Performing code reviews of other project developers work to validate approaches, find bugs, and collaborate on implementations.Triaging bugs reported on project forums and through other means.Triage leaderboard: +1 for evaluating and ticketing a bug, +5 for fixing it right awayResponding quickly to mailing list or forum posts.Tackling marketing duties.Writing documentation.
Sometimes it is enough just to gather metrics on some of these activities and show who is doing them those reports can serve as recognition.But sometimes recognition is not enough to motivate action. You need achievements such as Top code reviewer this week as incentive.*There are things you might wish for volunteer help on, and things that can make your project more successful that people might not understand is important. One way to tell them is to add scores and achievements to your project for these activities. Some examples could be:Mentoring new contributorsMentorship badge can be awarded by new contributors upon their first accepted patchBring in new contributorsContribute upstreamRepresent the project at eventsStart or attend a local meetup*If you can measure it, you can gamify it. Instead of measuring and rewarding raw contribution volumes, or better yet, quality contributions, try measuring teamwork and collaboration.Recognize teams(and dont recognize lone contributors)This means having things like a team leaderboard, and you cannot get on it unless you work together.Recognize cooperative efforts that span locations, types of developer and community member, etc.Recognize advocacyHow many people can you get to contribute this month? You get points when others act on your recommendation.
*Rewarding volume bugs reported, lines of code changed, etc. is bad. You can report it but best not to gamify it. Such scores are an open invitation to gaming the system doing actions intended solely to alter the score.
Rewarding the things you care about, that are not already acknowledged within your project those are the key activities to gamity. If you can attach a quality metric or a reputation vote to the score, that will limit the ability to game the system.*It can be de-motivating to see your name on a leader board in 110th place. So if you use raw scores to show a stack ranked leader board, youll motivate only the top people, who probably are the least needing of motivation!
Show a persons rank, or score, in context: where you are in the list, and the scores of people similar to you. This shows you what you need to do to move up, and while it also tells you where in the overall list you are, your attention is focused on the immediate tasks you can complete to uplevel.*If youve been contributing to FLOSS for a long time, and been a part of a project for years, your contributions will have made a huge difference in the project. But if the project presents contributions on a ranked all-time list, the first-mover advantage will freeze the leader board of contributions with the founders and core contributors at the top of the list. Newcomers to the project look at lists like that and realize that theyll never overcome that first-mover advantage in contributions, and be recognized on the project. This demotivates the very people youre trying to engage with.
So, make sure the scoring methods you use to acknowledge contributions include an aging function, so that recent contributions are much more heavily weighted than contributions from long ago. This also acts as an incentive for the core contributors to continue to work on the project to maintain their status.
You can still have a hall of fame or lifetime contributor list but make it separate and have the current contributions be the ones you highlight.*While FLOSS does a good job of keeping score already, many projects put a big emphasis on the code. This is probably as it should be, but there are many other ways to contribute and many necessary non-code tasks to do to keep a project healthy.
By offering a broad range of achievements that reward diverse talents and interests, you can make your project more attractive, well-known, and easier to contribute to.