I’ve come to think that libraries need to have either of two properties in order for me to want to use them:
They are well-known and provide sufficient value that DIY would be infeasible (cryptography and image generation for example); or
they are wellwritten enough that I can debug them or even take over maintaining a fork if the upstream is abandoned or I need to develop the functionality in another direction.
It’s astonishing to me how many are comfortable with releasing random unvetted libraries in production and still are very careful about reviewing code added to the project itself.
I went so far into this rabbit hole I've come to regard depending on anything but the Linux kernel as unacceptable.
To that end I created a freestanding C programming system of sorts. My own libc, essentially. Without all the legacy of C like errno and locales, and with no portability requirements. Then I implemented a lisp interpreter on top of it. I needed to implement some ELF stuff and eventually I realized I was recreating the linker well. I suppose that'll be the foundation of the lisp's foreign interface.
It's in my plans to create a freestanding Linux VFS for SQLite and integrate the database directly into the system as a module. I'll also try porting libsodium at some point, I'm not smart enough to roll my own cryptography.
They are well-known and provide sufficient value that DIY would be infeasible (cryptography and image generation for example); or they are wellwritten enough that I can debug them or even take over maintaining a fork if the upstream is abandoned or I need to develop the functionality in another direction.
It’s astonishing to me how many are comfortable with releasing random unvetted libraries in production and still are very careful about reviewing code added to the project itself.