> Value increases with # total downloads and LTM downloads on PyPI.
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.
> 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
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.
Exactly! The idea is to use available data for evaluating the value and risk of OSS and then allocate donations accordingly to the wide algo-based systemic index, not to a narrow set of manually picked projects (usually large or popular ones).
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.
Even an index fund has some human-curated criteria for what to include, though, right? The S&P 500 isn't open to just anyone. So it seems totally legitimate to have it be not completely algorithmic.
If there were an "Open 500" that was trying to be like the open equivalent to the S&P 500, I would happily donate to it. Right now I do GitHub sponsors but it feels kind of random.
You just don't want to include projects like React or TypeScript that are operated by a for-profit company - they don't need our donations. You want it to be, this money is actually going to an organization that will invest it in software quality.
There are probably only so many obvious metrics from which to pick and you wouldn't have to game them all, just pick the easiest ones and keep grinding. Fraudsters are usually motivated and not that dumb.
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!
Which is why spotify should pay a percentage of MY subscription fee to only the artists that I listen to. My money shouldn’t go to Taylor Swift if I don’t listen to Taylor Swift.
That would eliminate direct financial payment from botting. But botting could still affect trending or “related” recommendations for indirect financial boost.
That's not an issue, that's accurately reflecting reality. If I'm paying the same $10/month just to listen to $OBSCURE_ARTIST for 10 plays per month, then each play of that _is_ worth more to Spotify than each play from a 10-year old listening to the same track of $SUPERSTAR one thousand times in a month.
In one case, 10 plays brought in $10 of revenue to Spotify, and those 10 plays should get $PERCENT of that $10.
In the other case, 1000 plays brought in $10 of revenue to Spotify, and those 1000 plays should also get the same $PERCENT of that $10.
A fixed monthly subscription amount with unlimited usage will always carry this deficiency.
A solution that addresses this would be usage-based pricing.
That's not an issue. That's the entire point. You track listens per account and if you're only listening to a single niche musician, all your money (not someone else's) goes to that musician.
The real mystery is why it should work any differently, because the cross subsidy seemingly creates a perverse profit incentive for bots to scalp off some of that cross subsidy. The economics are broken. This is socialism for the rich and popular.
I find that court case very off putting, since it was Spotify that stole the royalties, because the same mechanic applies to simply being popular. When will someone sue Taylor Swift for stealing royalties?
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.
Makes me think of the "cobra effect", like the Great Hanoi Rat Massacre.[1]
Set arbitrary metrics like download count -> bad actors make bots to download their package -> they profit while the registry suffers from very heavy load.
Rather than trying to donate to the most popular packages, people could try to donate to the packages they use, and then their dependencies (it would be nicer, though, if repos had a way for packages to list their dependencies and automatically propagate donations they received down—which would be a usable by the top level packages but, eh, you have to trust people at some point).
Hey HN community, thanks a lot for your great feedback and actionable critique!
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:
Great idea, I also think it'd be interesting to systematically donate to the projects with the lowest bus factor (or as that one XKCD describes it: "the project that a random person in Nebraska has been maintaining since 2005")
Yes, that would be a very useful risk metric! Assuming access only to public APIs (GitHub, package managers, etc.), how would you define the bus factor in terms of data? I am thinking about # unique contributors over the last X years.
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:
It's a great idea; I have some similar thoughts. The looming problem, though, is that Goodheart's Law is likely to strike if this ever gets scaled up significantly.
Worse (and very unfortunately), any kind of unmonitored/low-attention payment scheme that starts funneling meaningful money to countless small libraries turns those libraries into revenue streams whose ownership can be valued and sold.
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.
I generally agree, though some of those specific risks already exist and some (like license changes) are if anything probably less likely if they mean giving up significant donation money.
I think you can solve that by funding the dependencies you rely on and have them fund their dependencies and so on...
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
It's a good start, but it's vulnerable to sticky fingers, patronage relationships and so on if the money becomes serious. For example, what if a project writes internal code instead of having a dependency on someone else's library? Do they get to keep the money which would have gone to an external contributor, creating an incentive to pull everything in-house? Or do they still have to push the same amount of money upstream? That creates the opposite incentive, a bag of free money which can be directed to third-party libraries which purely by coincidence happen to be staffed by members of the downstream project and/or their pals.
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.
In concrete terms, what you would or will see, if enough money starts going down this track, is open-source contributors changing their behaviour as they seek to make projects "donation-optimised" and to maximise their personal share of donations, and likely also "donation-bait" projects which exist simply to game the system. But even though all this could get quite bad, it's still quite likely to be less bad than the status quo. EDIT: If you're thinking of making such a contribution yourself I don't think the downsides should deter you yet, at least unless you're lucky enough to have control of a truly large bag.
On that note, the article states that it donates more to higher risk projects, and risk increases by OpenSSF score. One question I had about the article is does that mean that projects with more security vulns get a higher donation? If so, then that might become a perverse incentive to leave security gaps in your code.
I think this is a really interesting model for providing funding to open source software. There's something about the "Index Fund" approach that is really appealing. I also think it's interesting that the author was both balancing "value" and "risk". I do wonder, if this became a more dominant strategy for providing funding for open source how you would deal with a couple potentially adverse incentives:
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"?
But the issue is, whatever the criterias are, they will become the main kpis opensource projects (at least the not-so-driven ones) will target for growth. Goodhart's law.
I think Goodhart's law only applies if you have fixed, published criteria for funding. That's why I mentioned transparency explicitly. I wonder if you could avoid some of the worst of Goodhart's law by saying something like "the formula changes every year, and we will publish it only after 5 years, but the goal is to reward value provided, and de-risk the ecosystem". The idea being you're explicitly trying to incentivize broadly valuable work rather than specific metrics.
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 think that might be the best strategy: a charity playing Google and being transparent about what money it distributes to whom, but being less transparent about the exact mechanism it uses to calculate the disbursement, or at least being ready to make arbitrary future changes at its discretion to the mechanism to counter gaming (as well as outright zapping clear offenders ad hoc). One nice thing about this strategy is that it could generate a virtuous circle: consolidate together a big enough pot of money from early adopters and you could start getting some good media coverage, which in turn might generate interest and donations from "normie" sources which would never have wanted to be in before then. Similarly and relatedly, IME one of the excuses for low Open Source donations from big US companies is "we have to monitor and audit where all donated money goes, and that's too much overhead". Centralise that work in a big, fairly well-trusted charity to which multiple other organisations can donate and that excuse is hopefully removed or partly removed. It has long annoyed me that the Open Source Initiative never (AFAIK) tried to take on this role, despite having been (at one time, at least) the most obvious candidate for the role.
Of course, the big hazard here is "who watches the watchmen?" But public scrutiny plus the fact that others can jump in and try to take some of the same middleman role might help to keep that risk partly under control.
This reminds me of when Redhat went public in the late 90s and did a generous thing with the friends and family round for the IPO. They included every open source contributor they could find in the Redhat sources. Including me, a grad student at the time. I made a few thousand dollars flipping the stock which probably doubled my salary for the year. (My contribution was an early HTML mode for emacs.) It was a really nice gesture.
Reddit did something similar last year in their IPO. I'd love to read an article on how people benefitted from it.
Ha, maybe there should be a tool that calculates your "bill" based on the OS stuff you are using and help you make a single payment that distributes it to the rightful owners. That bill thingy can be calculated as how much you actually used this stuff and how much donation they currently receive and then you pick how much you feel like paying thing month.
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).
I still think it's much more efficient to let your teams vote for 8 or 10 libraries, once or twice a year, send N dollars for every vote over <enough to make it worthwhile to track down donation information and cut a check> and carry over remainders from one vote to the next, so that everything below the cutoff gets some love every couple of intervals.
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.
One thing is a bit frustrating for me personally is that I have a few packages that get tons of downloads yet very little stars. This is because I solve a niche well. Im usually deep in the dependency tree, rarely as a direct dependency. I would definitely be ignored by this scheme.
I don’t know what the solution to that is. I think you’d still get a few votes. I think it’s unlikely for library authors to pass some of their donations down to the libraries they depend on.
Foundations should probably be doing some of this work. Maybe government as well. National Science Foundation did it for a bit, partly because of Al Gore, but that is also how we ended up with the current model of everything being free either until it isn’t, or until you become the produce (advertising, user tracking).
There are some relevant tools for this, such as https://thanks.dev. While it doesn't work as a usage-based billing, at least it provides a way to fund all dependencies.
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.
Title is cut off; it is missing “… via GitHub Sponsors and PyPI data ”. My project, for instance, does not use GitHub, nor is it a Python library or even Python-only.
I suspect that a better measurement might be based on what software people actually have installed, perhaps using the Debian Popcon data.
I love the idea! Anyone here from MS/Github who could integrate this into Github sponsors? That way you could "Donate to Open Source" and see the allocation distribution without having to do all this work.
This is cool: good, reasonable methodology (I like the value x risk idea).
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.
If a sufficiently large number of participants, with sufficient resources participate, then any open source project with sufficient utilization and value will receive funding.
Comparing to index funds is neat. What Flattr.com offered was to set a monthly budget and then not allocate according to an index but according to your preferences (value per flatter = monthly budget divided by number of flatters).
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.
Open-source maintainers are the base that holds the entire industry! It is such a nice noble and generous act, I honestly wouldn't dedicate my skills and time to work in something that is not going to help me to pay the bills. (pretty selfish, I know xD). it's great to have you guys around!
I think someone should make an ETF that donates 1-2% of profits to the open source packages that the companies use. Tie profit directly to payback to the community.
Undisclosed use would be a bad idea - your package could be receiving free funding!
Oh what a coincidence. I wrote pypular (https://codeberg.org/ltworf/pypular) to artificially increase download counts on PyPI (talked about it at a MiniDebConf).
I was claiming that there are important incentives to play this sort of games.
I feel like there is a big risk here, which others have already mentioned, but in fact this risk has already been realized w.r.t npm packages.https://news.ycombinator.com/item?id=41178258
While some mistakes are probably inevitable (like it happened with Tea protocol), sourcing a wide range of metrics from multiple sources, fixing bugs and building reasonable guardrails can prevent them from repeating.
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.
I wanted to see if chatGPT will be able to understand the meaning of this comic, and i think it did.
*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.
Building something for fun with others seems underrated outside software. I sometimes look with jelousy at pictures of amish barn raising. Who benefits is rather different tho.
Does anyone know of a non profit that routes money directly to open source projects? I'm wondering what's the best way to support open source via 501c3 dollars
I tried to fix software funding - I think people can sell licenses to their software, we can introduce new licenses that allow free usage for individuals and nonprofits and charge the companies. I am the worst marketer/seller ever and failed with getting the publicity. I still think that’s a worthwhile idea and have all the source code for this platform
>> we can introduce new licenses that allow free usage for individuals and nonprofits and charge the companies
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).
It does not seem that Randall Munroe (xkcd) accepts public donations, but he recently released his own book, which can be bought at https://xkcd.com/what-if. I've just ordered.
My concern is that the value a project brings isn't always objectively measurable. You can try to approximate it, sure, using # of downloads and whatever else, but then those metrics can also be easily gamed if the incentives are large enough. For example if you applied this same logic to the npm ecosystem then the creator of is-odd would retire a billionaire.
Regardless, donating something is always better than donating nothing, so kudos.
Thanks. There is no ideal set of metrics for value, but some measurable ones correlate with it. The more reasonable inputs are accounted for, the harder it is to game the system.
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.
This spending comes from my personal pocket and does not even create any tax relief. I just think that Open Source is important and want to efficiently support it.
I know at least one of the maintainers in the list, I know they live in the US and their project is something they maintain as a hobby with no expectation of retribution, and I know they are probably ecstatic to receive a small grant.
Yeah, it's not much. But the publicity and the methodology and the possibility of others doing the same is more impactful than just the financial resources the author had.
Thanks. That's a start experiment - I am going to donate more using this approach in the future and hope that other people will join me in this non-profit initiative.
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...?
> Value increases with # total downloads and LTM downloads on PyPI.
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.
> 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
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.
Exactly! The idea is to use available data for evaluating the value and risk of OSS and then allocate donations accordingly to the wide algo-based systemic index, not to a narrow set of manually picked projects (usually large or popular ones).
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.
Even an index fund has some human-curated criteria for what to include, though, right? The S&P 500 isn't open to just anyone. So it seems totally legitimate to have it be not completely algorithmic.
If there were an "Open 500" that was trying to be like the open equivalent to the S&P 500, I would happily donate to it. Right now I do GitHub sponsors but it feels kind of random.
You just don't want to include projects like React or TypeScript that are operated by a for-profit company - they don't need our donations. You want it to be, this money is actually going to an organization that will invest it in software quality.
Totally agree! Actually I had outlined similar ideas and even an example (Pydantic) in https://news.ycombinator.com/item?id=42353209
In a nutshell:
- Algorithmic does not always mean automatic. An algorithm can have a human-in-the-loop element, as S&P500 or NASDAQ Composite have.
- Future versions of the index will account for known funding of OSS owners and maybe even exclude well-funded companies.
If everyone use their own idiosyncratic algorithm for choosing OSS to donate to, it's going to be awfully hard to exploit.
There are probably only so many obvious metrics from which to pick and you wouldn't have to game them all, just pick the easiest ones and keep grinding. Fraudsters are usually motivated and not that dumb.
The mechanism is kinda like the Spotify fake songs case: https://www.justice.gov/usao-sdny/pr/north-carolina-musician...
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!
Which is why spotify should pay a percentage of MY subscription fee to only the artists that I listen to. My money shouldn’t go to Taylor Swift if I don’t listen to Taylor Swift.
That would eliminate direct financial payment from botting. But botting could still affect trending or “related” recommendations for indirect financial boost.
The issue there is that the listens from people who listen to less music would be worth more than the listens from people who listen to more music.
That's not an issue, that's accurately reflecting reality. If I'm paying the same $10/month just to listen to $OBSCURE_ARTIST for 10 plays per month, then each play of that _is_ worth more to Spotify than each play from a 10-year old listening to the same track of $SUPERSTAR one thousand times in a month.
In one case, 10 plays brought in $10 of revenue to Spotify, and those 10 plays should get $PERCENT of that $10.
In the other case, 1000 plays brought in $10 of revenue to Spotify, and those 1000 plays should also get the same $PERCENT of that $10.
A fixed monthly subscription amount with unlimited usage will always carry this deficiency. A solution that addresses this would be usage-based pricing.
I don't understand how this is a deficiency.
That's not an issue. That's the entire point. You track listens per account and if you're only listening to a single niche musician, all your money (not someone else's) goes to that musician.
The real mystery is why it should work any differently, because the cross subsidy seemingly creates a perverse profit incentive for bots to scalp off some of that cross subsidy. The economics are broken. This is socialism for the rich and popular.
I find that court case very off putting, since it was Spotify that stole the royalties, because the same mechanic applies to simply being popular. When will someone sue Taylor Swift for stealing royalties?
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.
Exactly, and Goodhart's law drives the nails in the coffin.
https://en.wikipedia.org/wiki/Goodhart%27s_law
Makes me think of the "cobra effect", like the Great Hanoi Rat Massacre.[1]
Set arbitrary metrics like download count -> bad actors make bots to download their package -> they profit while the registry suffers from very heavy load.
[1]: https://en.wikipedia.org/wiki/Great_Hanoi_Rat_Massacre
Rather than trying to donate to the most popular packages, people could try to donate to the packages they use, and then their dependencies (it would be nicer, though, if repos had a way for packages to list their dependencies and automatically propagate donations they received down—which would be a usable by the top level packages but, eh, you have to trust people at some point).
2 is already happening, I have seen this multiple times.
sweet sweet human nature.
Hey HN community, thanks a lot for your great feedback and actionable critique!
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...
Great idea, I also think it'd be interesting to systematically donate to the projects with the lowest bus factor (or as that one XKCD describes it: "the project that a random person in Nebraska has been maintaining since 2005")
Yes, that would be a very useful risk metric! Assuming access only to public APIs (GitHub, package managers, etc.), how would you define the bus factor in terms of data? I am thinking about # unique contributors over the last X years.
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...
It's a great idea; I have some similar thoughts. The looming problem, though, is that Goodheart's Law is likely to strike if this ever gets scaled up significantly.
Worse (and very unfortunately), any kind of unmonitored/low-attention payment scheme that starts funneling meaningful money to countless small libraries turns those libraries into revenue streams whose ownership can be valued and sold.
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.
I generally agree, though some of those specific risks already exist and some (like license changes) are if anything probably less likely if they mean giving up significant donation money.
I think you can solve that by funding the dependencies you rely on and have them fund their dependencies and so on...
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
It's a good start, but it's vulnerable to sticky fingers, patronage relationships and so on if the money becomes serious. For example, what if a project writes internal code instead of having a dependency on someone else's library? Do they get to keep the money which would have gone to an external contributor, creating an incentive to pull everything in-house? Or do they still have to push the same amount of money upstream? That creates the opposite incentive, a bag of free money which can be directed to third-party libraries which purely by coincidence happen to be staffed by members of the downstream project and/or their pals.
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.
In case anyone else was wondering:
Goodhart's law is an adage often stated as, "When a measure becomes a target, it ceases to be a good measure"
https://en.wikipedia.org/wiki/Goodhart's_law
In concrete terms, what you would or will see, if enough money starts going down this track, is open-source contributors changing their behaviour as they seek to make projects "donation-optimised" and to maximise their personal share of donations, and likely also "donation-bait" projects which exist simply to game the system. But even though all this could get quite bad, it's still quite likely to be less bad than the status quo. EDIT: If you're thinking of making such a contribution yourself I don't think the downsides should deter you yet, at least unless you're lucky enough to have control of a truly large bag.
On that note, the article states that it donates more to higher risk projects, and risk increases by OpenSSF score. One question I had about the article is does that mean that projects with more security vulns get a higher donation? If so, then that might become a perverse incentive to leave security gaps in your code.
I think this is a really interesting model for providing funding to open source software. There's something about the "Index Fund" approach that is really appealing. I also think it's interesting that the author was both balancing "value" and "risk". I do wonder, if this became a more dominant strategy for providing funding for open source how you would deal with a couple potentially adverse incentives:
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"?
But the issue is, whatever the criterias are, they will become the main kpis opensource projects (at least the not-so-driven ones) will target for growth. Goodhart's law.
I think Goodhart's law only applies if you have fixed, published criteria for funding. That's why I mentioned transparency explicitly. I wonder if you could avoid some of the worst of Goodhart's law by saying something like "the formula changes every year, and we will publish it only after 5 years, but the goal is to reward value provided, and de-risk the ecosystem". The idea being you're explicitly trying to incentivize broadly valuable work rather than specific metrics.
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 think that might be the best strategy: a charity playing Google and being transparent about what money it distributes to whom, but being less transparent about the exact mechanism it uses to calculate the disbursement, or at least being ready to make arbitrary future changes at its discretion to the mechanism to counter gaming (as well as outright zapping clear offenders ad hoc). One nice thing about this strategy is that it could generate a virtuous circle: consolidate together a big enough pot of money from early adopters and you could start getting some good media coverage, which in turn might generate interest and donations from "normie" sources which would never have wanted to be in before then. Similarly and relatedly, IME one of the excuses for low Open Source donations from big US companies is "we have to monitor and audit where all donated money goes, and that's too much overhead". Centralise that work in a big, fairly well-trusted charity to which multiple other organisations can donate and that excuse is hopefully removed or partly removed. It has long annoyed me that the Open Source Initiative never (AFAIK) tried to take on this role, despite having been (at one time, at least) the most obvious candidate for the role.
Of course, the big hazard here is "who watches the watchmen?" But public scrutiny plus the fact that others can jump in and try to take some of the same middleman role might help to keep that risk partly under control.
> Publishing the exact formula for funding is great for transparency, but then leads to an incentive to game the system to capture funding.
I say think of it as an authorization protocol, and watch how people break it in order to figure out how to fix it.
> There's something about the "Index Fund" approach that is really appealing
This is an approach I'm actively working on, although I haven't actively donated anywhere yet.
This reminds me of when Redhat went public in the late 90s and did a generous thing with the friends and family round for the IPO. They included every open source contributor they could find in the Redhat sources. Including me, a grad student at the time. I made a few thousand dollars flipping the stock which probably doubled my salary for the year. (My contribution was an early HTML mode for emacs.) It was a really nice gesture.
Reddit did something similar last year in their IPO. I'd love to read an article on how people benefitted from it.
Ha, maybe there should be a tool that calculates your "bill" based on the OS stuff you are using and help you make a single payment that distributes it to the rightful owners. That bill thingy can be calculated as how much you actually used this stuff and how much donation they currently receive and then you pick how much you feel like paying thing month.
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).
I still think it's much more efficient to let your teams vote for 8 or 10 libraries, once or twice a year, send N dollars for every vote over <enough to make it worthwhile to track down donation information and cut a check> and carry over remainders from one vote to the next, so that everything below the cutoff gets some love every couple of intervals.
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.
One thing is a bit frustrating for me personally is that I have a few packages that get tons of downloads yet very little stars. This is because I solve a niche well. Im usually deep in the dependency tree, rarely as a direct dependency. I would definitely be ignored by this scheme.
I don’t know what the solution to that is. I think you’d still get a few votes. I think it’s unlikely for library authors to pass some of their donations down to the libraries they depend on.
Foundations should probably be doing some of this work. Maybe government as well. National Science Foundation did it for a bit, partly because of Al Gore, but that is also how we ended up with the current model of everything being free either until it isn’t, or until you become the produce (advertising, user tracking).
There are some relevant tools for this, such as https://thanks.dev. While it doesn't work as a usage-based billing, at least it provides a way to fund all dependencies.
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.
Title is cut off; it is missing “… via GitHub Sponsors and PyPI data ”. My project, for instance, does not use GitHub, nor is it a Python library or even Python-only.
I suspect that a better measurement might be based on what software people actually have installed, perhaps using the Debian Popcon data.
I love the idea! Anyone here from MS/Github who could integrate this into Github sponsors? That way you could "Donate to Open Source" and see the allocation distribution without having to do all this work.
This is cool: good, reasonable methodology (I like the value x risk idea).
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
Thanks!
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.
I believe this is a better approach for scale.
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).
I was 18th on the list, thanks for the donation!
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.
If a sufficiently large number of participants, with sufficient resources participate, then any open source project with sufficient utilization and value will receive funding.
Lots of “sufficients” in there, of course.
Comparing to index funds is neat. What Flattr.com offered was to set a monthly budget and then not allocate according to an index but according to your preferences (value per flatter = monthly budget divided by number of flatters).
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.
Had to modify the title slightly to pass validation. Also "How [I algo...]" got removed, did not know that happens automatically.
You can edit the title after submission (the automatic change won't trigger).
Open-source maintainers are the base that holds the entire industry! It is such a nice noble and generous act, I honestly wouldn't dedicate my skills and time to work in something that is not going to help me to pay the bills. (pretty selfish, I know xD). it's great to have you guys around!
I think someone should make an ETF that donates 1-2% of profits to the open source packages that the companies use. Tie profit directly to payback to the community.
Undisclosed use would be a bad idea - your package could be receiving free funding!
As soon as money is in play, greedy people will start gaming the system. The anonymous guy in Nebraska won't have a chance, even if he is interested.
tl;dr: well intentioned, but it isn't gonna work.
Specially when GitHub gatekeeps users from accepting sponsorships, even if you have stuff published for over a decade.
Oh what a coincidence. I wrote pypular (https://codeberg.org/ltworf/pypular) to artificially increase download counts on PyPI (talked about it at a MiniDebConf).
I was claiming that there are important incentives to play this sort of games.
Seems OP proved me right!
In your opinion, which metrics could be better than # downloads to evaluate PyPI packages at scale?
# of downloads from unique IP would be better for sure.
Also if you have a local cache and just check the version, that won't count.
Great post! I wish all companies would recognize their dependency on open source and compensate accordingly.
I feel like there is a big risk here, which others have already mentioned, but in fact this risk has already been realized w.r.t npm packages.https://news.ycombinator.com/item?id=41178258
While some mistakes are probably inevitable (like it happened with Tea protocol), sourcing a wide range of metrics from multiple sources, fixing bugs and building reasonable guardrails can prevent them from repeating.
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.
I wanted to see if chatGPT will be able to understand the meaning of this comic, and i think it did.
*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.
Building something for fun with others seems underrated outside software. I sometimes look with jelousy at pictures of amish barn raising. Who benefits is rather different tho.
Does anyone know of a non profit that routes money directly to open source projects? I'm wondering what's the best way to support open source via 501c3 dollars
Wow! I was surprised to see myself on the list. Sure enough, I see a donation and it will take 90 days to pay out the first time.
Interesting project
By the way, a lot of money goes to open-source projects via donations in exchange for an SEO backlink. A lot of stuff going down there.
I tried to fix software funding - I think people can sell licenses to their software, we can introduce new licenses that allow free usage for individuals and nonprofits and charge the companies. I am the worst marketer/seller ever and failed with getting the publicity. I still think that’s a worthwhile idea and have all the source code for this platform
>> we can introduce new licenses that allow free usage for individuals and nonprofits and charge the companies
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).
I think someone should also donate to the person who created that open source meme.
It does not seem that Randall Munroe (xkcd) accepts public donations, but he recently released his own book, which can be bought at https://xkcd.com/what-if. I've just ordered.
Oh right! I remember now. That meme was from xkcd.
My concern is that the value a project brings isn't always objectively measurable. You can try to approximate it, sure, using # of downloads and whatever else, but then those metrics can also be easily gamed if the incentives are large enough. For example if you applied this same logic to the npm ecosystem then the creator of is-odd would retire a billionaire.
Regardless, donating something is always better than donating nothing, so kudos.
Thanks. There is no ideal set of metrics for value, but some measurable ones correlate with it. The more reasonable inputs are accounted for, the harder it is to game the system.
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.
[dead]
Great initiative!
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.
One thing I want to try is looking at all the packages on a minimum install of a Linux distro. How many of those are just a dude?
[flagged]
Must be nice to have $5k to burn. Probably means you have too much money.
The guy is a GP at a VC so I think this spend goes from their marketing budget.
This spending comes from my personal pocket and does not even create any tax relief. I just think that Open Source is important and want to efficiently support it.
5000 is not that much anymore, especially in the US. would have been better to split into $1000 chunks instead of $200
I know at least one of the maintainers in the list, I know they live in the US and their project is something they maintain as a hobby with no expectation of retribution, and I know they are probably ecstatic to receive a small grant.
Yeah, it's not much. But the publicity and the methodology and the possibility of others doing the same is more impactful than just the financial resources the author had.
Thanks. That's a start experiment - I am going to donate more using this approach in the future and hope that other people will join me in this non-profit initiative.
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...?