Foreword

Before I begin I’d just like to mention that much of my success with open-source contribution (success in this case is measured in how good I feel about the project I’ve found and the contributions I’ve made) is thanks to Richard Schneeman and his book How to Open Source. I highly recommend this book, you can read it any which way you want (sequentially, or picking out the parts you need help with), and you don’t even need to finish it before you can start contributing, if you’re like me you won’t be able to stop yourself from starting right away.

Richard Schneeman is the creator of Code Triage (another great resource for beginner open-sourcers), and core committer to the Ruby programming language. I’ll soon include those open-source resources and many more in a resources section on this website.

The Analysis Paralysis

After humming and huffing over what my first true blog post should be about and stressing out about how to make it perfect, I’ve finally realized how imperfect it will be, and has to be.

Just like my darling niece, not even a year old, I’ve got to crawl before I can walk. And perhaps more fittingly, take my first few steps and stumble, before I can run.

So without further ado, I’m excited to clumsily and awkwardly describe with much passion my initial experience with open-source contribution so far.

Background

When I initially started taking online programming classes, I had heard about open-source, how well it could level up a beginner’s coding skills, as well as one’s credibility, but like many others I was intimidated about breaking onto the scene. The reality is I was afraid of putting myself out there. The code you write is kind of like a window into your soul, and I was scared someone would destroy my code and me. But one of the most basic lessons of life rings true here, if you never put yourself out there you’ll never learn.

Legwork

Also, you have to rip that first band-aid. After you do, every other one is much easier. Much, much easier. It helps if you do a bit of legwork first to make sure you choose the right project for you. In fact, I think what helped me the most starting out was just taking some time to look at a bunch of different projects and seeing which ones interested me, and to a lesser degree, seeing if they’d be a good fit skill-wise.

What do I mean by a good fit skill-wise? At first, you might think I’m talking about a project that is comfortably within my ability to program, maybe a todo list (dare I say, the one millionth todo list in the history of new coders), but I think a good fit in this case is really a project that has skills and technology you don’t have yet and want to learn. If you’re interested in COBOL and find a project written in COBOL, then go nuts.

Another important thing to consider is whether the repository is still maintained, and how many issues there are as well as how often new ones get posted. You certainly don’t want to pick up a project just to find out it isn’t maintained anymore, and you can learn a lot about a project from its issues, open and closed.

For me, I’m interested in a wide variety of technologies and programming languages, but in my case I happened on just the right project (after sifting through numerous over the course of a week). It happened to be an Angular-powered idle game, with a fantasy setting. I had gotten plenty of experience with JavaScript by then, and a bit of foundational experience in TypeScript, plus I’ve always been interested in learning about Angular so I thought this was the perfect circumstance for me. I ended up loving it.

This post has gone on a lot longer than I expected, so I think I’ll break it up here and continue in the next one. I know it was pretty rambling at times, but I hope hearing a little about my experience, especially the choosing of a project, could help you finally pull the trigger on open-source contribution. And if not, tune in for “My First Open-Source Experience” Part 2!