Category: Four pillars

I am intrigued by the regular convergence of comments on aspects of social software on to a single, critical topic: The role of the expert.
Whether I look at the “quality” comments, the lowest-common denominator ones, the “dumbing down” ones or for that matter the questions on the ontology of encyclopaedias, somewhere in my head they are all the same.
It’s all about the barriers we raise about being “qualified” to be an “expert”.

Imagine a world where venture capitalists refused to fund a start-up unless the founders all had university degrees. Know any large companies founded by college dropouts? :-)

Imagine a world where you couldn’t be a musician unless you’d done your time at the right academy or ecole. Know any talented musicians who had no formal training? :-)
History is littered with examples of prodigious talent without formal qualifications. Qualifications yes. But not formal ones. The world is richer as a result.

Too often “expertise” is associated with (a) formal qualifications (b) years of experience (c) the weight of being “published” and (d) various tests for competence and ability covering intelligence and emotion and cognitive ability and what-have-you.

These are all good indicators of expertise. Some are very good indicators of expertise. But they should not be considered necessary, or, for that matter, sufficient, conditions for being considered an expert.

Know any experts who turned down the Beatles? Know any experts who said that Fred Astaire couldn’t sing or dance? Know any experts who forecast a world market for maybe five computers? Know any that did not believe that a home computer was a good idea? Or that the internet was a passing fad?  :-)

There is no magic formula for talent or for expertise. But passion and motivation and perseverance and  access/enfranchisement go a long way. Every one of us is, or can be, a student for life, and a teacher for life. We all have a responsibility to ensure that the passion and motivation are allowed to be fruitful, and for that we need to ensure open access.

Ontologies can create unnecessary anchors and frames. Subjective elements creep in whenever we try and define expertise, particularly in the study of society. Too often definitions turn out to be dinosaur defences. There is a consilience taking place, a battle between the disciplines. Let’s not behave like the monarchs and priests and doctors and lawyers, and for that matter, IT professionals, of old, did.

As I said earlier, academic qualifications and experience and publishing history and test scores are all good indicators. In many cases they are very good indicators.

But they are not the only indicators. And should not be used to raise the wrong barriers.

Many years ago I used to watch Hill Street Blues regularly (I know, I’m sad that way….). So as we enter a phase where we’re all going to participate in, learn from, implement, iterate and adopt and iterate again the right governance standards for social software, I’d like to quote Sergeant Phil Esterhaus, played by the late Michael Conrad:

Hey, let’s be careful out there.

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.