Building FOSS is mostly rewarding and occasionally aggravating. Once in a while it requires some cleverness.
The old contract between maintainers and users was simple enough. We build the software, you use it, you report what breaks. Some of you stick around and contribute. The project gets battle-tested by people whose problems I would never have thought of, and everyone comes out ahead.
That contract is under some strain right now. Part of it is noise: AI slop, automated issues filed by agents on behalf of people who cannot describe the problem, and a general devaluing of open source by the machines spewing half-finished projects onto GH. Not all AI-written code is slop. But a lot of slop is going around.
The part that actually bothers me is quieter. A technical user can now fork a project and maintain that fork with agents indefinitely, without ever coming back. They used to need me. Now they need a subscription.
So here is the story.
The pull request
I woke up, checked my GH notifications, and saw a PR that had been opened and closed during the night. The title was Claude/merge. Nothing else.
I looked inside. 285 commits. 377 files. About 150,000 added lines and zero deletions, which is what a merge-direction mistake looks like. Opened 22:32, closed 22:33.
What happened is obvious. Somebody is maintaining a private fork of Xberg with an agent, the agent was told to merge upstream into their branch, and it pointed the PR the wrong way. Somebody caught it inside a minute and closed it.
It was also the second time. Four days earlier the same branch had done the same thing with 130 commits.
I read through it. There were real bug fixes in there. Not features, not their product code, just places where they had hit something in my extraction pipeline and dealt with it.
What I am and am not entitled to
Xberg is MIT. There is nothing in that license that obliges anyone to upstream anything, and I would not want there to be. The whole point of picking MIT was that people could do this.
But MIT cuts both directions. There is also nothing stopping me from reading public forks and learning from them.
I want to be precise about what I decided to take, because the distinction matters and it is the only reason I am comfortable doing this at all. I do not want their code. I want to know what broke. A fork that has diverged for six months is a bug report written in the most honest format there is: someone hit a problem in production and fixed it, and the diff tells me exactly where.
So the output of this is not patches. The output is issues.
The loop
Xberg has 576 public forks. Almost all of them are the fork button and nothing else.
The loop is not complicated:
- List every public fork.
- Drop the ones that are stale or have no commits ahead of their fork point. That kills the overwhelming majority immediately.
- For the handful that have real divergence, pull the comparison diff.
- Hand each one to an agent whose instructions are narrow: find where this fork worked around, corrected, or defended against upstream behaviour. Ignore anything that is their own feature work, their own configuration, or vendoring.
- Whatever survives becomes an issue on my tracker, written as a problem statement with a reproduction, not as a patch.
Step 4 is where all the difficulty lives, and it is worth saying plainly that this is the step an agent is genuinely good at and I am genuinely bad at. I am not going to read 150,000 lines of somebody else's merge. An agent will, cheaply, and it does not get bored halfway through and start skimming.
The narrowness of the instruction is the whole trick. If you ask an agent to "review this fork" you get a summary nobody needs. If you ask it to find the three places where somebody defended against a crash in your PDF layer, you get three places where somebody defended against a crash in your PDF layer.
What it actually produces
Fewer issues than you would hope and better ones than you would expect.
The signal is heavily concentrated. Most divergence in most forks is packaging, CI, and someone pinning a dependency. The interesting material is a thin band: encoding assumptions that hold in English and fail elsewhere, a file that is legal per spec and rejected by my parser, resource limits that are correct for a document and wrong for a real one.
Those are not exotic bugs. They are the bugs you only find by running the thing on documents you did not choose.
Where I land on it
I have some sympathy for the fork maintainers here. Upstreaming has real costs. You have to match a project's conventions, argue with a maintainer who has opinions, and wait. If your agent can just carry the patch forward on every merge, the calculation genuinely changes, and I do not think everyone taking that route is acting badly.
But the aggregate is worse for everybody, mine included. The bug they fixed silently is one you are going to hit next month.
I would still rather they opened the issue. Until they do, I will read the forks.
Xberg is at github.com/xberg-io/xberg, MIT, if you want to be one of the 576.
