Collaborative notes taken at the O'Reilly EmergingTechnology conference using SubEthaEdit (was Hydra) during ClayShirky's keynote speech, " A GroupIsItsOwnWorstEnemy". -- AdamShand
Clay Shirky - adjunct pruofessnct professor at ITP - "A group is its own worst enemy"
Social Software, and pattern regarding large supporting, long-lived groups.
Def: "Software that supports group interaction"
Many to Many rarely works correctly. Ridiculously easy group forming is very new. Just at the cusp of learning what works.
Definition is unsatisfying. Can't point to a single tool and say this is what it is.
- email doesn't support a bro
Weblogs are not necessary, but they -can- support social patterns. "Groups are a RunTime effect"
Much acabout surprising uses of group software. Unexpected by the developers
- Lit?
- Bayan's research about why a group is its own worst enemt
- Why think about this now?
- ID several (1/2 dox) things that are core to software to support longlived group efforts.
W.R. Bion, 1950s. Psych doing group therapy w/neurotics. Noted that as a group they conspired to defeat therapy. Whenever something was attempted to assist the group, group quashed it. Couldn't resolve the distinction between aggregated action vs individual. Homans function across both axes at once.
- More on Bion
- Experiences in Groups: And Other Papers by Wilfred R. Bion
Groups can be analyzed as both collections of individuals, and as an emotive group force/cohesion.
FWIW, Clay's RSS feed: http://shirky.com/writings/rss.cgi
Thesis is that the identification, etc, is much deeper, example:
- One at a party. Disengaged. But you don't leave. Make the decision that you "don't like this" but do not leave (note - this is different than from a book store, etc. if you get bored -- you usually leave). That social stickiness is what Bion is speaking of. But then one actor leaves, and everyone leaves. Triggering event (Gladwell's tipping point) pushes group over to action; "Paradox of groups"
At some point, you start getting group effects. Bion determined that the group was 'defending itself' against an outside source. Showed basic/specific patterns that the group enters into
- "sex talk" Conceives of purpose for flirtatious or pairing talk.
- identification and vilification of external enemies (s.a. OSS discussions in mid 90s; "warblogs")
- Religious veneration. Nomination and worship of an icon ("cult of clay") Nomination of something -beyond critique-.
Groups sandbag their sophisticated goals with this basic patterns. Groups learn structures (robt's rules of orders, etc). These structures defend the group from itself, from the above three patterns.
Early 70s. Communitree BBS. Concept of open access / free dialogue. (notes that incredible things can happen in these setups in their early days). However, over time, new patterns can emerge. In communitree's case, unanticipated group (HS boys) was introduced. Group felt overrun. "Too much freedom" Needed to add structure, no way to do it. The group's inability to defend themselves could be arguably social or technical. Moot issue, given intertwining (intertwinglying) of these. "An attack from within is the pattern that matters"
"Learning from experience about the alligators is lousy, rather than from reading..."
The Lessons Of Lucasfilm Habitat
Pattern happens over and over again.
LambdaMoo Takes A New Direction
http://www.cc.gatech.edu/classes/AY2001/cs6470_fall/LTAND.html
- wizards wanted to just be techies and not do the social aspects that failed miserably -- that placed needed a government
People who work on social software are more like economists or social scientist thatn programmers.
This struggle is analogous to a constitutional crisis. The first case is the worst case, because that is when rules need to be made for the making of rules.
The probability that any unmoderated group will get into a flame war over whether to have a moderator approaches one as time increases. -- who said this???
IIm is the wor. Why Now
The number of tools is astronomical now. The number of users, tools, etc. In part because of the relative decoupledness.
But the downside of this is that the dense interconnected matter that drives groups is not scalable to this level. We blew past the interesting mid-size scale of groups (larger than a dozen, less than a thousand)
Small groups can engage in patterns of interaction that large groups can't.
Now getting interesting ways (RSS, chat, etc) to experiment in this, and ways to do the experiments quickly and cheaping. When you lower cost, interesting new things happen.
Why Now?
Because it's now. Just learning patterns over time and internalising these ideas. For Clay, Phil's Pepy's diary implied a longevity - 10 yrs - that weblogs were infra, not as ephemeral. (http://www.pepysdiary.com/)
- Because it's web-native (weblogs, wiki's). He criticizes the "Lotus juggernaut with a Web front end". It's the web all the way in (not like lotus notes with a web plugin). Easy to extend, easy to break-down. Assumes http as xport, markup as encoding. Lets us build things quickly.
- We can now have a small pieces loosly jpoined (coupling, synchronous/asynchronous) pattern. Ex: Emergent Democracy work by Joi Ito. Joining of conf call / chat / wiki loosely linked into a mesh of modes. Interrup messages move to chat room from conf call, and in chat or wiki, annotation happens. "Broadband Conference Call" held together with a little bit of social glue.
- Ubiquity. All people (in certain situations) have access to the internet. All is a very different amount than most. No longer in a two hula hoop world, where online and offline worlds are distinct.
Quickly becomes an assumption that the group memory, that this ubiquity, can be done.
Note: Sounds like Hydra is just a live Wiki page. All we need are Wiki features in Hydra, (or add Hydra like features to something like Voodoo Pad. Hydra's a realtime wiki page; wiki's stateful, each person edits changes distinct from others; but now they're all simultaneously.
III. What can be done
What makes a lg long lived group successful? "It depends Social Software sometimes works, sometimes doesn't.
The normal experience is failure. There's 'nothing' you can do to make it come out right each time.
But there are 6 or so things that can be ided in successful projects.
Three things to accept, design for four.
1.
- Do not seperate technical and social issues. Don't break apart the tracks. You cannot specify all social issues in software.
- Software only determines what people will do up to a point. Not all social issues can be specified in technology The group will exhibthe group to define and defend the values.
- Core group is differentiated from the users. The group that gardens the environment. (See Also any non-profit...). Members in good standing, will find one another
- Group's needs must sometimes trump the indiv. users needs. Citizenship is beyond the ability to log in.
Citizens in good standing will find one another and recognize one another
All groups of any integrity have a constitution, whether in code or in social charter. But there's always an informal one. groups always have a constitution, formal (code) and informal (how we do it around here). You can't separate formal and informal.
What to design for
Handles the user can feel matters (not ex. identity). (Related to Howard's notion of reputation fr Anonymity om yesterday's keynote?)doesn't work (-- who saiweak psuedo doesn't work either)d what when is the minimum for a conversation enable penalties for changing handles Kaycee Nicole id change: http://www.rootnode.org/article.php?sid=26
reputation is not portable there has to be a penalty to changing handles
- on ebay, you lose your seller rating entirely.
- on slashdot, you lose your "karma".
- on kuro, you lose your article posting points.
- has to be a way to have members of good standing - reputation systems witho penaites and bonuses
rok hinesobB arhard dririves ebackrs and tfo paortrtihcipatei Segmentationon.
Some segmentation of cap of when you join th enetwork, your handle is appencp reputation system
- social software's ease of use needs to be taken account by the group and not the user.
4. have to spare the group from scale.
- here is obvious.
Need some barriers to participation. This means that some things need to be hard for some people. This gives the core group tools to defend the group from attacks.
5. Have to have some way to protect the group from scale. Metcalfe's law is a b Many to Many doesn't blow up like a balloon.
These are, of course, just cores; plenty of other interesting things that can be done and seen.
"Community leads to content leads to commerce" idea failed. Users are there for one another, not the product.
Build for a handful of givens. Assume that as a platform. Then you can go on to the interesting stuff.
Q: Marc C. "love everything. One usage of terms. Online communities are more than just message boards and fora."
A: acknowledges. Tom Coates essay on plasticbag on social software. Its the blending of online and offline communities, as in the conf room. Uses the online information as that is where the builk of the literature is.
Q: Tools have been around, and similarly the Kay preso showed long-aged tools. So what are the barriers? WHy aren't we in more 3d immersive, rather than just text.
A: VRML's design without purpose meant any machine could run slowly.
Still doesn't believe in immersive environment. But concentration on the strange new effects distracts from the important stuff. EMail, for example, is the serial killer app. The nonimmersive software allows more for the SmallPiecesLooselyJoined pattern. Immersion is not as universal a pattern.
Q: Different groups have different social needs.
A: Model in past has tended to be architectural. But now more of a shipbuilding approach. Not a place to be, a place to go somewhere together. Not yet a lot of software that anticipates patterns (gently?) No longer has to be all things for all people, because the tools reduce barrier to entry.
Mentioned texts:
- LambdaMOO Takes a New Direction
http://www.cc.gatech.edu/classes/AY2001/cs6470_fall/LTAND.html
- Pepys Diary
- Excesses of Social Software
http://www.plasticbag.org/files/comm/the_excesses_of_social_software.shtml