I don't bother filing bugs or sending PRs. I spend hours filing a detailed bug report. No response. I spend hours crafting a PR. Ignored. I file a bug report along with several possible solutions. I get a snarky response totally unrelated the proposed solutions.

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.

Well put.

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.

This is exactly the problem with an overadherance to "stability". If you submit a PR to fix a bug in a "stable" product, it will be a year before it ever becomes "stable", so the incentive to fix it is nearly zero, because you can't get the stability and your bug fix. (If they just ship every random PR to the stable build, well, now it's the "unstable" build.)

I file bug reports. It greatly depends on the person running the project; some are like you describe, or they're incompetent (particularly problematic in non-FOSS projects). Those, it's usually pretty clear that you're going to have to weigh "how much do I want this bug fixed" against how painful the process will be.

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.

> particularly problematic in non-FOSS projects

In my experience, the products I pay for usually fix bugs faster than FOSS.

I would advise against calling users leeches. A product is meaningless without users, and those users that do go out of their way to file helpful bug reports should be lauded not disparaged.

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.

Thank you for confirmin that "Free and Open Source" does not value stability or quality.

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.

This is an absurd sweeping generalization. There are many FOSS projects that value stability and quality. Just like there are many closed source projects that don’t.

The only one I'm aware of that does a good job of this is the Go language project, but it's not really your typical FOSS project; it's a Google project, and Google relies on it internally, so the incentive to make it stable and high quality is as high as it will ever get. They don't sell it to others, but they themselves rely on it as a core part of their own business.

When was the last time the Linux kernel or the gnu utils broke for you?

For me? Can't remember.

Yea, Linux is another good example, but that's really mostly because of Linus' adament commitement to never break user space. A lot of other people would be happy to break user space programs. As in this famous rant https://lkml.org/lkml/2012/12/23/75

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.

The Linux kernel and many other big FOSS receive a non-trivial number of their contributions from professional programmers on the clock at their day job.

What does that have to do with anything?

It's not breaking because the contributions are from paid professional developers with commercial priorities and incentives, with internal or external customers often driving those changes. Not unlike Go.

Often times you can get a support for a stable OSS, and then you actually help the ecosystem by giving it resources

Unfortunately, the "pay for support" business model means the incentive is to make a system that needs support but pretends on the surface to be stable and high quality.

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.

I don't understand, isn't the original complaint here that everything needs support eventually?

Everything should not need support. The fact that most everything needs support is a symptom of how crazy the software industry is.

I keep hearing people say that, but how do you propose we write software that has no bugs and does everything perfectly right the first time? That seems impossible.

The first time? Sure, nothing ever gets it right the first time, but over time software should converge on being bug free and not requiring any support at all. Free-with-paid-support has a perverse incentive against this.

"over time software should converge on being bug free"

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.

All I hear is excuses. I'm not interestd in hearing excuses.

That seems dismissive and I don't know why you would be hearing that. If there is a way to do this that you think would not qualify as an excuse, then you should mention it, otherwise both of us are stuck to what we are limited to by these bodies that require rest and sustenance.

You're creating a false dichotomy: we can either add new features, or stabilize the current version, but we can't do both!

Yes you can. You can spend some time to stabilize, and then add new features on top, then stabilize again if needed.

I am not saying that's a dichotomy, I mean this purely as a function of resources. Sure you can do both but that takes up twice as much time as if you only did one of them. So however much you want to do of either is really up to the project's management goals and what the customer is willing to pay for...

What other projects besides (La)TeX and METAFONT have noticeably converged on bug-free over time? Perhaps the Linux & BSD kernels.

LaTeX specifically might be bug free, but it's so incomprehensible to a not very experienced user (like me) that it exactly matches the notion of "software where you need support". the only good thing is that you can often get the support for free on the internet. Even though it might be stable and bug free, I'm just avoiding it for "shinier" things like HTML and Ctrl+P in a browser...

Is it incomprehensible because it can be configured in different ways, or is just because the notation language it uses is not familiar to you?

The distinction is cruicial.

I'd love to! Did you make sure your FOSS project is easy to build from source? I don't have to spend hours nagging the dev team for mysterious compilation bugs and dependencies? Projects that make this easy are the extreme exception, so if you actually get it right, then yes, I completely sympathize.

It's probably a bit blind to think that there's only one way to contribute by fixing issues. However, the new feature development is very important too, and it usually it does not necessary require a testing or beta channel.