4 ms·

In case you hadn't seen this yet, GitHub offers this service: https://github.com/sponsors/explore https://github.com/sponsors/explore (need to be logged in) I

In case you hadn't seen this yet, GitHub offers this service: https://github.com/sponsors/explore https://github.com/sponsors/explore (need to be logged in) 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.

armini 4y ago
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.
- lars_francke 4y ago
  I just joined. Not sure if I can offer much in terms of solutions, only problems :(
robertlagrant 4y ago
> A 5% flat fee is too much for me though, if it had a cap then it'd be different. It can't have a cap if payment gateway processing fees are percentage-based.
- lars_francke 4y ago
  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.
  - robertlagrant 4y ago
    It doesn't matter whether the payment happens once or multiple times if the processing fee is on a percentage basis.
- TheDong 4y ago
  Of course you can still have a cap. "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.
  - joshuaissac 4y ago
    > A payment processing fee of 0.5% + 0.20c Stripe's payment processing fee is 2.9% + 30¢ in the US.
matsemann 4y ago
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...
- lars_francke 4y ago
  I would guess so as well, yes. 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.
  - matsemann 4y ago
    Yeah, good point on the non-code-dependencies. While most of them I use have some big corporate backing, there's lots of small invisible things running everything getting little attention (like the old openssh story)
toastal 4y ago
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.
- lars_francke 4y ago
  It's better than not funding people at all. I'd like a different ecosystem as well.
- deleted 4y ago
  [deleted]

armini 4y ago

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.

lars_francke 4y ago
I just joined. Not sure if I can offer much in terms of solutions, only problems :(

robertlagrant 4y ago

> A 5% flat fee is too much for me though, if it had a cap then it'd be different. It can't have a cap if payment gateway processing fees are percentage-based.

lars_francke 4y ago
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.
- robertlagrant 4y ago
  It doesn't matter whether the payment happens once or multiple times if the processing fee is on a percentage basis.
TheDong 4y ago
Of course you can still have a cap. "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.
- joshuaissac 4y ago
  > A payment processing fee of 0.5% + 0.20c Stripe's payment processing fee is 2.9% + 30¢ in the US.

matsemann 4y ago

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...

lars_francke 4y ago
I would guess so as well, yes. 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.
- matsemann 4y ago
  Yeah, good point on the non-code-dependencies. While most of them I use have some big corporate backing, there's lots of small invisible things running everything getting little attention (like the old openssh story)

toastal 4y ago

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.

lars_francke 4y ago
It's better than not funding people at all. I'd like a different ecosystem as well.
deleted 4y ago
[deleted]