FreeBSD's Q3 2026 report includes an AI survey of 140 developers. Just 16% favor rejecting AI-assisted code outright. Meanwhile, AI scrapers keep attacking the project's infrastructure as developers work out the terms for accepting AI.
Key points
- What happened: In a survey of 140 FreeBSD developers, 88% wanted an AI policy and 16% favored outright rejection of AI-assisted code. Human accountability was the top principle, cited by 91%
- Where it matters in practice: AI wrote the NFS over RDMA server code. Without a policy in place, it is available as an unofficial port
- AI as an adversary: Scrapers collecting LLM training data continually attack FreeBSD infrastructure through botnets. The operations team calls them "trainers of probabilistic malware"
- The author's view: FreeBSD is debating when to accept AI in its code while defending infrastructure from AI-related attacks. The different roles AI plays inside one project reflect a wider tension in open source
Developers are open to using AI
FreeBSD Core Team members surveyed project developers about their use of AI and large language models (LLMs). 140 people responded.
The results show broad support for setting terms for AI use. 88% wanted some form of project AI policy. Of all respondents, 49% wanted a formal written policy and 39% thought lightweight guidelines would suffice. Only 6% wanted the project to explicitly discourage AI, and 3% said existing contribution rules were enough.
Responses split four ways on how to handle code produced with AI assistance. The largest share, 35%, wanted mandatory disclosure. Another 25% wanted stricter review than for human-written code, and 22% favored treating it like any other contribution. The smallest group, 16%, wanted it rejected outright.
In July 2026, GCC formally adopted a policy (in Japanese) rejecting LLM-generated code longer than roughly 15 lines. In Void Linux, a maintainer dropped 113 packages at once after being accused of violating its AI policy (in Japanese). QEMU moved from a blanket ban to allowing limited use under certain conditions (in Japanese). As projects take different approaches, FreeBSD's survey shows what its developers themselves think.
Human accountability and transparency lead the way
The breakdown shows that developers want conditions for using AI, with outright rejection attracting less support.
The most popular safeguard was mandatory human review, at 78%. Mandatory disclosure followed at 69%, documentation of provenance and licensing at 47%, and mandatory testing at 39%. Some 48% wanted AI use always disclosed and 36% wanted disclosure only for substantial involvement, giving 84% in favor of some disclosure. Marking AI use in commit logs drew 79% support, and naming the tool drew 56%.
Asked which principles the project should prioritize, 91% chose human accountability, the top response. Transparency drew 78%. Maintaining code quality was the leading goal for the policy.
Among quality concerns, correctness and subtle bugs came first at 39%. Copyright and licensing issues concerned 75% of respondents.
For AI-generated documentation, 65% would accept it with human review. Some 54% supported limited use of AI tools in project infrastructure, while 29% opposed it.
The survey informed the creation of an AI working group with members holding a range of views. It held its kickoff meeting on October 7 and plans a final report in Q4.
AI-written code already exists
The policy debate is already affecting concrete work.
The Q3 report's entry on NFS over RDMA (Remote Direct Memory Access) says generative AI produced the server-side code. Testing of the client side is going well, and it is expected to reach FreeBSD's main branch within weeks. The project cannot officially merge the server code while it lacks an AI policy, so the code is available as an unofficial port that builds a kernel module.
The lack of a policy prevents an official merge, which creates a practical reason to write one. The code arrived before the rules for accepting it.
"Trainers of probabilistic malware"
While FreeBSD debates how to accept AI contributions, scrapers collecting data for AI companies continue to attack its infrastructure.
The Cluster Administration Team reports that scrapers collecting LLM training data are attacking FreeBSD.org infrastructure constantly. Scraping has shifted from company infrastructure to botnets using residential proxies, which route traffic through household and business networks. This makes scraper traffic hard to distinguish from legitimate requests. The team says blocking it at the network edge risks substantial collateral damage.
The main target is cgit.FreeBSD.org, the web interface for FreeBSD source code. The report calls the scrapers targeting it "trainers of probabilistic malware." Traffic arrives continuously from compromised devices around the world.
During Q3, the Cluster Administration Team deployed additional cgit mirrors in California and Paris to spread the load. It reported spending considerable time mitigating distributed denial-of-service (DDoS) attacks that quarter.
The Bugmeister Team also lists this as its highest priority. It says the cause is known and the Core Team recognizes the severity, but Bugmeister has limited means to address it.
A volunteer operations team defends a cluster with 143 physical machines and 324 jails, for 467 installations across 14 sites. The traffic comes at botnet scale. The resources on each side remain uneven.
EU compliance and software bills of materials
Another source of pressure is the EU Cyber Resilience Act (CRA). Vulnerability and incident reporting requirements for manufacturers took effect on September 11, 2026. Reporting requirements for open-source software stewards begin on December 11, 2027.
The FreeBSD Core Team published a statement recognizing the FreeBSD Foundation as the project's open-source software steward. The foundation has prepared a cybersecurity policy and CRA reporting protocol and published guidance for business users and community members on its website.
A framework that automatically generates software bills of materials (SBOMs) at build time has entered review. An amd64 build produces 218 artifacts, with one for each base package and each library actually used in the build, enabling the full dependency chain to be traced. It supports SPDX 2.2 and Lite 3.0.1 output, with CycloneDX support underway. SBOM support for the ports tree is undergoing separate review.
The security team itself has started using AI in its work. Pierre Pronchery, a security engineer with the Linux Foundation's Alpha-Omega project, demonstrated a CI/CD workflow integrating a self-hosted LLM into a staging instance of Forgejo. It automates draft replies to vulnerability reports, analysis, advisory template preparation, compliance checks, signing, and uploads. The LLM is self-hosted to preserve confidentiality, and the workflow can be useful in production without the LLM.
A policy for code contributions is still in development, while AI has already entered security workflow automation. Here too, practice has moved ahead of policy.
Desktop, accessibility, and other work
FreeBSD is also becoming easier to use as a desktop OS.
Work continues on a script for the bsdinstall(8) installer that automatically configures a desktop environment. The script has shrunk from about 400 lines in Q1 to about 100. Four new ports, totaling 26 packages, cover automatic setup of GPU drivers, the KDE desktop, and the display manager. They have been submitted to Bugzilla.
A new bsddialog version adds accessibility themes including high contrast, one that avoids red, and one that avoids yellow and blue. Themes can now be managed centrally through system-wide or per-user configuration files. The team also acquired a HumanWare BrailleNote Apex and successfully tested it with FreeBSD. It could display text on the braille display and receive input from the braille keyboard over USB.
Suspend and resume work includes support for S0ix, a low-power sleep state used by recent Intel and AMD laptops. More models lack traditional ACPI S3 sleep support. Thunderbolt controllers can now resume as well.
On AWS EC2, a new desktop AMI for FreeBSD 15 provides a KDE environment accessible through xrdp.
Across Q3, the FreeBSD Foundation sponsored 530 commits to src, which covers the kernel and userland, 82 to ports, and 19 to doc. FreeBSD 14.5-RELEASE shipped in September, and 15.2-RELEASE is scheduled for December. The port of AMD's ROCm GPU computing platform also advanced: the amdkfd driver compiled, linked, and loaded, exposing /dev/kfd. The Bhyve VM management GUI, Bhyvemgr, moved to a client-server architecture. The foundation expanded its support for the Sylve web management platform through a new grant.
The 51 reports show how one project can use AI, prepare for rules around it, and defend against AI-related attacks at the same time. What policy will the FreeBSD working group produce in Q4? Alongside the answers from GCC, QEMU, and Debian, the open-source community is waiting for FreeBSD's.
Originally published on Joho no Todai. The Japanese original is here.
