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.
It's true that the metrics used in this story could lead to being exploited. But the value of the initiative is not in the specific method used to donate, but in the idea of finding worthy yet non-obvious projects to donate and in leading by example.
If the initiative catches on, the community can find better, harder-to-exploit methods to find deserving targets, as for example it has happend with NGOs. This idea could create a healthy ecosystem that supports FLOSS software, just like the idea of a stock exchange supported the emergence of public traded corporations in the XVIII and XIX centuries.
The current algorithm is far from being perfect (it's an MVP) and will never be, but with more measurable inputs and after multiple iterations with the help of the community, it can lead to an analogue of "S&P500" for OSS, that's worth using for donating to reduce the risk of the global OSS supply chain we all rely on.
As with publicly traded companies, having a decentralized set of private donors with skin in the game helps a lot to efficiently evolve the approach and make it harder to exploit in the future. And on the contrary, I would not trust an algorithm created and maintained by some state-owned or simply very large institution.
In the same way, there was a fixed pot of money available split up by popularity, so making thousands of songs and streaming them as much as possible with bot accounts is profitable, even though each bot account cost a few dollars per month.
Here, the bots you use to juice your numbers don’t even need a subscription fee!
That would eliminate direct financial payment from botting. But botting could still affect trending or “related” recommendations for indirect financial boost.
Also, since they didn't change the economics, they have done nothing to prevent this from happening again. Any economist that sees that he can earn $12 from a $11 payment would keep doing this until the risk adjusted return is equal to the interest rate. Ironically this will remain profitable until the cross subsidy is gone. I.e. there is an incentive to use the bots to boost real musicians who lose out from not being the recipient of the cross subsidy.
Set arbitrary metrics like download count -> bad actors make bots to download their package -> they profit while the registry suffers from very heavy load.
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...
It's funny that the experiment uncovered exactly such a case: a person from Nebraska got my donation as the first income from his open source contributions over the last 18 years and shared this on Linkedin:
https://www.linkedin.com/feed/update/urn:li:activity:7269812...
And when that happens, you'll quickly start to see professional schemers and hustlers coming in to buy them, the most aggressive of whom will start surreptitiously converting some of those projects into things like data siphons or bot shells, may relicense and restructure them for further monetization or to set up targeted lawsuits, etc
It creates a whole new and dangerous incentive scheme, not unlike the one that's already corrupted the browser extension ecosystem.
To avoid that from happening, people need to be actually paying attention to what they're paying for, when they're paying for it, so that they can make sure they're still getting what they expect. Automated/algorithmic schemes like this specifically avoid that.
They're a great idea in theory, meant to address a real issue in what reward open source developers might see from popular work, but as you suggest, it opens a very wide and inviting door for trouble at scale.
A related project I recently found out about is https://www.drips.network/ The more I think about it, the more I like it.
In fact, TFA says
> But how should one decide which users to sponsor and how much to donate to each one? It requires data on their importance, and I used PyPI to roughly estimate it for Python packages.
It's better to have one of the slabs in the XKCD comic fund the ones immediately below it than to have users look at the whole thing from the outside and try to arbitrarily allocate importance via some metric like PyPI downloads, GitHub stars and whatnot
But as I said elsewhere, I'm not using this to dismiss the idea or assert that it can't improve things overall. The status quo seems to be pretty bad, so an alternative certainly doesn't have to be flawless to be better overall.
Goodhart's law is an adage often stated as, "When a measure becomes a target, it ceases to be a good measure"
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"?
It's a bit like the SEO dance. Publishing the exact formula makes it much easier to game SEO, so instead search engines say stuff like "we're trying to gauge the overall quality of the site, we use metrics like [...] but not exclusively, focus on making good, responsive, accessible content above all else". Obviously it doesn't work perfectly and the more money there is, the more incentive to game the system, but it seems better than the alternative of publishing the exact ranking algorithm.
I say think of it as an authorization protocol, and watch how people break it in order to figure out how to fix it.
This is an approach I'm actively working on, although I haven't actively donated anywhere yet.
Reddit did something similar last year in their IPO. I'd love to read an article on how people benefitted from it.
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).
A lot of people will vote for the obvious ones, a few people will vote for the underdogs and it'll come out in the wash.
That also fights the common complaint here of people gaming the system by splitting up their libraries too much. Sindre, for instance, would get some money for p-limit, p-retry, and maybe p-queue, but not much else for his astounding menagerie of micro-libraries.
However, the issue is that most organizations relying on OSS are not tech companies. They mainly have no clue about OSS sustainability (e.g., airports and hospitals) and are unlikely to ever fund their own software supply chains, unfortunately. That's why there should be a data-driven index to address the global OSS supply chain, not only any particular ones.
I suspect that a better measurement might be based on what software people actually have installed, perhaps using the Debian Popcon data.
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
1) Yes. My plan is to continue iterating on this approach and publish more data later, including projects and some other inputs (PyPI, etc.)
2) Maybe. I prefer the full transparency and have planned to publish the code too, but some comments suggest that it might not be ideal. Need to think more about this.
Make it a local or company-wide identification of FOSS packages, and a way for those individuals, teams, and businesses to score them by importance or criticality (or needs of the FOSS project if they are aware).
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.
Lots of “sufficients” in there, of course.
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.
Undisclosed use would be a bad idea - your package could be receiving free funding!
tl;dr: well intentioned, but it isn't gonna work.
I was claiming that there are important incentives to play this sort of games.
Seems OP proved me right!
Also if you have a local cache and just check the version, that won't count.
For instance, given that my algo-donating aims to support the global OSS supply chain (not to distribute any crypto tokens like Tea did), it could potentially even focus only only "old" repos. They carry higher maintenance-related risks, but it will take years to distort such target area for donations.
*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.
You definitely can use such a license for your project. That's trivial to do.
However, of course, that would not be an OSS compatible license.
I'm as big a fan of OSS as the next guy. I'm also a fan of eating. I sell my work (as source code) with a proprietary license. That's how I "solved" the problem, at least for me.
Ideologically I'd love for it to be open source. But there's no sustainable way of capturing that value. So rather than not-do-it I chose to charge for it instead. (Shrug).
Regardless, donating something is always better than donating nothing, so kudos.
Regarding is-odd, it would unlikely receive a high score even with the current primitive version of my algorithm, as it already includes the package size among the "risk" set.
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.
While any particular donation I made to OSS maintainers is small, it seems important that the recipients get more attention and maybe will be less likely to burn out in the future. For instance, some of them (btw, from Nebraska!) did not receive anything for 18 years of contributing to OSS before last week: https://www.linkedin.com/feed/update/urn:li:activity:7269812...?
