It's usually not about doing a better job, it's people simply doing the job.
Of course.
But there is doing the job, and doing the job.
As I said in my first post:
Doing the job is one thing.
To decide what's going to be released is something else.
Any development engineer experienced immature rubbish was released into the market, faced the consequences it caused, footed the bill for decisions made by others too quickly, maybe also was taunted for he or she was part of the team working on that crap knowing better, but his or her concerns were ignored, know what I mean.
Just because most doing it that way is no reason to do it likewise.
(As we say in germany sarcastically: 'Eat crap! Billions of flys do. They can't be wrong.')
It's simply no style to blame who did the better job.
That's either to be an incentive to do it better oneself,
or just stand by the own way, and live with it, and its consequences.
In the end all what counts is if the user/customer buys it.
If not, it's not the customer to blame.
(It's also human to blame others. It's so much easier than to work on oneself.)
Especially for some software developers sometimes it's hard to accept,
if users reject their ideas, being too stupid to recognize the ingeniousness, while actually it's yet unfinished garbage, simply not needed, or useless.
But - depending on the environment - they sometimes simply can push it into the market anyway.
I do not mean put it at free disposal (website, github, ports tree etc.)
I mean feed it unasked to the user by 'upgrades' the user didn't asked for.
And just there was a lot of work done on it neither makes it good, nor it's a reason to press it on the user.
It's not about better or worse developers doing a good or better job.
The 'job' also includes if, when, how, and under what criteria decisions are made to release,
or to keep it in the lab.
As far as I experienced Linux to me sometimes it seems to be bit too open, so more often immature work is released too quickly into the wild which better stayed in the labs a while longer.
While I feel within FreeBSD the release process is more strict - which I appreciate, because it leads to more reliable products, and less crap.
And I object to anyone who want soften that, because I smell 'but I want my crap being released; even if it may not perfect yet; but what is; and I will work out the flaws later.'
As I know for many cases:'No, you won't. You got your release. Now you are going for another fancy idea.'
(I ment the 'royal you', not you.)
For that not always the developers are to blame.
And when this results in something users don't like, or even reject,
then it's neither the user, nor the programmer coding some source sections to blame,
but to think about other things, like reconsider QM, doing projects the way engineers are teached, the criteria for commits, etc.
That's all I was trying to say in short in my former posts.