Overall, the OP seems to be suggesting that, merely by posting code on github, we have now been conferred with the responsibility of "maintaining an open source project."
In fact, I find the first couple of screenshots kind of awful. "Why this is ignored?" Ugh, I think I'm going to go back to bed.
When I make a blog post, I'm not expected to respond to every comment. Or respond to every tweet. It's reasonable to not respond to every email. So what is it about posting code on the internet which mandates that people read, review, respond to, engage with, and eventually merge your code? And I do say mandate, because this blog post is basically a take-down, of which many have been written, of some poor project which has a bunch of outstanding pull requests.
I'm sorry that individuals feel that, by not spending their time to review code, they feel that it creates a "hostile" environment in open-source.
If the author had, instead of using github, simply posted a .tar.gz file on their personal home page, this wouldn't even be an issue. If you wanted to make a change, you'd download the source, modify it, and get on with your day. But somehow github (and probably the fact that everyone's dependency management system depends on "official" releases, often from github) keeps people from doing what they used to do, which was just change the code and continue on their way, and has bred some sort of animosity towards the very folks who provided this code in the first place.
My must-read on this topic is from Armin Ronacher, who says:
"I found it quite hard this year to work on my own projects because the bug trackers were full of things I personally did not really care about. The things I wrote over the last few years all work so well for me, that I don't need to fix problems or add things. When there is something that needs fixing, I will work on it, but otherwise I don't necessarily get the motivation to work on it." [1]
Armin does take steps to improve this, but to me it is important to say that he didn't have to.
I maintain several OSS projects. I have often gotten poorly-tested pull requests and merged them without reading, understanding, or testing code. It's the OSS maintainer who gets the heat, in the form of hundreds of emails, when things break, not the person who made the PR.
So I agree with the central theme that too many open pull requests is discouraging, and for projects which want to grow, there must be a process for managing it. But I think this is completely at the discretion of the maintainer, that we should take advantage of our ability to fork and modify code (since when did the definition of OSS become "they must also accept patches") and it is frankly rude for us to publicly knock a a project because they haven't chosen to accept your patch.
Here is a productive idea: make it easy for me to use `pip` to install my forked version of a library. That way I won't have to care whether it is merged into master. (In fact, pip already lets you use git as a repository source, but you can apply this to all of the other dep managers for other languages.)
[1] http://lucumr.pocoo.org/2013/11/28/emotional-programming/