When a product is already behind schedule and shipping late, I can just imagine how much pressure there is for security and QA to "accelerate" the review process. Somewhere, the bugs and vulnerabilities are probably ranked and prioritized (sorted by their cost-to-fix vs. the cost-to-M$-if-we-let-it-slide). Considering what we already KNOW has escaped the scrutiny of their security/QA review process, I wonder how much of this is truly undetected as opposed to problems they knew about and chose to ignore. It's the same result either way. Somewhere along the line, I think someone at M$ figured out that any number of patches could be released without spending any more than doing it right the first time. At first glance, this seems silly, but products that are held up in review are not generating revenue. At least open source is somewhat exempt from the profitability pressure to get the product out the door. IMHO, the need to minimize the cost/delay of the review process negates any advantage the closed source method could have had. Opinion: Traditionally, M$ has used the customer base as beta testers. For a long time, it kept their costs low, but now the security issue is getting out of hand. Another interesting point in the M$ argument is the reason why patches are delayed (because they are being tested.) Some of the security problems are so severe, even a "rough" patch might be better than nothing. Where was this rigorous testing when the products were being developed initially? One last point: At any closed-source vendor, who do you think is on the career fast track? It it the annoying QA person who detects a huge design flaw, or the project manager who kept "Widgets 2000" on schedule and pioneered interesting features that promise to keep the "Widgets" installed base on the upgrade trail? Would YOU want to work in a "boring" job, that was perceived by your employer as an "expensive" cost center? The prosecution rests.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/articles/191/5296#5296