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 Characteristics
Groups — 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 Signature
Identity — 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 Characteristics
Sharing — 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.
1. Jay Fienberg on September 30, 2004 2:32 PM writes...
I like the way you faceted the list--separating out the technological signature elements sets up a good way to talk about why/how what social software is, is not just software/technology.
Elements like "identity" are implicit in social software in the sense that, e.g., one can identify that some being is acting in/through/on the software, but the software itself may or may not implement any "identity" code.
Also, I think "presence" being part of the technological signature elements should factor into discussions about "intimacy gradient". I think intimacy is tied to presence (i.e., in a space and/or in proximity to others), and one's sense of presence in a social software system may not be explicitly representable in the code.
Permalink to Comment2. Matt Phillips on September 30, 2004 9:12 PM writes...
Clay,
The first thing that caught my attention (other than my name Matt Phillips) is the distinction between "Social Software" and "Communitity Software." In the past I have not made this point as articulately as you have here. BTW: How do you do it? I'm amazed at your ability to articulate your insight! Do you take vitamins? ;-)
Below I address Communities: (Not Wikis as simple social software):
Communities that invite interaction function from primarily two design elements:
•Organic Growth
•Aliveness
It is implied that an interactive community can not be established in isolation. Communities exist to the extent that members interact together and with other communities. It is this relationship of interconnectedness that supports the very rhythm of life, repairing the world around and within. However, I believe membership becomes more coherent, more whole when individuals are encouraged to ‘define’ their identity within the community. This can be accomplished through metadata (criteria); personal, professional, as well as desired attributes. Missing the importance of defining identity in community software is a common oversight that can suffocate the development of social communities. Once identity, such as a personal digital lifestyle, has been collected and organized, the ability to locate members, conversations or products based upon our own created “pivots” establishes what most of us believe to be most true; our personal perception.
Individuals communicate ideas based primarily upon internal perceptions. The ability for members to accurately articulate who they are establishes a sense of perceived commonality. Personal profiles accomplish two very important aspects in the development of community.
1) Members initial interaction within the community starts first with themselves. Who doesn’t like to talk about themselves?
2) Members are able to draw aliveness from the community based upon their own perceptions as articulated within their personal profiles. Clay Shirky states there are two elements social software must have – Groups and Conversations--(the Wiki model).
Social software for Community might include
–Identity, Groups and Conversations--.
Does this make sense? Thoughts?
Matthew Phillips
Permalink to Comment3. Luistxo Fernandez on October 1, 2004 1:10 AM writes...
So, is there any better socialsoftware than a mailing list? A list is a Group with conversations or Shared Awareness...
Some additions by Matthew Phillips do also match with the nature of working mailing lists: Identity, Organic growth, alivenes.
Permalink to Comment4. Tim Mansfield on October 1, 2004 2:31 AM writes...
I know it's not only risky but also somewhat curmudgeonly to suggest that there's a 20 year old academic field (Computer-Supported Cooperative Work) that might have the odd thing to say about Social Software beyond what's posted on the blogs, but I'm going to go right ahead and do so.
While I think your post is bang-on Clay, if you're interested in investigating what that prior field thought might be required to support people acting cooperatively in ear-bleedingly extensive detail, may I suggest a few armchair in front of the fire hours with Fitzpatrick's excellent "The Locales Framework: Understanding and Designing for Wicked Problems" (ISBN: 1402011903 - Kluwer 2003). It's not cheap, but it synthesises a great deal of research into how to design software for cooperation. It isn't pithy or simple to apply, but I think it is deep and applicable.
Full disclosure: Geraldine's an old colleague of mine and I assisted with some of this research in the early stages.
Tim mansfield
Permalink to Comment