'Why am I doing open source?'
I love open source. Whenever I have free time, I go on GitHub to browse open source projects and contribute to them.
But one day, this thought occurred to me. Why am I doing open source?
From the very beginning of my development journey, I frequently referenced other developers' code. I was always curious about how code is written in real-world projects, so I explored various side projects published on GitHub. As I read through the code, I naturally dug into PR histories and gained many insights into what deliberations led to their architecture, why they chose certain libraries, and more.
Gradually, I became interested in open source libraries like React and Tanstack Query as well. So I casually started a study group where we dug into React's internals and I even implemented it from scratch in vanilla code. I wanted to understand open source on a deeper level.
Then, while looking at the Contributors section on GitHub, I thought 'It would be nice to have my name there too,' and started with small contributions like documentation translations and typo fixes.
While contributing to various open source projects, I was fortunate enough to become a maintainer of Suspensive, and I've made many great connections along the way.
Suspensive Contributors
Then I had a realization. Most of the tools we take for granted and use every day are open source. These open source projects are maintained by individuals or companies, but they rely on community sponsorship and contributions rather than revenue to keep the projects going.
So now, and this might sound grandiose, I contribute for the advancement of the ecosystem. Developers need to show interest and help for this ecosystem to move in a positive direction. Even a small contribution that goes unnoticed, if it comes from understanding and empathy for the project, is meaningful enough. I believe these small efforts accumulate and eventually benefit us all.
I also engage in modest sponsorship activities. Through GitHub Sponsors, I sponsor open source projects or maintainers, hoping to give back even a little for their efforts.
GitHub Sponsors
Start by understanding the overall structure of the project. The README is the front door of a project. Here you can understand what problems the codebase solves and what features it provides. You can find more detailed information in the getting started or introduction sections of the official documentation.
It's helpful to draw out the relationships between folders and files while understanding each one's role. Don't just look at the file structure — follow the flow to see how the main files interact with each other.
Tips for Understanding the Structure
I usually analyze in the following order:
- Find the project's entry point (e.g., index.ts) file
- Understand the roles of the main folders
- src/
- packages/
- examples/
- tests/
- Trace the import/export relationships to map out the code flow
A project's history is also an important learning resource. By looking at past PRs, you can understand what deliberations and decisions led to the current codebase's implementation. Sometimes an idea you came up with may have already been discussed, and you can learn why that direction wasn't chosen.
Things to Check Before Analyzing
Each project requires different prior knowledge. If the project is written in TypeScript, you need an understanding of TypeScript; if the project solves problems in a specific domain, you may need domain knowledge. Identify and prepare the necessary knowledge before analyzing.
Don't try to understand all the code from the start. It's nearly impossible to fully understand a vast amount of code without knowing its history. Instead, focus on the parts that interest you or that you want to contribute to. Starting with documentation is fine, and starting with small bug fixes is fine too.
First, make sure to check the CONTRIBUTING.md document. This document contains detailed information about the project's preferred contribution methods, from PR writing to commit message conventions and code style guides. Even good contributions can receive revision requests if they don't follow these guidelines.
Clearly explain your changes, and be sure to mention any related issues. It's important to write in a way that reviewers can easily understand. It's even better if you specifically explain why the code change is needed and what problem it solves.
Casual Tips for Writing PRs
When writing PR descriptions, I divide them into AS-IS and TO-BE sections.
I describe the current situation and problems, and then how things improve after the change, attaching screenshots or short videos.
Visual materials can effectively convey parts that are hard to explain in writing, and they also significantly reduce the maintainer's review time.
It's also a good idea to leave comments on your own code.
You can proactively ask for opinions on parts you'd like reviewers to focus on, or parts where you're unsure if your implementation approach is appropriate. This kind of active communication makes the review process more efficient.
Filing issues or leaving comments is also an important contribution. If you've found a bug, describe the reproduction steps in detail and share your thoughts on potential solutions as well.
When writing an issue, it's good to include the following:
- Under what circumstances it occurs
- The difference between expected behavior and actual behavior
- Minimal code to reproduce the problem (preferably reproducible via codesandbox or similar)
- Development environment information (OS, browser, library versions, etc.)
At first, everything may seem unfamiliar and difficult. I hesitated at first too, but starting small made it less daunting than expected. By fixing typos in documentation and participating in translations, I was able to naturally understand the projects.
I was able to see and learn from many great open source projects. I will continue to read code, contribute, and grow. Since we receive help from countless open source projects every day, it's now our turn to contribute even something small to this ecosystem.
Open source contributions don't have to be perfect.
"Perfect is the enemy of good."
Open source contributions don't have to be perfect. In fact, they don't need to be. Open source is a place where everyone participates. Even small contributions are meaningful.