Many Eyes, But How Many Brains? - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Government // Enterprise Architecture
Commentary
7/16/2008
11:02 AM
Serdar Yegulalp
Serdar Yegulalp
Commentary
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Many Eyes, But How Many Brains?

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 reinf

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
News
The State of Chatbots: Pandemic Edition
Jessica Davis, Senior Editor, Enterprise Apps,  9/10/2020
Commentary
Deloitte on Cloud, the Edge, and Enterprise Expectations
Joao-Pierre S. Ruth, Senior Writer,  9/14/2020
Slideshows
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Slideshows
Flash Poll