You’re working on a Ruby development team, making an app that solves that nagging problem of <insert problem here>. The big payoff is coming, customers are signed up and you sit back and say to yourselves, “We are really going to do this!” And you do! Your app is a success, and you built it with free and open source software!
And then you wonder to yourself: how can I pay it forward?
Sure, it would be easy to look at charitable causes or to sponsor some event and say you’ve given back to open source community. But why not give back to Ruby directly? Too hard? No time? Not sure how to get started?
It may be easier than you think.
But I Don’t Know C!
Let’s take a look at your technical team. There’s Sheryl. She’s been slinging code for years, and Ruby is just the most recent tool in her toolbox. But she’s never coded in C. Bobby is a top notch front end developer with UI/UX skills and a mastery of anything with a “.js” at the end of the name. But again, no C experience. There’s Katherine, a fantastic DBA, but not much of a C coder. And then there’s you. Master of all things Ruby—except you’ve never actually contributed to Ruby itself.
This might seem daunting, but none of these things are really a blocker. Mental barriers? Sure. Impostor Syndrome? Perhaps. But you don’t need to contribute to the C internals, or know how the Garbage Collector works for instance, to start contributing.
In theory, everyone on the team should be able to help out.
Okay, Maybe I Know a Little C
Perhaps this situation doesn’t describe your team. Perhaps you are interested in contributing a little C code. Fantastic! But knowing where to start can be a little confusing if you’re new to the project. A great place to take a look is any personal pain points. What part of your project caused you and your team serious issues? Are there specific things in Ruby that, if improved, would help your project or the team’s productivity?
Once you’ve figured this out, it’s time to find out what the rules are. Luckily, the core team has put together a handy guide for submitting patches. All you need to do is follow the easy steps “Matz and the Gang” have set aside.
Contributing via the Documentation
There are parts of Ruby you know—and know well—but sometimes you have a hard time explaining these things to other people, and the docs are letting you down. This is a great opportunity to contribute. It doesn’t have to be time consuming. It’s something you already understand.
Contributing to the docs is also a great way to familiarize yourself with how contributions to Ruby work. Zachary Scott began by contributing to Ruby through documentation, and now he’s a member of the core team and is the 5th most active contributor to Ruby. (He has since become a contributor to Rails and Sinatra.)
For people that are less familiar with Ruby, it’s possible to go through and clarify statements, edit for grammar, make corrections, and so on. It may not be solving any big problems, but you are still contributing to the project, and that’s what matters.
Beyond documentation, there are other parts of the Ruby ecosystem that are written in a language you already understand: Ruby. All the tests for the language are written in Ruby. And as we all know, decent test coverage is very important for any project.
Additionally, native extensions bundled with Ruby depend on the cRuby API, but sometimes also include pure Ruby classes and extensions. And they are all tested using Ruby as well. The rest of the standard library is also written in Ruby and should be understandable to anyone with Ruby experience.
So really, there’s a lot of scope here for contributions in Ruby!
Where Do I Find The Time?
Giving back to open source doesn’t necessarily mean giving up your weekends or time with your family. Yes, you can take that route, but it could also lead to burn-out and other issues. Always take care of yourself first. Open source can wait.
If you are lucky, you might be able to schedule contributing as part of the regular work week for your team. Many offices enjoy “Freedom Friday”, some time set aside at the end of the week to code on open source projects. Or some sort of passion projects initiative where staff are given time during the course of work to contribute to or explore open source projects. This can be great for your company as well as being great for your staff.
There may also be an opportunity to contribute as part of a meetup in your area or perhaps at an Open Hack, if you have one nearby. The time investment needn’t be monumental.
The whole Ruby community (as well as the core team) could use your collective help. And don’t let the use of Subversion dissuade you either. The community is working on a plan to move to Git, and maybe that’s an area you’re interested in help out with! (For people who really must use Git, you can work against the mirror on GitHub.)
As my friend, and Ruby core team member, Terence Lee puts it, we can’t improve Ruby without the help of the community. And that includes you. So get involved!
P.S. Have you contributed to Ruby before? How was the experience? What areas do you think you’d be interested in contributing to? Let us know by leaving a comment.