Well, he makes some good points. Code review is indeed difficult, requires good skills, and is not done by many people in the free software community (the OpenBSD development team being a notable exception). Good software engineering methodology is crucial, certainly.
He concludes that Microsoft ends up shipping fewer vulnerabilities than anyone else. Is this true? Well, with the obvious exception of OpenBSD, it might be; but that's not the whole story. What developers do when a vulnerability is found is pretty important, too. Probably even more important.
Not long ago, a serious vulnerability was discovered in several versions of IE. Turns out
Microsoft had known about it for several months. So, naturally, they had a patch all ready and tested before it
became a problem - right? Well, no. Instead, they
urged users to upgrade to IE8. The bug didn't get patched until
almost a week after exploits were seen.
For all their professionalism and expertise, Microsoft developers labor under a severe handicap: they have to work on what Microsoft managers tell them to work on. They may think that a given bug is urgent and should be patched right away; but at the end of the day, the priorities are set by people who are focused on the bottom line, and those people know that nothing much is going to happen to Microsoft if a vulnerability is left open for a week or two. Every year, people in the Linux community confidently assert that
this is the year of the Linux desktop; and every year, they're proven wrong. Too many people are locked into Microsoft's proprietary formats, and have too much time invested in learning to use Windows, to switch easily. And that's not going to change anytime soon.