5 ms·
I think the devil is in the details. As others have pointed out, this would drastically change the incentive structure of OSS. You would attract actors whose en
by zoogeny 3y ago
I think the devil is in the details. As others have pointed out, this would drastically change the incentive structure of OSS. You would attract actors whose entire purpose would be to get listed on as many SBOMs as possible to maximize their revenue potential. I'm envisioning a world of `padLeft` controversies.
That is to say, I don't think a pure "frequency of use" metric is sufficient to fairly distribute such a pool. And if you have a large and growing pool of available money then the incentive to game the distribution scheme becomes more attractive than making truly awesome software. And I very much doubt that we have any reliable ways of aligning such a money distribution scheme with the goal of creating amazing software.
- orblivion 3y ago`padLeft` can't just inject itself into a software stack right? So there's an incentive to be valuable enough to be included.
- VyseofArcadia 3y agoDepends on how you do the accounting. "Well, you don't use padLeft, but 15 packages you depend on do, and 68 packages tjat those packages depend on do... Altogether you're looking at 348 instances of padLeft."
- orblivion 3y agoIf there were a metric that would make each instance of padLeft worth a tiny amount of money (for such a tiny library), that sounds like a reasonable outcome to me. EDIT: I may be missing part of the point
- bee_rider 3y agoA trivial way to exploit this kind of system, I think, would be to write LegitimatelyUsefulLibrary, then write 1,000 PadLeft projects, and make LegitimatelyUsefulLibrary depend on all of them. Since you are the one marking the dependency of LegitimatelyUsefulLibrary on your PadLeft projects, you can game the metrics however you’d like when making it.
- noworriesnate 3y agoBut why would I, as a developer, use such a library? It would cut me out of profits unnecessarily. In fact when I’m picking my dependencies I will deliberately avoid those that take a larger slice of the pie than is worth it for me.
- kybernetikos 3y agoIf I remember the story correctly the padLeft dev was actually pretty notorious for submitting patches to open source projects that 'coincidentally' added dependencies on his code.
- stolsvik 3y agoSources?
- bee_rider 3y agoI wonder if it would be enough to just recursively pay out to each dependency. You pick a % to keep and a % to pass along to each of your your dependencies, and then they split up that % that you passed along to them, so on and so forth. Of course people could choose to pass 0% along to their dependencies. But that seems fine; people can adjust and just not send greedy projects a very big split. Trying to enforce some fairness on the outside will probably just result in silly behavior from greedy people (ie, if every project gets an equal split out and somebody doesn’t want to hand any money down to their dependencies, then they can just create a bunch of tiny projects to dilute their out-split).
- Clamchop 3y agoOnly enumerate and pay for top-level tools and dependencies, none of which are probably padLeft. Those downstream recipients can further "pay it forward" to their top-level dependencies. Everyone has an incentive to not pull in superfluous bullshit so they can hold onto as much of their pitance as possible. Trickle down economics? Ronald, is that you?
- lars_francke 3y agoEverything you say is correct. I still want this. It's better than what we have today. We can work on improving things later.