One-time payments and custom amounts 🚀

[bdresser]

Thanks for trying out one-time payments and custom amounts! Our hope is that this additional flexibility will help you grow your Sponsors program in creative new ways.

Have any feedback on these two features? Let us know below!

• How easy were one-time payments or custom amounts to find and configure?
• How did you think about pricing your new one-time tiers?
• Is there any additional flexibility you're missing?
• Can you access the data you need from the API?

[terrytangyuan]

Thanks for making these additional options available! I just turned it on for my sponsors page but haven't had any one-time sponsors yet. Here are my questions so far (edited since I’ve had one sponsor so now I know what it looks like):

1. I wonder if there's any plan to categorize the list of sponsors who made one-time or recurring payments.
2. Would it be possible to send email updates only to the selected type(s) of sponsors?
3. Will the badges be displayed on both my sponsor's and my profiles? (edited: yes it will be displayed on both but only for 30 days).
4. Would it be unfair to have one-time sponsors listed on the profile but not sponsors who had been sponsoring for the whole year but cancelled recently (before one-time sponsorship was made available)?
5. It also looks like the badge would only appear for 30 days. What’s the motivation behind it? Would it be better if we can categorize these different types of sponsors and then display them in different ways (e.g. current recurring sponsors, retired recurring sponsors, one-time sponsors) so all types of sponsorships would be appreciated and acknowledged?

[bdresser]

Hi @terrytangyuan! I'm glad you like the feature.

One-time sponsors are basically treated as a recurring sponsor for one month. During that months, they'll have their avatar appear in your list of sponsors, a sponsor badge on their profile, and will receive email updates you send.

We think this is the simplest approach for now, but we definitely recognize the need to distinguish between sponsors at different tiers and different sponsorship lengths as folks grow their programs.

How would you like to see this work? Would you distinguish your sponsors by total value, or by sponsorship length, or something else?

Would it be possible to send email updates only to the selected type(s) of sponsors?

We've also been thinking about how to evolve the email tool. Could you say more about why you'd want to reach out to one subset of your sponsors, rather than the whole group? I have some guesses, but I'd rather hear it from you :)

[terrytangyuan]

How would you like to see this work? Would you distinguish your sponsors by total value, or by sponsorship length, or something else?

Both the total value and length are good options. Making this configurable would be great.

Regarding the email tool, it depends on the type of emails and the frequency I send out.

• I may send an appreciation letter with different content depending on the type of sponsors, e.g. to thank sponsors for their continuous support that have been sponsoring on a regular basis or encourage one-time sponsors to follow my updates on Twitter in case they might want to consider sponsoring regularly when they find out something I plan to work on may benefit their current projects.
• I may send updates more frequently to provide more details on the work I've been doing to recurring sponsors.

Just my two cents though and hopefully this would be helpful. Looking forward to future versions!

[bdresser]

This is helpful! Thank you for the feedback 🙏

[ivelin]

Custom amounts is a great step forward. Thank you!

The announcement email mentions a feature that we've been looking forward to:

• Issue bounties and prioritization

Is there a workflow example how that works with an open issue? There are multiple github actions and apps for bounties, but for some reason I have yet to find one that is stable and reliable. Triaging each discussion between sponsors and contributors who are available and capable to work on a specific issue has been quite distracting. Reliable and reputable automation would be great.

[bdresser]

Hi @ivelin! We've mostly seen this used for issue bounties on a pretty ad-hoc and manual basis so far. Basically, in the conversation on the issue, a funder offers sponsorship in exchange for the issue being resolved on some timeframe.

Sounds like this doesn't help your particular case, since it still requires a manual touch. We're very keen to see how this pattern evolves and aim to build better support into the product this year.

Could you share more about how you'd hope this would work?

• Can anyone put up a bounty? Do they have to specify how much, or do you help them determine how to price the bounty?
• It sounds like you're coordinating across a team. Should bounties be claimed first-come first-serve, or do you want to approve the person who ends up working on it?
• How do you determine success / exit criteria? Specifically, how do you make sure the issue is scoped well enough that the funder is confident they'll get what they're asking for, and the developer knows what they're building? Does this just rely on a thorough issue description?

Open to any other thoughts you have on the topic! This is something I'm really excited about.

[ivelin]

@bdresser thank you for responding. I am not sure why I did not get an email notification about your initial response. Maybe I missed it. But I did get one today with the latest message on this thread. Please see my comments below:

Hi @ivelin! We've mostly seen this used for issue bounties on a pretty ad-hoc and manual basis so far. Basically, in the conversation on the issue, a funder offers sponsorship in exchange for the issue being resolved on some timeframe.

Sounds like this doesn't help your particular case, since it still requires a manual touch.

This would be actually helpful. Usually there are several contributors who are capable to close an issue. However their time availability varies and so does the motivational threshold. It is also common for multiple sponsors to want an issue closed and are willing to contribute some funds towards that.

We're very keen to see how this pattern evolves and aim to build better support into the product this year.

Could you share more about how you'd hope this would work?

What might work well from my experience is a sort of bidding process akin to the flow in fiverr or upwork. In a few bullet points:

• Allow sponsors to stake amounts that they are willing to contribute towards an issue.
• Allow multiple sponsors to stake amounts into a pool for an issue
• Allow contributors to watch and grab a bounty for an issue on a first come first serve basis.
• Contributors who do not have PR merge rights, cannot start work until someone with review rights also joins the bounty.
• The project admin decides whether Contributor and PR Reviewer have to be different people or can be the same person.
• When a contributors grabs a bounty, they have to:
  • Specify what amount from the pool they want to claim.
  • Commit to a timeframe to close the PR.
• Github acts as the escrow agent. It starts the clock and keeps the money until there is a clear resolution.
• Each sponsor is listed as a PR reviewer.
• When a PR is approved by all sponsors and a member of the project who has PR review and merge rights, the payment is released.
• Contributors who work on a bounty are motivated to submit a clean PR that is well tested and documented which will take minimal effort for reviewers to approve. Otherwise the review process may drag on and go to a dispute mode.
• Reviewers don't get paid for the review work. That keeps them focused on the overall success of the project.
• To minimize disputes, issues and PRs should be sliced into the smallest possible scope that ensure quick and clean closure.
• When an issue is disputed, sponsors have the option to extend the timeframe or withdraw their stake from the pool.
• The github user profiles should reflect the ratings for the user in their role as a sponsor or a contributor. For example sponsors can be rated on the total amount paid for bounties and the % of cancelled bounties. Respectively contributors rating could show total $$ earned and % successfully completed bounties. That allows people to choose who they work with based on reputation.

To answer specifically your questions:

• Can anyone put up a bounty? Do they have to specify how much, or do you help them determine how to price the bounty?

Yes. Sponsors stake whatever they are willing to pay towards a bounty pool.
Github pulls into escrow money from sponsors on a pro-rata basis once a contributor grabs a bounty. If two sponsors staked $100 and a contributor agrees to do it for $150 , then $75 is drawn from both sponsors. The reason why a contributor may want to take less than the total amount in the pool is because it gives them room to negotiate the scope of the issue more precisely (in the issue comments thread).

Contributors can start work immediately after grabbing an issue with the respective commitment to payout take and deadline. Contributors who are not confident in their ability to deliver will prefer to clarify scope because taking on an issue and not delivering hurts their reputation.

The money is not actually paid to the contributor until all reviewers approve the PR that closes the issue. If a PR is not approved after the deadline and any potential dispute resolutions, the money from escrow is returned to sponsors.

• It sounds like you're coordinating across a team. Should bounties be claimed first-come first-serve, or do you want to approve the person who ends up working on it?

No need to have a prolonged process with multiple contributors asking to take a bounty. If the issue's scope is well stated and there is a fairly confident contributor available to work on it, things should be quick and simple for everyone: sponsors, project maintainers/admins and contributors.

• How do you determine success / exit criteria? Specifically, how do you make sure the issue is scoped well enough that the funder is confident they'll get what they're asking for, and the developer knows what they're building? Does this just rely on a thorough issue description?

1. Keep issues as small scoped as possible to avoid complications down the line.
2. Break bigger issues into smaller ones. For example a big feature issue can be broken into incremental smaller issues for design docs, then more small issues for implementation sprints.
3. Successfully closed issues improve the reputation for everyone involved. Disputed or cancelled issues hurt the reputation of everyone involved. This motivates everyone to do the best job possible before engaging in a bounty.
4. Github just has to ensure a clean and transparent escrow process. Since everything is open source, including scope discussions, there is little room for ill behavior.

Sorry for the somewhat random bullet points. Hope they are helpful. Happy to discuss and clarify the scope of the issue further :)

Regards,

Ivelin

Open to any other thoughts you have on the topic! This is something I'm really excited about.

[The-Compiler]

• How easy were one-time payments or custom amounts to find and configure?

In the settings, it was trivial to find them. On the public profile, it actually took me a couple of seconds until I found the "monthly / one-time" switch. I'm not sure why, really - perhaps the space is a little bit too cramped with so many things to interact with so I missed it while scanning:

Perhaps having something like "tabs" over the amounts would make it a bit more visible, but not sure how that'd look.

• How did you think about pricing your new one-time tiers?

I've had certain physical rewards planned even before this change (shirts/stickers, though shipping is on hold indefinitely for a while now). For those rewards, I plan to use the total amount a user has donated - so it made sense to have the one-time tiers priced based on those.

• Is there any additional flexibility you're missing?

I think the limit of 10 tiers total is too restrictive now that it's possible to have two different kinds of tiers. Why not allow for 10 recurring plus 10 one-time tiers? I guess the main motivation for the limit is to not have a very long list of tiers to scroll through, but if they are in two different "tabs", I think it'd be useful to allow for 10 each.

• Can you access the data you need from the API?

I mainly use the JSON exports because I find them quite useful to e.g. generate some custom stats. I don't think I've ever gotten a one-time donation so far, but I wonder how those would show up in the JSON. Right now an item there looks like:

  {
    "sponsor_handle": "...",
    "sponsor_profile_name": "...",
    "sponsor_public_email": null,
    "sponsorship_started_on": "2021-04-05T20:05:57.000+02:00",
    "is_public": true,
    "is_yearly": false,
    "transactions": [
      {
        "transaction_id": "...",
        "tier_name": "$5 a month",
        "tier_monthly_amount": "$5.00",
        "processed_amount": "$5.00",
        "is_prorated": false,
        "status": "settled",
        "transaction_date": "2021-04-05T20:06:11.000+02:00"
      }
    ]
  },

[bdresser]

Thank you for the feedback!

[josh-works]

I don't have feedback beyond I'm a huge fan of the flexibility that the one-time sponsorship feature enables!

So, thank you!

I'll inevitably have feedback as I see/experience different use-cases around the one-time sponsorship, but for now, it's exactly what I needed. Thank you @bdresser and the whole team!

[dennisameling]

Hi GitHub team, thanks for adding the option to do one-time payments! One of my sponsors just tried to do a one-time payment on top of their existing monthly donation, but that doesn't seem to be possible just yet. Would you mind considering this for a future iteration of GitHub sponsors? Thanks in advance! 😊

[bdresser]

@dennisameling absolutely! This is on the roadmap. I'll reach out when we have something in beta you can use.

[tbabej]

Hi @bdresser and the rest of the Github team, thanks for the great feature. We'd like to provide the option to do custom amounts, but only for the one-time donations (as our monthly tier page is already crowded enough!).

Currently, it seems that "Enable custom amounts' checkbox applies either to both monthly and one-time donations, or none of them. Would it be possible to decouple this, and enable/disable the custom amounts separately for monthly and one-time donations? Thanks!

[bdresser]

@tbabej this is on the roadmap! We'll follow up here when it ships :)

[bdresser]

Hey @tbabej – we've shipped an improvement that lets you enable custom amounts for either one-time sponsorships, recurring sponsorships, or both. You should see the UI below on the tier builder screen. Let me know if you have any questions or feedback!

[tbabej]

@bdresser Thanks for the headsup. Looks and works great!

[tbabej]

@bdresser I was wondering if you guys have plans to allow the default amount and minimum amount settings to be configurable per one-time and monthly sponsorship types separately?

Currently, I can either set a default/minimum monthly sponsorship amount (i.e. 3$), which is exteremely small for a one-time sponsorship, or I can set it very high (i.e. 50$) for the one time, but it will show up as a default and minimum also for the monthly sponsorships, where it will be in turn very high 😿

[jlord]

That's great feedback @tbabej! I'm going to write it up for us to consider planning for, what you've described definitely makes sense 👍

[ekecso]

Hello!

Thank you for all the hard work you have done on GitHub sponsors! It's been incredibly successful for us over at elementary and we appreciate all of the work that has been put into it. While we've had great success with the recurring monthly tiers, we've had some trouble setting up one-time tiers.

One issue we had (that's already been mentioned by @dennisameling) is allowing our monthly sponsors to add a one-time tier in addition to their monthly tier. It limits the potential one-time tier ideas we have because most people wouldn't want to switch from their monthly tier to the one-time payment because they might lose access to certain perks. This has been the biggest roadblock for us in publishing one-time tiers.

We currently only have one one-time tier published and the issue I have had with it is that the sponsor disappears after that given month. There doesn't seem to be a way to go back and see who was on that tier in a given month, which is essential because it's a high dollar tier and the main perk is getting recognition in our monthly blog post. This isn't necessarily a one-tier issue, either. It would be great to have a way to access previous months to see how many people are subscribed to certain tiers - and who they are when the perk is to give recognition.

A feature I would like to potentially see implemented would be a way to collect shipping addresses and any additional information for specific tiers. We would love to be able to provide exclusive merch (probably at the one-time payment tiers) and we would need shipping addresses in order to fulfill them. Expanding on that, being able to collect additional data like a clothing size, color preference, etc. would be really beneficial. This would also be great for a recurring tier we already have that has a perk for dedicated time from specific developers to work on an issue of their choice. It would be incredibly helpful if there was a way they could easily provide the link to the issue they want investigated when signing up and on a recurring monthly basis.

Thanks again for all of your hard work and hopefully we can get some more one-time tiers published soon!

[The-Compiler]

There doesn't seem to be a way to go back and see who was on that tier in a given month, which is essential because it's a high dollar tier and the main perk is getting recognition in our monthly blog post. This isn't necessarily a one-tier issue, either. It would be great to have a way to access previous months to see how many people are subscribed to certain tiers - and who they are when the perk is to give recognition.

You can get a history of all sponsor changes in the "Activity" page on your sponsors profile. There, you can also export a JSON file of all transactions, to programmatically get whatever information you need. Here's a small script I hacked a while back to get the total sponsorship amount per user:

import sys
import json
import collections
import glob

all_data = []
for filename in glob.glob('*.json'):
    with open(filename, 'r') as f:
        all_data.extend(json.load(f))

amounts = collections.defaultdict(int)

for sponsor in all_data:
    for transaction in sponsor['transactions']:
        status = transaction['status']
        if status != 'settled':
            assert status == 'processor_declined' or status is None, transaction
            continue
        raw_amount = transaction['processed_amount']
        assert raw_amount[0] == '$'
        if not raw_amount.endswith('.00'):
            #assert transaction['is_prorated']
            pass  # FIXME
        amount = int(raw_amount[1:-3])
        amounts[sponsor['sponsor_handle']] += amount
        

for sponsor, amount in sorted(amounts.items(), key=lambda x: x[1], reverse=True):
    print(f'{sponsor}: {amount}')

A feature I would like to potentially see implemented would be a way to collect shipping addresses and any additional information for specific tiers.

I'd love this as well! I try to collect email addresses for sponsors so I can contact them with an external form for those kind of information, but that's a pain. For people who don't have a mail address in their profile, aren't sponsoring anymore (so won't get updates) and don't fill out a quick questionnaire I link on the sponsorship page (asking for username and email), I won't have a way to get their perks to them (or I'll need to track them down one by one).

[jlord]

Thanks so much for writing this up @ekecso, it's really helpful feedback!

We should have good news soon on allowing funders to have concurrent sponsorships of projects i.e. adding a one-time payment while keeping your recurring sponsorship in place ✨

Better sponsor history and required sponsor details for perks is great to see validated here, too, thank you!

[ekecso]

Hey @jlord I was wondering if there has been any update on the concurrent sponsorships of projects. Did I miss the announcement or is it still coming soon? If it hasn't been announced yet, where should I be looking for when it will be announced?

We're really looking forward to this feature!

[jlord]

Hey! Yes, concurrent sponsorships did ship 🎉 There was not an official announcement because it was a smaller tweak to the existing feature but I should have followed up here. Let me know how it goes! ✨

[AGSPhoenix]

As a sponsor, it's not clear to me why developers are able to set a minimum support amount. With my interest being exclusively in monthly support (I'd prefer a set and forget approach that doesn't require my active attention to keep projects alive), developers that ask that I give, for example, $5 per month or don't bother are essentially refusing support from all but a small fraction of their most enthusiastic users.

We all use countless little pieces of OSS every day, and if I sponsored every one of them at those minimums, I'd probably be spending hundreds of dollars every month. I can't afford that, but I'd prefer to give at least a little support to all of them.

Please stop letting developers get in the way of me giving them money.

[AGSPhoenix]

(And before anyone correctly points out that I am currently sponsoring exactly one developer, my last Patreon bill was $34 across 23 creators. I'm trying to branch out to the software side too.)