Also, design by committee rarely produces good UI. You can patch little UI bugs, but if you really want to holistically improve the UI it's a huge undertaking.
Just because you're developer, doesn't mean you want to hack on every tool you use. Software has gotten way too big for that.
You mean like that crufty thing called homebrew?
Or the default versions of software shipped are out of date by maybe a long, long time?
https://www.reddit.com/r/bash/comments/393oqv/why_is_the_ver...
What kind of problems have you faced with Homebrew? Can you please elaborate?
I use Homebrew all the time and it just works for me out of the box without any issues. I never had to edit configuration files or customize anything to make it do the right thing. It just works.
You don't have to fix every bug you find. Just fix the odd bug, and work around the rest until somebody else fixes it; many hands make light work. But the work doesn't get done at all if you run away to proprietary platforms.
You don't have to boil the ocean. Just do your civic duty from time to time. Once a year, even. If everybody on HN used desktop Linux and, once a year, invested an hour into fixing a minor, polish-level bug, desktop Linux's polish problem would completely disappear.
I am typing this on a Mac. I spent years as a desktop Linux user and developer.
For maybe 5-6 years, I invested my evenings and weekends in trying to improve desktop Linux. I fixed bugs in ALSA. I worked on Wine. I fixed bugs in GNOME. I wrote freedesktop.org specs. I did a lot of stuff.
I also watched as lots of other people tried to fix basic problems.
You know what my experience was?
Half the time, attempts to fix things triggered massive flamewars. KDE and GNOME couldn't agree on basic things like how notifications should work; any attempt to come up with a compromise system resulted in the KDE guys screaming and yelling about how everyone should just adopt their own system (which had braindead usability problems). Linux people thought package management was God's Gift to users, even though actual users kept telling them it was awful and they just wanted to download apps from websites. The kernel developers insisted that every driver by GPLd, even though this was incompatible with the business models of key hardware developers, resulting in those firms working around the GPL, ensuring nobody "won". Common distros couldn't play music or video files because of a refusal to pay for software patents.
The other half of the time attempts to fix anything were rapidly undone by pointless ecosystem churn as things were written, rewritten, thrown away, and rewritten again.
There was no coherent plan, no architecture, and competitive evolution turned out to be bad way to create an operating system. Developer experience was a nightmare. Any time something deviated from what was laid down by the original UNIX in the 70s it caused massive schisms and basic APIs split or stopped working.
Linux on the desktop will never be competitive with macOS regardless of how badly Apple screw up their QA because the desktop Linux community is far more dysfunctional.
That's simultaneously a good thing and bad thing. It's good because it's possible. It's bad because when everyone is responsible for a platform's software defects, then no one is responsible.
Even if we ignore average users, and just consider developers, the overhead and learning curve is prohibitive. A frontend webdev or even a backend Java dev would probably have a really hard time tracking down and fixing an issue in Xorg or Wayland or in their touchpad driver. The relevant maintainer could likely fix it in a few hours or days if they had the available time and motivation, but the user (who just happens to be a developer in an unrelated field) would likely take many days or weeks.
Even if you match skill-sets -- say a C programmer is having trouble with some GNOME UI issue that would turn out to be a bug in a C library -- you still have a big hump to get over to contribute to a project you're not familiar with. Build system, how to safely test changes on a live system (where the normal software comes from a distro package), code organization and just learning how things work in a new code base, code style, pull request process, review process, etc. -- all of this makes it really difficult to contribute, even if the actual change is small.
I do wish more people would take the time to dig in and scratch their own itches, but I absolutely don't blame them for just wanting to be able to get their work done without having to first fix their OS and tools.
(Credentials: I use Linux as my daily driver, and have gotten frustrated by macOS as a development environment any time I've had to use it as such. I used to be an Xfce core maintainer, a decade ago. These days I mostly do Scala and Java backend dev, and consider myself quite rusty with languages like C.)