Open Source Code Integrity - How does quality assurance work?

Question

I've thought about this before and this topic has often steered me away from Open Source projects. Recently DotNetPanel has changed it's name to WebSitePanel and gone Open Source. The rumor mill is speculating that Microsoft is behind this.

My question (in multi-part) is quite simple. Can somebody please explain to me how quality assurance works on Open Source projects? How can a closed application get "only better" when Open Source? Doesn't the "too many cooks in the kitchen" theory apply when too many developers contribute (possibly bad) code to a project?

Answer 1

It's a bit too open-ended. I'll try to answer in pieces.

• First, the BIGGEST argument regarding the quality of open source code has almost nothing to do with the people contributing code, and more to do with people VIEWING the code. E.g. if the people looking for the bug constitute 5 project developers and 2 QA department people (to pick a random example), this level of attention easily gets beaten by 10s, 100s or 1000s of developer eyes on the code depending on project's usage and popularity.

  If you think this does not happen in real life, a personal anecdote for you - I personally check - at least on a surface - the code of pretty much EVERY CPAN module I newly use in my code. And actively report any bugs issues if I find.

• Second, the pool of potential testers. Obviously, FOSS code has more users (since people who might bulk at closed source version due to price or philosophical objections are added to the pool) - and the latter ones are likely self-selected to be qualified testers and developers.

• Third, a good FOSS project has high quality lead developer or team whose job it is to integrate code and ensure its quality. The major difference actually benefits the FOSS model - the leads have no timing pressure compared to commercial company and thus have more opportunity to devote as much time as needed to ensuring quality, code reviews and such.

• Last, but not the least, you seem to be operating under the assumption that anyone working on proprietary code base is somehow automatically contribute code that is not bad to the project? If so, you're sadly mistaken - and this comes from someone who spent close to 100% of his professional development career working on corporate side of the gate.

Just to give this flavor, I personally, as I said, work on the proprietary corporate software, never was associated with FOSS project (partially due to lack of time) other than to test and report bugs as needed by my own usage, and only use FOSS stuff for practical reasons (quality/functionality) as opposed to philosophical ones.

Answer 2

Common sense, please. If you download code that one random person posted to an uncontrolled forge, you are taking pot luck. You had better be very careful before trusting it.

On the other hand, consider code from a project with a 10 year track record and a well-documented set of internal controls and procedures (e.g., oh, Apache Xerces). You know much more about its parentage and content than you will ever know about the binaries you get from, oh, Microsoft or Sun. You can take or leave the 'lots of eyeballs' argument. If you can read the entire email archive and see all the source history, you can judge for yourself. If you know that the package is extremely widely used, you have the luxury of trusting in all the people who have evaluated before you.

Many prominent FOSS projects are populated by people who are paid to work on them, just to toss in another fact. Plenty of non-FOSS is created by overworked, overstressed, underpaid developers who aren't given the time and resources to do their best work.