Bekah Hawrot Weigel

There's been a lot of talk recently about how to get into open source. I think part of the challenge of breaking into open source is overthinking it.

https://x.com/BekahHW/status/1742920548353745068?s=20

We need to reframe how we think about starting with contributing. Getting started with open source can feel intimidating, but it's just like learning a new game with complex rules. You wouldn't jump straight into a game without reading the instructions. In the same way, you shouldn't overwhelm yourself with open source. Take it step-by-step.

So far in this series, we’ve explored maintainership from a high level understanding of what’s required, why you should consider it, and how to get started. But what are the day-to-day tasks of a maintainer?

The first project I actively maintained was something that I hadn’t initially considered for open source contributions. It was open sourced, but I didn’t anticipate anyone contributing but me. When I was encouraged to share it with contributors during Hacktoberfest a couple of years ago, I had to make some updates so people understood what the purpose of the project was, how to run it, and the technology behind it. Looking back at it, there are, of course, things I could have added or done differently.

Job seeking is really challenging, but if you've talked to me in the last six months and asked me how to find a job, you know that I've mentioned using open source. I know, I know. That can be an overwhelming experience. But hear me out if you're an early career developer.

Yesterday, I decided to make some "quick" changes to the OpenSauced docs site. Now, I know that "quick changes" is essentially a bad word in tech. Anytime you say it, it will indeed not be quick. I wrote up a quick issue that described reorganizing a couple of things and adding a quick intro page. I made the changes, wrote the page, pushed my changes, and made the Pull Request (PR), only to see that I failed. Ugh. It was quick, but it wasn't right. Not really having the time to dig into it, I left my PR open and determined to get back to it the next day. Understanding why a project is failing may look different depending on how it is set up. For us, we're going to look at implementation errors, compliance issues, check the deploy log.

Every week at 10:30a ET, I do X/Twitter spaces about open source. I’ve been fortunate enough to learn from some amazing folks in the space, and two conversations really had me thinking about this topic. I chatted with Rachel Nabors of Clerk and Ben Holmes of Astro about open source projects and the contributor’s journey. They both shared their philosophies on how to cultivate a positive contributor journey. As a former educator, it made a lot of sense: If we want to see return contributors, we need to create a space that encourages them to return. Part of this means cultivating a contributor journey that allows your contributors to grow, receive recognition for their contributions, and provides a positive experience. Creating an impactful contributor journey requires deliberate thought and understanding, listening, and a willingness to grow with your contributors.

A lot of contributors ask how to become a maintainer. I became a maintainer by creating an open source project and inviting others to contribute. @Ayu and @Chrissy became maintainers of some OpenSauced repositories by contributing to the projects, demonstrating leadership by helping others, and through their support for maintainers. There’s no one direct path to maintainership, but one piece of advice I give contributors who are interested in that path is to understand the role before taking it on. Being a maintainer can be lonely, and there’s a lot of work that goes into it that you should be aware of before jumping into the role. With that said, if you understand the role and have the capacity to take it on, you might find—like I did—that it can be one of the most gratifying experiences you could have in tech.

Last week, I was tagged in this tweet.

I appreciated the openness and honesty, and it’s a sentiment that I’ve heard from other people. It can be overwhelming to get started in open source, especially if you’re already feeling tired. And because I answer this type of question a lot, I thought it would be useful to create a whole blog post about it.

Sometimes, it can be hard to get your Pull Request (PR) reviewed, especially if there are a lot of other PRs ahead of yours. Maintainers can get busy, take some time off, or be overwhelmed with GitHub notifications. If you want to get your Pull Request reviewed, you need to make it easy for the maintainer to review your PR. How do you do that?

Welcome to our #100DaysOfOSS series. With this post, we've officially gone from A to Z!

Today, we're covering the letter "Z."

A couple of months ago, we launched the Intro to Open Source Course, which connects to another repository called guestbook. When the person taking the course gets to chapter five, they put their new-found knowledge to work and create a pull request on the guestbook.