I run community sites for which I am paid donations to cover running costs including writing code, bug fixes, servers, etc.
Today I take donations via PayPal, but the catch with this is that it's hard to provide visibility to donors of how healthy this is (WRT to costs), and whilst I considered Patreon that seemed to be very focused on creative deliverables to donors of a non-code/service nature.
I am trying Browser Attention Tokens, but these feel to be detached from the delivery of code, and still don't provide enough visibility to the donors of the overall health of the projects.
This though... this could be good. If Github sponsorship were attached to projects and people donated to a given org or repo, and then that were visible "this repo receives $500 per month" it would encourage code contribution whilst providing visibility over the health of a project.
I know my donors would appreciate the visibility (as would I, I manually create periodic reports on income and costs - at least this solves the income side).
The only question I have is how easy it would be for those who don't use Github to subscribe to a recurring donation?
Edit: Signed up for the waitlist, received a link to https://help.github.com/en/articles/about-github-sponsors which appears to clarify that you'd be sponsoring a developer not a repo/org... which means popularity/celebrity is everything. Oh well.
> The only question I have is how easy it would be for those who don’t use Github to subscribe to a recurring donation?
Thanks for the question buro9! All it takes to become a sponsor is an email address and payment method. Our goal is to make sponsorships as friction-free as possible.
Re: individual/repo/org question, GitHub Sponsors is launching small and simple, and as we learn from the initial beta program, we’ll look to expand the ways to participate. One thing we’ve done is put together an advisory panel of open source teams to better understand their unique needs. We’d love to have your voice on the panel, if you’re interested! Send me an email -- devonzuegel@github.com.
> visible "this repo receives $500 per month" it would encourage code contribution whilst providing visibility over the health of a project.
I fear this might snowball. Many people don't donate if they see a project with very small donations. It goes like this: "well, my contribution would not make any difference anyway"...
The reverse is also true: "this guy is OBVIOUSLY doing something right if he gets $500 a month for OSS work, I'll donate!". Yet another example of whales vs. small fish.
As you said in your edit, it will likely encourage celebrity cheering and everybody else won't get a cent as before.
Funny, I act completely opposite to this with respect to Patreon. If I see content that I enjoy is only getting minor donations I'm very likely to donate, even if Patreon sponsorship doesn't get me anything more. On the other hand, if a project has high donations I am unlikely to donate unless sponsorship gets me access to something additional, and even then I am more critical with the decision.
I think GitHub is more like the first scenario. You're already getting the content (code) regardless if you pay for support or not.
I'm curious if, in the long term, GitHub will extend this functionality to integrate benefits: faster support, pay for features, even access to repos for various tiers.
I'm exactly like you but my anecdotal evidence shows that we are the minority.
And yep, I'd like to see those same additional features. One-off small payments instead of a recurring donation is a must as well; many can't afford to donate on a regular basis.
Well what I'd like to do is establish a stack of budgets against a project, e.g. Kickstarter Goals.
$500 p/m = all hosting and domain costs paid for
$750 p/m = we'll use some paid service that makes the service better in some way
$1k p/m = we'll reward contributors $250 p/m distributed across those who contributed to PRs but exact distribution determined by repo admins
And then to have a budget associated to the lowest one being the means for the project to survive... with a running total on that one, showing deficits (because I do have to still cover raw costs and those end up on my credit card the months I fall short, so future months should help recoup that).
In this way, it would be extremely clear what funds a project needs to survive and how donations and support makes a difference.
NB: My projects do fine... we get enough support to be viable. But damn it would be great to not manage it all manually, it's a chore I'd like to give up so I can code more.
I'm sure it's possible to put that info in README.md and handle things according to that month's donation amount.
I don't know that a GitHub-run tier system will suit everyone, when a developer (the primary users of GH, of course) could easily just automate the update of the relevant info in the README or some other relevant document in the repo on a cadence that suits the project and the developer.
Huh? Am I the only one that has exactly the opposite line of thinking? If I see an underfunded project that I enjoy, I’m much more likely to donate than if something already makes many digits money.
The person you replied to tried to highlight why that particular framing a bad metric to highlight in an OSS project.
People respond better to something like:
this repo needs $500/mo to achieve X;
$1000/mo to achieve Y and;
$2000/mo to achieve Z. We have received $200 in funding for this month."
rather than the example given above:
"this repo receives $500 per month"
The first framing emphasizes your needs, the second framing emphasizes your current situation. The first is better because it gives any potential donor actionable information to decide whether you need a donation or not, and more importantly, how much impact their donation will make if they choose to donate.
A donor can make an out-sized impact on a project with a stretch goal of "$2000/mo to achieve Z" that has only received $200 in donor funds by providing the $1800 balance for instance.
Many people who get paid this way prefer the 1% case to the 25% case. It's much more stable. This means if you decide to stop, they only lose 1%, not 25%.
I mean, people are still going to enjoy getting more money, don't get me wrong. But they'd rather have 1000 people giving a dollar than two people giving 500.
Exactly your last. We could all take a page out of the Twitch streamers' books -- they do exactly like this: (a) set donation or subscription goals and (b) make it really cheap and (c) aim for volume.
>If Github can start automatically recognizing dependencies
I think that they already do this for JavaScript, Ruby, and Python dependencies[0]. However I don't think doing it automatically is the way to go, one dependency may be "worth" way more than another, and some dependencies may go undetected (e.g. if I conditionally sneak -lfoo into my LDLIBS somewhere)
Yea, definitely agree about automatically. For me the biggest problem with automatic is, exactly as you said, the worth of varying projects.
I think automatic inclusion would also run the risk of OSS becoming less integrated. Ie, if I include another dependency I risk losing money, incentivizing me to reinvent wheels so long as I have the ability.
Today I take donations via PayPal, but the catch with this is that it's hard to provide visibility to donors of how healthy this is (WRT to costs), and whilst I considered Patreon that seemed to be very focused on creative deliverables to donors of a non-code/service nature.
I am trying Browser Attention Tokens, but these feel to be detached from the delivery of code, and still don't provide enough visibility to the donors of the overall health of the projects.
This though... this could be good. If Github sponsorship were attached to projects and people donated to a given org or repo, and then that were visible "this repo receives $500 per month" it would encourage code contribution whilst providing visibility over the health of a project.
I know my donors would appreciate the visibility (as would I, I manually create periodic reports on income and costs - at least this solves the income side).
The only question I have is how easy it would be for those who don't use Github to subscribe to a recurring donation?
Edit: Signed up for the waitlist, received a link to https://help.github.com/en/articles/about-github-sponsors which appears to clarify that you'd be sponsoring a developer not a repo/org... which means popularity/celebrity is everything. Oh well.