In the wake of Hacktoberfest 2017 finishing (and I’ve managed to get the t-shirt again for the 3rd year in a row), I figured I’d try and convince a few more people to give back to open source projects. This is something I do just as part of my day-to-day work, and I want to try and convince the rest of you of the benefits of it as well. We all rely on a vast array of open source projects for pretty much everything we do with modern computer systems (and I’m including the proprietary stuff, as even organisations like Microsoft, Apple and Oracle use it as part of their proprietary software), and although in the wake of Heartbleed and related issues some of the more critical projects are finally getting a bit more help, there’s still a long tail of smaller projects that you’re using that could do with some help.
I’m not saying you need to do this entirely out of the goodness of your heart. Also, that many of us have actually have other commitments outside of work (e.g. families), and although I do do a fair amount of open source work outside of work hours, I’m going to talk here about doing this in work hours, for reasons that are good for your employer (and also good for you). I’m also going to try and show you how even small contributions matter, and that we need every one of you to do this stuff. I’m also going to focus here on providing small amounts of help to multiple projects, and not on the long-term work of maintaining projects (which is a whole other kettle of fish).
So why should you bother? Well, the most useful case is as follows: there’s an existing open source tool, it does 95% of what you want to do for a work task, but you need some extra little feature or it’s got a small bug. Good news: you can add that feature, because it’s open source 🙂 This will take some amount of effort, and sometimes it’s not worth that to the work project you’re on, but often it is. Generally, if the tool is already really close to what you want, then the amount of work needed to add the feature is pretty often pretty small. Spotting these is somewhat of an art rather than a science, but the next time you find a really great open source tool that almost does precisely what you need, take 10 minutes and see if you can figure out how to make it do the extra thing you need.
Ok, so you’ve done the hard work of adding the feature, but now you’ve got a forked version that you’ve got to maintain forever, which is no fun (and a long-term risk/cost to your work). Why not contribute it to the existing open source project instead? If it was useful to you, odds are it’s useful to others. It might not be, but it’s often the case (and always worth trying), and that way you can get all the benefits of new versions of the project without having to maintain your fork directly. Also, (depending on the relevant language) running forked versions might be difficult/annoying (I’m looking at you Go) and so handing it back upstream is a much better option. Additionally, you’ve probably done most of the hard work already by building the feature, so this starts to just become the better option.
Other motivations include that this looks good on your CV. Note that as everything you’re doing here is open source, you can talk about it in public, you can use it as code examples to future employers, and demonstrate abilities to deal with communities and other really, really useful soft skills. Your current employer should also quite frankly be talking about this, as it looks good for them if their employees are handing lots of things back to the wider world.
Ok, let’s give some recent case studies of ones I’ve done using this method:
- Clairctl is a tool for analysing security vulnerabilities in Docker images, and we wanted to use it programmatically without having to manually parse it’s output. I added JSON output to it’s “analyze” command (I also did the similar fix for klar)
- Rancher Agent Registration (as the name suggests) is a tool to do automatic Rancher registration, but it had a bug when restarting the local Docker daemon
- AWACS is a library for specifying AWS IAM policies, which didn’t yet support the ForAllValues and ForAnyValues options we needed
- watchify is a tool for watching browserify builds. It had a literally 1-character error in its README. For ones like this, Github has a feature for editing files in others repositories that makes this really easy.
- lein-jruby is a Leiningen plugin for JRuby that turned out to have some issues with modern Clojure versions
- buddy-core and lein-flyway had some reflection issues we were hitting (and I’ve got some patches for tools.nrepl once they finish fixing their CLA issues)
I did all of these during work hours because we were using the tool/library in question, and it almost, but not quite did what we wanted. In the coming months, we’re going to be talking more here about these sorts of projects and the contributions we’re making to them.