There's a tidy version of this story, and you've probably heard it. AI accelerates contributions. More code gets written. More projects get maintained. Everyone wins.
We don't think that's the full picture.
If your team builds on open source, and almost every team does now, the health of the projects underneath you isn't an abstract concern. It's what decides whether the library you depend on still gets security fixes next year, whether the bug you hit today ever gets fixed for everyone, whether the thing you rely on is still being looked after at all. We maintain around 40 open-source repositories, including Vortex(Opens in a new tab/window), our Drupal project template that's been continuously maintained since 2018. So we're not watching this shift from the outside. We're watching it from inside the work, and what we're seeing is more complicated than the optimistic version admits.
The contribution problem nobody wants to name
Open source runs on time. Volunteer time, mostly. Someone learns a tool, hits a bug, works out a fix, submits a patch. That cycle, frustration to fix to contribution, is how most projects grow. It's slow. It's unglamorous. And it depends entirely on developers caring enough to do the work.
AI changes the economics of that cycle in ways that aren't obvious at first.
Think about what happens now when a developer hits a bug. They don't necessarily file an issue. They ask an AI assistant, get a workaround, and move on. The bug still sits there in the project. The maintainer never hears about it. The workaround never makes it back upstream. And the project quietly weakens while looking perfectly healthy by every surface metric you'd think to check: downloads, stars, forks.
This isn't hypothetical. It's the natural result of removing friction in the wrong place.
The friction of figuring out the problem was never the part worth removing. That friction is exactly how developers build the understanding that lets them contribute something useful in the first place. Shortcut it, and you get a faster individual result and a slower, weaker collective. The person gets unblocked. The commons gets nothing.
Who actually trains on what
The licensing conversation has been building for a while, and it's messier than either side likes to admit.
Most AI coding tools are trained on public code. Some of that code is MIT-licensed. Some is GPL. Some carries no licence at all, which in most jurisdictions means "all rights reserved" by default, not "free for anyone to use". The tools trained on all of it have generally proceeded on the assumption that training counts as fair use, and that licence terms don't travel with the generated output.
We're not lawyers. But we maintain a lot of code, and we read what comes back from AI assistants closely. When a tool produces something structurally identical to a known implementation in a well-known project, that isn't an abstract worry. It's a real provenance question, and nobody has answered it cleanly yet.
The projects most exposed here are the ones with distinctive, opinionated implementations. The careful, considered work that represents genuine expertise. Generic boilerplate is easy to regenerate and nobody loses much sleep over it. Architecture built up over years, full of decisions that look arbitrary until you understand why they're there, is far harder to attribute and far easier to quietly absorb.
The sustainability question is getting worse
Open source sustainability was already a crisis before AI arrived. Most foundational projects are maintained by one or two unpaid volunteers. Critical infrastructure, the kind that sits under software used by millions, often runs on the equivalent of donated weekends.
AI doesn't fix this. In some ways it makes it worse.
Here's the dynamic we're watching. AI makes it faster to consume open source. You can scaffold in minutes what used to take days. The volume of projects built on open source foundations keeps climbing. But the number of people contributing back to those foundations isn't keeping pace, partly for the friction reasons above, and partly because AI creates a quiet sense that "the tool handles it" that dissolves the feeling of obligation to the commons that used to come more naturally.
And the contributions that do arrive aren't always a gift.
Code generated without a real understanding of a project's conventions, architecture, or constraints creates work, not relief. Reviewing a low-quality pull request often takes longer than just writing the fix yourself. As the volume of those PRs climbs, and it is climbing, maintainer burnout climbs with it.
We've felt this directly. Pull requests that look complete but miss the edge cases any experienced contributor would have tested first. Contributions that follow the README to the letter but ignore the unwritten conventions that give a project its coherence. More and more, maintaining looks less like reviewing and more like triage.
What AI actually does well here
This isn't a piece arguing that AI is bad for open source. It's more complicated than that, and the honest picture has real upside in it.
For experienced contributors, AI genuinely speeds up certain work. Writing tests for behaviour you already understand. Generating documentation from code you know inside out. Catching common issues in a pull request. Drafting changelog entries. These are tasks where you know enough to verify the output, so the speed is a real gain with no hidden risk attached.
For maintainers of smaller projects, it can take the edge off the parts of the job that burn people out fastest. Answering the same question for the fortieth time. Writing issue templates. Drafting a contributor guide. If AI absorbs some of the invisible emotional labour of maintenance, that's a genuine benefit, not a consolation prize.
And for discoverability, AI assistants sometimes surface smaller, less-marketed projects that would otherwise stay buried under the better-funded alternatives. An unexpected upside, and worth naming.
So here's the honest framing. AI is a force multiplier. It amplifies whatever you bring to it. For experienced, thoughtful contributors, it makes them sharper and faster. For rushed or inexperienced ones, it makes it easier than ever to produce something that looks right and isn't.
What this means for projects like Vortex
Vortex is our open-source Drupal project template. It exists because we couldn't find a solid, opinionated, well-tested starting point for Drupal projects, so we built one and have kept it maintained since 2018, with CI pipelines, testing tooling, deployment automation, and documented conventions.
Projects like it face a specific kind of AI challenge: the value lives in the conventions, not just the code.
The decisions about how things fit together, which testing approach to lean on, how deployment should work, what the workflow looks like for a real team under real pressure, aren't sitting in any single file. They're encoded in the relationships between files, in the CI configuration, in documentation that explains the why rather than the what. AI can generate Drupal scaffolding that looks the part. What it can't replicate is years of learning what goes wrong, accumulated since 2018, and building something that quietly handles it. The output might look similar. The behaviour under real conditions is not.
We watch how AI tools interact with Vortex closely, both how they read it and how they generate code meant to sit alongside it. So far it confirms what we expected. The surface layer is easy to approximate. The structural decisions are not.
The honest position
We use AI tools in our own work. We find them genuinely useful for specific tasks. And we're paying close attention to what they do to the ecosystem we depend on and contribute to, because for us those two things aren't in tension. They're the same responsibility.
The open source community built the foundations almost all modern software runs on. That didn't happen because it was efficient. It happened because skilled people cared enough to share their work, maintain it through the unglamorous stretches, and treat the commons as something worth investing in.
AI changes the economics of individual productivity without automatically changing the economics of collective maintenance. That gap is the real problem. Closing it will take conscious choices: from developers, from the companies that profit from open source without funding it, and from the community itself.
We don't have a clean answer. We don't think anyone does yet. But pretending the question isn't there is not a strategy, and the projects worth using tomorrow are the ones being maintained today.
That maintenance is still human work. It still takes time, judgment, and care. AI has made a lot of things faster. It hasn't made caring any easier.
We maintain around 40 open-source repositories, including Vortex(Opens in a new tab/window), a Drupal project template built to production standards. If you want to talk about open source sustainability, Drupal tooling, or what we've learned from years of platform maintenance, we're always open to that conversation.