Tags: Open Source, Challenge, Git, GitHub
Since 2012 I have been participating in an inspiring open source challenge called "24 pull requests". This post is an extended version of a lighting talk I gave at the Observe, Hack, Make hackercamp in The Netherlands in 2013.
The challenge hinges on a distributed source control system (a fancy name for a program that keeps tracks of modification to the text files that comprises the original instructions for a program) written by the author of Linux himself called Git and the social features of a website offering Git services called GitHub. Git allows teams of people to work on the same text (not unlike Google Docs, for example) but with each person working on slightly (or radically) different versions of the text. Each version is called a fork (think of it as a fork on the road of the creative process). People can update their own versions from other peoples versions by pulling changes into their own versions. Therefore, to contribute to a "master version" you can offer your changes and ask them to pull them from your version: a pull request.
The 24 Pull Requests challenge was started by @teabass. It involves making 24 precise Free Software contributions (pull requests) the 24 days before Christmas, on the website GitHub. I was lucky enough to find out about it on its first year (2012) a few days after it had launched. That first year itself, it gathered 3,800+ sign ups. But the task, while it looks deceptively simple, it's very difficult to accomplish. That first year I was among the less than 20 people that finished the full challenge.
I participated again in 2013, with a different focus and managed to finished the challenge again. Last year was not that successful as I had enough excuses to keep me busy (among them that I was moving and had no Internet access, alas). This year is off to a good start, though. In this post I want to share reasons for doing the challenge and some tips for how to go about it.
There are many reasons to take part in the challenge (and many not to, as December is a very busy month in terms of social activities). The main reason is to give back to the community. These days more and more professional software development relies heavily on Open Source software. During that process, bugs are found and fixed in local copies. Those local fixes never find the time to get contributed back into the mainstream version. This challenge gives you a frame of mind to take the time to shape up and share those local bug fixes.
It is also a great opportunity to explore different languages, platforms or projects. In 2012, I decided to explore old languages that there have been years since I looked at them, like Haskell, ObjectPascal/Delphi/Lazarus, Prolog or learn new ones such as Lua. A daily contribution as part of a challenge gives you a very specific goal to focus your learning curiosity.
But the most appealing part is the social aspect. Most Open Source projects receive very little attention. I have a few myself and I seldom receive any feedback, never mind contributions. Unless the project is widely deployed and successful, the changes of receiving a random contribution is, on itself, a type of holiday gift. You will be encouraging people to further their community service in the form of Free Software and maybe even making new friends or strengthen existing friendships. Thus in 2013 I decided to focus in contributing to projects from my friends and present and past colleagues. That resulted in getting involved with a game engine for children written in South America and Scientific Python tooling for Machine Translation, kindly released Open Source by Machinalis, a consulting company that originated in my home city, Cordoba, Argentina.
Submitting a daily Pull Request takes some planning. For the whole challenge there might be a few key contributions (for example, in 2013 I added a new ML algorithm to a suite by adapting an existing implementation to the suite, or in 2012 I added handling to preposition to an adaptive communication Android app). Most of the contributions are quite small. Fixes in documentation are a great start. Extra test cases are usually very welcomed. The same goes with translations. The next stop is to look at issues. Many projects label their issues with "beginner" or "simple" labels. If the work to fix them takes more than a day, it is useful to reply to the bug indicating you are working on a fix.
Finding which projects to contribute is the most fun of the challenge for a person that enjoys exploration like myself. The obvious candidates are projects which I rely upon for my daily work (like Apparatus, Scalatra or Scikit-Learn). Next come projects from people I know in person which I follow on GitHub or people I follow there because they have interesting projects. The site also allows you to "bookmark" (star) projects. Looking at projects I have starred throughout the year is also a good way to find interesting places to contribute. GitHub have some excellent exploration tools to find projects in different languages (and in some moment also by geographical area, but I can't find that in the new site). This is a good starting point when looking for projects in unusual programming languages. Finally, the 24 Pull Requests site allows people to submit projects as suggestions. I found that quite useful in 2012. These days I instead look at the other developers keeping up with the pull requests, visit their GitHub profiles and see whether any of their projects look interesting. This way there is a little bit of community building going on around the site. I have got a few Pull Requests from participants that way.
In terms of technology, by far the easier language to contribute is Python. In 2014 I tried to make my pull requests in Scala and it was much challenging (but I got to contribute this recursive descent generator for the Arnold-C language out of the challenge). This year I'm trying to contribute to more Haskell projects but the complexities of the build system is slowing things down.