The hard part of a payments product was never the rail. It was finding the people. For creator payments, they are already gathered: open-source, self-hosted communities with large, established audiences and no built-in way to move money between the people who make the work and the people who value it. Add a payments layer and the whole catalog opens at once: patronage, royalties, pay-per-view, tips, quadratic funding.
You don't have to build the audience or fork the project. Each of these already exposes the webhooks, plugins, and APIs you need to attach payments from the outside.
| Project | What a payment layer unlocks | Stars |
|---|
| immich-app/immich | Licensing and tips paid to the photographer named in the file | 103k |
| TryGhost/Ghost | Paid memberships, subscriptions, and newsletters for writers | 54k |
| jellyfin/jellyfin | Pay-per-view, rentals, or a creator subscription on your own media server | 53k |
| mastodon/mastodon | Patronage and quadratic funding for the posts a community values | 50k |
| discourse/discourse | Paid groups and gated categories for a community's best threads | 47k |
| DIYgod/RSSHub | Paid feeds, and citation tolls when an answer is grounded in a source | 44k |
| navidrome/navidrome | Royalties split by what listeners actually played | 21k |
| chocobozzz/peertube | Per-view or per-second streaming, split across contributors | 15k |
| owncast/owncast | Live tips and pay-to-watch streams | 11k |
| Kareadita/Kavita | Pay-per-book or rentals on a self-hosted reading library | 11k |
and dozens more across music, video, photos, writing, and the fediverse.
And the split is often already written down. beetbox/beets and metabrainz/picard keep track credits and provenance, immich keeps the photographer in the file. Read that graph and attribution metadata becomes the payout rule: every collaborator paid automatically, in the proportions the credits already record. Nanopayments push it furthest, into the per-listen and per-citation cases that were always too small to clear, but the opening is the same everywhere: the users are already here, and no one has been paying them.
Ideas to remix with the RFBs
Not directives or mandates — just starting points to add to or remix with the RFBs. The Distribution Bootstrap for Payments Founders sketches eight of them, in a rough order to deploy.
| The Subsonic-Protocol Scrobble Sidecar: a binary that registers across Subsonic servers, keeps an artist-to-wallet registry, and settles per-listen payments onchain with per-user spending caps. |
| The MusicBrainz Payee Registry: an artist-MBID-to-wallet mapping that handles credit splits using the metadata standards beets and Picard already write. |
| The Owncast Per-Second Streaming Webhook Sidecar: a webhook subscriber that derives viewing duration from join/leave events and settles per-second rates to live streamers. |
| The Jellyfin Per-Minute VOD Sidecar: subscribes to Jellyfin playback events, computes elapsed time per session, and settles per-minute fees to rights holders. |
| The PeerTube Payments Plugin: a maintained plugin for PeerTube's plugin loader supporting multiple payment rails, including onchain and Monero options. |
| The Mastodon Donation-Campaign Provider: an external service that feeds campaign data into Mastodon's new donation-campaigns API, configurable per instance. |
| The LLM Crawler Citation-Toll Layer: per-citation micropayments at the agent boundary that settle to source authors when their work grounds a generated answer. |
| The Settlement Core: portable backend infrastructure handling subscriptions, billing, multi-currency conversion, and transactional emails for all of the above. |
&
