Last year Matt Webb at Interconnected posted On Social Software, which was then picked up by Matt Phillips at drupal, who posted Incentives for online software: the 7 pieces social software must have…. Both Webb and Phillips’s pieces were riffing on Stewart Butterfield’s earlier post on the same subject. The list of attributes as posted at drupal was Identity, Presence, Relationships, Conversations, Groups, Reputation, and Sharing. [Updated 9/30, 19:40 EDT to reflect Matt Webb’s work.]
I just went through the list for this semester’s Social Software class at ITP, and re-aranged it, because the list is too big to be a subset of all social software (very few systems have formal support for Reputation or Relationships, for example), but much too small to be a superset of all interesting features (a potentially infinite list.)
I think there are in fact only two attributes — Groups and Conversations — which are on the ‘necessary and sufficient’ list (though I have expanded the latter to Conversations or Shared Awareness, for reasons described below.) I doubt there are other elements as fundamental as these two, or, put another way, software that supports these two elements is social, even if it supports none of the others. (Wikis actually come quite close to this theoretical minimum, for reasons also discussed below.)
Some of the remaining attributes are “technological signature” questions. These are not about essence so much as characterization — what kind of software is it? What are its core technological capabilities? I have four attributes that fall into this category, having added two to the drupal list: Identity and Roles, Presence, Naming and Addressing, and Valence. I think you can learn important things about any piece of social software by examining these four attributes. There are probably others.
Finally, there are three leftovers from the original seven. These are essentially optional characteristics, which only pertain to a subset of social software and which were, I believe, wrongly included in the original list out of an excitement about recent innovations. The inessential characteristics included on the drupal list are Sharing, Relationships, and Reputation. Others are of course possible: Profiles? FOAF networking? etc.
My version follows.
Essential characteristics:
* Groups
* conversations or Shared Awareness
Technological Signature:
* Identity and Roles
* Presence
* Naming and Addressing
* Valence
* (others?)
Partial List of Optional Characteristics:
* Sharing
* Relationships
* Reputation
* (many others)
Essential CharacteristicsGroups — Does the software support a single group (e.g. a mailing list), or are there sub-groups (e.g. conferences on the WELL or ECHO)? Are the groups sharply delineated (e.g. you are either in or out of the Python group on Orkut) or do they go along a gradient (e.g. your 10 closest friends on Wallop)?
The commonest case is that the group is made up of all users of the software, with no further articulation supported or required by the software.
Conversations or Shared Awareness — How does the system support conversation between the users (e.g. mailing lists, BBSes), or the production of objects that create shared awareness (e.g. pages on a wiki; popular links on del.icio.us.)?
The commonest case is unmoderated back-and-forth conversation accessible to all members of the group.
I think these two characteristics, taken together, are a minimal subset for social software. There has to be a group, or it’s not social, and that group has to have and be aware of some shared product. I emphasize the latter issue because it defines, for me, the difference between del.icio.us and Google. Both services help uncover links pointed to by a number of users, but only del.icio.us makes the users aware of one another’s efforts in doing the pointing. Google, by contrast, reads the aggregate link structure, but doesn’t identify the groups doing the linking.
(Doc Searls and Tim O’Reilly both call Google social software; I am less concerned with proposing an ‘in the club/out of the club’ distinction here than identifying differences between active and latent interaction. The difference between del.icio.us and Google in shared awareness is, for me, thing that makes del.icio.us active social software, and Google latent.)
Technological SignatureIdentity — How are users identified by the system (if at all)? Where does the system do to encourage or require users to identify themselves? Is there formal support for pseudononymous communication (as with Craigslist)? Is there support for linking the user to real details (as with a Friendster profile)?
The commonest case for identity is user-defined handles; the minimal case is no software supported identity at all.
Presence — Does any part of the system allow for real-time communication? Does it provide any read on the user’s presence outside their use of the system (e.g. the Idle or Away messages in Apple’s iChat app)?
Presence is, I think, the human experience of sychrony — real-time apps provide presence, non-real-time apps don’t. (This contention could be falsified by finding edge cases for either half of that proposition, but I can’t think of any.)
Valence — I may need a better word here, but valence describes how many modes of interaction the software is designed around. Email, for instance, is bi-valent — conversation, plus attached files. IM used to be bi-valent in the same way, but the rise of increasingly sophisticated presence (available/idle/away) and customizable messages alongside presence info (“on a conference call”/”listening to Radar Love”) make it tri-valent.
The “enterprise tool” philosophy suggests that multi-valence is a good characteristic — Groove and Sharepoint both try to support as many patterns in a single tool as they can. The “Small Pieces Loosely Joined” pattern, by contrast, suggests that low valence and well defined interfaces is better. del.icio.us is a model of univalence — it’s a list of tagged links — and its RESTian interface is a model of how to make the SPLJ pattern work.
I am unsure if RSS falls in this category, or if it is orthagonal to this list entirely.
The commonest valence seems to be bi-modal — conversation plus file attachment.
Naming or Addressing — A key characteristic of the software is to understand what elements in the system are named (and therefore usually addressable.) If you want to understand the difference between alt.tv.fan.buffy and Bronze:Beta (one of the key questions of the age, surely), understanding that Usenet treats both threads and posts as named entities, while B:B has a single conversation with no threading and no permalinks, goes a long way to explaining the difference. Similarly, much of the difference in conversations between irc and group IM can be understood by understanding that in irc, conversations and users are named, while in IM, only users are.
It’s harder here to make a judgement about what constitutes the commonest case — at a guess, it’s the mailing list/BBS pattern, with named spaces, users, threads, and posts.
Tom Coates makes the case that the rise of posts as addressable entities was a key moment in the transformation of the weblog world; this was like a change from treating old posts as plankton, simply sinking down into the depths of time, vs treating old posts as a coral reef, a growing structure that always supports the thin upper zone of recent posts.
Then there are the attributes that were on the original lists, but aren’t universally applicable.
Partial List of Optional CharacteristicsSharing — I take sharing to be shared content, as separate from conversation. Sharing my music is different than contributing to a conversation or editing a wiki page. Furthermore, sharing by passing URLs is effectively out of band — there are different technical requirements for direct file transfer in chat, for example, but not for pasting in a URL. So while support for sharing is interesting, it isn’t widespread.
Relationships — There are a lot of intersting questions around relationships: Does the system allow or require formal nomination of user relationships (as with social networking services)? Are the relationships transitive (you and I are linked as friends; the Friendster/Orkut pattern) or intransitive (I can call you a friend without requiring a response from you; the LiveJournal/Flikr pattern)? Are the relations named (friend vs. family) or weighted (close, distant)? Does the system allow or require the adoption of formal roles (e.g. Editor, or Moderator)?
However, concern with named relationships seems to stem from the profusion of social networking services. It does not apply to a majority of the world’s social software, and much orecentwork on it falls down the usuall rathole of ‘explicit is good’ (e.g.
Relationship; XFN); hence its inclusion on the optional list.
Reputation — eBay has done us all a disservice, by making reputation look both easy and useful, when it is mostly neither, at least in social spaces. eBay deals in atomic transactions (how much $ for how many Smurfs?) among actors not likely to interact with one another again. Most social situations, by contrast, are home to only fuzzy transactions (karmic calculations of who did whom a favor, or who is one the same team in an argument) by people who interact freely and frequently. In these situations, explicit reputation is less effective than simply letting the participants keep track of one another (Identity, above), and then letting the monkeymind do the bookeeping.
Formal reputation systems exist in very few pieces of social software, and most of the proposals for generalized systems make work on explicitly naming relationships look like models of clarity.
Looking at the list through the lens of the wiki
I think the original list of seven suffers from local excitement about late-model social software, and fantasies of explicit description and managment of human connectedness. My test case for seeing which elements would hold up across a wide domain was wikis. And once you hold the original list up to the wiki form, a lot of holes show up.
For example, Identity appears first on both Stewart and Webb’s lists of attributes. After all, what could be more fundamental than human identity in social software? And the answer, as it turns out, is that group cohesion could be more fundamental. Wikis sometimes offer optional support for identities, but it is rarely enforced (though Ross makes a compelling case around situations where it should be enforced.) So wikis provide a real world example of ways social software can exist and even thrive with no technological support for delcared identity.
In fact, a standard-issue wiki (UseMod, say) allows for group production of shared value without providing any formal support for Identity, Presence, Relationships, Reputation, or Sharing. It is the purest form of minimal expression I’ve found. Even del.icio.us has Identity support.
And therein lies a clue to the genius of the wiki pattern. The wiki, more than any other piece of social software, is built on the idea that you shouldn’t instantiate a pattern in software if the community can build it for itself. People are far more plastic than software, and the patterns a community invents for itself may well make for a better fit than making the software do or not do certain things.
A functioning wiki will often have common patterns of identity, conversation, and reputation. There is a social compact that guides when to sign new pieces of content, and whether to use RealNames. These signed additions amount to an embedded conversational pattern; there is a sense that the community has a core group, known to themselves, who do the wiki gardening and other work related to upkeep.
Thus the list here is really two lists, overlapping as always, between the characteristics the software enables or explicitly supports, the chracteristics any particular group using the software creates for itself. Software can support anonymous participation, but its users can create social expectations of discolsed identity, and enforce that expectation without recourse to code (habitually reversing unsigned changes in a wiki, for example, or ostracizing unidentified posters in conversational spaces.)
I still think the idea of listing these characteristics is useful, but yet again, what started like a crisp delineation of attributes of software requires an examination of he feedback loop between tools and their users.