This is something that should be taken care of when vetting the project on whether or not the company should use it. Anyone whos been around that block a few times knows to look for:
- current dev status (hasnt been updated in 6 months? probably shouldnt touch it)
- community review (is anyone else using it, hows it working for them?)
- limitations (this one is pretty obvious, technical limitations/benchmarks/etc)
- code quality (unless its a third party service you pay for you should be able to see if the code is worth a crap pretty easily).
- vendor lock (if we need to change, how easily can we change? do they use open source protocols/standards that other tools understand?)
But this is the point. There is no good rule for when you should use a library, and when you should build your own stuff in-house. It always depends on the specifics of your situation.
You need to think about things like the quality of existing third-party solutions, and how well they will fit into your codebase. You might find a third-party library that is 90% of what you need, but there just isn't a good way to get to the other 10%, and so sometimes even in those cases it makes sense to roll your own.
Other times I see people rolling their own versions of stuff, and it's clearly much worse than readily available libraries. You just have to look at the specific situation to determine the right thing to do.
Or more likely it is someone's open source project on GitHub, and is just as poorly documented as something in-house would be.