An ode to GitHub, the social coding platform


I believe two tools changed the way we code. One tool is Git – The world’s most favorite source control system. The next tool is of course – GitHub. 

In the early days, we – when I say we, I mean us coders – used to subscribe to a mailing list to contribute to open source and used JIRA for issue tracking. We find an issue on JIRA (most probably documentation) and start contributing. Afterwards we make a patch file and send it over to a person who manages the project. He verifies the patch and merge it to the project and commit it as USER X contribution. This whole process demands a lot of effort from the first time contributors to open source projects – as Arunoda of Meteorhacks mentioned in his interview here on Readme, you really had to be a guru to get your name into an open source project.


GitHub changed this. Intially, Git started to spread like a wild fire among developers because of it’s distributive nature. Since we needed a central repository, GitHub, which started out started as a startup project by Chris Wanstrath, PJ Hyett, Tom Preston-Werner 2008, arrived bang on time and simply became the de-facto provider for hosting Git projects afterwards.

GitHub made the above process very simple and intuitive. All I need to do is to pickup an issue on GitHub of the reposition (repo) and start work on my fork of the repo on GitHub. Once I am done with my work I commit my code to my fork and send a pull request to the parent project. As a good practice – I put a description of what the contribution is on the pull request message. A committer from the parent project will merge the pull request to a testing branch or merge the patch file from GitHub to his local repo and verify the changes. If he is happy he’ll merge it. Now the parent project will show it as I committed the changes and the committer merged it. Bob’s your Uncle.

github pull requests

Yes, that counts as simple and intuitive among developers. We use it to great effect at WSO2.

But GitHub’s true success is as a social site. As developers, we thrive to build a community among ourselves to help ourselves. We’ve had mailing lists, Google groups, the lot. There’s even video calls, but for Open Source projects, when the collaborators, committers and users are of different locations, timezones and languages, this quickly becomes unfeasible. Facebook groups don’t cut it: this is code we’re discussing, not selfies.

GitHub brought forward not just a code repository, but a better way to streamline communication. Code comments, issues, pull requests and developers profile form integral parts of GitHub that let us use it as a social network for coders. All of this is integrated with a powerful customizable notification system that keeps you in touch with conversations with various developers, updates on projects, allowing you to keep in touch with everything you’re interested in.


GitHub also brought forward a new street-cred way for developers to showcase themselves – a Contribution Graph. The contribution graph is available in every GitHub user’s profile. It shows the commitment the user has for coding and functions as a a like a medal of honor in developer community.

contribution graph

As the final piece of the social puzzle, there’s the GitHub followers. Users can follow other users, much like we do on Twitter.

Users who contribute a lot and are supportive have a lot of followers on GitHub. They will be considered as experts by the community and the industry. This build up a very real sense of community, and the entry barrier is logical – contribute. The more you contribute, the more your rep increases. Suddenly developers have yet another incentive to keep contributing. It’s a great system that, despite all its social perks, doesn’t distract from the whole point of contributing. After all, Code over Community!


C’mon, Octocats!



Please enter your comment!
Please enter your name here