A conversation with Brian reveals the interesting insight that many products emerge first as situated software; to use Clay’s delightful term.
Consider for example MovableType. It emerged situated in the intersection of the set of people that could install Perl and the set of people who manifested a desire to rant (or reveal). For the longest time that community of people both limited it’s growth but at the same time forgave it any number of short comings. Finally the folks who wrote it budded off TypePad which eliminated a the Perl expertise portion from the embedded situation.
If you want to get dragged into conversation about membrane design again then you can turn up the knob and rant about how that’s another example of how public goods can be captured by private entities. But that’s somebody else’s rant.
All this is analogous to Clayton Christensen’s rants about how disruptive products seem to always emerge serving unserved customers. Such customers are both forgiving of the products short comings and they provide a strong demand signal that helps to shape the product that emerges. Both of these are necessary preconditions for creating something new.
Oh no, there are now two dudes named Clay in this posting; what’s up with that!
In any case.
Another point to make about situated software is this balance between a forgiving environment and a strong signal that helps the software to adapt.
The challenge in making a thing survive over time is getting it to adapt.
So among the benefits that a piece of situated software draws from it’s environment is this adaptive advantage. More forgiveness. Better feedback.
One reason that real world software is so much harder is that it’s unforgiving. One reason that Windows has thrived is that they have demanded a high level of forgiveness from their users. They get to do that because of the monopoly.
Economists should stop being so fixated on the pricing advantages a monopoly captures and turn their attention to the adaptive advantages. Oh wait, I’m getting dragged back into the membrane design discussion; I hate that discussion.
Check out the book “Plans and Situated Actions : The Problem of Human-Machine Communication” by Lucy Suchman. She actually wrote the book on “situated” software/design/etc back in 1987. It’s a little hard to read; kind of dense and academic, but she definitely makes a compelling case. Thanks to Shirky for the case studies too.
Cowritten with John Seely Brown and others. Good company! Thanks!
http://allconsuming.net/item.cgi?isbn=0521337399
But the membrane design discussion is the one to have here.
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.
I’m slightly concerned. New fathers should be suffering from sufficent sleep deprivation that they aren’t rational. Rational isn’t compatible with caring for new borns.
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.