# Quarterly Progress Report - Q2 2026 > [!question] Lingering Questions > - Sponsor or community response to the new quarterly-report format hasn't been measured yet — did visibility actually change funding or staffing decisions? > - Severity and downstream-adoption data for the 100+ package security fixes shared with maintainers are absent — how many actually shipped in a release? > [!tip] Article Ideas > - Build a status table (RFC → implementation → release → WordPress-readiness) tracking PHP 8.6 proposals against WordPress core and popular-extension test suites. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Maintainer Attention Is the Scarce Resource in Open Source]] — directly related to this report's visibility-as-funding-infrastructure argument > - [[3. Resources/Permanent Notes/Maintenance Is Most of the Work but Gets No Prestige]] — same underlying claim from a different domain > - [[3. Resources/MOCs/Open Source Governance MOC]] ## Metadata - Source: [[3. Resources/Readwise/Articles/Quarterly Progress Report - Q2 2026]] - Publisher: The PHP Foundation, first quarterly contractor report, covering a 13-person core team across eight countries. ## Author's thesis PHP maintenance is distributed systems work in both the technical and organizational sense: engine correctness, sockets/streams/TLS, Windows builds, extension tooling, URI APIs, ecosystem security triage, php.net infrastructure, and public governance all combine to keep a language a large share of the web depends on dependable. The report's own existence is itself an intervention — the Foundation created it specifically to make routine, preventive maintenance work visible enough for sponsors to value. ## Key arguments (≤3) 1. **Maintenance is a portfolio, not a feature list.** Reliability depends on engine bugs, TLS, build tooling, CDN delivery, package security, extension tooling, and governance together — no single workstream carries the reliability story alone. 2. **Visibility is funding infrastructure.** The Foundation explicitly built this report to make normally-invisible contractor work legible to sponsors, on the theory that unseen work is harder to staff and defend during prioritization. 3. **Security work only reduces risk after adoption.** The Ecosystem Security Team paired vulnerability scans with 100+ fixes shared directly with maintainers — but a shared fix reduces risk only once a safe release actually reaches dependent systems. ## Claim atoms ### Maintenance is a portfolio Claim: Language reliability depends on more than core feature work. Evidence: the report spans engine bugs, TLS, builds, CDN delivery, package security, extension tooling, and governance. Limit: it doesn't quantify the relative cost or effect of each workstream against the others. ### Visibility changes maintenance funding Claim: Quarterly reporting can make routine and preventive work easier for sponsors to value. Evidence: the Foundation states this report exists specifically to improve communication about contractor projects. Limit: sponsor or community response hasn't been measured yet. ### Ecosystem security requires direct maintainer support Claim: Finding vulnerabilities creates value only when fixes are released and adopted downstream. Evidence: the security team paired scans with 100+ fixes shared directly with maintainers. Limit: severity and downstream-adoption data aren't published. ### Experiments need status labels Claim: Clear status labels prevent proposals and prototypes from being mistaken for shipped behavior. Evidence: the report distinguishes accepted RFCs, pending votes, early experiments, future targets, and paused work. Limit: status can and does change after publication, so the labels have a shelf life. ## Permanent candidates - **Maintenance visibility functions as funding infrastructure, not just communication** — supported by the "visibility changes maintenance funding" atom; a general claim about how invisible work gets starved regardless of domain. → promoted. ## Processing checklist - [ ] Track whether the 100+ package security fixes actually appear in subsequent releases and dependency updates - [ ] Map PHP 8.6 proposals against WordPress core and popular-extension test suites - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — maintainer funding, visibility, and sustainability infrastructure for open-source language projects