Claim: Unfunded maintenance creates systemic security risk because critical components are widely reused without sustainable staffing.

• Log4Shell (Log4j): widely used Java logging library vulnerability exposed how understaffed infrastructure projects can be. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
• xz-utils backdoor attempt: shows social engineering and maintainer compromise risk in core tooling. https://en.wikipedia.org/wiki/XZ_Utils_backdoor

Conclusion: “Maintenance” is not optional work. It is security work. Procurement can fund it as operational necessity.

Claim: We overweight small-dollar fundraising because it is culturally familiar, but it cannot match the scale of public procurement.

• Donations/pledges: useful, but unpredictable and limited in scale.
• Procurement: budgets exist already; the question is what requirements they enforce (open deliverables, maintenance, upstream work).

Example pledge framing: attempts to normalize funding commitments in industry. https://opensourcepledge.com

Speaker point: This talk is not anti-donation. It is “stop pretending donations solve infrastructure funding.”

Claim: Open source is ubiquitous in delivered software, but funding and incentives do not match that dependence.

• 97% statistic: cite the Synopsys Open Source Security and Risk Analysis (OSSRA) report used for your slide claim. https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
• GovTech scale: frame as a large market where procurement rules determine who benefits. World Economic Forum GovTech framing. https://www.weforum.org/publications/the-global-public-impact-of-govtech/
• Public digital capability gaps: procurement and delivery reform context (UK review). https://www.gov.uk/government/publications/state-of-digital-government-review/state-of-digital-government-review

What to defend verbally: “Open source won the technical war; funding did not follow.”

Claim: Central grants are fragile. Procurement is distributed and recurring. That creates resilience.

• Grants end: timeboxed funding does not guarantee long-term maintenance.
• Political risk: centrally administered funds can be cut; distributed procurement spreads risk across many buyers.

Practical rule of thumb: When adopting OSS, allocate a predictable slice of delivery spend to upstream maintenance (your “~20%” example) and treat it as ongoing operations, not a one-time project cost.

Reference point (fund model context): Sovereign Tech Fund. https://www.sovereign.tech/

DPI layers:

• Open Source & Digital Public Goods: the engine
• Open Standards: the rails
• Open Data: the cargo
• Actually Open AI: all of the above?
• Open Communities: the governance

Procurement-ready evidence example: Accessibility Conformance Reports can be required and evaluated in a structured way. OpenACR is an open format and tooling initiative. https://openacr.org/

Claim: “Upstream-first” only happens reliably when it is a contractual deliverable with verification steps.

• Deliverable form: PR links submitted upstream, not just “we changed code.”
• Repo hygiene: LICENSE, README, CONTRIBUTING, CI, and public issue tracking establish provenance and continuity.
• Verification lever: small holdback/escrow tied to repository openness and basic checks.

Reference examples:

• Drupal RFP Guide: https://www.drupal.org/community/governance/rfp
• French public code guidance ecosystem (code.gouv): https://code.gouv.fr/

Claim: “Open deliverables” must be defined in contract language, verified, and tied to payment milestones.

• Open standards requirement: avoids hidden lock-in through proprietary formats and undocumented APIs.
• Repo requirements: public by contract close, with an OSI-approved license and working CI.
• Maintenance clause: define an option-year (or equivalent) for maintenance with explicit upstream contribution expectations and service-level commitments.

Support reference: Public Money, Public Code framing. https://publiccode.eu/

Claim: Procurement outcomes depend on staff capability and evaluation criteria, not just policy slogans.

• Training: officers need practical literacy in OSS risks (supply chain, maintenance, security updates) and mitigations (upstream-first, contracts that fund maintenance).
• Exercises: scenario-based learning builds confidence to enforce requirements and evaluate bids.
• Evaluation criteria: require evidence of upstream contribution history, maintainership plans, and open deliverables.

Reference points:

• DITAP overview: https://techfarhub.usds.gov/get-started/ditap/
• Open Contracting Partnership: https://www.open-contracting.org/

Why this matters: “Public Money, Public Code” is a simple procurement test: if the public paid, the public should be able to reuse, audit, and improve.

Reference: https://publiccode.eu/

Claim: Procurement is the largest lever because it controls where money flows and can create recurring maintenance funding.

• Fund open deliverables: require public repos, open licenses, and open standards.
• Recurring contracts: create predictable maintenance revenue, reducing burnout and improving security posture.
• Reuse: open deliverables let other agencies adopt without repaying for the same work.
• Small policy changes scale: one clause replicated across frameworks becomes structural funding.

Concrete procurement rule: “No public money without a public repo.” Tie it to verification (license, CI, issue tracker, release tags).

Optional budgeting rule: reserve a defined maintenance allocation for upstream work (your “1%” or “20%” framing).

Claim: Procurement can progressively increase openness without requiring a single “big bang” policy change.

1. Publish code at contract completion.
2. Publish at milestones (reduces lock-in earlier).
3. Develop in the open from day one (maximizes reuse and oversight).

Why it matters: Each rung increases reuse and reduces vendor capture by making work reusable earlier.

Source: Maurice Hendriks (NL Government) write-up of the Open Source Ambition Ladder.

What the handout provides: copy-paste procurement clauses, verification checklist, and evaluation prompts (upstream PR links, repo requirements, maintenance option years).

Reference links:

• Drupal RFP Guide: https://www.drupal.org/community/governance/rfp
• Sovereign Tech Fund: https://www.sovereign.tech/
• Open Contracting Partnership: https://www.open-contracting.org/
• French public code guidance: https://code.gouv.fr/

Licensing reminder: require an OSI-approved license and ensure the contract explicitly grants the right to publish deliverables publicly at or before close.