Having worked on both commercial and FOSS code, I agree with your points, but there are several other issues. At each step along the way, the commercial environment is more complicated.

Design: In a commercial environment, I am told what the program is to do. This requires someone to explain not only the general functionality, but also some level of detail. The more miscommunication, the more the program has to be modified along the way. And when programs are modified, there are often ripple effects. In my FOSS project, I knew what I wanted from the big picture down to several levels of detail, and was able to make it modular, knowing that even if I had to change some modules, they would still work with the rest.

Staffing: Every commercial program I have worked on has had some turnover, and in one case the lead designers left. When new people are hired, they are expected to hit the ground trotting. While everyone talks the talk of programming standards, new team members usually introduce different styles that can affect readability. In FOSS projects, team members tend to stay longer and new ones have usually already started looking at the code, so the coding style tends to be more consistent. Also, when you live with an app long enough, you begin to run it in your head. While this is true of commercial developers too, turnover means losing some team knowledge.

Honesty: When I talk to developers (both commercial and FOSS), most of them are totally honest about the limitations, flaws, and poor design choices in the code. But I actually had a marketer prevent me from fixing a bug in a commercial product because they thought they could use it to trick customers into buying an optional feature. Fortunately the next user of the product to experience the bug was our own company--and we had the optional feature running, so it didn't solve the problem--and I was able to go ahead and fix it. I have never found a FOSS project trying to cover up problems.

Intangibles: I work on my FOSS app at home, so if I wake up with a good idea, I can make some notes about it, and maybe even a little code, before breakfast. While it is possible to do this in some commercial environments, based on personal experience and talking to co-workers, I doubt that it happens much there. And if I need a break, I can play the piano for about 1/2 hour and come back with a clear mind. Also, I can expirement with ideas without someone pressuring me to meet some deadline. For example, I spent a week reworking my lock functions at least 4 times before I was satisfied with them.

Finally, there is the pride of ownership. While I am sure that most developers are professionals and act that way, many of us have been thru mergers and layoffs and know what our value to the company is, which puts a damper on the motivation to become totally engrossed in the product. On the other hand, I will always own my FOSS code, and I am ready to discuss it at any level of detail to anyone who will listen.

Later . . . Jim

RenaissanceCore IDS, check it out at:
http://sourceforge.net/projects/renaissancecore

Jimm's observations were cogent, but he underemphasized one of the most important reasons open-source programmers are productive and faster to fix bugs: no meetings.

Our teams are geographically dispersed. Our budgets are low or zero. There's nobody to make us go through the hideous, brain-cell-destroying swamp of petty politics and lethal boredom that is the typical corporate meeting. Meetings are more often rituals designed to establish or maintain authority hierarchies than they are
ways to actually make good design or implementation decisions.

The time an "enterprise" programmer would spend in that swamp, *we* actually get to spend thinking and coding. Loss of the extremely limited utility meetings have in making us aware of requirements is more than compensated for by direct communication with our users through means like bug and issue trackers.

And deadlines. Don't even get me *started* about the effect of deadlines on productivity...suffice it to say that there's empirical evidence that the 'aggressive' deadlines so beloved of managers actually make development take longer than a "wake me up when it's done" policy.