> IMO If you're really staking a key part of your architecture, you should be comfortable enough with the technology to basically be able to document/maintain it yourself if you need to.
Good documentation has different level of criticality depending on where you are on the "I use a closed library with no access to the source" down to "this library is just a stepping stone, we have full control and will modify it as needed"
If you are on the completely blind side, documentation is your only window into how it works, and good documentation is non negotiable (you will take a slightly worse working library if it has way better documentation).
In comparison if you adopt a library as a time saving move, and audit all of its code the same you would review your own code, good documentation is a nice to have, but won't be the make or break point of your decision. You'll chose the better working code even if its documentation is meh.
I you are putting your fate into a specific stack or library, I hope it falls on the latter category than the former. On the two json libraries, I guess they both work decently, and the only criteria is which one feels better to use ?
Hmm. Not entirely sure I agree. To use an example, I find it much easier to read https://pkg.go.dev/encoding/json than the dozen or so files in https://github.com/golang/go/tree/master/src/encoding/json
Perhaps I'm misunderstanding your point.