[lioeters]

That's not always true.

Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever).

Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first.

Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.

[erik_seaberg]

I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.

[lioeters]

> explicitly depending on our fork of their library would be clearer and safer.

I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.