Steward
Sign in

Documentation › Sponsor guides

Sponsor-a-repo

The standard sponsor pattern is "a company pays for Steward on their own repos." Sponsor-a-repo is the second pattern: a company pays for Steward on an Open Source Software (OSS) repo they depend on but don't own. The maintainer keeps maintaining; the sponsor pays.

This doc covers when it makes sense, what each side sees, and the failure modes worth knowing about.

The shape

Acme depends on the widget OSS library. Acme wants its engineers' contributions back to widget to flow through Acme's Single Sign-On (SSO) and to count against Acme's seat allocation. Acme pays for Sponsor-a-repo on widget; widget's maintainer is unaffected.

Two parties, two tenants, one bridge:

  • The sponsor — Acme. Holds the subscription. Manages their org's members + audit + billing on /sponsor/*.
  • The maintainer — widget's owner. Holds the repo. Owns governance.pxf, approves PRs, retains every gate authority.
  • The sponsorship row — the bridge between them. Records who's sponsoring whom, at what tier, since when.

The two tenants never merge. The sponsor doesn't gain write access to the maintainer's repo; the maintainer doesn't gain visibility into the sponsor's org membership.

What the sponsor pays for

Three classes of capability that activate when a sponsorship is live:

  1. Cross-org SSO — Acme members signing in to interact with the widget repo (PR comments, governance editor, contributor reports) authenticate through Acme's OpenID Connect (OIDC) provider rather than via GitHub OAuth. Their identity is federated rather than personal.
  2. Per-org metering — Acme members' Deep Analysis + per-PR scorings against widget count against Acme's daily credit cap, not against widget's. Maintainers love this because they can keep their own subscription small while sponsoring orgs absorb the cost of their members' activity.
  3. Audit visibility — every action by an Acme member on the widget repo lands in Acme's audit log (alongside widget's own audit feed for the maintainer). Two audit destinations, one event — fan-out at write time.

What sponsorship does not give Acme:

  • No governance authority. widget's governance.pxf is the maintainer's file. Sponsors can read it; they can't amend it.
  • No merge authority. Acme members get the same contributor flow as anyone else. The widget maintainer still approves.
  • No access to the maintainer's contributor data. The per-repo contributor list at /app/repos/<id>/contributors belongs to the maintainer.

When this makes sense

Three motivating scenarios:

1. Federated identity on critical dependencies

Your engineers contribute back to a handful of OSS repos weekly. Your security team needs every contribution to flow through your SSO + leave an audit trail in your system. Sponsor-a-repo on the OSS repos closes that loop without asking the maintainer to install your IT stack.

2. Internal cost attribution

Your team's monthly Large Language Model (LLM) credit burn shows up in your /sponsor/usage even when the work happens on someone else's repo. The finance side knows "we spent $X engaging upstream"; the engineering side gets the verdict + reputation gradient on PRs they open against upstream.

3. Lightweight patronage

You want to support a maintainer financially. The repo runs on Steward; sponsoring it pays for upgraded tiers your team benefits from while sending real revenue to the maintainer (via the sponsorship payout — see "Maintainer payout" below). A neat alternative to GitHub Sponsors when the goal is "infrastructure that actually helps."

What each side sees

  • /sponsor/orgs — every sponsorship you hold, sponsored repo
    • tier + monthly amount + your seat count against it.
  • /sponsor/members — member roster + seat-cap badge across every sponsorship you own.
  • /sponsor/usage — per-repo metering breakdown so finance can attribute spend to specific upstream dependencies.
  • /sponsor/audit — events scoped to your sponsorships; per-sponsorship filter in the scope dropdown.
  • /sponsor/billing — invoices + payment method state.

Maintainer side

  • A "Sponsored by Acme Corp (Business tier)" annotation on the repo dashboard at /app/repos/<id>.
  • Aggregate sponsorship signal (count + tier) on the same page — useful for "12 companies depend on this enough to sponsor it" framing in your README or a maintainer blog post.
  • Nothing about who the individual sponsor members are. Their roster is the sponsor's data, not yours.

The maintainer does not need to do anything to receive sponsorships. The first sponsor's subscription activates the flow on the repo automatically.

Maintainer payout

Sponsorships pay the maintainer (minus Steward's platform fee). Configuration lives on the maintainer's account:

  • Default payout method — set on /app/account → Payout.
  • Per-repo split — for multi-maintainer repos, the split ratio is configured on /app/repos/<id> → Sponsorship. Default is 100% to the listed owner.
  • Pause incoming sponsorships — toggle on /app/account → Payout. Existing subscriptions continue; new ones can't start.

The payout cycle is monthly, USD via the same payment provider that handles tier billing. Payouts post about 7 days after the close of each calendar month.

Configuration: there is none

There's no governance.pxf section for sponsor-a-repo. This is deliberate — the model is "sponsor-side configuration

  • maintainer-side opt-in (by accepting payouts)." Bringing sponsorship into governance.pxf would either give the sponsor a configuration hook on the maintainer's file (a governance attack surface) or require a separate config that duplicates state.

The maintainer's only "configuration" is whether they accept payouts and what their split is. No per-sponsor settings, no per-tier hooks.

Tier matrix

The sponsorship tier ladder mirrors the standard tier ladder at Tiers + credits; the sponsor picks a tier when creating the sponsorship and pays its monthly rate.

The headline differences vs the standard pattern:

Tier Standard Sponsor-a-repo
Repo cap Your own repos The sponsored repo (counts as 1 toward your covered total)
Seat cap Your members Same — your members get access via the sponsorship
SSO Business only Business only
Audit Your own events Your members' events on the sponsored repo

A sponsor can hold multiple sponsor-a-repo sponsorships plus a standard subscription simultaneously. Each is a distinct row; each has its own monthly invoice line.

Failure modes + fail-safe

Subscription lapses (failed payment)

The sponsorship enters a grace period (the billing provider's default, typically 7 days). During grace:

  • Business features stay on for the sponsor's members.
  • /sponsor/billing shows a banner.
  • The sponsor's failed-payment retry policy applies.

Post-grace, features downgrade gracefully:

  • SSO sign-in falls back to GitHub OAuth.
  • Metering tables empty for the sponsored repo (the data is retained; the live surface degrades).
  • Retention bundle exports stop.

Nothing data-destructive — the sponsor's accumulated audit events, contributor history, etc. persist. The live-feature surface degrades; the historical record doesn't.

The maintainer keeps the platform's Free-tier features regardless of any sponsorship's state. A sponsor lapse doesn't penalise the repo.

The member loses Business-tier access on the sponsored repo immediately on next sign-in. Their contribution history on the sponsored repo is preserved — that's the maintainer's data, not the sponsor's.

Operator-granted (comp) sponsorships

Steward staff can grant a sponsorship at no cost via StaffService.GrantCompSponsorship. The row carries a comp_source annotation distinguishing it from paid rows; behaviour is identical at the feature level. The only difference is on the billing surface — comp rows show $0 and have no invoice trail.

Used for early-access partners, design partners, and sponsorship-of-record arrangements where the value exchange isn't dollar-denominated.

What this is not

  • Not a way to take governance control of someone's OSS repo by paying. Maintainer retains full control.
  • Not required for an OSS repo to use Steward. Repos run on the platform's Free tier indefinitely; sponsorships add Business-tier features.
  • Not the only way to get an org onto Steward. An org can run a standard subscription on its own repos; sponsor-a-repo is specifically for the cross-org pattern where the buyer and the repo are different tenants.

What's next