In the dark days before 2026 the standard advice was to avoid forking open-source projects: maybe a temporary patch is ok, but don't let it linger! Watch out or you'll get stuck in everlasting maintenance hell! I guess you'd better get reading git send email
I worked on XenServer: a distribution of the Xen hypervisor which runs on-prem VMs with vGPU, storage migration, High Availability etc. The hypervisor itself is small and trusted. By design it doesn't include things like device drivers, which can be enormous and complicated. So where did it get storage or network drivers from? Same place as almost everyone else: the Linux kernel.
Running Linux on Xen was actually quite hard. At the time Intel and AMD processors lacked hardware virtualization support, so Linux would crash or otherwise refuse to boot. The Xen project pioneered the technique of "paravirtualizing" Linux where Linux was patched to be fully aware that it was running under a hypervisor. The changes required were extensive. Everywhere Linux wanted to just do things it needed to be ask permission first with "hypercalls". This manifested as a large (contentious!) patch queue.
The problem with a large patch queue is that it bit-rots. Linux moves fast, changes (improves) things, and suddenly the patches don't apply (obvious) or (worse) don't work. They need redesign in some cases. Owning an out-of-tree patch queue is an ongoing commitment like owning a pet. We recognised the net present cost of all the future patch maintenance and judged it was cheaper in the long term to task human engineers with discussing, reimplementing and upstreaming these patches. [ Also it's nice to offer things back to the community ]
In fact we considered the kernel patch queue as a physical manifestation of our technical debt, a burden that would consume resources we'd rather spend on making new features for our customers.
Although I've not worked there for years, I notice their patch queue is a very manageable size these days: very nice.The cost of upstreaming patches is the same as it was: it requires asking (expert) humans to talk to other (expert) humans, ideally travelling to meet them at conferences to form bonds, agree approaches, then rework things to make them acceptable.
The obvious change in 2026 is that agents make patch queue maintenance cheaper.
The tedious task of rebasing, adapting to interface and architectural changes, can now be (mostly) automated. With a much lower net present maintenance cost, is it worth upstreaming patches at all?
The crossover point where the patch queue maintenance exceeds upstreaming cost has moved, making it economically viable in more cases to just keep the patch queue. Obviously the patches can still be open-source, and the original project can see them, and perhaps even choose to use them as inspiration for their agents and "remix" the good parts back in to the mothership (assuming compatible licenses). Some people have suggested that PRs should include the prompt rather than the code (how can you review all that code anyway?). A prompt with a branch which works -- an executable prototype -- would be even better.
It seems likely to me that the lower cost of maintenance will lead to an increase in the size of the average fork. If agents rebasing power keeps improving, a lot more people will never bother upstreaming. There'll be thousands of forks, with agents comparing them to each other and "remixing" each other's work. And this will be ok.
Xen runs device drivers in VMs which can have their privileges limited. This exposes lots of interesting bugs, like the time when the WiFi "driver domain" would receive a packet and crash because it would blatantly write memory it didn't allocate (... and which went unnoticed in a normal system because someone else had allocated it for themselves 🙈)