Most Open-Source Money Moves Through Payroll, Not Donations
The public conversation about open-source funding tends to focus on GitHub Sponsors tallies and Tidelift subscriptions — modest, visible, often disappointing. The actual money moves differently. For the most widely deployed infrastructure projects, the dominant funding mechanism is corporate employment: a developer at Google, Red Hat, or Meta whose job description, explicitly or effectively, is to maintain an upstream project that the employer depends on at scale. This arrangement is older than the donation platforms, larger in aggregate, and far less legible to the outside world.
The Linux kernel makes the point most directly. The Linux Foundation's own contributor data, tracked across kernel releases, consistently shows that the majority of commits by volume come from developers employed by companies such as Intel, Red Hat, Google, and Samsung, not from unpaid volunteers. Linus Torvalds himself has been employed since 2003 — first by the Open Source Development Labs, which merged into the Linux Foundation — specifically to steward the kernel. The foundation collects dues from those same corporate beneficiaries and routes a portion back as salaries. It is a circular arrangement, but a functional one.
Red Hat's model is the oldest explicit version of this in the enterprise space. The company, acquired by IBM in 2019, has employed kernel, compiler, and systemd engineers for decades on the explicit understanding that their upstream contributions are the product. Subscription revenue from Red Hat Enterprise Linux funds engineers whose output lands in the kernel, glibc, GCC, and GNOME. The alignment is visible: Red Hat's commercial interests and upstream health point in the same direction as long as the subscription model holds.
Who Employs Whom, and Why It Shifts
Google's open-source employment footprint is broad and deliberately strategic. The company employs engineers who maintain Chromium-adjacent projects, the V8 JavaScript engine, Android's kernel patches, Go, and parts of the Python ecosystem. Several Android and Chrome dependencies have effectively been Google-funded projects for a decade. The company also funds Rust compiler work and has contributed engineering time to OpenSSL since the Heartbleed response in 2014. The motivation is infrastructure reliability at a scale where an unmaintained dependency is an operational risk Google cannot accept.
Meta's approach follows similar logic, concentrated in areas where the company has proprietary bets. Engineers employed by Meta have been primary maintainers of the HHVM project and, after Meta's PHP investment wound down, shifted resources toward PyTorch, React, and parts of the Hack and Flow type systems. The company's open-source employment is a function of product roadmap: engineers move with product priorities, and upstream projects sometimes lose their primary corporate sponsor when Meta's internal direction changes.
This is the structural weakness in employer-funded maintenance. When a company's priorities shift — a product line is cancelled, an acquisition changes the roadmap, a cost-cutting cycle reaches the infrastructure team — the maintenance arrangement can dissolve without announcement. The project does not lose a donor; it loses the person who was doing the work. Daniel Stenberg, who has maintained curl since 1998, has spoken publicly about this dynamic: curl's position is precarious not because it lacks users but because no single employer has a concentrated enough dependency to fund its primary maintainer unconditionally. Wolfssl and JFrog have sponsored Stenberg's time at various points, but the arrangement has always been partial.
The xz incident of March 2024 — CVE-2024-3094, in which a malicious actor spent approximately two years building trust in a project before inserting a backdoor — illustrates the same gap from a different angle. The xz/liblzma project had one primary maintainer and no corporate employer behind it. The social-engineering campaign that preceded the compromise specifically exploited the pressure that comes from being a solo maintainer with no institutional backing: fake accounts created workload and urgency, manufacturing the conditions under which the maintainer would welcome outside help. Andres Freund discovered the compromise at Microsoft — corporate employment on the detection side, not the maintenance side.
The Open Core Complication
The employer-funded model takes a different shape when the employer is the project's own commercial entity. HashiCorp paid engineers to build Terraform, Vault, and Consul under open-source licences for years, then in August 2023 relicensed core products under the Business Source Licence, citing competition from cloud providers who consumed the work without contributing. Elastic made the same calculation in January 2021, moving Elasticsearch to the SSPL before partially reversing course in 2024. Redis Ltd moved Redis to a dual RSALv2/SSPL structure in March 2024; Salvatore Sanfilippo, Redis's original author, had departed the company years before the relicensing.
In each case, the company was the maintainer's employer, and the licence change was the employer asserting control over the terms of that employment's output. The contributor licence agreements — CLAs — signed by outside contributors were the legal instrument that made unilateral relicensing possible. Without them, a project with hundreds of outside contributors cannot be relicensed without consent from each one. With them, the employer holds all the levers.
The Sovereign Tech Fund, backed by Germany's Federal Ministry for Economic Affairs, represents a public-sector attempt to fund maintenance outside the employer-dependency cycle. By mid-2024 it had committed funds to projects including curl, OpenSSH, and parts of the GNU toolchain — filling gaps specifically where corporate employment is absent. The European Commission's Next Generation Internet programme runs a parallel effort. Neither operates at the scale of a Google infrastructure budget, but both are structured to persist through commercial priority shifts.
What the Record Suggests
Corporate employment remains the most reliable source of sustained open-source maintenance for high-traffic infrastructure. The Linux kernel, the GCC toolchain, LLVM, glibc, and the major language runtimes are maintained substantially by employed developers. The risks are real and documented: projects lose maintainers when employer priorities change; single-employer dominance can become a vehicle for relicensing; and projects with diffuse, high-volume use but no concentrated corporate dependency — curl, OpenSSL before Heartbleed, the Apache Commons libraries — tend to fall into the maintainer burnout gap that donation platforms were invented to address.
The funding model for open-source infrastructure is, in practice, a patchwork: large employers funding the projects they depend on most acutely, public-sector funds covering critical gaps, and individual maintainers absorbing the remainder. Donation platforms and foundation grants exist at the margin of this structure, not at its centre.
