In a marvelously appropriate off topic posting at Gizmodo the host points out a great article on how cell phones have a corrosive effect on people’s level of engagement with the place they are actually in. It’s a much more sophisticated take on the way that virtual places are in a vicious competition with physical places than the usual ranting about cell phones going off during meetings.

Meanwhile here at ApacheCon across the room a group of ten people is gathered closely around a round table. They are all gazing silent intent into their computers.  Occasional complaints about the network’s speed are heard.

I was very discomforted the first time I went to an ApacheCon. I had large complex mental models of the other participants in Apache. Models that I suddenly had to update with unnecessary facts – A is a drinker, B is quiet, C is a fast talker, D is tall, E is cute, F is young, G is old, H has a piercing, J has white hair, K isn’t very sociable, L is very personable…

On top of that is the shift in medium problem. This person, with whom you have a complex relationship entirely in one medium is suddenly shifted into another medium. IRC or email has an entirely different granularity and nature than other mediums. I know that some number of those people across the room are in IRC, maybe even talking to other people at the same table. That doesn’t surprise me in the least.

The  literature  on communities includes the  marvelous  term “Communities  of Limited  Liability”. Such communities meet most of the common tests of “community” (for example). But their members are aware that the scope of the community is limited.

The original example was urban neighborhoods. Members of such community know they are members, can identify other members, have a common practices and stories, and will come to each other aid as well as the aid of the community. But they don’t do any number of the other things that some people might assume are implied by community membership. They share holiday meals. They don’t marry each other. They don’t know details of each other’s personal lives – jobs, families, interests. The scope of  their  community involvement is clearly circumscribed.

I like to believe that  it is  part of modernity that people are parts of dozens such communities.  Each of these community relationships is very intense but only within the limits of that community.

I still feel a bit weird about the way that ApacheCon creates connections outside of the limited liability of the open source project relationship. There are risks, and  responsibilities  in that.

But I certainly don’t feel that it’s bewildering anymore. Now I kind of enjoy the weird sensation.

And, it’s nice, I’ve gotten to know some very interesting people.

Clay Shriky writes a delightful rant on the role of process as response to stupidity. …”Process is an embedded reaction to prior stupidity. When I was CTO of a web design firm, I noticed in staff meetings that we only ever talked about process when we were avoiding talking about people. ‘We need a process to ensure that the client does not get half-finished design sketches’ is code for ‘Greg fucked up.'”

He is wrong.

Healthy communities are full of diverse people of radically different skills. The
challenge in making a community that functions well is creating something out
of those talents that is closer to the maximum over the diverse talents rather
then the maximum of their lack of skills.

Did Greg fuck up? Maybe Greg’s the only guy in the group that actually ever
gets anything done. Maybe everybody knows that. Maybe the group is seeking a way to keep empower that talent while assuring that the occational errors that Greg makes stand a better chance of getting caught before they go out the door. So the community seeks a process.

Open source is full of processes to solving this problem – the problem of how
to get the max(talent) rather than the max(idiocy). We have numerious devices that are “biased-to-action” but enable the many eyes of different talents to keep a bit-o-quality-assurance on the risk implicit in that.

What pisses me off about Clay’s note is that he’s playing to people’s most base instincts. First he’s encouraging people to assume that process is a reaction to other people’s stupidity. That’s kind of thinking is toxic to community; it encourages people to label others rather than strive to find more functional processes.

Secondly he’s encouraging people to assume whenever they see a process to leap to the conclusion that was in reaction to some idiot’s incompetence. That reminds me of Mao’s advice to begin each negotiation by calling your opponent a “running dog.” Again it’s toxic to the community. What do you gain by accusing the people that crafted the process of “not trusting people.” I suspect that they were thinking that they had discovered a clever way to get the max of talent and speed in the face of a background noise of inaction, errors, and varying ablities.

This kind of thing spins people off your the merry-go-round; if your going to do this you better have some pretty delightful ponys on the ride to compensate.

None of this is to say that institutions don’t accumulate vistigal organs who’s cost totally overwhelms their benefit. I suspect that once Greg, aka mr. action man, leaves your probably need a process that adds a little action and a little less process that’s focus’d on quality assurance.

This is why it’s a healthy thing to keep at hand some suspision of vested interests, and institutional decay. But it is also health to have some respect for effective institutions, processes, and standards. A good dose of doubt is always best.

OK – now that I’ve gotten that rant out of my system.

(There was an only very marginally unrelated second half to this posting which I finally chopped off and posted separately.)

Tim O’Reilly tries to figure out where open source and the internet are going. “I think there’s a paradigm shift going on right now, and it’s really around both open source and the Internet, and it’s not entirely clear which one is the passenger, but at least they are fellow travellers.”

I agree with much of what he says, but I’m not so sure I think it’s a paradigm shift. Same elephant from a different perspective.

  – thanks Kimbo

A very nice complement to Clay Shirky’s peice on how in the fullness of time governance issues become a key challenge for online groups: Chuq Von Rospach takes an old fart’s look at the whole idea of the list mom. Listen to you mother. Eat your spinach. Respect your elders. Read it. Who took my car keys?

Steve Balmer, CEO Microsoft, one of the world’s richest men has, I gather, a list of troubles. Number one is the economy. Number two is open source.

Open source isn’t really Steve’s problem. Steve’s problem is that nobody trusts Microsoft anymore. Nobody.

A large constituency that doesn’t trust them anymore is developers. That’s bad. Microsoft’s OS monopoly provides a bridge between application developers and hardware developers. That’s what Operating Systems do. If both kinds of developers are scared to go over Mr. Balmer’s bridge – being a convicted abuser of your monopoly powers pretty much assures that – then they start looking for other ways over the bridge.

I bought a router recently for – after discounts, coupons, and rebates – five dollars. It’s got an operating system, a web browser, etc. etc. It doesn’t have any Microsoft components.

So I find it particularly amusing that Mr. Balmer would decide that the persona he want’s to adopt is that of Neo – the uber-developer of matrix, the wonderkun who is forced into battle with the system. How bizzare is that!?!

“Before Steve got on stage, there was a video showing Bill and Steve as Morpheus and Neo (respectively). Bill offered Steve two pills’one Big Blue on that required years of consulting, sub-par IT and a general lifetime of hell and the other a small, red one showing the truth. After the video, Steve rose up onto the stage from below the floor dressed in a black trench coat (a la Neo in the matrix).”

Consider the shiny red apple. “Buy me! Eat me!” it cries.

And what if you do? Will it be crisp, sweet and just a bit tart? Will it harbor a worm?

Will it be worth it? Will it deliver a good value??

Call those “signal value”, and “use value”. The attractive apple signals its value, but only by using the apple can you know its true “use value”.

Imagine! What you might do with that apple? You might display it in a bowl on the table. You might add it to a fruit salad. You might carve a hole in it, fill it with brown sugar, bake it, and later top it with ice cream. You might even fling it at a mugger and save an old lady. That apple is full of potential. How many old ladies might you save? Do these options make it more valuable?

If you watch, sometimes you will see shoppers in that trance of imagination. Boys in hardware stores will look at the coils of rope. They will imagine all the things they might do if they only had a length of rope. Oh, the trouble they might get into! They don’t value the rope particularly for its signal value, or for a use value. They value all those imagined worlds where that rope might play a role.

A designer might choose to focus on any mix of these three kinds of values. A car, for example; he might try to make it signal sophistication. He might labor to make it solid, affordable, reliable. He might attempt to create a car that enables a larger range of imaginary uses: a place to store the canoe, a holder for the french fries, a removable seat

But really I want to talk about software.

Software is assembled from modules with a liberal amount of caulking. Much of the craft of software design consists of design patterns for designing modules well.

I don’t think it’s too exaggerated to say that much of that craft is informed by a castle metaphor. Which is to say that a module is like a castle. You dig a moat around the module to defend it. You drop a carefully designed drawbridge (or more) to allow your users, about whom you are naturally somewhat paranoid, to safely transact with your module.

This metaphor is full of delightful consequences. Life is easier for your users, since they need only understand the drawbridge and can happily ignore all whatever bizarre things you might be doing behind the castle walls. For example you can safely reengineer your module without disturbing them. The metaphor runs deep, because it ties into one’s ideas about property rights, privacy, safety, etc.

But what if this is entirely backwards? What if this is entirely the wrong way to think about modules? What if we should be thinking like that car designer?

Shouldn’t the real goal of a powerful module be to create a large universe of options? Shouldn’t an exciting module create for its users the pleasure that a small boy gets when he contemplates a coil of rope?

Open.

A good module opens a universe of potentials, it delivers a bundle of options.

The modules whose design is grounded in the castle metaphor are often closed. They hoard their options.

These ideas are in partly the fault of Baldwin and Clark’s paper, “Does Code Architecture Mitigate Free Riding in the Open Source Development Model?“.

The most excellent cartoon of open-source offered in that paper is roughly as follows. If designers of open-source projects strive to design a kernel who’s nature creates a large bundle of options, then good things happen. Outside developers, with no coordination, are empowered to pick from among those options. They will, obviously, select the ones that best fit their skills and needs. The authors call each of those options a module, and the architecture modular. The kernel creates a kind of organizing principal for the project, a way of parceling out (or allocating) the work. The designer’s reward is that he gets to see his imaginary world built out – as if by magic. The contributing developers get rewarded directly – one module pays its own freight with that developer. The project thrives, assuming we can keep the barrier low enough so that developers contribute back their additions.

Abracadabra, the free riding problem is solved, and with luck the network effect around a project spins up enough to become self-sustaining.

Very nice.

But more than anything else, what I found fascinating was that the open source design problem is entirely inside out from the classic software engineering module design problem. The goal isn’t to create a beautiful well-guarded castle on a hill. The goal is to create a point of rendezvous. A place where a crowd of people wander about in a trance, imagining, “What kind of trouble might I get into with that rope?”

In France I like to go to the food markets. People walk slowly. They look at piles of mushrooms, beef, apples. I assume they are imagining, “Just what might I do with that apple?”

A most excellent essay on groups by the amazingly insightful Clay Shirky.

Here are two lists stolen from there.

Things you must accept about online groups:

• The social and technical are deeply entangled, you can’t partition them.
• Members are different from users. “… the group within the group that matters most.”
• Sometimes the rights of the core group trump those of individuals.

Things you really really ought to design for:

• Participants must have handles that can enable continuity, aggregate reputation, and be discarded
• You will need some scheme that recognizes members in good standing: handle, member since, introduction, karma points.
• You need barriers to participation, so the core can defend the group.
• Some protection against scale (or the tragedy of the commons)

I’d add that there needs to be a shared enterprise, often a document, around which the group revolves. But that’s probably optional.

A little list of the various line drawings I’ve encountered over the years of what open source is. These cartoons are both delightful and bloodless.

• Open source is a kind of public good.
• Open source is a kind of club good.
• Open source is a kind of standards making.
• Open source is a tactic in standards battles for limiting the rents captured by firms that implement the standard.
• Open source is r-selected, closed source is K-selected
• Open source as a labor movement, a guild, a profession; i.e. it can adopt any and all the functions those institutions sometime play.
• Open source is a search device in that the users, who are closer to the actual needs, search for innovations that the project can then aggregate.
• Open source as a portfolio of options, i.e. the project relinquishes to users control over an interesting options space.
• Open source as a fast first mover response to network effects.
• Open source as an aggregation of intrinsic motivations
• Open source as a projection of selfish motivation
• Open source as political revolution
• Open source as lower classes slipping around vested interests
• Open source as the immune response of the commons.
• Open source as a negotiation framework.
• Open source as mutual aid society
• Open source as club of enthusiasts
• Open source as platform competitor
• Open source as publish-or-perish analogy
• Open source as manifestation of alpha-male motives
• A scheme for users/buyers to coordinate their activities with supplier firms, i.e a more flexible substitute for rigid contracting or standards.
• A scheme that allows user/buyers to eliminate the need for a supplier (or temper supplier power) by working in common cause to create the supply.
• A means for network owner to temper or eliminate the power of adjacent networks.
• A negotiation framework where the code provides a document around which the parties organize the negotiation.
• A means to coordinate the creation of a pool of knowledge or IP.
• Just another massive multi-player game.
• A form of community specialized on the code as the point of common cause.
• Supply for the latent demand for quality collaborators around anything (or alternately a particular) common cause.
• Stone Soup: A point of rendezvous (kernel, seed crystal) for small contributions that when aggregated creates something tasty.
• An organization who’s parts are homologous to those found in any software firm, but interestingly different.
• Open source is a hot dog and bun economy, (e.g. manufacturing/services) where we give away the hot dogs.

I’m sure there another few dozen I’ve forgotten.

At dinner the other night somebody at an adjacent table was pondering that age old question; “who first realized you could eat an artichoke?” The question arose again at brunch yesterday, once again in a conversation on my periphery. I think the Gods are trying to tell me something.

The answer is, I’m sad to say all to painfully obvious. Innovation happens on the periphery. Where the need is greatest or the skill is most intense. Often where both are found together. That huge pool of poor starving people are continuously research on our behalf to discover new foods. Occasionally they discover something neat and the well feed among us get the benefit.

This model; where the vast unwashed masses do the work and a few aggregate the benefit lies at the heart of any number of modern successes. Open Source, when it works best, is a fine example – hundreds of millions of users, tens of thousands of developers, maybe a thousand contributing developers, a dozen developers doing the design and coordination and out pops Apache. Or Amazon, millions of readers, a few write reviews, Amazon captures them and out pops a unique product differentiator – one that’s hard to replicate because of the network effects. Or EBay with all those buyers and sellers rendezvousing around what is a really simple web site. Or Google using all those carefully hand crafted links as tiny votes to ranks the web’s pages. Or Microsoft with it’s thousands of developers striving to push the envelope of their platform to new heights.

Tim O’Reilly get’s it.