
Open Source Contribution
Understanding methods and value of open source contribution through experience

Understanding methods and value of open source contribution through experience
Public APIs face unexpected traffic floods without proper protection. Rate limiting, API key management, and IP restrictions to protect your API.

Started with admin/user roles but requirements grew complex. When RBAC isn't enough, ABAC provides attribute-based fine-grained control.

With 3 services needing separate logins, SSO unified authentication. One login grants access to everything.

Password resets were half my support tickets. Passkeys eliminate passwords entirely, but implementation is more complex than expected.

When I first heard about open source contribution, honestly, I was intimidated. Looking at famous projects on GitHub, I saw developers from around the world discussing in English, exchanging complex code, and doing what seemed like incredibly professional work. My first thought was, "Is there even a place for a beginner like me?"
But then something happened while building my service. I was using a library and found a typo in the documentation. It was an English doc that said "teh" instead of "the." An obvious typo. At that moment, I thought, "Hey, I could fix this."
That was the beginning of my first open source contribution. It was just fixing a typo, but through that experience, I realized that open source contribution was much more accessible than I thought.
Initially, I thought of open source as just "code you can use for free." Find the library you need, run npm install, read the docs, and use it. But when I started contributing, I realized that open source isn't just code—it's a living community.
Someone finds a bug and opens an issue. Someone else tries to reproduce it. Another person suggests a solution. The maintainer reviews and merges it. This entire process happens publicly and transparently. It was like watching massive collective intelligence at work.
And I realized something profound. Tools I use every day—React, Next.js, TypeScript—were all built through this process. Thousands, tens of thousands of developers contributing bit by bit to create what we have today. Understanding this completely changed how I viewed open source.
After fixing that typo, I gained confidence and wanted to make a more meaningful contribution. So I carefully read through the documentation of a library I frequently used. And I found something odd. There was an explanation for a feature, but no actual usage example.
I remembered struggling with that exact feature. Reading the explanation alone didn't give me a clear idea of how to use it, so I ended up digging through GitHub Issues to find code examples from other users. I thought, "If only there had been one example, it would have been so much easier."
So I created an example based on code I had written and submitted a PR:
// Original docs: explanation only
// "useCustomHook accepts options parameter"
// Example I added
import { useCustomHook } from 'library';
function MyComponent() {
const { data, loading } = useCustomHook({
enabled: true,
refetchInterval: 5000
});
if (loading) return <div>Loading...</div>;
return <div>{data}</div>;
}
A few days later, the maintainer commented: "Great addition! This will help many users." And it was merged. The feeling at that moment... I couldn't believe my code was now in the official documentation that developers worldwide would see.
With confidence from the documentation contribution, I wanted to try fixing actual code. Coincidentally, there was a small bug in a library I was using in my service. It threw an error under specific conditions, and the reproduction steps were clear.
First, I checked GitHub Issues to see if anyone else had the same problem. They did! Someone had already opened an issue, but it hadn't been resolved yet. So I commented on that issue: "I can reproduce this. Let me try to fix it."
Forking the project, cloning it locally, and setting up the development environment was complicated at first. Each project has a CONTRIBUTING.md file with setup instructions. Following those worked.
The process of reproducing the bug, finding the cause, and fixing it was... honestly beyond my skill level. But I learned tremendously by reading the existing code. Things like "Oh, this is how you handle errors," "Defining types this way makes it safer."
Eventually, I completed the fix and submitted a PR. The maintainer reviewed my code and suggested some improvements, which I incorporated and pushed again. Through this process, I experienced production-level code review. I wasn't even working at a company, yet I was getting feedback from experienced developers. It was amazing.
The biggest gain from open source contribution was real-world experience—things you can't learn from books or courses.
Reading other people's code was really difficult at first. Especially large projects with hundreds of files and complex structures. But as I kept reading, patterns started to emerge. "Oh, this project organizes folders this way," "Error handling is done like this."
Looking at code from famous open source projects, I found many patterns I never would have thought of when coding alone. Seeing those made me think, "Ah, this is best practice."
Writing issues in English, crafting PR descriptions, and responding to code review comments was daunting at first. But I got the hang of it with practice.
I learned what a good PR looks like:
## Problem
Users get error when calling API with empty array
## Solution
Added validation check before API call:
- Return early if array is empty
- Show user-friendly error message
## Testing
- Added unit test for empty array case
- Tested manually in development environment
- All existing tests still pass
Being concise, clear, and explaining why this change is needed was crucial.
Most open source projects have clear workflows: issue templates, PR templates, code review processes, CI/CD pipelines. Experiencing these firsthand taught me, "This is how real development teams work."
What impressed me most was automation. When you submit a PR, tests run automatically, linting checks happen, builds execute—all automated through GitHub Actions or other CI tools. Seeing this, I applied it to my own projects.
Reflecting on my experience, the key to open source contribution is starting small. Trying to add complex features from the start is overwhelming. Instead, start like this:
Step 1: Find typos while reading docsNot every PR gets merged. Some of mine were rejected. I was a bit disappointed at first, but reading the maintainer's explanation made sense. Reasons like "This feature doesn't align with the project's direction" or "This can already be solved another way."
That was also learning. Open source projects have clear visions and directions, and every contribution must align with that direction. That's why it's important to check the project's roadmap or issue discussions before contributing.
Open source contribution is a journey that starts with small things like fixing typos, then expands to documentation improvements, bug fixes, and feature additions. It's scary at first, but once you start, you realize it's the best learning method that gives you both real-world experience and community networking. And most importantly, it feels rewarding to contribute to making the tools I use every day even a little bit better.