Re: "bugs are much more likely to be found, fixed"
You obviously aren't familiar with the process of modern FOSS code review. It isn't about big security issues like this - those are the ones that get headlines but the "many eyes" process doesn't just (or even mostly) help with that.
I am not a kernel developer but I follow the btrfs development mailing list. Every patch to btrfs goes through that list. Every patch is reviewed by several of the key developers. So far, that is similar to the proprietary process (except that the reviewers work for different companies - itself a small benefit). But every patch is also reviewed by a lot of other people - some, like me, are just interested techies - some are very experienced system managers who have dealt with bugs in btrfs for many years, build their own kernels, and help track down problems - some manage the largest btrfs deployments in the world (think about places like Facebook) and have a lot of experience of how things fail in their world. All these people contribute to the review and the testing - before the code is even sent to Linus for the rest of the world to see.
The effect is that most of the bugs found by these people are not major security issues - they are functional issues, deadlock issues, hangs, performance slowdowns, etc. Many, many of those are found by interested parties in the community, long before the code gets out.
Personally I have only contributed one patch to btrfs. That was to fix a small functional issue - that probably would only affect less than 1% of users (still a lot!). But I have participated in other discussions and testing that have resulted in improvements to the code.
Yes, there are many FOSS projects that don't get the review, testing and support that the kernel does (and even parts of the kernel that don't get much interest - I submitted a long-asked-for improvement to a small and unloved part of the kernel and it took months to get it reviewed and accepted) and we need to improve that. But that is nothing to do with the "many eyes" issue.
FOSS has plenty of faults but there is no point trying to deny that the "many eyes" process is an important advantage for FOSS - which has to be weighed against the various disadvantages. This particular incident is a great example of the considerable benefit it gives.