Show HN: Merge to earn – reward system for open source development | Hacker News Reader

Show HN: Merge to earn – reward system for open source development

github.com

37 pointsjjranalli44 comments

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.

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.

> 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.

Involves a dumb and convoluted cryptocurrency instead of actual money. This smells of a scam.

And most of it is unnecessary. Git commits already have identifying info tied to them so there's no need to maintain a separate list of 'owners' using this thing when you can just `git blame`.

Merge to earn uses smart contracts to make this possible in a permissionless and automated way. It also doesn't impose projects to use any cryptocurrency (only ETH is always accepted, any other must be explicitly specified).

I'd be more interested to hear opinions that go beyond the crypto = scam argument.

This HN. They all missed the boat on crypto so it must be a scam forever.

If the permissionless part isnt attractive to someone, then they can add an issue on the repo and say "trust me i'll pay you".

I'd love to see if some the following issues have been thought through:

- This sounds like spec work, where someone writes up a PR and submits hoping that they will be picked and/or paid the amount they request

- What happens if there is a disagreement about the payment amount? If the submitter withdraws their PR, are the maintainers then limited in their ability to code up their own fix since they've already seen the PR?

- If someone submits a PR and gets paid, then a bug is found in their code, do they have to pay from their share to fix the bug? What if the payment amount requested for the fix is higher than their share?

- It sounds like payment amount is determined through negotiation between the maintainer and submitter, or through discretion of the maintainer. Any clear metric on amount is likely to be gamed.

- If a PR solves an known issue, maintainers could specify the prospective reward in advance on the issue. The contributor should though always be able to set their own terms, discuss them with maintainers, and see them go through once the PR is merged.

- Maintainers could theoretically steal the code in a PR, but since everything is public they would lose reputations with contributors and the community. Future contributors will be wary of opening new PR in case maintainers act in bad faith.

- MTE doesn't impose any restriction or rules when it comes to how contributions should be managed, so it's up to project owners to come up with their own rules.

- I'd expect projects to specify objective rules to quantify rewards, for example based on effort required, task difficulty and impact on the project. I would also expect that estimates would naturally become more accurate as the project and number of maintainers grow

"I'll solve this problem using cryptos", congrats you now have 34 problems and 92 security issues.

So we are looking at something like

- quadratic voting for issues to be fixed,

- buy votes by putting money into escrow / promissory fund

- openly available like patreon

The only problem is amazingly, how do you agree that the job has been done, to a quality standard you agree with.

I think this is the very core and essence of Coase's theory of the firm. It is management of a firm that decides on quality. To this extent Maintainers are management.

It's worth pointing out that as software eats the world the majority of management must come from judging quality of software produced - something current management structures are not setup for.

Ultimately you cannot contract for specific work in a market - you have to wait for the market to provide speculative development that you then "purchase".

Weirdly Open Source Software is a market failure ...

(I suspect there might be a future market of standard contracts between (business defined) micro-services - you could use an open source piece of software that fulfills a micro-service requirement - and because the contracts are standardised the market would be huge, swappable and vibrant.

A massive problem that crypto faces right now is that there's basically a whole army of hackers going around every single crypto project and figuring out how to smash their way in and steal all the cyrpto. So whilst this idea is of rewarding productive contributions to open source (which btw, I'm not sure this solves), what it's actually doing is putting a massive fucking target on the back of any open source project that adopts this.

It basically says "here's a pointer to a pot of money, smash up this git repo to get it". What's more likely to happen, contributors spend a tonne of effort contributing to open source for a tiny share of the money in the wallet? Or hackers break into your github account, open an issue, allocating all the money in the wallet to it, merge the PR and sign off on draining the wallet?

I know what I'd bet on.

By breaking into a github account hackers won't be able to drain any founds, this is not something that is handled by github authentication. Founds are stored in a multisig Safe wallet, transactions must be approved by the multisig owners.

Apart from that, you are practically saying "hey there are hackers out there, stop building tools".

If the payments aren't integrated into the github merge system, then what is this system doing at all. Why not just put a message in the merge commit saying "Hey, please send me eth at this address"?

TLDR; Compromising Merge to earn projects is not worth for an attacker as it requires:

- satisfying multiple hard requirements,

- yields low rewards, and

- can be easily and quickly mitigated by project owners.

Full answer:

---

What you describe is actually not possible for a number of reasons.

In order for an attack on a Merge to earn project to have success, an attacker needs to obtain:

- Access as owner / maintainer to the Github repo, and

- The private keys of the wallets of enough safe owners to autonomously execute transactions. The general rule for multisigs is, the higher the quorum, the higher the safety.

In absence of both conditions, project maintainers have plenty of time to get control of the situation, and the attacker couldn't do anything. In fact, even if a Github account is compromised and fake PRs are merged to give themselves fat rewards, nothing happens until multisig owners actually execute the malicious transactions.

But, even though extremely improbable, let's assume an attacker manages to do that and the worst possible scenario happens. What then?

Due to how slicers are designed, the attacker wouldn't be able to get money received until that point out of the slicer, but only what has been received after he gained control. The Slice protocol has been designed to safeguard against these kind of attacks and malicious usage.

On the contrary, to mitigate an attack, project owners just need to reinitialize MTE for their repo with a new slicer and multisig, distribute ownership to contributors as it was before the attack, and redirect any new income and donations to the new slicer. This is technically trivial and can be done in minutes.

There seems to be a fundamental problem here - which is that either this system automatically processes transactions as conditioned by github merges. In which case you're basically saying my github credentials need to be as secure as my bank account, even if you think multisig means that we need to hack a couple of accounts rather than just one.

>Due to how slicers are designed, the attacker wouldn't be able to get money received until that point out of the slicer,

How does a normal person get money out of a slicer? That's how the hacker will.

>On the contrary, to mitigate an attack, project owners just need to reinitialize MTE for their repo with a new slicer and multisig,

You're saying that you foresee people starting a new pot of money to be stolen in the immediate aftermath of their old MTE money being stolen?

I've been trying to figure out a similar system when I looked at potentially making some software source available. I wanted contributors to receive a portion of that months sales for the software, possibly including future ones as well. Some kind of development equity setup. It fell apart when you start trying to codify/cement how the equity is awarded, nothing is ever clear cut when considering level of effort/impact.

While this project tries to solve the money aspect (not sure benefit of it vs other sponsor distribution platforms...), it doesn't solve the biggest issue: how do you figure out who gets what. I can't imagine the kind of vitriol it would generate in the face of CoEs and modern meritocracy controversies for open source projects. Money corrupts everything.

Figuring out the rules for contributions is definitely a challenge, but should not be up to a tool like MTE to solve as it depends on too many variables. Each project should have its own rules and grow to reward equitably its contributors.

We definitely plan to contribute to this, and even propose flexible guidelines for projects to base their estimates on.

Of course nobody would exploit this by submitting a PR that just deleted the failing test…

Adding money to the mix or automating rewards is asking for abuse and would decrease the quality of the software.

Also, which open source project is awash with money that could afford to pay out?

I think this (monetisation/crypto) is a solution looking for a problem and open source isn’t it…

There are many open source projects and software that produce value, and most importantly there are many paid people who work on it.

I'd like something like this to work, but it seems to attract the worst elements of hacktober, security beg bounties, payout negotiation conflicts, and the inconvenience of dealing with cryptocurrency. Given that we have bountysource and gitcoin already, I don't have high hopes for mte. Mostly from the social side.

It would be neat if people could post or request a reward on Github issues. Maybe it's a maintainer-only feature, since they have to sign off on the final value. This would enable a way to post requests for work without having to open an empty PR.

Maintainers can and are encouraged to specify the entity of the prospective reward in the issue (see examples here https://github.com/slice-so/merge-to-earn/issues).

However this should be limited to maintainers as rewards in merge to earn are related to actual ownership of the project and its future earnings.

But anyone could open an issue, and then the maintainer can add a tag to it depending on the reward it thinks it could be worth.

At the end though it's important to note that the contributor opening the PR has the final word on the amount being requested for the work done.

Looks cool!

Bug report: clicking "See owners" or either of the products on Slice Gensis NFT result in an error page for me: "Application error: a client-side exception has occurred (see the browser console for more information)."

Thanks for reporting! Unfortunately can't reproduce on my end so additional details would be welcome (is there any log in the browser console?). Will figure it out anyway!

The problem is that this ceases to be open source. As soon as money is involved, it becomes a company. And the people involved with said company will develop a financial interest in what does/doesn’t get merged. The result of that will be a "source available" project.

You can govern a FOSS project however you want, reject all contributions if you want, the only factor that matters is the license. It doesn't stop being FOSS.

OSS people tend to think that a specific license is a technicality only needed because it is legally difficult to put things into the "public domain," and that OSS is actually something that has to do with the "spirits" and "souls" of pieces of software, their developers, and their users. The "spirit" of OSS is violated by anything that doesn't seem "fair."

Free Software people think that Free Software is a set of software licenses designed to support certain social outcomes (i.e. they think realistically.)

This statement does not mesh with companies that release open source software with paid employees working on the core roadmap but contributors getting rewarded for significant contributions (and those can be small or huge) as well, nor with foundation-backed open source projects that pay people to work on those projects even if the direction of those projects are fully community-governed.

"Being a company" and "releasing open source" are not mutually exclusive, you're just paying people for spending their time working on your project. You don't pay the reviewers, you pay the contributors, if their contribution was worth it. And they will know whether that will be the case before they even start any work because that's what issues and discussions are for. If you want to do something, and the project owners go "that's not a thing we need", you know that up front.

Projects can get income or donations and still be open source, what matters is the license. While allowing contributors to be rewarded for their work generally creates healthy incentives.

Handling rewards in public discussions on Github naturally prevent bad behaviours from maintainers (ie making bad-faith choices as to what does or doesn't get merged) as they would lose reputation with their contributors and community.

There are many companies that write FOSS software and make money doing it.

Reply on news.ycombinator.com