The L-Curve model would have us pack the entire US population onto a football field, 44 people per square inch. In the center of the field the 2 inch high turf represents the median income. Society cares for the lawn: prisons to the left, schools to right. California for example.
Less than 1% of the American population is in prison, while over the age of 18 6% are enrolled in school
This image is lifted from an article at First Monday (A Practical Model for Analyzing Long Tails).
I’d seen this trick of using a sports field to help inform your intuition about power-law curves previously. In that case the distribution of wealth is the topic. These guys talk about the L-curve; shown here (video):
Both of these do a nice job of helping to visualize the actual shape of these curves. They help to clarify why the politics and business models that serve the two legs are very different and why the appeals that emphasis middle class values are should be treated with some suspicion. The more typical illustration, shown to the right, is preferable if you want to deemphasis the polarization and highlight the uniformity of the underlying generative processes.
I hate most explanations for why people participate in Open Source. I care about this question. I enjoy the game of puzzling out the answer. In a reversal of the usual cliche I love the game and hate the players; the casual players who think they know the answer. After two decades of thinking about this question I love that I stumble upon new answers.
This morning I was attempting to read, yet again, Benkler’s essay on sharing nicely where in he argues that the usual dialectic framing of how to coordinate activities (hierarchy v.s. markets) has blinded us to a third scheme; i.e. sharing. He points out some huge coordination problems that are solved via sharing and he does the good and necessary work of constructing an economic model for why some problems are well solved by sharing.
Part of his model explains why owners have excess lying around, that is suitable for sharing. In that explanation I was excited to to notice a new motivation for sharing.
Benkler draws our attention to excess capacity that owners can not consume. Idle cycles on your PC or empty seats in your car as you drive hither and yon. He model for this is analogous to that seen in value pricing models - i.e. if you own a hotel full of rooms and as the hour grows late you should consider selling those rooms for less; since otherwise they will go idle an you will get nothing.
I found my self thinking at that point about the emotions an owner has about this excess capacity, for example the sense of of lost opportunity, leading to emotions of frustration, grief, guilt. The hostess pressing left overs on her guests as the party wraps up is motivated by a horror at the waste shows how motivating this kind of sharing might be.
But the resource that drives open source is talent so the question naturally arises at this point does this model have something to say about sharing around the creation of these knowledge pools? This is delightful bit. If we think of skill as a capital good then talented people own building full of skills; and they lease out to earn their living. Of course most of the time they can’t find a buyer for all their skills. The rooms are empty. It’s not surprising that they are willing to share freely some of this capacity.
I had already noted many of the motivations outlined above for sharing one’s talents: countering the guilt for letting it go to waste, the positive emotions of generosity, the low cost of giving away the excess capacity. But I had not noticed something else: skills that are not exercised decay. While the hotel room left idle depreciates only slightly, a skill unused decays quickly. The skill demands that I exercise it, it’s survival depends on that exercise. If I horde it, it evaporates.
I didn’t know about this and it’s quite useful. In Openssh you can specify the command to run when a given key connects. In effect this allows you to treat ssh keys as capability tokens. You can gin up a key pair, and then configure things so that key is useful for one and only one operation; say retrieving a log file or polling a remote system. If you leave don’t bother with giving the key a pass phrase (you could also configure your ssh-agents just right) the client machine can use the capability in scripts as it pleases. The details for how to set up the authorized_key file to do this are in the ssh manual. Meanwhile on the client side it helps to setup a pseudo host in your .ssh/config file. Wire up just right you can say ssh fetch-log-from-foo. In the ssh-config manual there is additional useful doc for. IdentitiesOnly helps keep a stray ssh-agent from blessing things with a more capable identity. You should disable the ControlMaster, setting that to no.
The group I’m involved with, as my job, has released some software: Appalachian, an OpenID add-on for Firefox 2.x. It’s under a BSD style license. It helps you manage multiple OpenID, and smooth the process of logging into sites using OpenID.
OpenID is a good example of a solution that has lots of benefits and lots of risks. It sits in that part of the risk/benefit plane where our brains don’t like to sit.
It’s great because it has strong adoption drivers: not to hard for web sites to use, not too hard for users to understand, and easy for lots of identity providers to add to their offerings (and more importantly it’s very good for them). So, it’s very likely that OpenID will get a slew of adoption.
It’s risky because it encourages people to adopt a single global identifier; and that’s bad because it makes it easy for arbitrary 3rd parties to aggregate data about them.
The global identifier problem in internet identity systems is a puzzle. If you hang out with Semantic Web people for a while you begin to see a picture of the future were by giving every entity it’s only URI we can then casually make statements about those entities. How many URI denote the same entity quickly becomes a problem to which all the social sciences have something to contribute.
I have a strong opinion about this. I think entities should have more URI, not less; but that it is the nature of our technology that we are likely to rapidly head in exactly the opposite direction. I.e. what I want is entirely in conflict with what I believe very strong forces are going to deliver.
So I’m curious about how to fight back. For example how could we enable users to have billions of OpenID, rather than one (or a handful)? Appalachian is, among other things, a step in that direction.