Two years ago, the idea of contributing to open source felt like something reserved for senior engineers at big companies. The code was already written. The smart people already worked there. What could I possibly add? It turned out the answer was: quite a lot. This is the story of how I went from passively consuming open source to actively shaping it — and what I learned along the way.
The Starting Point: Reading Code
My open source involvement began the same way for most developers: I had a bug I couldn't solve by reading the docs. The library was express-validator. I was trying to understand why a specific custom validator wasn't receiving the right context, so I cloned the repo and started reading the source code.
That was the turning point. Reading the source code of a library you use daily changes how you think about it. You stop seeing it as a magic black box and start seeing it as a collection of decisions made by humans who had the same constraints and trade-offs you face every day. Some decisions are brilliant. Some have known limitations. And occasionally you spot something that could genuinely be better.
The First Pull Request
My first contribution was not glamorous. It was a documentation fix — a misleading example in the README that had sent me down the wrong path for an afternoon. I corrected it, wrote a clear explanation in the PR description, and submitted. It got merged within 48 hours.
That small green "Merged" label had an outsized psychological impact. Something I wrote was now part of a package downloaded by millions of developers every week. The feedback from the maintainer was polite and encouraging. I was hooked.
Contributing to express-validator
After the documentation fix, I started looking more carefully at the issue tracker. I noticed a pattern: many issues were filed about edge cases in the validation chain that were actually documented behavior, but the error messages were confusing. I opened a series of PRs over several months that improved error messages, added TypeScript type safety in a few under-typed spots, and fixed edge cases in custom validator context handling.
The maintainers were responsive and constructive. Even when they declined a change, they explained why clearly. One of the most valuable lessons I learned from this period: a PR is a conversation, not a delivery. You propose, they review, you refine. That feedback loop made me a better programmer faster than anything else I've done.
Reading how experienced maintainers think about backward compatibility, API design, and edge cases taught me more about software engineering than any course I've taken.
The Helmet.js Chapter: 8 PRs
Helmet.js is a popular Express middleware that sets security-related HTTP headers. I started using it on a production service and noticed that the TypeScript types for a few middleware options were either missing or inaccurate. Some options accepted values that the documentation said were valid but that TypeScript rejected. Others accepted values that should have been rejected.
I fixed the first one and submitted a PR. The maintainer appreciated it and asked if I could look at other similar cases. That single conversation turned into eight merged pull requests over two months. The work was unglamorous — careful reading of MDN documentation for each HTTP header, cross-referencing with the Helmet source, writing precise TypeScript types, and writing tests. But the compound effect of eight small improvements is real. Those type fixes prevent actual bugs in real applications.
How to Find Projects to Contribute To
The best projects to contribute to are the ones you already use and have a real opinion about. You have context that random contributors don't. Here is a practical workflow:
- Pick a library you use every week.
- Clone its repo and read the source code — just the parts relevant to your use case.
- Browse the issue tracker. Filter by
good first issueorhelp wanted. - Look for issues with low engagement — fewer comments usually means fewer people competing to fix it.
- Read the contributing guide before writing a single line of code. Some projects require an issue discussion before a PR.
The Language Barrier Is Smaller Than You Think
For Arab developers, there is often an unspoken anxiety about contributing to international projects — the assumption that your English needs to be perfect, that you need to be articulate in code reviews, that your accent (in voice calls) will mark you as an outsider. The reality of async text-based code collaboration is that none of that matters much.
What matters in a PR: clear title, clear description of the problem and solution, tests, and clean code. I have never had a PR rejected because of grammar. I have had PRs declined because the change was unnecessary or because there was a better approach — and those were fair declines that I learned from.
The Practical Impact on Your Career
Open source contributions are resume signal that is hard to fake. When a potential client or employer sees that you have merged code into packages they use daily, the credibility is immediate. It signals several things at once: you can read unfamiliar code, you can navigate review processes, you care about quality beyond the bare minimum, and you think about how your code affects others.
More concretely: three of my freelance clients found me because they saw my GitHub contributions in a related ecosystem. One client specifically mentioned that my Helmet.js contributions were why they chose me for a Node.js security audit project.
Practical Tips for Arab Developers
- Start with documentation — docs improvements have the highest acceptance rate and the lowest barrier. They also force you to deeply understand the library.
- Fix TypeScript types — many Node.js libraries have incomplete or inaccurate TypeScript definitions. This is often low-hanging fruit that maintainers appreciate.
- Be specific in your PR description — "fix bug" is not a description. Link to the issue, explain the root cause, show a before/after behavior example.
- Don't be discouraged by rejections — a closed PR is not a personal rejection. Ask for feedback if none is given.
- Contribute in Arabic-related contexts too — Arabic developer tools, RTL libraries, i18n improvements. This is an underserved area where your unique perspective is a genuine advantage.
- Consistency over volume — one quality PR per month over a year is worth more than ten rushed PRs in a week.
What's Next
I am currently working on more substantial contributions — I want to move from fixing existing behavior to proposing and implementing new features. That is a different level of collaboration: it requires getting alignment from maintainers before writing code, understanding the project roadmap, and building trust over time. The skills are the same, but the scale of the conversation is larger.
If you are an Arab developer sitting on the sidelines of open source, the entry point is genuinely accessible. Clone a repo you use. Read it. Find something that could be better. Make it better. Submit the PR. The rest follows.