This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Collaboration

Five principles for successful mass collaboration, part 2

By Charles Leadbeater on April 01, 2008 (10:00:00 PM)

Share    Print    Comments   

Linux has succeeded as a product only because the community that supports it has organised itself systematically to create, share, test, reject, and develop ideas in a way that flouts conventional wisdom. Successful We-Think projects are based on five key principles that were all present in Linux. Yesterday I talked about Core and Contribute. Today, it's Connect.

This article is excerpted from the newly published book We-Think: The Power of Mass Creativity.

At the St. Louis World's Fair in 1904, an ice cream stand ran out of cups. The owner of the waffle stand next door started rolling his waffles to form cones. There was nothing new in either ingredient, but the combination of ice cream and the waffle created something entirely new. The more combinations a community can create, the more innovation there will be. Cities are creative when they make these combinations possible. The same is true of We-Think.

Diversity counts for little unless the different ideas that are floating around can be brought together to cross-pollinate. A community that is diverse but Balkanised will not be creative. People with different ideas must find a way to connect and communicate with one another. When they do, and in the right way, the results can be explosive. James Watson and Francis Crick unravelled the double-helix structure of DNA because they found a way to combine their very different outlooks. Crick's training spanned physics, biology and chemistry. Watson had trained as a zoologist but had become fascinated by DNA after studying viruses. They combined their ideas through constant, intense conversation of a kind of which their rivals were incapable. Watson and Crick's collaboration was a case of one plus one equals 12.

The larger the group and the more diverse perspectives are involved, the greater the benefits from combining them. Take five people, each with a different skill. That gives 10 possible pairings of skills. Add a sixth person with a different skill. That creates not 12 pairs but another five possible pairings 1 -- 115 in all. A group with 20 different tools at its disposal has 190 possible pairs of tools and more than 1,000 combinations of three tools. A group with 13 tools has almost as many tools -- 87 per cent -- as a group with 15 tools. Not much of a gap. But if a task requires combining four tools it is a different story. The group with 15 tools has 1,365 possible combinations of four tools. The group with 13 tools has 715, or about 52 per cent. Groups with larger sets of diverse tools and skills are at an advantage if they can combine effectively to take on complex tasks.

Markets are not the best way for people with diverse skills to connect and combine. A market might provide a way for someone with a problem to find someone else who might have a solution: if you have a leaking tap, you look for a plumber. That is the model of Innocentive, the scientific problem-solving community that was spun off from the drugs company Eli Lilly. Companies can post their scientific problems on Innocentive's Web site to see if they can be solved by one of the more than 100,000 scientists signed up to the market. But markets of this kind have inherent limitations: they work for specific problems that need exactly the right individual to solve them. They do not provide the basis for sustained creativity and innovation to explore difficult complex puzzles. That is a kind of problem-solving that comes only from intense collaboration. In the worm project, the researchers started by meeting in the coffee room at Brenner's laboratory. In We-Think, crowds need meeting-places, neutral spaces for creative conversation, moderated to allow the free flow of ideas. This is why, at their heart, these projects have open discussion forums and wikis, bulletin boards and community councils, or simple journals like Lean's Engine Reporter and the Worm Breeder's Gazette, so that people can come together in a way that allows one plus one to equal twelve many times over.

In We-Think projects, the task of combining ideas is made easier because the products usually fit together like Lego bricks: they are made from many interconnecting modules. Modularity is not new; it has been a feature of computer development since at least as long ago as the 1960s, when IBM was developing its System/360 computer. Fred Brooks, the person responsible, wanted everyone involved to be kept abreast of what everyone else was doing. Daily notes of changes to the program were shared with everyone. Quite soon people were starting work each day by sifting through a two-inch wad of notes on these changes. The costs of communication and coordination spiralled out of control. Miscommunication and misunderstandings grew. Adding people to the project did not solve the problem: more work got done, but more misunderstandings were created and with them more bugs. When the wad was five feet thick, Brooks decided to break the S/360 into discrete modules that could be worked on separately. A core team set some design rules specifying what modules were needed and how they should click together. This meant that module-makers could concentrate on their patch while the core team looked after the architecture of the system as a whole. New and better modules could be fitted into the system without its having to be redesigned from scratch.

Modularity really pays dividends when it is combined with open ways of working -- when it enables a mass of experiments to proceed in parallel, with different teams working on the same modules, each proposing different solutions. This combination is how open source gets the Holy Grail: a mass of decentralised innovation that all fits together. Just as Lego bricks come in a dizzying array of colours, shapes and even sizes but all have the same system of connectors, We-Think projects have rules for making connections that usually come from the core team. This is what allows a mass of independent but interconnected innovation. Mass computer games, collaborative blogs, open source programmes and the human genome project all share this feature: they click together masses of modules.

However, a Lego brick structure is not enough to make We-Think work. Groups also need to make decisions. Diverse contributors can combine their ideas only if they can agree how to collaborate. Any commons will fall into disrepair if it is not effectively self-regulated. That is far easier said than done.

Tomorrow: Two more principles and some conclusions

Share    Print    Comments   

Comments

on Five principles for successful mass collaboration, part 2

Note: Comments are owned by the poster. We are not responsible for their content.

Five principles for successful mass collaboration, part 2

Posted by: Anonymous [ip: 76.167.97.132] on April 02, 2008 04:18 AM
"Any commons will fall into disrepair if it is not effectively self-regulated". They also easily fall into abuse. Watson himself led the way on that by cutting out an important contributor from the credit. Rosalind Franklin's DNA crystallography and understanding of the structures was critical to the success of the effort to understand the molecule. It'd be nice if we could do better than the Old Days. The web needs some way to embed all contributors in headers, like EXIF data in photos for instance, so that attribution is easy, complete, and fair.

#

Five principles for successful mass collaboration, part 2

Posted by: Anonymous [ip: 66.122.165.196] on April 03, 2008 10:25 PM
Also concider pojects posting there priorities and looking for over lap, so insted of multiple different solutions to the same problem you are first to a solution, with variation persude with a lowered priority or background. This way all the important stuff at least gets a proof of concept allowing perspective on reletive refinements.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya