When Sentry and a group of co-signers launched the OSS Pledge in late 2023, the premise was simple: companies that use open source at scale commit a fraction of revenue, or a minimum dollar floor, to funding the maintainers of the projects they depend on. The launch press was optimistic and the commentary split sharply — proponents framed it as the first credible attempt to move the "who pays for open source?" conversation from rhetoric to structure, critics dismissed it as symbolic. Six months in, enough data has accumulated to check the intermediate scorecard. Adoption is climbing, the shape of that adoption is more uneven than the launch suggested, and the pledge has moved some things it claimed to move and not others. This post lays out what we can actually see from the outside at the six-month checkpoint.
What does the OSS Pledge actually commit signatories to do?
The pledge asks companies to commit to spending a minimum of $2,000 per developer per year on open source, or 0.1% of revenue, whichever is higher, with the funding directed to projects the company actually depends on. The commitment is voluntary, the enforcement is reputational, and the reporting cadence is annual. Signatories publish their spending levels; the pledge's own site aggregates these. The underlying theory is that once enough visible peers commit, the non-committing peers experience social pressure to match, and the aggregate flow of dollars to maintainers grows.
Who signed in the first six months?
The initial signatory list (as of the May 2024 update) includes Sentry, Astral, Gatsby, Buttondown, and a cohort of smaller developer-tooling companies. Notably absent from the initial list: the hyperscalers (AWS, Google Cloud, Microsoft Azure), the largest SaaS vendors, and most of the Fortune 500. This was not unexpected — the pledge was positioned from launch as a mid-market developer-tooling movement first, with the hope that larger peers would follow over time.
Six months in, the signatory count is in the low dozens. The tier distribution skews heavily toward companies with 50–500 developers; the long tail of smaller companies is mostly unrepresented, and the top tier is mostly absent. Whether this is the intended adoption curve or a plateau is one of the two key open questions.
How much money has actually moved?
From publicly available signatory disclosures, the aggregate annual commitment across signatories is on the order of low single-digit millions of dollars. This is not a small amount of money for most individual maintainers, but it is small relative to the broader open-source economic picture — the estimated market value of open source consumed by US companies is measured in the hundreds of billions annually, and the pledge's committed dollars represent a tiny fraction of that.
The more interesting metric is distribution. Where does the money actually go? Early indications: a mix of GitHub Sponsors individual donations, Open Collective project funding, and Tidelift-channeled corporate subscriptions. A small but growing fraction goes to direct grant programs the signatories have set up. The concentration is uneven — a handful of high-profile projects receive a disproportionate share, while the long tail of smaller critical dependencies remains underfunded even post-pledge.
What is the pledge moving that it claimed to move?
Two things, visibly:
The conversation in boardrooms. Companies of meaningful size are discussing open source funding as a line-item topic. This was not true two years ago. Even companies that have not signed are now fielding internal questions about whether they should.
A normative floor. The $2,000-per-developer number has become a reference point in conversations about "what is a reasonable baseline commitment?" Having a shared numerical anchor is underrated; it converts a fuzzy debate into a specific negotiation.
What is the pledge not moving?
Three things, notably:
Hyperscaler participation. AWS, GCP, and Azure are all extensive open source consumers, and none have signed. The economics of their participation would dwarf the current cohort. Their absence is the single biggest gap in the pledge's impact.
The long-tail funding problem. The dependencies most at risk of abandonment — small-maintainer, high-criticality, low-visibility — are not receiving proportional funding from signatory commitments. Pledge funding flows toward the same already-visible projects that would receive funding under any structure.
Maintainer burnout. Money is a necessary but insufficient fix for maintainer burnout. Several high-profile burnout/resignation events in 2024 illustrated that funding alone does not resolve the structural issues of expectation asymmetry, security pressure, and emotional labor.
What is the realistic trajectory into 2025?
Three plausible paths worth watching:
- Plateau and atrophy. If no major new signatories join by late 2024, the pledge stabilizes as a small-cohort norm without becoming an industry default. Likely if the broader macro funding environment stays cautious.
- Inflection from one hyperscaler. A single major cloud-provider signing would materially change the arithmetic and make the remaining two look conspicuous. Unlikely in the near term but not implausible.
- Structural regulatory pressure. If the EU's Cyber Resilience Act or a US equivalent makes commercial consumers of open source explicitly responsible for its security, funding shifts from voluntary to compelled. This changes the pledge's role from pioneer to reference floor.
The most probable outcome is some mix of the first two, with regulatory pressure arriving on a multi-year lag.
What should security leaders do with this information?
Two concrete actions, one defensive, one offensive:
Defensive: audit your dependency graph for critical single-maintainer projects and evaluate whether your company should be directly funding any of them. The pledge's $2,000 per developer is a reasonable internal reference point even if you do not sign publicly.
Offensive: raise the pledge's norms internally as the baseline for open source funding decisions. The norm exists now; use it to justify spend that would otherwise need to be argued from first principles every time.
How Safeguard Helps
Safeguard helps security leaders identify the right places to direct open source funding by surfacing the maintenance and risk signals that matter: unmaintained critical dependencies, single-maintainer projects in the runtime reachability graph, and license-or-sustainability-risk scores across the dependency tree. Griffin AI produces a ranked list of "if you could fund five things, fund these five" based on the combination of criticality to your runtime and health of the upstream project. The platform's TPRM module also tracks the pledge-adoption status of your software vendors, which is starting to appear in customer questionnaires as a supply chain resilience signal. For teams that want open source funding to be a data-driven decision rather than a goodwill gesture, Safeguard provides the underlying signal.