In our latest podcast episode, we spoke with Erika Heidi, who recently started at SourceGraph as a Developer Advocate. Erika, an open-source guru, and technical writer turned developer relations expert, made a great guest for our Open-Source October celebration. We dived into all things open-source, including how to get started if you’re a new developer, the benefits of contributing, and how to navigate tricky situations.
New to the Open Source World? Here’s Where to Get Started:
“My first time making an open-source pull request was actually unexpected. It was in a file upload component on Symphony, and I was using Silex. It’s a smaller subset microframework based on those components. But, the problem was in a component in the Symphony repository, so I realized I had to make a request for that. I was terrified; I’d never made a pull request on an open-source piece before! I knew how to push code to GitHub at that point, but that was about it. Going through the process when you’re first getting started can seem really scary, but you just have to jump in.” —Erika Heidi
For beginner developers or those new to contributing to open source, Erika emphasizes not to overthink it. Her first time completing a pull request, she accidentally created three to four branches per request, which turned into thousands of other files. It was as if she opened a can of worms and had to navigate through it to get what she wanted accomplished.
“I was really nervous that the contributors approving my request would be difficult to work with or that there would be barriers from a cultural standpoint since I’d never been involved in open-source work before. But, when I got the approval, I was so excited. So after that, I wasn’t so scared anymore because I thought if I went through all that, I could definitely contribute more. It’s been easier and easier with each pull request and open-source project I’ve been involved in,” recalls Erika.
After getting over the “open source hump” of her first contribution, Erika explained that it truly isn’t as scary as beginner developers might think and that the entire community is filled with supportive people to learn from, grow with, and innovate alongside.
When it comes to starting with open-source, pick a project or cause that you’re passionate about. Additionally, you can seek to team up with a more experienced developer to tag-team your first open-source project contribution if you’re nervous.
“I’d say it’s nice to find a project that you regularly use in your job already, or that you like that it’s written in a language you’re comfortable with, because then you feel more confident about it. Working on open-source documentation is a great way to get started, too,” shares Erika.
For more ideas on where to get started, here are some open-source tools that our engineers love here at Stoplight, or check out this blog to learn how to advocate for open source at your organization.
What to do When Working with Poor Maintainers
“My personal experience has been good so far, and I’m grateful that I haven’t witnessed any horrible experience in open source personally. But, I have occasionally seen some bad maintainers giving poor replies to other contributors that may deter a beginning developer. There was one time that one of my requests was rejected, but of course, that happens. Learn from the feedback and roll with the punches because the majority of the community is there to lift you up.” —Erika Heidi
The most important thing to note if you stumble across a not-so-friendly open-source maintainer is to realize that not everyone in the community is like that. The best thing you can do is to clearly communicate your intentions when contributing to an open-source project at the start with the maintainers
“It’s good to have some contact with the maintainers before you start and ask for more clarity or more details. A maintainer doesn’t want you to lose your time or waste theirs, so it’s pertinent that you have this communication going at the beginning to ensure you are on the same page,” Erika said.
Often, there is a misconception of an entire ‘anonymous contributor army’ behind an open-source project. However, usually, it’s actually just a few other core developers solely interested in that topic or project. They likely have a vision or roadmap of where the project is headed, and it’s best to understand that before spending loads of time building a contribution that’s not congruent with the maintainers’ direction.
When you encounter a poor maintainer, don’t let the naysayers get you down, keep on contributing! The more open-source projects you get involved with, the easier it becomes. When in doubt, take a step back from a project and return when you’re feeling inspired.
“I got used to working in cycles, so I’d be away for a few months, and then I would go back to a project when I am motivated. I usually go through a kind of spring, where I have an idea for the project and work for a while, then come back to it when I want to incorporate a new feature or add-on. My open-source work is meant to be a hobby,” shares Erika. “However, if you have a more serious project, you should probably be more frequent. Frequency is important if you have a project that many people are involved with and depend on, and as that’s a larger responsibility.”
Open-Source Contributing is a Benefit to YOU
“There is so much freedom that exists in open source that you can go and create your own version of something if you are not satisfied with what exists. I just want to reinforce the idea of doing open source for you. Some people think that doing open source is kind of like donating something, but that’s not really the case. It’s a two-way street.” — Erika Heidi
In all her years of open-source experience, Erika emphasizes that if you’re looking to get involved in open-source, you need to do it for YOU. As I’ve said many times, “selfish” projects are often the most successful; if you don’t have a personal passion for the subject, it will be hard to maintain momentum over time.
Open-source opportunities allow you to learn a ton as a developer, build a community, and have the chance to navigate a code that maybe you would not have had if you were just sticking to your developer day job.
To hear more about Erika’s work with open source and developer relations, check out the full podcast episode on API Intersection. If you’d like to contribute to our open-source tools, here’s where you can get started.
