> > five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have trans

> > five years down the line, when documentation is badly outdated, there is no organizational memory left behind that component, original developers have transitioned to either different teams/departments or left the company altogether, the component is still well isolated, analyzable and possible to work on. > This will be far more true for an external dependency - even one that's no longer actively developed - than for an internally developed component, IME. Just at the most basic level an external dependency has to have some level of documentation and at least be usable by someone other than the original author to even get picked up. Not sure if I can agree with the sentiment, especially with the "at least be usable by someone other than the original author to even get picked up." part. Components are easily usable either because they sort of adhere to the UNIX philosophy "do one thing and do it well", which makes them inherently well isolated, or they are easy to integrate, falling on the kitchen-sink end of the spectrum, making them inherently hard to isolate. I think it has more to do with the functional domain of the component, rather than source. > Sure, you need stay up to date, potentially even take over maintenance yourself, or accept the risk of not doing so, and none of that is free. The more of a kitchen-sink the component is, the more maintenance effort there is and the higher the risks. However, in my previous comment I wanted to highlight integration risks: components on the kitchen-sink end of the spectrum are more likely to break interfaces due to feature work, nudging organization towards trunk based development. It's not inherently worse or better than leaf based development, it's a compromise, however my key point remains that larger external components shift the compromise externally, which is impossible to plan. In my experience, internally-facing external components that diverge too much simply get code frozen instead of getting required support, whereas internal components get maintenance effort allocated.