Work in progressOctober 2026Some section links may be broken or include placeholder copy.

Case studies GitHub

Refreshing GitHub Sponsors: from growing pains to an expanded program

Leading the refresh of GitHub Sponsors, the program that lets people and companies financially support open source, to serve both developers and enterprise sponsors and reduce churn.

Client
GitHub
Role
Product Manager and Content Designer
Timeframe
2020
Disciplines
Product management, Content design, UX writing
GitHub's Mona the Octocat holding a pink heart next to the Stripe wordmark, surrounded by confetti.
Service overhaul and content design for GitHub Sponsors, which pays out to open source maintainers through Stripe.

Context

GitHub Sponsors lets anyone financially support open source work directly on GitHub.com. Think Patreon for open source developers.

After the program's initial success, it hit growing pains. The service page was outdated and had to speak to both peer contributors and enterprise-level sponsors. At the same time, the sign-up experience needed to be smoother, better informed, and legally compliant to reduce churn.

The goals were to update the service pages and web presence, including new features and general tax “guidance”; to onboard users with a frictionless experience that showed them where they were in the process; and, as a bonus, to reduce churn and fraud by being clear about what tax guidance we could legally offer and where to add checkpoints that kept bad actors out.

Without much experience in fintech, I partnered with Microsoft’s Fraud and Security team to understand the potential for bad actors and plan processes that kept the program healthy. The program information was outdated and scattered, it had to welcome individual open source contributors and large enterprises alike, and churn is hard to pin down: fixing one part of the problem only goes so far if other issues are left alone.

The work

  • Baselines, feedback, and a roadmap

    I started by establishing baselines for what was working and what wasn’t, with a running discussion for meeting notes so the data could inform our hypotheses and bets. With Stripe, our payments partner, I built a roadmap with check-ins covering user personas and flow mapping, scope and priorities (content updates and reducing churn in onboarding), mockup options, deadlines, and success metrics.

    A GitHub discussion used as a central place for ongoing meeting notes, with a template for each meeting
  • Supporting individuals and organizations

    Individuals need different information than organizations about legal documents and tax information. Mapping how sponsors and sponsored developers or organizations connect, and what matters to each, decided how each experience should be shaped. I worked through these questions with product managers, engineers, developers, data analysts, legal, and other collaborators.

    A diagram of pay-ins from individual and corporate sponsors and pay-outs to sponsored developers and organizations
    A sponsorship summary showing an early adopter discount and a prorated amount due
  • Landing page refresh

    The original Sponsors page was useful for sharing beta information, but it felt generic, without a focused audience or customer evidence. To elevate the design and get people excited about joining, I wrote FOMO-inducing copy and reworked the page so contributors and enterprise sponsors could each find their path.

    Before and after comparison of the GitHub Sponsors landing page and FAQ
    The old Sponsors experience, next to launch messaging such as "Available in 38 regions"
  • Overhauling the waitlist and onboarding

    One of the biggest issues I inherited was why we were seeing so much churn and feedback around onboarding. The sign-up and waitlist left much to be desired, leaving audiences confused about when they could participate and what to do. Addressing those concerns removed the bottleneck and reduced churn.

    The old "Join the waitlist" form next to the new bank account and country of residence fields
    The new onboarding checklist, ending with "Submit application to GitHub Staff for approval"
  • Proration for enterprise

    Setting expectations for fees, payment schedules, and proration was part of the solution for individuals and organizations alike, so people understood what was owed, to whom, and when.

    An organization’s sponsorship checkout with a prorated amount, billing information, and visibility options
  • Customer evidence, and show and tell

    Clarifying who our customers were showed that we needed to serve enterprises and individuals equally. Sharing the work in progress and asking customers for feedback on GitHub Sponsors for companies helped shape the overall program.

    A Sponsors project slide, with a teammate’s message thanking the team for the landing page meeting (name blurred)
    A "[Feedback Wanted] GitHub Sponsors for companies" issue
  • A part of the whole

    After so much change, it was important to share our findings internally and consider how GitHub Sponsors fit with the larger GitHub ecosystem and, further, the Microsoft ecosystem. Collaborating with product managers and others across both companies fed into further Sponsors updates.

    A board of sticky notes grouped into themes such as maintainer tools, issues and contributing, and profile recognition
  • Expanding the program: Malta and Cyprus

    I shipped the program expansion to new regions and announced it on the GitHub Blog, my debut as an author after years of editing the blog. A new welcome email set out the steps to get a Sponsors profile live.

    The "Welcome Malta and Cyprus to GitHub Sponsors" blog post next to the "Welcome to GitHub Sponsors" email
  • Collaborators and hurdles

    I worked with front-end, back-end, and full-stack developers, graphic designers, a service manager, legal, tax and accounting advisors, the Fraud and Security team, and marketing and public relations. The hurdles: many stakeholders with differing priorities, lots of legal and financial implications, scope creep and fast deadlines, and the gap between enterprise and individual open source developers.

Outcomes

  • $100k/yrearned through the program by one maintainer, Caleb Porzio
  • No waitlistremoving it reduced churn
  • Fewer ticketsabout tax guidance, after clear tax information
  • The Sponsors landing page hero, "Invest in the software that powers your world," with a brown octocat holding a heart balloon
    A more inclusive experience. Representation matters for people to see themselves succeeding in a program; now you’re greeted by a brown octocat.
  • A "Getting started with GitHub Sponsors" graphic
    Relaunching the program. After its growing pains, people could experience a more mature program, with information, processes, and a greater opportunity for financial success.
  • The "You’re on the GitHub Sponsored Developers waitlist!" email
    Holistic communications. Our audience knew what to do and when; setting expectations is part of the program’s success.
  • The December 8, 2020 changelog post "GitHub Sponsors for companies now available in beta"
    Expanded support. GitHub Sponsors for companies launched in beta on December 8, 2020.
  • Caleb Porzio’s post "I Just Hit $100k/yr On GitHub Sponsors! (How I Did It)," with a chart of his sponsorship income
    Community earners. Many members earned more after the relaunch.
  • The "Managing billing for GitHub Sponsors" documentation page
    Tax information. Partnering with legal and tax experts, we gave clear, concise tax information without dispensing financial advice.
  • The full refreshed GitHub Sponsors landing page in a browser window
    Customer evidence. Success stories showed corporations, individuals, and teams how to use the program for their own repositories.

Looking back

I learned a significant amount about fraud, financial security for programs, and banking trends on a global scale. Many of my open questions are about how the global majority approaches banking: would “bankless” options have changed the platform we built, and what new concerns would they bring? Questions I want to consider the next time I manage a project like this:

  • Are we seeing results from people who are predisposed to success because of their existing levels of privilege?
  • What would the program look like if we could incorporate bankless options?
  • Ease of use for an enterprise is different from ease of use for an individual, and may need a completely different approach.

Want results like these on your team?

Let’s talk about what you’re building.