I've written before about how the "many eyes" philosophy of open source security is only a starting point. Now a post at InfoWorld's Open Sources blog asks a parallel question, in the wake of two security holes being unveiled in the Spring Framework. If anything, this reinforces my opinion from before: Open is not automatically a synonym for safe.

The main question the authors derive from all this: "Are merit-based OSS projects more secure than single-vendor-driven OSS projects?" To put it another way:

If developers outside the company can't contribute code, what is the likelihood that a developer will look at a piece of code within the project and ask, "How can I make this better?" -- and in the process uncover a potential security issue?

My feeling is that the structure of the project -- merit-based vs. vendor-supported -- isn't as important as whether or not there is someone on the project team whose full-time job (as far as the project goes) is to perform security auditing. It might be better if that position was reinforced with compensation -- i.e., someone was getting paid to do that kind of gruntwork -- but if someone who genuinely cares about the project is doing it, that's also fine. What matters is that someone on the team is doing it, that it is their explicitly appointed duty to do so, and that they are suited for the job.

Now: Is it easier to guarantee those things with a vendor-driven project? That depends on who's running things in the first place. Having positive cash flow is no guarantee of competence, although it is one of the better signs that the folks in charge have some idea of what they're doing.

It all comes back to something I keep running into with open source: It's almost never about the code, but the people involved. If they run a tight ship, it doesn't matter where the money comes from or even if there's much money at all. If they don't, then all the openness in the world won't save them. Or anyone else.