They don't contribute to testing either, since they just consume releases and ignore development, then wonder loudly why there are bugs.
Don't be that guy... if you want your dependencies to have a long life being maintained, find some time to contribute. Leeching is not contribution.
But I get it. Maintainers are overworked and jaded. I'm on the receiving end as well, with 95% of the issues like: "help, it's broken" (with no error message), "please teach me git", "please debug my application code", "please implement this massive feature for me" (for free), "how do I do xxx?" (obviously didn't read the README.md), "your library is buggy" (no it's not, your pointer has run off the end of your array, causing Undefined Behavior).
With all of that noise, it is difficult to figure out which bug reports or PRs are in the 5% that are actually well-researched and valid.
A reputation/karma system for bug reports could be an interesting way to deal with this problem.
I wonder if it’s ever been tried.
But I've also had maintainers who were very helpful. Recently had to deal with the DST cross-sign expiring, and needed a third-party container to be rebuilt on a later version of Debian. Filed an issue with really nothing more than "Would you mind releasing with a newer version?"¹ and the maintainer had it published within like a day! Greatly made my life easier.
So I really want to separate out those maintainers that are doing a stellar job; certainly some merit your criticism, just not all.
¹I didn't have time then to track down the Dockerfile & figure out the required patch. Might have once my time freed up, but the maintainer beat me to it.
In my experience, the products I pay for usually fix bugs faster than FOSS.
The phrase leeching implies an entity is consuming a host's life force in some way (seeders's bandwidth in the torrenting analogy), simply using the product does not meet this criteria.
I'd rather pay for a closed program that comes with guarantees of stability and quality than participate in a community that considers these concerns tertiarty or off the menu entirely.
One way to make a system so incomprehensible that your customers absolutely need support is to make it configurable in a million different ways, and make the configuration invisible / opaque.
Example:
"Why is this program doing this when I told it to do that?"
Answer: Because this file in that directory configure service A to do X, and this other file in that other directory configures the program to behave like Y if it detects that service A is doing X.
But the program does not tell you that via its UI; you have to read obscure documentation.
Yeah, and the way that's done is by refactoring things, removing buggy/deprecated things, and not adding any more new features/requirements... So, pick your poison, I guess? I'd love to go move on to the next job as much as the next person, but somebody still has to be paid to do those things. I don't see what the significant difference is there with free-with-paid-support, if you pay for it up front you're still paying the same cost.
Yes you can. You can spend some time to stabilize, and then add new features on top, then stabilize again if needed.
The distinction is cruicial.
For me? Can't remember.
For the "gnu" user space programs, I don't use much of them so I can't comment, but for the desktop environment? It's a huge mess. Even with stable/sane environments like xfce, somethings are confusing and brittle, such as getting things setup properly for Kanji/Chinese character input. I've tried it several times, and everytime it takes a lot of effort to get it right, and I always forget what the right steps were. It's not even worth remembering because in a few years it will change.