For years, I thought Open Source Software (OSS) just wasn’t for me. I had no plans to join any OSS communities on top of my existing developer community obligations.
Curious about the hype I saw on Bluesky, I recently joined the npmx Discord server on a whim. My journey from lurker to contributor taught me a lot about OSS and gave me new confidence going into code reviews.
In this article, I’ll walk you through my journey to give you a little insight into the process of getting involved in Open Source.
Here’s what I’ll cover:
My Struggles with Pull Requests
I’ll admit, I’ve always had a hard time with code reviews. I can be quite the perfectionist. I’ll entertain every nitpick and only hear the criticism.
If reviews go on for days, I easily get overwhelmed. I enjoy pairing and co-working. I want to enjoy Pull Request (PRs), but addressing PR comments takes a lot out of me.
Some of my struggle is a need for accommodations that I rarely get. I also have plenty of lived experience with how hostile code reviews can become (even in a professional setting). Finally, there’s how I was introduced to PR reviews.
Outside of work, I had only ever experienced perfunctory PRs – I’d receive at most one suggestion, but usually just got a “LGTM” (Looks Good to Me) comment. Professionally, I went from no code reviews to incredibly detailed code reviews basically overnight. I still feel like I’m playing catch up.
On the one hand, thinking deeply about every suggestion has made me a better developer. I thrive in collaborative environments with thoughtful code reviews. Developers who have worked with me have told me that they benefit from answering all my “why?” questions.
On the other hand, I demand compliments, gifs, and video calls from my reviewers. I don’t do well with a bombardment of vague comments on my PRs. I’ve spent a lot of time documenting code guidelines and review processes that other people seem to understand and remember much more easily than I do.
Developer communities have helped me navigate all of this. Community is a priceless resource for career changers and new grads. When everyone shares their experience, the uninitiated learn about how things could be and what kinds of things aren’t normal (like very hostile code reviews).
My Former View of OSS
When I’ve talked and written about developer community, I’ve recommended online networking communities, going to meetups, tech conferences, social media, writing, and posting your writing online. The one thing I haven’t written about? OSS.
My first real introduction to OSS was through the online networking group Virtual Coffee. By the end of my first Hacktoberfest, I knew the basics.
The Basics of OSS
Find a project that interests you.
Check the Contributing Guide.
Claim an issue.
Following the Contributing Guide, make a fork, write the code, and open a PR.
The maintainer merges it.
You did it! That’s OSS.
The Dark Side of OSS
Over time, I couldn’t help but see the “dark side” of OSS – maintainers burning out, friction between users and maintainers, corporations suddenly trying to assert control over OSS (for example, Wordpress, Ruby), and the thankless, frustrating job of maintaining a package that everyone uses but no one wants to pay for.
I have to be honest: I had begun to think of open source maintainers as Roz from Monsters Inc. – justifiably fed up with the extra work dumped on them by unappreciative people.
Meeting maintainers in-person didn’t contradict my view. Every single one had a story about burnout and lack of funding. I started to assume that anyone excited about OSS just hadn’t been in it long enough
…so my friends were quite surprised when I suddenly announced that I had joined the OSS project npmx.
Getting Started with npmx
It wasn’t the first mention of the npmx project that interested me. It wasn’t the second. It was a meme. I’ve known Daniel Roe long enough to know that he is brilliant. I like learning from people who are smarter than I am.
I reached out to Patak, and got an invite to the npmx Discord server. I was amazed by what I saw: a rapidly growing, excited, and inclusive community. I realized that I had only ever contributed to communities with at most a handful of people. My view of OSS immediately changed.
This was it. I was finally going to have fun doing PRs.
So I hopped into the npmx GitHub repository and tried to get my bearings. Very quickly, I was overwhelmed. The project moves so fast. I tried to do step 3 – claim a ticket. As far as I could tell, all the tickets were being claimed in Discord before or as they were being written.
Jono kindly welcomed me into his fork for working on the blog page, but I ran into frustrating and weird issues with running the repository (repo) locally and the pre-commit hooks. Multiple people tried to help me debug and were just as stumped as I was.
The next day, Salma arrived. The day after, she was in charge of outreach, and asked me to write a blog. Then life got in the way. I couldn’t keep my promise to context switch into a feature branch in a new repo. I felt like my only contribution was going to be a single line change on the blog page and a blog.
It didn’t help that I wasn’t happy with the blog I had started writing. I gave up on keeping up and lurked in the Discord channels. I chimed in on a few conversations, and offered to help with things like failing accessibility tests.
Four days later, the project was officially two weeks old. The maintainers announced a mandatory week of vacation – community members experienced with burnout had seen the writing on the wall. Vacation would start in 10 days, so that’s basically how long I had to get a contribution in before the alpha release.
The Not So Perfect PR
An hour later, I finally saw it – my chance to contribute code. Alex needed a toggle re-written as a checkbox. It was my time to shine. I commented on the ticket to claim it as soon as it was written. I slapped up a draft PR to show I was working on it. Predictably, my focus was once again pulled away from the repo.
A couple days later, Knowler reviewed my draft PR, and all my PR anxieties came tumbling back. This was going to be The Perfect PR. How dare anyone look at it before I was ready to defend my work. What would they think about my abilities looking at my old copy and pasted portfolio site code that I hadn’t even finished translating from React to Vue? I was legitimately embarrassed someone was looking at my code in that state.
Fueled by embarrassment and productive procrastination, I sprung into action. In what little free time I had, I must have toggled my toggle a thousand times. Three days later, it was finally in a state I was happy with. It was time to open up my PR for review.
A couple dozen comments came in. Overwhelmed, I tried to remember that I had asked for this. I resolved most of the comments and left a comment saying I’d get to the last item, forced colors mode, in the morning. Frustrated with the code for the forced colors and myself for forgetting a few tiny things, I went to play games with friends.
A few hours later, I got a DM from Daniel. He had some code for my PR. I agreed with his reasoning for all the changes and found out an entire tooltip had been added while I was blissfully ignoring the rest of the repo. (I’m confident in my ability to merge or rebase my way out of any situation.)
Splitting my attention between Enshrouded and talking to Daniel, I felt defeated. I knew I finish the forced colors fix the next day, but also adding a tooltip felt daunting. Still, it felt like I needed to do it all.
Collaboration Over Perfection
And then I remembered, this wasn’t work and it wasn’t going to come up on a performance review. I wasn’t alone – Knowler and Daniel were taking the time to help me get this PR merged because they wanted to. I had the opportunity to collaborate with some brilliant people and see how they would write the same thing.
So I pushed through my perfectionism, demanded compliments, and asked Daniel to push his changes. I told him I’d review them in the morning.
Reviewing Daniel’s code, I found that he had forgotten a couple tiny things, just like I had. The code I was frustrated with the night before was legitimately frustrating. Emulating forced colors on a Mac was giving me weird and contradictory results. I needed to test on a Windows machine to finally get it right.
Then, six days after I opened the PR, I finally merged it. I was on top of the world. I had gotten my contribution in before our vacation (and more importantly, I had received multiple compliments). Finally, I knew what to write this blog about.
My Current View of OSS
When you’re looking for a project that interests you, the code isn’t the only thing to evaluate. Early in my career, I learned three rules for evaluating software tools.
Check the date of the last update to make sure it’s actively maintained.
Look at the documentation. Is it up to date and easy to follow?
Check out the community. Do people get fairly quick responses to their questions?
After joining npmx, I’ve discovered that, with a few tweaks, these rules also apply to evaluating an OSS project.
Check out the last few tickets and PRs to see how fast the repo moves. If it’s fairly slow, you can probably claim an issue in GitHub easily. If it’s rapid, start by getting to know the community and how they’re assigning tickets.
You should always check the repo for a code of conduct, contributing guide, and sufficient documentation. Also evaluate the tickets. Are contributors expected to research solutions on their own or given strict requirements? How do maintainers respond to comments on issues?
Check out the community. An active, inclusive community makes contributing a lot more fun.
Now, my view of OSS is much more nuanced. Yes, there are issues with OSS as whole, but there’s a reason people want to fix them. OSS can be collaborative, inspirational, and enjoyable.
Tips for PR Authors and Reviewers
People underestimate the importance of the relationship between PR author and reviewer. A collaborative OSS code review process doesn’t happen in a vacuum. It takes careful cultivation by the PR author, PR reviewer, and project community.
For a long time, I focused on the responsibility of the reviewer to make the PR author comfortable (for example, compliments, gifs). Don’t get me wrong – I think one of the most important parts of a senior developer’s job is to provide constructive, actionable feedback.
But I now understand that the PR author’s sense of agency and desire to learn are just as important.
A sense of agency is a sense of control over actions and consequences. In other words, the PR author needs to feel that they have control over what goes into their PR. Before npmx, I understood this a little bit. I always ask “why?” because I’m not putting my name on code that I don’t understand and agree with. I have counseled my own junior developer that it’s his job to get PRs he’s authored reviewed and merged.
After experiencing an in-depth code review outside of work, I finally understand that a PR is a process. Reviews exist to get consensus, so “perfect” is far more subjective than I originally thought. There’s a reason you get a conversation, not a grade.
Maybe I’ll even ignore some nitpicks in the future.
A desire to learn makes remaining open to a reviewer’s suggestions and requests a lot easier. During my first npmx PR, it was only when my desire to learn outweighed my desire to prove something that I started having fun.
Conclusion
Today, March 3rd, 2026, is the alpha release of npmx, and I am very proud to be a contributor and member of the community.
I look forward to learning about OSS from Patak, fancy, smart code from Daniel, outreach from Salma, and accessibility from Knowler. I know I’ll learn many things outside of that list, too. I’m grateful I’m not the smartest person in the room and that I finally get to have fun with Pull Requests.