I can confirm that this is the norm for all my open source projects. Forward-compatibility issues can be easily avoided by not using too many dependencies and by carefully checking dependencies before using them.

I check for things like over-engineering and I check out the author (check their other libraries if there are any).

Built carefully, extremely tiny, or single purpose.

"Do one thing and do it well" - the unix philosophy, and why I still use cd, ls (dir on windows) today.

If a project exceeds two functions its probably doomed to become either redundant or broken.

If a project does one thing well, even if something else uses it, you can always decompose to it (your software is always useful, even when somebody writes the fancy bells and whistles version).

What non-game-able metrics do you think an outsider can use to evaluate the quality of a tool? In some ways a "perfect" tool would have no flaws (thus no issues/pull reqs) and be so easy to use (few training updates, SO questions) that it would appear to be dormant.

SQLite seems to hit a good balance. There's always something new but nothing particularly breaking (from my light usage POV), so it looks live.

Filed issues are getting radio silence, no matter their quality.

The author chimes in, says he’ll take a look next evening, then two years whoosh by.

There is an ambitious todo and nothing moves.

The code is in alpha for years, considered unstable, huge exclamation points in the readme that it should not be used, and yet somehow there are hundreds of reverse dependencies and it’s like this for years (usually should mean “RUN!!!”). Sometimes sneaky as it’s not a direct dependency for you, but for those two or three libraries used by like 80% of the ecosystem.