Show HN: Recursive Donations to support Open Source maintainers(recursive.gives)
recursive.gives
Show HN: Recursive Donations to support Open Source maintainers
https://recursive.gives/
3 comments
Thanks for the links. Very useful. As a company that relies on open-source and wants to donate some (limited) money, we're facing a challenge. How do we easily donate a fixed sum every year/month and make sure it goes to open-source projects we depend on.
I tried https://backyourstack.com and uploaded our Gemfile.lock (rubygems) to try to match it with opencollective projects. It detected 249 dependencies but zero projects that require funding on opencollective :(
Do you have any advice on how to go about it? we really want to contribute back, but it seems like an impossible task right now.
EDIT: btw both www.libraries.io and www.repology.org cannot resolve DNS for me... are they gone?
I tried https://backyourstack.com and uploaded our Gemfile.lock (rubygems) to try to match it with opencollective projects. It detected 249 dependencies but zero projects that require funding on opencollective :(
Do you have any advice on how to go about it? we really want to contribute back, but it seems like an impossible task right now.
EDIT: btw both www.libraries.io and www.repology.org cannot resolve DNS for me... are they gone?
Hey, exactly that problem do we want to solve! Good to hear that more people want to donate but face this problem.
The links btw are: https://libraries.io/ and https://repology.org
The links btw are: https://libraries.io/ and https://repology.org
Thanks a lot for all the helpful links and relevant questions. I agree, there is still a lot to clarify. I also see Recursive as a platform which could work together with other platforms. Recursive can't solve tax issues for the project owners but can be an additional source for donations which can then be received by any legal entity.
Author here:
I know several people and also companies who would like to support Open Source financially, but don’t know how to do it in a fair way. Usually, there is just one approach, pick the most important library/project you depend on and donate some money to them. I asked myself if there is a simple method to support more maintainers with one donation, especially those who are further down the dependency chain and, thus, lack visibility. If you want to donate, for example, 100$ to 100 libraries, it is almost impossible to do it easily. You have to investigate for every single project if they accept donations, what platform they use for it, split the money, pay in the worst case 100 times transaction fees (credit card, bank transfer fees), and finally initiate the transactions.
I envision that you can donate on one platform and the donation is transparently and automatically distributed to all maintainers your project depends on. On the contributors’ side, this means that even if you are a small library down the dependency chain and don’t usually get a lot of visibility, you receive a small amount of the donation. I built a small mock up to demonstrate how it could work ... https://recursive.gives
As there are a lot of Open Source enthusiasts here, I would like to know if you think that it can work or if you have any other suggestion to tackle the problem.
I know several people and also companies who would like to support Open Source financially, but don’t know how to do it in a fair way. Usually, there is just one approach, pick the most important library/project you depend on and donate some money to them. I asked myself if there is a simple method to support more maintainers with one donation, especially those who are further down the dependency chain and, thus, lack visibility. If you want to donate, for example, 100$ to 100 libraries, it is almost impossible to do it easily. You have to investigate for every single project if they accept donations, what platform they use for it, split the money, pay in the worst case 100 times transaction fees (credit card, bank transfer fees), and finally initiate the transactions.
I envision that you can donate on one platform and the donation is transparently and automatically distributed to all maintainers your project depends on. On the contributors’ side, this means that even if you are a small library down the dependency chain and don’t usually get a lot of visibility, you receive a small amount of the donation. I built a small mock up to demonstrate how it could work ... https://recursive.gives
As there are a lot of Open Source enthusiasts here, I would like to know if you think that it can work or if you have any other suggestion to tackle the problem.
Why do the devDependencies gets less attention than the "normal" dependencies?
In my case, it does not matter if the dependency was added to "dev" or "normal", because I just compile JavaScript and CSS to a minified version. All dependencies are needed in the build process only.
I would recomment not to differentiate between runtime dependencies and dev dependencies.
In my case, it does not matter if the dependency was added to "dev" or "normal", because I just compile JavaScript and CSS to a minified version. All dependencies are needed in the build process only.
I would recomment not to differentiate between runtime dependencies and dev dependencies.
Usually, your runtime deps are still in your minified version and used during runtime. But in general, it might be a good idea to offer this as an option to the user how the money should be distributed.
I am not saying it cannot be done. It definitely can, and the more options we have the better. Sites like https://www.opencollective.com are trying. Github has a bunch of new Sponsorship features. They have the audience.
Sites like https://www.libaries.io and https://www.repology.org are building dependency graphs. There are other places which can help to identify the recursive structure you are after.
Fiscal sponsorship entities like https://www.sfconservancy.org and https://www.techcultivation.org, apache.org etc are trying to tackle some of the issues to legally represent projects (and receive donations for them).