Jon Udell posts about an experiment in cookie development, pitching cookie emulations of three common work paradigms in software against each other. The the glee of commercial software types, the traditional managed approach won. This is entirely unsurprising, but not for any of the reasons Udell gives.
From the description given, it's unclear whether staffing was the same on all projects, but even if it were there's no surprise in that the managed team came out ahead. What they were doing was delivering one take on one product - no second generation to consider, no bugs to fix. I don't know of any argument why this would be faster with open source.
Secondly, all the succesful open source projects have a 'star manager' (in the parlance of Udells post). Linux has Linus, Python has Guido, Perl has Larry, Firefox has Goodger and Ross. The list goes on. It's unclear whether this was the case for the cookie project, but if not I can't think of any good reason why open source by committee would be any better than any other software designed by committee. I am reminded of Jimbo Wales' statement about Wikipedia at Reboot: It doesn't work because it's a reputation system, but because it's a reputation culture. There's always someone there to command natural respect.

The reasons given, while obviously not without merit for the case of Linux (there was plenty of inspiration around) just fail completely for other categories of software. Apache was a semi-early entry in its category and was based on the equally open NCSA HTTP daemon. Not first, but still quite early. Python/Perl/Ruby had no obvious predecessors. In short, the reasoning that open source can't lead but only follow seems entirely bogus, based on examples defined by succesful commercial software. Obviously in these cases, open source can't win.