Cynthia Kurtz is an independent researcher, writer, software designer and consultant who works on the "listening side" of organizational and community narrative. She helps communities and organizations use narrative and complexity approaches for decision support, sensemaking and conflict resolution.

This paper brings together three strands of theory about how people interact in order to achieve common goals: aspects of identity (categorical, relational and positional); types of identity interaction (selection, mobilization and commitment); and conditions of tie formation and dissolution (boundary areas on the Cynefin sensemaking framework). The paper explains how the three strands come together to form a “braid” of interaction contexts that influence the needs of those interacting. The braid is
used to consider design issues in software that helps people interact, both in a general survey of social software and in specific response to some influential papers in the area. Special attention is given to interactions surrounding the collaborative development of open source software and information.

Introduction

Finding ways to help people interact in order to achieve common goals is something I think about often in my work with organizational narrative and decision support. A few years ago I came across a fascinating confluence of three bodies of theoretical work about how people interact. Since then I have found this “braid” of thought helpful in designing systems to support interaction, particularly around narrative, sense–making and decision support. I am not a sociologist, and I don’t claim to have discovered a new provable theory which I can defend with empirical results. This paper is not a treatise; it’s more like a message in a bottle, a bit of flotsam sent out to the world in the hope that others can do something with it that is helpful to everyone.

The first strand: Three aspects of identity

The first strand of the braid comes from cross-cultural work on human identity, on which the literature is large and diverse. Of the many definitions of identity, I am most concerned with identity as a determinant of behavior, because I want to think about the actions people take when they interact with each other. I like the approach of Stryker and Burke (2000), who refer to identity “with reference to parts of a self composed of the meanings that persons attach to the multiple roles they typically play in highly differentiated contemporary societies.”

While reading the identity literature I was struck by the experiments of Nisbett, Peng, Choi and others (e.g., Nisbett, et al., 2001) on the cow–chicken–grass question (which is the odd one out?). These highlight the difference between categorical and relational aspects of identity. Briefly, categorical aspects of identity have to do with what a person is or has: brown eyes, male, bald, 40s, tall, pre–diabetes, likes chess, hates bright sunlight, and so on. Relational aspects of identity have to do with how a person is connected: three children, two siblings, parents divorced, friends in Norway, work associates in Japan, part of a worldwide chess club, sometime member of a church, and so on. These aspects of identity have been widely discussed and researched by various authors (see especially Taylor, 1998; Williams, 2000). The cow–chicken–grass experiments in particular have shown that Western
thinkers are more likely to favor categorical distinctions (the grass stands out: not an animal) while those with Eastern backgrounds tend to favor relational distinctions (the chicken stands out: cows eat grass).

Positional aspects of identity are also present in the literature but are much less talked about. These are based on placement of the part in the whole, not on individual characteristics or relationships with other individuals. Mauss (1985) quotes the following example of extreme positional
identity in Zuñi Native Americans from the work of Cushing (1896):

In each clan is to be found a set of names called the names of childhood. These names are more of titles than of cognomens. They are determined upon by sociologic and divinistic modes, and are bestowed in childhood as the “verity names” or titles of the children to whom given. But this body of names relating to any one totem — for instance, to one of the beast totems — will not be the name of the totem beast itself, but will be names both of the totem in its various conditions and of various parts of the totem, or of its functions, or of its attributes, actual or mythical. Now these parts or functions, or attributes of the parts or functions, are subdivided also in a six–fold manner, so that the name relating to one member of the totem — for example, like the right
arm or leg of the animal thereof — would correspond to the north, and would be the first in honor in a clan (not itself of the northern group); then the name relating to another member — say to the left leg or arm and its powers, etc. — would pertain to the west and would be second in honor …. With such a system of arrangement as all this may be seen to be, with such a facile device for symbolizing the arrangement … [a] mistake in the order of a ceremonial, a procession or a council is simply impossible, and the people employing such devices may be said to have written and to be writing
their statutes and laws in all their daily relationships and utterances.

Individuals in this society are given identities not because of their individual categories or relationships, but (for the most part) according to received positions in a fixed cosmology in which the laws of reality — really the very existence of the clan — are “written.”

Says Mauss (1985):

What is at stake in all this is thus more than the prestige and the authority of the chief and the clan. It is the very existence of both of these and of the ancestors reincarnated in their rightful successors, who live again in the bodies of those who bear their names, whose perpetuation is assured by the ritual in each of its phases. The perpetuation of things and spirits is only guaranteed by the perpetuating of the names of individuals, of persons. These last only act in their titular capacity and, conversely, are responsible for their whole clan, their families and
their tribes.

Contemporary manifestations of positional identity are less extreme than these, but in some limited situations they are strong determinants of behavior. Consider teams of people who fly airplanes: not only those who fly on the plane but also those who prepare it, receive it and coordinate its motions. Positional roles within such groups perpetuate as individuals enter and exit, and individuals “acting in their titular capacities” are responsible for aspects of the operation of the whole team. The behavior of individuals in roles is more attributable to their position in the group than to their individual characteristics or relationships.

The second strand: Disciplines of identity
interaction

The second strand of the braid is a construction proposed by Harrison White in his 1992 book Identity and control. White defines identities functionally, as emergent properties of human existence: “identity is any source of action not explicable from biophysical regularities, and to which observers can attribute meaning.” According to White, identities “are triggered by contingencies,” meaning they form and activate as a result of events:

Who “we” are is all bound up with what “control” is in social surroundings, and also depends on our grounding in material production and the constraints from physical space. Much practical activity keeps on being done, and that translates into normality and habit at some level. But chaos and accident are the sources and bases for identities, and it is identities seeking control which give energy to practical activity in social context.

White then goes on to talk about the ways in which identities interact. Interacting identities require a means of valuation in order to negotiate positions in relation to each other. The simplest means of valuation is the linear pecking order in which a simple ranking determines relationships and power structures. According to White, when humans transcended the simple pecking order their social structure evolved in three distinct ways (at once), and these three transcendences taken together can be used to characterize
the ways in which human identities interact.

To arrive at these transcendences, White cites observational work by Bales (1970) using his Interaction Process Analysis system for observing interactions in group discussion. White interpreted Bales’ twelve categories of apparent evaluation (indicators like “seems friendly,” “asks for opinion” and “shows tension”), into three classes, as follows.

Communications judged on friendliness evaluated whether the communicators were friendly or hostile in their intent. According to this evaluation, a highly valued communication was pure, acceptable or safe.

Communications judged on dominance evaluated whether the communicators were dominating or submissive in their stance. According to this evaluation, a highly valued communication was prestigious, powerful or important.

Communications judged on instrumentalism evaluated whether the communications were useful to the receiver. According to this evaluation, a highly valued communication was of high quality or useful.

White goes on to say that when each of these valuation methods dominates a situation, we can say that interaction in that situation falls into a related “species of discipline” (type of identity interaction), thus.

An arena is a discipline in which evaluation of purity (acceptability, safety) is dominant. In an arena, which White calls “the sift–and–exclude species” of discipline, the dominant activity is a selection process by which “the formation sifts itself apart and together into new identities.” Combinatorial chance and unforeseen accident are important in arenas, which are flexible so as to accommodate “various and unexpected actors.”

A council is a discipline in which evaluation of prestige (power, domination) is dominant. In a council the dominant activity is a mobilization process centered on “balancing contending but ever–shifting coalitions.” The formation and dissolution of factions or coalitions is a continuous and emergent process, as “mobilization feeds on itself,” every action implies a counteraction, and “there is never a solution, a permanent alignment of factions, for that would contradict the general process.”

An interface is a discipline in which evaluation of quality (instrumentality, utility) is dominant. In an interface the dominant activity is a commitment process by which identities lock in to “a mutually constraining array of contentions for control which yield as net resultant a directed flow.” An interface is “robust to both internal and external control projects” and “difficult to disrupt.” Thus it has a degree of consistency and coherence that the other two forms lack.

To give an example of such types of interaction, suppose that people meet at the first meeting of a new conference. Say that the conference organizers deliberately set up the conference so that no two attendees know each other (I know, impossible; but bear with me). As the meeting begins, people mill around the room, “people watching” and having brief conversations. They are
pursuing a process of selection heavily influenced by chance proximity and a seeking out of pattern–forming indicators. Perhaps two people have chosen the same food from the buffet, or one person has an interesting hat, or someone makes a comment about the conference center.

As time passes groups begin to form, perhaps because people overhear others talking about topics of interest. In those groups people begin to behave in ways that advance agendas and build support for the mobilization of items of personal or mutual self–interest. Some people may want to form an interest group on a topic; some may want to influence the way the conference is being conducted; others may want to improve their reputation, power and social standing; others may want to find people to collaborate with in future work. Social forces converge like crashing waves as coalitions shift.

Later, some groups decide to move into a more intense interaction. This may be as short–term as simply planning to eat a meal together or as complex and long–term as planning to embark on a collaborative research project. When people make these arrangements they commit to a plan, and the group of people who thus commit negotiate roles which determine acceptable behaviors. For example, one person may drive to the restaurant, or
one person may host a planning meeting. People committing to these roles will be interacting in ways different from the ways in which they interacted when selection or mobilization were the dominant activities.

These interactions are all intermingled throughout the conference; we separate them artificially and for a purpose, but they are never actually so. Even in short conversations interactions of all three types, and of mixed types, may be present:

“What time is best to meet at the restaurant?” (selection: coordinating activities)

“I suggest we to find a place where we can get a private room so that our discussion is not interrupted.” (mobilization: influencing choices)

“I’ll drive to the restaurant if you navigate.” (commitment: taking on roles)

“Who in the group has a car?” (selection and commitment)

“Why don’t we ask my colleague to join us? He’ll have something interesting to say on the topic.” (selection and mobilization)

One problem with physical metaphors such as “arena” is that the visualization that naturally arises from them causes ambiguity to shut down and boundaries to appear. It is difficult to think of an interaction as an arena (which I picture as a Roman coliseum) if it is simultaneously a council (which I
picture as a parliament in session). The use of “interface” does not translate well into the world of software design; all I can see when I read that is a computer screen full of widgets. I find it easier to think of selection, mobilization and commitment processes as forces influencing how an interaction plays out. These can mix and combine easily. This is why I prefer to use White’s terms for the interactions themselves and put aside his terms for the “disciplines” in which these take place.

Strands one and two together

The reader may have begun to notice a pattern here. White’s three types of interaction match up with the three aspects of identity described above, thus.

The selection process draws on categorical aspects of identity based on characteristics. Because the focus in selection is on the identities being selected, coalitions and relationships among selected and/or selecting identities are downplayed and the properties of the individual identities are prominent.

The mobilization process draws on relational aspects of identity based on memberships. The building of coalitions and movements, unlike selection, requires the creation of connections.

The commitment process draws on positional aspects of identity based on placement. The focus in commitment is on sustaining overall production, and for this focus the perpetuation and “reincarnation of ancestors” is key.

The third strand: Cynefin boundaries

And here we add the final strand to the braid. White’s three interaction processes map nicely onto the Cynefin framework (Kurtz and Snowden, 2003).

For those unfamiliar with this framework a brief introduction will be necessary. The framework postulates five domains of decision making and sense–making in varying conditions (Figure 1).

Figure 1: Cynefin framework, domain form.

Note that these domains pertain to aspects of and perspectives on situations rather than to situations as a whole, which are rarely so
easily pigeonholed. (To avoid such an unwieldy phrase, I will talk about conditions rather than situations.)

The known domain describes conditions of simple, observable and predictable cause–and–effect relationships in which tried–and–true approaches lead to reliable outcomes. An example of a known condition might be a person looking up a term in a dictionary (when that person knows the language, and when the person knows what a dictionary is, and when that person can read, and when the dictionary is of the standard kind, and so on).

The knowable domain describes conditions of complicated relationships in which cause and effect are predictably connected, though ascertaining those connections requires effort: they are not known but can be known. An example of a knowable condition might be a person looking up a term in a dictionary in another language.

The complex domain describes conditions of interconnected webs and patterns of cause and effect that include the observer and cannot be reliably predicted, though the patterns that emerge are often enlightening — not as to prediction but as to the nature of the system and its interconnections. An example of a complex condition might be a visitor asking natives for the meaning of a term when they don’t know the local language and are new to the area and untrusted (or perhaps seen as an opportunity).

The chaotic domain describes conditions of internal relationships, causes and patterns that are not available to consideration and not amenable to any sort of control. An example of a chaotic condition might be a person trying to find out the meanings of words by giving typewriters to chimpanzees and reading what they type.

The domain of disorder describes conditions in which it is unclear which of the four other domains best describe the conditions at hand. An example of a condition of disorder might be a person trying to communicate with an alien creature whose very mode of existence is unknown.

In order to bring the Cynefin framework into the braid I also need to mention its dimensional form (Figure 2), which considers continuous rather than discrete variation in these conditions.

Figure 2: Cynefin framework, dimensional form.

In this form the strength of central connections is compared with the strength of constituent connections. Using de Landa’s (1997) terms hierarchy grows from left to right, and meshwork
grows from bottom to top.

Bringing in the third strand

The metaphor that best fits these interactions is that of a mixture boiling and condensing as “the formation sifts itself apart and together into new identities.” At times of maximum chance and accident, interactions are loosely coupled and maximally flexible, and the region acts as a nursery for pattern emergence. Some fads and fashions proceed in a manner that is mildly amusing, if useless; but others rapidly reach levels of hysteria that have unforeseen effects. Stock market bubbles and pyramid schemes are examples of such complex–chaotic boundary patterns.

Another example of selection processes might be associations between customers of a store who talk in the aisles and give each other advice, but rarely form longer–lasting connections — though when they do, it can be significant (to customers and to the store). Central bodies tend to be nervous about cultivating such constituent connections. In fact, how welcoming a central–body group (of any kind) behaves in response to the forming of constituent connections is a good gauge of how confident it feels about its
product. One example that comes to mind is the Mercedes–Benz owner forum, considered a model customer forum in the retail world. Not all product vendors encourage their customers to talk this freely. To think about this I tried a little thought experiment. I looked up “X owners” where X was the name of every automobile brand I could think of. The pattern I saw was that the more expensive the car, the more likely I was to find an officially sanctioned forum on which owners can discuss the car together. Typing in the “owners” phrase for most of the less expensive cars seemed to lead to one of two things: an unofficial site (with large disclaimers on it) or a
one–to–many information–only site.

Mobilization processes operate across the complex–knowable boundary. The metaphor that best fits these interactions is an ecology in which complex emergent patterns stabilize and repeat, at least for a time. In a biological ecology there are often predictable patterns of succession, as during
recovery of a clearing created by the fall of a large tree, or during the desertification process; but these patterns are not always reliable because they depend on many complex interactions being in place. For example, there is now some evidence that global warming is behind the growth of a fungal epidemic responsible for the extinction of dozens of frog species in Central and South America (though it appears that this is only one of the factors involved). In human societies, the complex–knowable boundary is the primary source of
productive collaboration, in which new patterns of thought and meaning emerge and move into stable use as they prove valuable.

During mobilization, hierarchies are the things that form and dissolve, creating or destroying central linkages as they do. An example might be that when an informal internet discussion group creates a “newbie guide” or FAQ certain aspects of “the way things are” become codified into
central control over what is said thereafter. Mobilization of different theories of truth may produce competing central forces, and the tension created may endure or may be resolved by one side winning out or by one group taking its version of the truth elsewhere. Once in a while people manage to present multiple viewpoints as a complex truth, but this is difficult and even when accomplished may shift with changing membership or context.

Commitment processes operate across the knowable–known boundary. The metaphor that best fits these interactions is a machine in which the parts mesh perfectly together, sometimes pausing for repair (or self–repair) but always returning to lock–step operation. Anyone who has returned home as an adult and regressed to behaviors they thought long abandoned can attest to the intermeshing role-based expectations of family
commitment.

When commitment is dominant, central control is constant because the group’s working operation must remain in good order. The things that form and dissolve in these interactions are connections among constituent elements. For example, say two assembly line employees are participating in a shared whining session about the difficulties of factory work. While doing so they stumble on the fact that the handover of products between their two stations could be improved by a new way of handling the product between them. They
form a linkage based on this understanding and test their idea without telling anyone (because management might not approve). When they have tested their improvement fully, they feel confident enough to communicate this to the plant management. The proven improvement is incorporated into standard procedure, and their temporary constituent bond is no longer needed. Of course the best factories would encourage the creation of such bonds at all times; but to leave
such improvements at the constituent-linkage level and not transition them to the central–hierarchy level of standard procedure would place too much reliance on particular individuals, harming the future health of the enterprise.

Why is there no named type of interaction across the known–chaos border? This is because movement in this area represents a pathological pattern outside the sphere of normal human interactions. People naturally form constituent connections all the time, so in a sense, as they say, “hope rises.” Dictators attempt to move the situation to the extreme bottom–right corner where they have absolute control and no other connections exist. Loyalty tests and other mind games are meant to sever nascent
connections among the subjugated masses, especially those given subordinate power. However, keeping up such an unnatural situation requires a huge influx of energy, so these situations eventually implode through their own fragility. Chaos can temporarily result, but rarely does a chaotic state persist in the absence of the dictator. When there are good reasons for drastic order to be imposed — during a natural disaster, for example — the pattern will not stay in the area but will rapidly zoom upward into selection and mobilization as people form new constituent connections. All non–pathological human interactions involve meshwork in one way or another: to be human is to be connected.

The full braid

Bringing this all together, we can describe what I call an “identity interaction braid” with three concise statements (notice the three: hence “braid” has a double meaning):

Selection of categorical aspects of identity based on characteristic–based evaluation of safety operates across the chaotic/complex boundary.

Mobilization of relational aspects of identity based on membership–based evaluation of importance operates across the complex/knowableboundary.

Commitment of positional aspects of identity based on placement–based evaluation of utility operates across the knowable/known boundary.

More connections

As an aside, here are two more serendipitous connections to the braid. First, Degenne and Forsé (1999) provide a model of social circles in which people can belong to a group because they know or otherwise are connected to people in it (cohesion); because they identify with something about it (identity); and/or because they fill a role in it (complementary roles). These distinctions match up with types of interaction I have outlined here: cohesion with mobilization, identity with selection, and complementary roles with commitment. (Note that Degenne and Forsé’s naming of selection–interaction circles as simply “identity” provides further evidence that Western thinkers tend to privilege categorical aspects of identity.)

Here is another connection from a completely different source. The many functions of the Roman house in antiquity have been well studied and discussed. Briefly, in the Roman domus of the well–to–do (which housed as many as dozens of family members and slaves) different types of identity interaction were to some extent conducted in separate physical locations. Says Hales (2003):

[T]he Roman domus was simultaneously home, place of entertainment, business office, and lobbying platform. The
paterfamilias received his clientes here [in the atrium] in the morning for the daily salutatio to distribute gifts, delegate errands and tasks, and demand political favours. In the evening, the paterfamilias did not frequent the tabernae, the haunt of the morally and economically bankrupt, but instead entertained his amici (friends and associates) in his own tricilinium.

The atrium was predominated by selection, though some mobilization (the demanding of political favors) also took place there. However, it appears that most of the serious mobilizations took place in more private places (to place a barrier between selection and mobilization) such as the study (tablinium) and other unnamed reception rooms less public than the atrium. Sheldon’s (2008) description of the atrium as “a nexus point from where callers to the house could be directed according to status” points to such a barrier between selection and mobilization. Sheldon also describes the semi–private reception rooms in a clear reference to the prestige valuations of mobilization:

As a rule, the higher the status of the house, the more reception rooms it possessed. These rooms were used in a private capacity for the entertainment of guests. However, even they were used to make statements of social status, employing visual language the visitors were familiar with. It was common to draw attention to particular features visible in the peristyle from the nearby triclinium, by using features of public architecture to frame the view, as in the case of the House of Menander in Pompeii.

The triclinium and small bedrooms (cubicula), by contrast with the atrium and reception rooms, housed commitment interactions. In these sacred places people filled the highly scripted roles of family member, friend, associate, and slave.

Using the braid to consider software design

Where this braid of ideas is particularly useful is in generating recommendations for the design of purposeful human activity that incorporates one or more of these types of interaction. Some of my observations and opinions made while thinking about these distinctions — by no means complete or proven — appear below. As I stated at the outset, I submit these not as facts but as food for thought.

Groups, enemies, and interactions

Shirky’s 2003 paper “A group is its own worst enemy” is a thoughtful look at how people interact over the Internet. He raises three ways in which “a group is its own worst enemy.” He also lists three things people need to accept about building social software and four things to design for. Looking at Shirky’s insights from the perspective of the identity braid, “wearing the tool” as it were, I can respond to his points.

First, Shirky describes three ways in which a group is its own worst enemy. People break off into social talk, vilify external enemies, and participate in religious veneration of central ideas and personalities. (Actually Shirky calls social talk “sex talk” for “pairing off” but I’d like to expand that to consider all sorts of not–obviously–useful social talk.)

In selection interactions, social talk is acceptable because there is no common goal to detract from. Neither vilification nor veneration is possible since there is nothing “outside” the group. Selection by definition can be done by anyone (but selection does not sift all into relevance).

In mobilization interactions social talk is complex. It may distract from the building of connections, but it also may build connections where common interests are uncovered. In mobilization lesser forms of both vilification and veneration may be useful in building coalitions, though a case can be made that these extremes are never useful.

In commitment interactions all three issues are real problems, because all three activities distract people from committing to roles and pursuing common goals.

It is interesting to consider that the origin of these three worst–enemy reasons was (according to Shirky) the writings of a psychologist who commented on why people in his group therapy session derailed his attempts to help them. My interpretation of this is that perhaps the therapist saw interactions within the group as consisting mainly of commitment to a shared goal, whereas the group participants saw the interactions they were participating in as more based on selection and mobilization. Problems from one
perspective might be solutions from another.

Next Shirky describes three things that must be accepted about social software. The first is that it is impossible to separate social and technical issues (i.e., the social affects the technical and the technical affects the social). I’d say that issue is relevant to all types of interaction (though later I will talk more about how supporting each type of interaction differs).

Shirky’s next two “things to accept” are related: members are different than users (i.e., some people do more than others), and the core group (people who do more) have more leverage than other users and can “trump individual rights” in some situations.

Similar observations have been made by others, for example Sawyer (2007):

[I]n 1969, a widely cited National Science Foundation study of five hundred innovations found that four out of five of them originated in user suggestions or were actually invented by the users. In 1981, another study by Eric von Hippel, an MIT professor of management, found similar percentages across industries: Users came up with 81 percent of the innovations in scientific instruments, 60 percent in process machinery. Between 10 and 40 percent of all users modify the products they buy. These are the so–called “lead users,” and their ideas often filter throughout the collaborative web.

Any successful social software (open source or not) has onion–like layers. I’ve observed this phenomenon in my own work with software (social and not, open source and not). I have classed users (not developers) thus:

The great majority of users simply use the software as it has been built. These “general users” don’t look into the nooks and crannies of the software, don’t use complex features, and rarely contribute anything to the community except perhaps a comment or two.

A smaller group of users are “power users” who explore most of the program and learn its quirks. They usually contribute elements to the community, like tutorials, advice, examples, and bug reports.

The smallest group of users are what I like to call “builders.” Builders not only use the program but improve it — when it is possible. When there is an opportunity to create elements the program uses (templates, scripts, macros, objects) they build their own and usually distribute them widely. They also tend to converse with the project developers often, report many bugs and request many features.

And of course software developers form a fourth group. In an open source project the line between builder and developer may be blurry (more on that later).

My user-classes are like Shirky’s “users” and “members” except that I separate “members” into two groups (power users and builders). Whichever set of distinctions you like can be mapped onto the interaction types in the braid.

General or casual users interact with the software in a selection interaction; it works for them or it doesn’t.

Power users tend to move from selection to mobilization as they gain “power” in the user community, thus ability to change the software by leveraging their prestige and influence.

Builders have the potential to cross the barrier between mobilization and commitment, actually becoming part of the team that builds the software, if that is permitted. Whether they actually write source code is to some extent beside the point, since most software — especially most social software — is not just source code.

Finally, Shirky describes four “things to design for” when building social software: “handles” that identify users so others can track their contributions over time; a reputation system; barriers to participation; and a way to spare the group from scale (keeping the many–to–many interaction to what people can handle). To begin, barriers to participation to separate types of interaction are indeed important (as expanded on below). Considering each interaction type:

When selection interactions are predominant, handles and reputation reporting may distract people from the actions of comparison and filtering. During selection people need to know characteristics more than connections. An example is the detailed personality profiles on some dating sites, which list many characteristics of individuals but little or nothing about their history using the site. Sparing groups from scale is counter–productive in selection; the more the better, as long as there are adequate measures for filtering and sorting.

When mobilization interactions are predominant, handles and reputation reporting are critical. They are the currency of mobilization. Sparing a group from scale is of intermediate importance, because subgroups tend to form naturally when scale becomes a factor (unless it is very difficult).

When commitment interactions are predominant, handles and reputations are unimportant because those were used to gain entry in the first place. Anyone who is “in the onion” doesn’t need those things anymore. However, saving the group from scale is a matter of life and death (of the group) when people are following predefined roles.

Stigmergy and identity interaction

Stigmergy, or the creation of large collaborative structures through the accumulation of many small uncoordinated contributions of things left behind, is widespread in nature and in human endeavor. Many of the collective successes of the Web have been stigmergic in nature. How does the idea of stigmergy connect with this typology of interactions? Does stigmergy require a particular type of interaction? My observation is that stigmergy
takes place in all types of interaction but takes different forms in each. The things left behind in each instance differ in their breadth of interchange: who uses them and to whom they make sense.

Contributions that result from selection interactions, such as Google page rankings and product ratings, are of the widest possible usage.

Contributions that result from mobilization interactions, such as Wikipedia pages, blog posts and discussion posts, are of intermediate usage.

Contributions that result from commitment interactions, such as code comments and to–do list items, make sense and matter only to those in relatively small groups.

When stigmergy takes place between rather than within types of interaction, the things left behind tend to grow in size. When something moves from commitment to selection, the thing is usually larger than if it stayed within commitment interactions or moved into mobilization. For example, a software development group might make several fine–grained comments on code changes per day, release incremental software versions to beta testers weekly, and release major versions to the public every few months. This works in
both directions. When a researcher publishes a paper about patterns of Web linkages, she might package many small selection–interaction stigmergies into coarser clumps of mobilization discourse. Mechanisms to support such clustering are embedded in the software we use every day: totals in spreadsheets, summaries in documents, 10–minute presentations that summarize years of work, and so on.

Surveying the field of social software

In this section I will use the braid framework to consider social software as supporting these three types of identity interaction. This is not an exhaustive survey or even a particularly well informed one. To write it, I just thought about all the software I’ve used and seen and heard about in relation to the braid to see what the result might be.

Software for interactions of any type

The most basic communication software — e–mail, discussion forums, chat, wikis, simple Web pages — can be and is used to support interaction of any type, and of intermingling types. No one has yet invented a solution that works better in flexibly responding to the needs of all interactions among identities than these multi–purpose tools. To give a simple example of e–mail use to support each type of interaction:

The frequent fads in which people send lists to friends (25 answers to questions about me, 25 things I like) are selection activities: expressions of characteristics–based identity.

Many charities, especially those for whom political advocacy is part of their mandate, conduct some of their activities through e–mail lists of concerned members. On responding to such an appeal (to send a letter or a Congressperson, for example), the member is asked to spread the word (i.e., increase the mobilization) on the issue. Family and friends use e–mail in the same way, to influence opinions and choices.

Work teams and families use e–mail to negotiate, commit to and reinforce roles and responsibilities related to pursuing common goals.

E–mail works for all of these things both because it is familiar and because it is a blank slate on which many configurations can be overlaid. Email works well on a one–to–one basis, but it also works on a one–to–many basis. Every time someone creates a carbon–copy list they have created a temporary coalescence of identities. For example, when I send an e–mail with family photos to my parents and siblings, I carefully go down the list of siblings in birth order. Even though my e–mail software gives me the ability to create a permanent list in my address book so that I can do this quickly, I like to build the list myself, as a sort of comforting ritual of connection and role reinforcement. I can easily overlay this interaction of committment onto open-ended software, but I might
not be able to do so if the software was more closed.

Even though these simple means of communication are flexible, they all hit walls when complexity rises. Anyone who has tried to schedule a meeting with ten people over e–mail has seen carbon copies explode into a mess. The tradeoff for maximum flexibility is minimum scope for intensive work.

Software for selection interactions

It is difficult to find any selection–only social exchanges on the Web. Perhaps it is difficult to find these anywhere except in temporary or artificial circumstances. I can only think of two online situations that match the characteristics of pure selection well. The first is Match.com and other dating sites, where people evaluate others primarily according to acceptability, and
selection is the primary activity taking place. Certainly people are attempting to promote themselves on Match.com; but there is no way of amassing prestige or creating mobilizations, because that is not the point of the service, and both mobilization and (sometimes) commitment interactions take place elsewhere after the initial “match” is made.

The second selection–only example that comes to mind is the sorting that takes place on simple Web–catalog sites where users are allowed to rate products (for acceptability) but where user identities are not remembered or shown. Here no accumulation of prestige is possible because users can only connect through the simplest of means.

Much more common than the selection–dominant interaction is the situation where selection co–occurs with an equally strong mobilization component. This covers most of the “social networking sites” such as Facebook, LinkedIn, Flickr and others. Many of the buying–and–selling sites on the Web have adopted this mixed character, including the review system at amazon.com, eBay, epinions.com, and the Web sites of many small catalogs. In all of these examples there is an essential communication between people looking for something (and assessing
acceptability) and people promoting something (and building prestige). To some extent vendors have bowed to the inevitable: whenever users are able to repeat their interactions with a site and make those repetitions visible to others, elements of mobilization tend to creep in. Some sites tolerate or even encourage
mobilization–creep more than others. Amazon.com clearly provides greater avenues for product advocacy and reputation building than does Barnes & Noble; there the architecture keeps the mix closer to pure selection. Giving scope to mobilization brings both the benefit of free reviews and the cost of policing a complex ecology of conflicting motivations.

These are some recommendations for software that supports selection interactions:

Selection–support software should enable the quick and easy exchange of information among identities without the need for memberships or other commitments. Fast and fluid pattern formation and dissolution provides an engine for pattern creation, so all information must be open and easily browsed without signing up or forming any sort of commitment.

Selection–support software should provide a common currency for exchange which is readily apparent to all without initiation or expertise. Jargon should be minimized, and products and people should be described in simple terms.

Selection–support software should provide a means of quick search and comparison of items. This allows purity valuations to be efficient and accurate. Hierarchical categories, ratings, keywords, and thumbnail images give people a quick means of entering into rapid comparison among competing items.

A case of violating these rules can be found in the recent changes at amazon.com, which has made a transition over the past several years from vendor to marketplace. Of late I find myself increasingly frustrated with amazon (which had been a mainstay) because of the proliferation of non–amazon vendors and the lack of obvious difference between them and amazon.com itself. Searching for a product used to return one result, but now it may return 10 entries for the same product, all sold by different vendors; and it is difficult to differentiate among them. This violates the third point above (provide means of quickly comparing valuations) and hampers the interaction of identities (myself,
amazon.com, and third–party vendors) in the space. In a sense amazon.com has fostered the mobilization of third–party vendors at the expense of my selection interactions with amazon.com itself.

Software for mobilization interactions

Software for situations in which mobilization interactions are dominant tend to be systems where the most important activity is talking. Blogs, Slashdot, Ning, CrowdVine, CollectiveX, Groupsite, discussion forums, and prediction markets are all examples of primarily–mobilization social Web phenomena. In all of these a means of identifying people and keeping track of prestige (reputation, power) is central. The karma voting system on Slashdot
is a strong supporter of reputation. Blog post comments, ratings and links form an informal method of reputation building. People come to be known in these communities based largely on their ability to mobilize resources to support goals they want to succeed.

When mobilization is dominant, commitment “pockets” often form where small groups pursue concentrated role–based interactions, perhaps for only a short time. Mobilization–support software that anticipates these pockets, supports transitions to and from them, and provides safety and
privacy for their uninterrupted work, improve the working of the entire system. I am reminded of the way in which some massively multiplayer environments, especially those where players build part of the environment, provide separate spaces (from “rooms” to “realms”) where smaller committed groups can concentrate on common goals. I’d like to see more support for this sort of pocketing on other social sites. For example I think Ning and other “create your own group site” sites may be missing an
opportunity by not providing much support for these role–based pockets to take place. Ning and similar others provide many opportunities for the individual to connect with the group, and for dyadic connections to form, but they offer little support for the type of collective output that committed groups tend to produce such as detailed FAQs, guides, and so on.

These are some recommendations for software that supports mobilization interactions:

Mobilization-support software should make it easy for coalescences (of many entities, including people, identities, technologies, data, opinions, etc) to form, dissolve, split, merge and transform, possibly with ritual elements surrounding these changes.

Mobilization–support software should provide means for social translucence (see Erickson and Kellogg, 2000) so people can use their awareness of the presence and actions of others to inform their own decisions.

Coalescence and campaigning are intertwined: trying to achieve one usually requires enabling the other. Because of this it is often hard to say which is most important, or even which is the goal of some aspects of software. For example, idealist.org links volunteers with needs, helps people form mutual–support groups, and — at the same time — gives projects, organizations and groups who need help a place to mobilize support for their causes. Similarly, changemakers.net brings together people with ideas to
pursue both funding from donors and collaboration with people who care about the same things.

The third recommendation, social translucence, is the area where I think social software for mobilization could improve the most. Erickson and Kellogg (2000) define social translucence as having three essential qualities: visibility, awareness, and accountability. My experience with social software has been that it does all of these things in a simple way, but there is something missing — context possibly, or depth. When people meet in person
such a wealth of information passes between them, and online connection reduces that wealth to a tiny trickle. I’m getting tired of looking at “profile” pages and seeing nothing but lists of posts, bobble–head pictures, and tired blurbs that were obviously pasted in from somewhere else. My feeling is that we are heading for a transformation in online social translucence, since I’ve seen many great ideas to improve it (including those of Erickson and Kellogg, or just take a look at any of the compendia of visualization ideas online such as the one at visualcomplexity.com). Few of these ideas are yet in wide use, but I think they will be, and soon.

Software for commitment interactions

Software for interactions based on commitment tends to be for people who are building or doing something. When such interactions are very simple and roles are few and well defined, software is an excellent support. An example is software that supports the mechanics of buying and selling over the
Internet (not selection but the actual purchase). Retail interactions related to putting items in a “shopping cart” and “checking out” are largely commitment interactions, with vendors and customers taking on scripted roles. Departures from these roles are danger signs for either party. When customers don’t find secure connections for purchasing, or when they discover that inventory statements are out of date, they become wary. Similarly, vendors watch for non–scripted customer behavior and respond accordingly, for example closing out checkout sessions where users have left the
computer idle for hours and then returned.

However, whenever you leave behind the case of simple (usually dyadic) commitments, software support gets much more difficult. Unlike selection and mobilization, the intricate dance of role–based commitment is so complex that few people can navigate it successfully, let alone software. Anyone who has been on either end of the “private e–mail blabbed to giant mailing list” faux pas, or has had the queasy feeling of being “friended” knows that.

These are some recommendations for software that supports complex commitment interactions:

Commitment–support software should provide a mythology in which the arrangement of positions can be communicated in a way that is memorable and compelling.

Commitment–support software should provide a means of role handover which makes the taking on and releasing of conformed behaviors (and the process of conforming) as easy as possible.

Commitment–support software should provide means for handling and correcting deviations from appropriate role behavior so that the group is efficient in its progress toward its goal.

This is the only one of the three types of interaction in which these recommendations are far from reality. I can’t find any software that successfully supports these things, though some have tried. When I worked at IBM I used the Lotus Notes TeamRoom product often. It tried to support some of these commitment processes, but most of the attempts didn’t take. When you first set up a TeamRoom you were supposed to write up a purpose for the team, and people were supposed to be given named roles and responsibilities, and there were some other proddings towards role handover and such things. But as I recall, those of us who were actually using TeamRooms just tended to dump information into them and use them as shared file repositories and ignore all the social proddings. I think the people who designed TeamRoom did know something about how people work together in teams, because none of their advice was wrong or misguided. It was more like the software just couldn’t get to where we were. It was like that ridiculous talking paper clip in Microsoft Word — it was in the way. People put in funny things for their roles and goals, like “world changer” or “get my desk clean.” It was sort of like having software to manage a dinner party: can’t be done. I doubt
anyone will ever build such software — or if they do, it will probably mean more about people than it means about software.

Groove and BaseCamp, and open source equivalents such as dotProject, eGroupWare, and phpGroupWare, are group support tools; but none of these try to help with the social issues of commitment. They focus on project management, file sharing, and scheduling: that is, helping people manage the non–commitment aspects of collaborative work (no mythology here). These applications are as useful for an individual working alone as they are for a group, which means that there is nothing commitment–specific or role–specific to them. They are individual tools “fattened up”
for the group. Really most of the tools groups use are either fattened–up versions of individual tools (notes in documents, comments in version control systems, wikis, shared to–do lists) or ways to talk (discussions, blogs, chat). This is true whether the tools are embedded in “groupware” or not.

One of the things I’ve found most useful in role–committed work has been software that supports talking and building at the same time. Some of my most productive moments in role–based teams have been in sessions like this. The something–done has almost always been something any individual could do alone, such as editing a document, building a presentation or writing code. Mainly this has been done using screen–sharing software that shows everyone what one person has on their screen. I’ve also been in sessions where everyone can edit something at once, but I haven’t found them spectacularly better than having one person edit and everyone else talk and watch. When everyone can make changes the conversation tends to end up wasting a lot of time on “no, you go ahead” negotiations. Having one person do the editing sets up a (sometimes temporary, sometimes permanent) role structure that obviates the need for ongoing negotiation.

There are two ways to support complex commitment interactions: either support them entirely, as TeamRoom tried to do, or fit support into the spaces between role–based negotiations. I don’t think the first approach can work, at least not yet and at least not based on the computing paradigms we have now. But the second can work. As Khahlil Gibran said, “Let there be spaces in
your togetherness, / And let the winds of the heavens dance between you.” In a sense the to–do lists, project milestones and shared calendars of groupware are the winds of the heavens (stuff getting done) that dance between the deeper tasks of people finding ways to work together. The main requirement for building winds of heavens is that they be modular building blocks, self–contained and with clear boundaries between instrumental and social, so that they can fit into the spaces unique to every group.

To belabor this point just a bit more: I think one reason it’s so hard to write software to support complex role–based interactions is that they are too important to talk about. Everyone may know that a certain person is the nay–sayer of the group, or the “child” who is expected to brainstorm ridiculous ideas, or the person who pays attention to which rules have been broken lately. But bringing those tacit understandings out into the open might break them rather than helping them form. The only possibility I can see for improving this state of affairs (if it needs improving) is in the use of narrative. Stories have been used for many generations to negotiate roles and role–based behaviors: they explain the shape of the world and our places in it; they give form and meaning to roles such as trickster, leader and worker; they prescribe and correct behavior. If I ever tried to design software that would work well for commitment interactions, I’d build it on a narrative foundation.

Software that covers all types of interaction

Software that covers all three types of interaction tends to be created for communities where something is being built or achieved and that thing is being offered to the public for use within the same environment. Some examples are SourceForge, Wikipedia, and Moodle. In these situations there must be elements of the system that work for each interaction type, and perhaps even more critically, there must be rituals that control and
guide movement between types.

Let’s take SourceForge as an example of such an all–encompassing site. If I as a member of the general public go to the site, I’ll probably click on “Find Software.” I see the simple hierarchy of available software and ignore the “projects” and “community” parts, since I don’t intend to get involved (at the mobilization or commitment level). I want to select something I can use. Let’s say I’m looking for a game to play with my kids. I click on “Games/entertainment” and get a list of game categories, as I had expected. How about simulation games? I click that and get indications of popularity, activity, and rankings. Nice selection criteria. Little screenshots help me choose something quickly: no jargon. Here’s one near the top. I click on the thumbnail and look at some more, bigger screenshots. Looks fun. I read the two–sentence blurb. A quick check that the manual has more than two pages in it, and I’m ready to download.

Now let’s say I come back to SourceForge as a person who has recently joined an open source project. Say it’s a project to build a new and better e–mail client. Say I have agreed to provide feedback on designs and prototypes, but I’m not ready to commit to being in the core group. What I’d really like to do is make a case for doing something about the context–destroying quality of simple text communication. I’m a historian, say, and I know that symbols and other extensions to text have been used throughout history to smooth over some of the misunderstandings plain text
carries. For example, when people used to write many physical letters, the style of the text carried meaning in addition to the words. Were there tear marks, blood stains, ink blots, smudges? Was the writing precise or sloppy? What was the quality of the paper? The ink? Did the writer “cross write” (write a second layer of text perpendicularly over the first)? Was this done to save money, or to keep the letter private, or to send a tacit message that the
receiver was within the sender’s social circle, or all three? How could e–mail do more to incorporate such subtle cues than it does now, and how could the current project improve on current e–mail use?

Now ideally I want to start a discussion, generate some support for my idea, and ultimately influence what gets built. I would like to gravitate right away to the forums and raise the issue strongly, but common sense tells me that I’d better put in some “homework” and add a document to the wiki with references to sources that support my arguments before I just start pontificating. I’m also going to have to build my reputation, both as a project contributor and as an authority in this area, so I make sure my profile is well populated, both with static information and with relevant history of performance. All of these activities require the mobilization–support portions of SourceForge.

Finally, let’s consider the use of SourceForge by a committed member playing a defined role. Members who take on roles are usually fully aware of (or are made aware of) the privileges, responsibilities and authorities that come with the role they have taken on. For example, when a member is given the responsibility of being the main FAQ editor, they are responsible for finding
often–asked questions and transitioning them to the solidified document. A member given permission to post news items is responsible for maintaining the public face of the project. Groups usually codify these elements of privilege, responsibility and authority in common documents such as licenses, which are essentially constitutions for behavior (both within the group and within the wider set of roles taken on by producers and users of software). SourceForge places the license prominently on the main page of a project site.

Let’s say I’ve been working in my spare time on a particular project for the last few years. I know the five other people in the core group pretty well, and we’re clear on what everyone is doing. I don’t write code, but I’ve turned out to be the best at writing documentation, so I’m expected to be in charge of that section of the site. Nobody else in the group has the whole help system in their mind the way I do, and we all know that. The other people do make changes to the documentation, but I have the system set up so that I find out about each change and can double–check it. I don’t like writing the news articles, but I do make screenshots
when they ask me to, because I make the best screenshots (and we all know that too). I know how to get into the version control system and update my current copy of the software, and I read the comments there to find out what’s going on — but I don’t mess with the code. That’s not where I fit into the scheme of things.

What may be even more important than supporting each type of interaction in such all–encompassing sites is how they support transitions between different interaction types. In some ways times of transition are the most dangerous times since they have the potential to upset the interactions surrounding them.

Transitions between selection and mobilization

Transition from selection to mobilization takes place when people join SourceForge projects. On SourceForge, the project administrator must add members by hand, thus ensuring a moderation barrier. Permissions are fine–grained in order to divide role–based behavior (editing documentation, building releases, uploading screenshots, editing source code) from the more flexible
behaviors available to mobilization–type discourse (posting questions, making suggestions, responding to feedback requests).

Transition from mobilization to selection takes place on SourceForge when an open source software package becomes available to the public. The selection process requires purity information whereas the mobilization process requires prestige information. So software made public is annotated with content
information for comparison and selection (function categories, screenshots, brief explanations, major version numbers), as well as context for mobilization (minor version numbers, change lists, technical notes, contributor lists). It is important that information moving from mobilization to selection be made useful to the selection process, but it may be more important that the information be readily taken up into mobilization again (and not be “lost” in selection) so that it can contribute to the dynamics of collaboration there. For example, statistics on selection activities (project downloads, screenshot views, comments) are easier for developers to interpret
and use if they provide enough (but not too much) useful information about user response.

Transitions between selection and commitment

Transition from selection to commitment is rare, since the mobilization layer of purposeful communication protects committed teams from the scrutiny of selection. FAQs, etiquette guides, wikis and other “read this first” barriers keep people from penetrating role–based teams too easily or quickly. Often “public–facing” roles take on the brunt of this interaction to free up other roles for the concentration they need to pursue the
common task. This is not to say that transitions from selection to commitment are not useful; feedback is critical to production. But if the people working in tightly interlocked roles pay too much attention to wide–ranging selection comparisons, the destabilizing forces of the vortex will threaten the clockwork universe inside.

Transition from commitment to selection is usually temporary and utility–driven. Timing is important to interlocked role–based groups, so it is useful to give such groups tools that help them to enter the selection area quickly and select what is required without getting lost there. (Hence clean statistic views are important.)

Transitions between mobilization and commitment

The movement of people and artifacts from mobilization to commitment is controlled by the presence of conduits that are negotiated, constitutional, or some combination of both. The selective movement of texts from the “talk” pages of Wikipedia articles to their public–facing portions is an example of such a conduit. On SourceForge, forum discussions sometimes lead to the creation of design documents and presentations (sometimes on wikis) that cross over into the more intense, focused environment of role commitment. Histories and member profiles provide indicators that make it easier to recognize when supporting such a transition
(of a person or artifact) is appropriate and where it will not succeed. As with role negotiation much of this action takes place without specialized software support, usually in discussion.

Movement from commitment to mobilization, like that into selection, is a “reaching out” sort of activity. It usually involves broadcasting or polling in order to gather information needed by people in defined roles. An example might be when a core group creates a new discussion forum to gather ideas from the wider member group about difficult decisions. Such outreaches may
also be used to scout out solutions and to recruit people to fill vacant roles.

Conclusion: Cathedrals, bazaars and identity
interactions

Of course anyone writing two words about software development is required to address the cathedral–bazaar comparison (Raymond, 2001). I concur with those who say that “cathedral” is a misnomer for what Raymond meant by the word, since actual historical cathedral building was much more complex than the “closed” model he talked about (for a complex view of cathedral building see especially Turnbull, 2000). The kind of closed, structured interaction Raymond was talking about seems to me to fit the commitment model more than any other.

A bazaar would on the face of it seem to be a place in which selection interactions predominate, but Raymond’s responses to criticisms of the original paper make it clear that what he meant by “bazaar” is more like an all–encompassing activity than a selection–only activity. As he explained, he did not mean that concentrated teams could not or should not form in open source development, but rather that their doors should stay at least partly open to other forms of interaction.

My observation is that the most successful open source projects have included elements of all three types of interaction and have managed transitions between interaction types well. The problem with closed source development is not that it consists only of role–based closed teams. The users of many closed source software packages are too active to permit that exclusion — Google “Excel macros” or “Flash tutorials” if you don’t believe me. But the nature of closed source software is such that it sets up very high barriers to transition between types of interaction, especially to and from the interactions of commitment. I remember years ago trying in vain to convince a commercial vendor of a programming platform to fix a bug that was devastating to my project but that did not impact the majority of their users. I selected the platform, but could not mobilize the vendor to commit to a goal they didn’t share (and a role they didn’t want to play). If the software had been open source, if I couldn’t talk other people into fixing the bug (mobilize support for it), I could have “scratched the itch” myself (committed to a role and carried it out). The difference between crossing that barrier being impossible and just difficult is what matters. It is the reason I think closed source development is less powerful in the long run: not because it entails a different type of interaction, but because it isolates interaction types. When Raymond noted that, “Given enough eyeballs, all bugs are shallow,” it’s not the eyeballs alone that matter. They exist in the closed source world too. The difference is that in the open source world eyeballs are connected to mouths and ears and, most critically, hands.

The impetus for this paper was a serendipitous juxtaposition of separate theories and the patterns of thought it created. I’ve got a lot out of playing with this gem of contemplation over the past few years, and I hope this paper has given others something to play with as well.

About the author

Cynthia Kurtz is an independent researcher, writer, and software designer who consults in the field of organizational and community narrative for decision support, conflict resolution, and collective sense–making. Her free online book Working with stories helps people use narrative techniques to benefit their own communities and organizations. Her free open source software Rakontu helps small groups share and work with stories for collective sense–making, decision support and conflict resolution. Cynthia’s original background is in ethology and evolutionary biology.
E–mail: cfkurtz at cfkurtz dot com

Acknowledgements

The work that led to the insights contained in this paper was supported in part by Cognitive Edge and its clients. Thanks to Paul Fernhout for thoughtful criticism, which improved the article tremendously.

Fiona Williams, 2000. “A conceptual chart for CAVA,” Methodologies for researching moral agency, Workshop
Paper, number 16; ESRC Research Group on Care, Values and the Future
of Welfare, University of Leeds, at http://www.leeds.ac.uk/CAVA/papers/paper16fiona.htm, accessed 5 November 2009.