GitHub is a game changer

Update: here is another recent blog post with excellent detailed instructions on forking and contributing to a GitHub project.

I used GitHub for a while before I could really appreciate what this site is doing to our culture as software developers. GitHub isn't just a neat tool: it's a revolution in the making.

GitHub is a social platform for developing software, built around git. The use cases for git have always been interesting, but not necessarily compelling. GitHub builds on the strenghts of git, and the result is a brand new approach to writing and sharing code. While git takes care of the technical issues like forks and merges, GitHub takes care of the social issues like pull requests and tracking forks.

Just think of a typical development problem: patches. Your project uses a third-party library, and that library has a bug. Here is how you usually deal with the problem if the library is proprietary:

1. You contact the producer's customer service and report the problem.
2. You sit on your hands until the company fixes the problem. If ever.

Here is what you tipically do with an open source library:

1. You go to the library project's forum and report the problem.
2. You sit on your hands until the authors fix the problem. Eventually.

As an alternative, you could fix the problem yourself. To do that, you have to download the library's code, set it up, make sense of it, patch it, build it and test it. It could take you weeks. Then you submit a patch, and you hope that your patch will end up in the original codebase. Until then, you have to merge subsequent changes from the original codebase into your patched local codebase. Merges are usually painful enough that you'll probably stick with steps 1 and 2 in most cases. Bottom line, you'll probably end up doing like you would for a proprietary project: you find a workaround, and keep hoping.

Now, here is what you do with GitHub:

1. You fork the library.
2. You fix the problem.
3. You use your own forked library in your project.
4. You send a pull request to the original library.
   

GitHub makes step 1 as easy as you could reasonably hope. If you use good tools like Bundler, step 3 becomes a one-liner as well. And step 4 is both trivial and not necessarily critical. You still have to merge future changes from the project into your fork, but git makes it easy for you to merge, and for the original library to incorporate your patch. All in all, GitHub turns patching from a bottomless pit of pain into a geeky form of pleasure.

Now look at step 2, the remaining difficult step. To make it worth the trouble, you need a project that is easy to setup, easy to understand, and well covered by tests. So GitHub is a perfect fit for languages that promote clear, concise code and for communities who take pride in unit testing and easy project setup.

Suddenly, complicated open source projects feel so last century. By removing all accidental difficulties of patching, GitHub tips the balance towards projects that are trivial to set up and test, and languages that promote easy change. If I need to pick between two projects, I'll probably pick the one that's easier to patch over the one that has the most bells and whistles. Month by month, GitHub is shifting our collective coders' hivemind towards simplicity.

After all, wasn't this one of the original promises of open source? "It's your code. You'll never be stuck."