4 ms·

> employees decide how the funds get appropriated. E.g. by popularity, relevance, love, or whatever other criteria feels right FWIW this is not the way. Distri

> employees decide how the funds get appropriated. E.g. by popularity, relevance, love, or whatever other criteria feels right 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-we-do-not-have-the-funding/ 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.

nevernude 4y ago
At this risk of some self promotion, we developed StackAid (https://stackaid.us https://stackaid.us) to help fund the long tail of open source because of the exact problems you mentioned. People only tend to remember the popular/direct dependencies.
- imiric 4y ago
  This is a great project, thanks for creating it. 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.
  - nevernude 4y ago
    Yes, we do hold payments for projects and pay them out monthly. However if you don't want to claim your funds on StackAid but do accept donations elsewhere, we will use those service to pay you out instead. Running the tool offline would be challenging because we a large index of dependency->repository mappings across various ecosystems so we can resolve your dependency tree. You would also still be stuck manually paying out to possibly hundreds of projects. FWIW we are completely transparent about the payments we make to each project as well as how much goes to us.
imiric 4y ago
> Distributing based on these criteria means most of the funding will go to those who already receive most of the funding. 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.

nevernude 4y ago

At this risk of some self promotion, we developed StackAid (https://stackaid.us https://stackaid.us) to help fund the long tail of open source because of the exact problems you mentioned. People only tend to remember the popular/direct dependencies.

imiric 4y ago
This is a great project, thanks for creating it. 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.
- nevernude 4y ago
  Yes, we do hold payments for projects and pay them out monthly. However if you don't want to claim your funds on StackAid but do accept donations elsewhere, we will use those service to pay you out instead. Running the tool offline would be challenging because we a large index of dependency->repository mappings across various ecosystems so we can resolve your dependency tree. You would also still be stuck manually paying out to possibly hundreds of projects. FWIW we are completely transparent about the payments we make to each project as well as how much goes to us.

imiric 4y ago

> Distributing based on these criteria means most of the funding will go to those who already receive most of the funding. 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.