This quote struck me from an interesting article called World Wide Mush by Jaron Lanier in the Wall Street Journal:

Here’s one problem with digital collectivism: We shouldn’t want the whole world to take on the quality of having been designed by a committee. When you have everyone collaborate on everything, you generate a dull, average outcome in all things. You don’t get innovation.

If you want to foster creativity and excellence, you have to introduce some boundaries. Teams need some privacy from one another to develop unique approaches to any kind of competition. Scientists need some time in private before publication to get their results in order. Making everything open all the time creates what I call a global mush.

There’s a dominant dogma in the online culture of the moment that collectives make the best stuff, but it hasn’t proven to be true. The most sophisticated, influential and lucrative examples of computer code–like the page-rank algorithms in the top search engines or Adobe’s Flash–always turn out to be the results of proprietary development. Indeed, the adored iPhone came out of what many regard as the most closed, tyrannically managed software-development shop on Earth.

To which I say, “What about the Linux kernel?”  Lanier raises some interesting points and includes some compelling examples, particularly the iPhone, but overall his article feels too “all or nothing”–that all mass collaborations in all settings always turns to mush.

There are a number good aspects to the open model that Lanier has overlooked, particularly the number of hugely successful and widely used open source software programs–all of which by definition, are free.

Lanier’s criteria for the “best stuff” is confusing.  “Sophisticated and influential”–maybe, but “lucrative?” It seems odd to make monetary success part of the criteria when the whole point is making these these programs freely available.

A “design by committee” approach for strategic leadership does turn to mush.  This is why I believe the leadership bodies of the Fedora Project, particularly the Fedora Board and Fedora Engineering Steering Committee (FESCo), have an obligation to lead and that all of Fedora cannot decide Fedora’s strategic direction together.  These leaders can and should solicit input and ideas from all of the Fedora Project.