Hacker News Reader

Comment by kirillrogovoy | Hacker News Reader

I think the world of open source would be a better, not worse, place if we had some usable bounty system at the level of issues/PRs.

And I say it both as a contributor, but also a consumer. Sometimes I'd be happy to throw $100 on top of some specific issue of a lib/app I use regularly to incentivize its resolution.

I wish this service didn't require repo owners to do anything before they see some actual bounty assigned to one of the issues. So, theoretically, I could go and assign a bounty to any repo on Github right now, and the owner (and maybe the public) would see it right away.

View on HN

> Sometimes I'd be happy to throw $100 on top of some specific issue

The problem with this approach is that while that's a lot for you to throw on a bounty, it's not much compared to the going rate of a software engineer. Even as a full-time employee you're probably making north of $90/hour and a good bug that gets a bounty certainly takes longer than an hour to fix.

Maybe it's low if the $100 is coming from a single person that needs it desperately. But if the fix brings big value to the community as a whole, we'll like see more people chipping in as the incentive grows.

Exactly, I'd probably contribute small amounts to multiple issues/projects in hopes that others also contribute enough to motivate someone to apply the fix.

Often I want to fix the issue myself, but something prevents me from doing so. I might not be familiar enough with the programming language, or I might not have enough time right now

Perhaps if several small payments are combined on the same bug, it could be paid for.

Bug 1 (25% pledge): XXX set a pledge of $100. $300 more needed to fix the bug.

> Even as a full-time employee you're probably making north of $90/hour

Assuming everyone is making 180k is maybe a bit naive, no?

Perhaps PRs could be marked with a bounty amount that would notify maintainer/owner when a threshold of $ has been met.

Actually that's not necessary, with Merge to earn it's theoretically possible to send whatever amount to only the contributors of a PR (instead of all contributors).

Imagine putting money into a vault that gets released to contributors on PR merge.

Opensource developers don't get paid. You're saying that paying them money demotivates them because they can earn money by not doing opensource work? The reality is that people paying a bounty sends a message that they really want this problem to be resolved or feature implemented. Maintainer burnout is minimized because people don't spam bounties on things they don't care about.

But here's the thing- most developers are salaried. I'd love extra work than can be done on my time for a bounty even if it's way lass than my salaried rate. It'd be the perfect way to moonlight.

I don't see why the repo owner needs to do/approve this. All this requires is that the repo can be forked. I could see a product looking like this.

   -Define a CI-like pipeline that runs tests that will fail if the bug persists and succeed if the bug is fixed.
   -Allow bounty seekers to pass links to branches/repo forks that try to pass the tests.
   -The first one to pass the tests get the bounty released to them
   -As a courtesy, the system should probably offer the patched code as a PR to the original repo, even if they don't accept it.

This might work for libraries (with the addition of the obvious "and doesn't obviously game the system by special casing all the test inputs" rule, because as soon as you add financial incentives, someone will try that).

I'm not sure it works for end-user software; the set of people who can write working tests is usually smaller than the set of end users.

Rewards mechanism are set at the repo/organization level, only maintainers know what to merge and how to reward contributors. Many solutions can be explored to find common patterns.

The effort to set up a test suite is oftentimes significantly higher than simply fixing a bug or adding a feature.

Paying a pittance, for something that was previously given away for free, makes it less valuable. Human psychology is notoriously fiddly, be careful.

MTE rewards are designed to give partial ownership of the project to a contributor. So I'd say it's natural that such issues are opened by project owners.

But the bounty system you mention is interesting. This is already implementable in the current system (ie open an issue and commit to give $ to those who fix it), but you'd need to peek at the PR solving the issue and manually send $ to those who fixed it.

We can easily automate that.

Reply on news.ycombinator.com