AI Makes Open Source More Essential

Hey everybody, we're back at the Open Source Summit here in lovely Minneapolis, and we're having a little chat about, well, the future of open source, because what else would we be talking about here? Steven, welcome to the show. Hey.

Glad to be on again, and this has been a great conference so far. So I got a chance to kick off the keynotes and talk about what's happening with open source projects, particularly related to artificial intelligence, which is all the buzz of the conference. Well, and that's what everybody's talking about, and one of the topics that keeps coming up is, well, is there a future for open source in the world of AI, or is everybody just going to go write their own code everywhere and they won't be using as much open source because, well, the AI is going to do that.

But it seems like there's also going to be a need for some sort of back-end headless services that people are going to use. So what does the future look like to you? Yeah.

So my opinion is the folks who think that you can just recreate open source software and actually have the same level of functionality, of security, and general community support for a code base is largely overstated. Right? If you think about open source projects, really what they excel at is a lot of different enterprises, companies, individuals work on the software.

You have researchers, even now AI researchers like Mythos, who are contributing bug sins, finding issues with it. And what this results in is it results in very solid foundations for you to build upper application layers on. And if anything, the amount of contributions to open source projects is going up.

So when you look at the number of PRs, the number of submissions, the fact that people can use AI to code quicker, they can more easily use tools like GitHub, check in, follow contributor guidelines and policies, makes it much easier for individual software developers to contribute to projects. And if anything, the maintainers are the bottleneck right now because they're overwhelmed with the number of PRs. But again, this is a great opportunity for open source to automate some of the manual processes which the maintainers use to accept new incoming PRs.

So won't the maintainers just build their own AI agents to go look and review all the contributed code, and this will just be one AI talking to another AI? So the real challenge with building a system and getting it to meet the user requirements, it's not the coding. The coding's actually the easy part.

It's always been the easy part. The hard part is understanding the requirements and figuring out exactly what needs to be done for the end user environment. So typically, in an open source project, you have people who are end users, contributors.

They submit issues or bugs. Even if they submit a patch, often the maintainers will review the patch and will possibly modify it or make a different patch. But getting the requirements in on where there's feature function gap, where there are bugs, where there are issues, is the real value.

That's always been the real value to open source projects. And one of the advantages of AI coding in this ecosystem is now end users can more easily contribute patches and fixes for the issue, and the maintainers can also use AI to review and secure those patches. Mm-hmm.

So if anything, the fact that there's a larger funnel of requirements coming into open source projects makes it a much better ecosystem. Is this all going to happen at a much faster pace? What you're describing, or at least it looks like with AI, something like a flywheel is starting to emerge.

Yeah. So I think the best place to look for this is some of the frontier projects like OpenClaw or Hermes Agent, where they have tens of thousands of PRs coming in, and the process for releases is extremely high. Easily you're getting dozens of new releases per day with new functionality.

And they're able to do this because they're taking advantage of both AI on the contributor side, since people are using these agentic personal agent systems to code against the system itself, so they're dogfooding on top of it. And then the teams are using the AI to throttle and to get more contributions in quicker. So that's I think where we're headed, is both the open source maintainers and the contributors are both using AI to accelerate this whole process.

Now, different open source projects are at different stages of adoption of AI, and some of them necessarily will use less AI for security or because they're in an industry where they're kind of targeting a more regulated industry where they need to be more careful about contributions. So I think it depends on the use case of the application, how much open source technology is applicable for them. And the best way to figure it out is projects often publish their contribution guidelines.

They tell you how they want use of AI, how much AI issues and contributions, whether it's okay for your agent to submit PRs directly or whether you should hand review it and be the person who's representing it. And as long as you're following those guidelines and operating in the spirit of the project, then this is a great way to contribute back to the ecosystem. Do you think we're going to essentially unlock a wave of innovation?

Because I think a lot of times people had an idea, but then by the time they get off the couch and set up the development environment, they were like, "I don't know. " Yeah, no, I think that's exactly right. So now if you have a good idea for an open source projectIt's extremely easy to create a code base, to publish it, to get feedback on it.

So I think we'll see more open source projects emerging, and also it's a lot easier to contribute back to existing open source projects. So you can simply, if you see a bug or you see an issue, have your agent do a code fix, file an issue, file a PR, and you can even script your agent to read the contribution guidelines and advise you on how to responsibly submit back to the project. And I think that the key here is agents are the tool that coders use to build things, but it's about the people.

Mm-hmm. So it's about having domain experts who really understand the problem set, about having innovative people who can come up with new ideas and new things to contribute. And you can think of, I'm going to borrow a quote from Libby, from my panel yesterday, you can think of IDEs or AI as the IDE for open source.

Yeah. I could see that. One of the things that people are talking about here, though, is this sense of doom around the number of vulnerabilities that might be discovered soon, especially in older open source environments.

What's your take on this whole thing? Should we be terrified, or is it a little overrated, or maybe it's just the butcher's bill coming due finally? Yeah.

So what we should really be terrified about, and I think you're referring to Mythos and security tools like that, which are very good at finding security exploits in existing code bases. And, what we should really be worried about is the fact that closed and proprietary code bases have always been the most vulnerable to security exploits. And you can think of government systems, a lot of closed financial systems, anybody who relies on security by obscurity- Mm-hmm ...

is going to be killed in the AI age because AI is the best hacker. It can find the exploits, it can automate things, it can do things quicker and at a more rapid pace than we've seen before. But well-maintained and peer-reviewed open source code bases are not where we're going to see the biggest issues.

And, for example, I was having a chat with some of the maintainers of the biggest Linux Foundation projects because they've been given access to Mythos. They're starting to use it on their code bases. Now, it is finding issues, but for the most case, they're small, they're isolated, they're hard to exploit because most of the large, easy-to-exploit vulnerabilities have already been submitted through a public review process because these projects are used so widely.

There's so many- Mm-hmm ... eyes and security firms and folks who are evaluating constantly to try to find exploits. But if you have a less used code base, if you have a code base which is proprietary, that's where you're going to find most of the bugs.

And tools like Mythos will just destroy those. So I think we should be worried more about the ecosystem which is not in the open, which is not being reviewed constantly, because that's where you'll see most of the exploits. And then a lot of traditional industries, even government, have relied on the fact that it's relatively hard to hack into closed proprietary systems.

AI is going to break that barrier. It's going to break that wall. Mm-hmm.

Do you think that ultimately we may go through some bumps along the way, but will the quality of software get better in the AI age because we do have these tools? " Yeah. So I think quality is relative.

So, I think anybody who's been using the current generation of AI tools knows that if you know the code base, if you're a domain expert, like if you really understand it, you can write better code than the AI can. And often for code bases you know well, you can also develop it faster than AI tools. AI tools will actually slow you down.

I think where AI tools bring innovation and possibility is when you're trying to solve a new problem, you're trying to brainstorm, you're trying to create new software, you're trying to work on a code base that you're not very familiar with. And this brings a whole new era of innovation in software development because now you can think about, instead of thinking about the code, you can think about the features you want to develop. And for a lot of things, for example, user interface development, you care a lot less about the code quality because you spin and you rewrite the user interface constantly, but you care about the feature set, you care about the patterns and things you're able to do with it as a user.

And I think that's a wonderful application for entirely AI-coded interfaces. And an example of this is we had a project internally at Neo4j where we rebuilt our CLI from scratch, over 95% AI coded using FLoD code. And that sort of innovation, we were able to have an idea, we wanted to be able to have a CLI, which is not just good for humans, it's also good for agents.

And we can quickly spin on that and recreate things much more rapidly than we could do without AI technology. Mm-hmm. One of the things you do hear from developers is that they feel like they're spending more time reading code than writingAnd because they didn't write it, they're not as intimately familiar with the code, so they don't feel like they have the domain expertise over it either.

So how do I strike the right balance here between my essentially proofreading code that the machine created and actually knowing that code base? Yeah. So I think that when you're using agentic tools, it can generate a lot of code very quickly, but you still need to be on top of your code base and how it's generating the code, what are the pattern it's using, or it easily gets out of control.

And one of the common patterns you'll see with people who are junior developers who are using AI coding is they'll let it not only generate the code, but they'll let it generate all the possible fallbacks and redundancies and different issues which may or may not happen in a real system. And it generates so much code bloat that it's hard to maintain over time. Mm.

So the same software engineering practices for writing good code also apply to agents. You need to be writing unit tests. You need to make sure you're refactoring the code and cleaning it up constantly.

You need to make sure the APIs are clean so you can integrate different systems. And agents can do this, but they won't do this by themselves. It requires a human who understands good engineering practices, who's monitoring and reviewing not all the code, but the critical sections.

And then they're advising the AI on going back, "No, no, no, that's the wrong pattern. Refactor that. This has the wrong API.

" And having it not just continue to generate new code, but then to take the existing code and keep it in a maintainable shape. Mm-hmm. What has been the impact on DevOps pipelines?

" And it's starting to look like a bad day at LAX with too many planes coming in at the same time. Yeah. So I think it's very similar to the bottleneck that maintainers have today, right?

So I mentioned that people in maintaining open source projects have more PRs than they can review by hands. Mm-hmm. And now they're finding innovative ways to use AI to accelerate that process.

And I think we'll also see the same shifts on the DevOps and CI/CD space where if you're not also using AI technology to manage your environments, to provision hardware, to set up your CI/CD pipelines, you can't possibly keep up with the amount and the pace of developments which the software development teams are doing. So it's a great problem to have, right? Because we need more people doing this, we need more infrastructure, we need more resources.

But it's also really good for the DevOps space because now you have more software packages. Now you have more releases that you're pushing out. And this means you need more people, you need more hardware, you need more tools to manage the delivery and the security of these systems.

So more software engineers. What are we not talking enough about these days? Everybody's talking about all things AI, but is there something on your mind that you think that folks should be paying a little more attention to?

Yeah. So we talked a bit about the fact that AI is a boon to open source. It's also going to accelerate DevOps and a whole bunch of delivery pipelines.

But these are all things where you're taking seasoned software engineers or software release experts, and they have better tools, and they're able to do more with it. Now, the missing gap here is we're graduating a generation of computer scientists and software developers who are not AI informed. The schools treat AI as a way to cheat, so they discourage using AI in the curriculum.

Mm-hmm. The curriculum hasn't been updated for using tools like Copilot or Claude Code or Codex. It's just not part of their curriculum.

And frankly, a lot of professors I talk to, they don't even have the school budgets for tokens or the availability of those tools for their students. And the students graduating have a gap between the expectations of employers and then the skill set which they're graduating with. So I think that if you're an existing software engineer, this is a wonderful time because you can retool in AI, and you can have even more job opportunities in the future.

But for the graduating generation and our current school programs, there's a huge gap that we need to address, or we're not going to have the pipeline of AI engineers needed to meet the demands. All right. Hey, folks, you heard it here.

AI's changing everything, and hopefully for the better. Hey, thanks for coming by. Yep.

All right. And we'll be back in a minute.