It's just a judgement call. For existing options you have to score based on: maintainedness (frequency of upkeep, issues answered, etc), invasiveness (cost of r

It's just a judgement call. For existing options you have to score based on: maintainedness (frequency of upkeep, issues answered, etc), invasiveness (cost of removal, definitely a big one here when choosing a framework vs a library), dangerousness (trustworthiness of maintainer), weight (itself and transitive dependencies), quality (quick code review, license, etc), and reimplementation difficulty. That score is weighed against your requirements (e.g. building a lib for others might have stricter dependency reqs than an in-house app). But you can take these metrics and apply them to even broader things such as lang/ecosystem choice, general software choices, and even life choices. No different than entering into any other relationship. While I try to avoid premature abstraction, on libs that have high volatility or otherwise don't score very high, I'll put a thin interface layer between my use and the true impl. This saved me recently as I had a Scala trait abstract the async Postgres client lib I was using, then I hopped from one to another to another over a couple of years until just recently writing one because the others sucked for various reasons. Just make sure you have integration tests and you'll feel comfy in your choice.