The UI imposes a 5% minimum (and 15% default) value for "Tip thanks.dev" under "How much would you like to donate each month?" on https://thanks.dev/settings
This implementation is clearly for-profit. I want to directly tip open source projects using a system that doesn't involve other third parties taking a significant cut.
What are your fees?
Tips at time of donation. You decide.
If payment is required to use a service then that payment is not a "tip" - it is a "fee". Anything over the required payment would be a "tip". This FAQ answer implies that the required payment is zero, which, it turns out, is false.
There is absolutely nothing wrong with charging a fee for a service, but there is something wrong with lying about it.
> There is absolutely nothing wrong with charging a fee for a service
Agreed, but percentage-based fees can quickly become an unfairly large part of payments. I love the idea of this project, but I'd prefer there to be a 5% or X dollars minimum, so that if 5% is more than X dollars, then it doesn't force 5% minimum. If I'm donating $500 to 45 projects, then each project on an even split is getting $11, but thanks.dev is getting $25 even though their service isn't actually in use by my app/service. Seems unfair to me.
The irony of "someone should build something for free" when complaining about a donation system for helping open source projects get paid for their work.
Why would this be irony? If anything it's irony that they're offering a for profit service to facilitate donations vs adding themselves as a donor recipient on their platform.
No, the idea of having a simple payments system for open source devs to use to get paid for their "free" software should be "free". Let the merit of the software dictate. That's the whole point of open source. To build things freely and openly to make the best possible software that we (humans) can make. We should also expect the same in the tools we rely on to do that work. It's not a hard ask. It's a philosophy of not wanting a corporation to own the keys and profit from others work. Stripe already takes 2.9%+. I don't want someone else taking 10%-30%. Then I have to give the government 30%.
> Thanks.dev presently supports itself through a voluntary tip percentage that, if more than zero, gets deducted from donation amounts along with a Stripe payment processing fee prior to distribution.
I also think they should allow manual addition of projects. E.g. I use Syncthing but that won't be found in my Github/Gitlab scans. I can donate via Github too but would be easier if I can have one place to control all such donations.
My Name is Armin Nehzat (aka armini), my brother is Ali Nehzat (aka qwerki). Feel free to also look us up on linkedin if that helps. Here's a podcast of my brother talking about how he started the project https://podcast.sustainoss.org/148
Sponsors have a slider that allows them to adjust their tip from 5% to 100% of their monthly donation. We figured minimum 5% would cover our compute & merchant fees but left it to the community to decide what we should get. We thought this was the most aligned approach with open source. Totally open to other ideas and suggestions though.
I work for a > 100 people company where the business model is entirely based on donations. We are using stripe for payment and it costs us money, but you can still use our service freely if you want to.
I agree it is not simple, but it proves it is doable.
Absolutely appreciate & respect your perspective. We're passionate about making open source sustainable & understand that there can be multiple ways of achieving this goal. The more ways money is channeled to the community the better...
I think it would be easier to defend taking a cut if the cut was calculated in the same way as for the dependencies, e.g. next.dev being automatically added to the list.
For every OpenSource project I donate to, I check, whether they provide a SEPA IBAN, then I just set up a monthly transfer of a small amount that I can afford instead of a bigger single donation.
Whenever possible, I try to avoid any instances in-between which take some % of the cake.
There is some overhead in collecting money. When you use a charge card a small percentage goes to the credit card and processing companies.
There are some gas stations in Massachusetts that have a slightly lower cash price because they don’t have to pay that fees and pass along the savings. Most businesses nowadays just fold that fee into the price.
If they are upfront about how much I’m ok with it. Otherwise you can send a check, but no one is using that option.
The service also completely blocks VPN users with a 403. That seems like blocking a pretty good chunk of your target audience to me. I will absolutely be looking elsewhere to support projects I benefit from.
People will sign praise your work, tell you how much they depend on it, and how it changed their lives. Others will ask you tricky questions that really ought to be asked to a lawyer.
...and they still won't donate a cent. I get about 70 cents per thousand unique visitors. About one in every 14,000 visitors donate. Affiliate income is roughly 100 times that without trying.
Let me put it differently: with the same traffic, donations barely cover my groceries, and affiliate income is a comfortable salary.
I'm at peace with that. I make free things for a reason. It's just something to keep in mind when suggesting donations as a business model. Doubly so as an alternative to ads.
Another tidbit: praise people who create the things you use. It feels so good to know that people use and love the fruits of your labour. I've become lavish in my praise after experience the effects of it.
I think the main obstacle to donations, even for those who _would_ wish to donate, is the fact that it requires a premeditated process (e.g. going to the project homepage to donate) or that it makes the request _before_ the user had a chance to realize how useful it is, rather than after.
If instead there is some way to capitalize the timing of the user experiencing "wow this makes my life so much easier!" to remind them with a low-friction shortcut to make a donation, this short-circuits the cognitive process that previously require the user's mind to go out of its way to invoke their "oh, I should probably donate" sense of reciprocity.
As reviled as impulse-driven microtransactions are, I think there is much for open-source projects to learn from and wield in an ethical manner.
Right now it seems there is a false dichotomy between being either [be unethical and leverage user impulse] or [be ethical and off-putting to the user].
There is no reason why an understanding of the psychology in friction-reduction can be utilized ethically to encourage "impulse-reciprocity".
A model that might be worth analyzing is the streamer-donation UX flow -- yes it can be used irresponsibly to encourage parasocial obsession, but in the hands of the responsible it is a facilitation of healthy engagements with the audience
My tip jar is in my email signature, which means it's part of the answer people get when they request free support from me. It's also at the end of the content they consume from my website.
Depends how you present it. The Ubuntu download page used to punch you in the face asking for donations. They also tried sliders, asking downloaders to choose how to spend the money they donated. These were super successful. People felt in control of how their money was spent. There was no way for them to check in on that, it was a trust process. But the net result was a lot of people donated a very significant amount of money.
Similarly I understand (from an interview with the developer) that the eBook software Calibre gets a significant number of donations from users via the giant donate button in the toolbar.
I do agree, having a "tip jar" option for donations is rarely as successful as the above methods though. Not diminishing your personal experience. Just saying it's possible to change the way things are done, and get more.
Tipping in the real world is easy. You just leave some of the money you have on you. Tipping online is a far more deliberate process, unless you're already processing payments.
Thanks for sharing your experience & insight. You’re observations are similar to our experience. We as a community could always do a better job recognising & rewarding each other.
I use affiliate links for the products I mention in my guides. There is no promotion beyond "if you need this service I just talked about, these options exist in your language".
If I actually pitched products, I'd make even more.
I have no insight but I could imagine that GitHub are going to offer something similar based on that data at some point in the future.
For us the "top" developers on that page are people with 150+ repos that we depend on that I have never head of before. It turns out that they are all tiny JavaScript libraries that we depend on in some repository that's not part of our real product.
I'm happy to sponsor them as well but it'd be cents not euros per month compared to libraries that do the "heavy lifting" for us. At the moment we hand-pick things, also not ideal.
All of that text to say: This is a hard problem, I have no idea how to solve it but I applaud you and everyone who's giving it a shot.
A 5% flat fee is too much for me though, if it had a cap then it'd be different.
Same here, that list from github is close to useless.
In some cases we depend on a library indirectly, because we use a wrapper to match it to our stack. An old school example is we use bower, and want to use the uglify library. Someone has made an uglify-for-bower wrapper, that's like 20 lines of code, so we depend on that. But all the meat, and where I would like the money to go, is the uglify maintainers, one level down.
I'm not saying those people making the wrappers haven't brought us some value. But it's less than the underlying library.
Github falls prey to this. My guess is thanks.dev also would? But at least it has a "boosting" option, I just don't want sindresorhus to scoop up all the money...
That doesn't stop us from sponsoring some projects, it's just a manual process and having this automated would be great. Not sure if thanks.dev can do it but at the moment I'd probably like to exclude the whole JavaScript ecosystem and just include one or two libraries that I _know_ we're using.
And I'd like a similar thing as thanks.dev but for non-code-dependencies. Let's say our devs are using Kubernetes, Kind, Visual Studio Code, VLC etc. - they are not dependencies of our code but it'd be good to have those sponsorships also managed in a single place.
There may even be some use in having a standard format to define those kind of things so they can be machine readable. i.e. I'd like a repo that contains a file with the tools we rely on that can then be used for sponsorship purposes. Like a SBOM for internal tooling.
If you have the time, we’d love to connect with you on our discord & learn more about your experience. It’s a hard problem & that needs a strong open community. Given the recent PayPal incident, I don’t think GitHub should be the only solution.
I do see your point but in this case _everyone_ pays the 5% even though the payout only happens once per project and the payment also only happens once per person donating.
It might be that it is this expensive to run, I don't know. It just seems unfair to me that the platform would get 5% and "only" 95% are distributed to the projects. I do understand that everyone has a different definition of "fair" and I also don't know what I'd be willing to spend. It's something I'd need to think about.
Letting Microsoft GitHub try to monopolize laterally in the developer space by doing funding is going to lead to further lock-in for folks down the line. I’d be wary of supporting them with a chunk of your donation.
At first I thought "Oh another Patreon/Open Collective" but actually this is kinda neat in how it works.
Slightly offtopic, but every month when my Patreon donations get processed Patreon sends me this STUPID email with "Tweet your receipt!"
Honestly, it's so pathetic. It's like giving food to a homeless person while filming it so I can post it on Twitter.
Yes I realise it's an option and I don't have to (nor do I) click it.
I love and support this idea very much. I had actually been thinking about this exact solution myself, but I'd personally want to stay clear of anything involving real money, so it's great that you're doing it. :)
Just a note which probably isn't worth your time to act on, but using this service as a maintainer in Finland is illegal unless you can offer a geoblocking feature that can block any Finnish supporters from routing money to Finnish maintainers. This is due to our Money Collection Act which prohibits soliciting any donations except for very strict circumstances which aren't really applicable here. Might be worth a note on the page if you have extra time, since this is not know by many Finns that I've talked to.
Not sure if you're assuming that I am using the service with the wording "for you" or if it's a general question (I'm not a user). But if it's a general question, legally speaking, my best guess (not a lawyer) is that it would be perfectly legal to make a maintainer account to forward the funds to other projects, since you are not receiving anything. I guess you know if a feature like that is worth the trouble to implement.
So it looks like the idea is it goes through your GitHub dependencies, and splits your donation up among them.
That’s a pretty neat idea.
I wonder if it would be possible or even desirable to try and get some automatic measure of “how much” you depend on a given project, to weigh the split. Probably that would be really difficult to capture. Anyway the current idea is already pretty cool.
Not automatic, but it already supports a measure of "how much" you depend on a project: boosting. You can boost dependencies up or down by up to a factor of 20 (e^3).
Regarding the post generally, using the problem of “how should I re-distribute my donations” to help solve the problem of “am I actually willing to be part of your software supply chain or am I just a hobbyist project, good luck using my code” seems like a nice way of hitting two birds with one stone.
Re gaming the system you're totally right. Although slightly unintuitive, we've also heard the opposite from maintainers. That they'll be motivated to remove the silly one line packages from their dependency trees due to the imbalance of value they provide vs extract.
We also prune self dependencies, circular dependencies and a few other cases to keep things level. Hopefully we'll be at a stage to open source our codebase soon and can better leverage community feedback in this space :)
You're absolutely right. When you login you can actually see a list of dependencies & make your own adjustments. While thanks.dev makes a recommendation based on what's analysed, sponsors are able to boost or exclude beyond our recommendations. It's not perfect & has a lot of room to improve but we hope it's a good starting point :)
One thing that I haven't seen addressed here or in the FAQ is:
What happens to donations towards dependencies where the maintainer / organization / group of maintainers is not registered at thanks.dev?
The FAQ has a section titled "What happens if I don’t claim my balance?", but I think this only applies to people registered at thanks.dev.
I'm not even sure that thanks.dev would be able to reliably contact developers that / maintainers in all (most ?) situations.
great observation & questions, we will update that on our FAQ shortly. If users aren't registered then we can't verify who's project admin & no funds will be allocated to them from the sponsors pool. Only when an admin register then we can allocate funds.
If I decided to sponsor my project's dependencies with say 100 USD and none of the developers are registered with thanks.dev – which seems like a reasonable assumption, especially as thanks.dev appears to be a young project – I wonder what happens with the money.
The money can't be allocated.
Does thanks.dev just keep it? Is it "stored" until it can be allocated?
And if this is the case: From the information on allocation it seems that all of the money will be distributed between all eligible developers (possibly 3 months after devs don't claim their balance)?
If so, what if there is only one (transitive) dependency that is registered with thanks.dev?
Readit News
This implementation is clearly for-profit. I want to directly tip open source projects using a system that doesn't involve other third parties taking a significant cut.
There is absolutely nothing wrong with charging a fee for a service, but there is something wrong with lying about it.
Agreed, but percentage-based fees can quickly become an unfairly large part of payments. I love the idea of this project, but I'd prefer there to be a 5% or X dollars minimum, so that if 5% is more than X dollars, then it doesn't force 5% minimum. If I'm donating $500 to 45 projects, then each project on an even split is getting $11, but thanks.dev is getting $25 even though their service isn't actually in use by my app/service. Seems unfair to me.
https://en.liberapay.com/
The platform itself is also a project on the platform, where the donation happens
https://en.liberapay.com/Liberapay
GitHub sponsors isn't too bad, they take a 3% cut (and the CC takes another 3%). But you're effectively donating to Microsoft, which feels icky.
> Thanks.dev presently supports itself through a voluntary tip percentage that, if more than zero, gets deducted from donation amounts along with a Stripe payment processing fee prior to distribution.
I also think they should allow manual addition of projects. E.g. I use Syncthing but that won't be found in my Github/Gitlab scans. I can donate via Github too but would be easier if I can have one place to control all such donations.
[0]: https://www.theregister.com/2023/04/07/thanksdev_open_source...
I'm seeing comments from two separate accounts, but when you look at their about, they seem to be the same person:
https://news.ycombinator.com/user?id=qwerkihttps://news.ycombinator.com/user?id=armini
Sponsors have a slider that allows them to adjust their tip from 5% to 100% of their monthly donation. We figured minimum 5% would cover our compute & merchant fees but left it to the community to decide what we should get. We thought this was the most aligned approach with open source. Totally open to other ideas and suggestions though.
I agree it is not simple, but it proves it is doable.
Nothing stops you there to put 100% into one of those and 0% on the others.
There are some gas stations in Massachusetts that have a slightly lower cash price because they don’t have to pay that fees and pass along the savings. Most businesses nowadays just fold that fee into the price.
If they are upfront about how much I’m ok with it. Otherwise you can send a check, but no one is using that option.
tea.xyz will not have fees once it goes live with its funding protocol for open-source software.
People will sign praise your work, tell you how much they depend on it, and how it changed their lives. Others will ask you tricky questions that really ought to be asked to a lawyer.
...and they still won't donate a cent. I get about 70 cents per thousand unique visitors. About one in every 14,000 visitors donate. Affiliate income is roughly 100 times that without trying.
Let me put it differently: with the same traffic, donations barely cover my groceries, and affiliate income is a comfortable salary.
I'm at peace with that. I make free things for a reason. It's just something to keep in mind when suggesting donations as a business model. Doubly so as an alternative to ads.
Another tidbit: praise people who create the things you use. It feels so good to know that people use and love the fruits of your labour. I've become lavish in my praise after experience the effects of it.
If instead there is some way to capitalize the timing of the user experiencing "wow this makes my life so much easier!" to remind them with a low-friction shortcut to make a donation, this short-circuits the cognitive process that previously require the user's mind to go out of its way to invoke their "oh, I should probably donate" sense of reciprocity.
As reviled as impulse-driven microtransactions are, I think there is much for open-source projects to learn from and wield in an ethical manner.
Right now it seems there is a false dichotomy between being either [be unethical and leverage user impulse] or [be ethical and off-putting to the user].
There is no reason why an understanding of the psychology in friction-reduction can be utilized ethically to encourage "impulse-reciprocity".
A model that might be worth analyzing is the streamer-donation UX flow -- yes it can be used irresponsibly to encourage parasocial obsession, but in the hands of the responsible it is a facilitation of healthy engagements with the audience
Similarly I understand (from an interview with the developer) that the eBook software Calibre gets a significant number of donations from users via the giant donate button in the toolbar.
I do agree, having a "tip jar" option for donations is rarely as successful as the above methods though. Not diminishing your personal experience. Just saying it's possible to change the way things are done, and get more.
If I didn't care about user experience, I could earn more from donations, but I could also earn much more from affiliate links.
As it is, I just list a few options when I happen to mention a products. There is a tip jar at the end of every guide, and in my email signature.
Tipping in the real world is easy. You just leave some of the money you have on you. Tipping online is a far more deliberate process, unless you're already processing payments.
If I actually pitched products, I'd make even more.
I have no insight but I could imagine that GitHub are going to offer something similar based on that data at some point in the future.
For us the "top" developers on that page are people with 150+ repos that we depend on that I have never head of before. It turns out that they are all tiny JavaScript libraries that we depend on in some repository that's not part of our real product.
I'm happy to sponsor them as well but it'd be cents not euros per month compared to libraries that do the "heavy lifting" for us. At the moment we hand-pick things, also not ideal.
All of that text to say: This is a hard problem, I have no idea how to solve it but I applaud you and everyone who's giving it a shot.
A 5% flat fee is too much for me though, if it had a cap then it'd be different.
In some cases we depend on a library indirectly, because we use a wrapper to match it to our stack. An old school example is we use bower, and want to use the uglify library. Someone has made an uglify-for-bower wrapper, that's like 20 lines of code, so we depend on that. But all the meat, and where I would like the money to go, is the uglify maintainers, one level down.
I'm not saying those people making the wrappers haven't brought us some value. But it's less than the underlying library.
Github falls prey to this. My guess is thanks.dev also would? But at least it has a "boosting" option, I just don't want sindresorhus to scoop up all the money...
That doesn't stop us from sponsoring some projects, it's just a manual process and having this automated would be great. Not sure if thanks.dev can do it but at the moment I'd probably like to exclude the whole JavaScript ecosystem and just include one or two libraries that I _know_ we're using.
And I'd like a similar thing as thanks.dev but for non-code-dependencies. Let's say our devs are using Kubernetes, Kind, Visual Studio Code, VLC etc. - they are not dependencies of our code but it'd be good to have those sponsorships also managed in a single place.
There may even be some use in having a standard format to define those kind of things so they can be machine readable. i.e. I'd like a repo that contains a file with the tools we rely on that can then be used for sponsorship purposes. Like a SBOM for internal tooling.
It can't have a cap if payment gateway processing fees are percentage-based.
"A payment processing fee of 0.5% + 0.20c is collected on the total donation. We take an additional fee of 4.5%, up to a maximum of $10"
There, done.
It might be that it is this expensive to run, I don't know. It just seems unfair to me that the platform would get 5% and "only" 95% are distributed to the projects. I do understand that everyone has a different definition of "fair" and I also don't know what I'd be willing to spend. It's something I'd need to think about.
Deleted Comment
Slightly offtopic, but every month when my Patreon donations get processed Patreon sends me this STUPID email with "Tweet your receipt!" Honestly, it's so pathetic. It's like giving food to a homeless person while filming it so I can post it on Twitter.
Yes I realise it's an option and I don't have to (nor do I) click it.
Just a note which probably isn't worth your time to act on, but using this service as a maintainer in Finland is illegal unless you can offer a geoblocking feature that can block any Finnish supporters from routing money to Finnish maintainers. This is due to our Money Collection Act which prohibits soliciting any donations except for very strict circumstances which aren't really applicable here. Might be worth a note on the page if you have extra time, since this is not know by many Finns that I've talked to.
That’s a pretty neat idea.
I wonder if it would be possible or even desirable to try and get some automatic measure of “how much” you depend on a given project, to weigh the split. Probably that would be really difficult to capture. Anyway the current idea is already pretty cool.
The formula is explained in https://thanks.dev/static/how.
If this takes off people will be inventivized to make lots of small dependencies that are likely to be needed in tier 1 (or tier 2).
The trick will be to find a bug in a first dep of webpack for example, fork it and fix some bugs there then convince webpack to switch to you.
Algorithmic decisions can be gamed.
I suggest instead the app lists the deps, and you choose how much to give each one.
Re gaming the system you're totally right. Although slightly unintuitive, we've also heard the opposite from maintainers. That they'll be motivated to remove the silly one line packages from their dependency trees due to the imbalance of value they provide vs extract.
We also prune self dependencies, circular dependencies and a few other cases to keep things level. Hopefully we'll be at a stage to open source our codebase soon and can better leverage community feedback in this space :)
The FAQ has a section titled "What happens if I don’t claim my balance?", but I think this only applies to people registered at thanks.dev. I'm not even sure that thanks.dev would be able to reliably contact developers that / maintainers in all (most ?) situations.
If I decided to sponsor my project's dependencies with say 100 USD and none of the developers are registered with thanks.dev – which seems like a reasonable assumption, especially as thanks.dev appears to be a young project – I wonder what happens with the money. The money can't be allocated.
Does thanks.dev just keep it? Is it "stored" until it can be allocated? And if this is the case: From the information on allocation it seems that all of the money will be distributed between all eligible developers (possibly 3 months after devs don't claim their balance)? If so, what if there is only one (transitive) dependency that is registered with thanks.dev?