Episode 292: Vlad-Stefan Harbuz: Launching the Software Stewardship Lab  🔗 **Source:** [Episode 292: Vlad-Stefan Harbuz: Launching the Software Stewardship Lab](https://www.youtube.com/watch?v=7cSfF1T4Q5w) > [!note]+ Document Notes > tags: [open-source-sustainability, funding-models, software-supply-chain, maintainer-burnout, dependency-graphs, open-source-pledge] > author: [Sustain podcast — Richard Littauer, Abby Cabunoc Mayes, Errol Fox, with guest Vlad-Stefan Harbuz] > source: [Sustain (SustainOSS) podcast, Episode 292] > reference: [https://www.youtube.com/watch?v=7cSfF1T4Q5w] > date created: 2026-08-07 00:00 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Sustain Episode 292 — Vlad-Stefan Harbuz: Launching the Software Stewardship Lab > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [🔗 References](#-references) - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [📚 References](#-references-primary) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🧱 Refactor Appendix](#-refactor-appendix) ### 🔗 References - Episode: https://www.youtube.com/watch?v=7cSfF1T4Q5w (published 2026-08-07, ~36 min, ~6,918 transcript words) - Software Stewardship Lab — `stewardshiplab.org` (launched the day this episode aired) - Open Source Pledge — https://opensourcepledge.com/ - Ecosyste.ms — https://ecosyste.ms/ (Andrew Nesbitt) - Software Sustainability Institute — https://www.software.ac.uk/ (Neil Chue Hong) - Invest in Open Infrastructure — https://investinopen.org/ - Sustain podcast — https://sustainoss.org/ > [!warning] **ASR name corruption — read before citing anything from this transcript.** > The auto-captions garble nearly every proper noun in the episode. The right-hand column is my > **inferred** intended referent based on context and public record, not a verified correction. > Confirm against the show notes before quoting or citing. > > | Transcript says | Almost certainly means | > |---|---| > | Richard Littower | Richard Littauer | > | Abby Cabs / Abby Kabun Maze | Abby Cabunoc Mayes | > | Vlad Stefan Harbuzz | Vlad-Stefan Harbuz | > | Fosage / Fosback Stage / Fosspect Age | FOSS Backstage | > | Chad Whitaker | Chad Whitacre | > | Andrew Nesbet | Andrew Nesbitt | > | ecosystems | Ecosyste.ms | > | Zeroda | Zerodha | > | Kylashnath | Kailash Nadh | > | Neil Chu Hong | Neil Chue Hong | > | Miranda Heave | Miranda Heath | > | Caitlyn Teny | Kaitlin Thaney | > | Paloma Olivea | Paloma Oliveira | > | Stuart Guyger / Sean Gogggins | Stuart Geiger / Sean Goggins | > | open blast | OpenBLAS | > | PI project automal | `pyproject.toml` | > | 51c3 | 501(c)(3) | > | US UHRC type thing | US UARC (University Affiliated Research Center) | > | $7.2 into a million | $7.2 million | > | stewardship.org | stewardshiplab.org | > > This is the third document in this batch where ASR corrupted low-frequency technical terms and > names. The pattern is now established, not incidental. ## 📝 Summary - **What happened.** Launch-day interview for the **Software Stewardship Lab**, a newly formed Scottish nonprofit research lab focused on open source sustainability. Guest Vlad-Stefan Harbuz is its executive director, also directs the Open Source Pledge, and is doing a philosophy PhD at Edinburgh on the ethics and epistemology of open source. - **Why it matters.** It names a specific, under-discussed second-order funding gap: even when money for open source exists, **the research and infrastructure required to decide where it should go is itself unfunded**. That recursion is the episode's central and most original idea. - **Key stakeholders.** Open source maintainers, especially of invisible transitive and binary dependencies; companies with undocumented supply-chain exposure; funders and charity regulators; academic open source researchers; foundations whose remit differs from a research lab's. - **Risks and tradeoffs.** The Pledge's flat $2,000-per-developer ask scales badly at both ends — punitive for very large employers ($10–50M), and arguably mis-calibrated across purchasing-power regions. The Lab launches with roughly £500 in its Open Collective and no secured grant, so its own sustainability is an open question it candidly acknowledges. - **Bottom line.** A serious, well-diagnosed set of problems from someone who has already moved ~$7.2M and learned what breaks. The diagnosis is much stronger than the funding plan, which the guest does not pretend otherwise. ## 📖 Main Content - **Origin story, unusually candid.** Harbuz says he ran a software company and concluded he had been an exploitative employer — > [!quote] one day I realized I was a bad guy in that I was an exploitative employer and then I felt very sad and regretted my decisions. That admission drove him into philosophy, then into open source ethics. It is a rare instance of a founder narrative built on self-indictment rather than vision. - **The Open Source Pledge, mechanically.** Companies commit at least **$2,000 per developer employed, per year**, paid directly to maintainers or foundations. Roughly **$7.2M** raised. Critically, the Pledge is a **pass-through with no intermediary** — Harbuz's own work is funded by Sentry, and the Pledge touches none of the money. Its role is advisory: talking to companies, advising on distribution, publishing research. - **The allocation problem.** Even willing money struggles to find a destination. Which projects do I actually depend on? What is the full dependency chain? Which packages are most critical? Where are the gaps in the dependency tree? Harbuz frames this as the discovery that motivated the Lab. - **Metrics are bad proxies.** Downloads are the obvious measure and a poor one — his own example is that millions of downloads may be one CI pipeline running 100,000 times, not meaningful human reliance. Improving these metrics is explicitly core Lab work, with Andrew Nesbitt (creator of Ecosyste.ms) among the directors. - **Value judgments are permissible.** A notable philosophical move: rather than pursuing neutral algorithmic allocation, he argues you may legitimately start from what you care about — "healthcare is important, can we look at open source used in healthcare?" — instead of "abstract theoretical sort of neutrality and purity." - **The scaling tension, unresolved.** Asked about barriers for large companies, he concedes the ask becomes $10M–$50M for employers with thousands of developers. He is openly torn: recognizing smaller gifts risks "watering down the pledge," but refusing to celebrate a $500,000 contribution is also wrong. The current workaround is letting a *subdivision* rather than the whole company join. He says plainly he does not know the best answer. - **Purchasing-power parity, complicated by evidence.** The flat-dollar ask arguably burdens lower-income regions disproportionately — but he immediately counters his own framing by noting **Zerodha**, an Indian stockbroker, is among the most generous contributors. He lets the counter-example stand rather than resolving it. - **Why a "lab," not a foundation.** Deliberate positioning: the Lab does research, software, papers, and services; foundations do many other things. He also names a structural obstacle — it has historically been **hard to convince charity regulators that paying people to write open source is in the public interest**. The Lab intends to apply for UK charity status partly to help establish that. - **Not a university lab.** Pressed by the hosts, he confirms it is a Scottish nonprofit rather than a University of Edinburgh institute. Funding plan: grants (noting UKRI currently opening a normally-academic program to non-academic researchers) plus company sponsorship. - **Binary dependencies — the concrete technical case.** His worked example: your Python code depends on NumPy's source, but NumPy depends on **OpenBLAS**, written in C and consumed in *compiled* form. Compiled dependencies **do not appear in the manifest**, so at scale they are invisible to dependency analysis. If those projects carry security vulnerabilities, you are exposed and cannot see it. PEPs are being drafted to allow declaring external projects in `pyproject.toml`. This is the sharpest argument in the episode for why companies should fund the work out of self-interest. - **Research software has a parallel gap.** Papers cite software in prose ("I used NumPy") with no machine-discoverable manifest, so there is no way to determine which packages carry the most research and therefore deserve funding. - **Burnout and governance workstream.** Co-director Miranda Heath authored a burnout report, is producing a yearly follow-up, and is working on a report on **the impact of AI on the mental health of open source maintainers**. Related question: can governance structures be designed to support maintainer mental health? - **Explicit collaboration posture.** He repeatedly disclaims sufficiency — > [!quote] it would be delusional of us to say, "Oh, we're going to solve open source sustainability just with the people that we have." Hosts push him toward academic researchers (James Howison, Stuart Geiger, Sean Goggins) and adjacent orgs (Invest in Open Infrastructure, the Open Technology Research group, the Software Sustainability Institute). - **The ask.** Tell your employer their commercial work depends on volunteer labor more than they realize; fund the Lab; and treat it as a conversation rather than a donation. ### 🗒️ Notes - Hosts: Richard Littauer (New Zealand), Abby Cabunoc Mayes (Toronto), Errol Fox (UK). Guest in Edinburgh. Two PhD students on the call. - Chad Whitacre founded the Pledge *and* co-founded this podcast; he has since left open source, works at Home Depot, and makes zines about living offline. Harbuz's spotlight is Chad's *Open Path* episode 4, filmed in Ukraine during air-raid sirens. - The Lab's Open Collective held roughly **£500** at recording — a striking figure against a $7.2M pledge total. - npmx.dev is praised not for its technical merit but its *social* structure: a comparatively large maintainer team including designers, UX, copywriting, and localization people, not only programmers. - Spotlights: Paloma Oliveira's *Diversifying Open Source*; a former GitHub colleague's *Open and Async*; and the Software Sustainability Institute's **Generative AI risk register** (open source, ~15 entries, contributable on GitHub). - The episode is explicitly the Lab's announcement vehicle — launch day was the air date. ## 📚 References (primary) - Software Stewardship Lab: stewardshiplab.org (and its Open Collective) - Open Source Pledge: https://opensourcepledge.com/ - Ecosyste.ms — dependency and ecosystem metrics infrastructure - Miranda Heath's open source burnout report (SSL workstream) - Python PEPs on declaring external/binary dependencies in `pyproject.toml` - Software Sustainability Institute Generative AI risk register (GitHub) - Paloma Oliveira, *Diversifying Open Source: an open standards playbook for inclusive and equitable tech projects* - Prior Sustain episodes: Chad Whitacre (Sept 2024), Kailash Nadh/Zerodha, Miranda Heath, Kaitlin Thaney, James Howison ## 🗣️ Paraphrase - **Origins.** A software company owner concluded he had exploited his own employees, turned to philosophy to understand cooperative work, and found his way to open source funding. - **The Pledge.** Companies pay $2,000 per developer per year straight to maintainers; ~$7.2M moved; the Pledge itself handles none of it. - **The gap discovered.** Willing money still cannot find its target, because dependency visibility and criticality metrics are poor. - **The recursion.** The infrastructure needed to identify who to fund is itself unfunded — that irony is the Lab's founding rationale. - **Structure.** A Scottish nonprofit, not a university institute, deliberately called a lab to signal research output rather than foundation-style stewardship. - **The technical case.** Compiled dependencies are invisible in manifests, so companies carry unmeasured security exposure — a self-interest argument for funding the research. - **The human case.** Burnout research continues, with a forthcoming report on AI's effect on maintainer mental health. - **The ask.** Convince your employer; fund the Lab; collaborate rather than donate. ## 📰 Newsletter **The money exists. Nobody knows where to send it.** Sustain 292 marks the launch of the Software Stewardship Lab, and it contains the most useful framing of the open source funding problem I've heard in a while. Vlad-Stefan Harbuz runs the Open Source Pledge, which has moved about $7.2 million from companies straight to maintainers — no intermediary, the Pledge never touches the cash. And what he learned doing it is that getting companies to say yes was not the hard part. The hard part is *where does it go*. Which packages do you actually depend on? Which are critical? Downloads are the obvious metric and a terrible one — a million downloads might be one CI job running in a loop. So here's the recursion, and it's a good one: the research and infrastructure needed to figure out where funding should go is itself unfunded. That's what the Lab exists to fix. The sharpest concrete example is binary dependencies. Your Python code depends on NumPy. NumPy depends on OpenBLAS, written in C and consumed compiled — so it never appears in your manifest. If OpenBLAS has a vulnerability, you're exposed and your dependency scanner cannot see it. That's not a charity pitch, that's a risk register item. Worth noting what the Lab launched with: about £500 in its Open Collective. The diagnosis is excellent; the funding plan is grants and hope. Which is, of course, exactly the problem it was founded to describe. **Links:** [the episode](https://www.youtube.com/watch?v=7cSfF1T4Q5w) · [stewardshiplab.org](https://stewardshiplab.org) · [Open Source Pledge](https://opensourcepledge.com/) · [Ecosyste.ms](https://ecosyste.ms/) ## ✅ Action Items - **DevRel** - `#action/h1` Steal the self-interest framing. "Your dependency scanner cannot see your compiled dependencies" moves budget in a way "support maintainers" never will. This is the strongest advocacy line in the episode. - `#action/h2` Write the explainer on invisible dependency classes — transitive, OS-level, and now compiled/binary — since the podcast notes this third category is rarely discussed. - `#action/h3` Profile the npmx maintainer-team composition as a model for non-programmer contributors holding real maintainer status. - **OSPO** - `#action/h1` Policy & governance: evaluate the Open Source Pledge against your own developer headcount, and note the subdivision-level participation option as the practical on-ramp for large orgs. - `#action/h1` Security management: audit for binary/compiled dependencies that never appear in manifests. This is a genuine, testable blind spot in most SBOM pipelines. - `#action/h2` Software inventory: treat SBOM completeness as unproven until compiled deps are demonstrably represented. - `#action/h2` Community engagement: the Lab explicitly wants company conversations about supply-chain pain, not just money. Cheap, high-value engagement. - `#action/h3` License compliance: charity-status precedent matters — track whether UK regulators accept that funding open source serves the public interest. - **Community** - `#action/h2` Maintainers: watch for Miranda Heath's AI-and-maintainer-mental-health report; it will be citable in burnout conversations. - `#action/h2` Sponsors: the "recognize $500k from a giant company" problem is a live governance design question any recognition program faces. - `#action/h3` Contributors: note the argument that design, UX, copywriting, and localization deserve maintainer status, not helper status. - **WordPress (by team)** - Core: WordPress has its own invisible dependency surface — bundled libraries and vendored code that no manifest describes. - Core Performance / Core AI: the AI-and-maintainer-mental-health research is directly relevant to how AI contribution load is landing on reviewers. - Core Program Team: the "which work is critical" measurement problem is the same one that showed up in the Josepha/Crossword episode — activity is measured, criticality is not. - Meta: plugin/theme directories are exactly the dependency-visibility infrastructure the Lab argues is chronically underfunded. - Plugins / Themes: AI-driven submission volume plus invisible dependencies is a compounding review-burden problem. - Support / Documentation: document the dependency surface users actually inherit when installing. - Training: a module on reading a dependency tree, including what it omits, would be genuinely novel. - Hosting: hosts carry the compiled-dependency exposure most directly (PHP extensions, image libraries). - Tide: the original ambition — automated ecosystem-wide compatibility and quality signal — is precisely the "unfunded measurement infrastructure" this episode describes. Worth revisiting in that light. - Openverse: research-software citation gap has an analogue in media provenance. - Accessibility: a11y work suffers the same prestige gap the guest names for design and UX. - Mobile, Playground, Marketing, Design, Photos, TV, Polyglots, CLI: Not applicable to this source — no specific content bearing on these teams. - **The WPOCC** - `#action/h1` Direct precedent. A newly formed nonprofit trying to fund open source stewardship research, wrestling publicly with structure (lab vs foundation), charity status, and legitimacy. Both the reasoning and the pitfalls are worth capturing in the governance wiki as a comparison case. - `#action/h2` The "recognize partial commitment without diluting the standard" problem maps onto Five for the Future almost exactly. - **FAIR** - `#action/h1` Strongly relevant. Dependency discoverability, criticality metrics, and gaps in the dependency graph are core FAIR concerns; Ecosyste.ms is prior art worth engaging rather than reinventing. - `#action/h2` The charity-regulator obstacle — proving that funding open source infrastructure is a public good — is a live question for any FAIR funding vehicle. ## 🧪 Hypotheses 1. Download counts correlate poorly with meaningful human reliance, because automated CI traffic dominates. *Testable: segment registry logs by user-agent and request pattern; compare against telemetry or survey-reported use.* 2. A material fraction of production dependency trees contain compiled/binary dependencies absent from manifests. *Directly testable: audit built artifacts against declared manifests across a sample of popular packages.* 3. Security vulnerabilities in binary dependencies have longer mean time-to-remediation than source dependencies, because scanners cannot see them. *Testable against CVE and advisory timelines.* 4. Flat per-developer funding asks produce lower participation among very large employers than tiered asks would. *Testable by comparing participation rates by company size, which the Pledge already has data for.* 5. Projects with multidisciplinary maintainer teams (design, UX, localization as maintainers) show lower maintainer burnout than programmer-only teams. *Testable via the burnout report's instrument, using npmx as a case.* 6. Research software citation is prose-only in the overwhelming majority of papers, making funding allocation to research dependencies impossible at scale. *Testable by sampling papers for machine-readable software citation.* ## 📊 Methodology **Of the source:** none in the empirical sense. This is a launch interview — testimony from a founder about his own organization on its announcement day. Claims about the Pledge's $7.2M and the Lab's structure are first-party and unaudited here. The metrics critique (downloads as poor proxy) is argued by illustrative example rather than data. The burnout report is referenced but not summarized, so its methodology is out of scope for this document. Treat everything as informed practitioner testimony with a clear promotional interest, which the format makes obvious rather than hides. **Of this analysis:** full transcript read from the Reader `notes` capture (~6,918 words, auto-generated captions). All content claims trace to explicit statements in that transcript. The name-corrections table is **inference from context plus public record, not verification** — flagged as such in the callout, and every entry should be confirmed against the episode's show notes before citation. Comparisons to the Crossword/Josepha episode and to Five for the Future are my own cross-links from earlier vault work, not connections the speakers make. ## ❓ Questions - What replaces downloads as a criticality metric, concretely? Ecosyste.ms improves coverage, but what is the actual proposed ranking function? - Is there a tiered or capped Pledge variant under consideration, or is subdivision-level participation the permanent answer? - How does the Lab avoid becoming another unfunded intermediary — the exact failure mode it diagnoses? - What is the charity-status argument that regulators have historically rejected, and what changed to make the attempt worthwhile now? - Which PEPs specifically address external/binary dependency declaration, and what is their status? - If value judgments are legitimate inputs to allocation ("healthcare matters"), who adjudicates competing value claims? - Does the Lab's research output get published openly, and under what license? ## 🔮 Future Research - Build the compiled-dependency visibility tooling the guest describes; it is the most concrete and tractable gap named. - Empirical criticality metrics that survive adversarial gaming — a genuinely open research problem, since any published metric becomes a target. - Longitudinal study of maintainer burnout with AI workload as a variable — already underway per the episode, and worth tracking. - Machine-readable software citation for research papers, enabling funding allocation to research dependencies. - Comparative governance study: lab vs foundation vs university institute as vehicles for open source sustainability work. - Whether direct company→maintainer transfer (no intermediary) produces different allocation patterns than pooled/foundation funding. ## 💡 Implications - **Practice.** Audit for dependencies your manifest cannot see. If your SBOM is manifest-derived, it is incomplete by construction. - **Policy.** Charity and public-benefit frameworks have not caught up to the reality that paying people to maintain shared infrastructure is a public good. That is a policy gap, not merely an administrative one. - **Security.** The binary-dependency blind spot is the most actionable security finding here and applies to essentially every ecosystem with native extensions, including PHP. - **Education.** Non-code contribution — design, UX, localization, docs — carries a prestige discount that is a funding problem, not just a cultural one. - **Funding.** The recursion is the durable insight: allocation infrastructure is a prerequisite for allocation, and nobody funds prerequisites. Any funding program should budget for its own measurement layer. ## 🧠 Learning Styles Assessment - **Visual.** Poorly served. Audio-first; no diagrams despite the dependency-tree and binary-dependency material crying out for one. The YouTube presence is described in-episode as "an automatic thing." - **Aural.** Strongly served — four-voice conversation, distinct speakers, natural turn-taking, good pacing. The primary intended mode. - **Verbal.** Moderately served. Rich verbal explanation, but the transcript is degraded by pervasive name corruption, which specifically damages the most citable content. - **Kinesthetic.** Weak. Nothing to build or run, though the closing call to action (talk to your employer, fund the lab) is a concrete behavioral ask. - **Logical.** Well served. The core argument chain — money exists → allocation is hard → metrics are bad → measurement infrastructure is needed → that infrastructure is itself unfunded — is clean, sequential, and easy to follow. - **Social.** Strongly served. Genuine multi-host dialogue with real pushback, especially the hosts pressing on structure, funding, and the £500 balance. - **Solitary.** Well served via transcript. - **Naturalistic.** Weak but non-zero — "ecosystem" framing is used throughout, and the dependency-graph material is fundamentally about classification and relationships between entities. - **Reading level.** Roughly grade 11–13. Vocabulary is conversational, but comprehension requires substantial prior context: dependency trees, manifests, SBOMs, transitive vs binary dependencies, 501(c)(3) and UK charity status, PEPs, quadratic funding, UKRI. A newcomer to open source funding would need a glossary. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA. 1. **Perceivable — text alternatives.** ⚠️ Auto-captions only, and they are materially degraded — essentially every person and organization name is corrupted. For an episode whose value is largely *who to contact and what to read*, this is a severe practical failure even though captions technically exist. 2. **Perceivable — time-based media.** ⚠️ Audio podcast with transcript; no audio description needed for a talk format. Show notes reportedly carry the links, which mitigates the name corruption for sighted users following along. 3. **Operable — keyboard.** ✅ Standard players; podcast distribution is broadly accessible. 4. **Operable — enough time.** ✅ Self-paced, pausable, ~36 minutes with no time-dependent interaction. 5. **Understandable — readable.** ⚠️ Heavy unglossed jargon. The hosts do gloss one term explicitly ("PEP stands for Python enhancement proposal"), which is good practice, but most others pass unexplained. 6. **Understandable — predictable.** ✅ Consistent Sustain format — introductions, topic, then the recurring "spotlight" segment. Regular listeners know the shape. 7. **Robust — compatible.** ✅ Standard podcast and YouTube delivery. The transcript lacks internal headings or timestamps, so a screen-reader user cannot navigate ~6,900 words by topic. **Priority fix:** human-corrected names in the transcript. The episode's actionable value is its network of people and organizations, and that is precisely what the ASR destroyed. ## 🌍 DEIB Assessment - **Cultural breadth.** Genuinely strong, and unusually so. Hosts and guest span New Zealand, Canada, the UK, and Scotland; the conversation explicitly raises **purchasing-power parity** as a fairness problem with the flat $2,000 ask, and then complicates its own framing by citing Zerodha, an Indian company, as among the most generous contributors. That is a real engagement with global equity rather than a gesture — though it remains unresolved, and the Pledge's dollar-denominated ask still encodes a US-centric default. - **Inclusive language.** Good throughout. Warm, plain, non-gatekeeping. The guest's admission of having been "an exploitative employer" models accountability language rarely heard in founder narratives. Hosts are careful to credit prior guests and name predecessors. - **Neurodiversity support.** Mixed. Strengths: clear argument sequencing, a predictable recurring format, and a full transcript. Weaknesses: heavy digression (the opening several minutes are conference chat), rapid name-dropping without context, no chapters or summary, and a long unbroken transcript. - **Representation.** Reasonable on the call — mixed nationality and gender among hosts — and notably self-aware about its limits elsewhere. A host directly challenges the Lab's board composition, urging inclusion of named academic researchers, and the guest concedes the point rather than defending. The npmx discussion foregrounds designers, UX, copywriters, and localizers as first-class maintainers, which is a substantive inclusion argument about *what counts as contribution*, not just who is in the room. - **Psychological safety.** High. Hosts ask genuinely pointed questions — why not a university structure, what is your sustainability plan, you only have £500 — and the guest answers without defensiveness, repeatedly saying he does not know. The exchange about board composition is the clearest instance: a critique is offered, accepted, and met with "I'm super open to that." Disagreement is treated as collaboration. ## ✅ Logical Validity **Strong reasoning** - **The central recursion is genuinely novel and well-argued:** funding allocation requires measurement infrastructure; measurement infrastructure is itself unfunded; therefore the funding problem is self-blocking. Clean, non-obvious, and it reframes a tired debate. - **The downloads critique is precise.** Rather than vaguely asserting metrics are bad, he supplies the specific mechanism — automated CI traffic inflating counts — which makes the claim falsifiable. - **The binary-dependency argument is the strongest passage in the episode.** It moves from a concrete chain (Python → NumPy → OpenBLAS), to a structural consequence (absent from manifests), to a risk implication (invisible vulnerabilities), to a funding conclusion (self-interest). Each step follows. - **Epistemic humility is consistent and specific.** "I don't know what the best thing to do is," "it would be delusional of us to say we're going to solve open source sustainability just with the people that we have." He distinguishes what he researches personally from what colleagues do, rather than claiming the whole field. - **He argues against his own framing.** Raising purchasing-power parity and then immediately citing Zerodha as a counter-example is intellectually honest behavior that weakens his own rhetorical position. **Fallacies** 1. **Special pleading (structural, and the most important one).** *Located:* the Lab's founding rationale. *The argument:* open source infrastructure deserves funding because it is critical yet invisible — and the research needed to identify it is *also* critical and invisible, so fund us too. *Why it warrants scrutiny:* the same reasoning extends indefinitely (who funds the research into which sustainability research is critical?), and it conveniently terminates at the speaker's own organization. *Mitigating:* he flags the irony himself ("the irony of it is..."), which converts it from a hidden move into an acknowledged tension. *Fix:* specify what would count as the Lab succeeding, so the recursion has a stopping condition. 2. **Appeal to self-interest presented as universal alignment.** *Located:* the pitch that funding this work is in companies' interest. *Why it's incomplete:* it holds for firms with material supply-chain exposure and audit obligations; it does not obviously hold for firms whose exposure is low or whose risk is already externalized. *Fix:* segment the pitch by company risk profile rather than asserting a general interest. 3. **Hasty generalization from a single vivid example.** *Located:* the CI-inflated-downloads illustration. *Why it fails:* one plausible mechanism is offered as evidence that metrics *generally* amount to a popularity contest. The conclusion may well be right, but the example does not establish magnitude. *Fix:* cite the proportion of registry traffic that is automated — data that exists. 4. **Unfalsifiable framing of "criticality."** *Located:* the value-judgments passage. *Why it's a problem:* once "we might want to say healthcare is important" is admitted as a legitimate input, criticality becomes partly a values question with no stated adjudication procedure — which quietly reintroduces the arbitrariness the metrics work was meant to remove. *Mitigating:* he is explicit that he is rejecting "abstract theoretical neutrality and purity," so this is a considered position, not an oversight. *Fix:* state how competing value claims get weighed. 5. **Survivorship bias in the Zerodha counter-example.** *Located:* the purchasing-power discussion. *Why it fails:* one exceptionally generous Indian company does not establish that a flat dollar ask is equitable across economies; it establishes that it is not universally prohibitive. *Fix:* look at participation *rates* by region, not exemplars. 6. **Appeal to emotion (mild, closing).** *Located:* the Chad Whitacre spotlight and the Ukraine episode description. *Why it's weak as argument:* moving, and entirely irrelevant to whether the Lab should be funded. *Mitigation:* clearly framed as a personal recommendation in a dedicated segment, not offered as evidence. **Tone of voice.** Warm, digressive, self-deprecating, and notably non-defensive. The hosts are affectionate toward their own community and generous with credit, sometimes at the cost of focus — several minutes go to conference chat and name-checking prior guests. Harbuz is earnest, precise when technical, and repeatedly comfortable saying he does not know. The register is insider-to-insider: it assumes you already care about open source sustainability and know most of the names. There is no adversarial content anywhere, and the one moment of real challenge (board composition) is absorbed graciously. ## 🛡️ DARVO Analysis **Not applicable to this source.** No one is accused of wrongdoing at any point, so the pattern has nothing to attach to. - **Deny.** ⚪ Absent. The nearest thing to a defensive moment is the guest being pressed on the Lab's structure and £500 balance — and he concedes rather than denies, answering candidly that funding is needed and unresolved. - **Attack.** ⚪ Absent, and conspicuously so. Companies that under-fund open source are the natural target for blame, and he declines to attack them, framing the problem as informational ("relies more on open source than they realize") rather than moral failure. Adjacent organizations are praised, not positioned as rivals — "let's be friends." - **Reverse victim and offender.** ⚪ Absent. The one place the pattern *could* have appeared is the origin story, where a former employer discusses exploitation — and it runs the opposite direction. He casts himself as the offender ("I was a bad guy," "an exploitative employer") with no reassignment of blame to employees, market conditions, or circumstance. That is the inverse of DARVO and worth noting as such. Do not tag this document with any `#darvo/*` value. ## 🎯 Conclusion **Bottom line.** The most useful idea here is the recursion: open source funding is blocked not by unwillingness but by unknowability, and the measurement infrastructure required to unblock it is itself the least fundable work in the ecosystem. The binary-dependency example makes that abstract point concrete and gives it a security-risk framing that will move corporate budgets in a way that appeals to fairness will not. Against that, the Lab launches with roughly £500, an unproven grant strategy, and a founding argument that is structurally self-serving — a tension the guest names himself rather than hiding. Diagnosis: excellent. Plan: candidly incomplete. **Next steps.** 1. Run the compiled-dependency audit against something you own — this is a testable claim with real security stakes, not a theory. 2. Cross-link into `llm-wiki-wp-governance` and `llm-wiki-fair-cms`: the criticality-measurement problem here is the same one the Crossword/Josepha episode identified in WordPress, arriving from a completely different direction. Two independent sources, one gap. 3. Track Miranda Heath's AI-and-maintainer-mental-health report; it will be the citable source on AI contribution load. 4. Note the Five for the Future parallel — "how do you recognize partial commitment without diluting the standard" is live in both programs, unsolved in both. ## 🧱 Refactor Appendix ### Literature Split Pad #### L1 — The funding recursion: allocation infrastructure is itself unfunded `#atom/literature/h1` > [!quote] there's infrastructure and research that's needed to identify those projects to be able to fund them. And you know what's also not sustainably funded? That very infrastructure and research that is required to make open source stable Claim: the prerequisite for solving open source funding is itself the least fundable work. The episode's central and most original idea. #### L2 — Download metrics are automation artifacts, not reliance signals `#atom/literature/h1` > [!quote] how do I know that that's someone that's sort of meaningfully using it and relying on it. How do I know that's just someone that ran their CI 100,000 times and it's just a computer doing all of those downloads? Claim: the dominant funding-allocation metric measures machines, not humans, making allocation a popularity contest by accident. #### L3 — Compiled dependencies are invisible to manifest-based analysis `#atom/literature/h1` > [!quote] when analyzing your manifest and your dependency trees, especially at larger scales, that stuff doesn't show up. And so if those projects have security vulnerabilities, those security vulnerabilities affect you as a company that depends on that stuff, but you have no idea. Claim: manifest-derived SBOMs are incomplete by construction wherever native/compiled dependencies exist. The strongest actionable finding in the episode. #### L4 — The flat per-developer ask breaks at scale `#atom/literature/h2` > [!quote] all of a sudden you're looking at 10 million, $50 million that these companies that were asking them to pay per year. I think that I don't know what the best thing to do is Claim: linear-in-headcount funding asks become prohibitive for large employers, forcing a choice between dilution and exclusion. Explicitly unresolved. #### L5 — Value judgments are legitimate allocation inputs `#atom/literature/h2` > [!quote] We don't have to start from like abstract theoretical sort of neutrality and purity, but we might want to go, hey, here's this thing that I care about as a human being, as a citizen. Claim: criticality is partly a values question, not purely a graph-theoretic one. Philosophically interesting; reintroduces an adjudication problem. #### L6 — Non-code contribution carries a prestige discount `#atom/literature/h3` > [!quote] there's also a kind of respect that is given to technical work that it feels more prestigious sometimes... those kinds of work are not always understood Claim: design, UX, copywriting, and localization are underfunded because they are less legible as "real" work, not because they matter less. npmx offered as the counter-model. #### L7 — Founder accountability, inverted `#atom/literature/h3` > [!quote] one day I realized I was a bad guy in that I was an exploitative employer and then I felt very sad and regretted my decisions. Claim: the origin narrative is built on self-indictment rather than vision — the structural inverse of DARVO and rare in founder storytelling. ### Atomic Split Pad - **Z1 — Prerequisite starvation `#atom/zettel/z1`.** Systems that allocate resources need measurement infrastructure to allocate well, but measurement is a prerequisite and prerequisites attract no funding because they produce no visible outcome. Generalizes far past open source — to grantmaking, public health, and platform governance. Links to `[[criticality-vs-activity]]`. - **Z2 — Proxy metrics select for what is countable `#atom/zettel/z1`.** When the only cheap measure is a count, allocation drifts toward whatever generates counts. Downloads measure automation; activity measures enthusiasm; neither measures dependence. - **Z3 — Invisible dependency classes `#atom/zettel/z1`.** Every dependency system has a visibility boundary. Transitive deps, OS packages, and compiled/binary artifacts fall outside manifest-based analysis. Security exposure concentrates precisely where visibility ends. - **Z4 — Recognition thresholds create a dilution dilemma `#atom/zettel/z1`.** Any program with a public standard must choose between honoring partial compliance (diluting the signal) and ignoring substantial contribution (losing participants). Applies identically to Five for the Future. Links to `[[five-for-the-future]]`. - **Z5 — Legibility determines funding, not value `#atom/zettel/z1`.** Work is funded in proportion to how easily a funder can narrate its impact. Illegible work — infrastructure, maintenance, design, measurement — is systematically starved regardless of importance. Links to `[[public-toilets-problem]]` from the Crossword/Josepha episode: the same phenomenon named from two independent directions. - **Z6 — Pass-through funding `#atom/zettel/z1`.** Removing the intermediary (companies pay maintainers directly; the program never touches the money) trades allocation expertise for trust and low overhead. An explicit design choice with real tradeoffs. ### Fleeting Queue - `#atom/fleeting/f1` "Public toilets" (Josepha) and "prerequisite starvation" (Harbuz) are the same idea derived independently in two 2026 podcasts. That convergence is itself the article. - `#atom/fleeting/f1` Does WordPress core have a compiled-dependency blind spot? PHP extensions, image libraries, bundled vendor code — worth an actual audit rather than a guess. - `#atom/fleeting/f1` Tide was WordPress's attempt at exactly this measurement infrastructure, and it stalled. Reread that history against the "prerequisite starvation" frame. - `#atom/fleeting/f1` £500 in the Open Collective on launch day against $7.2M moved by the Pledge — the gap between moving money and being funded is the whole thesis, accidentally demonstrated. - `#atom/fleeting/f1` Five for the Future's "aspirational not required" framing is the same dilution-dilemma answer the Pledge is currently struggling with. Cross-reference both. - `#atom/fleeting/f1` Chad Whitacre: founded the Pledge and this podcast, now offline making zines and working at Home Depot. There's a piece in there about what open source costs the people who fix it. - `#atom/fleeting/f1` Third batch document with systematic ASR corruption of technical terms and names. Time to fold a caption-cleanup or name-verification step into the deep-read skill itself. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Episode 292 Vlad-Stefan Harbuz Launching the Software Stewardship Lab.md|Episode 292: Vlad-Stefan Harbuz: Launching the Software Stewardship Lab by YouTube]] ## Highlights - word. Vlad tell me how you ended up in that chair. What happened? >> Okay so let me give you a bit of background. So I've been working in a software for a long time and I used to just run a software company and in doing so I became a little bit upset with myself because basically we had a bunch of employees that were building the software and then one day I realized I was a bad guy in that I was an exploitative employer and then I felt very sad and regretted my decisions. At the same time I realized that it's not super easy to figure out all the best ([View Highlight](https://read.readwise.io/read/01kze79ye82rweyvcxdsepyvbr)) - Note: L7 — Founder accountability, inverted. The origin story is built on self-indictment ("I was a bad guy... an exploitative employer... regretted my decisions") rather than vision. Structurally the OPPOSITE of DARVO: he casts himself as the offender with no reassignment of blame to employees, market, or circumstance. Worth filing against the Josepha/Crossword contrast, where the word "regret" appears zero times across a 7,900-word interview with a former project leader. Two founders, two eras, opposite postures toward their own record. - Tags: atom/literature/h3, open-source-sustainability, open-source-leadership - know that that's someone that's sort of meaningfully using it and relying on it. How do I know that's just someone that ran their CI 100,000 times and it's just a computer doing all of those downloads? So these metrics are best proxies currently. That's actually a big part of the stuff that we want to do at the stewardship lab is improve these kinds of metrics and create services and infrastructure. So Andrew Nesbet is one of the directors. He's the creator of ecosystems and ecosystems obviously is tremendously helpful. So I think that's one thing but I think another thing is ([View Highlight](https://read.readwise.io/read/01kze7874nz63cymsdhkqtmgjj)) - Note: L2 — Download counts measure machines, not humans: a million downloads may be one CI job looping 100,000 times. Funding allocation therefore becomes a popularity contest by accident rather than design. Proxy metrics select for what is countable. NAME NOTE: "Andrew Nesbet"/"ecosystems" is ASR corruption for Andrew Nesbitt / Ecosyste.ms — see the corrections table in the notes; nearly every proper noun in this transcript is garbled. - Tags: funding-models, atom/zettel/z1, dependency-graphs, atom/literature/h1 - not fair so on the one hand we're sensitive of that kind of thing. But then we had Zeroda who's giving almost the most out of anyone. Zeroda is an Indian stock broken. They are really incredible in their support for open source. So on the one hand, you know, we want to think about that. On the other hand, we see companies sort of giving more. But also specifically to your question, I do also recognize that on the high end, it becomes difficult because you start to see some really big numbers in terms of really large companies that employ thousands of people and all of a sudden you're looking at 10 million, $50 million that ([View Highlight](https://read.readwise.io/read/01kze79b13qamay32fqsend9v0)) - Note: L4 — The dilution dilemma, unresolved and stated honestly. A flat $2,000/developer ask becomes $10–50M for employers with thousands of devs. Recognizing smaller gifts risks "watering down the pledge"; refusing to celebrate $500k is also wrong. Current workaround: a subdivision joins rather than the whole company. DIRECT PARALLEL to Five for the Future's "aspirational, not required" — every public-standard program must choose between honoring partial compliance (diluting the signal) and ignoring substantial contribution (losing participants). Note he raises purchasing-power-parity as a fairness concern and then argues against himself with Zerodha (ASR: "Zeroda"), an Indian firm among the most generous. - Tags: atom/literature/h2, open-source-pledge, governance, funding-models - it's difficult for open source projects to get funding. However, there's infrastructure and research that's needed to identify those projects to be able to fund them. And you know what's also not sustainably funded? That very infrastructure and research that is required to make open source stable, which is something that is in the interest of you know not only the open source community but also the companies that rely on open source. So to me it's a little bit ironic that often exactly the kind of work that's required for open source stability it's difficult to fund that work and so that's why I ([View Highlight](https://read.readwise.io/read/01kze7800cjxc24xf19qw50vnb)) - Note: L1 — THE central idea: the funding recursion. Allocating money requires measurement infrastructure to know where it should go; that infrastructure is itself the least fundable work in the ecosystem. Prerequisite starvation — generalizes past open source to grantmaking, public health, platform governance. NOTE this is also structurally special pleading (the recursion terminates conveniently at the speaker's own new organization), which he flags himself as "ironic" rather than hiding. Same phenomenon Josepha called "public toilets" in Crossword S11E10 — two independent 2026 sources deriving the same gap from opposite directions. - Tags: funding-models, atom/zettel/z1, atom/literature/h1, open-source-sustainability - dependencies. Maybe I'll give like a super quick intro to that. Usually when you depend on stuff you depend on the source code of a different package. But sometimes you depend on a compiled form of a different package. So this happens for example because I might write some Python code. The Python code might depend on something like NumPy which is fine because I depend on its source code but numpy depends on things like open blast which are written in C. And so that C code is dependent upon in compiled form. What that means though is that it doesn't show up in the manifest. ([View Highlight](https://read.readwise.io/read/01kze7928p1afj9sc41scs46b5)) - Note: L3 — The most actionable finding in the episode. Python → NumPy (source, visible) → OpenBLAS (C, consumed COMPILED, invisible in the manifest). Manifest-derived SBOMs are incomplete by construction wherever native extensions exist, so vulnerabilities in compiled deps are exposure you cannot see. This is the self-interest argument that moves corporate budgets where "support maintainers" does not. ACTION: audit something you own for this — WordPress has an analogous surface in PHP extensions, image libraries, and bundled vendor code. ("open blast" = OpenBLAS, ASR.) - Tags: dependency-graphs, atom/zettel/z1, atom/literature/h1, software-supply-chain