I’m writing a book on building a Ruby gem. If you’re interested in sample chapters and a 20% discount code when the book launches, sign up here . The book will include tips for managing and contributing to open source projects.

Towards the end of 2012, I began feeling like a had a good grip on the Ruby language. As mentioned in a previous post, I felt confident enough in my skills that I could make a positive contribution to the open source community.

I learned a lot by watching certain projects and getting involved with others and hope that my notes are helpful for you and your endeavors.

1. Fix a bug in an existing gem because it affects you

My experience with Meeteor and Spokely caused me to move FAST and break a lot of things along the way. Because of the pace, when I did find a bug, I wasn’t great at contributing code back to the source repository. In many cases, my fixes were brute force monkey patches or something else that I would probably be pretty embarassed about today.

Some of the more extreme cases caused me to fork a gem and commit changes to my version of the repo and reference my version of them gem in the application. Thinking back on this now, doing so probably did more harm than good. The downside is that it creates yet another fork of the gem and it also suffers from lack of future updates by the original author. Unless, of course, you’re diligent about merging in changes from master, but let’s admit, this never happens.

In hindsight, I should have spent the extra 30 minutes to write organized and tested code in order to contribute back to the original project. If I experienced the bug, it’s likely that others would too, if they hadn’t already.

Be sure to review the Github issues for other reports of the bug. It’s possible there may already be an open pull request, thus saving you the effort of preparing the fix.

2. Improve an existing gem to learn more about the subject

It’s best to head towards projects that you either have passion for or use heavily. If you’re unsure of the level of effort required for an issue or feature, ask the gem’s author. Also, before you prepare that killer feature that’s going to take you 2 weeks to prepare, make sure it’s known and approved by the author. It’s a bummer to put in all that work only to learn that it’s not something the author is interested in adding and supporting. They’ll likely be happy for the extra help and point you in the right direction.

For me, this was Sidekiq. I had been a long time user of Delayed Job and Resque. When I first tried Sidekiq, I was dumbfounded at how much faster it was because of its multi-threading capabilities. I was also really surprised how easy it was to get started. Sidekiq’s author, Mike Perham, has done a great job at keeping the API similar to that of Resque, thus minimizing the pain of switching.

Often, a popular gem will have a list of pending features to be written for upcoming versions. If you can’t find this list documented in the source code, again, ask the gem’s contributors. They’ll likely have thought through upcoming features and can make recommendations on how to get started.

There’s no better way to learn than reading code. Sidekiq uses Celluloid to handle the concurrency and for me, concurrency was an afterthought. I realized this and figured by contributing, it would force me to better understand the fundamental patterns of concurrency in Ruby.

I can hear the next question…how can you contribute to a codebase you want to learn about but know nothing about? At the time, Sidekiq’s Web UI wasn’t great. Web applications are what I’m good at, so I took it as an opportunity to improve the Sidekiq Web UI, while I became more familiar with Sidekiq’s internals. I spent a few weeks playing with graphs and improving Sidekiq’s internal API and was able to make the Web UI significantly better than it was before I started.

That was the start of my contribution to Sidekiq and since then have learned quite a bit more about what makes the system tick. It’s by no means a straight forward gem and probably one I wouldn’t urge you to cut your teeth on, but certainly a challenge and very well maintained.

3. Create a new gem by extracting code that you commonly use

Greenfielding Rails apps is exciting. It starts out as rails new my-awesome-new-app. You boot the server only to be greeted by the default index page. The next steps are a series of copying and pasting from previous applications or blog posts on the subject of configuring a Rails app. Whichever stack you prefer, there’s generally a number of changes/additions that need to be made to kickstart the productivity.

Rather than paste in the same old code to handle “______” (insert your favoritie super important feature), what better than to simply include a gem that does it all for you. And what better person to create this gem than YOU!

On a previous project, I found myself calling the same view helper methods over and over again, so I pulled it out into a gem so I didn’t have to worry about copying the code across projects. It’s a trivial example, but one that can save you a lot of time and headache.

The ease of creating a gem is both a blessing and a curse for the community. Ruby advocates writing code in a way that’s modular, which tends to make extracting that code to a gem pretty easy when done correctly. With a little Google’ing, you can pretty quickly extract a feature that’s already written and have it up on RubyGems for the world to consume in no time.

In summary

I spent a fair amount of time trying to plot my entrace in to the Open Source community. Github has made it tremendously easy to not only collaborate, but scour other products in search of code that might be interesting to both learn and contribute to.

For those that write Ruby, I would urge you to avoid starting by contributing to gems like Rails or other large codebases. Despite having plenty of work to do, they’re often hard to navigate and have quite a few idosyncrasies due to their long and complex histories. It’s also hard to know whether other people are working on the same issue you might think is relatively trivial. There’s not much worse than putting in a few hard hours on a bug, only to have a pull request fixing the same buy show up a few minutes before.

Start with a smaller project and figure out the path that works best for you. Everyone is different, but that’s what makes you so valuable to the open source community. Work on things you love and make open source software better than when you started.

What will your next open source project be?