It's heart breaking to know that the world's largest companies are using software whose author is struggling financially. That xkcd is 100% right, but this situation is far from amusing.
It's heart breaking to know that the world's largest companies are using software whose author is struggling financially. That xkcd is 100% right, but this situation is far from amusing.
FWIW this is not the way. Distributing based on these criteria means most of the funding will go to those who already receive most of the funding. It does not solve the XKCD/2347 problem, which is exactly what this guy is encountering: People who maintain unknown software, software you don't even realize you're using, but which is so useful it ends up used everywhere.
OpenSSH (via OpenBSD) faced that issue in 2014 (https://www.osnews.com/story/27519/openbsd-will-shut-down-if...), and got funding because the story got attention. I suspect core-js after this post has also solved his problem for the time being thanks to this post (assuming it gets enough attention; seeing as it's at the top of HN now, I bet it will). But this is not viable. People in open source often do not see money as a resource, but as a corruptor, so they refuse to touch it unless strictly necessary; to a fault. (I should know; I was in that situation as well for years. Out of idealism I also refused to touch money. Now I work in fintech, so clearly I changed my outlook; but old me would probably hate current me.)
What a soul-crushingly sad and difficult read this was, though. Jesus.
Am I interpreting it right, and your service acts as an escrow? Even though you seem to solve the payment headaches, I'm not sure I'd trust a middle-man to do the right thing in these matters. Would it be possible to use your tool entirely offline and just get a list of dependencies, and suggested payment per month for each depending on available funds? And then allow me to tweak it depending on whatever criteria I want, similar to the Humble Bundle sliders?
Getting the payments out to every project would be a hassle that you already solve, but I think it would be preferable to deal with those than with a centralized service that everyone depends on.
It depends on the strategy used. If we define "popularity" as "number of our projects that depend on this OSS project", then the distribution should be fair, and projects like core-js would be well compensated. This could all be automated, and the popularity ranking could be fixed and used by default, so that employees could add additional funding by voting on their most used and loved projects. I think both approaches would work well.
In any case, my suggestion was to create a company-wide OSS fund to begin with, which most companies don't even bother with. The strategy of how they're appropriated can always be improved after that.