--- title: "Open Source Is About to Get a New Kind of Contributor" canonical: "https://www.guild.ai/blog/news/linux-foundation-announcement" --- # Open Source Is About to Get a New Kind of Contributor - **Category:** News - **Author:** James Everingham - **Published:** Aug 28, 2026 - **Reading time:** 3 min _**How agents will help build the next era in open source.**_ A lot of us at Guild come from open source. Back when I was at Netscape, when we open-sourced Mozilla, plenty of smart people thought we were giving the company away, but I've believed in the power of that community ever since. If anything, the case is stronger now. Security pressure is up, the pressure to move fast is up, and being open and working with a community is how you handle both. ## Agents are a new type of contributor Now, I'm writing this because I think open source is about to get a new type of contributor. Picture what happens when a new model comes out. Within days, someone points it at an open source project, and it finds fifty security holes. Within a week, everyone else can find them too. No maintainer can write fifty patches that fast. The only way to keep up is to send in agents. They write the fixes, test them, and submit PRs for a human to approve. You fight fire with fire. That's the new contributor. Open source has always had people contributing code. Now it will also have agents contributing code, and people contributing the agents. This way, when a maintainer builds an agent to handle a job they used to do by hand, that agent keeps doing the job after they move on to the next thing. Agents let one person cover far more of a codebase. Humans still do the work humans are best at, but agents can handle the rest. ## Playing out differently depending on where you sit If you _maintain a project_, your problem is _toil_. You put out a release and the issue tracker floods. Agents can sort out which issues are real, which are duplicates, and which are noise. When you decide an issue needs fixing, an agent writes the fix, and you review it. Good fix, land it. Bad fix, try again or do it yourself. You stay in charge. You just stop spending your time on triage. If you _lead an engineering team_, your problem is getting those patches into production. Patching inside a company is hard - a fix has to pass review, get tested, and get deployed, and none of those steps were built for this much volume. That's where things get stuck, and I think that's where a lot of companies will end up exposed. The fix will exist, but the question is whether it's running in production or sitting in a queue. That process needs to be rethought. If you _run the company_, your problem is control. Most tools in this space tell you what an agent did after it's done. That's a report, not a control. Guild runs agents in its own isolated environment and watches them while they work. You can stop an agent mid-run. You can see what it's doing in real time. You can manage costs, access, and governance from one place. That last point is important - today, if you ask who our competitors are, I'd have to name four or five companies to cover what we do. It's like building an operating system by buying the kernel from one vendor and the drivers from another. But Guild is one platform that does it all. Think of it as the operating system for running AI agents responsibly in a company. The Agent Hub is one part of that, where you find, fork, and publish agents so teams don't keep rebuilding the same thing. ## What we learned at Guild We know this works because we run it on ourselves. Our internal software factory is a workspace with about eight agents. When an issue comes in, the factory plans a fix, writes a test, writes the code, and hands a finished PR to an engineer to review. Almost half the code written at Guild now comes out of the software factory. Another example: one of our agents checks our logs every hour for 500 errors. If it finds one, it files an issue, and the factory takes it from there. Our engineers used to lose weekends figuring out what broke. Now they review PRs. An open source project could run the same loop because the work is largely the same, just happening in the open, with more contributors. An issue comes into the tracker, it gets tagged for the factory, and the factory fixes it, tests it, and gets it ready for a reviewer to land. ## Our work with the Linux Foundation Which brings me to the [Linux Foundation](http://www.linuxfoundation.org/). Few organizations have done more for open source. They steward the Linux kernel itself, which just turned 35, along with more than a thousand open source projects that modern software runs on. If you want to see what open collaboration can build over decades, that's the place to look. They're also home to the [Agentic AI Foundation](http://www.aaif.io/), which is where the open standards and projects for AI agents are taking shape. Naturally, Guild is a member, and that was an easy decision: if agents are going to be built and shared the way open source code is, the community needs a neutral place to do it, and the Linux Foundation has been running that playbook for years. So we're proud to be partnering with them to help them build internal agents for their organization, running on Guild. The Linux Foundation product team will be able to build, run, and manage those agents themselves. They also pushed us, the way good customers do. Their requirements drove our first support for an outside agent framework: [goose](https://goose-docs.ai/), the open source framework from Block that now lives under the AAIF. An open source foundation running open source agents on a platform built by open source people felt exactly right. Agents won't replace open source maintainers. They'll change what maintainers spend their judgment on.