In October 2021, the maintainer of colors.js and faker.js deliberately sabotaged his own packages, breaking thousands of downstream builds overnight. His public explanation was blunt: he was tired of maintaining infrastructure that "billion dollar corporations" used for free. That single incident became the reference point for a question every security and procurement team now has to answer: who is actually paying the people who write the code your supply chain depends on, and does that funding buy you anything in return?
Three platforms dominate the answer — GitHub Sponsors, Tidelift, and Open Collective. They look similar from a distance (all three move money from companies to maintainers) but they differ sharply in fee structure, payout mechanics, and whether money buys you a security or maintenance guarantee at all. This guide breaks down how each one actually works, with real numbers, so you can decide where your organization's open source funding dollars belong.
What is GitHub Sponsors and how does it actually pay maintainers?
GitHub Sponsors, launched on May 23, 2019, lets any GitHub user or organization set up monthly or one-time sponsorship tiers, and GitHub takes 0% platform fee on top of standard payment processing costs — a policy it made permanent in May 2020 after initially covering processing fees itself for the platform's first year. Money flows directly from sponsor to maintainer, in whatever tier amount the maintainer defines, with no obligation attached: a $10/month sponsor gets whatever perks the maintainer chooses to offer (a badge, a Discord role, early access to a changelog), not a support contract. GitHub briefly ran a Sponsors Matching Fund that matched contributions up to $5,000 per maintainer per year, but that program was discontinued in August 2022 as GitHub Sponsors matured into a self-sustaining marketplace. The catch for buyers: GitHub Sponsors is built for individual generosity, not vendor accountability. There's no SLA, no security disclosure commitment, and no guarantee the maintainer even sees your company's sponsorship as anything more than a tip jar. It's the easiest model to set up and the weakest one to point to during a vendor risk review.
How does Tidelift's subscription model differ from a direct sponsorship?
Tidelift sells a subscription, not a donation — enterprises pay Tidelift directly (historically priced per-developer-seat, commonly cited in the low hundreds of dollars per seat annually) and Tidelift redistributes a share of that revenue to the maintainers of the specific open source packages the subscriber depends on, based on usage data pulled from the customer's manifest files. Founded in 2017 by former Red Hat executives Chip Childers, Jeremy Katz, and Donald Fischer, Tidelift's pitch was always about turning sponsorship into procurement: maintainers who join the "Tidelift Lifter" program agree to specific maintenance commitments — security response within a defined window, license clarity, and a documented release cadence — in exchange for recurring payouts. That structure is why Tidelift reads as a genuine vendor relationship rather than charity: you're buying a documented assurance layer on top of packages like Lodash and Django, not just funding goodwill. Sonar acquired Tidelift in April 2024, folding the maintenance-guarantee model into Sonar's broader code-quality and security portfolio, which signals where the market believes the real value sits — not in the payout itself, but in the compliance and response commitments attached to it.
What makes Open Collective's transparent-budget model different from the other two?
Open Collective, founded in 2015, publishes every transaction publicly — every dollar in and every dollar out is visible on the project's page, down to individual expense line items — and it operates through fiscal hosts (most commonly the Open Source Collective, a 501(c)(6) in the U.S.) that charge roughly a 10% combined host-and-platform fee on funds raised. Rather than sponsoring an individual maintainer, backers fund a project's collective, and the project's admins decide how to spend it: paying contributors, covering CI costs, funding in-person contributor summits, or reimbursing conference travel. Vue.js used Open Collective to raise sponsorship funding that at its peak exceeded $20,000 per month, and Webpack and Babel both ran their core funding through the platform for years. The transparency is the differentiator — a security team evaluating whether a project is financially healthy (a decent proxy for whether it will still be maintained in 18 months) can see the actual budget instead of guessing from a sponsor badge. The tradeoff is that Open Collective funds projects, not maintenance guarantees, so it tells you a project is funded, not that it's secure.
Which model actually pays maintainers the most reliably?
None of the three guarantees reliable pay, but Tidelift comes closest structurally because its payouts are contractually tied to subscription revenue rather than discretionary sponsor mood. GitHub Sponsors and Open Collective both depend on ongoing voluntary contributions that can and do lapse — a maintainer with 50 GitHub sponsors at $5/month loses income the moment even a handful churn, with zero notice period. Tidelift's model smooths this by pooling enterprise subscription revenue across a catalog of packages and distributing it on a defined schedule, which is why maintainers who've spoken publicly about the platform (including Lodash's John-David Dalton in Tidelift's own case studies) describe it as closer to a paycheck than a tip. That said, Tidelift's catalog is curated — it only covers packages enterprises are actively subscribing to use, so an obscure but critical transitive dependency may not qualify at all, and would need GitHub Sponsors or Open Collective to get funded instead.
Does funding a maintainer actually reduce your open source supply chain risk?
Funding reduces risk indirectly, by lowering the odds of maintainer burnout or abandonment, but it does not substitute for verifying what a package actually does. The colors.js/faker.js sabotage in January 2022, the event-stream backdoor injected via a hijacked maintainer account in 2018, and the XZ Utils backdoor discovered in March 2024 — arguably the most serious open source supply chain compromise on record — all happened to packages that had normal-looking maintenance activity. Sponsorship can make a maintainer less likely to walk away or accept help from a bad-faith "contributor," which was explicitly the social-engineering vector in the XZ Utils case, but it does nothing to catch a malicious commit after the fact. Tidelift's model gets closer to a real risk control because its Lifter agreements include security disclosure commitments, but even that is a contractual promise, not a scan. Treat sponsorship as a governance signal you factor into risk scoring, not as a control that replaces SBOM generation, dependency scanning, or provenance verification.
Which sponsorship model should an enterprise fund in 2026?
Fund based on what you're trying to buy: GitHub Sponsors for goodwill and developer-relations budget on packages your engineers personally rely on, Tidelift-style subscriptions when you need a documented maintenance and security-response commitment you can cite in a vendor risk assessment, and Open Collective when you want to fund a project's overall health and can verify that health yourself via its public ledger. Many mature security programs run all three simultaneously against different tiers of their dependency tree — Tidelift dollars against top-20 critical dependencies identified in an SBOM, Open Collective backing for mid-tier infrastructure projects with active public budgets, and ad hoc GitHub Sponsors contributions for smaller utilities a team has come to depend on. The common mistake is treating any of these three as a security control on their own; they are funding mechanisms with different levels of accountability attached, and accountability is not the same thing as verification.
How Safeguard Helps
Sponsorship data tells you whether a maintainer is likely to stick around — it doesn't tell you whether the code they shipped last Tuesday is safe to run. Safeguard sits on the verification side of that gap: it generates and continuously monitors SBOMs across your dependency tree, flags packages with maintainer or funding instability alongside known CVEs and license risk, and gives security teams a single view that combines supply chain health signals (including sponsorship and maintenance activity) with actual vulnerability and provenance data. Instead of manually cross-referencing a package's Tidelift status, Open Collective budget, and CVE history across three different tabs, Safeguard surfaces all three in context, so procurement and AppSec teams can decide not just who to sponsor, but which dependencies need a compensating control regardless of how well-funded they appear. For teams building a defensible open source funding strategy, that combination — funding signal plus verified security posture — is what turns a goodwill line item into an actual risk-reduction decision.