Ignorance of Crowds


In the latest Strategy+Business magazine, Nick Carr discusses the ignorance of crowds and the limits of open source innovation. Peer production, and in particular the sub-genre known as user generated content, has been the latest hammer that has made every business problem look like a nail. Carr shows that he is one of the few people who understand the role that context and coordination play in the realm of peer production.

First, peer production works best with routine or narrowly defined tasks that can be pursued simultaneously by a big crowd of people. It is not well suited to a job that requires a lot of coordination among the participants. If members of a large, informal group had to coordinate their efforts closely, their work would quickly bog down in complexity. The crowd's size and diversity would turn from a strength to a weakness, and the speed advantage would be lost. Second, because it requires so many "eyeballs," open source works best when the labor is donated or partially subsidized. If Linus Torvalds had had to compensate all his "eyeballs," he would have gone broke long ago.

Carr brings up the flaws in Wikipedia again (something he enjoys harping on). I'm not convinced that Wikipedia is successful because of the peer production aspects. I think it's popularity stems from being the first free encyclopedia on the web (at least, it was the first one I ever found). Anyway, it's nice to see this buzz finally starting to die down, and for people to accept the role of peer production as any other tool – useful in certain situations.

  • I am curious to see whether this author is correct and that peer generated content is just a currently popular paradigm. The comment about hammers & nails might apply to the situation.

    However, I am not sure that this is the case. Peer generated content might be around for as long as we have this Web 2.0 kind of communication. Wikipedia’s greatest success is in breadth, not depth, of information. That comes from different people writing about what they know.

  • I’ve found one of the advantages of open-source software is that it doesn’t large numbers of dedicated contributors. If you have 10,000 people who each come up with one possible improvement or contribution, all you need is a very small number of people to package it all together. And because the individual contribution is minimal (i.e. wikipedia), paying them or keeping them on salary is not as big a priority.

  • I agree that peer production works best with routine tasks, although I am not sure in the case of coordination. Since people are more willing to render their support, I think it’s even faster for the group to achieve something

  • A lot of coordination will indeed slow down production with peer production. There should be balance to within the group to prevent those effects.