AI-Driven Code Review, Project Security, Red Hat and Lightwell Solutions, Moonshot Leads Model Spending

Robert Jacobi: Welcome to Open Channels News. I’m your host, Robert Jacobi. Today, AI is getting better at finding bugs in open source software. What happens after it finds one? We’ll start with the maintainers who have to turn a finding into a fix, then look at the teams who have to get that fix into production, and we’ll finish with a number about enterprise AI spending that sounds very different once you know what’s being counted.

First up, Matt Asay writes in InfoWorld that AI gives open-source projects more eyes on their code. He’s responding to an optimistic idea from Eric Raymond, who helped popularize the notion that bugs get easier to find when enough people look at the code. AI can bring more scrutiny to projects that have already been through years of security testing. But Asay asks, what happens tomorrow when the tools get better again? The code changes, dependencies change, and businesses put systems together in ways that original developers could not anticipate.

Asay points specifically to PHP. A developer spotted signs of a problem in 2024, but there was no concrete attack path at the time. A fix meant weighing performance, compatibility, and the effect on third-party extensions. AI-assisted research eventually demonstrated the impact. The maintainers then had to make those trade-offs and coordinate fixes across supported versions. I like the example because it shows where the work goes. If you have a credible demonstration of a bug, you can make a better decision about how urgently to fix it. You still need someone who knows which applications a change could break, and you need a project that can review the fix, put it into a release, and get it into the hands of people who depend on it.

Think about a library used by 100 companies. Each company could carry its own repair, or a fix can go into the shared project along with a test that catches the problem if it comes back. When those companies move to the next release, they can pick up the work together. That’s the value Asay sees in having a common code base that people have the rights to work on and share.

Now put yourself on the receiving end of that release. You’re responsible for a business application and a security advisory comes in. Which version of the affected component are you running? Does it come bundled inside something else? Can you apply the update without interrupting the business? If those answers live in different places, the clock is already running while you look for them.

Matthias Czwikla of Red Hat writes in E3 Magazine that traditional patching processes are struggling with that timing. He’s writing for an SAP audience where companies can depend on open source components and extensions and integrations as well as in the platform underneath. If AI speeds up discovery, the teams running those systems still have to identify what’s affected, test the fix, and roll it out. Czwikla points to Lightwell, an IBM and Red Hat initiative, as one response. It uses automation and engineering expertise to identify affected dependencies and package fixes. One part of the approach is backporting. That means taking a fix and adapting it to an older version so a customer can address a vulnerability without moving to a new major release at the same time.

Imagine the vulnerable component sits inside a system that handles payments. A major upgrade might mean retesting integrations and getting several teams to agree on a maintenance window. A backported fix can narrow the change they have to review. The teams still need to know what’s installed and check that the update works in their environment. That’s where I’d look for time savings. How quickly can they go from an advisory to knowing which systems need attention, and how much do they have to change to protect them?

Finally, let’s talk about who’s getting paid when companies use downloadable AI models. The South China Morning Post reports on Menlo Ventures’ enterprise AI study. In the category Menlo calls open-source model spending, Chinese models account for an estimated 89%. Moonshot AI’s Kimi family leads at 61%, followed by DeepSeek and Z.AI’s GLM family. Here’s the other number to keep in mind. Menlo puts that whole category at around 4% of enterprise model spending. So Kimi leads a small slice of the market by spending, while proprietary models still account for most of the money.

Menlo’s measuring dollars. A company can run a large volume of tasks on a lower-cost model and still spend most of its budget elsewhere. When a report calls a model open source, I also want to know what the team can actually take with it. Can they download the weights? What does the license allow? Can they run it with another provider or on their own equipment? Those are distinct questions. A team may be paying a hosting provider to run the model, and the ability to move that workload depends on what’s available and what the terms permit.

That brings us back to the people doing the work. Whether you’re taking a security fix from a shared project or building a product around an AI model, what matters is what your team can do when something changes. Can you get the fix into production? Can you move the workload if you need to? You’ll feel the answers long after the announcement.

And that’s it for today’s Open Channels News. I’m Robert Jacobi. Be open and stay secure.