---
title: "Getting into Open Source"
date: 2010-12-01T00:00:00+00:00
draft: false
needs_review: true
canonical_url: https://www.viget.com/articles/getting-into-open-source/
---

When evaluating a potential developer hire, one of the first things we
look for is a profile on [GitHub](https://github.com), and I'm always
surprised when someone doesn't have one. When asked, the most frequent
response is that people don't know where to begin contributing to open
source. This response might've had some validity in the
[SourceForge](http://sourceforge.net) days, but with the rise of GitHub,
it\'s become a lot easier to get involved. Here are four easy ways to
get started.

## 1. Documentation {#1_documentation}

There's a lot of great open source code out there that goes unused
simply because people can't figure out how to use it. A great way to get
your foot in the door is to improve documentation, whether by updating
the primary README, including examples in the source code, or simply
fixing typos and grammatical errors.

## 2. Something You Use {#2_something_you_use}

The vast majority of the plugins and gems that you use every day are
one-person operations. It is a bit intimidating to attempt to improve
code that someone else has spent so much time on, but if you see
something wrong, fork the project and fix it. You'll be amazed how easy
it is and how grateful the original authors will be.

## 3. Your Blog {#3_your_blog}

I don't necessarily recommend reinventing the wheel when it comes to
blogging platforms, but if you're looking for something small to code up
using your web framework of choice, writing the software that powers
your personal website is a good option. [The
Setup](http://usesthis.com/), one of my favorite sites, includes a link
to the project source in its footer.

## 4. Any Dumb Crap {#4_any_dumb_crap}

One of my favorite talks from RailsConf a few years back was Nathaniel
Talbott's [23
Hacks](http://en.oreilly.com/rails2008/public/schedule/detail/1980),
which encouraged developers to "enjoy tinkering, puttering, and
generally hacking around." Don't worry that your code isn't perfect and
might never light the world on fire; put it out there and keep improving
it. Simply put, there's almost no code worse than *no code*.
