Status: Outline only. Do not publish. Content is intentionally not drafted — this is a structural skeleton with suggested threads, references, and inline examples to slot in during writing.

Working title options

  • The Parallels Between Open Source and Charities (current)
  • Alternatives to consider: The Uncharitable Truth About Open Source (riffs on Pallotta's documentary), Open Source Has a Charity Problem, Why Open Source Is Breaking for the Same Reasons Charity Is

Audience & goal

  • Audience: non-developers first, developers second. Assume readers have never heard the term "open source maintainer" but know what a food bank is.
  • Thesis: OSS and the charity sector suffer from the same structural ailments — under-compensation, a "should be free / should be lean" cultural expectation, volunteer dependency, burnout, and the absence of long-term funding. The fixes look similar too.
  • Tone: journalistic, data-forward, not preachy. Pair an OSS data point with a charity data point wherever possible — don't silo the parallels.

Section flow

1. Hook / Opening

  • Open with a concrete scene the reader can place themselves in (phone, car, TV, banking app) — every one of those things depends on software maintained by a handful of unpaid volunteers.
  • Then the charity parallel: same way you don't think about who keeps the food bank running.
  • Suggested anchor: the 10-year anniversary of the left-pad incident (March 2026) — "ten years ago, one developer deleted 11 lines of code and broke half the internet for a few hours."
  • Thread: consider opening cold with a 2-sentence cURL stat (used by every Internet-using human on Earth) and pivoting to "the man who maintains it doesn't get paid by you, or by Apple, or by Google."

References to slot in

  • https://daniel.haxx.se/blog/2026/03/09/10k-curl-downloads-per-year/
  • https://curl.se/ (the "used daily by virtually every Internet-using human on the globe" line)

2. Setting the stage — two industries, one problem

  • One paragraph framing: this article is about two industries that look unrelated but suffer the same structural failures.
  • Side-by-side framing:
    • Charity sector: critical services, perpetually underfunded, "should be lean," can't pay market salaries.
    • OSS: critical infrastructure, perpetually underfunded, "should be free," can't compensate maintainers.
  • Both are running on the assumption that goodwill is enough. It isn't.
  • Thread: keep this section to ~150 words. Don't oversell — let the rest of the article do the work of proving the parallel.

3. What is open source? (For non-developers)

  • Plain-English definition: source code is publicly readable, freely usable, built collaboratively, mostly by volunteers.
  • Examples the reader has actually used today, even unknowingly:
    • Linux (almost every website, every Android phone, every WiFi router)
    • cURL (every car, TV, printer)
    • Python / JavaScript (the AI products everyone is talking about)
  • The food bank analogy: anyone can walk in and take what they need; most don't think about who stocked the shelves or who paid for the lights.
  • Headline stat: OSS makes up 70-90% of any modern software product.

References to slot in

  • https://www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-open-source-software-application-libraries-the-world-depends-on
  • Thread: include a quick "if all OSS disappeared overnight…" thought experiment — banking, hospitals, air traffic control all rely on Linux.

4. The scale problem — one maintainer, a billion users

  • Anchor: cURL, maintained primarily by one person (Daniel Stenberg), used by effectively every internet-connected device on Earth.
  • Hit the scale stats hard (from Stenberg's March 2026 post):
    • 250,000 tarballs / month
    • 400,000–700,000 Docker pulls / day
    • 32,000 git clones / day
    • Bundled by default on every Windows and macOS install
    • Embedded in countless cars, TVs, printers, games, devices
  • Charity parallel: Food Banks Canada / Feeding America — N million people served, M volunteers, $X budget per person served. Land the ratio: X people served per paid employee vs Y users per paid OSS maintainer.
  • Thread: find a single striking ratio for the headline ("one paid maintainer per N billion installations").

Research TODO

  • [ ] Food Banks Canada 2025 HungerCount stats
  • [ ] Feeding America 2025 annual report (people served, volunteers vs paid staff)
  • [ ] OpenSSF / Tidelift maintainer counts for cURL, OpenSSL, Log4j

5. The pay problem — the "Uncharitable" parallel

This is the section that anchors the whole article. Spend the most time here.

  • Lead with Dan Pallotta's thesis from Uncharitable:
    • The MBA example: someone with an MBA can take a private-sector job, donate the difference between their corporate salary and a charity salary to a charity, get the tax receipt, and still pocket more than they would have made at the charity.
    • The unspoken moral judgement: "charities shouldn't pay big salaries — that money should go to the mission."
  • The exact same dynamic in OSS:
    • Top engineer at Google/Meta total comp: $500K–$2M.
    • Same engineer maintaining a critical OSS dependency full-time: $30–80K if they're lucky, mostly via sponsors / grants / GitHub Sponsors.
    • OpenSSL pre-Heartbleed: ~$9K/year in donations. One full-time-ish maintainer. Protecting two-thirds of the secure web.
    • Tidelift 2024 survey: a third of maintainers aren't paid at all for maintenance work but would like to be.
  • Important caveat to surface (the user's note): there are an enormous number of incredibly talented engineers working on OSS today — the issue isn't the quality of who's there, it's that the incentive structure can't attract the breadth and depth the industry needs.
  • The cultural symmetry:
    • "Charities shouldn't pay big salaries — it should be a calling."
    • "Open source shouldn't pay big salaries — it should be a labour of love."
  • Thread: Sanity's pledge announcement called out Tailwind Labs laying off ~75% of engineering after AI assistants slashed docs traffic ~40%. The documentation traffic was how developers discovered their commercial products. AI is actively breaking the OSS funding loop right now — this is fresh and worth its own callout sub-section.
  • Thread: pull a Patak quote on burnout (link below) to humanize the data.

References to slot in

  • https://uncharitablemovie.com/about/
  • Dan Pallotta TED 2013 — "The way we think about charity is dead wrong"
  • https://opensourcepledge.com/blog/burnout-in-open-source-a-structural-problem-we-can-fix-together/ (Patak)
  • Tidelift 2024 State of the Open Source Maintainer report

6. The "why pay when it's free?" problem

  • Mental-model gap:
    • Charity has ~2,000 years of cultural infrastructure: tithing, philanthropy norms, tax incentives, social expectation. People are trained to give.
    • OSS has ~40 years of "free by default." There's no cultural muscle for paying for it. Most non-developers don't know it exists; most developers know it exists but don't know who pays for it (answer: mostly nobody).
  • Public attitudes mirror each other:
    • Charity: "they should just be more efficient" / "I already pay taxes."
    • OSS: "the maintainers do it because they want to" / "it's free, isn't that the point?"
  • Thread: walk through a brief history of charitable giving — religious tithing → 19th-century Victorian philanthropy → modern tax-deductible giving — and contrast with the (much shorter) history of OSS funding attempts (FSF, GitHub Sponsors, Patreon for code, Open Collective).
  • Thread: tax policy. Charity giving is tax-deductible almost everywhere; OSS sponsorship is mostly not. That is itself a policy choice that shapes giving behaviour.

7. Burnout and revolt

Frame the section: when you underfund a critical system long enough, the system fights back.

  • Burnout — open with Patak's piece (link above). Pull a quote.
  • The revolts — keep these tight; one short paragraph each.
    • left-pad (Azer Koçulu, March 2016) — 10-year anniversary right now. 11 lines of code unpublished after a trademark dispute with Kik. Broke Babel, React, builds at Facebook, PayPal, Netflix, Spotify. npm manually restored. Subsequently disabled unpublishing for packages older than 24h with dependents.
      • Thread: find the official npm post-mortem and the dependent count at the time of incident. Note the irony Koçulu pointed out years later — npm itself provided him the script that deleted all 273 packages at once.
    • colors.js / faker.js (Marak Squires, January 2022) — sabotaged his own packages over unpaid work. colors had ~3.3B downloads / 19,000 dependents; faker ~272M / 2,500+ dependents. Broke AWS CDK, Jest.
    • node-ipc / peacenotwar (Brandon Nozaki Miller, March 2022) — protestware that deleted files on systems geolocated to Russia / Belarus. The case that supply-chain talks now open with.
    • Lerna (Jamie Kyle, August 2018) — added restrictive license clauses banning Microsoft, Amazon, Dell, Xerox, Canon, LinkedIn for collaborating with ICE. Reverted, maintainer removed. Sparked the "ethical source" license wave (Hippocratic, Anti-996, NoHarm).
    • Bukkit / CraftBukkit (Wesley "Wolvereness" Wolfe, September 2014) — DMCA'd his own 23,000-line contribution after the Mojang acquisition, using GPL itself as the protest weapon. Froze the Minecraft modding ecosystem for months.
  • Charity parallel: when frontline workers in underfunded charities burn out or strike, the public usually frames it as a failure of the workers, not the funding model. Same framing happens in OSS — coverage calls maintainers "malicious actors" rather than "underfunded contractors who finally quit."
  • Thread: compare the language used to describe OSS revolts ("malicious", "sabotage", "supply chain attack") to language used for similar disruptive acts by underpaid workers in other sectors.

8. The security tax of underfunding

  • Setup: when critical software is maintained by exhausted volunteers, security suffers. The cost of "free" is paid in breaches.
  • Headline incidents:
    • Heartbleed (OpenSSL, 2014) — ~17% of secure web servers affected. Project had ~$9K/year in donations pre-incident.
    • Log4Shell / Log4j (December 2021) — patched on Christmas vacation by unpaid volunteers while companies with billion-dollar products built on it tweeted thank-yous instead of cheques.
    • TanStack / Mistral AI / UiPath supply-chain attack (2026) — most recent example of how compromised maintainer accounts cascade.
  • Tidelift datapoint: paid maintainers are 55% more likely to implement critical security practices than unpaid ones.
  • Charity parallel: food-safety / hygiene lapses in food banks when staffing collapses; root cause is under-resourcing but the blame falls on the volunteer. Same dynamic.
  • Thread: this is the section where the "public infrastructure" framing lands hardest. Would we accept this from roads, bridges, water supply?

References to slot in

  • https://www.microsoft.com/en-us/securityengineering/opensource/ossthreats
  • https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-in-fresh-supply-chain-attack/
  • https://pmc.ncbi.nlm.nih.gov/articles/PMC7338168/
  • Heartbleed retrospectives (find a canonical one)
  • Log4Shell holiday-volunteer-patch coverage

9. Licensing — the tools maintainers use to protect their work

Non-technical reader primer, then the controversies.

  • The three buckets:
    • Permissive (MIT, Apache, BSD) — take it, modify, ship commercially, even close-source your fork. Almost no obligations.
    • Copyleft (GPL, AGPL) — use it freely, but if you modify or distribute, your changes have to be open too. "Viral" in good and bad ways.
    • Source-available / "rugpull" licenses (BSL, SSPL, Elastic License v2) — not OSI-approved open source. Designed to stop hyperscalers from reselling the software as a managed service without paying upstream.
  • The Sentry-invented BSL (Business Source License): source available, becomes open after a few years. Designed specifically to prevent AWS-style resale without alienating self-hosters.
  • The "rugpull" controversies — keep each to ~50 words:
    • Redis (2024) → SSPL → community fork as Valkey (Linux Foundation)
    • HashiCorp Terraform (2023) → BSL → community fork as OpenTofu
    • Elastic (2021) → SSPL/Elastic License → community fork as OpenSearch (AWS-led)
    • MongoDB (2018) → SSPL
    • Red Hat CentOS (2020) → CentOS Stream → community forks as Rocky Linux and AlmaLinux
  • The core tension: how do you protect your work financially while keeping it accessible to the community? Every license is an answer to that question, with different tradeoffs.
  • Charity parallel: mission creep / commercial arms — Mozilla Foundation owning Mozilla Corporation; Goodwill thrift stores funding the nonprofit; Girl Scouts cookies funding programs. Same fundamental question: how do you generate revenue without compromising the mission?
  • Thread: this is the section where the charity parallel is weakest — acknowledge that rather than force it. The honest framing is "OSS is groping toward the financing structures charities have spent centuries building."

References to slot in

  • https://opensource.org/license/bsl-1-1 (BSL background)
  • Linux Foundation announcement of Valkey
  • OpenTofu launch announcement
  • https://www.mozilla.org/en-US/foundation/ (foundation/corp hybrid example)

10. The volunteer trap

  • Both sectors lean heavily on volunteers; both then suffer for it.
  • OSS: community events (KubeCon, conference talks), documentation, issue triage, support forums — all volunteer labour.
  • Charity: events, food sorting, donation drives — all volunteer labour.
  • The structural problem chain:
    1. Can't afford staff → rely on volunteers
    2. Volunteer time is unreliable / unpredictable
    3. Long-term planning becomes impossible
    4. The strategic work that would attract reliable funding (marketing, partnerships, polish, fundraising apparatus) never gets built
    5. Stay in survival mode forever
  • Thread: name this dynamic ("perpetual scramble mode") and use the name again in the conclusion. Survival mode crowds out the work that would end survival mode.

11. People doing it right (or trying to)

The constructive turn. The list is long but the patterns are few — surface the patterns.

11a. Commercial models that fund OSS sustainably

Short capsule on each model — the line should be drawn at organizational features, not developer capability. Keep the community whole.

  • Open core — GitLab, HashiCorp, MongoDB, Elastic, Sentry, Confluent ($4.5B), Databricks ($6.2B). Free core, paid enterprise (SSO, RBAC, audit, compliance).
  • Hosted SaaS — PostHog, Supabase, Plausible, Tailscale. Same code, you pay them to run it.
  • Services/support — Red Hat. Historical pioneer, weak as a pure play now.
  • Foundations / nonprofits — Apache, Linux Foundation, Ghost Foundation (cleanest "ethical" model for a small/mid project — all profits reinvested in the OSS).
  • VC-backed dev tools — Astral (uv, ruff), Bun, Deno. Monetization wedge still unproven.
  • Key insight to land (HashiCorp's CMO): "monetize the org's problems, not the individual developer's."
  • Thread: this is where Trellis's self-disclosure begins — we're a SaaS that depends on OSS, and we're considering taking the Pledge ourselves. The full self-audit lives in 11c below.

References to slot in

  • https://github.com/protontypes/open-business-models

11b. The Trellis stack — a worked example of every funding model

The point of this section: take the abstract bucket list above and prove it isn't abstract. A single mid-size SaaS's dependency tree spans every funding model on the list — and not all of them are equally well-funded. Make the reader feel that the parallels aren't theoretical.

Frame this as a public bill of materials. For each bucket: what we use it for, how it's funded today, and what we (and companies like us) should be doing about it.

Bucket 1 — Open source core with a paid offering
  • What it looks like: the core is OSS (often a permissive license); revenue comes from a paid hosted service, paid enterprise tier, or both.
  • Trellis examples to slot in:
    • Prisma — OSS ORM + paid Prisma Data Platform / Accelerate / Pulse. (Already cited heavily in The Silent Flag, so the reader is familiar.)
    • Sentry — OSS error tracking + paid SaaS; relevant double-duty here because Sentry is also the company behind the Open Source Pledge.
    • PostHog — OSS analytics + paid cloud.
    • Thread: confirm and add any others — Supabase? Grafana? n8n?
  • How Trellis funds these today: by paying for the hosted tier. The honest framing: this is the easiest form of "OSS support" because it's baked into the invoice — nobody has to make a discretionary decision.
  • What this bucket teaches: the model works because the paid wedge is aligned with org-level needs (hosting, compliance, SSO), not with developer capability. The reader doesn't have to think about whether to fund it — they fund it by using it.
  • Thread: this is the cleanest model from a sustainability standpoint, and Trellis benefits directly from it. Worth saying so plainly.
Bucket 2 — Fully open source, backed by a single large company
  • What it looks like: the project is genuinely open source under a permissive license, but ~all of the engineering payroll comes from one corporate steward. No paid tier. No hosted version. The company's motivation is strategic (platform leverage, hiring, ecosystem control), not direct revenue.
  • Trellis examples to slot in:
    • Angular (Google) — the canonical case for Trellis given Jay's Angular GDE background.
    • TypeScript (Microsoft)
    • React (Meta) — even though we don't use it, name-check for reader recognition
    • Playwright (Microsoft) — we use this for testing
    • VS Code (Microsoft)
  • How Trellis funds these today: we don't, directly. We're free-riding on Google / Microsoft / Meta's strategic interest in maintaining them.
  • What this bucket teaches: the funding is real, but it's contingent on the corporate steward's continued strategic interest. The risk surfaces when that interest shifts — name examples to discuss:
    • Google killing Angular.io momentum during the AngularJS → Angular 2 transition (2014–2016)
    • Meta's React team headcount changes
    • The general "what happens if Google decides Angular isn't strategic anymore" question
  • Charity parallel to draw: large foundations funded by a single donor or family. The work is real, the money is real, but the mission is one boardroom decision away from a pivot. Think Gates Foundation's pivots in priorities over the years.
  • Thread: this bucket has the least public discussion of its own fragility. Worth dwelling on — most developers assume "backed by Google" means "permanent" when it means "permanent until it isn't."
Bucket 3 — Pure community OSS relying on contributions / sponsorships
  • What it looks like: no commercial entity. Funded (if at all) through GitHub Sponsors, Open Collective, occasional corporate donations, or foundation grants. Often maintained by one to a handful of people.
  • Trellis examples to slot in:
    • cURL (Daniel Stenberg) — already the anchor example in section 4
    • OpenSSL — already the anchor for the security section
    • Nx — check current funding status; Nrwl/Nx is corporate-backed (Bucket 1 or 2), but adjust if we use community plugins
    • Eleventy (powers this blog) — solo-maintained by Zach Leatherman; a perfect example. Funded primarily via GitHub Sponsors / Open Collective.
    • Most of package.json — left-pad, ms, lodash, debug, chalk, countless utility libraries we depend on transitively without thinking about
  • How Trellis funds these today: mostly we don't. This is the bucket where the article's central argument bites hardest — we benefit enormously and pay nothing.
  • What this bucket teaches: this is where the Open Source Pledge math actually lands. At ~10 engineers × $2K/year = $20K, the budget exists; the question is whether the decision-making apparatus to allocate it exists.
  • Thread: name the specific dependencies in our package.json that fall into this bucket. Pick 5–10 of the most-used and call them out by name. Concrete > abstract.
  • Thread: connect this back to the volunteer trap — these maintainers are one bad week away from a left-pad / colors.js style revolt, and Trellis is one of thousands of companies that would be affected.
Bucket 4 — Open source backed by venture capital
  • What it looks like: open source project, often permissively licensed, funded by a VC-backed company whose monetization plan is "TBD" or "open core / hosted SaaS later." The funding is real and substantial today, but the runway depends on future revenue capture or an acquisition.
  • Trellis examples to slot in:
    • Bun (Oven; acquired by Anthropic in late 2025) — the user's reference example
    • Astral (uv, ruff; acquired by OpenAI in March 2026)
    • Deno (Deno Land Inc.; still independent)
    • Turbopack / Turborepo (Vercel)
    • Thread: which of these does Trellis actually use? Confirm before writing. If we use Bun / uv / ruff, name them; if not, use them as illustrative-only.
  • How Trellis funds these today: indirectly, by being part of the user base that justifies the VC valuation. We're not paying, but our adoption is itself the commodity.
  • What this bucket teaches: the cleanest funding short-term, the most uncertain long-term. The "VC-funded OSS → acquisition" pipeline is now well-established (Bun → Anthropic, Astral → OpenAI). The license stays open, but the strategic direction moves under the new owner.
  • The uncomfortable question: when an OSS project's funding is venture-backed, the project is one acquisition or one missed funding round away from existential change. Is that meaningfully different from Bucket 2's "one corporate boardroom decision away"? Discuss.
  • Thread: this section connects directly to section 12 ("the acquisition era") — set it up here, pay it off there.
The uneven funding picture

Close 11b with a synthesis paragraph the reader should walk away with:

  • Buckets 1 and 4 are the best-funded today. Buckets 2 and 3 are the most fragile — and Bucket 3 is the one Trellis (and the industry) is most freeloading on.
  • The article's core argument applies to each bucket differently — but the charity parallel is sharpest for Bucket 3, which is the closest analogue to a small, under-resourced charity living donation-to-donation.
  • Thread: a small visual could help here — a 2×2 or a table showing funding stability vs Trellis's current support level per bucket.

11c. Structural philanthropy and industry-changing interventions

These go beyond GitHub Sponsors tip jars. Each creates a structural commitment.

  • Sentry's Open Source Pledge (2024–) — $2K/engineer/year, public annual report. 25+ companies, $6.8M+ to date.
    • Thread: Sanity's $146K/2025 pledge is the cleanest worked example, including the Tailwind Labs callout.
  • Germany's Sovereign Tech Agency — €37.3M invested. Three programs: Fund (deliverable contracts >€50K), Fellowship ("maintainer in residence" stipends), Standards (€4,800–5,200/month for standards work). Treats critical OSS as public infrastructure.
  • Proposed EU-STF — €350M (2028–2035), German model scaled to the EU.
  • GitHub Secure Open Source Fund — pooled funding, low-bureaucracy applications, paired with free security tooling.
  • Tidelift — marketplace, not charity. Converts OSS support into a contractual supply-chain relationship. 55% better security outcomes for paid maintainers.
  • Astral OSS Fund — $26K/year ($3,250/dev/year), explicitly Sentry-Pledge inspired.
  • Bloomberg & Indeed FOSS Funds — internal employee-democratized OSS budgets. Indeed/Microsoft/Salesforce all participating.
  • thanks.dev — usage-based recurring funding tied to actual dependency use.
  • Hiring maintainers directly — Astral (Charlie Marsh / Ruff), Stripe Open Source, Google / Meta / Microsoft on Chromium, React, V8, TypeScript, Linux kernel.
  • The five patterns that distinguish "actually changing things" from tip jars — pull these into a sidebar / callout box:
    1. Per-engineer formulas
    2. Public reporting requirements
    3. Pooled funding with low bureaucracy
    4. Routing through foundations that know the maintainers
    5. Government as backstop for critical infrastructure

References to slot in

  • https://opensourcepledge.com/
  • https://www.sovereign.tech/
  • https://thanks.dev/
  • Tidelift 2024 maintainer survey

12. Open question — the acquisition era

Don't try to resolve this; leave it as an open uncomfortable question.

  • The trend, very recent:
    • OpenAI ↔ Astral (March 2026) — uv, ruff, the modern Python tooling chain.
    • Anthropic ↔ Bun (late 2025) — JavaScript runtime + bundler.
    • Thread: research whether there are other 2025–2026 acquisitions worth listing (Vercel/Turbo? Datadog OSS acquisitions?).
  • Even when licenses stay MIT, strategic neutrality is compromised.
  • Open questions to raise:
    • What happens to a community-driven project when the maintainer's employer pivots?
    • Are we building public infrastructure on private balance sheets?
    • Is this the natural endpoint of "hire maintainers directly"?
  • Charity parallel: what happens when a charity / foundation is effectively captured by a corporate sponsor and quietly aligns to their priorities? Thread: the Sackler family's museum and university endowments are the canonical cautionary tale, but find a cleaner / less-loaded parallel if possible.

13. What can readers actually do

Practical, audience-tiered. Keep this section short and concrete.

  • Companies — take the Open Source Pledge; formalize an OSS budget per engineer; route through foundations rather than spraying small donations.
    • Trellis self-disclosure: a 10-engineer pledge is $20K/year and lands us on the public member list alongside Sentry and Sanity. The annual reporting requirement is the actually-industry-changing part.
  • Developers — sponsor the 3–5 packages that show up in every package.json you touch. Advocate internally for an OSS line item.
  • Everyone else — this is the charity-style direct ask. Easiest entry points: PSF (Python Software Foundation), Django Software Foundation, Apache Software Foundation, OpenSSL Foundation, GNOME Foundation.
  • Thread: a small "find your OSS" exercise — "open your phone, list 5 apps, odds are 4 of them ship OpenSSL."

14. Closing

  • Tie back to the opening anchor (left-pad / cURL / food bank).
  • Land the reframe: this is not a charity problem and it is not an OSS problem. It is a public-infrastructure problem. Both sectors are running on fumes for the same structural reasons, and the fix in both cases looks the same — treat critical work like critical infrastructure, fund it predictably, pay the people doing it like the work matters.

Cross-cutting threads to weave throughout

  • Always pair an OSS data point with a charity data point in the same paragraph. Don't silo the parallels into separate sections.
  • Repeat the audience reframing every few sections: "if you've ever wondered why your local food bank can never get out of survival mode, the same dynamic is keeping the software you use every day from getting out of survival mode."
  • Avoid developer jargon. If a term must be used, define it inline once, then use it freely.
  • Tone: don't moralize. The "donate more" answer is not sufficient — structural change is the real ask. Make that the consistent drumbeat.

Style & length

  • Target: ~3,000–4,000 words. Comparable to the "Quality at Trellis" post in length but written for a non-technical audience.
  • Voice: Jay's. First-person where it lands ("at Trellis we…"), mostly journalistic otherwise.
  • Add the standard AI disclaimer to frontmatter when this becomes a real post.
  • Disclose Trellis's self-interest up front (we're a SaaS that depends on OSS; we're considering the Pledge).

Research / citations TODO before writing

  • [ ] left-pad post-mortem (official npm write-up; dependent count at time of incident)
  • [ ] Food Banks Canada HungerCount 2025 / Feeding America 2025 annual stats
  • [ ] Dan Pallotta TED 2013 — exact MBA quote
  • [ ] Patak burnout post — the single most quotable line
  • [ ] Tailwind Labs layoff coverage — confirm 75% / 40% numbers
  • [ ] Heartbleed retrospectives — confirm OpenSSL pre-incident funding
  • [ ] Log4Shell — confirm the "patched on Christmas vacation" narrative
  • [ ] Recent (2025–2026) supply-chain attack roundup
  • [ ] Median OSS maintainer income (Tidelift / GitHub State of the Octoverse 2025)
  • [ ] Charity sector compensation-gap study (2024–2025, US or Canada)
  • [ ] Confirm 2025–2026 OSS acquisitions beyond Astral / Bun