Linked by Thom Holwerda on Tue 19th Jul 2005 19:23 UTC, submitted by Just_A_User
FreeBSD On Tuesday, code-analysis software maker Coverity announced that its automated bug finding tool had analyzed the community-built operating system FreeBSD and flagged 306 potential software flaws, or about one issue for every 4,000 lines of code. The low number of flaws found by the system underscores that FreeBSD's manual auditing by project members has reduced the vulnerabilities in the operating system, said Seth Hallem, CEO of Coverity.
Permalink for comment 6633
To read all comments associated with this story, please click here.
RE[2]: the shape of things to come
by butters on Wed 20th Jul 2005 05:28 UTC
Member since:

I'm sorry, I'm not allowed to provide statistics, but you must have read that my job is to analyze proprietary (read: AIX) source code with static anaylsis tools and manage a system that provides tools for complaint mitigation and statistics collection. AIX and FreeBSD are fairly similar with regards to the nature of the codebase, although AIX is significantly larger. I can say with absolute certainty that the number of valid complaints found in AIX using static analysis is higher than 306, and that the number of complaints per thousand lines of code is higher.

The reason is because companies like IBM are servicing different kinds of customers. Some customers demand that we only ship them fixes for field-reported software defects, because they fear that internally discovered defect fixes might destabilize their mission-critical systems. Customers demand that we test our fixes, and that we test them on their hardware configuration running their OS level. They demand 1 week regression runs for all fixes, and they want them to be tested for versions of AIX that are several years old.

In open source projects, the situation is usually more like: I make a code mod, it works for me, create a diff, send the patch upstream, works for maintainer, earmarked for next week's release. There is normally no fix backlog for simple code mods. There is also a sense of pride in fixing problems in open source software, even if it is low hanging fruit. No one wants to touch the low hanging fruit in proprietary software development unless a manager imposes a deadline for closing those defects.

I'm not aware of any proprietary software project aggregator that makes people aware of new proprietary software releases, whereas with open source there's freshmeat. Half the people in my building don't even know that my static analysis infrastructure exists, because the communication sucks. Developers get angry when some smtp daemon sends them an email about various problems with their code. For proprietary software developers, static analysis is a necessary evil used to satisfy certain code drop requirements, but for open source developers it is an excellent way to quickly find bugs and an even better way to involve new contributors.

I've worked in both open source communities and proprietary software development, and I've dealt specifically with static analysis tools, so I wouldn't be so quick to dispell my comments as BS.

Reply Score: 2