In our recent interviews with James Whittaker and Michael Howard, the importance of process came up. These two guys are focused on limiting security vulnerabilities in Microsoft software, so the conversation centered on security processes, but it’s just as true in all phases of software development.
It seems clear to me that closed source development has a built in advantage when it comes to process. It’s all in the fact that all phases of contribution are captive. (I know, that’s brutal.) What does that mean? It means you can mandate processes, and you can enforce them.
Let’s take coding standards as an example. Many older APIs that have always been available to C/C++ programmers introduce potential vulnerabilities in code. All string (array of char) functions that rely on a terminating NULL, for instance, are susceptible to buffer overrun exploits. People are animals of habit, however, and if you’ve spent 10 years using sprintf(), you’re probably going to use it again the next time you need to format a string. Surfing the web for sample apps verifies this. I’ve downloaded multiple C/C++ sample apps and in nearly all of them I’ve encountered the use of dangerous APIs like sprintf(). In a closed source environment, it can be made a matter of policy that code containing these dangerous APIs may not be checked into the source tree, and that policy can be enforced without a lot of trouble.
Does that mean that open source projects can’t set and enforce necessary process? No, I don’t think that’s true. I think that a necessary level of process definition and enforcement can be maintained in almost any development environment. However, it’s a bigger challenge with open source. Your development team is likely geographically dispersed, and your ability to directly influence contributor adherence is minimal at best. Clearly, though, open source projects are meeting this challenge at some level, since there is a lot of quality open source software out there, and you can’t get quality without process.
So how are they doing it? Is it through strong gatekeepers? Is it through setting a high bar of acceptance on prestigious project teams? (But what about the baby projects?) Is it through peer pressure? I’d like to know the answers to this; I’d bet there are many.
The other question I have is one where I’m starting to form an opinion, but it isn’t firm yet. Are there parallel advantages on the open source side? If closed source gives you a natural advantage in process control, is there a different natural advantage on the open source side? What do you think?



June 21st, 2007 at 10:36 pm
> Is it through peer pressure?
Yes - exactly. Although you may have fellow employees looking at your source code, I have fellow hackers - now and through posterity - looking at my code.
I want to provide something good, so I work to achieve high levels of code-coverage with tests, I write documentation and I (will) write articles about open-source software I have written.
It’s a bit more democratic than your “Open Source Dictatorship.” I can provide something of value without making sure my lawyers say it’s “OK” to give it away without maximizing shareholder value with it.
My $0.02