A few years ago when I was really getting into programming, I really wanted to contribute to open source software projects. At the time, I didn’t think I had enough experience to really provide anything valuable. I later realized that that wasn’t entirely true.

Even if you’re relatively new to programming and are looking to contribute to software projects, there are valuable contributions you can make. In the process, you’ll learn more and meet other people you can learn from.

If you don’t feel comfortable with basic git workflows, I would probably stop reading this and go learn that first. Most projects these days are using git, and if you don’t know how to use it, it will be fairly difficult to contribute.

Many articles will suggest starting with writing documentation, but unless you have a good handle on the larger project, this might be difficult for a newcomer. Unless you have time and ability to play around with new undocumented features, you might have to really read some code to figure things out. If you’re able to document by reading code, you can probably already submit code contributions.

Here are a few ways you can start actually contributing code to free projects as an intermediate programmer. These examples are given mostly with Ruby and GitHub in mind, but you should be able to apply them to other languages or free project hosts.

Cleanup Warnings

The first types of contributions I made to free projects were pretty boring. However, it was very motivating to see a pull request accepted by a project, even if it was for something minor that had little to no change on the functionality or value of the project. I was able to contribute to a few projects by following this formula:

  1. Find an interesting Ruby gem
  2. Install it
  3. Run it in pry with warnings enabled
  4. Fix warnings and submit a PR

Most of the warnings were minor issues of confusing syntax, things like that. It wasn’t stuff that was going to push the project forward, but it was a sort of maintenance that was generally appreciated by maintainers, and got my name into the contributor’s lists.

Here are two examples of this that I did a few years ago:

The first one has 2 changes. In this case it seemed OK to lump these together. The latter change is due to a warning about the unused variable e. I don’t remember what the first one was about, I think I removed unused attributes, which is why you should always put in a good description with your PRs!

Here is a PR for just a simple indentation mismatch that generates a warning

Fix Dependencies

Have you ever installed a gem, only to find that it depended upon another gem that it didn’t specify as a dependency? I ran into this somewhat frequently with RubyGems, and I would update the offending gem’s Gemfile (or gemspec these days) and submit a PR. These kinds of PRs felt a lot more valuable, as they were saving some other poor sap the trouble of manually installing the dependency.

Additionally, you can consider updating dependencies of old projects, especially if the project is relying on gems with known vulnerabilities. GitHub will warn you about vulnerable gems if you own the repository. You can fork other projects to find out if they have vulnerable gems you can update. Sometimes this is as simple as updating a version specification in the Gemfile/gemspec. Even if the gem’s API has changed, it might not be that much work to get the new version working with the rest of the code. Make sure to understand semantic versioning before dabbling with gem updates.

In this particular instance, the maintainer disagreed about the behavior, but look, he was really nice! They don’t bite. I remember being pretty nervous submitting that one, and looking back, it was silly to wrap up those to items (dependencies and SO_REUSEADDR), but big thanks to mjtko for being cool about it.

Anyways, that’s a good segue into the next idea.


My first real Ruby project was a gem to control my Onkyo stereo over the network. It was great for motivation because the code was useful to me. It also forced me to learn a lot about socket programming. Early on in socket programming, you need to set socket options. One of those options is “SO_REUSEADDR”, for “socket option reuse address”. The net-dhcp-ruby project shipped a script to show how the gem could be used. It listens on UDP port 68 and sends out a DHCP DISCOVER message to get info about available DHCP servers. The script uses the gem to parse the info that comes back to port 68, and prints it out in a human-readable format.

Chances are, you already have a DHCP client listening on your computer on port 68, so if you run this test binary, you’ll get an error that the socket is already in use. By setting the SO_REUSEADDR option on the socket, we can have multiple processes listening on that port. Usually you don’t want to do that, but for this particular use case, you probably do.

Anyways, I stumbled over this one because I have a DHCP client running on my machine, and I tried to run the test script. I was already interested in DHCP. However, I could probably go search GitHub for socket creation code, and find other places where this option would be useful. The point is, if you learn a lot about one specific thing (e.g. sockets), you can still provide value to lots of projects, at least for that specific thing, and you can find them by just searching GitHub.

Just fix issues!

Maybe this one is horrendously obvious, but just browse GitHub projects you’re familiar with, and find minor issues you think you can handle. These are way better than most of the above stuff, if only because you know without a doubt that you’re solving a problem for someone.

In the this example, I fixed a fairly simple method to return the broadcast address for an IP. This has been done a bazillion times, so it was easy to find what the values should have been. It was also easy to add tests for these values, as the author had already had a bunch of tests, just not a few edge cases that would exhibit the bug. I added these and tweaked the code until it passed the tests. I didn’t have to know about how the testing framework worked, I didn’t have to know about how the rest of the gem worked, save for learning the parse_u32() method’s job.


So there you have it, if you have some basic proficiency with code, don’t sell yourself short. Go try to make a simple contribution to a project you like! You’ll definitely learn something, get a huge confidence boost, and you’ll probably meet some nice people who can teach you more things.

You may run into the occasional smug or rude response to a contribution. Try not to let it get you down, and consider diverting your contributions to a project more appreciative.

Happy contributing!