> 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.
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:
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.
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"?
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.
kibwen ·19 days ago
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.
Show replies
kvinogradov ·18 days ago
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...
Show replies
leoc ·19 days ago
Show replies
Wilduck ·19 days ago
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"?
Show replies
NelsonMinar ·18 days ago
Reddit did something similar last year in their IPO. I'd love to read an article on how people benefitted from it.