Seriously, chill, then think about how you'd implement it. Then think how it'd go wrong. Then think about how to fix those problems. Repeat until you realize there's a better solution or until you solve the problem without making it overly convoluted. More often than not the former is the better option. More often the latter is just a variant of the sunk cost fallacy and your ego. Reality is (un)surprisingly complex and solutions aren't usually trivial
More than likely GitHub would have to maintain their own internal wallet solution for this, which is a big engineering lift. But we're all just having a discussion.
> to a genuine solution
> More than likely GitHub would have to maintain their own internal wallet solution
> This is an overly negative response
There's two types of lazy, and this is the kind that creates more work, not less
Mind you: that's on one of the most convulated ways there is to get involved, because it involves a bunch of smart contract operations and on-chain voting. If we are talking about crypto only as a payment network, things are even simpler.
A generic python library used by generic people who have no interest in this field is something else.
Also, we are talking about people who are tech-savvy enough to be interested in participating in a FOSS project. Opening an account at an exchange is not rocket science.
And those who are living in countries the USA doesn't like will probably have no issue to learn how to work with crypto. Of all the complex things they need to do to work around the restrictions, setting up a wallet barely registers.
No one, meat or chip, would just set aside $10 "for the opportunity to contribute"
This is "let them eat cake" level of out of touchness.
If I was told that I could make a deposit of $10 to get less stressed maintainers and a faster PR review cycle, I wouldn't even blink. I wouldn't even ask for the money back.
---
I know it's against convention to comment on downvotes, but really? Really? This is controversial? The OP came up with an elegant solution that cleanly solved their problem without subjecting contributors to anything more than a captcha. Then somebody comes along and says "oh, it's so easy, just charge $10". You're going to set up payment infrastructure, incur administrative overhead with human support managing refunds, and deter 99% of actual humans from contributing, and then call that the easy solution that OP is so stupid for not thinking of first? Give me a fucking break. This site really is just Reddit-lite, anyone who thinks about engineering problems seriously would realise this does not stand up as anything beyond a pithy internet solution with three seconds of thought into what actually implementing it would entail.
Polar.sh is already doing things that are a lot more complex in this space.
If you are in a civilized country which allow direct payments (i.e, anything but North American nowadays) and you don't want to deal with Github or any external system, there is always good old "make a M-PESA/SEPA/Pix/UPI transfer to account XYZ")
> the thought put into it as the actual solution by people with a stake in actually solving the problem
Let me flip your argument: think of how much time and thought is poured into problems like this one by people who don't even try to implement a Pfand system beforehand.
...which is not available to maintainers to use in this way.
> there is always good old "make a M-PESA/SEPA/Pix/UPI transfer to account XYZ"
And then lock out anyone who is not from the same country as the maintainer, on a platform that is known for its global reach.
Moreover, you're introducing significant anti-human friction. For privacy-conscious people, it's a complete non-starter; I'm not giving my payment information, not for a $1 transaction, and compromising my anonymity just to make a PR for the benefit of other people. That's a small subset. Then, you have the lazy people. The majority of the population will simply not bother with something if it has friction. Getting out their credit card is one of those things, and it's why products/services that offer free trials or a free tier tend to be overwhelmingly more successful -- people want to see a tangible benefit to themselves before they engage in high-friction processes (where "high-friction" is as little friction as requiring a payment, yes). "Free to play" video games with microtransactions engineer first-time purchases to be cheap ($1 or $5) and have 5x or 10x the value of the normal microtransactions, because that first hurdle of getting somebody to hand over their payment information is by far the biggest.
I'll take the captcha, thanks. And maintainers will too, because they'd rather have the solution that filters bots and keeps humans contributing rather than the one that filters out both humans and bots.
Yes, that friction is intentional. The lazy people don't want to do it? Great, there is very little chance their contributions are worthwhile. The privacy conscious people won't do it? Then let them work on their own repositories and complain loudly about the idiot maintainer who puts these insane barriers. Then the maintainer can go take a look at that forks done by the loud complainers and see if it is worth to whitelist them.
> it's why products/services that offer free trials or a free tier tend to be overwhelmingly more successful
Drug dealers also offer the first hit for free, why don't you use that as an example as well? ;)
To answer this properly in case the quip was too vague: there is no reason for "number of PRs opened by new contributors" to be a viable/interesting KPI for any FOSS project.
> I'll take the captcha, thanks.
First you need to show me all your cool FOSS projects.
2) You are not "paying" $10. The money would be returned to you. In case you haven't heard of Pfand systems: https://en.wikipedia.org/wiki/Container-deposit_legislation
Or teenagers without full access to online banking.
Or the unemployed.
And a registration system that amounts to a more complicated captcha doesn't? How long until someone starts farming accounts and run bots that jump through these hoops as well?
> wonder if the idea is fundamentally broken.
It's only "fundamentally broken" if you need to build a perfect system that needs to accept 100% of legit PRs without raising any level of friction.
But we don't need that. Pfand systems are not meant to be perfect, and they are not meant to the single solution to any problem involving the commons. They will not get rid of all bad behavior, but they will certainly bring it a global-scale problem down to levels that can be then managed by other smaller, context-aware systems.
Unless I knew the maintainers personally, this would prevent most of my contributions, which are most often accepted. Maybe it's worth losing out on my small contributions to avoid slop. But things would absolutely be lost this way.
If you don't trust the maintainer, you can always fork a repo and let them merge on their own.
Let's say I'm a maintainer of an open source project on Github/Gitlab. How would you actually implement this deposit-refund loop in practice?
``` # FIrst-time contributors
Due to the increased number of AI bots and low-effort contributions, we are being forced to add some friction for first-time contributors. PRs are closed for anyone not explicitly added to our list of authorized users.
To be accepted in the list, you must do one of the following:
- Show a history of meaningful contributions in projects from related technologies done before Jan 1st, 2023.
- Be vouched by one of the existing contributors in the core team
- (If you have github sponsors/polar/patreon) Be a sponsor for the project for the last 3 months)
- Submit a small payment, which will be held in escrow until your PR is accepted. The following methods are accepted (choose all that apply: paypal, SEPA, Crypto, Venmo, Pix, UPI, M-Pesa, etc) ```
I was also wondering how automated or manual you would envision the review process. I'm guessing your hope would be that the small deposit would stem the flow of submissions enough to make it all possible to review manually again, and you would also manually return all the payments sent to escrow?
Paypal/SEPA transfers are free in Europe. And even if I lived in the US and had to pay a small processor fee, I'd be more than willing to cover the $0.50 in fees if that meant I was receiving contributions from people who went through all the trouble.
Wonder if a dollar would work for now until more people give bots credit cards.
Location of the envelope with the money: the same police station where I'd reported the death threats.
The bigger issue being, raising the bar to students who may have otherwise had productive careers (but education is a general issue, where the students don't even yet recognize they are being scammed).
Unless the contributors don't care about the repos they contribute to, this is not a likely scenario. AI doesn't care. We do.
You keep describing this as not a likely or realistic scenario. But why is the likelihood even of relevance here? The way to avoid the worst case i.e scammed of your money, is to not even put it on the table in the first place.
Ill thought out logic like your own. I think you are likely a bot at this point.
It's not likely, because that's not something that people are likely to do. Only a bot like yourself with a poor model of the world will do this type of thing. It will be amusing to see the AI bots trying to run the scam you are describing and then nobody will contribute to the fake projects... except other fake AI contributors.
I think that OP is trying to say is that there is very little reason for a human to go through the trouble of contributing to a "plausible looking fake repo".
To get to the point that a repo starts to attract interest from other contributors, that project needs to have actual utility.
Who in their right mind would jump into opening a PR from projects they never used? And if the project does get used to the point that it attracts people interested in contribute to improve it, wouldn't it mean that we've achieved https://xkcd.com/810 ?
That's called theft. And for what, one banana?
Let's also be realistic, everything that can be automated will. Even if that thing is worse off for it. There's a clear historic pattern of this. Companies and people love to be penny wise and pound foolish.
Of course not, because the number of low-quality PRs with $10 attached to it will be lower than whatever number of PRs are being created now.
I am more concerned about the sustainability of the projects as a whole than trying to optimize the number of potential random PRs.
> you're welcome to give it a try on your projects.
It's not exactly the same, but in a way I'm already doing that with Communick. I'm running one of the few Matrix and Fediverse services where members must pay to have access. Up until last week, I was giving 14 days as a free trial period and no deposit/confirmed subcription required. But now because of AI bots, I dropped it and I am collecting payment info before activating any account.
If I were playing the startup playbook, that would be insane. It's already crazy to try to charge something that people are used to get for free; my conversion rates are already low, requiring credit card info will make them even lower.
In the end of the day, I don't care. At first I was really hoping this would be something profitable, right now I just keep it running because I can. Even with the small number of users Ithe servers get, I get enough to cover the better part of operational costs, I get to sharpen my devops skills and have a test lab to learn what is that people really want (i.e, they are willing to pay to have solved) vs what people claim to be a problem.
All in all, the Communick instances are not going to win any popularity contest, but my servers have been up and running without major issues or drama for more than 6 years, and that's a lot more than I can say for all the other servers that have come and gone because the admins tried to play the numbers game.
> trying to optimize the number of potential random PRs.
You can't just hand wave them away as if this isn't an important factor. If you don't care about them at all I got a much much simpler solution: don't allow issues or PRs. Problem solved! But that's not a real solution either
There are plenty of ways to indicate in the project that the Pfand is meant as one way to filter out bad actors, but it doesn't mean that it should be the only way to accept external contributions. You can find somewhere else on the thread where I listed some alternatives that can be used as well.
> If you don't care about them at all I got a much much simpler solution: don't allow issues or PRs.
Yes, and what is the problem with this solution? That's what many projects are doing and many more will do. They will close access to non-members and only accept someone new when they have some type of social proof. [0] And that is totally fine.
If I have to trust GitHub to give me back my $10, frankly, I have more trust for a random person on the internet at this point.
Also, you glossed over my banana joke, but it did hold meaning[0]
> Yes, and what is the problem with [closing down PRs and Issues] solution?
Unfortunately, the issue is that time is not enough of a filter anymore. The time from machines is basically worthless compared to yours, so you need to give something else, and that something else needs to be something that shows you have actual skin in the game.
Well no, they don't need to. As they said they could just do something else instead of contributing (and I know I would too).
Your proposal would just end up killing those open source projects even more than what you are trying to solve.
Name 3 open source projects that are dependent on a continuous stream of first-time contributors to keep going.