This is a problem with larger teams though if anyone else needs to work on the code, and results in code that doesn't have documentation/support available.
Not documentation as in 'He didn't make a confluence' page, but documentation as in 'If I google this error message will I get a good answer'
IF an app depends heavily on a feature AND there are not many external alternatives, then a shop should lean toward rolling their own.
A related issue is the volume of code. If the in-house version is 500 lines of code and the external (downloaded) version is 5,000 lines, then the internal one may be easier to debug and fix. (Yes, I realize that lines of code is not the only factor to consider.)
Common factors to look at:
1. Complexity of the part, including dependencies on other parts.
2. Swappability of the part for alternatives.
3. How well the part is written and documented.
4. Need for the part. If it's merely a "bonus", then dependency may be less of a problem/risk.
> I personally find it far easier to fix my own code than others' code.
is that if you work on a team, you're fixing others' code either way. The difference is that with an external library there's usually documentation, a community, etc; but with a home-rolled solution, you're usually on your own.
The "community" often ignores my bug fix requests, I would note. Maybe I ask wrong, but we don't all have wonderful asking skills. If you do, that's a nice feature of your personality, but doesn't necessarily extrapolate to all code users.
But the flip side is that any code you borrow you have to fix, debug, and/or replace if it doesn't work as intended. I personally find it far easier to fix my own code than others' code.
I'm not claiming one should reinvent most wheels to gain control, though, only that there are trade-offs for each. If you borrow code, you should have an alternative(s) in mind if it stops working in the future or key bugs are found in it.
For example, using a JavaScript date-picker gizmo for forms is usually not a big maintenance risk because there are multiple to choose from. If you had only one choice and that choice went kaflooey, then you'd be stuck.
Well, the user could hand-enter dates. For internal software that's an acceptable temporary work-around, but not for commercial software, because every customer expects a date-picker (and the HTML5 ones currently stink if you want mm/dd/yyyy formats).
In short, don't heavily depend on any external part you don't have a "Plan B" for.