What I've Learned Contributing to Open Source Software

It was the Ruby community that first got me excited about Open Source. Ruby was free and open, Matz was a likable and intelligent role model, and it wasn't too long before I wondered if I could give back to the community like Matz, Wayne Seguin, Aaron Patterson, and others.

Today I have a much more realistic view of the enterprise of free software than I've had before. And the biggest lesson I can share is probably as true of your job as much as in Open Source:

Your Contribution is not limited to your Code.

So now that you have a tweetable quote, let me share with you the 3 Open Source contribution attempts, also known as Pull Requests, or more simply PR’s, that I learned the most from.

2012 - Ruby - Chronic

As I played with new Ruby libraries, I would often find something they didn't do that seemed natural to me, but they didn't handle. Chronic, the library that turns values like -0.125  into the text "3 hours ago" was supremely useful, but the first thing I tried did not work. Maybe not everyone wanted "quarter till one" to parse into 0.55, but I did! "Could this be my first PR?", I thought. My PR was accepted on its first attempt—not at all a usual experience.

How did I do it? I looked for issues matching mine first, before writing code. I found other PRs that were like mine, and copied them. I added code, tests, and documentation to match other PRs. I tried to blend in.

It was a small change, but it felt exhilarating to know thousands of users would get this code. It made the whole community feel less distant. It was small, but that was enough—it was only the beginning.

Lesson: Stay within the project style. No change is too small if it's done well. Link to the Commit

2012 - Scheme - Lilypond

Lilypond is a music software, written in Scheme, and a custom markup language, that can turn plain text into MIDI, staff notation and chord charts. Music is like a second language to me, particularly music that swings, like blues and jazz. But Lilypond lacked a feature to take uniformly spaced notes like 1 & 2 & 3 & 4 and play them with a shuffle like 1  &2 &3 &4  &.

I had never written Scheme, and it was hard to do so! But I tried and tried, until I had something that kinda worked—for my limited use case. However, in the time that I was struggling, people took my use case, and wanted to expand it. "But Brazilian samba", "But the Viennese Waltz" the comments poured in as people how this feature could extend to all kinds of rhythmic adjustments. How could I code all those variations when I could barely transform 50% to 66% in a language I knew so little of?

At first I was disappointed that my code did not become a part of Lilypond core. But I was inspired to see what happened. People piled their expertise and ideas into a feature I wanted, to make it far better than I could have expected. My name is still mentioned in the comment threads, though none of my Scheme code made the cut.

Lesson: Start the discussion, even if that's all you can do! If someone else can take your idea and run with it (and do it better), be glad! You can learn a lot for the low, low price of your ego. Link to thread

Personal and Family Time

When I became a first-time parent to Sierra in 2014, my time for Open Source went down to zero! Family, employers and clients came first, period. While I continued to put packages up on GitHub that I made, I learned that not everyone wants every package you make. So this wasn't the give-and-take of Open Source, but it was what I could handle, and still beneficial to me. One success during this time: I had over 7,000 downloads of deanius:promise, a library I wrote to help with Javascript. It's now an obsolete package in an obsolete ecosystem, though it enjoyed a brief surge of popularity before Promises were part of the JavaScript language proper. But I'm happy with my tradeoffs :)

Lesson: Personal time may come first and that's ok! Simply publishing a project is a big step, even if you think it’s only for you. You never know who it may help.

2019 - Ruby - Overcommit

Ready to try Open Source again, and working in a Ruby environment at G2, I learned about Overcommit - a tool to run commit hooks to enforce coding standards. But imagine my surprise when I saw that the commit hooks edited your files, and didn't need to in most cases. This was a minor nuisance at first, but at one point I lost work due to this behavior. And it happened to a coworker too. Something had to be done. Could I get a PR accepted?

I started with the intent to write the code to fix it. I had patience. I opened the issue. I floated an idea for an implementation. I got really great feedback. I received and implemented this guidance. Ultimately though, I just couldn't keep up, and the maintainer implemented the feature themselves.

But like before with LilyPond, the impact was greater than my code contribution. Barely 2 weeks after the idea crystallized, a new release made it so my files (and my coworkers') would not be touched, potentially lost, in the vast majority of circumstances. This morning, I updated our shared repository to incorporate the new version of Overcommit with a smile :)

Link to the PR

Lesson: Maintainers will help you if you're inquisitive and show a willingness to implement their ideas. But if you can't keep up, don't take it personally if they close the issue, or go and implement it without you.

There's a feeling that comes from helping an Open Source project that is horizon-broadening. It takes time you may not always have. But if you're looking to affect people positively, it's certainly a rewarding way to share your love of creating software.

I hope the stories above give you a taste of what can happen when you play in Open Source. None of it was very bad, thankfully. Just remember, read all you can on a project before diving in - the Code of Conduct, the Contributor's guide, the README, LICENSE, issues and PRs, and try to be patient. Many maintainers will help you. Ultimately, believe that the world needs your input—because it does! If you've got the time, then what have you got to lose?!

For more information on submitting your first pull request, find one of the awesome guides out there like First Timers Only, and let me know how you do!