Monthly Archives: July 2003

until somebody loses an eye

If Kieran Healy was in Silcon Valley rather than some primitive outpost of the british empire he’d capture a pattent: shake and bake business model for research and development. He outlines a simple DYI method – take two large rich complex world views, slam them into each other, study the result. I used to joke that particle physics proceeded from the presumption that if you need to understand the automobile the right approach was to slamming cars into each other a very high volocity and then weigh the debris. For example here is an example of running Quaker and Puritian world views into each other the result formed a big thick interesting book.

Of course the dark side of this amusement arises when the two big world views are two institutional forms locked in mortal combat. It’s all in in good fun until somebody loses an eye.

Practicewise vs Sciencewise

In the paper today is an article about a currenlty popular approach to dealing with bing drinking on college campuses. It contains this wonderful quote: ”’Part of the enthusiasm about social norming is that so little has worked in the past,” Wood said. ”Practicewise, it’s extremely popular. Sciencewise, it’s a little preliminary.”’

My son and I enjoyed an amusing conversation about a thick book he’s reading about the British Empire, the Middle East, and all that. He says: “They didn’t know what they were doing.” I say: “Good lesson there, one rarely does … though there is some comfort in pretending.” He say: “Oh they were quite confident they knew what they were doing.” I say: “Probably a general rule there. Given that nobody knows diddly, and a large population of possible actors, the sorting hat will see to it that those who are arrogant enough to pretend they know what they are doing will rise to the top and do something.” Since everybody around them will be pointing out that we really don’t know what we are doing they will become more and more arrogant and better and better at dismissing everybody else as useless irritants. Once you get rid of all those generators of negativity you can then get down to maximizing on your own self interest.

I’m glad that modern empire builders don’t suffer from this syndrome.

Weeds and Tubers

mapleseed.gif

There is a maple tree in my backyard. Each year it drops a carpet of winged seeds on the ground. Tens of thousands of seeds, every year, for 30 to 60 years. One, just one, of those seeds needs to take for this tree to fulfill it’s Darwinian mandate and create the next generation. One survives out of million? The ecologists call this a r-Selected strategy.

I, on the other hand, have only a few children, and unlike the maple tree I am expending vast resources on each one of them. The ecologists call this a K-Selected strategy.

Species with an r-Selected architecture (weeds, annuals, insect pests,bacteria) tend to be opportunistic. They spread fast. The “r” stands for resources. If storm clears a section of forest the nearby maple is ready to seed that clearing. These species quickly cover new territory and quickly compose the dead. They tend to fluctuate quickly with the weather.

Species with K-Selected strategy (coconuts, apples, birds, most mammals) expend more on each offspring. Their populations tend to be more constant and self regulating

I assume that some business models are more r-Selected, with others are more K-Selected. If the weather is good and new markets are emerging fast then one should invest in the r-Selected businesses. For the last hundred years technology has created new markets in quantity – a good time for r-Selected businesses. Ones where it’s best to encourage a large population of lightly funded experiments. Now if you think that’s easy I’d recommend a careful dissection of a maple seed. Conversely I’d assume that if your operating in a very mature market with volatile weather then larger enterprises more careful planning and husbanding of your resources if a better tactic.

All this give rise to my new cartoon of open source. That those tens of thousands of projects at Source Forge are like maple seeds. That Open Source is a species that has adopted a r-Selected strategy. It assumes that that the problem at hand is not husbanding ideas, but covering the fresh earth of possibilities. That the problem isn’t finding options worth executing upon, but finding which of a ten thousand possible options will actually take root.

Now one thing that’s curious about this is that if you look at large Open Source projects you might not see that. Those projects look more like whales. They tend to have a certain overhead where in their resources more carefully managed so the baby doesn’t die.

Of course all this is in total contrast to closed source projects. Every one of those I’ve worked on has expended tremendous resources attempting to manage scarce resources. Those projects seem much more like K-Selected species, carefully hording their fatty reserves so they can survive the next round of lousy weather that the market or management blows down the hallway.

Finally I think this has something critical to say about what goes on as you move along the power-law curve. That the population that resides on the long tail tends to be more r-Selected (limited by resources and driven by opportunism) while the upper classes that reside in the towering heights tend to be more K-selected (durable in the face of bad weather, fat, enthusiastic about property rights that guard their inheritance.).

language code is vo

Any theory of standards needs to include standard languages; i.e. French, Japanese, Java, etc.

No widely sucessful human languages were designed by professionals. Languages are extremely sticky (i.e. nobody can learn a second language perfectly after puberty). Most people acquire their primary language by a cognitive short cut. They adopting the local dialect. Preferential attachment indeed. Like any systems with large a installed base rationalization after the fact is extremely difficult. But it does create a vast and entertaining liturature of how we got here.

July 18th is Johann Schleyer’s birthday. Schleyer was a late 19th century German who invented a Volap’k (notice the umlat) a constructed language. It was quickly displaced by Esperanto.

I’m amused that Schleyer was extremely fastidious about retaining control over his IP rights. It must have been an interesting time, the late 19th century, when it first became plausible that individuals might own one of these widely used standards.

Why Standardize?

This is a list of what drives standardization, i.e. what the goal or purpose of creating a standard is, or what value provides the motive force to cause a standard to come into existence.

I mined many of these out of Industrywide Voluntary Product Standards by Hemenway. Many many moons ago. It has drifted from that original over time. I keep making additions.

frame the competition
A standard make it easier for buyers and sellers to negotiate an agreement. It frames that negotiation. It defines the landscape upon which the competitors will meet. It reduces the complexity of the buyers shopping significantly.
accelerate growth
By clarifying how cooperation takes place, enabling a platform, encouraging complements, simplifying contracting, etc. etc. standards accelerate the growth of the industries around them. For example after the standards for computer interconnection settled in (two examples: the IP protocol stack, or the PC backplane bus) the growth in took off.
cooperation
Enable and frame cooperation between parties to the standard. For example, the standard to drive on the right hand side of the road makes things go smoothly for all parties.
exclude competitors
“A dominant entity (or oligarchy) can use standards to shape the competition and define things to the disadvantage of competitors. This can be done by using the standard to focus on attributes that benefit the standard maker. (See also stability.) The standard maker can gain some first mover advantage, an advantage which (in multiple rounds of the game) can keep competitors “”chasing tail lights.”””
raise the bar
A powerful player may use standards to force suppliers to stretch for a higher level of quality. Governments, for example, do this when they set fuel efficiency or safety standards. Microsoft does this when they define the standard PC.
f(in)->out
A standard can specify the inputs to a good, the process used to make that good, or the outputs. It is often the case that one of these three is far more tractable to measure than the others (it’s easier to measure students per class than it is knowledge instilled). In the construction industries, for example cement construction, the process is critical to a quality output so standards are set to guide inspection steps in the construction.
worse is better
A standard requires both a spec, and a community of users. Attributes that improve a standards abilities to achieve and maintain critical mass often compete with other attributes. Simpler specs are often incomplete; sometimes quite incomplete. The original spec for C, SQL, and Java are all examples of the ‘worse is better’ syndrome. Sometimes the community/spec doesn’t grow – or it fragments – so this is all you get. The early adopters often feel they have been deceived.
brandname displacement
Brandnames are one of the ways used to signal quality to buyers. Buyers maybe forced to use brandnames as a substitute for more accurate measures of quality when buying complex goods. Government standard setting often does this; for example, in the battery industry AA batteries are all built to a standard and don’t vary significantly from brandname to brandname.
platform
Create a platform in service of a bloom of applications above that platform. This is similar to the desire to create compliments.
scale economies
Enable the cost advantages that comes from big: distribution, manufacturing, purchasing, externalities, network effects, etc.
mutual aid
Enables parties to share resources to solve problems. For example, assuring that allied armies share the same size bullets, or that communities share the same size fire hoses. The most generic of these is the sharing of labor, members of the standards community benefit from the problem solving done by other members. For example, if I purchase a Macintosh I get some of that; if I purchase a PC, I get some more. This and a number of other aspects (platform, complements, etc) all create a network effect around standards.
preempt the rush for the bottom
“In the absence of standards vendors may sell efficiency (i.e. lower price) while in fact they deliver is actually lower quality. This is what led to the airline industry writing a standard to define ‘a sandwich’ or the construction industry to write a spec for the “”1 inch board””.”
my way
It is extremely common to find individuals or small groups that have codified their operating rules into what they call standards. Coding conventions are one example of this. Such groups will share these with others; their motives in doing that run the range from enthusiasm to ascription.
aid smaller buyers
Large buyers can afford the overhead of writing their own specifications and have the buying power to enforce them. Historically milspec standards, since they were public, benefited smaller buyers who could free-ride on the public good.
survey current practice
Many standards writing processes start with a capturing a list of current practices – and then some of them never get very far beyond that. The vocabulary they create for describing how things are done in this first stage can be extremely valuable. The standards for medical information systems are like this.
quality
Most goods have numerous heterogeneous attributes. Standards tend to strip down those attributes to a few, and then define quality in those terms. Grade A apples, for example, might mean only that they are blemish free; but say nothing about their taste. This is related to framing the competition.
lawyers or standards
Standards are often used as a device to avoid costly litigation or accidents; in this sense a standard is a cheap form of contracting.
amusement
“Standards often seem designed to amuse. For example, the standard for a 2×4 isn’t 2 inches by 4 inches, but rather something less than that. This kind of thing arises out of the ‘preempting a rush for the bottom’ and the ‘cataloging of current practice’. It also arises out of the need for stability; as with the definition of “”the hundred year storm””; which after it was defined turned out to be misnamed.”
stability
Standards tend to create homogeneous markets; this tends to lower the chance of disruptive innovation.
create complements
Vendors desire that complements be of high quality and low cost; since standards tend to create those aspects it maybe in the interest of a vendor to create standards for those complements. For example when Apple introduced user interface standards for Mac programs they were laboring to make their complementary products, i.e. MacIntosh Applications, higher quality.
signal value
“Vendors often use standards compliance for it’s signal value. “”Version 12, now fully certified XHotStuff support.”” “
IP pooling
IP creates monopolies, which in turn frustrates the creation of markets and complements. Firms may find it necessary to cross-license or create IP pools to work around this barrier to market growth. [See Carl Shapiro’s paper “Navigating the Patent Thicket: Cross Licenses, Patent Pools, and Standard-Setting”]
prevent stranding
In the absence of standards and in the presence of strong network effects early buyers are likely to find they have made happened to choose a vendor that fails to win the leading position. Such buyers are then forced to bear the cost of being stranded and switching to the winning, now standard, vendor(s).
taxonomy
Diversity of practice makes standardization harder. One scheme to move toward something less diverse, more standard, is to catalog the existing practice. This might not be, strictly, a motivation to standardize; but rather a tactic.  This is, of course, self referential and intended to assure the above is put to good purpose – e.g. – epistemic closure.
interoperablity
What to say…

counterpoint

David Weinberger makes a number of important counter points to Clay Shirky’s talk on groups.

sumo.jpg

Clay often does a clever bit of dialectic busting by simultanously enjoying the new, emerging, innovative, that disrupts the vested interests while at the same time demanding that people stay grounded in the lessons of the past and admit to the enivitable, necessary emergance of hubs, formal structures, centers of excelence, or dare we say vested interests.

Dave, on the otherhand recognizes the violence inherent in forcing things that are implicit to become explicit. That when you write the governing constitution for your group you reduce a picture worth a thousand words and compress it into a few dozen bare statements. A lot dies in the process.

Shortly after writing the rules, making explicit a tiny bit of what was once implicit, people show up who recognize that rules imply a game. People who enjoy the process of playing games and writing rules. People blind to all that is implicit.

Capablity Nostolgia

One of the curious things about academics is how the structure of their institutions encourages them to become extremely specialized. The doctoral process and it’s follow-on the tenure process both encourage an extremely depth first drill down into a domain. Each paper they write is required to be tightly entangled in the literature via references and a long reprise of what has come before.

This is a little like a man who has spent his entire legacy to purchase a very expensive peice of equipment, say a high speed drill press. In a variation on the if all you have is a hammer everything looks like a nail when you present a highly trained academic with your problem, say a leaky roof, he starts thinking – “Hm. You know I think we could get my drill press up there on the roof… sure, no problem.”
My life has been much broader and much much more shallow. And when presented with a leaky roof I often find myself thinking; “Hm, I worked in an umbrella factory once – maybe 30 years ago…”

I was reminded of that by reading Tim Orton‘s post of a list of links to systems that allow delegation of rights to other parties.

These papers were a nostalgia trip for me. Back in the 70s at CMU I had some light involvement in the development of a multiprocessor system known as C.mmp. The operating system had a clever way of managing rights. It used something called “capabilities.” Capabilities where a much better but in the end impractical design. Today operating systems use an approach called access control lists – a lousy but practical design.

Access control lists, usually called ACL, protect things by marking objects with a list enumerating who is allowed access. If the question arises “Is Bob allowed to update the payroll data?” the ACL system checks that list to see if Bob’s on the list, if so it allows the change. ACL’s are like the guest list at an exclusive party, each time another guest shows up the doorman checks their ID against the guest list before letting them in. Maintaining the guest lists is a pain, so is the managing the ID cards.

Capabilities allows Bob to delegate the task of updating the payroll to one of his acquaintances.
keyring.jpg
In a capability system Bob carries around large set of capabilities. Think
of one of those huge key rings that building maintenance
guys carry around. When Bob wants to modify the payroll data he pulls
out the right key/capability and presents it to the system, which then checks
it. If Bob want’s to delegate, he can hand the key to his assistant. Keeping
all these keys under control is a pain.
Real world system work with a hybrid of keys and guest lists. In some situations you present an ID card (for example to withdraw books from the public library) and in other scenarios your provided with a key (for example when you rent a car).

I’m finding it very chew on all that, particularly because there is lots of work going on these days in and about identity systems for the net. It’s an amusing puzzle: is a browser cookie more like a capability or an identity card? … Yes. It depends. Ah, no it’s really something else. More about groups…

Imagine

market.jpg

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?”