"Is This Piece of Open Source Software Still Maintained?"

Yes. Maybe. Actually... perhaps no. Well, really, it depends on what you mean by "maintained".

Individually-produced (as opposed to "corporate") open source software is written to solve a problem someone had, when they had them. While they could have kept the software to themselves, they instead released it publicly, under the terms of an open licence, with the hope that it might be useful to others, but with no guarantees of any kind. Thanks to the generosity of others, it costs them literally nothing for you to use, modify, and redistribute this project, so why not release it as open source and perhaps let others benefit?

OK, Whatever. What About Maintenance?

In one sense, open source software is "maintained", and always will be. The author fixes the bugs that annoy them, they upgrade dependencies when not doing so causes them problems, and they add features that they need. To the degree that any on-going development is happening, it's because the author wants that development to happen.

However, if "maintained" to you means responses to your questions, fixes for your bugs, upgrades to suit your needs, or new features that meet your requirements, you may be somewhat disappointed. That's not "maintenance", that's "support", which is a whole other thing, that takes time and energy to provide. You are not entitled to the time and energy of anyone else, unless you are appropriately compensating them.

I Don't Like the Sound of That!

If it makes you feel better, there are several things you are entitled to:

1. The ability to use, study, modify, and redistribute the software, under the terms stated in the applicable licence(s).

2. That any interactions you may have with the author, other contributors, and anyone else in this project's spaces will be in line with the published Code of Conduct (if there is one), and any transgressions of the Code of Conduct will be dealt with appropriately.

3. ... actually, that's it.

Things that you are not entitled to include an answer to your question, a fix for your bug, an implementation of your feature request, or a merge (or even review) of your pull request. Sometimes the author (or someone else) may respond, either immediately or at some time long afterwards. You may luck out, and someone will think "hmm, that looks interesting" and start to work on it. But if that happens in any particular instance, it does not create an entitlement that anyone will continue to do so, or that anyone will ever do so again in the future.

But... I've Found a Huge and Terrible Bug!

You have my full and complete sympathy. It's reasonable to assume that the author hasn't come across the same bug, or at least that it doesn't bother them, otherwise they'd have fixed it for themselves.

Feel free to report it, if only to warn other people that there is a huge bug they might need to avoid (possibly by not using the software at all). Well-written bug reports are valuable contributions, and the effort you've put in is appreciated, but the work that you've done on your bug report still doesn't create any entitlement on anyone else to fix it.

If you really want that bug fixed, the source is available, and the licence gives you the right to modify it as you see fit. You are encouraged to dig in and fix the bug. If you don't have the necessary skills to do so yourself, you can get someone else to fix it -- everyone has the same entitlements to use, study, modify, and redistribute as you do.

You may even decide to pay someone -- the author, or anyone else -- to fix the bug for you. That's totally cool and, in fact, even encouraged.

But... My Contribution Should Be Valued!

A pull request (PR), or any other suggested change to a piece of software is a worthy contribution. If you take the time and effort to make the contribution, you're doing good work and you are to be commended for it. However, that doesn't mean that the original author will necessarily merge it into their repository, or even work with you to get it into a state suitable for merging.

See, your contribution is what is often called a "gift of work". The author will have to make sure that, at the very least, it doesn't make anything actively worse. That includes introducing bugs, or causing maintenance headaches in the future. Properly reviewing a PR usually takes at least as much effort as it would take to write the same code from scratch, in almost all cases.

So, if your PR languishes, it might not be that it's bad, or that the project is (dum dum dummmm!) "unmaintained", but just that the author chooses not to accept this particular gift of work at this particular time.

Don't forget, though, that the terms of the licence include permission to redistribute modified versions of the software. If you think your PR is all that and a bag of potato chips, fork away! Nobody sensible will be offended if you decide to release a permanent fork of the software, as long as you comply with the terms of the licence(s) involved.

What About "The Community"?

A community is simply a group of people coming together for a common cause. If such a thing evolves around a given piece of open source software, then that's great!

However, the overwhelming majority (as in, somewhere north of 99.99%, as a conservative estimate) of open source software never develops anything even vaguely resembling a community. That means that the chances are that any given piece of software will be single-author, with perhaps a few drive-by contributions by others.

Even if the odds are beaten, and there is a community of contributors involved in a particular piece of open source software, that still doesn't change the fundamental nature of the relationship. You are no more entitled to answers, bug fixes, upgrades, or new features from a community of people than from a solo author.