This, but for an escrow so people can show their actual interest in GitHub Issues, instead of just demanding new features or fixes. So if it gets implemented, the devs get the bounty, if not then they're refunded. I sometimes think about how this could help fund open source at least a little bit.
No comment on making PRs paid, not everyone would react well to that, and some people might be in countries and circumstances where any amount would be problematic.
https://news.ycombinator.com/item?id=46938811
escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.
let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.
escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.
there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free
ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.
Crypto has a perfect way to burn money, just send it to a nonexistent address from where it can never be recovered. I guess the trad fi equivalent are charitable donations.
The real problem here is the amount of work necessary to make this viable. I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals, not to mention all the potential contributors that have no access to Visa/MC (we do want to encourage the youth to become involved with Open Source). This basically means crypto, and crypto has its own set of problems, particularly around all the annoying KYC/AML that a normie has to get through to use it.
That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:
https://news.ycombinator.com/item?id=46943416
A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.
> The real problem here is the amount of work necessary to make this viable.
Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:
https://news.ycombinator.com/item?id=46938811
> all the annoying KYC/AML that a normie has to get through to use it.
There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.
You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.
For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.
That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.