Akrites is a new Linux Foundation effort framed as a joint defense of critical open source software. The letter says big companies will contribute engineering talent, money, and AI-based security help to coordinate vulnerability discovery, remediation, and disclosure. It also claims Akrites can step in as a maintainer of last resort when an important package has no active maintainer. That is the core promise. Not a general funding drive for open source, but a centralized mechanism for privately handling security issues in software large companies depend on.
The reaction was skeptical from the start because the signatories are exactly the firms many people blame for free-riding on open source, over-centralizing infrastructure, and flooding maintainers with AI noise. The main objection was not that coordinated disclosure is illegitimate. Most people accepted that private handling of unfixed vulnerabilities is normal security practice. The objection was that Akrites reads like a corporate control layer sitting on top of the commons. The phrases that set people off were “confidential, trusted place” and “maintainer of last resort.” Those sound less like help and more like a path to private forks, pressure on maintainers, or de facto control over package health and release timing.
Where the conversation landed was more concrete than the outrage. People kept asking the same operational questions: who actually writes patches, how those fixes reach upstream projects, what counts as a “critical” package, what happens when the original maintainer disagrees, and whether this work goes through normal community channels or around them. Several comments argued that the whole effort should be judged on that implementation detail alone. If Akrites mostly funds maintainers, buys them time, provides
CI, hardware, audits, and respectful security assistance, it could help. If it mostly scans code with AI, batches up reports, and escalates fixes through private corporate workflows, it will make open source worse while claiming to save it.
A second theme was that the real current crisis in open source is not undiscovered bugs in famous projects. It is trust collapse around the long tail of underfunded maintainers and the flood of low-quality AI-generated reports and pull requests. That made the letter feel mis-aimed. Big projects already have corporate backing and governance. Small dependencies that everything rests on usually do not, and several people noted that these announcements rarely say how the long tail gets paid, protected, or given agency. The most persuasive practical alternative was simple: fund maintainers directly, provide infrastructure and paid review work, and make any automated security help opt-in and maintainer-first.
There was some pushback to the doomier takes. A few commenters noted that corporate employees already do a huge share of maintenance on Linux, Kubernetes, and other load-bearing open source, so corporate participation itself is not the scandal. Others defended the Linux Foundation’s record as better than critics allow, especially when it provides governance and operational support without closing projects off. But even among people open to the idea, enthusiasm was thin. The consensus was that Akrites has not yet earned trust. It might become useful infrastructure, but only if it behaves like a service to maintainers instead of a command center above them.