Ever since I started learning to code, I've aimed to give back to the community. People working together across the world enable us all to do great things. Entire platforms stand and build on the foundations that these folks set up, and that's something I've wanted to be a part of and continue to enable right from the start.

I've finally been able to hit a major personal landmark and contribute to Rails. But let's talk about how I got that far in the first place.

The Blockers

For all the efforts open source tries to make to be as accessible as possible, it takes a certain level of time and experience to be an effective contributor. There's a selection of things I've encountered myself on the journey that hinder folks from getting stuck in. I'm still dealing with some of them even now.

The first is the complexity of the code itself, especially in larger projects. When contributing to code, there are a lot of concerns to bear in mind. Will your code be compliant with style rules? Does it have a place in the philosophy of the project? Can you get things running locally? All of these things can be daunting, especially early on. It might not be possible in the time that you allocate to it.

The second is impostor syndrome. I'm sure this doesn't need too much of a summary, but impostor syndrome led me to picture Rails as a final boss of sorts. It's a massive project comprising many gems and supporting thousands of projects. Some folks have the guts to run Rails edge in production, so your change could be used right after it's been merged.

Choice anxiety is a major factor, too. Where do you go? What do you add? Will it be useful? When I started out, I felt like it was on me to come up with something fresh that a given project could use. It was like saying to myself "I'm going to run a startup." What for? What change would it make in the world? Pressing myself for answers to those questions caused me to shy away from it all the more.

But I had to do it eventually, in spite of all these things. So let's look at how I got this far!

Getting Stuck In

There are a lot of ways to get involved, and it gets easier the more experience you have. Documentation and raising issues with good detail both tend to be good ways to contribute without getting into the complexities of the code. There are also projects that are simpler from a code perspective that are also good for contribution.

For my first Hacktoberfest back in 2018, I contributed to faker. I figured this would be a really good place to start for a few reasons - it's got an active community, a good test suite and local dev experience, and simple code. I figured I could deepen my understanding of Ruby over time and use this as some good experience to get stuck in.

I also contributed to internal documentation at work and in hedgedoc. I've also raised a lot of issues in the past, and that's been a really good window into what's going on behind the scenes. You get to see how decisions are made and talk to the folks that can help you with implementing fixes and features for yourself. Lots of people I've worked with on issues and PRs have been really receptive to it, and when working on Rails, one of the maintainers even suggested we meet and chat about it.

Taking It Up A Level

I've got nearly two years of industry experience under my belt now. This last year has been especially exciting as I've been the earliest developer on Raise.dev. I drive and implement a lot of the technical decisions we make, and it's been an incredible learning experience that's pushed me far and made me much stronger as a developer. But in implementing parts of our infrastructure, I've seen the cracks in some of the open source libraries we use and taken it upon myself to fix them. It's taught me a few things about how best to get started with making pull requests and getting your name on a contributor list.

Most of my contributions as of late have come from problems that I myself have experienced - outdated docs, inconsistent configuration, and errors while setting something up for the first time, for example. The lesson here is that the best way to find issues is to build and work on things of your own. Whether they're personal projects or part of your work, you can reveal and mend the cracks in plenty of libraries just by putting them to the test. It's far easier to do that than suggest features.

As you get more confident with it, sometimes this means you'll need to get your head around how things are working behind the scenes. I certainly had to understand that with Action View - it's all a bit of a blur to me now, but I definitely had to think about how Action View builds up an output buffer and where that all ends up behind the scenes. There are so many components, from the four templating languages Rails natively supports down to how that gets composed and rendered.

Don't underestimate the time it'll take, though, for several reasons. Your code will need to match all those things I mentioned previously - being in line with the philosophy of the project, stylically correct, and sufficiently tested. It's also easy to forget that there are humans behind the scenes, each with their own schedules, their own takes, and their own approach to what should be included in the project.

So, to anyone who's getting started with open source (especially the Simon of 2018, halfway through university) - it's a marathon, not a sprint. It takes time to build up the confidence and motives to contribute to open source. Hopefully my experience with it might help you to see how you can take your first steps to contributing.