Zerodep is the idea that third party dependencies should be minimized, and ideally be zero.
In general, given the choice between writing a few dozen or so lines of code and importing a multi-thousand line library, it's better to write a few dozen lines of code. Less lines of code means less bugs. Less lines of code means the codebase is auditable. Less lines of code means the codebase is more maintainable. Have you ever tried to audit a codebase that had 500,000 lines of code and 5 MILLION lines of dependencies?
It has become cliche for people to complain about code bloat. And yet, people still use multi-hundred-thousand line frameworks. The only way to return to sanity is to dump the frameworks and actually learn how to code. If we do not, code will collapse under its own weight, and AI will not be able to fix it! (That should probably be a subject of another blog).
There is one other thing missing from the software ecosystem, and that is replacement. Once a codebase gets above a certain size, it only accretes code. Sure, some code may be deleted, but on net the size of the codebase only increases. Do operating systems really need to be 150+ million lines of code? Do web browsers need to be 50+ million lines of code? No, but there is no mechanism to keep them a reasonable size.
What is the solution bring these enormous codebases under control? Personally, I believe it would be less work to start from scratch than to try to reduce existing codebases. We should also do studies (actual computer science!) to find when a codebase reaches "black hole" status (becomes so big that it only ever gets bigger). When we have an approximate number, we can create new projects where we say "We cannot go over X lines of code. If you really need to add more you must remove some from somewhere else". I think this discipline and skill must be deliberate. Without this discipline we risk a Parkinson's Law for code except that there is no limit to expansion.