2026-09-18
Lecture Friday: Dependency Cultures
It's weird seeing Mitchell Hashimoto's philosophy. I already kind of do a version of that for my own projects. I don't often fork but more often just learn from others and then create my own better version that fits the task at hand. It depends on what you count as a dependency, but I have some number you can count on two hands for this website including the OS and database and such. I've written my own tools for a number of things where I thought I could do a more minimal version for my needs. I just don't like bloat, so in a way I ended up at the same place as the fork model.
And yet, when it comes to third party dependencies I run, I advocate for basically running on their release branch. A dependency you suddenly need to update after being left fallow for some time generally involves major changes and risk. And because I only run a hand full of fairly large reputable dependencies with few transitives, it's pretty easy for me to trust the process.
The hardest thing I've come up against is that both of my philosophies are pretty unpopular where I've worked. It really is the case that dependence is a cultural phenomena. If I don't know exactly what it's doing, I get frustrated. Other people get frustrated if they can't import a solution to their problems and be done with them.
When it comes to security problems though, I've lost count of how many "security updates" I've had to patch that have nothing to do with the dependency as deployed in our application. Patching "critical" vulnerabilities for obscure non-default configurations in components we don't even enable. Fork and prune saves significant overhead on all of that. The code is now internally maintained. A real part of the software and not some box you call into and pretend has zero overhead. You also get to actually read the dependency. At least for source dependencies. You'd also be much more aware how many binary blobs you actually depend on. To any Python programmers reading, you might be surprised how many binary blobs you depend on.
It also means you're free to reshape it because it lives in your software, not along side it. You're also free from someone else arbitrarily imposing changes on you. You acknowledge that it's your responsibility. It always was. Adding any dependency to your code takes on the responsibility for the actions of its maintainers. You just pretend that it's a line in a dependency file and not really your problem.
One of the interesting ideas was how the number of dependencies for a project could be related to the tooling for this problem. I'd like more data to see if that's really a trend or if it's a sampling artifact in their data. The problem with the fork model could just be there isn't tooling that encourages it and makes it simple to maintain. Interesting problem space. It's possible LLMs could make it easier to let you fork a dependency, slim it down to just the things you need, then track security patches in the upstream and compare them to your fork to see if you need to fix anything.