Study: Engineering teams, not processes, factor heaviest in code quality

As the Slashdot commentary suggests, new research that finds open-source code quality to be no better than that of proprietary software has its flaws. "Code quality" is difficult to measure. Finding metrics to analyze the successes and failings of four operating systems--FreeBSD, GNU/Linux, Solaris, and Windows--is especially difficult.

So, while Coverity recently found open-source software quality to be quite high and continuously improving, I suspect there's some truth to the conclusion of the research:

Across various areas and many different metrics, four systems developed using wildly different processes score comparably. At the very least, the results indicate that the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.

This does not mean that process is irrelevant, but that processes compatible with an artifact's requirements lead to roughly similar results.

I buy that. Gold doesn't miraculously emerge from garbage developers, no matter the process. Good people will always be the foundation of good code. As one commentator noted, team almost certainly trumps process when it comes to writing high-quality software.

However, I also believe that an open process can help to mitigate some deficiencies in the team. Perhaps more importantly, an open process can help to allocate superior resources that might not otherwise be known to the project lead at the start of the project. Also, as more developers opt to work on open source, it's very likely that the best developers and, by extension, the best teams of developers, will want to work on open-source software.

In other words, if you're limited to the people that you can hire through your network or a recruiter, and if you limit those developers to working on proprietary software, you may be hobbling your project from the start. Open source may result in a wider diversity of hands and eyes working on a project. It's not a guarantee, but it's a way to let process influence the composition of a development team.

[jrepenning]

The Open community (and the Agile community, for that matter) have already been making the "better process selects for better workers and encourages better practice" argument for some time. Studies like the Coverity one are attempts to verify that claim. If their results are ambiguous or non-confirming, then to the extent we believe their results at all, they're saying that this claim is ambiguous or unconfirmed.