http://allconsuming.net/item.cgi?isbn=0521337399

And you’re right in your earlier point that this idea isn’t baked yet — wanted to float it now, to get some reaction.

Part of the problem is that this isn’t a coherent theory, like Open Source, or set of practices, like XP. Its more a question of a shift in both possibility and emphasis.

We have lots of examples of software that started for small uses — slashdot and ebay come to mind — that later grew, and suffered various success crises and refactorings on the way. Those are fascinating but rare cases — what I’m trying to pind down now is software that _doesn’t_ grow like that, but is still successful for its user population.

Banks have this all the time, custom software for a small group of traders, but they can eat the expense. What happens if the expense falls for making tools like that?

The best analogy I’ve got (which, of course, I thought of after putting out the original piece) is bookshelves. Your books in your house are in some order, even if that order is time-based — a big pile in which the most recently used book is on top.

No need, in a situation like that, to say “It’s not enough to have the programming books together, I must have all OOP books together, and separated from the procedural books.” You keep the ref manuals for perl and java close by, and the smalltalk and algol books far away.

This system would not work in a Barnes and Noble, nor would it work in the Library of Congress, and those two high-scale institutions couldn’t swap strategies either. But that doesn’t mean you need to use LC cataloging in your house — it would make things worse than your current cobbled together system.

So the software I’m interested in is software built around the naive taxonomies or other ‘that’s just how we do it around here’ behaviors.

It’s good news that Clay’s having great ideas like this. We must remain cognizant that this may just be a bizzare vision induced by lack of sleep. Further evidence of that possiblity is seen in his confession that his books are not well ordered.

In the essay there is some talk about the absense of scarcity. Mostly having fun with the analogy to programming becomming as common a practice as typing.

The word scarcity always catchs my attention because an absense of scarcity is one of the preconditions of the public goods. If X isn’t scarce you don’t have rivalry over X, and there is no reason to exclude access to X – no need nor benefit to making market in X. Markets evaporate as scarcity disappears.

Assertion: Situationed software depends upon some number of the public-goods provided by their niche.

For example: in Clay’s examples on app. leverages the public-good of physical proximity, and another leverages the public-good of existing reputation frameworks.

All this reminds me a little of how species emerge in niches. That they maywell be unable to survive outside that niche. They are dependent upon the niche. A large suite of niches creates a fucundity of emergence.

If programming becomes less scarce, as it did with Hypercard, then we get a bloom of new software in smaller situations. As the scarcity declines the situated software emerge as a kind of public-good building network dependencies between it’s behavior and the existing public-goods of it’s niche.

I should get more sleep.