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

New research suggests that open source doesn't necessarily create better-quality software. This is perhaps not surprising, but begs the question as to whether the open-source process does attract better developers.

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.

Tags:
Tech Culture
About the author

    Matt Asay is chief operating officer at Canonical, the company behind the Ubuntu Linux operating system. Prior to Canonical, Matt was general manager of the Americas division and vice president of business development at Alfresco, an open-source applications company. Matt brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. He is a member of the CNET Blog Network and is not an employee of CNET. You can follow Matt on Twitter @mjasay.

     

    Join the discussion

    Conversation powered by Livefyre

    Don't Miss
    Hot Products
    Trending on CNET

    HOT ON CNET

    Find Your Tech Type

    Take our tech personality quiz and enter for a chance to win* high-tech specs!