Why Crowdsourcing Isn't Always Wise

Jaron Lanier, the futurist and virtual reality pioneer, thinks technology decisions shouldn't be made collectively.

By
Thu, March 25, 2010

CIOYour book, You Are Not a Gadget: A Manifesto, challenges the value of crowdsourcing. What's wrong with the hive mind on the Internet?

The fad is to assume that groups are always smarter than individual people. Somehow some magic wisdom will come about if you form a mob instead of having people work as individuals.

It does work sometimes: A crowd of buyers sets a price in a marketplace. But it only works if you want output of a single result. Otherwise, you get design by committee. You get features added to services without anyone looking at the whole complex picture of what you're trying to build.

There's nothing wrong with soliciting feedback and ideas, but you can't design a complex system that way. You get appeasement to this or that concern, like the health care bill. It breaks the heart of every idealistic person to say this, but sometimes there can be too much democracy.

The equivalent for CIOs might be scope creep on a project. No one's saying "no."

That's not how you create real value. CIOs and IT departments should look at the perception of their value. CEOs will say, "Why are we paying you if the crowd can do it?"

What should IT leaders do about that?

Know that crowds and people are different. Every design decision should be worshipful of the value of individuals and their separate contributions and knowledge, rather than averaging everything out to please an amorphous crowd. You shouldn't have stealth socialism enter into a company through the IT department.

Explain what you mean by 'stealth socialism.'

One of the big crazes is open software development where people work as if on the Linux model. There's a weird ideology among some developers that if software is open and crowdsourced, it's intrinsically better. Mediocre software made openly is sometimes more valued than other software made in a closed way.

People perceive value that isn't really in the code. It doesn't matter how software was created. You should make decisions based on the raw facts: What does this software cost and will it do what I need?

Why does it happen?

There are two stakeholders who benefit from it: lazy software designers and users who avoid responsibility because there's no one person accountable for the final product. No one gets the blame when it fails. When money's on the table, and accountability's on the table, people get smarter. Good development is about individuals who are competent and can be held accountable.

Continue Reading

Our Commenting Policies