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.