Earlier this month, Anthropic announced they mostly-autonomously built a C compiler that can compile the Linux kernel. This week, the corporate beef between Vercel and Cloudflare flared up again with the announcement of a Vite-based fork of Next.js built from scratch in a week.
Today, open-source drawing app tldraw decided to pull all tests into a private repo. The PR itself doesn’t explain the rationale but I think Malte is likely correct:
Wow, @tldraw is moving their tests to a closed source repo to prevent a Slop Fork
— Malte Ubl (@cramforce) February 25, 2026
We are entering the age of the Slop Fork. Any software with robust tests / verification specs is clonable (in the same or another language, with the same or altered requirements) by an engineer coaxing along an agent for a week or two. This doesn’t hold for some of the largest, most complex software (Cursor’s experiments haven’t shipped a functional browser, yet), but the writing is on the wall.
The moat that became the drawbridge
Before now, one of the signals for the quality of an open-source project was how robust and comprehensive its test suite was. The care and effort put into testing for edge cases and hardening from production usage was a durable moat that provided some stability and required true innovation to disrupt.
Today, a comprehensive test suite provides all the information necessary to replicate the hard-won lessons. Models can capably translate the intent of a unit or integration test between languages and frameworks with ease.
This was all technically possible before, but it was prohibitively expensive (with the exception of hyperscaler clouds cloning restrictively licensed database products), especially with the requirement of keeping a fork aligned with changes to upstream.
A shift of this magnitude will have casualties. I can fully understand tldraw’s actions in the context of their business model: their code is copyrighted and has a commercial license, but a cleanroom slop fork based only on the test suite might not violate copyright…at least until courts decide it does.
Embrace?
As someone who has spent a good portion of my career building open-source libraries that connect to paid services, this change is more of an opportunity than a challenge.
In “A Software Library with No Code” Drew Breunig creates a wonderful embodied thought exercise of a library that is purely defined by a specification of behavior and a conformance test suite — let the model fill in the details.
What I think is very likely is we will start seeing spec-driven development as a cornerstone of multi-platform software libraries. Building, for example, an SDK that works across many languages, platforms, or frameworks was one of the more expensive investments Firebase made in its early days.
In 2026, to tackle a new cross-language library I would:
- Build it from a conformance test suite
- Add per-language idiom guidance
- Create agent skills to automatically actuate spec/test diffs across implementations
This is embracing the slop fork and turning it to your own purposes.
Extinguish?
The other option, which seems much more fraught, is reworking open-source licensing to try to explicitly block slop forking.
Permissive licenses have no defense for slop forks. Even moderately restrictive licenses don’t protect against weaponized competitive forking (like vinext).
Could we see libraries with different licenses for library and test code? Or new types of OSS licenses that somehow try to lawyer their way into preventing slop forking? It’s hard to see how to draw the line between “legitimate forks” and “slop forks” when the only real change is the cost of rewriting software dropping to near-zero.
Like many developments in AI, this genie is unlikely to return to its bottle. Slop forks exist and will only get easier. This is yet the latest in a series of massive disruptions (e.g. Tailwind’s stellar popularity and declining revenue) that are likely to continue to batter the developer ecosystem.
I’m not a “fight the future” type. We need to fix this forward, not try to roll it back. But I sympathize with the awesome engineers who have been turning open-source community work into a viable career and may soon find themselves battling new challenges on a monthly basis.
We software engineers have been cursed to live in interesting times.