LIGHT

❯ Free Software Isn't Gratis

Why companies should treat
Open Source as part of their infrastructure

Christopher Tineo SRE @ Palantir Technologies

❯ whoami

Christopher Tineo

SRE · Palantir Technologies

CNCF Ambassador

Kubestronaut

Google Cloud Professional Cloud Architect

GCP Cloud Architect

Google Cloud Professional Cloud DevOps Engineer

GCP Cloud DevOps

Certified Kubernetes Security Specialist

CKS

MCPA

Community

Organizer

Upstream Kubernetes SIG Contributor Experience · Member

The five acts

Problem

The "free" in free software has a price someone pays.

Examples

What it looks like when the bill comes due.

Cost

To companies, to maintainers, to the ecosystem.

Solution

Treat open source like the infrastructure it is.

Action

What you do on Monday morning.

Act 01

The Problem

"Free" has a price. Someone always pays it.

Open source is everywhere

98%

of the 947 commercial codebases Black Duck audited contain open source.

Sources: Black Duck OSSRA 2026, Feb 25 2026

This is the moment to slow down. 98% is the entry point to the whole moral argument: when this much of your stack is OSS, "free" is doing a lot of work in the sentence "free software." Receipt (re-checked 2026-09-26): Black Duck OSSRA 2026 press release (Feb 25, 2026): 947 codebases, open source "appearing in 98% of codebases". Careful: it's the share of codebases that CONTAIN open source, not the share of code that is open source. If you want to make it land harder: ask the room to raise hands if they shipped a service today that didn't depend on at least one OSS package. (No one will raise their hand.) [TIMING: 45s. The 98% stat needs a beat to land. The value numbers are on the next slide.]

Billions to write. Trillions to use.

$4.15B

to write it
once

$8.8T

for companies to replace
the open source they use

Areas to scale: the dot is ~2,100× smaller.

Source: Hoffmann, Nagle & Zhou, "The Value of Open Source Software", HBS WP 24-038, Jan 2024

New slide (design pass, 2026-09-27): the Harvard numbers used to be two stat cards and a quote on the previous slide. Receipts, Harvard HBS WP 24-038 (Jan 2024): - "We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion." Supply side = cost to write that code once. Demand side = what it would cost if every company using it had to rebuild it. - "96% of the demand-side value is created by only 5% of OSS developers." How to read the left side: the square AREAS are to scale. $8.8T is about 2,100 times $4.15B, so the $4.15B square is a dot. Point at it. How to read the right side: same 5% of people, 96% of the value. A handful of people carry the whole ecosystem. It sets up ingress-nginx in the next act. Say it as: "It cost about four billion dollars to write. It's worth almost nine trillion to the companies that use it. And five percent of the people carry nearly all of it." These are model estimates from the paper, not money that changed hands. Say "estimate" if anyone asks. [TIMING: 75s.]

❯ clarification

Free software ≠ Open source

Two overlapping but distinct philosophies. Same code, different why.

Free software

A movement

User freedom as the goal
FSF · 1985 · Richard Stallman
Four freedoms (run, study, modify, share)
License ethos: copyleft

≠

Open source

A methodology

Practical benefits as the goal
OSI · 1998 · Raymond & Perens
10 Open Source Definition criteria
License ethos: copyright

Most projects are both. The difference is the why, not the what.

Sources: FSF, "What is Free Software?" · OSI, The Open Source Definition

This is the intellectual setup for the rest of the talk. Two different terms, two different communities, two different values frames. They overlap on the code (most FLOSS is both), but diverge on the *why*. "Free software" is a moral stance: the user has rights. "Open source" is a practical stance: sharing the code makes better software. Both arrive at similar licenses, but the *conversation* about sustainability differs depending on which camp you came from. The talk title uses "Free Software" deliberately — the moral frame. The "Open source" frame comes in the cost sections. [TIMING: 90s. Don't dwell. Move on to the Stallman slide where the etymology actually lands.]

"Free" as in beer vs "free" as in speech

Portrait of Richard Stallman, founder of the GNU Project and the Free Software Foundation — Richard Stallman, founder of the GNU Project and the Free Software Foundation. His framing of "free software" — meaning freedom, not price — gave us this wordplay. Photo: Ruben Rodriguez, LibrePlanet 2019 · CC BY 4.0 · Wikimedia Commons

Stallman chose "free" to mean freedom (speech), not price (beer).

The English language has only one word for both, causing 40 years of etymological confusion.

This talk is about the gap between them — and who pays for it.

Act 02

The Examples

What it looks like when the bill comes due.

What is ingress-nginx?

The front door to your Kubernetes cluster.

Routes external traffic into your services.
Not built in: Kubernetes ships no default Ingress controller. You pick one.
Maintained by a handful of SIG Network volunteers.

~60% of CERN's Kubernetes deployments relied on ingress-nginx as their ingress controller at the end of 2025.

Project kubernetes/ingress-nginx · Steward Kubernetes SIG Network

Sources: CNCF End User TAB, "Ingress NGINX retirement: Experience from end users", Apr 2 2026 (CERN: "As of the end of 2025 ~60% of deployments rely on ingress-nginx") · kubernetes.io, "Ingress Controllers", checked Sep 30 2026

Set the stage. Ingress NGINX is not an obscure project — it's the default ingress controller most people reach for. By the end of this act, the audience should feel a small jolt of recognition: "I use this. And it's going away." The NGINX logo on the left is a quick visual anchor. Don't dwell on it — the audience knows the logo. The point of the slide is the recognition, not the brand. The bottom panel is the data the audience doesn't have. The "~60% of deployments" stat is CERN's OWN fleet, from CERN's section of the CNCF End User TAB blog post (Apr 2, 2026): "As of the end of 2025 ~60% of deployments rely on ingress-nginx as an ingress controller." Say "at CERN" out loud; it is not an industry-wide number. The industry-wide number is on the Cost slide: the Kubernetes Steering Committee's "about half of cloud native environments." "Not built in": ingress-nginx was never the official Ingress controller, because there isn't one. kubernetes.io (checked Sep 30 2026): "Kubernetes as a project supports and maintains AWS, and GCE ingress controllers." Everything else, 30+ controllers, is listed as third party. People reached for ingress-nginx because of what it could do: dynamic backend config via OpenResty/Lua (which stock NGINX can't do without a reload), extra modules, several balancing algorithms. My opinion, say it as one: "probably the most feature-rich Ingress controller out there." No source for that, so it stays off the slide. [TIMING: 45s. Less is more on this slide. The ~60% at CERN is the takeaway. Let the room absorb it before you advance.]

Critical infrastructure, growing CVE list

~50% of cloud native environments depend on it (Steering, Jan 2026)

41%+ of internet-facing clusters ran it (Wiz, Mar 2025)

6,500+ clusters exposed its admission controller to the internet (Wiz, Mar 2025)

ingress-nginx CVEs by year

2018

2019

2020

2021

2022

2023

2024

2025

2026

critical high medium / low

1 critical CVE-2025-1974, CVSS 9.8: remote code execution through the admission controller.

10 high of 17 CVEs in total. 10 of the 17 landed in 2025–2026, then it was archived.

Sources: GitHub Advisory Database, k8s.io/ingress-nginx, queried Sep 27 2026 · Kubernetes Steering statement, Jan 29 2026 · Wiz Research, IngressNightmare, Mar 24 2025

Rebuilt Sep 27 2026: the date timeline was replaced by bigger adoption cards and a CVE chart. Say the key dates out loud instead: - Nov 11 2025: retirement announced, best-effort until March 2026. - Jan 29 2026: Steering + Security Response statement, "critical infrastructure for about half of cloud native environments." - Mar 19 2026: last release (helm-chart-4.15.1); repo archived Mar 24. - Now: six months with no patches for anyone still running it. Adoption cards: ~50% is the Steering statement (Jan 2026). 41%+ and 6,500+ are Wiz Research, Mar 24 2025, measured when CVE-2025-1974 was disclosed: "over 41% of internet-facing clusters are running Ingress-NGINX"; "over 6,500 clusters, including Fortune 500 companies, that publicly expose vulnerable Kubernetes ingress controllers' admission controllers to the public internet". The 6,500 is only what Wiz could see from the internet, so it's a floor. CVE chart: every GitHub Advisory Database entry for Go package k8s.io/ingress-nginx (gh api advisories?ecosystem=go&affects= k8s.io/ingress-nginx), queried 2026-09-27. 17 CVEs: 1 critical, 10 high, 5 medium, 1 low. Grouped by the year in the CVE ID, because the database's publish dates for the old ones are 2022 backfills. - 2018: CVE-2018-1002104 (medium) - 2020: CVE-2020-8553 (medium) - 2021: CVE-2021-25745 (high), CVE-2021-25748 (medium) - 2022: CVE-2022-4886 (high) - 2023: CVE-2023-5043, CVE-2023-5044 (high; annotation injection, "arbitrary command execution") - 2025: CVE-2025-1974 (critical, 9.8, IngressNightmare RCE), CVE-2025-24514, -1098, -1097 (high, config injection), CVE-2025-24513 (medium) - 2026: CVE-2026-1580, -24512, -4342 (high, config injection), CVE-2026-24513 (low), CVE-2026-24514 (medium) "10 of the 17 landed in 2025–2026": 5 CVEs in 2025 + 5 in 2026. 7 of those 10 are high or critical. [TIMING: 90s. Pause on 2025 and 2026: half the CVEs landed in the project's last 18 months.]

Every feature became someone's upkeep

Issues and pull requests opened per year on kubernetes/ingress-nginx

issues pull requests * 2016 starts Nov 4 (repo created) · 2026 ends at the March archive

Features came in as PRs; the upkeep stayed. 9 of 10 PRs in 2025 came from one maintainer or a bot.

Sources: GitHub search API, repo:kubernetes/ingress-nginx created:<year>, queried Sep 26 2026 (2025 authors: first 1,000 of 1,414 PRs, queried Sep 30 2026) · PR #2794, Jul 27 2018 · kubernetes dev list, Jun 23 2022 · issue #13002, Mar 20 2025

New in revision 2. There is no public dataset of how many production clusters ran ingress-nginx year by year, so don't claim one. This chart is the demand side: every issue and pull request opened on the repo, per calendar year, from the GitHub search API (queried 2026-09-26). Totals (issues / PRs): 2016 52/48 (from Nov 4) · 2017 741/1,021 · 2018 817/927 · 2019 700/558 · 2020 957/870 · 2021 758/624 · 2022 652/721 · 2023 595/731 · 2024 455/1,342 · 2025 319/1,414 · 2026 16/366 (until the March archive). Sum: 14,684 (6,062 issues + 8,622 PRs). Read it as: steady ~1,300–1,800 items a year, for a decade, landing on a team that peaked at six maintainers and spent years at two. Updated Sep 30 2026. Bars are side by side now (the stacked version got misread). The story is features turning into upkeep: - Jul 2018: PR #2794 "enable dynamic backend configuration by default" (release 0.18.0). Backends update through OpenResty/Lua without an NGINX reload, which stock NGINX can't do. First shipped behind --enable-dynamic-configuration in 0.12.0 (Changelog.md); PR #3198 (Oct 2018) made it the only mode. - Jun 23 2022, dev list: "it's time to temporarily pause accepting new features and focus on fixing and stabilizing Ingress NGINX." - Mar 20 2025, pinned issue #13002: "No new features from maintainers". - 2025 PR authors, from the first 1,000 of 1,414 PRs (GitHub search caps results at 1,000): Gacko (maintainer) 565, k8s-infra-cherrypick-robot 245, Dependabot 104 = 914, so "9 of 10". Gacko's titles are mostly chores: "Images: Trigger NGINX build." 219, "Go: Update dependencies." 128, CI 70, Tests 51. Next human author: 11 PRs. 2024 looks the same: cherry-pick robot 529, Gacko 184, Dependabot 115 of 1,000. - So PRs outnumber issues because maintainers and bots opened them to keep the thing patched, not because users sent fixes. The adoption numbers (Wiz 41%+, Steering ~50%) are on the previous slide; this one is only about demand. [TIMING: 60s.]

The humans behind the controller

"We do this in our spare time, and it's becoming hard for us to keep this pace. … we now have to split our time between issues, bug fixing, new feature reviews, and the bugs that may arise from this feature."

James Strong (@strongjz) · ingress-nginx maintainer · kubernetes dev list · Jun 23, 2022

Sources: James Strong, kubernetes dev list, Jun 23 2022 · kubernetes/org#5305, Dec 15 2024

This is the human slide. Rewritten Sep 30 2026: the terminal box is gone (its "we're drowning" was a paraphrase in quote marks, not the maintainers' words), and one verbatim maintainer quote explains what was happening. The quote: James Strong's email to the kubernetes dev list, Jun 23 2022, checked against the Google Groups page on Sep 30 2026. The "…" skips one sentence: "This lack of support becomes a burden to Ingress NGINX maintainers:". The same email goes on: "it's time to temporarily pause accepting new features and focus on fixing and stabilizing Ingress NGINX" (the feature-pause marker on the chart). The highlighted phrase is the previous slide said by a maintainer: every feature becomes upkeep. Say it after the quote (the personal cost, in your voice): two years later, Ricardo Katz (@rikatz) stepped down. kubernetes/org#5305, Dec 15 2024: "I need some time for myself, and I am not really being able to take care of the project and my personal life together :)" The smiley face is what makes it worse. What they actually did, for $0, after hours: triage and review, CVE patching, release management, end-user support. Moved from the removed "Why it collapsed" slide (Sep 27 2026). Four reasons it collapsed, to say out loud if there's time: - CVE overload: a handful of maintainers patching security bugs without compensation (the CVE chart two slides back). - Triage frozen: 50+ issues labeled lifecycle/frozen because the queue became impossible to review. - Replacement abandoned: InGate, the kubernetes-sigs successor with the same maintainer team, shipped and was retired. No volunteers. - Corporate rescue declined: Steering declined a last-minute takeover, citing security trust. @BenTheElder, Jan 21 2026: "Building trust for owning critical software takes time, we needed that to happen years ago during the earlier pleas for support." (kubernetes/ingress-nginx#14178) [TIMING: 60s. Read the quote, pause, advance.]

Act 03

The Cost

To companies. To maintainers. And now, the AI flood.

Cost to companies

direct drop-in replacements
for ingress-nginx.

"None of the available alternatives are direct drop-in replacements. This will require planning and engineering time. Half of you will be affected."
Kubernetes Steering + Security Response Committee · Jan 29, 2026

Sources: Kubernetes Steering + Security Response Committee statement, Jan 29 2026

Cost to maintainers

60%

of open source maintainers
are unpaid for their work

"Nobody has been paying anyone to work on this software for some time, it has been entirely volunteer driven and they've been overwhelmed."
@BenTheElder · Kubernetes Steering Committee · Jan 21, 2026

The cost is the most expensive line item in this talk: time, health, and career impact.

The CVE cascade turned volunteer contributions into a second job with constant security liability.

Sources: Tidelift, 2024 State of the Open Source Maintainer Report · @BenTheElder, kubernetes/ingress-nginx#14178

This is the slide the DevOpsDays audience will feel in their chest. They're the people who would be maintainers if the economics were different. The "60%" number is from the Tidelift 2024 State of the Open Source Maintainer report: "60% of maintainers are (still) not paid for their work", and the share who "have either quit or considered quitting" was also 60%. Say "2024": Tidelift (now part of Sonar) has not published a newer edition. Revision 1 cited ByteIota / It's FOSS, which were re-reporting this same survey. The @BenTheElder quote on the right is the strongest single line in the entire kubernetes.org record. He's on the Steering Committee. The XZ Utils backdoor is what made the Steering Committee decline the last-minute corporate rescue — they didn't want to endorse a maintainer who hadn't gone through the contributor ladder. But the underlying problem was: nobody was paying anyone. The "CVE cascade" line at the bottom connects back to the "Why it collapsed" slide. The maintainers weren't just doing feature work for free — they were doing SECURITY work for free. That's the part that doesn't show up on a procurement report. [TIMING: 60s. The number is the headline. The @BenTheElder quote is the moral. Let the room do the math.]

AI didn't shrink the work. It multiplied the inbox.

GitHub activity per month, as reported by GitHub (each panel has its own scale)

Merged PRs: 25M → 90M+ a month since Jan 2023, about 3.6×.

Sources: GitHub Octoverse 2025, Oct 28 2025 (2024/2025 monthly averages, public repos) · GitHub Blog, Jun 18 2026 (merged PRs, Jan 2023 and 2026) · * Kyle Daigle (GitHub COO), quoted in Latent Space, Jun 2 2026: 275M commits/week in Apr 2026

Three-panel chart (Sep 30 2026, second version). Every number is GitHub's own, all per month: - Octoverse 2025 (Oct 28 2025), table "2024 monthly average / 2025 monthly average": "Code pushes 65M 82.19M", "Pull requests merged 35M 43.2M", and "Pull requests created: +20.4% (47.5M vs 39.5M)". Octoverse says its numbers are public activity unless noted. Also: "pushed nearly 1 billion commits in 2025 (+25.1% YoY)". - GitHub Blog, Jun 18 2026: "In January 2023, developers merged about 25 million pull requests a month across GitHub. Today that number tops 90 million—a roughly 3.6x increase." Note the scope says "across GitHub" (Octoverse says public); GitHub's own labels don't line up, so don't claim open source only. - Kyle Daigle, GitHub COO, quoted on Latent Space (Jun 2 2026): "There were 1 billion commits in 2025. Now, it's 275 million per week, on pace for 14 billion this year if growth remains linear". The ~1.2B/month bar is 275M × 52 / 12, a run rate, not a measured month. Say "run rate" out loud. - No official PRs-opened number for 2026 yet, so that panel stops at 2025. Commits and PRs in the Octoverse table are pushes; the text treats ~1B commits and 82M pushes a month as the same. Each panel has its own scale: compare growth within a panel, not heights across panels. Earlier version of this chart (dropped): GitHub Innovation Graph, human git pushes per quarter, bots excluded: 106.3M (Q2 2021) to 319.8M (Q1 2026), 3.0×, +80% year over year. New in revision 2. Since the June delivery, the AI story flipped from "AI finds bugs" to "AI buries maintainers." curl (Jun 15, 2026): "The curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026." Paused July 1 00:00 CEST, resumed August 3 09:00 CEST. Only vulnerability reports were paused; the issue trackers stayed open. And the line that makes the talk's point for you: "Everyone with a paid support contracts will of course still get full and appropriate service even during this period." (typo is in the original). Paid customers kept service; everyone else waited. Follow-up (Aug 3): "This was possibly our best project decision in a long while." "High-Quality Chaos" (Apr 22): "Recently it's been about double the rate we had through 2025, which already was more than double from previous years." And the reports are GOOD now: "somewhere in the 15-16% range" are confirmed vulnerabilities. The problem isn't slop anymore. It's volume of real work with the same handful of people. GitHub (Jun 18, 2026, Camilla Moraes & Ashley Wolf): "In January 2023, developers merged about 25 million pull requests a month across GitHub. Today that number tops 90 million—a roughly 3.6x increase." Removed from the slide Sep 27 2026, still worth saying if there's time: kernel.org (Aug 29, 2026), "git.kernel.org receives about 6M daily requests"; "legitimate requests are only about 2% of git.kernel.org traffic — everything else are scrapers." https://people.kernel.org/monsieuricon/creepy-crawlies Caveat on 25M → 90M+: that's ALL merged PRs on GitHub (private repos, bots, agents included), not only open source. [TIMING: 90s.]

AI finds bugs faster than volunteers can fix them

Screenshot of Anthropic's Project Glasswing initial update — anthropic.com · "Project Glasswing: An initial update" · May 22, 2026

Anthropic · Project Glasswing

"…some have even asked us to slow down our rate of our disclosures because they need more time to design patches."

75 of the 530 high/critical bugs reported to OSS projects patched at the time of writing

Black Duck OSSRA 2026

Mean vulnerabilities per codebase up 107% to 581. 87% of codebases contain at least one.

Mozilla · with a paid team

423 Firefox security bugs fixed in April 2026, 271 of them found by an AI pipeline.

Patch the Planet · Jun 22

"a firehose of security findings, and already-stretched maintainers must sift through all of it"

Sources: Anthropic, Glasswing update, May 22 2026 · Black Duck OSSRA 2026 · Mozilla Hacks, May 7 2026 · Trail of Bits, Jun 22 2026

Updated in revision 2. In June the headline was "AI finds 10k+ bugs." Four months later the headline is: the fixing didn't scale. Receipts (re-checked 2026-09-26): - Anthropic, "Project Glasswing: An initial update" (May 22, 2026): "several maintainers have told us they're currently severely capacity constrained, and some have even asked us to slow down our rate of our disclosures because they need more time to design patches." And "75 of the 530 high- or critical-severity bugs we've reported have now been patched". Anthropic also donated $2.5M to Alpha-Omega/OpenSSF and $1.5M to the Apache Software Foundation (anthropic.com/glasswing). NOTE: the widely repeated "1,596 vulns / 281 projects / ~6% patched" figures are from a Cloud Security Alliance note, not from Anthropic. Don't use them without citing CSA. - Black Duck blog on OSSRA 2026: "rising 107% to an average of 581 vulnerabilities"; "87% of all audited codebases contained at least one vulnerability". - Mozilla Hacks, May 7, 2026: "We fixed a total of 423 security bugs in releases in April. In addition to the 271 bugs announced two weeks ago…" The contrast: Mozilla has a funded security team to absorb 271 AI-found bugs. A two-person project does not. - Trail of Bits, "Introducing Patch the Planet", Jun 22, 2026: "Frontier models like GPT-5.5-Cyber are producing a firehose of security findings, and already-stretched maintainers must sift through all of it to separate real vulnerabilities from plausible-sounding false positives." Humans triage before maintainers see anything, and patches are included. That's the model to praise. The bottleneck is no longer finding bugs. It's the human capacity to patch, and that capacity is unpaid. [TIMING: 2 minutes.]

One maintainer's token is your production

2026's biggest open-source attacks went through people, not code.

axios MAR 31, 2026

~100Mdownloads a week, backdoored

Social engineering put a RAT on the lead maintainer's PC. It stole the npm login.

trivy-action MAR 19, 2026

76 of 77release tags hijacked

A stolen CI token turned a security scanner into malware.

GitHub MAY 20, 2026

~3,800internal repos accessed

One employee installed a poisoned VS Code extension (Nx Console).

ChainDrop worm AUG 4, 2026

400+npm packages infected

Stolen tokens republished keyv, cache-manager and more.

Sources: axios post-mortem, axios/axios#10636, Apr 2 2026 · Wiz, Mar 31 2026 · GHSA-69fq-xp46-6x23 · GitHub Blog, May 20 2026 · Microsoft Security Blog, Aug 4 2026

Rewritten Sep 30 2026: the four biggest open-source attacks of 2026, each told as project → one number → one line. Every one went through a person or their credential, not a code bug. - axios (Mar 31 2026, no CVE). Post-mortem by maintainer Jason Saayman, axios/axios#10636 (Apr 2): "The attacker gained access to the lead maintainer's PC through a targeted social engineering campaign and RAT malware. This gave them access to the npm account credentials, which they used to publish the malicious versions." Malicious versions 1.14.1 and 0.30.4. Wiz (Mar 31): "present in ~80% of cloud and code environments and downloaded ~100 million times per week"; "observed execution in 3% of affected environments". The post-mortem's own lesson: "Open source maintainers with high-impact packages are active targets for sophisticated social engineering." - trivy-action (CVE-2026-33634, GHSA-69fq-xp46-6x23, CVSS 9.4). Attack live Mar 19–20; advisory published Mar 21. "force-push 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware". Aqua: attackers extracted a privileged access token, and the rotation "was not fully comprehensive". Knock-on: LiteLLM on PyPI (Mar 24): "the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow". - GitHub (May 20 2026, updated May 26; CVE-2026-48027, GHSA-c9j4-9m59-847w for Nx Console 18.95.0). GitHub Blog, Alexis Wales: "a compromise of an employee device involving a poisoned VS Code extension published by a third party." "The attacker's current claims of ~3,800 repositories are directionally consistent with our investigation so far." And: "no evidence of impact to customer information stored outside of GitHub's internal repositories". Chain: TanStack (CVE-2026-45321, May 11, 84 malicious versions across 42 @tanstack packages) leaked an Nx developer's GitHub credentials, which shipped the poisoned Nx Console, which reached a GitHub employee. - ChainDrop (Aug 4 2026), Microsoft Threat Intelligence: "a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others." "Evidence points towards stolen maintainer credentials as the attack vector for initial compromise." Datadog Security Labs (same day) shows the first wave went out through a malicious commit and legitimate OIDC trusted publishing, with genuine provenance: "Some of these npm packages have over 150 million weekly downloads." "Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release" (Microsoft). Dropped from the cards, say if there's time: - Red Hat RHSB-2026-006 (Jun 1): 32 @redhat-cloud-services npm packages, GitHub account "compromised via a VS code extension containing malware". Same pattern as GitHub, smaller victim. - npm's response (GitHub changelog, Sep 3 and Sep 18): staged publishing, stage-only tokens; 2FA-bypass tokens for direct publishing go away Jan 2027. Every maintainer has migration homework. - Contrast, if asked "what about real bugs?": Copy Fail, CVE-2026-31431 (Apr 29), a 9-year-old Linux kernel local root, in CISA KEV May 1. The worst code bug of the year, still not the year's story. [TIMING: 90s. One sentence per card.]

Act 04

The Solution

Stop calling it free. Start treating it like infrastructure.

Open source is critical infrastructure

Dependencies are your infrastructure. Run them like it.

Monitor

OpenSSF Scorecard report for github.com/kubernetes/ingress-nginx: 6.9 overall, generated 2026-03-20, Maintained check 10 — scorecard.dev · ingress-nginx

An SBOM per service (Syft) plus Scorecard and OSV-Scanner in CI.
Also alert on archived and EOL: the last scan still says Maintained 10/10.

Set SLOs

endoflife.date page for Kubernetes showing active and maintenance support end dates per release — endoflife.date · Kubernetes

Critical CVE in a dependency: patched in 7 days.
Nothing past EOL in production. Alert 90 days before.

Staff it

Linux Foundation

hosts CNCF and AAIF

CNCF

Kubernetes, OpenTelemetry

AAIF Agentic AI Foundation

MCP, goose, AGENTS.md

An owner for every tier-1 dependency, with 2 h/week upstream.
Join the foundation behind what you run. These are examples.

Sources: OpenSSF Scorecard, ingress-nginx · endoflife.date, Kubernetes · Linux Foundation, AAIF launch, Dec 9 2025 · CNCF projects · SLO targets are examples

Rebuilt Sep 27 2026 with a real tool for each practice. Walk left to right; each column is something a platform team can start this quarter. None of it is new discipline, it's SRE applied to dependencies. MONITOR. Screenshot: OpenSSF Scorecard viewer for github.com/kubernetes/ingress-nginx, captured Sep 27 2026. Overall 6.9. "Generated at 2026-03-20", four days before the repo was archived (Mar 24), and nothing newer since. It still shows the Maintained check at 10/10. That's the lesson: a health score alone would not have warned you. Alert on archive status and EOL announcements too. Practical stack: an SBOM per service (Syft or CycloneDX), OSV-Scanner or Dependabot/Renovate for CVEs, Scorecard or deps.dev for project health, CHAOSS metrics for maintainer risk. SET SLOs. Screenshot: endoflife.date/kubernetes, "Last updated on 24 September 2026", showing active and maintenance support end dates per release. EOL is a date, so it's alertable. The two SLOs on the slide are EXAMPLES, not an industry standard; say so. Other good ones: nothing more than 12 months or one major version behind; Scorecard at or above 6 and at least 2 active maintainers for tier-1 deps. Use an error budget: when it's spent, dependency work beats feature work. STAFF IT (Sep 30 2026: foundations replaced the Open Source Pledge screenshot). Owners: one per tier-1 dependency, like a service owner. 2 h/week: the Bloomberg OpenTelemetry cohort later in the deck. Then join the foundation that hosts what you run. The three are examples, pick by stack: - Linux Foundation: the umbrella. CNCF and AAIF are both Linux Foundation projects (aaif.io: "a neutral, open foundation under the Linux Foundation"). - CNCF: Kubernetes, OpenTelemetry (cncf.io/projects). Membership prices are on the funding ladder two slides on, don't repeat them here. - AAIF, the Agentic AI Foundation: launched Dec 9 2025 (Linux Foundation press release) with MCP from Anthropic, goose from Block and AGENTS.md from OpenAI. Platinum members: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI. Relevant if your teams build on agents. Open Source Pledge, if asked: companies pay maintainers at least $2,000 per developer per year; members have paid $7,408,535 since launch (opensourcepledge.com/members, Sep 30 2026). An OSPO, even 1-2 people, holds it together. [TIMING: 90s. The pivot should feel like relief, not work.]

❯ new since June

The industry just said it out loud

OpenSSF graphic: We're In: Enterprise Commitment to Sustainable Package Registries, signed by Arm, Datadog, Dell Technologies, Ericsson, GitHub, Google, IBM, Kusari, Microsoft, Red Hat, Rust Foundation and Sonatype — openssf.org · "We're In: Enterprise Commitment to Sustainable Package Registries" · Sep 16, 2026

12 signers commit to pay registry fees based on enterprise use, as a business investment, while keeping access free for individuals and small orgs. Covers PyPI, npm, Maven Central, crates.io, RubyGems, NuGet, Open VSX, Packagist.

OpenSSF · Sep 16, 2026

"…the heroic efforts of small teams, often just two or three people."

1.8 million malicious packages needing human takedown "so far in 2026"

Brian Fox · Sonatype / Maven Central · Jun 16, 2026

"But open does not mean infinite. And free does not mean costless."

Publishing limits + paid "Publisher Pro" tier for commercial scale · enforced Oct 1, 2026

Sources: OpenSSF, Sep 16 2026 · Sonatype, "Sustaining Open Publishing at Commercial Scale", Jun 16 2026

New in revision 2, and the strongest evidence for this whole talk. Ten days ago, twelve organizations, including Google, Microsoft, GitHub, IBM and Red Hat, signed a public statement that package registries are infrastructure enterprises should pay for. That is this talk's thesis, in their words. Receipts: - OpenSSF blog, Sep 16, 2026. Signers: Arm, Datadog, Dell Technologies, Ericsson, GitHub, Google, IBM, Kusari, Microsoft, Red Hat, Rust Foundation, Sonatype. Quotes: registries rely on "the heroic efforts of small teams, often just two or three people." "The number of malicious components that require human analysis and takedown has reached 1.8 million packages so far in 2026". The graphic on the left is OpenSSF's own image from the post. - Sonatype, "Sustaining Open Publishing at Commercial Scale", Brian Fox, Jun 16, 2026: "But open does not mean infinite. And free does not mean costless." Hard enforcement was first set for Aug 11; the Jul 23 update moved it to Oct 1, 2026. Free for community open source; limits aim at commercial-scale publishing. Ask the room: is your company on that list? If not, why not? [TIMING: 2 minutes.]

Small money, measurable results

What 2026's funding programs actually bought.

GitHub Secure OSS Fund

533 CVEs

found and disclosed by 188 funded projects, for $1.88M in total.

OpenSSF Alpha-Omega · OpenSSF

$12.5M

in grants for maintainers hit by AI-found bugs.

Linux Foundation

2–5× ROI

for companies that contribute instead of only consuming.

EU Cyber Resilience Act, since Sep 11 2026: report exploited vulnerabilities within 24 hours. The duty sits with whoever ships the open source.

Sources: GitHub, Aug 13 2026 · OpenSSF, Mar 17 2026 · Linux Foundation, Feb 24 2026 · EU CRA reporting

New in revision 2. The answer to "we don't have budget": the amounts that work are small, and the ROI is published. Receipts: - GitHub, "What 50 open source projects taught us about security in the AI era", Gregg Cochran, Aug 13, 2026: "The Secure Fund invested more than $500,000 across 50 projects", $10,000 each. The 533 CVEs are for ALL participating projects across sessions (188 projects, $1.88M), not just these 50: "Participating projects have identified and disclosed 533 new CVEs". Also "participating and Alumni projects fixed 4,210 CodeQL alerts" in the six months ending July 2026. - OpenSSF press release, Mar 17, 2026: "$12.5 million in total grants from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft, and OpenAI". Earlier than June, but it's the AI labs paying for the mess AI tools created. - Linux Foundation, "ROI for Open Source Software Contribution" (Boysel & Lawson, Feb 2026, 567 responses): "active contribution delivers a 2-5x return on investment"; "Foundation membership stands out with a 4.8x ratio". The private-fork numbers from the same report are on the "fork tax" slide in Act 05. - EU CRA reporting (Commission page, Sep 11, 2026): "As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents". Early warning within 24 hours, notification within 72 hours, final report within 14 days of a fix. Full CRA obligations from Dec 11, 2027. [TIMING: 90s.]

Start where your budget is

Two of the four cost nothing but time. Each has a company already doing it.

01 · Know

Know what you run

Cost: $0, a few hours

An SBOM for every service, plus the forks and patches you carry.

45% of organizations keep private forks (LF, 2026).

02 · Upstream

Upstream your fixes

Cost: $0, your time

Send the patch instead of carrying it.

66% say maintainers respond faster to contributors.

03 · Fund

Fund what you use

Cost: any amount

Small, regular grants to the projects you rely on.

Bloomberg FOSS Fund: $10K grants, ~$320K paid out, e.g. to Let's Encrypt.

04 · Join

Join the foundation

Cost: from $2K a year

A seat where the roadmap is decided.

CNCF Silver from $2K a year. Membership returns 4.8×.

Sources: Linux Foundation, "ROI for Open Source Software Contribution", Feb 2026 · Bloomberg FOSS Contributor Fund, Open Collective, Sep 30 2026 · CNCF membership

Reframed Sep 30 2026 as advice, not a sales pitch: cards are equal height and each carries its cost. Not every company has a budget, and that's fine. Rungs 01 and 02 cost only engineering time, and 02 is time you already spend carrying the patch. Say: "Start with the rung your budget allows. Most of you can do the first two on Monday without asking anyone for money." Funding and foundations are for when you're ready, not a price of admission. Sentry's $750K (below) is in the notes, not on the slide, so the slide doesn't read as "spend big". Receipts (all checked on the source page, Sep 2026): - LF, "ROI for Open Source Software Contribution: Insight from the Open Source ROI Survey and Economic Model", Sam Boysel & Adrienn Lawson, Feb 2026, 567 responses (Oct-Nov 2025). 45% keep private forks. "66% of respondents noted that upstream maintainers respond more quickly to security issues". "Foundation membership stands out with a 4.8x ratio"; membership "increases overall OSS contribution rates by 24% on average". - Rung 02: the Percona story (PR #2315) is told once, on #one-less-fork. Optional aside here: "you'll see mine at the end." - Card 03 example: Bloomberg FOSS Contributor Fund on Open Collective (opencollective.com/bloomberg-foss-fund, Sep 30 2026): "$319,902.13" disbursed, $360,021.98 raised; recent grants of $10,000 to Let's Encrypt and pURL. Bloomberg's own page blocks fetches, so the Open Collective ledger is the public source. - Alternative example, Microsoft FOSS Fund (github.com/microsoft/foss-fund): "Every quarter a new fund and selection process will distribute up to $12,500 USD across one or more open source project(s)." Only employees who contributed to open source get a vote. Running since 2020. Indeed (2019) and Bloomberg (2023, $10K grants) run the same model. - Sentry, Jan 6 2026: $750K to maintainers for 2025, fifth year in a row. The Open Source Pledge ($2,000 per developer per year): members have paid $7,408,535 since launch (opensourcepledge.com/members, Sep 30 2026). - CNCF join page: Silver $2K-$50K a year by company size, Gold $100K, Platinum $350K; "722 CNCF Members" on the counter. [TIMING: 90s. This is the slide they photograph.]

❯ the new reality

The build-vs-buy equation has flipped

AI is driving down development costs, flipping the build-vs-buy equation. Traditional SaaS margins are eroding.

~$1T software market value lost in seven days (Feb 2026)

+10% projected US software developer jobs, 2025–35 (BLS)

OSS is the Engine

We build on open source, and now we must pay our share by contributing fixes upstream.

Case study · previous role at Game Plan Tech

Added GCS Workload Identity support to Percona MongoDB Operator for a federal compliance workload.

Rather than maintaining a private fork, contributing upstream solved it for us and the community.

Sources: "Build vs. Buy Is Dead" (YouTube) · Fortune / Bloomberg, Feb 5 2026 · BLS OOH · percona-server-mongodb-operator#2315

[TIMING: 2 minutes. This is the bridge between the framework and the action. The video argues AI makes build cheaper than buy — but the corollary is that your CUSTOMERS can now use AI to build against your APIs, so the vendor business model breaks. The flip side: we don't write MongoDB operators from scratch, we use Percona's. When we needed a feature (Workload Identity for IL4/FedRAMP), we contributed it upstream as PR #2315. That contribution is how we "pay" for what we use. Same logic as the framework, but grounded in a real example from my own work.] [The two stats are the receipts, both corrected in revision 2: - ~$1T: Bloomberg via Fortune, Feb 5, 2026, on the software sell-off ("SaaSpocalypse"): "the value of those tracked in an iShares ETF has now dropped almost $1 trillion over the past seven days." Revision 1 said "$1T+ in a single month", which was wrong. - +10%: BLS Occupational Outlook Handbook, software developers, page updated Aug 27, 2026: "projected to grow 10 percent from 2025 to 2035". Revision 1 used the older 2024–34 figure (15%). The juxtaposition is the point — software companies bleeding, engineers still hiring.] [The Game Plan Tech example is the concrete instance. IL4 is a federal compliance level where you can't export service account JSON keys. Workload Identity is Google's recommended approach for GKE service-to-service auth. The operator didn't support it. Rather than fork, we contributed it upstream. Every GKE customer got the feature, not just us.]

Act 05

The Action

What you do on Monday morning.

The fork tax

Carrying private forks

5,160 h

of rework every release cycle, just to keep forks building.

86 forks × 60 h each · ≈ $258K at $50/h

At Android scale

18 months from an upstream kernel release to phones.

90% of kernel security bugs were already fixed upstream.

The fix: Upstream First. The patch lands upstream before it ships.

Sources: Linux Foundation, "ROI for Open Source Software Contribution", Feb 2026 (fork questions n=238) · Android GKI docs · ChromeOS, Upstream First

New Sep 27 2026. This is the most realistic argument for the room: you are probably already paying for open source, just in the most expensive way, by carrying patches. Receipts: - LF ROI report (Feb 2026): "On average, an organization maintains 86 private forks … Each … requires 60 labor hours for maintenance and integration per release cycle." 86 × 60 = 5,160 hours. The $258K is the report's own estimate at an assumed $50/hour (Stack Overflow median wage), NOT reported spend. The fork questions had n=238 of the 567 responses. It scales with size: 147 hours for small orgs, 11,152 for orgs over 5,000 employees. Reasons for forking: custom features 54%, internal integration 44%, "security patches or compliance requirements" 37%. Aniszczyk's foreword: "Organizations that rely on internal patches without upstreaming them create private forks leading to technical debt". - Android GKI docs (source.android.com, updated Jun 2026): as much as 50% of kernel code out of tree; "a delay of up to 18 months from the point where an LTS release was available upstream, to when it was in a device"; 90% of the kernel security issues reported in the Android Security Bulletin had already been fixed for devices that stay up to date. - ChromeOS "Upstream First": driver patches must be accepted upstream first. LWN, Sep 2019, Doug Anderson: "We're trying not to do what Android did 10 years ago." Ask the room: how many internal patches does your team carry? [TIMING: 75s.]

❯ what it looks like in practice

Two hours a week

Bloomberg × OpenTelemetry · 2026

70 PRs

merged in 10 weeks by 48 engineers, at 2 hours a week each. Most were first-timers.

94% of participants felt more confident contributing.

up to 2× productivity for firms that pay staff to contribute (Nagle, 2018).

Sources: CNCF blog, Jul 23 2026 · CNCF blog, Mar 31 2026 · Nagle, "Learning by Contributing", Organization Science 2018 (HBS Working Knowledge)

New Sep 27 2026. The realistic answer to "we don't have time": a big company did this with two hours a week per engineer. Receipts: - Alyssa Wright (Bloomberg OSPO), CNCF blog, Jul 23 2026: "48 Bloomberg engineers participated in the initiative. Most had never contributed to open source before." "118 pull requests (PRs) were submitted to the OpenTelemetry project. 70 were merged". "842 volunteer hours were logged by participants". 94% felt more confident, 88% plan to continue. One team built a credential-rotation extension for the Collector to fix a real work problem (still in maintainer review). - CNCF blog, Mar 31 2026: "~2 hours/week per Bloomberg participant" and the stewardship quote on the slide. - Bloomberg also runs a FOSS Contributor Fund (since Jan 2023, $10K grants voted quarterly; Open Collective shows ~$320K disbursed). - Frank Nagle, "Learning by Contributing", Organization Science 29(4), 2018, via HBS Working Knowledge (Sep 5 2018): paying employees to contribute boosts "productivity from using the software by as much as 100 percent, when compared with free-riding competitors." "Up to 2×" on the slide = "as much as 100 percent". Note: Bloomberg's own site blocked our fetches; these numbers are from Bloomberg's posts on the CNCF blog. [TIMING: 60s.]

❯ git log --author=me

A practical example

GitHub pull request percona/percona-server-mongodb-operator #2315, K8SPSMDB-1602: support Workload Identity for GCS backup storage, merged Jun 22, 2026 — github.com · percona/percona-server-mongodb-operator #2315 · merged Jun 22, 2026

67 daysissue to merge

The gap: backups needed a key file that IL4/FedRAMP forbids.

Sources: percona/percona-server-mongodb-operator issue #2314, Apr 16 2026 · PR #2315, merged Jun 22 2026 · screenshot cropped, Sep 30 2026

New Sep 30 2026; slimmed the same day around the PR screenshot. The fork tax at the scale of one engineer. The LF report says 37% of forks exist for "security patches or compliance requirements" (fork-tax notes); this is one that never became a fork. Say the line from the old slide: "Your compliance requirement is probably someone else's too." Receipts: - Issue #2314 opened Apr 16 2026 02:22 UTC; PR #2315 opened 02:52 UTC; merged Jun 22 2026 13:06 UTC. Apr 16 to Jun 22 = 67 days. - PR body: "This is blocking for IL4/FedRAMP environments where exporting service account JSON keys is not permitted." The operator always read credentialsSecret; PBM errored with "clientEmail and privateKey are required for GCS credentials". Fix: an opt-in credentials.workloadIdentity flag, PBM falls back to Application Default Credentials. Includes an e2e test (demand-backup-gcs-workload-identity). - The PR was written with AI assistance (the PR body says so). If asked: a human reviewed it, it shipped with tests, and the maintainers merged it. That's the good version of the story the AI-flood slide warns about. Say: "I could have carried this patch. Instead I opened the issue the same night." Then close. [TIMING: 60s.]

What you do on Monday

Leaders & SRE teams

Count your forks and carried patches. Put the hours next to each one.
Budget 2 hours a week of upstream time, like Bloomberg did.
Pick one foundation or fund for what you run in production.

Individual contributors

Carrying a patch? Open the upstream issue this week.
Turn the fix into a PR. One merged patch is one less fork.
Review someone else's PR. Reviewers are the scarcest resource.

Sources: Linux Foundation, "ROI for Open Source Software Contribution", Feb 2026 · Bloomberg OSPO, CNCF blog, Mar 31 2026

Rewritten Sep 27 2026: the lottery-factor question and the gh/glab and ORT slides were replaced by actions backed by the fork-tax and Bloomberg evidence. Each bullet points back to a slide: - Count your forks: the fork tax (86 forks × 60 hours per release cycle on average). - 2 hours a week: the Bloomberg OpenTelemetry cohort. - One foundation or fund: the ladder (CNCF from $2K a year; LF says membership returns 4.8x). - Reviewers are scarce: Godot Foundation, Jun 30 2026, "This reviewer shortage was already a problem, but it was one that we successfully ignored. We can no longer ignore it." [TIMING: 90s. End on "one merged patch is one less fork."]

Nadia Eghbal speaking at Strange Loop 2017 in front of her slide: 2017, two-thirds of popular projects have just 1-2 maintainers — Nadia Eghbal at Strange Loop 2017 · Photo: Chris Koerner, CC BY-SA 2.0, Wikimedia Commons · cropped

"In order to maintain our pace of progress, we need to invest back into the tools that help us build bigger and better things."

Nadia Eghbal · Roads and Bridges, Ford Foundation, 2016

Thank you · Christopher Tineo

Find me · take the slides

Let's keep in touch

QR code to linkedin.com/in/christopher-tineo

LinkedIn linkedin.com/in/christopher‑tineo

QR code to tineoc.github.io/talks/devopsdays-philly-2026

Slides tineoc.github.io/talks/devopsdays-philly-2026

QR code to k8s.dev/docs/orientation, the Kubernetes New Contributor Orientation

Contribute k8s.dev/docs/orientation

Links: linkedin.com/in/christopher-tineo · tineoc.github.io/talks/devopsdays-philly-2026 · Kubernetes New Contributor Orientation · github.com/TineoC/talks