Hey, Devon here. :)

> 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 -- [email protected].

Well feel free to enable my GH account... @buro9 there too (verified by https://keybase.io/buro9 )

> 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 like your tiers idea - optionally you could even make that happen by tying it to the Marketplace. IOW - "Help pay for our <SAAS> subscription!"

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.

Don't get me wrong, I agree.

I was just commenting what I have been witnessing over the years is all.

This logic is strange.

If this repo receives $20 a month, if I donate $5 I'll increase their budget by 1/4, a huge impact.

If this repo receives $500 a month, my $5 will increase their budget by 1%, barely visible.

In practice, it is not strange at all.

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.

I don't disagree. I'm sharing what I have been observing in the past.

It would be really neat if the eventually introduce some type of dependency sharing.

Ie, huge project X built on top of Y and Z show that 30% of donations go to Y and Z.

If Github can start automatically recognizing dependencies it could also incentivize people to "properly" (whatever that means) share donations.

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

[0]: https://github.blog/2017-11-16-introducing-security-alerts-o...

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.

Have you looked at other alternatives like OpenCollective or LiberaPay?

Basically identical to what GitHub is now introducing, but with the nice feature of being open platforms and not seen as loss-leaders for their owner.

LiberaPay seems popular with developers. But Patreon is not unheard of either. The guy that codes Inkscape is on Patreon for instance.