Broken

> No one fucking communicates.

We all laughed when Tim Cook said that Apple will double-down on secrecy[1]. Who's laughing now? Turns out he was dead serious.

[1] https://www.cnet.com/news/tim-cook-were-going-to-double-down...

I've been at Adobe at a time when they shipped Creative Suite, as boxes (even though downloads started to be more prevalent, it was still very much pre-packaged software). People don't give Adobe enough credit for what it was achieving back then - every 18 months, like clockwork, it shipped an entire suite of huge applications, that needed to work well with one another. And they couldn't rely on post-release fixes - because US accounting regulations made it impossible to ship fixes after the GM builds, if I remember correctly. And they did it. Reliably so - at least until CS6 (with the subscription, things changed, you can now ship fixes anytime). What's more impressive than the fact that they did it, is that from the engineering perspective, it was an "of course we'll do it" - there wasn't at any point any doubt that CSnext will be released, and will be released on time. And it had to be awesome - the entire company depended on it.

Thing is, there was nothing really special that Adobe did and I haven't witnessed elsewhere. Extensive testing, pre-releases/ getting the most loyal users involved early. Waterfall, yes - but "waterfall done right" (I don't think the overhead was too onerous). What they probably did "specially" though, even though it sounds mundane and boring... was to relentlessly cut scope. It was no shame to do less than what you initially planed for - but it was a crime to not say ASAP that you may not be able to do what you promised. I know personally of a feature that didn't ship in CS5, at all, because it was deemed "not ready" (even though at the start it was deemed as "required"); almost brought down a development center (that was supposed to ship it), and their biggest sin was not that they weren't ready, but that they didn't say so until it was too late.

The short version of all this, I guess, is that cutting scope can do miracles. I'm surprised that it's not used more widely - and somewhat saddened that even Adobe lost its skill at this (from my pov, the cloud has enticed the management to ship features that are not quite ready yet, and counter-intuitively, I think this actually slows them down now).

> Getting and keeping a Linux Desktop in good working order is harder than it should be at this age of Linux.

I use desktop Linux as my daily driver (personal and work), and generally have very few problems. I hear so much grief from friends and colleagues who are running macOS and have so many issues. I really don't want to be "that guy" who obnoxiously pushes desktop Linux, understating its usability issues for average users, so I decided to log some of the issues I had over time.

I realized that the failures on Linux, while fewer, were usually much worse: the things that fail on macOS are either annoyances that can be ignored or worked around, or things that can be Googled and fixed (for the most part). There were certainly sometimes failures on Linux that followed that pattern, but there's another class of failures: when things failed, they failed hard. Once, I rebooted after some kernel and Xorg package updates, and Xorg just hung on startup, logged nothing useful, and only responded to SIGKILL. I did manage to fix it, but the average user would be completely lost, and, to make matters worse, would have no GUI to use to search for help on the web. They'd probably end up having to reinstall and hope for the best. That's not acceptable; that might have been a common recovery step with Windows back in the 90s, but people expect better now.

The distinction is that macOS failures are overwhelmingly solely of the type that frustrate and reduce productivity. It's very rare to run into something that grinds you to a complete halt. While desktop Linux has come a long way, and I'd (unscientifically) say there can be fewer frustrations than on macOS, there are still enough hard-stop, my-computer-is-a-brick-now failure modes to make it unsuitable for most users.

I wonder if things are so broken, how do they manage to create world class hardware and software. Genuinely curious.

> That's the good thing of open source: don't like it? Then fix it and send me a patch and stop complaining.

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.)