Github Gamified: Good?

January 11, 2016 • John Vandivier

This article explores the pros and cons of treating GitHub as a game.

GitHub is a place where coders put their code. It serves as a technical tool, but it also serves as a social network and signaling device.

Rep on GitHub, <a href="http://stackoverflow.com/">Stack Overflow, and similar sites capable of skill signaling can lead to sweet jobs and projects potentially. So they have value.

GitHub has various point-like metrics which can be viewed on any registered user's personal profile page, like <a href="https://github.com/Vandivier">mine here. Metrics include:

Commits per year
Streak
Followers
Stars
Many others

GitHub can transfer shallow signals and quality signals, but the quality signals are harder to interpret so they are often ignored and the shallow signals substituted in.

A quality signal would be the actual code checked in to a GitHub account, but analysis of this data requires a skillset on behalf of the viewer and a degree of time and effort. Most people won't bother with analyzing this stuff. When I interview people for a programming job I rarely bother in-depth analysis. The fact that they even contribute at all is rare enough that it signals well.

Except there is this incentive to cheat.

Maybe, as a user, you seek to maximize your shallow signals and metric values instead of making technically valuable Open Source contributions. You would do stuff like this:

Prefer many small commits to fewer large commits, probably committing a large volume of entirely superfluous code.
Run your blog off GitHub so you could gain economies of scope for blogging without even actually coding on GitHub.
Fork less and create altogether new projects more, because GitHub doesn't count fork commits.

Not all of these effects are strictly negative, and there are probably other effects as well. Committing superfluous code is negative, but hey, at least you are coding something. Maybe this is better than an alternative scenario in which you never started coding.

The blog thing is totally cheating imho and recruiters and those doing hiring and so forth should learn to ignore these commits.

Forking less is sometimes bad but it's not clearly always bad. Here are some further implications of forking less and creating altogether new projects more:

Forking is easy, creating a project from scratch is hard. So overall this gamification effect may create a barrier to entry and reduce overall output of code.
Forking tends to put you in a group coding situation which is similar to a professional situation. When you create an altogether new project you are missing out on cooperating with other developers and you are also maybe losing specialization opportunities.
On the other hand, creating a project from scratch may give you an opportunity to become a more well-rounded and knowledgeable developer yourself.
Forking tends to increase the quality of technologies which already exist. Creating an altogether new project tends to generate altogether new technologies which may have more innovative applications.

Finally, what about asking all your real life friends to make GitHub accounts to star your projects? This would make it look like lots of people use and like your products, but it could be false. On the other hand, you may stimulate your friends to learn what your code actually does and says. Since they already have a GitHub account now maybe they should start coding.

After all, it shouldn't be that hard to code the garbage you just wrote, right? Kidding, kidding.

Seriously, though, the social effect of gamification may incentivize more people to code. Perhaps more if your friends and you are often competitive with one another.

We have basically analyzed the effects of GitHub's treatment as a game. Some are good and some are bad. What is the net effect? I have no idea.