You have a few merged PRs. Maybe a maintainer thanked you by name. Now the question shows up: can this turn into money?
Sometimes. Not the way most people picture it. This page is the real paths from open source contributions to income, ranked by how often they actually pay a contributor, plus the boring admin once they do. It is not a resume page. That is open source on your resume. It is not a hiring-signal plan. That is five merged PRs.
Short version: almost nobody gets paid for their first five PRs. People get paid because of their first five PRs, later, by someone who already reviewed them.
Sponsors and donations
GitHub Sponsors and Open Collective let people and companies send money to a person or a project.
They mostly pay maintainers, and mostly the maintainers of things a lot of companies depend on. A contributor with a handful of merges is not on anyone’s sponsor list. That is fine. It is not the path for you yet.
Where it does matter: if you end up owning a part of a project --- a plugin, a language binding, the docs site --- the project’s Open Collective sometimes pays for specific work. Ask in the project channel how the budget is spent. Do not ask for money in your first PR description.
Turn on a Sponsors profile if you want. Do not expect it to pay rent.
Bounties
Some issues carry a cash bounty, from the project, a company that needs the fix, or a bounty platform.
This is the path people try first, and the one that disappoints most often:
- Low payouts. Many bounties are small amounts for work that takes days once you count setup, review, and rework.
- Races. Several people open PRs for the same bounty. One gets merged. The rest worked for nothing.
- Bounty farming. Bounties attract low-effort and AI-generated PRs that ignore the issue and the guidelines. Maintainers spend their time closing spam.
- Many maintainers dislike them. Some projects refuse bounties outright, or close bounty-chasing PRs on sight. A bounty can turn a small issue into a pile of noise.
If you take one anyway: read the project’s rules first, claim the issue the way the project asks, and write the PR as if no money were attached. A merged, reviewed PR is worth more to you than the payout. A rejected bounty PR is a public record of the opposite.
Never open a PR on a project you have no interest in just because a dollar sign is on it.
Maintainers hiring contributors they know
This is the path that actually pays, and the one nobody advertises.
Projects with a company or a paid product behind them need help. Companies that depend on a project need someone who already understands it. When either one needs a contractor, the first list they check is people who have already merged something and survived review. No job post. A message.
You cannot apply for this. You can make yourself the obvious name:
- Stay on one or two projects. Issue two on the same repo beats ten repos with one typo each.
- Take the unglamorous work: tests, a flaky CI job, a migration, a docs hole that keeps generating issues.
- Answer review quickly and without drama. Maintainers remember who was easy to merge.
- Say once, plainly, that you are available for paid work --- in your GitHub bio or profile README. Do not pitch in issue threads.
Most of these start as small, scoped contracts: one feature, one integration, a fixed number of hours. That is normal. A good first contract leads to the second.
OSS-adjacent jobs
The larger version of the same thing: a full-time job at a company that builds on, sells, or maintains open source. Developer tools companies, infrastructure vendors, companies with an open-core product.
Here your merged PRs are the interview. A hiring manager can open the review threads and see how you work. How hiring managers read GitHub covers what they look at. Apply where you already contributed, or where you use the project at your day job. “I fixed this bug in your project last month” is a better opener than any cover letter.
Do not contribute to a company’s repo only to get hired there. It shows, and it usually stops when the rejection arrives.
Grants
Foundations and public funds pay for open source work: security audits, maintenance, accessibility, specific features. NLnet in Europe is one long-running example; there are others, and the list changes.
Grants usually go to projects, or to people already doing sustained work on them, with a written proposal and milestones. It is a real path for someone who has become a regular on a project and wants to fund a defined piece of work. It is not a path for a contributor with three PRs. Read the program rules before writing anything. Deadlines and eligibility are strict.
The admin side of contract income
The first time a maintainer or a company pays you as a contractor, you become a small business for tax purposes. Nobody withholds anything for you. This part is not exciting, and skipping it is expensive.
What applies depends on your country. Two things are true almost everywhere:
- Keep a record of every payment, every invoice, and the costs of doing the work.
- Set money aside from each payment for tax when it arrives, not at the end of the year.
If you are in the US and get paid as an independent contractor (the client sends you a 1099 instead of a W-2), there is no employer withholding income tax or paying half your Social Security and Medicare. You usually owe quarterly estimated taxes, due around April 15, June 15, September 15, and January 15 of the following year (moved to the next business day when the date lands on a weekend or holiday). You also owe self-employment tax: 15.3% for Social Security and Medicare, on top of income tax. That rate surprises most people on their first contract.
Before the first due date, estimate your quarterly 1099 taxes so you know how much of each payment to keep aside. Then talk to an accountant once your contract income is more than pocket money. This section is not tax advice. It is the minimum you should know before you send your first invoice.
Outside the US the rules are different, but the habit is the same: find out before the first payment, not after the first bill.
What to do this month
Do not chase money with your next PR. Chase the next merge on a project you would be happy to be paid to work on.
- Pick one project you use and like. Find a live issue on the open source issues feed.
- Merge it. Stay for review. Then take issue two on the same repo.
- Write those merges up honestly: open source on your resume.
- Add one line to your profile saying you take contract work.
The money comes from the people who already reviewed your code.
Related
- Five merged PRs: a practical hiring signal — the set of work that gets you noticed
- How hiring managers read GitHub — what someone opening your profile looks for
- After your first open source contribution — stay for issue two
- Open source on your resume — the document, one bullet per merge
FAQ
Can I make a living from GitHub Sponsors?
A few maintainers of widely used projects do. Contributors almost never do. Treat sponsorship as a maintainer path, not a contributor one.
Are bounties worth it?
Sometimes, on a project you already work on, with rules you have read. Hunting bounties across random repos mostly produces rejected PRs and low hourly pay.
How do I find paid open source contract work?
Become a known contributor on a project with a company or paying users behind it, then say plainly that you are available. Most of this work is offered, not posted.
Do I owe tax on small open source payments?
Usually, yes, depending on where you live. In the US, contractor income on a 1099 is subject to income tax and 15.3% self-employment tax, often paid quarterly. Check your own situation with an accountant. This page is not tax advice.