vendoring culture
#Software often has dependencies, and the bigger the codebase the more dependencies the software is likely to have. A dependency is another chunk of code, written and maintained by someone else, that you incorporate into your project in order to fulfill certain functions. Your project then becomes dependent on that external code in order to run properly, which is why it’s called a dependency.
But there is an alternative to employing dependencies, and it’s called vendoring. When you vendor someone’s code, instead of writing instructions to point to the external code, you copy that code directly into your project. Even when such an action is legal — it isn’t unless the relevant code is open-sourced or otherwise explicitly made available to you — it’s not widely done because when you vendor someone else’s code you become wholly responsible for it. If you were using that code as a dependency, then maybe you could count on the person who originally wrote it to maintain it, develop it, extend it, fix it when things go wrong; but when you vendor their code you have no access to the original, and so the running of that code becomes your problem.
On the other hand, if you’re willing to take on that responsibility then you really get to know an alien codebase and may incorporate it not only into your code but also into your thinking. A programmer named Tom MacWright says that he vendors code more often that most other programmers do for just this reason:
When I’m vendoring code - copying it into the project and making it pass my basic eslint [a JavaScript analysis tool] & testing standards, I’ll do light rewrites and refactors of new code, allowing me to get a deeper understanding of how they [sic] work and where their limits lie.So: Vendoring rather than dependencies. This leads me to a comic book.Obviously, other people’s code is their code. I didn’t do 100% of the thinking that led to it - I’m probably doing 5% of it. But absorbing that bit into my mind, instead of seeing only the external API surface, pays dividends.
Now: If you’ve been following this series of posts, you’ll have zeroed in on Robin’s key point:
For me, these are matters not primarily of judgment — who was wrong? Who continues to be wrong? Exactly how wrong are they?? — but of repair.So Robin has already said the thing that most needs to be said, but let me just add this point: What Yang has done is moral repair through vendoring code — in this case not the code of programmers but cultural code. And note that Yang has not created a dependency: he has not simply pointed to code created and maintained by someone else. He has copied that code and pasted it into his own creation, not because he admired it but because he needed to correct it. And he could only correct it by making it his own. Like Tom MacWright, he has thereby enabled for himself a better understanding of how that code works and where its limits lie. He has “absorbed it into his mind”; but his mind is more capacious and generous than what it absorbs. And that is precisely what enables the absorption.And in this case, amazingly, we have an example of what repair might look like.
In this case the code doesn’t remain 95% that of the original text and 5% Yang’s; the proportions are closer to being reversed. When the original is healthier, and stronger, the relation can be more equal and more constructively reciprocal. But even when the original code is destructive, even when it’s a kind of cultural malware, it can seed the act of repair — the act of repair that goes far beyond repair. It is a seed in the same way that a irritating piece of grit trapped within the mantle folds of an oyster eventually generates a pearl.