Introduction

I'm hoping to start a discussion here modeled after the one currently taking place on Timothy Gowers' is massively collaborative mathematics possible?, with the basic goal of designing and creating a collaboration tool well suited to this sort of thing.

There's already a second post, outlining the initial ground rules for people who would like to take part. As with just about everything else about this project, they are a valid subject for discussion.


Opportunity
I've become aware of an increasing interest in large-scale distributed collaboration; the tools available do not seem very suitable to the task; and -- perhaps most importantly -- awareness is emerging that the collaboration tools could be better-designed.

There's a feedback loop between the quality of the toolset and the quality of the collaboration, and I have in mind a collaborative project designed to take advantage of that feedback loop, using its own product (the collaborative toolset) in the process of designing, coding, testing, and improving it.

This message is intended as an invitation for collaboration by any interested parties.

Background
Three factors are important for any potential contributor to the project:

1. A general knowledge of collaborative communities. Of particular value: theoretical knowledge of the factors which cause a community to succeed or to fail; experience with one or more of the successful online communities; and current active participation in such communities. Best of all would be experience managing such a community, especially(!) if it ultimately failed.
2. Possession of any of the specific skills needed for the development effort. We'll need to do some coding, but there's a whole range of needed skills, including social engineering, cognitive psychology, human interface design, social network analysis, and so on. If there's a way you think you can help, you probably can. Even if you only want to use the fruits of our labour, we'd still like to get your input about what is required.
3. I like working closely with people who know how to behave themselves socially. Translation: be nice or get lost.

Criteria for Success

1. Health of the community
   
   
   
   1. reasonableness of the core people
   
   
   2. competence of the core people
   
   
   3. group social engineering
   
   
   4. usability of the initial platform
   
   
   
   


2. Benefits to the community
   
   
   
   1. prominent exposure if we succeed
   
   
   2. opportunity to prove competence publicly
   
   
   3. possibility of eventual sponsorship of the effort
   
   
   
   


3. Solving challenges (roughly chronological)
   
   
   
   1. management: cultivate awareness of the project
   
   
   2. social engineering: cultivate high-quality feedback
   
   
   3. design:
      
      
      
      1. lower barriers to participation in the community
      
      
      2. make it attractive, to attract participation in the community
      
      
      3. lower barriers to communication
      
      
      4. solve the "I speak when I want; you listen when you want" problem
      
      
      5. solve the "right amount of communication" problem
      
      
      6. incorporate and improve existing visualization and summarization tools
      
      
      
      
   4. thinking: anticipate and subvert monopolies
      
      
      
      1. democratize the viral network effect
      
      
      2. avoid leader worship
      
      
      3. facilitate branching & merging
      
      
      
      
   5. technical: the liquidity of trust kernel (described below)
   
   
   
   

Liquidity of Trust Kernel
The big technical challenge for the project concerns what I'm calling the liquidity of trust.

When someone participates in a collaborative project, they gradually earn the trust of their colleagues. Currently, this works very well for the people leading the project (e.g, Linus Torvalds, Richard Stallman, Pamela Jones, etc.,) -- the trust they have earned is well-known to the public, and it's easy for them to convert that trust into something of more immediate use such as academic prominence, paying jobs, etc.

It doesn't work so well for the people who play less prominent roles -- they establish the trust of the others within the community, but basically can't do very much to transfer that trust outside. This is especially problematic for the people who play supporting roles -- the system rewards flashy behaviour, but not the quiet, steady contribution.

I think it's essential in the long run to find an effective way to allow all kinds of trust (and distrust), established within one community, to be transferrable to another. This won't be easy, but I don't think it's beyond the capabilities of a carefully-constructed "super-programmer", and I won't be satisfied until we get it "just right". For this part of the project I also would like to quote djb: "I won’t be satisfied until I've put the entire security industry out of work".

For the time being, however, I think it suffices to commit ourselves to providing candid recommendations for people who contribute substantially to the effort.

Models

1. Tea Time -- the combination of the social and the mathematical hosted by math departments


2. Slashdot (comment moderation system)


3. Groklaw (massively collaborative community)


4. Stackoverflow (explicit treatment of trust)


5. GNU/linux (massive collaboration in a programming effort)


6. EVE online and other MMOGs (casual social cooperation)


7. Timothy Gowers' 'Is massively collaborative mathematics possible?' (functioning fine-grained collaboration)