# Who maintains the PHP you run? A version signed off by the people who maintain it, buyers who require that signature, and money that flows down the chain: what changed in v1.2.0, sgit.ai > The changes to the article "Who maintains the PHP you run? A version signed off by the people who maintain it, buyers who require that signature, and money that flows down the chain" in v1.2.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Who maintains the PHP you run? A version signed off by the people who maintain it, buyers who require that signature, and money that flows down the chain](../../who-maintains-the-php-you-run.md) / [Versions](../who-maintains-the-php-you-run.md) / v1.2.0 # Who maintains the PHP you run? A version signed off by the people who maintain it, buyers who require that signature, and money that flows down the chain: what changed in v1.2.0 From v1.1.0 (2026-10-23, `e50452d9f`) to v1.2.0 (2026-10-24, `ac82adf34`), paragraph by paragraph. 45 paragraphs added, 9 removed, 8 changed in place, 32 unchanged. About 2,613 words added and 423 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [← v1.1.0](v1.1.0.md) · [all versions](../who-maintains-the-php-you-run.md) · [v1.3.0 →](v1.3.0.md) # Who maintains the PHP you run? A version signed off by the people who maintain it, buyers who require that signature, and money that flows down the chain: a follow-up to the maintenance deficit: a market failing both ways, the services and business models that should exist now, and why the money has to reach the people who know the codedeficit Summary: A follow-up to the maintenance deficit, with evidence, whichandfollowedthis time with the solutions first. My proposal is simple to state. Every version of an open source platform that a product depends on should be signed off, cryptographically, by the people who maintain that platform, who help set it up, support it and patch it. Buyers, governments first, should refuse to buy products whose core pieces do not carry that signature. That creates a financial flow all the way down the chain, from the buyer to the product, to the platform, to the maintainers, and a commercial ecosystem of companies that provide the assurance, the maintenance and the ability to patch that php2shell showed we need. It is many small purchases, not one large one: the money spent maintaining the core pieces of an application should be in proportion to the money spent on top of PHP; this one follows what should be bought instead. php2shell asks every organisation that switched a website off one of two questions. Either the site does not matter,project, and it can stay off. Or it matters, there is a real cost to it being down, and somebody has to payaddtovaluekeepall the time, not sit there as insurance. And it maintained.scalesTodaynowalmostbecausenobodyofisGenpaying, and that isAI, not because Gen AI writes the moneycode,isbutmissing;because it ishelpsbecausepeople understand code bases, side effects and changes, so customised support can be sold at a price that makes sense. Today the market is failingfails both ways. Theways: organisations that runrunning PHP have no maintenance of exactly what they run to buy. The people who know PHP best, its core developersbuy, and thePHP'speople around its foundation,experts have no product to sell them: the foundation sells sponsorship tiers, and its packager for Debian and Ubuntu does it "mostly in my free time".sell. When the flaws landed, the PHP security team wrote the fixes and published source backports for old versions for free,free and vendors soldresoldbuilds of those fixesthem within a day,day.withInnoWardley'sstated share flowing back. One model shows it can be different: since 2024terms, the OpenJS Foundation has endorsed a vendor that shares 15% of its revenue with the projects it supports. So heremaintainers are the servicestown planners: paid to read, maintain and sign off the code, pushing quality downstream, with their certification something insurers can price and regulators can require as a licence to operate. Here is the case I thinkmake on open-source.sgit.ai and at RiskMandate, the seven services that should exist now, starting with bringing the switched-off sites back, and thehowrulestheythatcanwouldbemake the money flow to the people who maintain the code. This is not about leaving open source; it is about fixing its economics, for PHP first, then Node, Python and the rest.sold. 2 unchanged paragraphs ## In short {#in-short} • **Two questions for every site switched off.** Does it matter? Then who pays to keep it maintained? • **The market is failing both ways.** No maintenance to buy, no maintenance to sell. • **The fix was written for free.** And sold within a day by vendors, with no stated share flowing back. • **The best maintainers are the experts.** The workflow to hire them for what you run does not exist. • **It can work.** OpenJS has had a 15% revenue-sharing partner since 2024. • **Seven services should exist now.** Starting with bringing the switched-off sites back. • **Not leaving open source.** Fixing its economics, for every ecosystem. ## In short: what I am proposing {#in-short} • **A version signed off by the people who maintain it.** The maintainers of PHP sign, cryptographically, the builds they stand behind, and help set them up, support them and patch them. • **The maintainers are the town planners.** Paid to read the code, maintain it and sign it off; they push quality downstream, and their certification is what insurers and regulators can rely on. • **Buyers require the signature.** Governments and companies stop buying products whose core open source pieces do not carry it. • **The money flows down the chain.** From the buyer to the product, to the platform, to the people who maintain what it depends on. • **Many small purchases, in proportion.** Maintaining the core is a cost line in every project, sized to the project's own spend, and it adds value all the time. It is not insurance. • **Gen AI makes it scale.** Not by writing the code, but by helping people understand code bases, side effects and changes, so customised support costs what it should. • **No signature is a mapped risk.** We now have the data to map what each organisation depends on, and who maintains it. • **Seven services, and a way to sell them.** Starting with bringing the switched-off sites back: paid to map, paid to engineer, retained to maintain. • **Why it is needed.** The market fails both ways: no maintenance to buy, none to sell. This week the fix was written for free and resold within a day. ## The case I have been making {#the-case} Before the PHP details, where I am coming from, because this article is an application of an argument I have been making for a while, and of a business I am building on it. On [open-source.sgit.ai](https://open-source.sgit.ai/) I make the case that open source is a strategy, not a charity, and that its real value is in highly customised, maintainable and, in a way, smaller versions of the applications and packages people run. Most organisations use a fraction of what they install. As I put it there: "a company might only need 10% of them. So we create a version with only 10% of the features. It has much less attack surface, it is much cheaper to run". Customisation is not only addition, it is subtraction. And the people best placed to build and maintain those versions are the people who maintain the code: "A consultancy can study the package. The maintainer is the package." What is missing today is the connection between them and the people who use the software: "The relationship is missing because the platform is missing." At [RiskMandate](https://riskmandate.ai), the company I co-founded, we are turning that into a commercial model: every customer version is built on the open-source base, the customer decides what stays private, and the revenue comes from the work customers ask us to own, mapping, engineering and above all maintaining, not from access to closed code. So I have a commercial interest in what follows, and I would rather say so up front. php2shell is that argument with the market already in place. The PHP story's source watch tracks 295 sites that somebody named as taken offline this week, each run by an organisation that has just discovered, in the worst way, that it runs software nobody is maintaining for it. The need for these services is not hypothetical; it is the list of sites switched off this week. What has to be managed and mapped is that direct connection: who maintains each piece of what an organisation runs, and how they are paid. ## A version signed off by the people who maintain it {#signed-off} [figure mk-signed-chain.webp] The signature that makes the money flow: the buyer requires a signed-off version; the product's supplier gets the platform it builds on signed off by that platform's maintainers, who sign off what they depend on in turn. Signatures go up the chain, money comes down it, and Gen AI scales the work at every step. | concept This is the idea I think makes the rest work. A version of an open source platform, the one a product actually ships with, should be signed off by the key authors of that technology. Not a logo, not a sponsorship: a cryptographic signature on a specific build, saying the people who maintain this code know this version, stand behind it for this use, and will help maintain it and patch it when something like php2shell lands. Those maintainers are involved in the set-up and the maintainability of the application built on top, and they provide a level of support for it. The pieces already exist. PHP's release managers have signed the project's release tags in Git since April 2012, so the source can already be proven to come from them. What does not exist is the next step: a signature on the version a customer runs, from the people who know the code, with a commercial relationship behind it. Then comes the part that turns it into a market. Governments first, and then any organisation that buys software, should say: we will not buy your product unless its core platforms are signed off by the people who maintain them. That single procurement line creates a financial flow all the way down. The supplier of a council's portal pays for the sign-off of the CMS it builds on; the CMS's maintainers pay for, or provide, the sign-off of the PHP underneath. And it creates a commercial ecosystem for the companies that provide that assurance, that signature, that maintenance, and the ability to patch quickly that we needed this week. ## The maintainers are the town planners {#town-planners} In the language I used for [explorer coding](https://newsroom.sgit.ai/articles/explorer-coding.html), there are three kinds of work on any piece of software. Explorers build by talking to an agent, and what they build is the brief. Villagers maintain what other people have started to depend on. Town planners own the code in production. PHP, the runtime under a large share of the web, is about as far towards commodity as software gets, and the people who maintain it are its town planners. That is the role they should be paid for: to read the code, to maintain it, and to sign it off. Signing off is already how the most mature projects work. The Linux kernel's [rules for AI coding assistants](https://docs.kernel.org/process/coding-assistants.html) say "AI agents MUST NOT add Signed-off-by tags" and "Only humans can legally certify the Developer Certificate of Origin". A signature means a person has read it and answers for it. What I am proposing extends that from the code a project accepts to the versions its users run. Because they sign, town planners will have no patience for what they do not support, and that is a feature. It pushes quality downstream. If a product does too much that is unsafe on top of PHP, an unsupported extension, a private fork nobody can patch, a version left far behind, the people who maintain PHP will not sign it off, and the buyer of that product will see that they did not. That signature also connects to insurance. A certified application is a risk an insurer can price: the people who know the platform have said what they stand behind. An uncertified one is on its own. And for the services that matter most, a government login, a bank's portal, a hospital's records, it becomes a question of a licence to operate: should a service like that run on a platform nobody who maintains it has signed off? That is where regulators can come in, and where the money becomes non-negotiable. ## Why it scales now {#gen-ai} First, the caveat: this is not about Gen AI magically writing all the code, or Gen AI as a massive thing in the middle. The maintainers still read the code; that is the point of their signature. What Gen AI changes is everything around it. It helps people understand code bases, the side effects of a change, the architecture and the changes between versions. It scales the non-functional work: the maintenance, the support, the testing, the documentation, the explanation of what a patch does to a particular customer's version. That is what makes mass-customised support possible at a price that makes sense, and that is what was missing. Before, signing off thousands of customer versions would have needed thousands of experts. Now the right experts can cover far more of them, with the tools doing much of the reading and checking around them. ## Many small purchases, in proportion {#proportional} This is not about charging a large amount for one thing. It is about lots and lots of small purchases, aligned with the money each organisation already spends. The amount spent maintaining the core pieces of software an application depends on should be in direct proportion to the money spent on, and available in, that project. A €100,000 site and a €10 million programme should both carry a maintenance line for their platform, sized accordingly. And it has to add value all the time. If it is seen as insurance, it is the first thing cut. It should show up as patches applied, versions kept current, code removed, questions answered, set-ups reviewed, every month. Maintaining the core platforms has to become a cost item in every project; when it is not there, that should be visible as a risk. That is a place where we now have data: for PHP alone, the Dutch NCSC's inventory lists 751 products that ship or depend on it, and the PHP story's source watch tracks 295 sites named as switched off. The same mapping can show, for any organisation, what it depends on, how much it uses, and whether anyone is maintaining it. 14 unchanged paragraphs, under Two questions {#two-questions}, A market failing both ways {#both-ways}, What happened to the old versions {#old-versions} ## ItThecanbestwork:thattheexistsOpenJS modeltoday {#openjs} ThereThe closest thing to a working model today is ainmodel that shows how.JavaScript. In May 2024 the OpenJS Foundation, home of Node.js and much of the JavaScript world, [announced an Ecosystem Sustainability Program](https://www.linuxfoundation.org/press/the-openjs-foundation-announces-the-ecosystem-sustainability-program-with-herodevs-as-the-first-partner) with HeroDevs as the first partner. Partners sell commercial security fixes for end-of-life versions; they must be endorsed by the project's own core team; and HeroDevs is "contributing a 15% revenue share to all OpenJS Foundation projects participating in the program." ThatIt is the shapebest that can happen right now, and it is not what I wantthinkforshouldPHP:happen. The maintainers stay at one remove: a vendor sells the peoplefixes and the project receives a share. What I am proposing is more direct: a commercial decision by everyone who maintaindepends on the codecode,endorsewithwhothemaymaintainers'sellownitssignaturelong-termonmaintenance,theandversionatheystated share of every sale flows back to them.support. Other models point the same way from different angles: Tidelift says it pays maintainers "income based on a number of factors, including customer usage"; the Open Source Pledge asks companies for $2,000 a year per developer they employ; GitHub Sponsors passes on 100% of personal sponsorships. None of them is yet the default way an organisation running PHP buys maintenance. 2 unchanged paragraphs, under Why the experts {#experts} I have done this commercially, and I am doing it again at RiskMandate; I have seen what happens when it does exist. When the company that maintains a piece of software is directly connected to its source code, and is responsible for maintaining it at scale for many customers, it invests in exactly the things that make maintenance cheaper: the scalability of the process, the tooling for customised versions, the tests that make a back-port safe. That investment goes back into the code everyone uses. A consultancy that patches one site and moves on has no reason to make that investment, and no way to. 3 unchanged paragraphs, under The services that should exist now {#services} 1. **Bring it back.** The market that exists this week: restore the sites switched off as a precaution. Map what each site can reach, cut what it does not need, patch, name the signals to watch, restore. That is the workflow in [application behaviour policies](https://newsroom.sgit.ai/articles/application-behaviour-policies.html), priced per site. 2. **A maintained build.** PHP as the customer runs it: only the extensions they use, fixes back-ported to the versions they cannot leave yet, signed, on time, by people connected to the code. 3. **Patch on behalf.** The same for everything on top: the CMS, its modules and plugins, fixed and tested on the customer's own copy. Every piece of software people depend on should have someone paid to apply its fixes. 4. **Remove what is not used.** The most important question in any of these sites is why the code is there at all. PHP makes this easier than most: it is interpreted, so you can see which files and functions a site actually runs, and build PHP with only the extensions it needs. In [the code you do not ship](https://newsroom.sgit.ai/articles/the-code-you-do-not-ship.html) a real tool went from 1,500 files to 428 for one use case. The cheapest patch is the code that is not there. 5. **The dependency register.** For each piece of software an organisation runs: how much it depends on it, how much it uses it, and how well it is maintained. The maintenance deficit ratio, per dependency. A risk the executive signs, knowingly. 6. **The incident desk.** An independent assessment in hours, from captured evidence, as the [PHP story's own site](https://php.oct.2026.newsroom.sgit.ai/) did in a day, so the next shutdown is a decision with a map. 7. **The endorsed partner.** Partners endorsed by the foundation that maintains the code, with a stated revenue share, as OpenJS does; and the line a procurement can require. 1. **Bring it back.** The market that exists this week: restore the sites switched off as a precaution. Map what each site can reach, cut what it does not need, patch, name the signals to watch, restore. That is the workflow in [application behaviour policies](https://newsroom.sgit.ai/articles/application-behaviour-policies.html), priced per site. 2. **A maintained build.** PHP as the customer runs it: only the extensions they use, fixes back-ported to the versions they cannot leave yet, signed, on time, by people connected to the code. 3. **Patch on behalf.** The same for everything on top: the CMS, its modules and plugins, fixed and tested on the customer's own copy. Every piece of software people depend on should have someone paid to apply its fixes. 4. **Remove what is not used.** The most important question in any of these sites is why the code is there at all. PHP makes this easier than most: it is interpreted, so you can see which files and functions a site actually runs, and build PHP with only the extensions it needs. In [the code you do not ship](https://newsroom.sgit.ai/articles/the-code-you-do-not-ship.html) a real tool went from 1,500 files to 428 for one use case. The cheapest patch is the code that is not there. 5. **The dependency register.** For each piece of software an organisation runs: how much it depends on it, how much it uses it, and how well it is maintained. The maintenance deficit ratio, per dependency. A risk the executive signs, knowingly. 6. **The incident desk.** An independent assessment in hours, from captured evidence, as the [PHP story's own site](https://php.oct.2026.newsroom.sgit.ai/) did in a day, so the next shutdown is a decision with a map. 7. **The signed-off version.** A build signed by the people who maintain the code, with their involvement in its set-up and support, and a stated share of every sale flowing to them; the line a procurement can require. ## How we are thinking of selling it {#selling} [figure mk-options.webp] Ways to make money selling open source software, as RiskMandate is mapping them: paid to map one workflow or site; paid to engineer the implementation; a scoped custom version built on the open-source base; and recurring maintenance priced by criticality (standard, operational, critical). Every customer version is built on the open-source base; the customer decides what stays private. | concept Here is how we are mapping the ways to make money selling open source software at RiskMandate, in the words of our current proposal. They are directly applicable here, and they are still proposals, not proven revenue. • **Paid to map.** One workflow, one accountable owner, what the system can actually reach against what the business approved, the gap, the control options and a decision. For a switched-off PHP site: what does it run, what does it reach, what does it need, and what would make it safe to bring back. Proposed as a bounded engagement (£5,000 in the current proposal). • **Paid to engineer.** Deeper mapping, implementation design, integration or a proof of concept, acceptance tests and a handover (£25,000 in the current proposal). • **A scoped custom version.** Built on the open-source base, with private adapters and configuration, deployment hardening and a supported release. For PHP, this is the smaller build: only the extensions and code the site uses. • **Retained to maintain.** Compatibility, change review, regression tests, evidence refresh, response and continuity. Priced by what is at stake: standard (supported releases, quarterly review, dependency compatibility), operational (monthly change review, a regression suite, an incident response target), and critical (reserved capacity, rapid response, a continuity drill, current evidence). • **Small public products** as a lightweight on-ramp, from £10 to £1,500. Three lines from that proposal carry the logic. "Paid to map. Paid to engineer. Retained to maintain." Revenue follows "the work customers ask RiskMandate to own", not access to closed code. And "Contract value follows the obligation accepted": maintenance can be worth more than the first implementation, "if the additional support burden is measured and priced." A council's citizen login and a university's archive wiki both run PHP; they should not buy the same maintenance, and today neither can buy any. The part that matters most for this article: "Less unique code" makes a version "Easier to maintain, audit, replace and hand over", and improvements that are not sensitive can go back to the open base when the customer permits. That is how the maintenance of one customer's version feeds the code everyone runs. 1 unchanged paragraph, under Towards regulation {#regulation} The path I would like to see is that this becomes easy first, and then required. Easy: the PHP Foundation, or any foundation, publishes how a company becomes an endorsed maintenance partner, and the share it pays; buyers can find one. Required: public procurement asks, for every open source dependency a contract relies on, whether its version is signed off by the people who maintain it, who maintains it and how they are paid, with a maintainer line item in the budget, as Tiffany Farriss of the Drupal Association has proposed, according to Dion Wiggins; and regulation such as the EU's Cyber Resilience Act, which makes manufacturers answer for the open source in their products, recognises endorsed maintenance as a way to meet that duty. 5 unchanged paragraphs, under Not only PHP {#beyond}, What this does not claim {#limits} • **The signed-off version is a proposal.** Signed release tags exist; I found no offer of signed customer versions with the maintainers' support behind them. • **Gen AI scales the work around the code.** It does not replace the maintainers reading it. • **Insurance and a licence to operate are proposed links.** They describe what could follow, not what insurers or regulators require today. • **RiskMandate's options are a proposal too.** The prices are anchors in a current proposal, not published pricing (the public site lists £10 to £1,500), and the commercial proof is still being built. • **I have a commercial interest.** RiskMandate sells this kind of work. 5 unchanged paragraphs, under Where this comes from {#sources} My voice memo of 23 October 2026; a research pass on PHP's commercial support, checked against the sources: [php.net](https://www.php.net/)'s advisory of 21 October; the [PHP Foundation](https://thephp.foundation/) and its [sponsorship tiers](https://thephp.foundation/sponsor/); [Zend's post of 22 October](https://www.zend.com/blog/php2shell-patches-now-available); Ubuntu's security pages for CVE-2026-109618; TuxCare's and HeroDevs' php2shell posts; [Freexian's PHP LTS](https://www.freexian.com/lts/php/); [deb.sury.org](https://deb.sury.org/); the [OpenJS programme announcement](https://www.linuxfoundation.org/press/the-openjs-foundation-announces-the-ecosystem-sustainability-program-with-herodevs-as-the-first-partner); Tidelift, the Open Source Pledge and GitHub Sponsors; [open-source.sgit.ai](https://open-source.sgit.ai/)'s pages on [open core or packaging](https://open-source.sgit.ai/views/open-core.html), [funding](https://open-source.sgit.ai/funding/index.html) and [somebody has to be the villagers](https://open-source.sgit.ai/views/villagers.html); RiskMandate's current commercial proposal (October 2026); and the [Cyber Safety Review Board's Log4j report](https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf). Related:[explorer coding](https://newsroom.sgit.ai/articles/explorer-coding.html), [software vendors as villagers](https://newsroom.sgit.ai/articles/software-vendors-as-villagers.html),[the maintenance deficit, with evidence](https://newsroom.sgit.ai/articles/the-maintenance-deficit-with-evidence.html), [application behaviour policies](https://newsroom.sgit.ai/articles/application-behaviour-policies.html), [the code you do not ship](https://newsroom.sgit.ai/articles/the-code-you-do-not-ship.html), [the eyeballs get cheap](https://newsroom.sgit.ai/articles/the-eyeballs-get-cheap.html), [open source is not free](https://newsroom.sgit.ai/articles/open-source-is-not-free.html). Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine. [← v1.1.0](v1.1.0.md) · [all versions](../who-maintains-the-php-you-run.md) · [v1.3.0 →](v1.3.0.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/who-maintains-the-php-you-run/v1.2.0.html)*