Because an Unmaintained library is worse than one you write yourself because bugs are much harder to understand and fix.

You imply that you're still going to understand your code one year later. While this is a favorite fantasy of all programmers, it's usually false. Also, if you're in a team, the person running into the bug is likely not you, so it's foreign code for them anyway.

I was being brief because I was leaving work so I’ll expand a bit.

An unmaintained library is usually more difficult to fix because fixes are no longer committed back or released. At that point you can choose to vendor and maintain your own copy, or replace it with something else. And at either of those points you’re no longer in context.

My point wasn’t really geared at debugging a piece of code. A library, my own, or a coworkers are roughly comparable. The cost to fix is a lot higher in a library though.

It’s not a universal rule, despite the way I originally phrased it.

I think there is also certain negative selection bias in the sense that people are more likely to stop maintaining libraries that were badly designed / problematic to begin with. That's why I tend to be more sceptical than average when it comes to "orphaned" projects.

I've had many a struggle with this.

On the flip side, I have found libraries that are unmaintained and are pleasant enough to understand. I've forked those and used them, happy that:

1. I can quickly fix any bugs that I face

2. Someone else can make use of my maintenance.

I agree with 3, not necessarily 4.

The amount of people who uses a product does not determine is quality.

However stars can determine to an extend whether it's a project worth looking at or not.

My home-made code will probably just do the specific thing I need it to do, and not all of the other things the library has been generically designed for.