This is a terrible idea in my opinion and it's been tried/is being tried by services like thanks.dev. Yes, we need something here but this is not it. The reality is more complex.

It doesn't work well in practice. Because then people like https://github.com/sindresorhus?tab=repositories&type=source would get a shit ton of money because of the pure number of dependencies. And yes our stack also contains his code somewhere in a debug UI but our main product is entirely written in a different programming language with way fewer dependencies but if one of them goes away we'd be in trouble. In other words: Dependency count is not a good metric for this.

GitHub actually offers something in that direction: https://github.com/sponsors/explore

My "idea": Lots of companies will have to create SBOMs anyway. Take all of those but also scan your machines and take all the open source software running on there (your package.lock does not contain VLC etc.) and throw it in a big company wide BOM, then somehow prioritise those using algorithms, data and just manual voting and then upload that to some distributor who then distributes this to all the relevant organisations and people and then (crucially) sends me (as a company) an invoice.

We've tried doing the right thing but sponsoring is hard - it works differently for every project/foundation and the administrative overhead is huge.

The reality is that "we" as an open-source community suck at taking money and I believe this is partially on us.

> The reality is that "we" as an open-source community suck at taking money and I believe this is partially on us.

More broadly people suck at giving money for things they can get for free. That’s just the reality of how most people out there behave.

The only “solution” is to educate people but that is completely unfeasible.