After an eventful week in the dotnet open-source ecosystem about, how can it be more sustainable and OSS-developer friendly, I thought I should contribute meaningly to the discussions besides criticisms. So I started thinking about an idea that could help with that. There are many alternative package stores that help developers sell their packages, similar to Gumroad’s model. I did not want it to become another of these stores, as I wanted to target the middle-ground between paid licensing and sponsorships accurately.
What I wanted to achieve is for companies or individuals to purchase a monthly or yearly subscription through an app and provide them with a service: Sponsorship-as-a-Service. It would act like a combination of GitHub Sponsors and NuGet store, but package that into a subscription fee that would be distributed on behalf of the subscriber. Think of how SetApp works: You purchase a subscription and you can download all the apps participated to SetApp. Now think of a donation-powered version of this: Instead of purchasing, the system determine which developer receives a part of your subscription fee, based on your usage.
I know what you're thinking. You think I'm reinventing GitHub Sponsors. I'm not, I'm bridging the idea behind it with NuGet feed. Ideally, this should be implemented by NuGet and become part of the ecosystem, but I don't know what their priorities are and what held them up this long. I also have to admit I haven't looked into Java world or other ecosystems to see if there's already a similar idea implemented or not.)
Enter SponsorFeed
Meet SponsorFeed: A subscription based NuGet-proxy feed for companies to support OSS developers, without compromising their security and their purchase model.
The idea is very straightforward: The OSS developers who already publish their packages to NuGet link both their package feed and Stripe account to SponsorFeed. The customers who want to support OSS but can’t donate directly purchase a monthly or yearly subscription from SponsorFeed and receive a private feed URL which is a proxy for the packages linked to SponsorFeed by their developers. Every month, based on the download statistics calculated by the platform, the amount is split across the linked packages and the money is deposited to the developers’ accounts, through their linked Stripe accounts.
From The Consumer / Subscriber Perspective
From consumers’ perspective, consider SponsorFeed like a donation-based SetApp. You buy the subscription for, let’s say $10, and you receive a private feed URL. You link that feed to all your developers’ machines, your CI builds, anywhere you want within your company or personal use. Let’s say you only used 4 packages that month through the feed, and the usage is like below:
- Package A: 100 times
- Package B: 30 times
- Package C: 60 times
- Package D: 10 times
- Total downloads: 200 times
Based on this monthly usage and your $10 monthly subscription fee, the developers or each receive the following amount at the end of the month:
- Package A: $5 (100 times download / 200 total)
- Package B: $1.5 (30 times download / 200 total)
- Package C: $3 (60 times download / 200 total)
- Package D: $0.5 (10 times download / 200 total)
SponsorFeed is a proxy for NuGet and compatible feeds; it doesn’t keep the packages on the platform, doesn’t alter them in any way. The feeds are also available through their origin NuGet store, so at any time you can cancel your subscription and revert to the original NuGet feed.
The Subscriber Portal would be straightforward: Current subscription and payment history, monthly breakdown of usage, payouts calculated per package based on your subscription fee.
For clients that would consume the packages, it wouldn’t change anything apart from the feed URL. If you make the SponsorFeed your primary feed, your client would try to resolve the packages from it first, then the NuGet feed if failed. This would ensure your donation goes to the developers.
From The Developer / Contributor Perspective
From the OSS developers’ perspective, it’s similar to GitHub Sponsors: You reference your package feed and link your Stripe account. At the end of the month, based on the usage of each subscriber and their fee, your payout is calculated and sent to your Stripe account.
The payout amount for each package is calculated per subscriber, not globally. The idea behind SponsorFeed is not to make it a competition and calculate a monthly leaderboard. It’s based on the usage of each subscriber. If a subscriber pays $10 and only downloads Package A through SponsorFeed, then the Stripe account of Package A receives the $10. If the subscriber downloads 100 packages through SponsorFeed in equal numbers, each package developer receives 10 cents.
The Developer Portal would be simple: A page to see your package registrations, then details on the daily, monthly, yearly statistics. Another page about payment methods, payout history, statistics, etc.
Benefits
As mentioned, SponsorFeed would act as a proxy feed between the NuGet Store and the subscriber. Its whole purpose is to calculate the payouts, nothing fancy or sinister. It wouldn’t modify the packages or wouldn’t store them anywhere, even for caching.
It would also not need to employ any package scanning or feed security, as it would only authenticate the subscriber key to calculate the usage.
I know that some companies use third-party tooling to cache the NuGet store and scan the packages individually for malicious content. That’s fine and compatible with SponsorFeed. Rather than using NuGet Store’s feed URL, you can use SponsorFeed’s URL.
Drawbacks
If the subscriber caches the packages in a company-wide store, that would mean the clients wouldn’t hit SponsorFeed again after the first hit. That could be a problem for developers who don’t release new packages frequently, or if the clients wouldn’t update packages frequently.
Gaps & Questions
- Although this sounds like a nice idea, I have to say I don’t know about anything about how donations and taxes work in each country, even the UK. My knowledge of taxes is limited to my own limited-company experience, so this idea may need some legal help.
- Should SponsorFeed only act as a proxy for developer-registered packages, or the entire NuGet feed?
- Would NuGet store employ any throttling to SponsorFeed?
- How would the taxes work?
- Would SponsorFeed need to be a non-profit company? How would that be managed?
- How would the fee be distributed if the subscriber doesn’t download any packages that month? Same as last month? Yearly average?
Closing Words
Remember, this is not something I already built. This is just an idea, to start some discussions in the right way. I don’t think the whole Moq and SponsorLink shenanigan was the correct way of implementing it, so I thought I should at least throw an idea into the arena, so it would be only fair.
What do you think? Feel free to reach out to me on Twitter/X using my handle @hylegoz to kick off the discussion.