open source

contributing to open source is one of the highest-leverage things a teen builder can do. it's the most meritocratic environment you'll find — nobody cares about your age, your school, or your credentials. they care about your code. a merged PR speaks for itself.

why open source matters

public portfolio. every contribution is permanently visible on your GitHub profile. any hiring manager, mentor, or collaborator can click through and see exactly what you did, how you did it, and that someone else's project accepted your code.
reading other people's code. this is 80% of real engineering and it's almost never taught in school. open source forces you to understand a codebase you didn't write, find the relevant part, and make a change that doesn't break anything.
connections with maintainers. the people who maintain popular open source projects are often senior engineers, founders, or researchers. a good PR is one of the best cold intros you can make — you've already proven you can contribute.
real-world engineering practices. CI/CD, code review, testing, documentation, git workflow, issue tracking. open source projects use the same tools and processes as professional engineering teams.

my open source contributions

OpenClaw (April 2026)

first PR: loguru fix — merged. a small fix, but it got my foot in the door.
second PR: vite fallback — addressing a build issue.
the lesson: start small. your first PR doesn't need to be a major feature. fixing a bug, improving docs, or cleaning up an error message is a legitimate contribution that helps the project and gets you familiar with the codebase.

IPD tournament

forked from existing implementations
rewrote for 10x speedup
the lesson: forking an existing project and substantially improving it is a form of open source contribution. you don't have to start from scratch — you can make something that exists dramatically better.

how to start contributing

step 1: find a project you actually use

don't pick a random project from a "beginner friendly" list. pick something you actually use and care about. you'll be more motivated, you'll understand the user perspective, and your contributions will be better.

think about:

tools in your development stack
libraries you use in your projects
apps you use daily
frameworks you're learning

step 2: look at issues

search for issues tagged:

good first issue — explicitly meant for new contributors
help wanted — the maintainers are actively looking for help
documentation — often the easiest entry point
bug — small bug fixes are great first contributions

resources that aggregate these:

goodfirstissue.dev — curates easy issues from popular projects
goodfirstissues.com — aggregates good first issue labels across GitHub
firstcontributions.github.io — step-by-step guide for your first PR
forgoodfirstissue.github.com — GitHub's official curation of impactful first issues

step 3: read the contributing guide

every serious project has a CONTRIBUTING.md. read it. it tells you:

how to set up the development environment
the coding style and conventions
how to run tests
the PR process and review expectations

skipping this step is the #1 reason first-time contributors get their PRs rejected.

step 4: submit a small PR

your first PR should be small. a bug fix, a documentation improvement, a test case. small PRs get reviewed faster, are more likely to be merged, and teach you the contribution workflow without the risk of wasting weeks on something that gets rejected.

step 5: respond to review feedback

your PR will get review comments. this is normal and good — it's free mentorship from experienced engineers. respond promptly, make the requested changes, and ask questions if you don't understand the feedback.

what to contribute

ranked by difficulty and impact:

documentation fixes. typos, unclear explanations, missing examples. every project has these. lowest barrier to entry.
bug fixes. reproduce a reported bug, find the cause, fix it, add a test. this is the sweet spot of difficulty and value.
test coverage. write tests for untested code. maintainers love this because nobody wants to write tests.
small features. implement a feature from the issue tracker. make sure it's approved/wanted before you start building.
performance improvements. profile, find bottlenecks, optimize. the IPD tournament 10x speedup falls here.
major features. only after you know the codebase well. discuss with maintainers first.

the compounding effect

open source contributions compound:

your GitHub profile becomes a living resume
maintainers remember good contributors and invite them to bigger work
other projects see your contribution history and are more likely to accept your PRs
the skills you develop (code reading, git workflow, code review) make you better at your own projects

open source contributions become proof points for internship cold emails — "I have 5 merged PRs in [project they use]" is a stronger signal than any resume line. and the connections you make with maintainers can become mentor relationships organically.

the beautiful thing about open source: the barrier to entry is literally zero. you can submit your first PR tonight.