I had a similar idea to this while reading the article. Basically, people donate primarily to end-user facing projects, like they do anyway (if at all). Each de

I had a similar idea to this while reading the article. Basically, people donate primarily to end-user facing projects, like they do anyway (if at all). Each dependency gets 10% of the donation, which gets capped at 50:50. If there are more than 5 dependencies, these share the 50% among them. So for example, in case I described it bad: Project A (1 dep.) gets 90%, the dep. 10%; Project B (5 dep.) gets 50%, each dep. gets 10%; Project C (10 dep.) gets 50%, each dep. gets 5%. Now for the loopholes: How to track dependencies? Well, I think the fear of public-shaming and pulling back of donations in case of bad acting would stop the end-user facing projects from lying. This donation system (ideally run by a trustful brand like Mozilla etc.) has a website, where you can look up projects and the dependencies they list. Since being open source is a requirement, claims can be checked. Should all dependencies be weighted the same? The massive UI library, and the tiny bare-bones A*-implementation, or the NPM micropackages? This needs a metric that can't be rigged, so things like number of contributors, LoC or number of commits are not really sufficient. What about MIT-licensed libraries? They may get used a lot by proprietary projects, but these can't receive donations in first place, so there is nothing to share to the libraries. Now the opinions on MIT are kinda mixed, but simply saying "your fault, pick a viral licence" is too easy, imo. __ Footnote: How the [user]--donation-->[end-user facing project] chain works in first place, is not really part of my idea, I wanted to focus on how to get the money to the people whose project names nobody knows (until things like Heartbleed happen).