Comment by andai
19 days ago
It should just be $1 to submit PR.
If PR is good, maintainer refunds you ;)
I noticed the same thing in communication. Communication is now so frictionless, that almost all the communication I receive is low quality. If it cost more to communicate, the quality would increase.
But the value of low quality communication is not zero: it is actively harmful, because it eats your time.
This thought pattern leads to crypto.
In that world there's a process called "staking" where you lock some tokens with a default lock expiry action and a method to unlock based on the signature from both participants.
It would work like this: Repo has a public key. Submitted uses a smart contract to sign the commit with along with the submission of a crypto. If the repo merges it then the smart contract returns the token to the submitter. Otherwise it goes to the repo.
It's technically quite elegant, and the infrastructure is all there (with some UX issues).
But don't do this!!!!
I did some work in crypto. It's made me realize that the love of money corrupts, and because crypto brings money so close to engineering it corrupts good product design.
The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
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.
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
Plenty of businesses do the “your credit card will be charged $1 and then reversed” as a verification method that I don’t think it would be a major issue. I do wonder how much those companies are paying for that, though… I am guessing they lose some of that $1.
You can reduce the transactions with payment providers. Instead of money exchanging from contributor to maintainer, have a token exchange. Contributors fund tokens with real money, and pull requests cost and refund tokens. Like an escrow account. But the money never goes to the target system. There are no perverse incentives to steal tokens. If you get a reputation of not refunding tokens (which have no value to a maintainer), then contributors will dry up.
"TrustTokens" or "EscrowTokens"
1 reply →
> I bet Visa and Mastercard would look at you funny if your business had such a high rate of voluntary transaction reversals
…you might be right, but I do wonder if the situation would be different if “your business” was “Microsoft”. Obviously they would discuss this plan ahead of time.
> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.
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=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.
right, the ethereum gets spent whether the transaction is cancelled or not. and that's an issue
> because crypto brings money so close to engineering it corrupts good product design.
Amen.
It feels like the problem here comes from the reluctance to utilize a negative sum outcome for rejection. Instead of introducing accidental perverse incentives, if rejected your stake shouldn't go to the repo, 50% could be returned, and 50% deleted. If it times out or gets approved you get 100% back. If a repo rejects too often or is seen doing so unfairly reputation would balance participation.
No, the perverse incentive is that there will be RepoCoin, and the people involved will be incentivized to make the price of that as high as possible.
13 replies →
"It's made me realize that the love of money corrupts".
Yep. How about $1 per PR. The submitter gets to choose from a list of charities. No refund if the PR is accepted.
The goal is to get rid of junk PR's. This would work. There could be a central payment system, which any open source project can integrate with. It could accept payment in say India, of the Indian PPP of $1, so you aren't shutting out poorer developers.
I would not pay any amount of money, even a trivial one, for the privilege of being able to do free work for a project - and I don't think I'm an outlier here.
7 replies →
I think the core insight here is about incentives and friction, not crypto specifically.
I’m working on an open source CLI that experiments with this at a local, off-chain level. It lets maintainers introduce cost, review pressure, or reputation at submission time without tying anything to money or blockchains. The goal is to reduce low-quality contributions without financializing the workflow or creating new attack surfaces.
I see no advantage with this over real money transfers. At all. Just use some kind of escrow.
You don’t need a third party, or anybodies permission, nobody can censor you or block your transactions, you don’t need a bank account with everything that entails. The barrier of entry is the same as creating an SSH keypair. It works globally, fast, cheap. You do not need to trust anybody, all the code is open and the ledger is cryptographically verifiable by anyone. There are lots of advantages.
1 reply →
No. Just because you can use crypto for something doesn’t mean you should. In fact you almost never should.
If you want me to read your comment, please pay me $1 first... if I find your comment interesting I might refund.
I had this idea / pet project once where I did exactly this for email. Emails would immediately bounce with payment link and explanation. If you paid you get credit on a ledger per email address. Only then the mail goes through.
You can also integrate it in clients by adding payment/reward claim headers.
Bill Gates already had this idea. All efforts to change email were already documented 25 years ago. The biggest changes are it is more centralized these days, SPF/DKIM/DMARC, JMAP innovation, oh... and one more thing! It is HUGE!! HTML email is the default...
1 reply →
Scammers (and spammers) always got $1! That's why there's a lot of the scam ads on google, fb, apple.
So the paywall email firewall will not work as desired.
13 replies →
The market currently values your reading of HN comments at $0.
I'm sure astroturfers value it more highly than that.
2 replies →
Who's hit with the transaction fees though?
I built a side project to solve this for myself that’s basically an inbox toll system. It funnels emails from unknown senders into a hidden mailbox and auto replies to the sender with a payment link. After the sender pays, the email gets released to recipient’s main inbox. Recipient can set custom toll amounts, whitelist, etc.
Would be happy to share the code, just lmk!
Has anyone ever paid you?
The technical side of this seems easy enough. The human side, that seems more complicated.
Like, if I were your doctor or contractor or kid's schoolteacher or whoever you hadn't happened to already whitelist, and had sent you something important for you, and got that back as a response... I'm sure as heck not paying when I'm trying to send you something for your benefit.
no one paid me but didnt really have this running for very long on my inbox. was really just a poc. and you're right - the human side is weird. surprisingly hard to solve the "real human, not spam, that's also an email address you see for the first time" scenarios, which there are many of - even with LLMs
Yeah, meanwhile a scammer will actually pay to have a seal of approval.
It's a great way to stop receiving anything that benefits yourself and only start receiving mail which could make the sender way more than $1
1 reply →
I’m interested in seeing this too. Heh an agent will gladly pay a dollar of their human’s money if they can declare success.
https://github.com/JoeBerg8/tollbooth
this was part of a little saas tool i was building (since retired it) so spent some time today having an LLM help me pull it into a headless service. far from perfect but sharing anyway. details in readme!
Please do share!
https://github.com/JoeBerg8/tollbooth
this was part of a little saas tool i was building (since retired it) so spent some time today having an LLM help me pull it into a headless service. far from perfect but sharing anyway. details in readme!
Yes please!
https://github.com/JoeBerg8/tollbooth
this was part of a little saas tool i was building (since retired it) so spent some time today having an LLM help me pull it into a headless service. far from perfect but sharing anyway. details in readme!
People with very little to no skill in software development are spending hundreds of dollars on tokens to fix things for clout, will an extra dollar barrier really slow things down noticeably?
There are a lot of _free_ models on opencode.
> But the value of low quality communication is not zero: it is actively harmful, because it eats your time.
But a non-zero cost of communication can obviously also have negative effects. It's interesting to think about where the sweet spot would be. But it's probably very context specific. I'm okay with close people engaging in "low quality" communication with me. I'd love, on the other hand, if politicians would stop communicating via Twitter.
The idea is that sustained and recurring communication would have a cost that quickly drops to zero. But establishing a new line of communication would have a slight cost, but which would quickly drop to zero.
A poorly thought out hypothetical, just to illustrate: Make a connection at a dinner party? Sure, technically it costs 10¢ make that initial text message/phone call, then the next 5 messages are 1¢ each, but thereafter all the messages are free. Existing relationships: free. New relationships, extremely cheap. Spamming at scale: more expensive.
I have no idea if that's a good idea or not, but I think that's an ok representation of the idea.
Haha yea, I almost didn't post my comment since the original submission is about contributors where a one time "introduction fee" would solve these problems.
I was specifically thinking about general communication. Comparing the quality of communication in physical letters (from a time when that was the only affordable way to communicate) to messages we send each other nowadays.
This means someone with tons of money can spam anyone repo, while the lower income people cannot raise as many PR or speak as much as the filthy rich.
The incentives are way off too. Now you have a financial incentive as a maintainter to throw out normally well meaning PR's as "bad".
...which is balanced out by all the other incentives that have the maintainer currently contributing unpaid time & effort.
1 reply →
Which is true now as well, but at least the cost is more than zero
I'll simply never file PRs, then. I'd say 4 out of every 5 PRs I file never get a response. Some on very large projects, and I like to think my PRs are more useful than docs fixes or pointless refactors. I'm simply not going to spend money to have to float around in the void endlessly because a maintainer lost interest in the project and won't ever look at my PR, I'll simply keep my changes on a downstream fork.
Moreover, I'm not interested in having my money get handed over to folks who aren't incentivized to refund my money. In fact, they're paying processing costs on the charge, so they are disincentivized to refund me! There could be an escrow service that handles this, but now there's another party involved: I just want to fix a damn bug, not deal with this shit.
The system could be set up to automatically refund, if your PR wasn't checked for over $AVERAGE_TIME_TO_FIRST_REVIEW$ days. The variable is specific to the project, and even can be recalculated regularly and be parameterized with PR size.
I don't think you heard what I said: I don't want to pay money to contribute to someone else's project. If I fixed your bug, I'm not paying you money for you to ignore my PR for _any_ amount of time, I'm simply not going to contribute back.
> It should just be $1 to submit PR.
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.
pay-to-commit has been discussed in the article linked here
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.
there are many many examples where paying a nominal fee seems like it would get rid of the clowns. and it would. almost any place where the public can "post". but the challenge is to not inadvertently throw out the good ones.
once notable policy SQL Server enterprise support used to have was you must be available 24/7 if you submit a critical issue. Microsoft was demanding as much of their time as our time.
not sure how that could be rolled out to repos but it worked
Or just don't refund it. Most people want to make contributions to open source, and everyone can afford $1. Exceptions can be made for very active contributors.
In fact, we can use an automated schedule: first PR - if rejected, 5€ are drawn from the contributor’s account, then 4€, 3€, etc (plug in your favourite decreasing function, round to 0€ when sufficiently close).
But, crucially, if accepted, the contributor gets to draw 5€ from the repository’s fund of failed PRs (if it is there), so that first bona fide contributors are incentiviced to contribute. Nobody gets to profit from failed PRs except successful new contributors. Virtuous cycle, does not appeal to the individual self-interest of repo maintainers.
One thing I am unsure of is whether fly-by AI contributions are typically made with for-free AI or there's already a hidden cost to them. This expected cost of machine-driven contribution is a factor to take into account when coming up with the upside/downside of first PR.
PS. this is a Gedankenexperiment, I am not sure what introducing monetary rewards / penalties would do to the social dynamics, but trying with small amounts may teach us something.
>everyone can afford $1
Well that's awfully assumptuous. So now a young college kid needs to spend time and money to be able to help out a project? I also don't like that this model inentivizes a few big PR's over small, lean, readable ones.
We're completely mixing up the incentives here anyway. We need better moderation and a cost to the account, not to each ccontribution. SomethingAwful had a great system for this 20 years ago; make it cost $10-30 to be an external contributor and report people who make slop/consistently bad PR's. They get reviewed and lose their contributor status, or even their entire account.
Sure, you can whip up another account, but you can't whip the reputation back up. That's how you make sure seasoned accounts are trustworthy and keep accounts honest.
But one way to get better at communication is try and error. This solution makes trying much harder, and eventually leads less good communicators.
in the 90s, before bayesian spam filtering, Microsoft proposed a proof of work for email along these lines. it would cost the server a few cents per message to sign and send emails, so spammers would not be able to afford spam, but regular senders could handle a small fee per day.
$1 might not be a lot to you, but in some countries that's the daily wage. Even in rich countries one dollar for some might be the difference between eating or not eating that day.
Paywalling without any regional pricing consideration it's just going to incentivize people from poor countries to not participate in your project. Maybe that's okay for you but it's something to consider.
I don't like this idea but the people unable to afford $1 don't have time to propose PR
That’s not true—it depends entirely on the country..
I'm glad that you are lucky enough to never have had to choose between filling your gas tank or eating. It's sadly the state many people live in.
1 reply →
Plenty of teens in poorer countries actively devoting a lot of time to practicing programming. $1 is a lot for a PR.
It's externalisation of cost.
We've seen it everywhere, in communication, in globalised manufacturing, now in code generation.
It takes nothing to throw something out there now; we're at a scale that there's no longer even a cost to personal reputation - everyone does it.
Sorry, but this seems like a privileged solution.
Let's say you're a one-of-a-kind kid that already is making useful contributions, but $1 is a lot of money for you, then suddenly your work becomes useless?
It feels weird to pay for providing work anyway. Even if its LLM gunk, you're paying to work (let alone pay for your LLM).
It is a privileged solution. And a stupid one, too. Because $1 is worth a lot more for someone in India, than someone in USA. If you want to implement this more fairly, you'd be looking at something like GDP or BBP plus geolock. Streaming services perfected this mechanism already.
This might be by design. Almost anyone writing software professionally at a level beyond junior is getting paid enough that $1 isn't a significant expense, whether in India or elsewhere. Some projects will be willing to throw collaboration and inclusivity out the window if it means cutting their PR spam by 90% and only reducing their pool of available professional contributors by 5%.
13 replies →
[dead]
Not that word, in the context of contributing to an open source project that you're likely already benefiting from.
ie, if you want to contribute code, you must also contribute financially.
>contributing to an open source project that you're likely already benefiting from.
Yes, but many people benefit for free. You see the backwards incentives of making the most interested (i.e. the ones who may provide the most work to your project) pay?
And none of that even guarantee support. Meanwhile you donate more and you get to tell people what the build. It's all out of what.
You get it refunded
The default could should be to refund.
That would make not-refunding culturally crass unless it was warranted.
With manual options for:
0. (Default, refund)
1. (Default refund) + Auto-send discouragement response. (But allow it.)
2. (Default refund) + Block.
3. Do not refund
4. Do not refund + Auto-send discouragement response.
5. Do not refund + Block.
6. Do not refund + Block + Report SPAM (Boom!)
And typically use $1 fee, to discourage spam.
And $10 fee, for important, open, but high frequency addresses, as that covers the cost of reviewing high throughput email, so useful email did get identified and reviewed. (With the low quality communication subsidizing the high quality communication.)
The latter would be very useful in enabling in-demand contact doors to remain completely open, without being overwhelmed. Think of a CEO or other well known person, who does want an open channel of feedback from anyone, ideally, but is going to have to have someone vet feedback for the most impactful comments, and summarize any important trend in the rest. $10 strongly disincentives low quality communication, and covers the cost of getting value out of communication (for everyone).
2 replies →
It is simple: we simply add a whitelist for the child prodigies.
[dead]