by lorey on 12/3/24, 10:45 PM with 84 comments
by kibwen on 12/7/24, 4:21 PM
While I applaud the OP for the initiative, if this ever takes off it will cause people to exploit the system in the following ways:
1. Hammer the package registries with fake downloads, which will increase the financial burden on the registries both in terms of increased resource usage and in employing countermeasures to stop bad actors.
2. People spamming the repositories of popular packages with PRs that just so happen to add a dependency on their own personal package, so that they can pick up transitive downloads. This increases the burden on package authors who will need to spend time rejecting all of these.
So this approach carries the risk of possibly making things even worse for OSS maintainers.
If a metric can be gamed, and there is a financial incentive to game it, it will be gamed. I coin this the "this is why we can't have nice things" law.
by kvinogradov on 12/7/24, 10:03 PM
It was a simple MVP for personal OSS donations, and I have many considerations on how to evolve it and especially to prevent it from becoming a victim of Goodhart's Law at scale. Some of them:
1) Value and Risk scores shall include more metrics: dependencies, known funding, time since the last dev activity, active contributors, etc. A wider set of connected but relatively independent metrics is harder to fake. Also, it will help to exclude edge cases — for instance, I auto-donated to Pydantic (it's a great OSS), but such support is unlikely needed as they have raised $12.5M Series A from Sequoia this year.
2) Algorithmic does not mean automatic. While I see a strict, measurable, and ideally fully transparent methodology crucial for donating, it does not mean that all inputs shall be automatically generated. For instance, in the stock ETF world, one can generally rely on such metrics as "annual financials" for trading because they are annually audited (although it does not prevent fraud in 100% of cases). In the OSS world, data from trusted ecosystem actors can also be part of the equation.
3) Many guardrails are possible: limited budget per project, manual checks of top repos with the most anomalous changes in metrics. Also, if we target the sustainable maintenance of OSS the world relies on (I do!), then new projects (1-2 years) will unlikely get high scores - that adds another protection layer.
Given the interest in this topic, I am going to continue developing this algorithm further and expand it to other ecosystems (e.g. JS/TS and Rust). Your feedback here is very valuable to me, and those who would like to help make the algo better or donate through it are invited to the newly created gist:
https://gist.github.com/vinogradovkonst/27921217d25390f1bf5e...
by leoc on 12/7/24, 3:09 PM
by Wilduck on 12/7/24, 2:32 PM
1. Publishing the exact formula for funding is great for transparency, but then leads to an incentive to game the system to capture funding. Doing things like breaking your project up into many small packages, or reducing the number of maintainers are not good for the ecosystem but may lead to more funding. Also, there starts to be an incentive to juice download numbers.
2. In general, rewarding "risk" with additional funding seems like it creates an adverse incentive. This seems like a really tricky problem, because lack of funding is a major source of risk. It seems like there could be a pendulum effect here if you're not careful. Is there a way to structure the funding so it encourages long term "de-risking"?
by NelsonMinar on 12/8/24, 12:47 AM
Reddit did something similar last year in their IPO. I'd love to read an article on how people benefitted from it.
by mrtksn on 12/7/24, 4:02 PM
Distribution can favor projects that need funding to be sustained. Maybe you are using niche library than only 20 other people are using it but you are getting great value out of it, then maybe it can be reasonable to be billed $100(or not a strict sum but high coefficient to make your donation go mostly to this particular library).
by teddyh on 12/7/24, 3:48 PM
I suspect that a better measurement might be based on what software people actually have installed, perhaps using the Debian Popcon data.
by iandanforth on 12/7/24, 2:51 PM
by bajabaq on 12/7/24, 2:35 PM
Two requests: 1) could you easily add the projects to the CSV file (maybe one column left of the user: "projectA;projectB;...") 2) could you share the code (understanding that it's rough and lots of hand-curation)
I've long given to EFF, FSF, and other projects sporadically, but this method seems excellent and expandable and customizable, maybe something like: 1) identify the packages on your machine (or used by your team) 2) score them 3 donate based on score
by tlocke on 12/7/24, 2:46 PM
There's also the approach to funding that looks at things from another angle, and says we should have a basic income, or negative income tax, for everyone.
by lorenzleutgeb on 12/7/24, 4:14 PM
Flattr is no more. But I could see that work out for open source projects: Allocate a fixed monetary amount per unit of time you want to donate. Record "intent to donate" during that period. This could be done via a browser extension or a CLI. At the end of one period, distribute.
by lorey on 12/3/24, 10:49 PM
by gauss233 on 12/7/24, 11:33 PM
by jvanderbot on 12/7/24, 5:32 PM
Undisclosed use would be a bad idea - your package could be receiving free funding!
by bradley13 on 12/7/24, 3:04 PM
tl;dr: well intentioned, but it isn't gonna work.
by LtWorf on 12/8/24, 7:49 AM
I was claiming that there are important incentives to play this sort of games.
Seems OP proved me right!
by mrbluecoat on 12/7/24, 2:10 PM
by Wilsoniumite on 12/7/24, 4:10 PM
by kinderjaje on 12/8/24, 1:43 AM
*Gpt message:*
This comic humorously highlights a critical issue in the tech world: the dependency of massive modern digital infrastructure on small, often overlooked, and underfunded components maintained by individual contributors. The large stack in the illustration represents the complex and sprawling "modern digital infrastructure," while the tiny piece at the bottom, maintained by a "random person in Nebraska," symbolizes open-source software or obscure tools that are crucial for the functioning of this entire system.
The key message is that large systems often rely on foundational work done by unsung heroes who may not receive the recognition, support, or resources they deserve, despite the critical nature of their contributions. This comic resonates particularly with the tech community, where dependencies on small open-source projects are common.
by theendisney on 12/7/24, 10:58 PM
by igor47 on 12/7/24, 4:47 PM
by xk3 on 12/8/24, 6:31 PM
Interesting project
by kinderjaje on 12/8/24, 1:47 AM
by yu3zhou4 on 12/7/24, 9:08 PM
by joshdavham on 12/7/24, 4:21 PM
by paxys on 12/7/24, 3:20 PM
Regardless, donating something is always better than donating nothing, so kudos.
by hartator on 12/7/24, 9:11 PM
Yeah, doing open source is very unthankful even outside of that money consideration. I have a 5k+ star GitHub project for like 9 years, 200-300 bug requests via GitHub/personal email, and maybe I got maybe 1 genuine thanks email without a request.
by IAmLiterallyAB on 12/7/24, 3:34 PM
by jillyboel on 12/7/24, 7:45 PM
by 38 on 12/7/24, 2:27 PM