I've been writing code since university. Almost all of it was public: contributions to upstream open source communities, where the work is visible, the feedback is real, and the users are often strangers across the world who depend on what you build. I loved it.
But somewhere along the way I started noticing something uncomfortable. Open source depends on two groups of people: the contributors who write the code, and the maintainers who review it, merge it, and keep the project coherent. Bounty platforms existed that let companies or individuals put money on GitHub issues. The payout always went to the contributor. The maintainer who had to read every line, test it, reason about edge cases, and ultimately accept responsibility for the merge? Nothing.
Living it from both sides
I was a Project Team Lead for OpenStack Quality Assurance upstream projects. My daily reality was Gerrit: reading patches, writing reviews, asking questions, waiting for new patchsets, then doing it all again. A good review takes real effort. You have to understand the change, understand the context, catch the problems the contributor might not see, and write feedback that's useful rather than discouraging.
And then there's the merge itself. On a big project with hundreds of users and dozens of CI jobs running against every commit, merging bad code breaks things for everyone. That weight sits with you. The contributor moves on; the maintainer carries the responsibility.
It was never one specific moment that made me think something was wrong. It was the slow accumulation of the same frustration, on both sides, over years. As a PTL, there were stretches where I reviewed the same patch three or four times because the contributor kept returning with small revisions, and each time I had to reload the full context to give a useful opinion. That effort is invisible in the git log. The commit message records who wrote the code. It doesn't record who spent an afternoon making sure it was safe to merge.
But I also spent years on the other side, as an engineer writing patches and waiting for reviews. I know what it's like to post something and then wait. Weeks, sometimes. The context fades. You move on to other tasks. When the review finally arrives, getting back into the mindset of that patch takes time you didn't plan for. The delay doesn't just slow down that one contribution. It gradually wears down your motivation to contribute at all.
Nobody is really at fault. Open source work just isn't compensated in a way that makes responsiveness easy. People are busy. Reviews happen when they happen. But that doesn't make the problem less real or less worth solving.
The gap no one was filling
Bounty platforms weren't new when I started thinking about this. But every one I looked at had the same design: someone posts a reward on a GitHub issue, a contributor solves it, the contributor gets paid. End of story.
That model treats a merged PR as if the contributor is the only person who made it happen. They're not. The maintainer who reviewed it, who read it carefully, gave feedback, waited for revisions, and ultimately accepted responsibility for putting it into the codebase, did real work too. Unpaid work, in every model I could find.
That seemed unfair. Not only as an abstract principle, but also from a point of view of someone who'd spent years doing that work and watching others do it too.
The 80/20 split
The model I started with was an 80/20 split. When a bounty is claimed, 80% goes to the contributor who implemented the fix, and 20% goes to the maintainer who reviewed and merged it. The Pareto principle turns up everywhere, and I think it works here too.
The split is calibrated to motivate both sides. Contributors get the larger share because they carry the implementation effort. Maintainers get a meaningful cut because their work is essential and currently invisible. Eighty percent is enough to make a fix worth pursuing. Twenty percent is enough to make a review worth prioritising.
As a maintainer, one of the most frustrating experiences was giving someone a review and then waiting weeks for a revised patchset. By then I'd forgotten half the context and had to re-read everything from scratch. As an engineer, the equivalent frustration was posting a patch and waiting just as long for the maintainer to get back to it. Both problems have the same root: no strong incentive to respond. The split is designed to change that.
Why time limits matter
Every reward on OtterSource has an expiration date. If a company or individual is willing to put money on a GitHub issue, it's because they need it solved, not in theory or sometime eventually, but within a reasonable window. They have a product to ship or a dependency to unblock.
The time limit makes that explicit. Everyone knows the window. Contributors know when the reward expires. Maintainers know when they need to have reviewed and merged. The person who posted the bounty knows what they're committing to. Transparent, clear, and plannable, which is very much in the spirit of open source.
Where the model got complicated
Building out the payment architecture surfaced a harder problem than I expected. Moving money between funders, contributors, and maintainers puts a marketplace into a different regulatory category than a SaaS product: payment institution licensing under PSD2 in the EU, DAC7 income reporting for European contributors, e-money rules if you offer credits, and fee economics that break down on small bounties once you price in the actual cost of marketplace payment infrastructure.
None of these are individually fatal. Together, they describe a different product than I had designed, or a much bigger business, the kind that needs serious capital and licensing runway before it can hold funds for third parties at all. The mechanism is being rethought. The problem and the principle haven't changed: open source work needs to pay the people who actually do it, contributors and maintainers both. How the money moves is the part still being worked out.
What OtterSource is
OtterSource is a marketplace where anyone (an individual, a team, a company) can post a time-limited reward on any public GitHub issue. When the issue is resolved and the PR merged, both the contributor and the maintainer get paid. The exact model is still being worked out, but the principle is fixed: the person who wrote the code and the person who made sure it was safe to merge both deserve recognition.
The name follows the same logic as my other project, OtterSay: a word play on "open source", otters are my partner's favourite animal, and .com availability was part of the decision. It fits.
Where things stand
As I write this, OtterSource is in early development. The idea has been sitting with me for a while; the implementation is only now catching up. If you depend on open source, as a developer, a maintainer, or a company with OSS in your stack, head to ottersource.com. The otter is getting to work.
Update, May 2026: The payment architecture and business model are being rethought. OtterSource is still live at ottersource.com and you can sign up for updates. The direction has changed. The mission hasn't.