Also, Linus' Law has some doubters. Things like Heartbleed show that Open Source isn't immune to long-standing, very impactful bugs.
Why all-or-nothing?
The fact is that free software has transparency as one of its advantages.
When software is closed-source, its users must rely on the developers to maintain that software.
> Why all-or-nothin?
The parent was citing the existence of a few specific bugs in macOS and Open Source as an alternative (implying it wasn't vulnerable). I really think the "given enough eyeballs, all bugs are shallow" is something Open Source advocates take too much comfort in. The idea does have merit, but there needs to be more study/context to how it plays out in real life.
Another example where this idea fails; there are credible suspicions that the NSA has influenced encryption standards introducing backdoors or known flaws even though the algorithms themselves are publicly known and freely available as well as the implementations.
That may be true, but the alternative is certainly worse.
If I found a bug in ssl, I can't imagine I'd re-compile that and track down every package I use that relies on it and re-compile those. Everyone uses their own build system and managing dependencies suck. I'd try and mitigate the risk against those tools until fixes were distributed through normal channels--just like I would in Windows or macOS.
If I was a large company, with closed source software I would have a vendor agreement to get fixes/changes, with open source I would have the expertise in-house and extra labor (or I'd have an agreement with a support company like Red Hat much like closed source software). A small company likely won't have the expertise in house or the spare bandwidth to mess with those things. For home users it would have to be someone with a serious hobby and specific skills.
I'd send you to the relevant jwz rants but I'd rather spare everyone the goatse-ing...
s/that goes viral before reaching \"proper\" channels//
The fact that the problems existed to begin with is more troubling than whether they became known outside the company or not. IMO.
With an open source UNIX-like OS (like the ones Apple sourced from for parts of macOS), both the developers and the users can watch the commits as they happen. Developers and users anywhere can choose to watch the commits and may be able to detect a series of poor quality ones. At least they can make informed decisions on the relative merits of changes from one version to the next. (Edit: They might choose not to compile or install certain components. I do not use X11. Nor do I use systemd.)
The fact that development of macOS is hidden from those outside Apple and that problems are protected from "going viral" does not make the problems any less of an issue for macOS users.
The issue is not how fast and secretively they fix problems, it is how many problems their developers are introducing into the existing version to begin with.
If there are problems routinely being introduced then no amount of fixing after the fact and behind the scenes is going to make the OS higher quality. Only due care taken before introducing changes will guard against further deterioration of quality level.
(Edit: The mention of open source is not intended to be interpreted as an argument that open source inherently results in better software. Perhaps skill and attention to detail are at cause. This is a debate worth avoiding.
The relevance of the mention of open source is intended to suggest that detecting and avoiding problematic software may be easier for some users, e.g. yours truly, if they can access the source code. As opposed to hoping that Acme Hardware and Software Corporation will quickly and secretly fix all software problems that slipped through their QC procedures. Too late for the user who has already paid for the software and updated to the new version. That argument should not be too controversial.)