> Ah yes, the "it's all subjective" argument. The thing is, it's not subjective.
Some things are, some things aren't - and even some of the subjective objections can be reasonable. If your entire dev team is a bunch of crusty C programmers with no exception handling experience, introducing a new library that throws exceptions has drawbacks, no matter how reasonably they might be used. They're simply not in the right mindset for it. If it's just 1 member of your dev team, however, perhaps it's time for them to learn to deal with exception handling if the library is otherwise good.
Then I see devs getting very passionate about vanilla XML vs JSON, CamelCase vs snake_case, and making kneejerk reactions to well documented edge cases that their replacement implementations would also have (minus the documentation.)
Your tastes are a bit better, but even there I can think of scenarios where all three aren't vital to me - easily fungible dev-only debug tools come to mind.
> Sure, it may be hard to objectively measure the qualities of a library, but that doesn't mean we should give up and assume there's no underlying objective truth.
Agreed. But I find that the best way to measure is to have at least one person try - or have previous experience with - using the library.
Obscenely convoluted dependency chains that can't be simply checked into VCS? Consistently unstable? Insecure by design and defaults? Constant public interface churn? I agree that there are reasons to kill a library with fire - sometimes before you decide to integrate it in the first place, sometimes after the fact when you've realized it was a mistake.
> The result? We often end up with a larger maintenance burden by using a library.
I see this rather rarely, which does make me think we've spent time on opposite ends of the NIH spectrum. It does happen though, and those are libraries that I will still avoid.