← Back to context

Comment by leoc

1 year ago

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.