Month: September 2006

Following the Aaron Swartz post, some of the comments and discussions I’ve seen on the web suggest that people think there is no real difference between Wikipedia and traditional encyclopedias, in terms of how they are produced.

This is wrong. And dangerous.

Three critical differences need to be preserved, they are key distinguishers of what makes social software “social”.

These are:

Contributor selection
Subject selection
Capacity to show dissent

In Brickipedia, the editors choose the contributors. In Wikipedia the contributors choose themselves. This is very powerful.

In Brickipedia, the editors frame and anchor the topics. In Wikipedia the contributors choose to write what they’re passionate about. Also very powerful.

In Brickipedia, there is no capacity to show dissent. In Wikipedia, dissent is visible. This is the most powerful differentiator.

Of course there is also a difference in the way Bricki and Wiki contributors get rewarded, but I feel that this is less important than the three I’ve mentioned above.

We must preserve this. Motivated people selecting themselves to write about things they feel passionate about, and able to show agreement and dissent as well.

Read Cass Sunstein on Democracy and Dissent if you’re interested, I am currently travelling and unable to point to the right references. I’m sure Google will oblige.

Following the Aaron Swartz post, some of the comments and discussions I’ve seen on the web suggest that people think there is no real difference between Wikipedia and traditional encyclopedias, in terms of how they are produced.

This is wrong. And dangerous.

Three critical differences need to be preserved, they are key distinguishers of what makes social software “social”.

These are:

Contributor selection
Subject selection
Capacity to show dissent

In Brickipedia, the editors choose the contributors. In Wikipedia the contributors choose themselves. This is very powerful.

In Brickipedia, the editors frame and anchor the topics. In Wikipedia the contributors choose to write what they’re passionate about. Also very powerful.

In Brickipedia, there is no capacity to show dissent. In Wikipedia, dissent is visible. This is the most powerful differentiator.

Of course there is also a difference in the way Bricki and Wiki contributors get rewarded, but I feel that this is less important than the three I’ve mentioned above.

We must preserve this. Motivated people selecting themselves to write about things they feel passionate about, and able to show agreement and dissent as well.

Read Cass Sunstein on Democracy and Dissent if you’re interested, I am currently travelling and unable to point to the right references. I’m sure Google will oblige.

I feel at ease. For once I am not confused. At least I am less confused than I was earlier.
You remember the sequence of posts I wrote about opensource and gatekeepers? [Those new to the conversation can find them here, here, here, here and here, in chronological order. Alternatively you can enter “gatekeeper” into the search box in the sidebar and get the same results. But it’s not important.]

I’ve been tracking what Aaron Swartz has been saying about Wikipedia in Raw Thought, his blog. Now why would I do this? Simple. In a strange kind of way I think that Wikipedia is the Drosophila of social software, much like a recent Scientific American article suggested that chess could be the Drosophila of cognitive science. You can measure things in Wikipedia, conduct experiments, analyse what’s happening, predict results, compare actuals against predictions. Wikipedia provides the nearest thing to a live laboratory for the study of social software. For now, anyway.

In a recent post, headlined Who Writes Wikipedia, Swartz has some interesting analysis of what happens there. I quote from the post:

• Wales decided to run a simple study to find out: he counted who made the most edits to the site. “I expected to find something like an 80-20 rule: 80% of the work being done by 20% of the users, just because that seems to come up a lot. But it’s actually much, much tighter than that: it turns out over 50% of all the edits are done by just .7% of the users … 524 people. … And in fact the most active 2%, which is 1400 people, have done 73.4% of all the edits.” The remaining 25% of edits, he said, were from “people who [are] contributing … a minor change of a fact or a minor spelling fix … or something like that.”
  

They expected to find an extreme Pareto Law in operation. They looked for it. And they were not disappointed. They found it.

There were critics of the findings, who felt that counting the raw number of edits was not a useful indicator, that there should be a measure related to that which was created, the body text. [Notice I didn’t say Content. Bad word.] And Wales indicated this would happen over time.

When I first heard this, I couldn’t get my head around the Pareto-versus-Long-Tail tension. Surely Wikipedia should behave Long-Tail rather than Pareto? And Wisdom-Of-Crowds Emergence surely cannot depend on a small gatekeeper fraternity, because that is hard to scale? But I’m used to the gatekeeper mentality, so I just stayed quiet. And confused.

Swartz was curious, and did a little bit of homegrown investigation. Here are his early observations:

• Wales seems to think that the vast majority of users are just doing the first two (vandalizing or contributing small fixes) while the core group of Wikipedians writes the actual bulk of the article. But that’s not at all what I found. Almost every time I saw a substantive edit, I found the user who had contributed it was not an active user of the site. They generally had made less than 50 edits (typically around 10), usually on related pages. Most never even bothered to create an account.

So there was some reason to look at what the critics (of the original findings) were saying. Maybe analysis at number-of-edits level was not particularly useful; maybe the amount of original text created would be a better yardstick.

Here’s what Swartz found, admittedly in a simple “homegrown” experiment:

• To investigate more formally, I purchased some time on a computer cluster and downloaded a copy of the Wikipedia archives. I wrote a little program to go through each edit and count how much of it remained in the latest version. Instead of counting edits, as Wales did, I counted the number of letters a user actually contributed to the present article.
• If you just count edits, it appears the biggest contributors to the Alan Alda article (7 of the top 10) are registered users who (all but 2) have made thousands of edits to the site. Indeed, #4 has made over 7,000 edits while #7 has over 25,000. In other words, if you use Wales’s methods, you get Wales’s results: most of the content seems to be written by heavy editors.
• But when you count letters, the picture dramatically changes: few of the contributors (2 out of the top 10) are even registered and most (6 out of the top 10) have made less than 25 edits to the entire site. In fact, #9 has made exactly one edit — this one! With the more reasonable metric — indeed, the one Wales himself said he planned to use in the next revision of his study — the result completely reverses.

Read the article for yourself. I have no idea who Swartz is, never met him, never even heard of him until I decided (following the gatekeeper debate) to try and understand what makes Wikipedia tick. That’s all.
One swallow does not make a summer. Swartz’s findings are based on a relatively small sample; and whenever you study anything remotely connected with society, there is a high risk that you bring in cultural bias and what Stephen Jay Gould called Reification (in The Mismeasure of Man). I am not, therefore, suddenly extrapolating Swartz’s findings into a resolution of the MidEast crisis.
What I am doing is sharing those findings with you. They support Wisdom of Crowds. They support Emergence. They support micromarkets and microbrands. They support Long Tail rather than Hit Culture. They support markets being conversations. All these are about people and relationships and access and empowerment, but in different fields and with different perspectives.
And most importantly, they suggest that the success of social software is based on everyone doing something about whatever it is they are passionate about. Everyone. Passion.

There’s an important principle in there somewhere, which (I hope) will be borne out by more intensive and formalised study:

Given enough eyeballs, all bugs are indeed shallow….provided there is code to look at. The value starts with the created output, not with the bug.
Gatekeepers can and should be eyeballs that help us all remove bugs and improve the pool of ….code….information….ideas….whatever.

What worried me about gatekeepers, something I could not articulate well before this, was the ability of the gatekeepers to restrict creativity. Particularly when we are yet to grow out of the Blame Culture and Hierarchy and Command and Control.

Without creativity there is nothing, no shallow bugs, no bugs, no nothing. Nothing.

Let’s not forget that as we experiment with, build, adapt and evolve governance models for social software.

To put it in Swartz’s words:

• Even if all the formatters quit the project tomorrow, Wikipedia would still be immensely valuable. For the most part, people read Wikipedia because it has the information they need, not because it has a consistent look. It certainly wouldn’t be as nice without one, but the people who (like me) care about such things would probably step up to take the place of those who had left. The formatters aid the contributors, not the other way around.
  

The formatters aid the contributors, not the other way round. Great stuff.

This time I can’t blame Sig alone, I have to include Malcolm and Dom and Don Marti, and their comments and posts over the past six months. Last night I meandered back to Don’s seminal post of many months ago, on Lightweighting, which I covered here.

Seeing the comments on my post last night, and thinking further about it, I felt it was important to try and understand exactly why lightweighting and opensource and agile programming and social software all have such roll-water-uphill problems in enterprises. They seem to share similar problem characteristics. Again, there’s a lot of rich literature on the subject, so I shall concentrate on just one small perspective.

The power of perception.

When you tell someone that their phone is now also a camera, they have no problem accepting it. They can pick it up and play with it and see that it has a Ronseal about it, “it does exactly what it says on the tin”. It is real to them. [An aside. I am definitely growing old. I cannot for the life of me figure out why someone would want a television display embedded into the facade of their refrigerator. Shades of reading Powerpoint on BlackBerry there….]

When you tell someone that their satellite TV is also a DVD rental shop and a video recorder, they have no problem accepting it. They can fight over the controls and delete unwatched recorded programmes accidentally to their hearts’ content. It is real to them.

When you tell someone that their PC is also a music player and a TV, they have no problem accepting it. Despite all the problems of DRM by accident and by design, they remain relaxed about the experience. In fact, given the traditional reluctance in households to learn anything about setting and operating VCRs in the past, they probably feel some familiarity in experiencing the failures. The experience is real to them. [An aside: I have been singularly uninterested in live TV on a computer, only in replays, and only of snippets and clips.]

I could elucidate more examples, but I think these are enough to underpin my simple point. It’s all about perception.

The examples all include some level of process redesign and innovation, some level of lightweighting, but they come packaged with hardware. And the hardware is real, people can touch and feel it. So the experience is real to them.

When it comes to software, particularly enterprise software, the touch-and-feel aspect is harder. True, we are seeing a move towards the purchase of appliances, where the hardware and software are integrated. But the appliances tend to get embedded in the “infrastructure’. And infrastructure hates lightweighting.

So how do people perceive value in software? Four ways:

• Lots of new hardware
• Big project/licence expenses
• Large teams
• High pain of adoption

Notice I carefully don’t state “People perceive value in software by seeing the measurable business value generated by usage of the software”. This-Page-Left-Intentionally-Blank.

Software becomes real to enterprise people through one or more of these things. When it comes to opensource, to process lightweighting, to social software and to agile programming, we have a problem. And if anything, the continuance of the laws of Moore and Metcalfe and Gilder exacerbate this problem. [An aside: is that why Bloatware is so successful? I wonder]

The problem is that the software isn’t perceived as real unless one or more of those perception triggers are set off. And we don’t want to set them off.

So what’s the solution? I have this uneasy feeling it’s going to be about hardware, especially when you look at the iPod phenomenon.

I think we are going to see all these things embed in enterprises over time: lightweight processes, opensource software, social software and agile development methods. But it may take a new generation of hardware and of platforms before that happens.

People buy the overall experience, like they buy cars. When we have desktop platforms which use opensource software as their basis, that come with agile programming and social software as standard, that support the lightweighting of processes seamlessly, it is then that we will have lift-off.

Our challenge then may become isolated to the design and architecture of these hardware-plus-firmware-plus-enabling-software platforms, concentrating on the user interface and look-and-feel and simplicity and convenience and usability and interoperability. Customers want to be able to touch and feel what they buy, and perceive value through the pain of acquisition. People like us want to reduce the pain of acquisition and adoption, but we’re taking away some of the ways customers perceive value as a result, and making our jobs harder.

I am reminded of Christensen’s Innovator’s Dilemma discussions with respect to Britannica and Encarta:

People did not replace Britannica with Encarta, far from it. They replaced Britannica with a home PC, spending a similar amount of money to assuage their guilt, but getting Encarta wrapped in. The PC was real to them. Encarta was a useful by-product, a Trojan Horsed entrant to their home.
So if we want to embed lightweight in enterprise, we may need some heavyweight Trojan Horses.

If there was a kernel for this post, it was probably Sig at Thingamy writing “Forthcoming: documents, schmocuments and Pluto“. At least that’s my excuse and I’m sticking to it.

Anyway, here’s the list. All beginning with S. Just for the heck of it.
Stalinists: Even though there is some doubt as to whether he actually ever said it, Stalin is often credited with saying that as long as people know there is an election, it’s not the people who vote that count, it’s the people who count the votes. A variation of this tends to operate in enterprises, where “power” is vested in the presentation-makers and minute-takers. What social software does is threaten this power.

Sadists: Learning to do things in an enterprise can be painful. Learning to do hard things can be very painful. I have worked in a company where, in order to save on stationery costs, they instituted a process whereby the “stationery cupboard” was only open on Tuesdays between 2pm and 4pm; if that wasn’t enough, no stationery could be ordered unless a form was filled in; and forms were only made available on Tuesday mornings between 10am and 10.30am. Learning how an organisation works is often like growing ear hair. There are no short cuts, it just takes a long time. And causes much suffering. What social software does is threaten to take away this familiar pain, leaving phantom limb sensations.

Stockholmers: Similar to hostages forming an attachment to their captor (despite the invidiousness of their position) there is an enterprise tendency to form deep-rooted and long-lasting relationships with lock-in vendors. This syndrome comes in two flavours: Temporary and Permanent. The Temporary one is less intense, fading when there is a change of management on the enterprise side. The Permanent version is a real feat of engineering, able to withstand multiple changes of management. Nobody gets fired for buying locks. What social software does is threaten to release the hostages from their secure jails.

Second-guessers: Any swarming or emergence effect needs to have a swarm in the first place. One place. With the plethora of options available in Web Too Many Oh, this creates a paradox of choice. Freedom’s just another word for nothing left to choose. Second-guessers can stultify attempts to derive value from social software, by fragmenting the enterprise base in time and space. Space because they ensure multiple options are taken up simultaneously guaranteeing there is no critical mass, no liquidity. Time because they engineer an enterprise change-of-horse-in-midstream, never actually allowing the liquidity to be acquired. What social software does is threaten to take away the freedom of the second-guessers.

Sewer-dwellers: The ploy here is to define the battleground for social software as infrastructure, as plumbing. Even though it shouldn’t be the case, most enterprise buyers treat infrastructure as overpriced, oversold and over. As soon as the argument shifts to sewerage, the enterprise immune system has no problem repelling all boarders. This is despite the fact that social software has minimal infrastructure costs. Why do sewer-dwellers do this? Because it’s their home. What social software does is threaten to take away where they live.

Silobites: These are people who live in silos. Their jobs are to ensure that as much stuff as possible is stored in the silo, the bigger the silo the better they feel. They are defined by the walls. What social software does is threaten to take down these walls, building small connectors between silos.

Look at the things threatened. Power. Familiarity. Security. Housing. Freedom. Enough said.