pull down to refresh
619 sats \ 3 replies \ @Lumor 17 Nov 2023 \ on: The Lack of Compensation in Open Source Software is Unsustainable bitcoin
I've been considering a solution were lightning addresses are added as metadata to libraries and applications, and the user (company?) can periodically blast them with sats. Maybe the OS keeps track of how much one uses the various parts, and its up to the user if they want to especially boost one component. Devs could potentially boost certain dependencies they feel strongly about more than others.
There are projects in various systems to generate SBOMs - information about software including all dependencies. One could probably use that.
I really like this idea. I think it would have to be included in some format though that would be free from manipulation or removal, it shouldn't just be included in plaintext format so that anyone who had access to the code could just delete it or change it. Perhaps there could be some kind of webring-style service setup on nostr or a similar platform, that existed using a weighted trust kind of model, to ensure that people who were added to it for receiving payouts for contributions were individuals/developers who were known to other people who were known to be actual, contributing developers. Basically, if person A is a prominent developer who is known by many people, but person C is a developer who also contributes but isn't known by many people -- as long as they have one person (person B) in common, who can vouch for them, so to speak, it would enable their inclusion. Kind of similar to "social proofs", if you are familiar with the concept.
Could have any software/projects built that wanted to include it, just include the webring service thing as a dependency/included library, and it would periodically sync up with a web URL/nostr node that could push an array of the different lightning addresses, etc.
reply
Glad you like it!
Yeah, ensuring malicious people don't replace the lightning addresses of the component maintainers is critical. The same thing goes for not having dependencies which are clones of the actual library, just with added malware.
Payments per component would further incentivize devs to fork their dependencies as soon as they run into trouble with them. And then keep the forks alive, to have their own payment address set.
Guess that leads us further towards some kind of reputation-based system like what you suggest.
reply
I know the guys at Alby are working on this issue. they suggested adding this to my PeerTube plugin's package.json for future funding.
"funding": {
"type": "lightning",
"url": "lightning:donkimberlin@getalby.com"
},
reply