More on Control and Complexity and Big

Dennis Howlett commented on a recent post of mine, On Control, where I was musing over Big’s relationship to Control Failure, and arguing that we needed a Better But Not That Big approach. One of the things Dennis said was

“Big often means complex. So how do you propose to solve the complexity issues?”

That stayed in my mind; I have tremendous respect for what Dennis has to say, it’s not often that I am able to connect with a tech-savvy open-minded articulate accountant :-).

Almost coincidentally, I was reading The Origin Of Wealth by Eric Beinhocker, as recommended to me by a couple of readers of this blog. [Thank you Dave Bridgeland and Tommi Vilkamo]. [And yes it’s true, I read every comment, try and reply to as many as I can, and try and learn from the comment. Otherwise why bother?].

I’m still reading it. [I read maybe a dozen books in parallel, usually in multiple passes as well. First pass skim-read, take a few notes along the way. Determine where to focus serious reading time the next time around. Second pass do the serious reading. Take notes on what I didn’t understand, what I need to dig deeper into, not necessarily in the book either. Third pass follow up and clean up, get the ideas clear in my head.]

And it was while I was reading the Beinhocker book first-pass that I was given the opportunity to revisit some of the stuff that Scott Page had written. I’d come across Scott before, I think it was Erik Brynjolfsson who first pointed me at him; I’d read Scott’s Computational Models from A to Z some time ago, and some of his stuff on Path Dependence more recently; I couldn’t link to that, you can find it on his homepage as a pdf.

I quote from Beinhocker:

Page proposed that there are two dimensions to the difficulty of an economic coordination problem. One dimension is how hard it is to decompose the problem into chunks that can be solved in parallel. [……] The second dimension is the number of steps that need to be done sequentially. […….] Page posited that organisations evolve to match the nature and difficulty of the probelms they are trying to solve. In rough terms, if the problem can easily be chunked into parallel tasks and doesn’t require much sequencing, then the organisation will reflect this simplicity and tend to be broad and flat. If the problem cannot be easily divided up and has numerous sequential steps, then the organisational hierarchy will tend to be narrow and deep.

And I think that’s where one of the major problems of Big and Complex lie.

There is considerable organisational inertia to task redefinition, de-sequencing and re-sequencing, as people desperately try and hold on to fiefdoms and power bases built around particular task definitions and sequences. As a result, things are done sequentially where they don’t need to be done sequentially. This false sequencing yields an unsolvable complexity and an immense amount of wasted energy, repeat work, even completely unnecessary work. Which in turn demotivates the workers and reduces task completion quality and increases task completion time. Workers aren’t stupid, soon you have apathy.

And I guess apathy is the hierarchical organisation’s equivalent of anarchy.

Big is necessary for Complex. But only when Complex itself is necessary. What I worry about is how often Complex is a construct of past hierarchies rather than a genuine need to solve a problem. I’ve heard phrases like “Don’t Allocate, Isolate”, “Don’t Automate, Obliterate” for a few decades now. I’ve even read HBR and related articles with similar titles that long ago. So why doesn’t it happen? Because of Unnecessary Complex.

As Einstein said, we need to keep things as simple as possible. But no simpler. So where there is a need for Big, Big can and should stay.

When you take into account the fruit of Moore’s Law and Metcalfe’s Law and Gilder’s Law, when you take into account the sheer power of the web and virtualisation and consolidation and service orientation, when you overlay all that with distributed computing and the grid and P2P, then maybe some of these hub-and-spoke approaches are ripe for obliteration. Just maybe.

Thanks again to Dennis for forcing me to think harder about this. And I look forward to more challenging comments, that’s how I learn.

On gatekeepers and opensource

Opensource communities have always had some form of moderation.

Sometimes they are called “the core“, sometimes they are referred to as “1000lb gorillas”, and sometimes they’re just called “moderators”. The term itself doesn’t matter, but the function represented by the term does matter.

Unless the term itself is wrong.

Like “gatekeeper”. [Yup, this was partially triggered by some of the Rogers/Searls/Finkelstein debate. But only partially. The true kernel for this post was a piece by FactoryJoe which I will come to later.]

Why do I think it’s wrong? Let me try to explain. To keep the argument simple I am going to compare “gatekeeper” with “moderator”. This is not some deep semantic exercise going into the etymology of each word; it is nothing more than my personal view on what the terms conjure up, and the contexts they tend to get used in.

  • A gatekeeper checks your credentials before he lets you in, the default is access denial; a moderator assumes you are in unless some simple overarching community principle is broken by you, the default is access approval.
  • A gatekeeper protects a narrow entry into an exclusive space; a moderator seeks to prevent an open space from being polluted.
  • A gatekeeper provides the credentials he later checks; a moderator neither provides credentials nor checks them.
  • A gatekeeper is a concept rooted in hierarchy; a moderator is a participant in a network, although sometimes moderators have supernode status within the network. In this context the moderator operates, in a Gladwellian sense, as part-maven, part-connector. And the connections tend to operate on a soft-touch-weak-interaction network-oriented basis rather than a Pyramid-Selling exploitative strong interaction which is hierarchical in nature.
  • Moderators need the deep domain knowledge that mavens have, and the wide social networks that connectors have; gatekeepers need authority from on high within the hierarchy, like parking wardens and ticket inspectors have.
  • Gatekeepers are about exclusion. Moderators are about inclusion.
  • Gatekeepers can be automated; moderators can’t.

I could go on, but I won’t. What I wanted to do was get a worthwhile debate going, so that I can learn from it, and hope that the community learns as well. How will I know? Simple, the market/community will tell me. Many comments and links, the snowball works. None or few, the post will atrophy into nothingness. The market decides.

The essence of democratised innovation, be it opensource software or for that matter the blogosphere, is enfranchisement of all. Which is what a moderator seeks to do. The essence of what a gatekeeper does is enfranchisement of a few. Which is about as counter to opensource thinking as is humanly possible.

So when I read Chris Messina’s recent post on Building a Better Mousetrap, I was thinking “Oh dear, gatekeeping, path pollution” and not “Wow, enabling”. Maybe I’m wrong; I’d love to find out otherwise. Here are a few quotes from Chris’s post:

  • The problem that I see is Google’s ability to shut out third party services once you’ve imported yourself into the proverbial gLife.
  • In simplest terms, with the state we’re in with centralized authentication in web applications, it’s like waiting for Microsoft and Apple to strike a deal enabling you to copy and paste from Appleworks to Word.
  • To put it in greater perspective: Web2.0 should have been the “great wide opening” — that is, where you could be in utter control of your data and move it in and out of services at your whim, just as you can with your money, in and out of banks depending on the quality and diversity of services they offer. And indeed, they’ve got to compete just to keep your business

Great post, Chris.

Ability to shut out. Centralised authentication. Rather than the “great wide opening”. In other words, gatekeeping rather than moderation.

This is why getting identity and authentication and permissioning right is critical for a functioning Web 2.0; this is why getting IPR and DRM right is critical for a functioning Web 2.0; this is why getting an internet that is neutral to what’s in the bits is critical for a functioning Web 2.0.

Otherwise what we will have is a Web 2.0 that is less than Web 1.0 ever was, and a pitiful shadow of what it could have been. That’s like building planes and then ensuring by law rather than by technology that they can’t fly. And that’s why I’m confused.

An aside on the “mathematics of opensource”, a rule of thumb that I’ve seen work:

For every 1000 visitors/lurkers you get around 80 active participants; of the 80 active participants you get maybe 20 hyperactives. These hyperactives often form the core, the 1000lb gorilla, the moderators.

And guess what? These moderators don’t get elected, blessed or knighted into place as a result of some grace and favour by a ruling monarch. They vote themselves in to that place by active (and valuable) participation. Participation that needed no prior authentication or credentials. Just their brains and their willingness to participate. Participation that generates value to the community.

I think this rule of thumb works for the blogosphere as well. I know many so-called A-listers, but nothing in their behaviour makes me think of gatekeeping. Open access. Nobody owns it Everyone can use it Anyone can improve it. That’s how these A-list people have behaved with me.

It is possible that some of the access I’ve had was bequeathed upon me as a result of my title or my status. I can’t discount that. But most of the time, in my experience, people don’t even ask me what I do, they use something that is more akin to a trusted domain approach. And perhaps, as a consequence, there is something that looks like gatekeeping to those who look for something like gatekeeping.

But it’s not gatekeeping.

Moderators connect. Gatekeepers channel. Connected, not channelled.