Half of them have not written an AI policy

The Linux Foundation published a survey this month and one number travelled much further than the rest of it. A quarter of incoming pull requests are low quality, generated with AI, and dropped on maintainers who then have to read them. The number is real. It is also the least useful thing in the report if you work in enterprise infrastructure, because it describes somebody else's inbox.

I went and read the report rather than the summary, which took about an hour, and there are three figures in it that nobody quoted and that change how I would think about consuming open source in a regulated estate.

What the survey actually is

Before the numbers, the shape of them. Navigating Open Source Software Development in the Generative AI Era is based on 234 qualified respondents, with a margin of error of ±6.41% at the 95% confidence level. Of those, 206 identify as contributors and 134 as maintainers, with heavy overlap between the two. It was a 45-question web survey, fielded April to June 2026, distributed through Linux Foundation newsletters and social media and through research partners. Red Hat sponsored it.

The finding that did not make the headline

Respondents reported average time reductions of 19% on proposal discussions and 52% on code authoring. Those are the numbers that produced the "cuts coding time in half" framing everywhere.

Further down, 21% of respondents reported that high-complexity tasks took them more time with AI assistance, not less.

That is the number I would put in front of an architecture team, because high complexity is most of what we do. Nobody is asking an infrastructure architect to write a parser. They are asking why the upgrade path breaks on one cluster out of ninety, or whether a design decision taken in 2023 still holds under a lifecycle date that moved. The report does not claim AI makes that work slower across the board. It records that for a fifth of the people doing the hardest work, it did.

The aggregate 52% is true and the 21% is also true, and they are not in tension. Easy work got much faster. Hard work got slightly worse for some people. Averaging them produces a number that describes nobody.

The policy numbers, stated precisely

The summaries said one in three projects have a formal AI contribution policy. That is accurate as far as it goes. The full distribution is more interesting:

So 45% of projects have taken a position, in one direction or the other. The remaining 55% have not written anything down. Not a permissive policy, not a restrictive one, nothing.

For a project maintainer that is an internal matter. For anyone pulling that project into a regulated enterprise it is a governance gap with a familiar shape, because it is the same gap we spent a decade closing on licensing and then again on software bills of material. Somebody eventually asks the question in writing, and then everyone has to have an answer.

An inconsistency inside the report

On disclosure, the body text reports that 52% of contributors say they disclose AI assistance most of the time or always, and 19% never do. The infographic published alongside it gives three in ten always disclosing and two in ten never.

Those do not reconcile. The body text and its underlying figure are the more detailed source and I would use them, but I cannot explain the difference from the published material, so I am recording it rather than picking the number that suits the argument.

What the report says separates the good contributions from the slop

It is not the tool. Sixty-one percent of contributors said they conduct line-by-line review and functional testing of AI-generated code before they submit it. The report also found 71% of maintainers agreeing that generative AI lowers the barrier to entry, and 53% disagreeing that it has improved community trust.

Lower barrier, no more trust. That combination is the whole story. The volume went up, the floor came down, and nothing in the process changed to tell a reviewer which submissions had a human standing behind them.

Which is a process problem, and process problems have fixes.

What this looked like in practice, last week

I reviewed a VCF Operations management pack from a regulated enterprise's perspective in September and published what I found. Four things that would decide whether it could go into a regulated estate, one of them a hardcoded certificate validation bypass on the vCenter connection carrying the service account credentials.

The maintainer, Iwan Rahabok, read it and used AI to do the remediation work. The repository now has a TLS module with three modes: Trust on First Use, which records the certificate thumbprint on first connection and compares it on every collection afterwards; Enabled, which validates the chain and hostname with a TLS 1.2 minimum; and Pinned, which enforces a supplied thumbprint before any credentials are sent. There are tests, including one that scans for unpinned calls. A SECURITY.md was added.

My published review was then wrong, because its lead finding had been fixed. So I went back and marked it, with a revision note recording what was addressed, what was partly addressed, and what I had not re-examined. The licence is still PolyForm Noncommercial, so finding four stands.

Four steps. A named reviewer with a specific finding. A maintainer who decided what to accept. Code with tests behind it. A public record on both sides saying what changed and when.

Remove any one of those and you get the pull requests in the survey. Remove the named reviewer and it is an unsolicited patch from a stranger. Remove the decision and it is automation committing to your repository. Remove the tests and it is plausible text. Remove the record and nobody downstream can tell what happened, which is the one that matters most to an enterprise consumer, because the enterprise is downstream.

The question your intake process is not asking yet

If you run an open source intake process in a bank, an insurer or a telco, it almost certainly asks about licence and it probably asks for an SBOM. On these numbers, there is a third question that belongs next to them, and more than half the projects you depend on currently cannot answer it.

The third question makes the first two mostly redundant, which is worth noticing. Projects with disciplined review were never the problem and are not the problem now. The survey is measuring what happens when volume arrives at projects that did not have that discipline to begin with, and generative AI did not create that condition. It found it.

What I would do with this

Not very much, immediately, and that is deliberate. One survey of 234 people does not justify rewriting a governance standard.

But the OpenSSF webinar on 3 November covers private fork maintenance at an estimated 5,160 labour hours per release cycle, alongside Cyber Resilience Act reporting, and the economics of that sit directly underneath this problem. If AI-assisted contribution is making upstream review harder, then the internal fork that your team maintains because upstream was too slow gets more expensive, not less. Those two things are the same conversation and almost nobody is having it in one room. Details are on the OpenSSF site.

And the next time you write an open source assessment, record which of the three questions above you could not answer. The gap is the finding.

Open items

Sources

• Navigating Open Source Software Development in the Generative AI Era, Sam Boysel and Anni Lai, Linux Foundation Research, 20 October 2026. DOI 10.70828/BUHS3754.
• Full report PDF, including the methodology section and Figure 17.
• Linux Foundation press release, 20 October 2026, announced at All Things Open.
• What a bank would ask before installing the vCommunity management pack, and its revision note of 30 October 2026.
• VCF-vCommunity-Adapter, Iwan Rahabok, commits of 29 October 2026.