Almost every open source maintainer you have ever thanked has, at some point, run a project that outgrew them. A weekend script turns into a service. A service turns into infrastructure strangers depend on, and strangers do not wait politely for you to catch up. A recent conversation with the team behind a popular local-first AI assistant pulled the curtain back on what that transition looks like at scale. The numbers are striking and the lesson is portable: viral open source, once it happens, is a different job than the one you signed up for.
The job changes before you do
Most projects slide past a few thousand stars without anyone noticing, and then trip somewhere between fifty thousand and a hundred thousand. The shape of the work changes before the team does. Maintainers describe the shift in three ways:
- The issue tracker stops being a support channel and becomes a queue that nobody drains in a week.
- The pull inbox fills up faster than review bandwidth grows, so the same handful of people end up sorting the same fire.
- Trust erodes quietly. Other people run your software in production, sometimes in places you have never heard of, and a small mistake on your end can mean a rough afternoon for someone who trusted you.
If you maintain a project of any size, none of this is news. What is news is the rate. A few years ago the volume climbed over months. Now it climbs over weeks, and a lot of the climbing is not from humans.
When contributions stop being from humans
A maintainer on that team stopped calling inbound changes pull requests and started calling them something closer to prompt submissions. Several teammates backed him up. The pattern they describe is real, and it shows up in a lot of repos now: scripts scan open issues, hand the title to an AI tool, and post a diff with little or no human review.
That breaks the old mental model in three places:
- A pull request used to mean a person read your code, thought about the problem, and typed a fix. Now it often means a tool ran a prompt and posted the result.
- Volume stops being a signal. A single careful change from someone who knows the codebase is worth more than a hundred shallow ones that touch the same line.
- Sorting signal from noise becomes the actual job. That is exactly the work the tools were supposed to help with, and they have made it harder instead.
You cannot uninvent this. It is also not all bad. Some of the most useful submissions in the conversation came from people without a programming background who used an agent to draft the change and then worked with a maintainer to land it. The work still gets done. The shape just looks different than it did five years ago.
Why welcoming the flood is the harder call
Closing the door is tempting when the queue is ugly. Tighter contribution rules. Stricter templates. Required maintainer sign-off before any AI tooling can run. Each of those buys you a quieter week. Each of them also closes a door on the next first-time contributor.
The team in the conversation kept the door open on purpose, and they said why. The founder remembered his own first accepted contribution, years back, and used that memory as a tiebreaker when the queue got painful. Three groups stayed explicitly welcome:
- Newcomers who do not know the conventions yet
- People without a development background who hit a specific problem and used an agent to draft a fix
- Contributors whose AI-assisted submissions are rough but point at a real bug
Their rule fits on a sticky note. Look for the idea. If the idea is good, work with the person to refine it, rewrite the rough parts, or finish the change yourself.
Here is the trade-off you have to take seriously. The polishing time comes out of the same hours that could fix a real bug. The team accepted that cost because they wanted a healthy pipeline of future maintainers. You may decide differently for your own project, and that is a defensible call. Just make it on purpose, not by accident, because the volume will keep climbing either way.
What to actually worry about if you deploy the thing
The third thread in the conversation, and the one that matters most if you actually run this software or anything like it, is the shape of risk in a project that lands commits faster than review can follow. The team is part of a fund that pays people to look for ways dependencies can hurt you. That is not a guarantee of safety. It is a sign that someone is being paid to look.
A short list of habits worth copying before you wire any AI tool into a sensitive workflow:
- Pin a version. Do not track the main branch. Run a tagged build whose checksums you can verify.
- Read what the tool can reach. Email and chat access is the keys to most of your life.
- Treat every dependency as a potential attack surface. When the commit count climbs this fast, the chance that a bad package slips in is not zero.
- Keep secrets out of the conversation. Anything you paste can end up in a log.
The team has been open that the security work is ongoing. Apply the same posture to every tool you connect to a sensitive workflow: minimum access, real logs, and a fast kill switch.
What to do on Monday morning
Maintain a project, and this story is your near future. Set up a triage pass that catches low-effort AI output before a human reviewer ever opens the diff. Budget the time, because the volume will not wait.
Submit changes, including ones drafted with an AI, and the homework is yours to do. Skim the issue. Skim the surrounding code. In the description, write down the why, not just the what. That extra paragraph is usually the thing that separates a merged change from a closed one.
Wire AI tools into anything sensitive, and the move is to slow down before you click through. Skim what the tool stores, what it can read, and what turns it off. Treat each permission like a key you can lose.
Trade-offs
Keeping the door open for newcomers grows the community and lowers the barrier, but it eats hours that could fix bugs. Tighter rules calm the queue but shrink the next crop of maintainers. AI triage can sort signal faster than a human reviewer, but the triage model itself becomes something you have to defend, and staying ahead of the people gaming it becomes a permanent tax. Pick the costs you can absorb, write them down, and revisit when the volume shifts, because the volume will shift.
The single thing worth borrowing from this conversation is the part that did not get automated. The team told the truth about how hard it got, in public, while it was still hard. Most projects wait until things calm down before they talk, and by then the lessons are no longer useful to anyone in the middle of the flood. If you are about to be the next project that catches fire, write down your rule for non-human contributions before the flood arrives.