This makes logical sense on the face of it, but in practice dependency stacks can be very broad and very deep. I doubt there would be enough donation money to make the effort of distributing it worthwhile, and at some point there would be so many small transactions that the transaction fees would eat up a significant amount.
Especially for something as complex as an OS, the dependency inventory is less like a list and more like a fractal.
It’s a donation so you’re never going to have perfect pricing everything down to the nearest penny or remunerating each person-hour worked. I think It’s about something rough and ready that is better than nothing. And it’s all goverened by morality anyway . . .
so doomed to failure on that side.
Buy hypothetically a simple principle with reasonable administration cost, like each 3 months, each node shoud add up all donations, slice off 25-50% , split it equally among their top 5 or 10 most important dependencies - just guess, and maybe swap from quarter to quarter if if there’s doubt. There’s some wiggle room there for small projects to do less and large over funded projects to do more.
Each node in the network could follow a simple rule like that, making a limited number of transactions each time period ,and you’d probably end up with quite a complex outcome after a few iterations (years).
The real trick would be having enough nodes in the network that actually enact such a simple rule. (Apart from having enough donations flow in to the consumer level projects of course).
But enough nodes and enough inflow and the fractal would work for you - roughly.
THe speed is an issue, the more often you settle up then quicker people see money, but the more the admin cost.
But even doing it quaterly is not slower than doing nothing.
Such a model is not something anyone will be securing bank loans off though, so if that’s the point then you probably need a paid licensing / service model of some sourt maybe Canonical and redhat.
When I buy a turnip from the grocery store I don’t have to pay the farmer directly.
If I donate to debian, that I depend on , then debian (morally) should disburse some of that donation to the linux kernel that debian depends on.
This makes logical sense on the face of it, but in practice dependency stacks can be very broad and very deep. I doubt there would be enough donation money to make the effort of distributing it worthwhile, and at some point there would be so many small transactions that the transaction fees would eat up a significant amount.
Especially for something as complex as an OS, the dependency inventory is less like a list and more like a fractal.
It’s a donation so you’re never going to have perfect pricing everything down to the nearest penny or remunerating each person-hour worked. I think It’s about something rough and ready that is better than nothing. And it’s all goverened by morality anyway . . .
so doomed to failure on that side.
Buy hypothetically a simple principle with reasonable administration cost, like each 3 months, each node shoud add up all donations, slice off 25-50% , split it equally among their top 5 or 10 most important dependencies - just guess, and maybe swap from quarter to quarter if if there’s doubt. There’s some wiggle room there for small projects to do less and large over funded projects to do more.
Each node in the network could follow a simple rule like that, making a limited number of transactions each time period ,and you’d probably end up with quite a complex outcome after a few iterations (years).
The real trick would be having enough nodes in the network that actually enact such a simple rule. (Apart from having enough donations flow in to the consumer level projects of course).
But enough nodes and enough inflow and the fractal would work for you - roughly.
THe speed is an issue, the more often you settle up then quicker people see money, but the more the admin cost.
But even doing it quaterly is not slower than doing nothing.
Such a model is not something anyone will be securing bank loans off though, so if that’s the point then you probably need a paid licensing / service model of some sourt maybe Canonical and redhat.