“the social behavior of [online] groups is a runtime experience” (Shirky 2005 [2003])

SHIRKY, Clay. 2005 [2003]. A group is its own worst enemy. In: Joel Spolsky (ed.). The best software writing I. New York: Springer-Verlag, pp.183-209.

SOCIAL SOFTWARE (processo tecnicamente mediado de associação)

Let me offer a definition of social software […]: it’s software that supports group interaction. (Shirky 2005:185)

While that definition—software for group interaction—cuts across existing categories, I think it is the right one, because it recognizes the fundamentally social nature of the problem. Groups are a runtime effect. You cannot specify in advance what any given group will do, and so you can’t instantiate in software everything you expect to have happen. (Shirky 2005:186)

Prior to the Internet, the […] [t]here was no technological mediation for group conversations. The closest we got was the conference call, which never really worked right […]. It’s not easy to set up a conference call, but it’s very easy to email five of your friends and say, “Hey, where are we going for pizza?”—so ridiculously easy group forming is quite a new pattern, something technology has never made easy before. (Shirky 2005:185)

We’ve had social software for 40 years at most, dated from the Plato BBS system, and we’ve only had a decade or so of widespread availability, so we’re just finding out what works. We’re still learning how to make these kinds of things. (Shirky 2005:185)

Social software is like that. You can find the same piece of code running in many, many environments. And sometimes it works and sometimes it doesn’t. So there is something supernatural about groups, where having good software alone isn’t enough, because the social behavior of groups is a runtime experience. (Shirky 2005:199)

PSICOLOGIA SOCIAL DE BION

The best explanation I have found for the ways in which this pattern establishes itself, the group is its own worst enemy, comes from a book by W. R. Bion called Experiences in Groups, written in the middle of the last century. (Shirky 2005:187)

SOMOS INDIVÍDUOS SOCIAIS

Every one of us has a kind of rational decision-making mind that allows us to assess what’s going on and make decisions and act on them. And we are all also able to enter viscerally into emotional bonds with other groups of people who transcend the intellectual aspects of the individual. (Shirky 2005:187-8)

the “paradox of groups.” It’s obvious that there are no groups without members. But what’s less obvious is that there are no members without a group— because what would you be a member of? (Shirky 2005:188-9)

SOCIOGÊNESE

So there’s this very complicated moment of a group coming together, where enough individuals, for whatever reason, sort of agree that something worthwhile is happening, and the decision they make at that moment is “This is good and must be protected.” And at that moment, even if it’s subconscious, you start getting group effects. (Shirky 2005:189)

AS 3 FORMAS DE AUTOSABOTAGEM COLETIVA (azaração, oposição e religião)

Bion […] detailed three patterns. […] The first is sex talk […]. […] The topic of sex is always in scope in live human conversations […]. […] The second basic pattern […] is the identification and vilification of external enemies. […] Nothing causes a group to galvanize like an external enemy. So even if someone isn’t really your enemy, identifying them as an enemy can cause a pleasant sense of group cohesion. And groups often gravitate toward members who are the most paranoid and make them leaders, because those are the people who are best at identifying external enemies. […] The third pattern Bion identified is religious veneration—the nomination and worship of a religious icon or a set of religious tenets. […] Groups often have some small set of core tenets, beliefs, or interests that are beyond criticism, because they are the things that hold the group together. Even in groups founded for fairly intellectual discussion, the emotional piece comes out whenever you threaten one of these core beliefs, because when you take on those beliefs, you are not just offering an opinion, you are threatening group cohesion. (Shirky 2005:189-90)

ESTRUTURA PROTEGE O GRUPO (seus fins elevados) DE SI MESMO (seus instintos mais baixos)

Bion has identified this possibility of groups sandbagging their sophisticated goals with these basic urges. And what he finally came to, in analyzing this tension, is that group structure is necessary. (Shirky 2005:190)

Group structure exists to keep a group on target, on track, on message, on charter, to keep a group focused on its own sophisticated goals and away from sliding into these basic patterns. Group structure defends the group from the action of its own members. (Shirky 2005:191)

O CASO COMMUNITREE

What matters is, a group designed this and then was unable, in the context they’d set up, to save it from this attack from within, and that context was partly technical and partly social. The lesson of Communitree is that attack from within is what matters. Communitree wasn’t shut down by people trying to crash the server or flood it from the outside. It was shut down by people logging in and posting, which is what the system was designed to allow. The technological patterns of normal use and attack were so similar at the machine level, there was no way to specify technologically what should and shouldn’t happen. Some of the users wanted the system to continue to exist and to provide a forum for discussion. And other of the users, the high school boys, either didn’t care or were actively inimical. And the system provided no way for the former group to defend itself from the latter. […] This pattern has happened over and over and over again. Someone built the system; they assumed certain user behaviors. The users came on and exhibited different behaviors. And the people running the system discovered to their horror that the technological and social issues could not in fact be decoupled. This story has been written many times. It’s actually frustrating to see how many times it’s been written, because although there’s a wealth of documentation from the field, people starting similar projects often haven’t read these accounts. (Shirky 2005:192-3)

O CASO LAMBAMOO

There’s a great document called “LambdaMOO Takes a New Direction,” which is about the wizards of LambdaMOO, Pavel Curtis’s Xerox PARC experiment in building a MUD7 world. And one day the wizards of LambdaMOO announced, “We’ve gotten this system up and running, and all these interesting social effects are happening. Henceforth we wizards will only be involved in technological issues. We’re not going to get involved in any of that social stuff.” […] And then, I think about 18 months later, the wizards come back, extremely cranky. And they say, “What we have learned from you whining users is that we can’t do what we said we would do. We cannot separate the technological aspects from the social aspects of running a virtual world. […] “So we’re back, and we’re taking wizardly fiat back, and we’re going to do things to run the system. We are effectively setting ourselves up as a government, because this place needs a government, because without us, everything was falling apart.” (Shirky 2005:193)

RULES FOR MAKING RULES

And the worst crisis is the first crisis, because it’s not just “We need to have some rules.” It’s also “We need to have some rules for making some rules.” And this is what we see over and over again in large and long-lived social software systems. Constitutions are a necessary component of large, long-lived, heterogeneous groups. (Shirky 2005:194)

THE COHEN LAW

Geoff Cohen has a great observation about this. He said, “The likelihood that any unmoderated group will eventually get into a flame-war about whether or not to have a moderator approaches one as time increases.” As a group commits to its existence as a group, and begins to think that the group is good or important, the chance that they will begin to call for additional structure, in order to defend themselves from themselves, gets very, very high. (Shirky 2005:194)

PROBLEMAS DE ESCALA

In groups of larger than a dozen but smaller than a few hundred, there are conversational forms that can’t be supported when you’re talking about thousands or millions of users a single group. (Shirky 2005:195)

O CASO FLICKR

I was talking to Stewart Butterfield about Flickr, the application they’re launching here. I said, “Hey, how’s that going?” He said, “Well, we only had the idea for it two weeks ago. So this is the launch.” When you can go from “Hey, I’ve got an idea” to “Let’s launch this in front of a few hundred serious geeks and see how it works,” that suggests that there’s a platform there that is letting people do some really interesting things really quickly. It’s not that you couldn’t have built a similar application a couple of years ago, but the cost would have been much higher. And when you lower costs, interesting new kinds of things happen. (Shirky 2005:195)

O CASO DOS WEBLOGS

We had every bit of technology we needed to do weblogs in 1994, the day Mosaic launched the first forms-capable browser. Every single piece of it was right there. Instead, we got Geocities. Why did we get Geocities and not weblogs? We didn’t know what we were doing. […] It took a long time to figure out that people talking to one another, instead of simply uploading badly scanned photos of their cats, would be the real source of value. (Shirky 2005:195)

A weblog is web-native. It’s the Web all the way in. A wiki is a web-native way of hosting collaboration. It’s lightweight, it’s loosely coupled, it’s easy to extend, it’s easy to break down. […] It assumes HTTP is transport. It assumes markup in the coding. RSS is a web-native way of doing syndication. So we’re taking all of these tools and we’re extending them in a way that lets us build new things really quickly. (Shirky 2005:196)

VERTIGO MOMENT

The vertigo moment for me was when Phil Gyford launched the Pepys weblog, Samuel Pepys’ diaries of the 1660s turned into a weblog form, with a new post every day from Pepys’ diary. What that said to me was that Phil was asserting, and I now believe, that weblogs will be around for at least 10 years, because that’s how long Pepys kept a diary. And that was this moment of projecting into the future: this is now infrastructure we can take for granted. […] Why was there an eight-year gap between a forms-capable browser and the Pepys diaries? It just takes a while for people to get used to these ideas, to understand the technical form well enough to put it to socially novel uses. (Shirky 2005:196)

O CASO DA TELECONFERÊNCIA COM CHAT E WIKI de JOI ITO (Emergent Democracy)

This is a broadband, multimedia conference call, but it isn’t implemented as a single giant thing. It’s just three little pieces of software, laid next to each other and held together with a little bit of social glue. This is an incredibly powerful pattern. (Shirky 2005:197)

AS DUAS UBIQUIDADES (todo mundo está online; toda interação offline tem uma dimensão online)

The Web has been growing for a long, long time. In the beginning, just a few people had web access, and then lots of people had web access, and then most people had web access. But something different is happening now. In many situations, all people have access to the network. And “all” is a different kind of amount than “most.” “All” lets you start taking things for granted. (Shirky 2005:197)

We’re starting to see software that simply assumes that all offline groups will have an online component, no matter what. (Shirky 2005:198)

I have this Venn diagram image of two hula hoops, where my real life is off to the left, and my online life is off to the right, and I’m the only thing in common between the two; people in my offline world are different than people in my online world. And for most of the last 30 years, the Net has been like that—you had different friends online than offline. If the hula hoops are swung together, though, so that everyone who’s offline is also online, that’s a different kind of pattern. In a world of ubiquitous Net access, the split between offline and online is not between different groups, but between different modes of interacting in one group. (Shirky 2005:198)

If you assume whenever a group of people are gathered together that they can be both face to face and online at the same time, you can start to do different kinds of things than if real versus virtual communications are treated as separate cases. I don’t run a real-world meeting now without either having a chat room or a wiki up and running. (Shirky 2005:198)

These kinds of ubiquity, both “everyone is online,” and “everyone who’s in a room can be online together at the same time,” are leading to new patterns. (Shirky 2005:198)

POWER LAW

The normal experience of social software is failure. If you go into Yahoo groups and you map out the subscriptions, it is, unsurprisingly, a power law. There’s a small number of highly populated groups, a moderate number of moderately populated groups, and this long, flat tail of failure. And the failure is inevitably more than 50% of the total mailing lists in any category. (Shirky 2005:200)

FIRST THING TO ACCEPT (o fenômeno é sociotécnico)

Of the things you have to accept, the first is that you cannot completely separate technical and social issues. (Shirky 2005:200)

You can’t separate technological effects from social ones, and you can’t specify all social issues in technology. The group is going to assert its existence independently of the software somehow, and you’re going to get a mix of social and technological effects. (Shirky 2005:201)

The group is real. It will exhibit emergent effects. It can’t be ignored, and it can’t be programmed, which means you have an ongoing issue. And the best pattern, or at least the pattern that’s worked the most often, is to put into the hands of the group itself the responsibility for defining what value is, and defending that value, rather than trying to describe everything in the software up front. (Shirky 2005:201)

SECOND THING TO ACCEPT (membros ou usuários)

The second thing you have to accept: members are different from users. A pattern will arise in which there is some group of users that cares more than average about the integrity and success of the group as a whole. And that becomes your core group (Shirky 2005:201)

in all successful online communities that I’ve looked at, a core group arises that cares about the community as a whole—not just their part of it—and that gardens effectively and takes care of the social environment by encouraging good behavior and discouraging bad behavior. (Shirky 2005:201)

THIRD THING TO ACCEPT (a centralidade do “core group”)

The third thing you need to accept: the core group has rights that trump individual rights in some situations. This pulls against the libertarian view that’s quite common on the network, and it absolutely pulls against the one-person/one-vote notion. But you can see examples of how bad an idea voting is when citizenship is the same as ability to log in. (Shirky 2005:202)

The core group needs ways to defend itself so that it can keep the larger group concentrated on its sophisticated goals and away from its basic instincts. (Shirky 2005:203)

So leveraging the core group is a really powerful system. (Shirky 2005:203)
And because of the difficulty in maintaining a focus on sophisticated goals, all groups of any integrity have a constitution. At the very least, the formal part is what’s instantiated in code—“the software works this way.” The informal part is the sense of “how we do it around here.” And no matter how it is substantiated in code or written in charter, whatever, there will always be an informal part as well. You can’t separate the two. (Shirky 2005:203)

PRIMEIRO PRINCÍPIO DE DESIGN (sistema de reputação)

The first thing you would design for is handles the user can invest in. (Shirky 2005:204)

anonymity doesn’t work well in group settings, because “who said what when” is the minimum requirement for having a conversation. (Shirky 2005:204)

eBay works in noniterated atomic transactions, which are the opposite of social situations. (Shirky 2005:204)

Reputation is also not generalizable or portable. There are people who will cheat on their spouse but not at cards, and vice versa, and both, and neither. Reputation in one situation is not necessarily directly portable to another. (Shirky 2005:204)

If you give users a way of remembering one another, reputation will happen, and that requires nothing more than simple and somewhat persistent handles. (Shirky 2005:204)

the important lesson is this: changing your identity is really weird. And when the community understands that you’ve been doing it and you’re faking, that is seen as a huge and violent transgression. And they will expend an astonishing amount of energy to find you and punish you. So identity is much less slippery than the early literature would lead us to believe, because although the technology makes fluid identity easy, social life demands some degree of fixity. And all you need is a system with some sort of persistent handle, and users will invest them with all the trappings of identity and even the layers above that like reputation. (Shirky 2005:205)

SEGUNDO PRINCÍPIO DE DESIGN (sistema de reconhecimento)

Second, you have to design a way for there to be members in good standing, some way in which good works get recognized. (Shirky 2005:205)

TERCEIRO PRINCÍPIO DE DESIGN (limiares para participação)

Three, you need some barriers to participation, however small. […] There needs to be some kind of segmentation of capabilities. […] It has to be hard to do at least some things on the system for some users, or the core group will not have the tools that they need to defend themselves. (Shirky 2005:206)

The groups’ goals sometimes differ from those of the individual members, and the user of social software is the group, so ease of use should be for the group. (Shirky 2005:207)

QUARTO PRINCÍPIO DE DESIGN (proteger o grupo dos efeitos de escala)

Finally, you have to find a way to spare the group from scale. (Shirky 2005:207)

You have to find some way to protect your own users from scale. This doesn’t mean the scale of the whole system can’t grow. But you can’t try to make the system large by taking individual conversations and blowing them up like a balloon; human interaction, many-to-many interaction, doesn’t blow up like a balloon. It either dissipates, or turns into broadcast, or collapses. So plan for dealing with scale in advance, because it’s going to happen anyway. (Shirky 2005:208)

HOSPEDAR SOFTWARE SOCIAL é como GERIR UM CONDOMÍNIO

the act of hosting social software, the relationship of someone who hosts it is more like a relationship of landlords to tenants than owners to boxes in a warehouse. […] The people using your software, even if you own it and pay for it, have rights and will behave as if they have rights. (Shirky 2005:209)

==============================================
SHIRKY, Clay. 2005 [2004]. Group as user: flaming and the design of social software. In: Joel Spolsky (ed.). The best software writing I. New York: Springer-Verlag, pp.211-21.

COMPUTER-AS-BOX (used by individuals) versus COMPUTER-AS-DOOR (to a social space)

When we hear the word “software,” most of us think of things like Word, PowerPoint, or Photoshop, tools for individual users. These tools treat the computer as a box, a self-contained environment in which the user does things. […] And yet, when we poll users about what they actually do with their computers, some form of social interaction always tops the list—conversation, collaboration, playing games together, and so on. The practice of software design is shot through with computer-as-box assumptions, while our actual behavior is closer to computer-as-door, treating the device as an entrance to a social space. […] We have grown quite adept at designing interfaces and interactions between people and machines, but our social tools—the people-to-people software the users actually use most often—remain badly mis-fit to their task. Social interactions are far more complex and unpredictable than human/computer interaction, and that unpredictability defeats classic user-centric design. As a result, tools used daily by tens of millions are either ignored as design challenges, or treated as if the only possible site of improvement is the user-to-tool interface. […] The design gap between computer-as-box and computer-as-door persists because of a diminished conception of the user. The user of a piece of social software is not just a collection of individuals but a group. Individual users take on roles that only make sense in groups: leader, follower, peacemaker, process enforcer, and so on. There are also behaviors that can only occur in groups, from consensus building to social climbing. And yet, despite these obvious differences between personal and social behaviors, we have very little design practice that treats the group as an entity to be designed for. (Shirky 2005:211-2)

SOFTWARE SOCIAL

much of the most important recent work in social software has been technically simple but socially complex. (Shirky 2005:212)

Mailing lists were the first widely available piece of social software. (The PLATO system beat mailing lists by a decade, but had a limited user base.) Mailing lists were also the first widely analyzed virtual communities. And for roughly 30 years, almost any description of mailing lists of any length has mentioned flaming, the tendency of list members to forgo standards of public decorum when attempting to communicate with some ignorant moron (Shirky 2005:212)

FLAMING AS HISTORICAL INEVITABILITY OF GROUP ONLINE INTERACTION

Flame wars are not surprising; they are one of the most reliable features of mailing list practice. (Shirky 2005:213)

This tension in outlook, between “flame war as unexpected side effect” and “flame war as historical inevitability,” has two main causes. The first is that although the environment in which a mailing list runs is computers, the environment in which a flame war runs is people. (Shirky 2005:213)

Flaming, an un-designed-for but reliable product of mailing list software, was our first clue to the conflict between the individual and the group in mediated spaces, and the initial responses to it were likewise an early clue about the weakness of the single-user design center. (Shirky 2005:213-4)

NETIQUETTE

The first general response to flaming was netiquette. Netiquette was a proposed set of behaviors that assumed that flaming was caused by (who else?) individual users. […] Interestingly, netiquette came tantalizingly close to addressing group phenomena. Most versions advised, among other techniques, contacting flamers directly rather than replying to them on the list. Anyone who has tried this technique knows it can be surprisingly effective. […] Addressing the flamer directly works not because it makes him realize the error of his ways, but because it deprives him of an audience. Flaming is not just personal expression, it is a kind of performance, brought on in a social context. […] People behave differently in groups, and while momentarily engaging them one-on-one can have a calming effect, that is a change in social context rather than some kind of personal conversion. Once the conversation returns to a group setting, the temptation to return to performative outbursts also returns. (Shirky 2005:214)

KILL FILE

Another standard answer to flaming has been the kill file, sometimes called a bozo filter, which is a list of posters whose comments you want filtered by the software before you see them. […] Kill files are also generally ineffective, because merely removing one voice from a flame war doesn’t do much to improve the signal-to-noise ratio—if the flamer in question succeeds in exciting a response, removing his posts alone won’t stem the tide of pointless replies. And although people have continually observed (for 30 years now) that “if everyone just ignores user X, he will go away,” the logic of collective action makes that outcome almost impossible to orchestrate—it only takes a couple of people rising to the bait to trigger a flame war, and the larger the group, the more difficult it is to enforce the discipline required of all members. (Shirky 2005:214-5)

FLAMING as TRAGEDY OF THE COMMONS

Flaming is one of a class of economic problems known as the Tragedy of the Commons.5 Briefly stated, the Tragedy of the Commons occurs when a group holds a resource but each of the members has an incentive to overuse it. […] In the case of mailing lists […], the commonly held resource is communal attention. The group as a whole has an incentive to keep the signal-to-noise ratio high and the conversation informative, even when contentious. Individual users, though, have an incentive to maximize expression of their point of view, as well as maximizing the amount of communal attention they receive. (Shirky 2005:215)

NEGATIVE ATTENTION IS BETTER THAN NO ATTENTION

It is a deep curiosity of the human condition that people often find negative attention more satisfying than inattention, and the larger the group, the likelier someone is to act out to get that sort of attention. (Shirky 2005:216)

WEBLOG SOLUTION TO FLAMING (privatization)

Weblogs are relatively flame-free because they provide little communal space. In economic parlance, weblogs solve the tragedy of the commons through enclosure, the subdividing and privatizing of common space. (Shirky 2005:216)

WIKI SOLUTION TO FLAMING (communization)

Like weblogs, wikis also avoid the Tragedy of the Commons, but they do so by going to the other extreme. Instead of everything being owned, nothing is. […] And because older versions of wiki pages are always archived, it is actually easier to undo damage than cause it. (Shirky 2005:216-7)

SLASHDOT SOLUTION TO FLAMING (moderation)

Rating, karma, meta-moderation—each of these systems is relatively simple in technological terms. The effect of the whole, though, has been to allow Slashdot to support an enormous user base, while rewarding posters who produce broadly valuable material and quarantining offensive or off-topic posts. (Shirky 2005:218)

CRAIGLIST SOLUTION TO FLAMING (moderation & incentive)

Likewise, Craigslist took the mailing list and added a handful of simple features with profound social effects. First, all of Craigslist is an enclosure, owned by Craig […]. Because he has a business incentive to make his list work, he and his staff remove posts if enough readers flag them as inappropriate. Like Slashdot, he violates the assumption that social software should come with no group limits on individual involvement, and Craigslist works better because of it. […] And, on the positive side, the addition of a “Nominate for ‘Best of Craigslist’” button in every email creates a social incentive for users to post amusing or engaging material. […] Like flaming, the “Best of” button also assumes the user is reacting in relation to an audience, but here the pattern is harnessed to good effect. The only reason you would nominate a post for “Best of” is if you wanted other users to see it—if you were acting in a group context, in other words. (Shirky 2005:218)

OPERANDO FATOS SOCIAIS (Bumplist; flame-retardant; worst-of; get a room; flagging) (Shirky 2005:218-20)

Once you regard the group mind as part of the environment in which the software runs, […] a universe of untried experimentation opens up. […] There is no guarantee that any given experiment will prove effective, of course. The feedback loops of social life always produce unpredictable effects. Anyone seduced by the idea of social perfectibility or total control will be sorely disappointed, because users regularly reject attempts to affect or alter their behavior, whether by gaming the system or abandoning it. (Shirky 2005:220)

==============================================
SPOLSKY, Joel. 2005. [Editor’s commentary]. In: The best software writing I. New York: Springer-Verlag, pp.183-4.

HISTORY OF SOCIAL SOFTWARE DESIGN

In the late 1980s, software went through a major transition. […] Before about 1985, the primary goal of software was making it possible to solve a problem, by any means necessary. […] Humans will bend to the machines, like Charlie Chaplin in Modern Times. […] Suddenly with personal computers […] [i]t wasn’t enough just to solve the problem: you had to solve it easily, in a way that takes into account typical human frailties. […] And we called this usability, and it was good. […] Eventually usability came into its own as a first-class field of study, with self-trained practitioners and university courses, and no software project could be considered complete without at least a cursory glance at usability. […] We’re about to undergo a similar transition. […] As soon as the Internet happened, software stopped being solely about computer-to-human interaction and started being about human-to-human interaction. We had new applications like the Web, email, instant messaging, and bulletin boards, all of which were about humans communicating with one another through software. […] Now, suddenly, when you create software, it isn’t sufficient to think about making it possible to communicate; you have to think about making communication socially successful. In the age of usability, technical design decisions had to be taken to make software easier for a mass audience to use; in the age of social software, design decisions must be taken to make social groups survive and thrive and meet the goals of the group even when they contradict the goals of the individual. […] Features need to be designed to make the group successful, not the individual. […] The field of social software design is in its infancy. In fact, we’re not even at the point yet where the software developers developing social software realize that they need to think about the sociology and the anthropology of the group that will be using their software, so many of them just throw things together and allow themselves to be surprised by the social interactions that develop around their software. […] [I]n this new era, sociology and anthropology are just as crucial to software design as usability was in the last. (Spolsky 2005:183-4)