A roadmap for building genuine contributors—from someone who's walked the same path
Before We Begin: I Need to Tell You Something
In 2018, I was exactly where you might be right now.
I was chasing credentials. Hunting for that one thing that would make my resume stand out. And then I cracked the Google India Challenge Scholarship—selected through Udacity, backed by Google Inc.
That moment changed my trajectory. But here's what I didn't understand back then: the scholarship didn't make me a better developer. The learning that came after did.
I'm telling you this because I need you to trust me when I say: I understand the pressure you're under. The placement anxiety. The family expectations. The feeling that everyone around you has figured out some secret you haven't.
I've been there. I've felt that desperate need to have something on my resume that proves I belong.
But I've also seen what happens when that desperation leads people down the wrong path. And I've spent years training thousands of engineers, watching some flourish and others struggle—not because of talent, but because of the choices they made early on.
So let me share what I wish someone had told me.
The Developer They Remember
Somewhere in Bangalore, a maintainer of a popular web framework is scrolling through pull requests on a Saturday morning. Coffee in hand, bleary-eyed, volunteering their weekend because they love the project they've built over seven years.
They pause at a PR titled "Update README."
It adds one line: their name. Just... their name. Added to the heading of the README file.
They sigh. Close. Mark as spam. Lock thread. Report user.
This ritual will repeat eleven more times before lunch. Each notification pings 485 watchers. Each one costs five minutes of attention. Each one makes them wonder why they bother.
Now imagine a different PR. Same maintainer, same Saturday morning. But this one fixes a bug the contributor actually encountered. The commit message explains the problem clearly. The code is tested. The contributor has been in the community for three months, helping newcomers in Discord, answering questions they once asked themselves.
The maintainer smiles. Merges. Remembers why open source still matters.
Which contributor do you want to be?
The Uncomfortable Truth: What's Actually Happening Right Now
I need to show you something that's been happening—and is still happening as you read this.
The ExpressJS Incident (It's Not Ancient History)
ExpressJS is one of the most popular Node.js frameworks in the world. Millions of applications run on it. And right now, if you go to their GitHub repository and look at closed pull requests, you'll find pages upon pages of PRs titled "Update README" or "Update README.md."
What are these PRs doing?
Adding names. Just names. "Swapnil." "Adarsh." "Speedy Navigation." Contributors simply adding their own names to the H1 heading of the README file.
As one developer who investigated this pointed out, searching "Update README" on that repository shows 20 pages of mostly garbage PRs mixed with a few legitimate ones. Another analysis found that approximately 22.8% of all open PRs on ExpressJS are these spammy README updates.
This isn't a bot attack. These are real people—our fellow Indian developers—following tutorials without thinking.
The Source: A Tutorial Watched by Millions
Here's what happened, and I'm sharing this not to shame anyone, but because you need to understand the mechanics of how this works.
A popular Indian educational YouTube channel with over 7 million subscribers published a Git and GitHub tutorial. It's been watched over 5.6 million times. And 99% of the video is genuinely helpful.
But there's a 3-minute segment near the end where the instructor demonstrates how to fork a repository. She uses the official ExpressJS repository for the demonstration. She shows how to edit the README (adding a name), and how to create a pull request.
Now, here's the thing: she explicitly warns viewers not to actually submit this PR. She says, verbatim: "This is a useless commit... do not actually create this pull request."
But here's what happens with a video that has 5.6 million views:
- Audience retention graphs show viewers often stop listening carefully by the end of tutorials
- Many viewers watch with the sound low, just following the visual steps
- Even if only 1% ignore the verbal warning and follow the visual steps...
That's 56,000 potential spam PRs.
As one Indian developer doing the math put it: with 1.3 million views at the time he checked, even 1% means 13,000 spam PRs for maintainers to deal with.
Why This Keeps Happening (Year After Year)
What makes this particularly painful is that this issue was identified over two years ago. Multiple prominent developers made videos about it. Comments on the original tutorial warn viewers not to create test PRs on official repos.
YouTube Studio allows creators to trim segments out of existing videos without re-uploading. The problematic 3-minute section could have been removed with a few clicks.
It wasn't.
And so every year—especially during Hacktoberfest season, or when new college terms begin—the spam comes in waves. ThePrimeagen, a popular developer and content creator, documented that two years later, it's still happening. The spam has spread beyond ExpressJS to other repositories, including Node.js itself.
The Real Consequences (They're Worse Than You Think)
Here's what many students don't realize:
1. You can get your entire GitHub account banned.
GitHub's Terms of Service explicitly prohibit "opening empty or meaningless issues or pull requests." As Hitesh Choudhary (Chai aur Code) explained in a video about this issue, getting flagged as a spammer doesn't just lock you out temporarily—it can destroy your reputation as a developer.
One user's account got suspended, locking them out of all their repositories—including sensitive ones—with no way to back them up. They eventually got it unlocked after contacting support, but the warning is clear.
2. CI/CD costs real money.
When you open a PR, it often triggers automated tests (Continuous Integration) on the maintainer's servers. Thousands of garbage PRs mean wasted computational power and money on changes that add zero value.
3. It reinforces the worst stereotypes.
Because of India's large population, even a small percentage of bad actors creates a massive volume of spam. This reinforces negative stereotypes about Indian developers in the global community—stereotypes that affect all of us, including those doing excellent work.
It's Not You—It's a System That Shaped You
Now, before you think I'm here to lecture you, let me say something important:
If you've ever felt the urge to just "get something on GitHub," you're not broken. You're responding rationally to a broken system.
Consider the math. Major coding programs offer stipends of ₹1.2-2.5 lakh over a few months. The average engineering internship pays around ₹17,778/month. Even elite internships cap around ₹50,000-80,000/month.
Colleges celebrate program selections as institutional achievements. Your seniors tell you that a "green contribution graph" matters for placements. YouTube thumbnails scream about earning lakhs from stipends.
The economic logic is overwhelming. The social pressure is real.
And here's the deeper problem: multiple studies have documented that our engineering education system "still leans heavily on classroom lectures, textbooks, and rote learning." Open source isn't in most curricula. Git workflows, community etiquette, how to read unfamiliar codebases—these skills are left for you to figure out on your own.
So when a YouTube video shows a shortcut, is it any surprise thousands take it?
But here's what I want you to understand: the shortcuts don't lead where you think they lead.
Chasing green contribution squares or free t-shirts via spam PRs has—and I cannot stress this enough—0% impact on your actual career growth. The hiring managers I talk to don't count contribution squares. They look at the actual code. They check if your PRs were merged or closed as spam. They notice if your "contributions" are just README edits.
The irony is brutal: the very thing you're doing to improve your resume could be what destroys it.
A Moment of Encouragement (Yes, Really)
Here's something that might actually make you feel better.
One developer who analyzed this situation offered a surprisingly motivating perspective to skilled developers worried about market saturation:
"Your competition consists of these people who blindly copy-paste without thinking. If you have genuine skills and critical thinking, you have nothing to worry about—because the vast majority of the crowd lacks these basics."
Read that again.
The bar is not as high as you think. You don't need to be a genius. You don't need to attend an IIT. You don't need to have been coding since age 10.
You just need to be someone who thinks before they act. Someone who reads the instructions. Someone who asks, "Does this actually add value?"
That alone puts you ahead of a terrifying percentage of your peers.
What Actually Works: Lessons From Those Who Got It Right
Let me tell you about programs that successfully build real contributors.
Outreachy's Three-Phase Model
Outreachy places contributors into open source projects. Here's how selection works:
Phase 1: You write essays explaining your genuine interest. They explicitly warn against AI-generated content. They're looking for authentic motivation.
Phase 2: You spend four weeks actually contributing. Not writing proposals about what you might do someday—doing the work, now, in public. This is the brutal but beautiful filter: it selects for people who can work independently, communicate publicly, and prioritize quality over quantity.
Phase 3: Mentors rank applicants 1-5 based on demonstrated work. "5 = Amazing applicant, could become maintainer, extensive high-quality contributions."
The key insight: selection happens after demonstrated contribution, not before. You can't game a system that requires you to actually do the thing.
The Apache Way
The Apache Software Foundation uses a similar philosophy. Contributors progress through levels: User → Contributor → Committer → Project Management Committee Member → Foundation Member.
Their core principle is "Community Over Code"—they'd rather have a healthy community with mediocre code than brilliant code maintained by toxic people. Because over time, healthy communities produce better code anyway.
Post-Crisis Hacktoberfest
After the 2020 spam crisis (which I'm sure you've heard about—it was covered by The Register, InfoQ, and sparked the #shitoberfest hashtag), the annual open-source celebration made structural changes:
- Maintainers must opt-in by adding a specific tag
- Contributions only count when maintainers explicitly label them "accepted"
- Users with multiple spam PRs are permanently banned
- An advisory council provides ongoing feedback
By 2022, the same program saw 146,891 participants from 194 countries producing 335,000 contributions—with measurably higher quality.
The lesson: give gatekeepers control, require demonstrated work before recognition, and make gaming harder than genuine contribution.
Understanding What You're Walking Into
Before you submit your first pull request, I need you to understand something that will change how you approach every interaction.
According to the 2024 Tidelift Maintainer Report:
- 60% of maintainers are not paid for their work. At all.
- 60% have quit or considered quitting maintaining their projects.
- 44% cite burnout as the reason.
These are volunteers. They have day jobs, families, health problems, grief. They maintain code that powers companies worth billions—for free, on weekends, often alone.
As one developer put it bluntly: "Open Source is not a playground for absolute beginners to test buttons."
That sounds harsh. But think about it this way: would you walk into a stranger's workshop and start randomly pressing buttons on their equipment? Would you "test" hacking on Google's servers just to learn how penetration testing works?
The same principle applies here.
When you ping a maintainer asking to be assigned an issue you haven't researched... When you submit a PR that doesn't follow the contribution guidelines you didn't read... When you ask questions the documentation already answers...
You're not just wasting time. You're contributing to the burnout that's killing the ecosystem that benefits all of us.
But flip it around:
When you show up having done your homework... When your PR is small, focused, well-tested, and solves a real problem... When you help newcomers instead of just asking for help...
You become the kind of person maintainers want to mentor. The kind who might, someday, become a maintainer yourself.
A Personal Roadmap: Four Phases to Becoming a Real Contributor
Let me give you the framework I wish I'd had when I started.
Phase 1: Foundation (Before You Touch Any Codebase)
Technical skills to build:
- Git proficiency: branching, rebasing, resolving conflicts, writing meaningful commit messages
- Ability to set up development environments from documentation alone
- Comfort reading code you didn't write
Mindset shifts to make:
- "Read the manual before asking" becomes your default
- You accept that maintainers don't owe you anything
- You commit to contributing only to projects you actually use or care about
Practice first: Create your own repositories. Test features there. Break things in your own sandbox—not in someone else's production codebase.
Checkpoint: You can clone a project, set it up locally, run the tests, and navigate the codebase without asking anyone for help.
Phase 2: Community Orientation (Observe Before You Participate)
Activities:
- Join the project's communication channels (Discord, Slack, mailing lists)
- Read the last 50 issues and 20 merged PRs
- Identify who the maintainers are and how they communicate
- Understand the project's rhythms: when are people active? How long do reviews take?
The silent observation period matters. You're not just learning the codebase—you're learning the culture. Every community has unwritten rules. The only way to learn them is to watch.
Checkpoint: You can explain the project's governance structure, name the active maintainers, and describe what a good contribution looks like for this specific project.
Phase 3: Quality Contribution (Your First Real Work)
Good first contributions:
- Fix a bug you actually encountered while using the project
- Improve documentation that genuinely confused you
- Write tests for untested code paths
- Respond to issues with helpful debugging context
Quality standards:
- PRs are small (50-200 lines ideally)
- Commit messages follow the project's conventions (check their CONTRIBUTING.md)
- You respond to review feedback completely and promptly
- The key test: You don't need the certificate to feel good about the work
As ThePrimeagen advised: Join the Discord of a project you like. Ask for advice on which issue to tackle. Spend hours debugging, adding print statements, understanding the code. Submit a PR with actual value.
"Real joy in programming comes from solving actual problems, not from adding your name to a README."
Checkpoint: You have at least one contribution merged with positive feedback from a maintainer.
Phase 4: Sustained Participation (Where Real Growth Happens)
Activities:
- Move beyond "good first issues" to meatier challenges
- Help review other people's PRs (even without commit access)
- Answer questions from newer contributors
- Take on documentation ownership or triage duties
6-month metrics that matter:
- Are you still contributing to the same project?
- Do maintainers recognize your name?
- Have you helped anyone else get started?
Checkpoint: Someone refers to you as a regular contributor, not a drive-by participant.
Start Today: Your First Three Actions
Don't wait until you "know enough." Here's what you can do this week:
1. Pick ONE tool you use daily that's open source
Maybe it's VS Code, a testing library, or a linter. Don't pick something famous just because it's famous. Pick something you actually use—because you'll understand the problems it has.
2. Find and join their community
Look for a Discord, Slack, or discussion forum. Introduce yourself briefly. Then lurk. Read. Learn how people talk to each other there.
3. Set up the project locally
Clone it. Read the README. Follow the setup instructions. Run the tests. If something in the docs confused you, write it down—that confusion is your first potential contribution.
That's it. No PRs yet. No issues opened. Just presence, observation, and preparation.
A Word About Your "Competition"
I want to leave you with something that might fundamentally change how you see your situation.
You're worried about saturation. About competition. About whether there's room for you in tech.
But think about who your "competition" actually is:
- People who submit PRs adding their name to README files
- People who follow tutorials one-to-one without thinking
- People who can't understand the purpose of a Pull Request
- People who chase green squares instead of actual skills
As one developer observed: if you have genuine skills and critical thinking, you have nothing to worry about—because the vast majority of the "crowd" lacks these basics.
The bar is not adding your name to ExpressJS. The bar is solving real problems.
And that bar? It's completely achievable. Not because you need to be exceptional—but because so many people aren't even trying to clear it.
Resources for the Journey
Learning Git properly:
- Oh My Git! (interactive game): https://ohmygit.org/
- Git Katas (exercises): https://github.com/eficode-academy/git-katas
Understanding open source culture:
- The Apache Way: https://www.apache.org/theapacheway/
- First Contributions: https://firstcontributions.github.io/
Finding projects that welcome newcomers:
- Good First Issues: https://goodfirstissue.dev/
- CodeTriage: https://www.codetriage.com/
Indian open source communities:
- FOSS United: https://fossunited.org/
- amFOSS (Amrita): https://amfoss.in/
A Final Word
I started this by telling you about my Google India Challenge Scholarship in 2018. Let me tell you what I didn't say:
That credential opened doors. But what kept those doors open was the work I did after—the skills I built, the communities I joined, the problems I solved. The credential was a starting point, not a destination.
If I had gotten that scholarship by gaming the system, by cheating, by submitting spam... it would have been worthless. Because the moment I was asked to actually do something, I would have been exposed.
The path I've described in this post is harder. It takes longer. It requires you to care about more than credentials.
But at the end of it, you'll be someone who can actually build things. Someone maintainers trust. Someone who gets opportunities not because of resume keywords, but because people have seen your work.
Someone who, when they say "I'm an open source contributor," actually is.
The developer you could become is waiting. Start today.
If this resonated with you, share it with a friend who needs to hear it. And if you're already doing the hard work of genuine contribution—thank you. The community needs more people like you.
— Divyansh Bhardwaj
Corporate & Technical Trainer | Google India Challenge Scholarship Recipient 2018
Teaching engineers to think, not just code
Top comments (0)