← Back to Writing

Why I Clone Libraries I Used to Take on as Dependencies

The shadcn pattern is becoming a terrifying part of my development process.

There’s many projects I adore and engineers I admire. Shadcn’s components have always stood out to me as such an incredibly fascinating approach to a React UI library. This pattern of “just clone the things into your repo and extend/compose” was incredibly useful in 2022. It’s becoming a terrifying part of my development process in 2025.

What happens when you hit a bug?

I’m building a tool that needs a terminal in Swift. There’s a popular library called SwiftTerm. Works great. There’s a bug that bothers me. I find out the bug has an open issue.

Fork in the road. Open a PR and produce the fix? Hope the author doesn’t have nits? Still wind up building it myself and integrating into my project while I wait for merge? And release?

Or just clone it, patch it, move on.

I cloned it. Patched it. Moved on.

Am I the first person to do this?

How many people have fixed this exact bug? I see contributors being very vocal on Twitter with their disdain for the flood of AI-generated PRs flooding their repos. The other side of this is that I will not only not open PRs, I won’t even report issues. Why would I? I don’t technically use your library anymore, just a slimmed-down version of it that met my needs.

This will have compounding effects. Every developer who clones and patches is one fewer issue filed. One fewer data point for maintainers. One fewer potential contributor.

Is this actually bad?

On one hand, this is amazing. I’m not blocked. I’m not waiting on anyone. I shipped.

The downsides might not even be a big deal? Maintainers will still notice issues and fix them. They’ll still iterate on their libraries. But they’re way less likely to be supported financially. This is already extremely rare. Will it get rarer when fewer people even know they’re using your code?

Open source funding has always been broken. Maybe this doesn’t make it worse. Maybe it just makes it more obvious.

What tooling is missing?

Is there some mechanism we need to be building that enables and fixes this pattern? Some way to track “I forked this, here’s my patch, merge it upstream automatically if it ever gets accepted”? Some way to notify maintainers that fifty people all independently fixed the same bug without anyone telling them?

The core problem is friction. Opening an issue or PR has overhead when you’ve already solved your problem. What if there was a low-friction way to signal “I patched something here” without writing a proper report? You clone, patch, ship. In the background, some tool notices you changed Terminal.swift line 342 and pings a registry. Maintainer sees the aggregate: “something’s wrong around line 342.” They don’t get fifty duplicate PRs, they get a heatmap.

Anonymous signals. No workflow change required. Just a background process that turns isolated patches into collective intelligence.

Is this something we even need to fix?

Maybe the answer is no. Maybe shadcn had the right idea all along and we’re just finally catching up. Clone what you need. Own your dependencies. Stop pretending npm install creates a relationship with the maintainer.

The library isn’t a service. It’s a starting point.