To gamify or not to gamify community

3 readers like this.
7 open source Android apps for chess players

David Lapetina. Modified by CC BY-SA 3.0.

Human beings are inherently playful creatures. From birth, play has an important function in our lives—from skills acquisition, to competition and beyond. We continue this love affair with play throughout sports, video games, and even catching animated animals in Pokémon Go.

Unsurprisingly, gamification—the process of applying game mechanics to different things—has become something of significant interest. Over the years I have had my own flirtation with gamification, too. I designed and created a gamification platform for Ubuntu, have used gamification in other online communities, and studied it as part of my community leadership research.

Interestingly, and particularly within the realm of open source, gamification can divide people. For some it is a fun, playful, and creative way to get people involved. For others it cheapens how people should join communities, and is seen as a shortcut in the absence of better approaches.

To delve into this a little, let me share the story of Ubuntu Accomplishments, and then share takeaways I have learned over the years.

Ubuntu Accomplishments

Years ago I was at a Canonical sprint in Europe, where a colleague, who was an active gamer, shared his idea for some kind of high-scores system in which community members could compete in the way they contributed. His off-the-cuff idea got me thinking.

Although a competitive framework was not interesting to me—we had tried a hall of fame, which ultimately didn't deliver the results we wanted—the idea of a gamification platform got me excited.

The more I mused on it and bounced the idea off a few folks, such as Stuart Langridge, core principles bubbled to the surface:

  • I wanted this to be about accomplishments, and more specifically to reward people for achieving new skills.
  • I wanted to ensure the system could not be gamed in any way. I didn't want this to be about rewarding people for filing X number of bugs—this is how you can generate crappy content.
  • A core goal was not just rewarding people with trophies for achieving something, but also to make those skills inherently discoverable. I wanted to make sure that a community member could learn how to accomplish that skill by browsing the trophies.
  • I also wanted to use this platform as an opportunity to map out a journey so that certain skills would not be available until others had been completed first.

Additionally, I wanted the entire platform to be decentralized (as commissioning hardware/services in the company was going to be a pain), secure from tampering, and completely automated.

This project was no mean feat. So, I rolled up my sleeves, wrote a stack of Python, Twisted, and GTK code, and ended up with this:

Clicking on a trophy would show how to get it. Here's an example of the StackExchange badges that were integrated:

screenshot from Ubuntu Accomplishments system

This would help the user understand what the trophy was, how to accomplish it, and share tips and tricks for being successful. If community members performed these actions, they would be detected automatically and the trophy would be awarded.

For the technically minded among you, this is how it worked:

  • The client (shown above) had a series of Python scripts that would periodically query Launchpad to see whether each of the trophies had been accomplished.
  • If one had, a .trophy file would be generated with some details and would be synced to a separate server.
  • That server would independently verify whether the trophy had been completed and, if it were, it would sign the file and sync it back to the user.
  • When this signed trophy arrived, the client would verify its integrity and, if valid, the client would display the trophy. This ensured that trophies could not be faked.

Overall, the system worked pretty well, but it always was something of a hobbyist project. Sadly, we never got the reward system to a point where it shipped in the platform.

Lessons learned

From my experience building out Ubuntu Accomplishments—in conjunction with amazing contributors in the community—I came to fairly key conclusions:

Gamification is not just about trophies

We tend to think of gamification as primarily the distribution of trophies/badges based on the successful completion of tasks; however, this is only a tiny piece in applying game mechanics to other areas. Games tap into a wide range of behavioral economics principles and psychological driving forces, such as the importance of ownership, incentives and how they map to growth on a journey, the risks of over-rewarding, and other principles.

Gamification varies depending on context

Gamification varies tremendously depending on the context. For example, the way gamification is applied in video games has a different set of principles and norms compared to my own experiment I shared above. Gamification in video games taps into our intrinsic scavenger instinct. As such, being out to get all you can is perfectly acceptable. In a collaborative open source community, however, this motivation is less socially unacceptable. As such, gamification principles need to be carefully crafted to the context.

Reward is important, but so is discovery

In gamification, so much focus is placed on the rewards that the discovery is often completely absent or poorly implemented. In Ubuntu Accomplishments, the discovery component of being able to learn about the different skills that were available was one of the most compelling aspects for new users. In fact, when I did light user testing around this (and when we switched it on for beta testing), we saw an uptick in people participating. I would argue that this was due to this discoverability aspect.

Gamification is a helpful onboarding tool

Gamification is a tremendous tool for onboarding, particularly for skills-orientated gamification as I shared in my example. Interestingly, though, when users get to a certain number of trophies/badges, they often start losing interest. At the beginning of a new experience, each new trophy/badge is exciting and feels like a genuine reward, but when you have gotten your 160th trophy/badge, the newness tends to wear off. In video games, however, this is less of an issue, as they tap into that scavenger instinct that makes people want to collect them all.

Gaming the system is an inherent risk

Finally, gamification does have the inherent risk of people gaming the system and trying to cheat. In offline video games this is not that big of a deal, but in any kind of online setting, the problem of gaming the system gets more serious. The problem becomes even more of an issue in meritocratic environments, such as open source communities in which reputation should be earned in objective and honest ways.

As such, when designing gamification systems, assessing these risks—which are contextual, as discussed above— and creating a mechanism to combat them, such as encrypting/signing trophies as we did in Ubuntu Accomplishments, is critical.

So that's a quick spin around gamification, and I hope it lit fires in your own minds about how these principles can be used in interesting ways. Be sure to let me know your thoughts, ideas, and feedback in the comments!

User profile image.
Jono Bacon is a leading community manager, speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, developer workflow, and other services. He also previously served as director of community at GitHub, Canonical, XPRIZE, OpenAdvantage, and consulted and advised a range of organizations.


I found the fact that ppl loose interest with accomplishment after their 160th trophy in Ubuntu accomplishments interesting.
I guess the main factor is the *quality* of the accomplishment.
For example is someone has an interesting profile picture, then people should be able to leave a video message about that of their wiki page.
Of course you can do that by leaving a 'reaction-video' youtube link. But I think this misses the goal.
The trouble with ubuntu is that we are still using the DOS prompt, an almost ham-radio style of communication (IRC) and mailing lists that are frankly a joke to the average mac user. Sure, we all need like buttons (eg the heart button on discourse) we are still stuck in the same paradigm that we started with back in 2004 - and haven't moved on.
What we need (and will never get it) is Ubuntu 2.0, where users can avail of voiceboxes and if needed, video messages posted to community managers to get feedback from the community.
Have you noticed that there are nearly half a dozen community managers since Jono left ?
Frankly, Ubuntu is all over the place in terms of proportioning community leadership to trusted sources (& I only really rated Jono as the person with no hang-ups to lead the community).
I could go on - but I think that Jono really needz to write a memoir of his experiences at Ubuntu so that we can learn from them.
I never forgave the leadership from not including their community manager (JB) at the time, from the Ubuntu Edge project, it just seemed to be another MVP (minimal viable product) that came from the 'design team' in their wisdom and offered no real improvements on mobile, well, maybe advancing it a couple of seasons, but nothing corporeal. I mean you couldn't even remove the battery. The fact that Jono wasn't in the video was a real snub to the community and I guess I lost the traction of the 'whole project' after that.

Gamifying Ubuntu is good, but feedback is more important amongst your peers.
Perhaps you think more in terms of "Salesforce™" for opensource. (?)

Cheers Jono, you were good. ..... you were good.

Joel Spolsky, told in a talk I attended that people don't participate more with gamification. It helps to identify and highlight leaders, to give weight to someone action on a community. Only a few people will actually "play the game".

I did some gamification trials in my previous job. And I tend to agree with him.

Leaders gives a lot of value to a community, a Q&A, a forum, or whatever. However, you can be sure that they would participate at the same level without gamification. Once you are able to identify the leaders of your community, the rewards should be something else than just points and badges, or moderation rights.

You can then interview your community leaders on you blog, invite them to events, integrate their feedback in your roadmap. You can, in some case, think about hiring them to continue what they do, full time, for the benefit of your project/product community.

At the Eclipse Foundation, we are working on a new user profile for our Community. Not sure that we will introduce points and badges. However, we already have many statistics: commits, messages on the forum, articles on our planet blog, issues on the bug tracker, ..... You can not cheat with this kind of information, and just displaying it is a good starting point. It helps to understand if you are exchanging with a long time expert, or a beginner in the Community.

The last point, in open source, is how you can highlight and reward non coders people. A lot of open source software users (like me) are not technical people, but advanced users. They participate to the forums, improve documentation, help beginners, open bugs. Meritocracy is often concentrated around the code contribution, I really think that this should evolve and be more user centric.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.