[HN Gopher] I algorithmically donated $5000 to Open Source
___________________________________________________________________
I algorithmically donated $5000 to Open Source
Author : lorey
Score : 267 points
Date : 2024-12-03 22:45 UTC (4 days ago)
(HTM) web link (kvinogradov.com)
(TXT) w3m dump (kvinogradov.com)
| lorey wrote:
| Had to modify the title slightly to pass validation. Also "How [I
| algo...]" got removed, did not know that happens automatically.
| asicsp wrote:
| You can edit the title after submission (the automatic change
| won't trigger).
| mrbluecoat wrote:
| Great post! I wish all companies would recognize their dependency
| on open source and compensate accordingly.
| 38 wrote:
| 5000 is not that much anymore, especially in the US. would have
| been better to split into $1000 chunks instead of $200
| loloquwowndueo wrote:
| 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.
| mikelward wrote:
| 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.
| kvinogradov wrote:
| 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...?
| Wilduck wrote:
| 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"?
| 3abiton wrote:
| 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.
| Wilduck wrote:
| 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.
| leoc wrote:
| 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.
| pessimizer wrote:
| > 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.
| ants_everywhere wrote:
| > 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.
| bajabaq wrote:
| 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
| dmacedo wrote:
| 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).
| tlocke wrote:
| 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.
| freen wrote:
| 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.
| iandanforth wrote:
| 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.
| bradley13 wrote:
| 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.
| kassner wrote:
| Specially when GitHub gatekeeps users from accepting
| sponsorships, even if you have stuff published for over a
| decade.
| leoc wrote:
| 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.
| cbeach wrote:
| 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
| leoc wrote:
| 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.
| TiredGuy wrote:
| 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.
| airstrike wrote:
| 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
| leoc wrote:
| 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.
| swatcoder wrote:
| 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.
| leoc wrote:
| 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.
| paxys wrote:
| 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.
| kvinogradov wrote:
| 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.
| IAmLiterallyAB wrote:
| 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?
| teddyh wrote:
| 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.
| mrtksn wrote:
| 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).
| Wilsoniumite wrote:
| 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
| lorenzleutgeb wrote:
| 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.
| joshdavham wrote:
| I think someone should also donate to the person who created that
| open source meme.
| kibwen wrote:
| _> 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.
| tempodox wrote:
| Exactly, and Goodhart's law drives the nails in the coffin.
|
| https://en.wikipedia.org/wiki/Goodhart%27s_law
| ddulaney wrote:
| 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!
| TuringTest wrote:
| _> 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.
| kiba wrote:
| If everyone use their own idiosyncratic algorithm for
| choosing OSS to donate to, it's going to be awfully hard to
| exploit.
| kvinogradov wrote:
| 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.
| bee_rider wrote:
| 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).
| Pooge wrote:
| 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
| igor47 wrote:
| 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
| jvanderbot wrote:
| 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!
| jillyboel wrote:
| Must be nice to have $5k to burn. Probably means you have too
| much money.
| Nimishg14 wrote:
| The guy is a GP at a VC so I think this spend goes from their
| marketing budget.
| kvinogradov wrote:
| 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.
| yu3zhou4 wrote:
| 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
| hartator wrote:
| 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.
| kvinogradov wrote:
| 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...
| theendisney wrote:
| 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.
___________________________________________________________________
(page generated 2024-12-07 23:00 UTC)