And when they are found they are fixed and the community is always outraged.
When a closed source project has a bug in it, sometimes the knowledge of that bug is kept hidden. Maybe most of the time it is handled responsibly, but without oversight how can an outsider tell?
You mean for those few FOSS projects that both get plenty code review and fix those bugs? Sure those probably are better off than average proprietary. Much worse than proprietary niche that's quality-focused. Yet the community isnt outraged enough to use low defect processes to prevent the next set. Further, that both FOSS and proprietary focus on getting features out quickly with few review ensures plenty of bugs in both.
The trick to either is the committment to quality/security is real, each commit is reviewed before acceptance, and independent verification is possible. With proprietary, the confirmation can come from a trusted third party, several third parties (mutually suspicious), or source provided to customers (but still paid).
In the long the source being publicly available means the bug will be found.
> Much worse than proprietary niche
I disagree, but even if I didn't how can the average purchaser of software discern quality software from junk. If they had the source, they could pay an expert.
I agree a commitment to quality, and therefor security, is important. But I feel that if all other things are equal the open source software will always have an advantage over the closed sourced software.
Reliability, determinism, and security vulnerabilities are a good start for the purchaser. For the reviewer, we already know what methods [1] historically improved the assurance of software. Every method they added, the more bugs they found. That most proprietary and FOSS software use little rigor is why they're insecure. Only a few proprietary or academic offerings, not community driven, had the rigor for the B3/A1/EAL6/EAL7 process. I give examples here [2] for those that want to see the difference in software lifecycle.
Can you name one FOSS product designed like that? Where every state, both success and failure, is known via design along with covert channels and source-to-object code correspondence? I've never seen it. Although, it has happened for a number of proprietary products whose claims were evaluated by NSA & other professional reviewers for years straight without serious flaws found. So, for high security, the "proprietary niche" that does that has beaten FOSS by far and mainstream FOSS is comparable to mainstream proprietary in quality (i.e. priorities of provider matters most).
FOSS can potentially outdo proprietary in highly assured systems given they have free labor. In practice, they do whatever they feel like doing and so far that's not using the best software/systems engineering practices available. So, I don't trust FOSS any more than proprietary except in one area: less risk of obvious subversion if I verified transport of the source and compiled it myself. Usually plenty of vulnerabilities anyway, though. Would love to see more high assurance efforts in FOSS.
And when they are found they are fixed and the community is always outraged.
When a closed source project has a bug in it, sometimes the knowledge of that bug is kept hidden. Maybe most of the time it is handled responsibly, but without oversight how can an outsider tell?