Pull requests are loud. Documentation fixes are not. Most of the open source community runs on the quiet half, the people who fix a typo, write a paragraph, file a clean bug, or reply to the same newcomer question for the fifteenth time. If you have ever closed a tab because a tool’s docs were vague, you have already seen the gap those people fill. You are closer to being one of them than the pull-request counter on your GitHub profile suggests.
The framing that open source only counts when you ship code is a habit, not a rule. It is a habit that exhausts maintainers, because every project is mostly held together by the boring middle layer: issues triaged well, READMEs that explain the install step that is actually broken, translations that did not get abandoned at version 1.0, and a kind person answering “how do I run this on Windows” in a thread that would otherwise rot.
Why the maintainer pool is so thin
Most projects are not short of volunteers. They are short of volunteers willing to do the unsexy work. The pattern repeats across small libraries, niche tools, and even large frameworks.
- A handful of people own the codebase and review every change. Most of them are unpaid, or paid as a side responsibility on top of a day job.
- Issues pile up faster than anyone can read them, because opening an issue is one click and triaging it is ten minutes of context loading.
- Documentation rots on its own. New versions ship with new flags, and the README from 2022 still says
python setup.py install. - Translators sign up for one release and disappear. The translation coverage in many open source apps is permanently stuck at 80 percent because nobody owns the missing 20 percent.
- Newcomers hit the same five onboarding questions, get an outdated answer from a 2019 issue, and leave.
None of that needs a compiler. All of it needs someone with an hour and the stubbornness to push through a slow review queue.
The moves that do not require code
You do not have to install a development environment to be useful. The list of contribution types that projects almost always need is long, and most of it is reachable from a normal web browser and a text editor.
- Triage issues. Read open issues, reproduce the ones you can, label them, close the ones that are duplicates or out of scope. Maintainers get hours back when a duplicate gets marked correctly instead of sitting in the queue.
- Fix the docs. Typos, broken examples, missing install steps, screenshots that show an old UI. A clear documentation PR (a proposed change you send to the project for review) often lands in a week, while a code PR might sit for months.
- Translate strings. Open source projects that ship in multiple languages rely on volunteers to translate the user interface through a platform like Weblate (a self-hosted translation platform many open source projects use) or POEditor (a hosted translation service with a free tier for open source). One hour of translation work can reach thousands of users.
- Answer questions in issues and forums. Search GitHub, the project’s Discord, Matrix room, or community forum for unanswered questions you can actually help with. Most newcomers want a sentence, not a paragraph.
- Report bugs well. A good bug report includes the version, the steps to reproduce, what you expected, and what happened. Filing one is a contribution, even though nothing ships.
- Donate or sponsor. Money is not the only way to help, but it is the way that lets the people who are already doing the work keep doing it. GitHub Sponsors, Open Collective, and Liberapay (three platforms that let you send money to open source maintainers directly) all integrate with most projects’ READMEs.
The list is not exhaustive. Every project has a CONTRIBUTING.md (a file in the project repo that lists how to contribute) that says what it actually needs. Reading that file is step zero.
What I actually do week to week
I keep a small running list of projects I rely on, and I check their issue trackers when I have a spare half hour. The pattern is the same each week: I open one project’s issues tab, look for anything tagged good first issue or documentation, and pick whichever one I can answer without setting up a build environment.
Sometimes the contribution is just a paragraph in a discussion thread confirming that yes, the install error on macOS Sonoma is reproducible, and here is the workaround that worked for me. Sometimes it is a one-line README clarification that the project maintainer has been meaning to write for three years. Sometimes it is a translation of two error strings into the language my family uses.
The cumulative effect is small per week and large over time. The exact number does not matter. What matters is that the contributions are in public project histories that anyone can audit, and the pattern has been running long enough that it is part of how I use software now.
The other thing I do is more selfish but still useful: I use the open source tools I depend on. Switching my phone’s map app from Google Maps to OpenStreetMap (a community-built map of the world, free to use and free to edit, that underpins many of the maps you already use without realizing it) via OsmAnd (an Android navigation app that draws its maps from OpenStreetMap) does two things at once. It removes one more data stream from a company that did not need it, and it gives the OpenStreetMap community another active user whose feedback shapes the project. Using the tool is not the same as contributing code, but it is not nothing either.
Trade-offs
There are real limits to non-code contributions, and pretending otherwise wastes everyone’s time.
- Maintainers still need code, and code contributions take longer to land. If your project has a maintainer who can review code PRs in days, count yourself lucky. Most do not. A non-code contribution moves faster precisely because it does not need a code review.
- Documentation-only PRs get deprioritized. Some maintainers will sit on a documentation PR for weeks because they are not the right person to review it. That is normal. Do not take it personally. If a docs PR stalls for a month, ping the maintainer or offer to be the reviewer for future docs PRs.
- Translation work needs ongoing care. Translating version 1.0 of an interface does not help anyone when version 1.1 ships next month with new strings. Translation is a long-term commitment, and it works best when you stay involved past the first release.
- Money is not a substitute for code review. If a project is starving for a maintainer who can review Rust, donating $20 to their GitHub Sponsors does not unblock the queue. It helps them afford the time, but the queue is still a queue.
- Some contributions have a higher bar than they look. A “good first issue” label does not mean the issue is actually small. Read the linked discussion before you commit your weekend.
Your first hour, if you have never contributed before
Pick one project you already use. Open its issue tracker. Find a tagged good first issue or documentation entry. Read the related discussion. If you can write a one-paragraph reply that helps the next person who hits the same wall, post it. If you can fix a typo in the README, fork the repo (copy the project to your own GitHub account so you can edit it without affecting the original), make the change, and open a PR.
That is the whole thing. Everything else is repetition.