I like the idea but instead of pools going arbitrarily every which way or to the discretion of the donator, it should be automatically applied across that open source project's dependencies as well. If I am open source software A, and I make ample use of open source software B within my project, your pool donation should automatically apply some to B, relative to it's usage in the project.
Agreed this would be nice, though this layer of complexity introduces a bigger attack surface for bad actors. They could try to get their modules listed as dependencies of popular projects to piggyback on their downloads. On the flip side there are some low-level tools (say, the `stylis` CSS autoprefixer) that are almost never used in their "raw form" but are the backbone of several massively popular projects. It's a tricky balance.
Is this really a concern though? In this situation, adding a dependency to your project means making a decision to divert some of your funding to them as well. It gives an incentive to avoid adding unnecessary dependencies.
If you're willing to do the extra maintenance of keeping them up to date (or else on the hook for their issues) ... maybe that's 'ok'?
I don't mean that it's a service worth paying for, just that maybe it doesn't seem like it's worth the extra (presumably minor) cut of initial donation and people wouldn't really do it (more than once / for long / on a big project with significant donations) anyway.
Distribution indeed seems to be tricky. Out of the myriad of utilities you use, e.g. React & a string sorting library. Should they both receive the same remuneration? That feels wrong.
No. The amount you donate, the majority goes to the primary project, since that's directly what you the user are receiving the value from, even if it's for the sake of the author pulling those dependencies together in a usable convenient fashion for you. The discussion simply becomes how much goes to the primary and how many goes downstream. I think 51% to the primary dependency at minimum as a starting point for debate.
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).
