The idea that the community fix resulting in faster time to protection is a flawed argument Matt. The vast majority of support agreements from vendors supplying OSS technologies prohibit modification of source code, and many mandate that you wait for the vendor-approved security patch to be applied to a system. I've been harping on this for a while, but the fact that a solution was developed under the OSS model does not mean that it is run in production as anything other than commercial binary code. If you have a support contract with Red Hat and SpikeSource, and SAP - and at each layer they specify what versions of what components with what patches you can run...you are not dealing with community fixes. The trade off in speed of fix availability is balanced by testing of the fix solution so you don't end up breaking other elements when applying the security patch. Customers expectations around stability and predictability make a difference.

I don't underestimate the value of community, but to position OSS solutions as somehow mystically better at security because of the development model is not supportable. The academic and industry studies I have seen support the fact that there is no superior mode of production when it comes to creating software with fewer security flaws (because devs are trained the same way and make the same types of mistakes no matter who they are coding for). The quality of a vendor's securty response mechanisms and their engineering capacity to deal with incoming issues is hugely important.

Security is a universal problem and not limited to one vendor or one class of technology. All of us in the industry have a vested interest in seeing consumer confidence remain high in connected computing. Thus, I tend to find comparative arguments such as this to be more less productive than other parts of the grander OSS debate.

You need to start reading what I write, rather than what you think I write, Jason. I didn't say that the community would fix a problem faster. I said community pressure on the core developers, and the transparency of the process, results in faster fixes to problems. I think that has been demonstrated near-conclusively. It's certainly the case at Alfresco that the community (even though we have final control over the code) exercises a huge amount of influence over us - the transparency of that influence matters.

In other words, transparency of people matters as much - probably more - as transparency of code. You've solved, to a limited extent, the transparency of code issue for your customers (though you've done little to make it permeable for would-be customers), but you're failing to provide transparency of people and process.

You say, "The quality of a vendor's securty response mechanisms and their engineering capacity to deal with incoming issues is hugely important."

Agreed. That was my point. And I think a vendor's security response is either dramatically accentuated or pulverised by the community factor. Architecture should tend to be better in an open process (as in cryptography), if for no other reason than shortcuts aren't really permissible when the code is on display. I would expect that Microsoft has things in its code that it would be highly reluctant to publicly display, just as with any other closed-source vendor. For open source vendors, we don't have the luxury of hiding things behind copyrights and such.

Again, it's not a question of whether we do or don't allow modifications of our software - that's post-release of the code, and still doesn't touch my argument about community pressure. We have active, outside involvement in the code creation and beta/review process. That matters. It has an effect on our performance, stability, and security.

And no, it really wouldn't be that hard for Microsoft to do the same, and reap the same benefits. You just have a culutural hurdle to overcome first. I'd be happy to coach you on the process. :-)

Ouch!

Jason -- as all others adhering to the Microsoft messaging mantra -- ignores the most fundamental question of "Value for Money" -- since they use the term so frequently that they have lost the sense of its meaning: that file formats need to be open to even qualify for evaluation.

That is, there is no VALUE to a organization of a non-standard file format.

This will be more apparent as an OpenDocument subsumes whatever else is available that offers benefits in superficial areas.

Yes, it's a showdown. But you would have to trust the premise that orgnization want to remain dumb in discerning what is and isn't 'open' to believe superficial values will trump funamental values in the market in the next 2-4 years.