I remember being impressed by this article when it came out, but while this metric (about bugs found by fuzzing) is appealing, it's confounded by a lot of other

I remember being impressed by this article when it came out, but while this metric (about bugs found by fuzzing) is appealing, it's confounded by a lot of other factors—like development environment and language, coding standards, whether the project is regularly doing its own fuzz testing, whether the project makes effective use of high quality libraries, whether people who wrote important parts of the logic are super-sticklers for taking particular precautions... In particular, one development that way postdates this study is that lots of software projects started doing their own automated fuzz testing (but lots of others didn't). There are free software projects that don't do this, and there are proprietary software projects that do, and vice versa. A particular shock for people like me who had internalized this and also ESR's "many eyeballs make bugs shallow" and also the same-day Linux kernel patch for the Ping of Death was that Microsoft started spending a billion dollars a year or whatever on improving Windows code quality and security around 2007—and it actually worked! Also now Microsoft Research people are doing a lot of formal methods stuff (although I don't know how much their work influences Microsoft's software products). I think factors other than whether software is free or proprietary are now dominating for their influence on code quality metrics. (See also https://mako.cc/writing/hill-when_free_software_isnt_better.html https://mako.cc/writing/hill-when_free_software_isnt_better....)