My open source contributions in 2016

I find it immensely satisfying to be able to contribute to open source, here’s what I managed in 2016.

Screamshot

I created Screamshot for a personal project and especially wanted to make it open source once I had an idea for a logo.

Dragonfly S3 Server

Another open source creation that sprung from a personal project — and something I have yet to write about separately. The motivation is to remove Dragonfly requests from being served by the main Rails app.

Allow Dragonfly to fetch a URL with basic auth

Whilst creating Screamshot I discovered that Dragonfly didn’t understand URLs containing authentication credentials. A quick pull request and it was taken care of.

Keep rspec-rails’ gem description up-to-date

A tiny, seemingly pointless, but nevertheless helpful, pull request.

A Ruby API client for Medium

I made the decision to cross-post my blog posts to Medium but didn’t like the look of the existing Ruby libraries so I wrote my own. It was also featured in Ruby Weekly Issue 312.

Open source libraries are great and so is open source documentation; I found Medium’s API documentation to be good and readable which makes being able to contribute more satisfying.

The funny thing about some larger companies’ open source projects is that you are required to sign a licence agreement to contribute. I think I understand why this might potentially be required from a just-in-case cover-all-bases legal perspective but it seems slightly at odds with the whole point of an open source licence.

Quotesplit

Another little ditty that I haven’t yet written about separately, Quotesplit is a Ruby library for quote-aware whitespace string splitting — like Shellwords.split but without raising ArgumentError: Unmatched double quote.

Rails: don’t introduce Uglifier to an app when JavaScipt has specifically been turned off

I wrote about my ~/.railsrc and found a small something that I could contribute to Rails.

A tiny amendment to Paperclip’s regular expressions

This is one of those annoying (for the receiver) pull requests on the one hand making the project a tiny bit “better” — which is what open source enables — but on the other hand creating work and introducing risk for little to no gain.

Peity

Peity is my most “successful” open source project to date but, having been created in 2009, it’s stable and mature and saw only a scattering of minor commits and a patch release during 2016.