Love Coding, Love Source Control, Love Github

The source code which makes up the software we develop is our most valuable asset. As such, it needs to be treated with love and care. While backing up assets like this is important, with something such as source code – which is changed by multiple developers – you also want something to analyse and manage the changes which these assets go through.

Item number one on Joel Spolsky’s “Joel Test” is: “Do you use Source Control?”. Any software company who do not use source control are not taking appropriate care with their own code and potentially their customer code – and that’s foolhardy at best. At Go Tripod, we use the Git version control system which has gained a lot of traction over the past year or so. Subversion (SVN) used to be the cool kid in this arena, but Git has firmly placed itself at number one on the popularity contest.

Github’s been key to this, because it’s provided a really easy way of working with Git thanks to its excellent guides and documentation. Both myself and Jon have our own modest Github accounts, and while I’ve used Google Code in the past I really want to try and keep with Github as I move forward. Why? Because I think Github promotes healthy projects.

Look at any project on Github and you’ll see two little icons – one to keep watch on a project, to check when there’s any activity, and a second one to fork it. I believe that forking a project is the single strongest part of Github. It enables two things – firstly, for contributors to get involved without having to submit patches or anything like that – all contributions and merges can be done by the project owner by simply pulling in a contributor’s changes.

Secondly, if a project goes dormant, it’s trivial for someone else to fork it and essentially take it over. The most active fork of a project is likely to attract the most attention, so for valuable projects, we could see the end of stale, unmaintained work.

However, forking on Github does have weaknesses. In the above scenario, where a fork ends up becoming the predominant development version of a project, Github doesn’t have any way of transferring ownership of a repo from one person to another. This would make sense – the original developer doesn’t want to maintain a project then it’d really be better to allocate it to another developer rather than that developer having to fork. And in some ways forking can dilute a project, with many users adding their own tweaks and enhancements which never then get pulled back into the master. This is a shame, though ultimately I’m not sure how much of an issue it is.

Anyway, we love Github, warts and all. Look out for some more interesting Labs projects hitting our Go Tripod Github account soon.