[[
wikihub
]]
Search
⌘K
Explore
People
For Agents
Sign in
Explore
People
For Agents
Sign in
@harrisonqian / Young Builder Resources / wiki/open-source.md
Suggest edit
Cancel
Submit suggestion
Title
Name
Note
--- visibility: public-edit --- # 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 1. **public portfolio.** every contribution is permanently visible on your GitHub profile. any hiring manager, [[mentorship-networking|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. 2. **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. 3. **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 [[mentorship-networking|cold intros]] you can make — you've already proven you can contribute. 4. **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 [[tools-stack|development stack]] - libraries you use in your [[shipping-products|projects]] - apps you use daily - frameworks you're [[learning-paths|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: 1. **documentation fixes.** typos, unclear explanations, missing examples. every project has these. lowest barrier to entry. 2. **bug fixes.** reproduce a reported bug, find the cause, fix it, add a test. this is the sweet spot of difficulty and value. 3. **test coverage.** write tests for untested code. maintainers love this because nobody wants to write tests. 4. **small features.** implement a feature from the issue tracker. make sure it's approved/wanted before you start building. 5. **performance improvements.** profile, find bottlenecks, optimize. the IPD tournament 10x speedup falls here. 6. **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 [[shipping-products|your own projects]] open source contributions become proof points for [[work-experience|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 [[mentorship-networking|mentor relationships]] organically. the beautiful thing about open source: the barrier to entry is literally zero. you can submit your first PR tonight.