index.md (2177B)
1 --- 2 title: "Getting into Open Source" 3 date: 2010-12-01T00:00:00+00:00 4 draft: false 5 canonical_url: https://www.viget.com/articles/getting-into-open-source/ 6 --- 7 8 When evaluating a potential developer hire, one of the first things we 9 look for is a profile on [GitHub](https://github.com), and I'm always 10 surprised when someone doesn't have one. When asked, the most frequent 11 response is that people don't know where to begin contributing to open 12 source. This response might've had some validity in the 13 [SourceForge](http://sourceforge.net) days, but with the rise of GitHub, 14 it's become a lot easier to get involved. Here are four easy ways to 15 get started. 16 17 ## 1. Documentation 18 19 There's a lot of great open source code out there that goes unused 20 simply because people can't figure out how to use it. A great way to get 21 your foot in the door is to improve documentation, whether by updating 22 the primary README, including examples in the source code, or simply 23 fixing typos and grammatical errors. 24 25 ## 2. Something You Use 26 27 The vast majority of the plugins and gems that you use every day are 28 one-person operations. It is a bit intimidating to attempt to improve 29 code that someone else has spent so much time on, but if you see 30 something wrong, fork the project and fix it. You'll be amazed how easy 31 it is and how grateful the original authors will be. 32 33 ## 3. Your Blog 34 35 I don't necessarily recommend reinventing the wheel when it comes to 36 blogging platforms, but if you're looking for something small to code up 37 using your web framework of choice, writing the software that powers 38 your personal website is a good option. [The 39 Setup](http://usesthis.com/), one of my favorite sites, includes a link 40 to the project source in its footer. 41 42 ## 4. Any Dumb Crap 43 44 One of my favorite talks from RailsConf a few years back was Nathaniel 45 Talbott's [23 46 Hacks](http://en.oreilly.com/rails2008/public/schedule/detail/1980), 47 which encouraged developers to "enjoy tinkering, puttering, and 48 generally hacking around." Don't worry that your code isn't perfect and 49 might never light the world on fire; put it out there and keep improving 50 it. Simply put, there's almost no code worse than *no code*.