Community Leadership Summit Wiki

Session: Gamification in Communities
Time Saturday at 3:00 PM, Session #7
Session Leader: Rich Sands of Black Duck
Note taker: Andy Oram of O'Reilly

Introductions and whether people are using gamification in communities

TED reputation system: rolled out ability to add comments to their
videos, called TEDCred. No attempt to set the tone, a few people
assigned just to clean things up afterward. They attracted people who
were inspired and positive-minded, but quickly taken over by a few
bullies who just wanted to stand on a soapbox and who drove away
everyone with a positive attitude after a few months. There was a
rating system for comments, but the bullies took that over too. They
would create multiple accounts to rate each other up and do other such
things to dominate.

Now there are a lot of checks in place, such as no thumbs-down
ratings, you're limited in how many thumbs-ups you can give during a
week, and you can't rate a comment from your own IP address. Two
moderators and a volunteer team. Working on improving the management
of the volunteer team. Changes have entirely fixed the system.

Ubuntu accomplishment system: Jono liked giving people a sense of
accomplishment through trophies, but many people thought it was really
bad. Besides stopping abuse, it's important to focus on the right
kinds of accomplishmnet. What do you value?

Many people who are against gamification have seen some bad
implementations and assume these systems can't work. In Ubuntu, tried
a hall of fame that hurt the community because highlighting a few
achievers made other contributors feel like they haven't been
appreciated or can't do enough.

If a leaderboard acknowledges the best contributor, it may demotivate
the second best. Good for a competitive situation, but bad in a
situation where you want people to cooperate and achieve some goal
together. Good to know how to rise in the leaderboard, if that
furthers the overall goals of the community.

For communities, avoid one-on-one competition.

Question: all participation is rewarded in a community in some way,
even if just by a sense of accomplishment. So perhaps people
comfortable with the old system feel threatened. Jono: more just a
fear of the unknown.

Some people want the only criterion for approval to be how the
community views the quality, not to impose another system that
requires special handling and that some people can play better than

Easier to build a game if you can base it on objective standards.
Harder to judge quality, how nice someone is, etc.

Ohloh: people can rate the helpfulness of comments, and this works.
Requires a fairly high number of ratings to be valid.

Social aspect of games often forgotten now. People in the flow are
more open to suggestions.

Relationships are also important, so if people like each other and see
the right people getting rewards, the game could help build community.
But if it undermines relationships, it could hurt.

One advantage of a good game is it gives people agency (a forum where
they can do things that matter to them). In contrast, giving a reward
doesn't address the sense of empowerment.

There's a difference between acknowledging a contribution and creating
an incentive. Measurements are acknowledgements.

Competition can be part of a social connection. You may target someone
to beat on the metrics, but feel respect for them.

Everybody cares about where they stand in a community. Key is to make
it fair.

People treat real life as a game whether or not there are formal
metrics. For instance, in political systems, people know not to take
positions that would cause powerful people to make life difficult.
Gamification provides guidelines for getting the status that people
would otherwise get in illegitimate ways.

Make sure new people get a chance; cumulative achievements shouldn't
put old-timers too far ahead. Perhaps restart a timer every week or

Open source code communities have built-in rules for advancing.
They're different for each project, but don't need gamification.

Rewards may be useful for tasks that nobody likes to do naturally,
such as reviewing patches.

Communities need to highlight members who have historically been very
helpful: old-timers recognize and respect them when they speak, but
newbies don't understand their history. Have a shared ownership of the
journey they're taking.

Lots of experiments a couple decades ago to determine the most
productive programmers. Whatever was measured became a pathological

Ohloh: people know statistics about the value of a codebase are
unrealistic, but still like them because they can interpret them in
ways that are useful to them.