Turking! The idea and some implications

I recently read an edited collection of five stories, Metatropolis; the stories are set in a common world the authors developed together. This is a near future in which nation state authority has eroded and in which new social processes have grown up and have a big role in making things work. In some sense the theme of the book was naming and exploring those new processes.

One of those processes was turking. The term is based on Amazon’s Mechanical Turk. Google shows the term in use as far back as 2005 but I hadn’t really wrapped my mind around the implications; Metatropolis broadens the idea way beyond Amazon’s implementation or any of the other discussions I’ve read.

Turking: Getting bigger jobs done by semi-automatically splitting them up into large numbers of micro-jobs (often five minutes long or less), and then automatically aggregating and cross-checking the results. The turkers (people doing the micro-jobs) typically don’t have or need any long term or contractual relationship with the turking organizers. In many cases, possibly a majority, the turkers aren’t paid in cash, and often they aren’t paid at all, but do the tasks as volunteers or because they are intrinsically rewarding (as in games).

One key element that is distinctive to turking is some sort of entirely or largely automated process for checking the results — usually by giving multiple turkers the same task and comparing their results. Turkers who screw up too many tasks aren’t given more of those tasks. Contrast this with industrial employment where the “employer” filters job candidates, contracts with some to become “employees”, and then enforces their contracts. The relationship in turking is very different: the “employer” lets anybody become an “employee” and do some tasks, doesn’t (and can’t) control whether or how the “employee” does the work, but measures each “employee’s” results and decides whether and how to continue with the relationship.

This is an example of a very consistent pattern in the transition from industrial to networked relationships: a movement from gatekeeping and control to post hoc filtering. Another example is academic publishing. The (still dominant) industrial model of publishing works through gatekeeping — articles and books don’t get published until they are approved through peer review. The networked model works through post hoc processes: papers go up on web sites, get read, commented and reviewed, often are revised, and over time get positioned on a spectrum from valid/valuable to invalid/worthless. The networked model is inexorably taking over, because it is immensely faster, often fairer (getting a few bad anonymous reviews can’t kill a good paper), results in a wider range of better feedback to authors, etc.

It seems quite possible — even likely — that post hoc filtering for work will produce substantially better results than industrial style gatekeeping and control in most cases. In addition to having lower transaction costs, it could produce better quality, a better fit between worker and task, and less wasted effort. It also, of course, will change how much the results cost and how much people get paid — more on that below.

Amazon’s Mechanical Turk just involves information processing — web input, web output — and this is typical of most turking today. However there are examples which involve real world activities. In an extreme case turking could be used to carry out terrorist acts, maybe without even doing anything criminal — Bruce Sterling has some stories that explore this possibility. But there are lots of ordinary examples, like counting the empty parking spaces on a given block, or taking a package and shipping it.

Examples

  • Refugees in camps are turking for money. The tasks are typical turking tasks, but the structure seems to be some more standard employment relationship. If there were enough computers, I bet a high percentage of the camp residents would participate, after some short period in which everyone learned from each other how to do the work. Then the organizers would have to shift to turking methods because the overhead of managing hundreds of thousands of participants using contracting and control would be prohibitive.
  • A game called FoldIt is using turking to improve machine solutions to protein folding. Turns out humans greatly improve on the automatic results but need the machine to do the more routine work. The turkers have a wide range of skill and a variety of complementary strategies, so the project benefits from letting a many people try and then keeping the ones who succeed. (This is an example where the quality is probably higher than an industrial style academic model could generate.) The rewards are the intrinsic pleasure of playing the game, and also maybe higher game rankings.
  • There’s a startup named CrowdFlower that aims to make a business out of turkingrowdFlower has relationships with online games that include the turking in their game play. So the gamers get virtual rewards (status, loot). I can easily imagine that the right turking tasks would actually enhance game play. CrowdFlower are also doing more or less traditional social science studies of turking motivations etc. Of course the surveys that generate data for the research are also a form of turking.
  • Distributed proofreading. OCR’d texts are distributed to volunteers and the volunteers check and correct the OCR. (They get both the image and the text.) The front page goes out of its way to note that “there is no commitment expected on this site beyond the understanding that you do your best.” This is an early turking technology, and works in fairly large chunks, a page at a time. It may be replaced by a much finer grained technology that works a word at a time — see below.
  • Peer production (open source and open content). An important component of peer production is small increments of bug reporting, testing, code review, documentation editing, etc. Wikipedia also depends on a lot of small content updates, edits, typo fixes, etc. These processes have the same type of structure as turking, although they typically hasn’t been called turking. The main difference from the other examples is there’s no clear-cut infrastructure for checking the validity of changes. This is at least partly historical, these processes arose before the current form of turking was worked out. The incentive — beyond altruism and the itch to correct errors — is that one can get credit in the community and maybe even in the product.
  • I just recently came across another good example that deserves a longer explanation: ReCaptcha. It is cool because it takes two bad things, and converts them into two good things, using work people were doing anyway.

    The first bad thing is that OCR generates lots of errors, especially on poorly printed or scanned material — which is why the distributed proofreading process above is required. These can often be identified because the results are misspelled and/or the OCR algorithm reports low confidence. From the OCR failures, you can generate little images that OCR has trouble recognizing correctly.

    The second bad thing is that online services are often exploited by bad actors who use robots to post spam, abusively download data, etc. Often this is prevented by captchas, images that humans can convert into text, but that are hard for machines to recognize. Since OCR failures are known to be hard for machines to recognize correctly, they make good captchas.

    Recaptcha turns the user effort applied to solving captchas, which would otherwise be wasted, into turking to complete the OCR — essentially very fine grained distributed proofreading. Recaptcha figures out who’s giving the correct answers by having each user recognize both a known word and an unknown word, in addition to comparing answers by different users. Users are rewarded by getting the access they wanted.

    Note that if spammers turk out captcha reading (which they are doing, but which increases their costs significantly) then they are indirectly paying for useful work as well. Potentially Recaptcha could be generalized to any kind of simple pattern recognition that’s relatively easy for humans and hard for machines, which could generate a lot of value from human cognitive capacities.

    Some implications

    It seems that over time a huge variety and quantity of work could be turked. The turking model has the capacity to productively employ a lot of what Clay Shirky calls our “cognitive surplus”, and also whatever time surplus we have. Many unemployed people, refugee populations and I’m sure lots of other groups have a lot of surplus. As Shirky points out, even employed people have a discretionary surplus that they spend watching TV, reading magazines, playing computer games, etc. However right now there’s no way to bring this surplus to market.

    Switching from industrial relationships (heavyweight, gatekeeping and control) to networked relationships (lightweight, post hoc filtering) reduces per task transaction costs to a tiny fraction of their current level, and makes it feasible to bring much of this surplus to market.

    The flip side of that of course is that the more this surplus is available for production, the less anyone will get paid for the work it can do. Already in a lot of existing turking, the participants aren’t getting paid — and in many cases the organizers aren’t getting paid either. Also, more or less by definition, the surplus that would be applied to turking currently isn’t being used for any other paid activity, so potential workers aren’t giving up other pay to turk. Therefore, I expect the average payment for a turked task to approach zero, for both turkers and organizers. Usually there will still be rewards, but they will tend to be locally generated within the specific context of the tasks (online community, game, captcha, whatever). Often the entity that generates the rewards won’t won’t get any specific benefit from the turking — for example, in the case of ReCaptcha, the sites that use it don’t particularly benefit from whatever proofreading gets done.

    Mostly turking rewards won’t be measurable in classical monetary terms — in some cases rewards may involve “in game” currency but this doesn’t yet count in the larger economy. In classical monetary terms, the marginal cost of getting a job turked will probably approach the cost of building, maintaining and running the turking infrastructure — and that cost is exponentially declining and will continue to do so for decades.

    This trend suggests that we need to find some metric complementary to money to aggregate preferences and allocate large scale social effort. But I’m not going to pursue that question further here.

    Obviously it will be important to understand what types of work can be turked and what can’t. For example, could the construction of new houses be turked? That may seem like a stretch, but Habitat for Humanity and other volunteer groups do construct houses with a process very much like turking — and of course this has a long history in the US, with institutions like barn raising. Furthermore the use of day labor isn’t that different from turking. I’d guess that within ten years we’ll be turking much of the construction of quite complex buildings. It is interesting to try to imagine what this implies for construction employment.

    Realistically, at this point we just don’t know the limits of turking. My guess is that the range of things that can be done via turking will turn out to be extremely broad, but that it will take a lot of specific innovations to grow into that range. Also of course there will be institutional resistance to turking many activities.

    When a swarm of turkers washes over any given activity and devours most of it, there will typically be a bunch of nuggets left over that can’t be turked reliably. These will probably be things that require substantial specialized training and/or experience, relatively deep knowledge of the particular circumstances, and maybe certification and accountability. Right now those nuggets are embedded in turkable work and so it is hard or impossible to figure out their distribution, relative size, etc. For a while (maybe twenty years or so) we’ll keep being surprised — we’ll find some type of nuggets we think can’t be turked, and then someone will invent a way to make most of them turkable. Only if and when turking converges on a stable institution will we be able to state more analytically and confidently the characteristics that make a task un-turkable.

    Another issue is security / confidentiality. Right now, corporations are willing to use turking for lots of tasks, but I bet they wouldn’t turk tasks involving key market data, strategic planning, or other sensitive material. On the other hand, peer production projects are willing to turk almost anything, because they don’t have concerns about maintaining a competitive advantage by keeping secrets. (They do of course have to keep some customer data private if they collect it at all, but usually they just avoid recording personal details.) I’d guess that over time this will give entities that keep fewer secrets a competitive advantage. I think this is already the case for a lot of related reasons because broadly speaking “Trying to keep secrets imposes huge transaction costs.” Eventually keeping big secrets may come to be seen as an absurdly expensive and dubious proposition and the ability to keep big pointless secrets will become an assertion of wealth and power. (Every entity will need to keep a few small secrets, such as the root password to their servers. But we know how to safely give everyone read only access to almost everything, and still limit changes to those who have those small secrets.)

    There’s lots more to say, but that’s enough for now.

    Social fixed points

    Austin Henderson in his comment on Dancing toward the singularity starts by remarking on an issue that often troubles people when dealing with reflexive (or reflective) systems:

    On UI, when the machine starts modeling us then we have to incorporate that modeling into our usage of it. Which leads to “I think that you think that ….”. Which is broken by popping reflective and talking about the talk. Maybe concurrently with continuing to work. In fact that may the usual case: reflecting *while* you are working.

    We need the UIs to support his complexity. You talk about the ability to “support rapid evolution of conventions between the machine and the human,”. …. As for the “largely without conscious human choice” caveat, I think that addresses the other way out of the thinking about thinking infinite regress: practice, practice, practice.

    I think our systems need to be reflexive. Certainly our social systems need to be reflective. But then what about the infinite regress that concerns Austin?

    There are many specific tricks, but really they all boil down to the same trick: take the fixed point. Fixed points make recursive formal systems, such as lambda calculus, work. They let us find stable structure in dynamic systems. They are great.

    Fixed points are easy to describe, but sometimes hard to understand. The basic idea is that you know a system is at a fixed point when you apply a transformation f to the system, and nothing happens. If the state of the system is x, then at the fixed point, f(x) = x — nothing changes. If the system isn’t at a fixed point, then f(x) = x’ — when you apply f to x, you “move” the system to x’.

    A given system may have a unique fixed point — for example, well behaved expressions in the lambda calculus have a unique least fixed point. Or a system may have many fixed points, in which case it will get stuck at the one it gets to first. Or it may have no fixed points, in which case it just keeps changing each time you apply f.

    Now suppose we have a reflective system. Let’s say we’re modeling a computer system we’re using (as we must to understand it). Let’s also say that at the same time, the system is modeling us, with the goal of (for example) showing us what we want to see at each point. We’d like our behavior and the system’s behavior to converge to a fixed point, where our models don’t change any more — which is to say, we understand each other. If we never reached a fixed point, we’d find it very inconvenient — the system’s behavior would keep changing, and we’d have to keep “chasing” it. This sort of inconvenience does arise, for example, in lists that try to keep your recent choices near the top.

    Actually, of course, we probably won’t reach a truly fixed point, just a “quiescent” point that changes much more slowly than it did in the initial learning phase. As we learn new aspects of the system, as our needs change, and perhaps even as the system accumulates a lot more information about us, our respective models will adjust relatively slowly. I don’t know if there is a correct formal name for this sort of slowly changing point.

    People model each other in interactions, and we can see people finding fixed points of comfortable interaction, that drift and occasionally change suddenly when they discover some commonality or difference. People can also get locked into very unpleasant fixed points with each other. This might be a good way to think about the sort of pathologies that Ronald Laing called “knots”.

    Fixed points are needed within modeling systems, as well as between them. The statistical modeling folks have recently (say the last ten years) found that many models containing loops, which they previous thought were intractable, are perfectly well behaved with the right analysis — they provably converge to the (right) fixed points. This sort of reliably convergent feedback is essential in lots of reasoning paradigms, including the set of compression / decompression algorithms that come closest to the the Shannon bounds on channel capacity.

    Unfortunately we typically aren’t taught to analyze systems in terms of this sort of dynamics, and we don’t have good techniques for designing reflexive systems — for example, UIs that model the user and converge on stable, but not excessively stable fixed points. If I’m right that we’re entering an era where our systems will model everything they interact with, including us, we’d better get used to reflexive systems and start working on those design ideas.

    The path to a synthesis in statistical modeling

    As I discuss in Dancing toward the singularity, progress in statistical modeling is a key step in achieving strongly reflexive netminds. However a very useful post by John Langford makes me think that this is a bigger leap than I hoped. Langford writes:

    Attempts to abstract and study machine learning are within some given framework or mathematical model. It turns out that all of these models are significantly flawed ….

    Langford lists fourteen frameworks:

    • Bayesian Learning
    • Graphical/generative Models
    • Convex Loss Optimization
    • Gradient Descent
    • Kernel-based learning
    • Boosting
    • Online Learning with Experts
    • Learning Reductions
    • PAC Learning
    • Statistical Learning Theory
    • Decision tree learning
    • Algorithmic complexity
    • RL, MDP learning
    • RL, POMDP learning

    Within each framework there are often several significantly different techniques, which further divide statistical modeling practitioners into camps that have trouble sharing results.

    In response, Andrew Gelman points out that many of these approaches use Bayesian statistics, which provides a unifying set of ideas and to some extent formal techniques.

    I agree that Bayesian methods are helping to unify the field, but statistical modeling still seems quite fragmented.

    So in “dancing” I was too optimistic to “doubt that we need any big synthesis or breakthrough” in statistical modeling to create strongly reflexive netminds. Langford’s mini-taxonomy, even with Gelman’s caveats, suggests that we won’t get a unified conceptual framework, applicable to actual engineering practice, across most kinds of statistical models until we have a conceptual breakthrough.

    If this is true, of course we’d like to know: How big is the leap to a unified view, and how long before we get there?

    Summary of my argument

    The current state of statistical modeling seems pretty clearly “pre-synthesis” — somewhat heterogeneous, with different formal systems, computational techniques, and conceptual frameworks being used for different problems.

    Looking at the trajectories of other more or less similar domains, we can see pretty clear points where a conceptual synthesis emerged, transforming the field from a welter of techniques to a single coherent domain that is then improved and expanded.

    The necessary conditions for a synthesis are probably already in place, so it could occur at any time. Unfortunately, these syntheses seem to depend on (or at least involve) unique individuals who make the conceptual breakthrough. This makes the timing and form of the synthesis hard to predict.

    When a synthesis has been achieved, it will probably already be embodied in software, and this will allow it to spread extremely quickly. However it will still need to be locally adapted and integrated, and this will slow down its impact to a more normal human scale.

    The big exception to this scenario is that the synthesis could possibly arise through reflexive use of statistical modeling, and this reflexive use could be embodied in the software. In this case the new software could help with its own adoption, and all bets would be off.

    Historical parallels

    I’m inclined to compare our trajectory to the historical process that led to the differential and integral calculus. First we had a long tradition of paradoxes and special case solutions, from Zeno (about 450 BC) to the many specific methods based on infinitesimals up through the mid 1600s. Then in succession we got Barrow, Newton and Leibnitz. Newton was amazing but it seems pretty clear that the necessary synthesis would have taken place without him.

    But at that point we were nowhere near done. Barrow, Newton and Leibnitz had found a general formalism for problems of change, but it still wasn’t on a sound mathematical footing, and we had to figure out how to apply it to specific situations case by case. I think it’s reasonable to say that it wasn’t until Hamilton’s work published in 1835 that we had a full synthesis for classical physics (which proved extensible to quantum mechanics and relativity).

    So depending on how you count, the development of the calculus took around 250 years. We now seem to be at the point in our trajectory just prior to Barrow: lots of examples and some decent formal techniques, but no unified conceptual framework. Luckily, we seem to be moving considerably faster.

    One problem for this analogy is that I can’t see any deep history for statistical modeling comparable to the deep history of the calculus beginning with Zeno’s paradox.

    Perhaps a better historical parallel in some ways is population biology, which seems to have crystallized rather abruptly, with very few if any roots prior to about 1800. Darwin’s ideas were conceptually clear but mathematically informal, and the current formal treatment was established by Fisher in about 1920, and has been developed more or less incrementally since. So in this case, it took about 55 years for a synthesis to emerge after the basic issues were widely appreciated due to Darwin’s work.

    Similarly, statistical modeling as a rough conceptual framework crystallized fairly abruptly with the work of the PDP Research Group in the 1980s. There were of course many prior examples of specific statistical learning or computing mechanisms, going back at least to the early 1960s, but as far as I know there was no research program attempting use statistical methods for general learning and cognition. The papers of the PDP Group provided excellent motivation for the new direction, and specific techniques for some interesting problems, but they fell far short of a general characterization of the whole range of statistical modeling problems, much less a comprehensive framework for solving such problems.

    Fisher obviously benefited from the advances in mathematical technique, compared with the founders of calculus. We are benefiting from further advances in mathematics, but even more important, statistical modeling depends on computer support, to the point where we can’t study it without computer experiments. Quite likely the rapid crystallization of the basic ideas depended on rapid growth in the availability and power of computers.

    So it is reasonable to hope that we can move from problems to synthesis in statistical modeling more quickly than in previous examples. If we take the PDP Group as the beginning of the process, we have already been working on the problems for twenty years.

    The good news is that we do seem to be ready for a synthesis. We have a vast array of statistical modeling methods that work more or less well in different domains. Computer power is more than adequate to support huge amounts of experimentation. Sources of almost unlimited amounts of data are available and are growing rapidly.

    On the other hand, an unfortunate implication of these historical parallels is that our synthesis may well depend on one or more unique individuals. Newton, Hamilton and Fisher were prodigies. The ability to move from a mass of overlapping problems and partial solutions to a unified conceptual system that meets both formal and practical goals seems to involve much more than incremental improvement.

    Adoption of the synthesis

    Once a synthesis is created, how quickly will it affect us? Historically it has taken decades for a radical synthesis to percolate into broad use. Dissemination of innovations requires reproducing the innovation, and it is hard to “copy” new ideas from mind to mind. They can easily be reproduced in print, but abstract and unfamiliar ideas are very hard for most readers to absorb from a printed page.

    However, the situation for a statistical modeling synthesis is probably very different from our historical examples. Ideas in science and technology are often reproduced by “black boxing” them — building equipment that embodies them and then manufacturing that equipment. Depending on how quickly and cheaply the equipment can be manufactured, the ideas can diffuse quite rapidly.

    Development of new ideas in statistical modeling depends on computer experiments. Thus when a synthesis is developed, it will exist at least partly in the form of software tools — already “black boxed” in other words. These tools can be replicated and distributed at almost zero cost and infinite speed.

    So there is a good chance that when we do achieve a statistical modeling synthesis, “black boxes” that embody it will become available everywhere almost immediately. Initially these will only be useful to current statistical modeling researchers and software developers in related areas. The rate of adoption of the synthesis will be limited by the rate at which these black boxes can be adapted to local circumstances, integrated with existing software, and extended to new problems. This make adoption of the synthesis comparable to the spread of other innovations through the internet. However the increase in capability of systems will be far more dramatic than with prior innovations, and the size of subsequent innovations will be increased by the synthesis.

    There is another, more radical possibility. A statistical modeling synthesis could be developed reflexively — that is, statistical modeling could be an essential tool in developing the synthesis itself. In that case the black boxes would potentially be able to support or guide their own adaptation, integration and extension, and the synthesis would change our world much more abruptly. I think this scenario currently is quite unlikely because none of the existing applications of statistical modeling lends themselves to this sort of reflexive use. It gets more likely the more we use statistical modeling in our development environments.

    A reflexive synthesis has such major implications that it deserves careful consideration even if it seems unlikely.

    What’s missing in Second Life?

    Most of the features of Second Life enumerated in my previous post appear to be implemented adequately, if not brilliantly. However SL has three fairly glaring deficiencies, which are probably related.

    • Lack of external connections
      This one is simple. SL currently has no way to embed live web content or other connections to internet resources.

      The UI challenges could be finessed by starting with script-controlled web embedding. This alone would be enough to enable all kinds of neat uses. Full interactive web support may or may not be really necessary.

      More generally, SL should provide a general way to embed bi-directional external data connections, again via scripting. This would make possible “widgets” that could do all kinds of useful things.

      This change would bring SL much closer to a general platform for online activities.

    • Lack of reflexive abilities
      This requires bigger changes to the current SL model. Right now no one outside of Linden Labs can build higher level tools for creating and modifying prims. Thus a huge range of potential enhancements to the environment are impossible. For SL to become a true platform this is an essential change.

      The existing script-level data structures aren’t a good fit for higher level manipulation. However clean ways of describing and manipulating 3D content are available in open source implementations with friendly licenses. Similarly the existing scripting language is limited but cleaner, more powerful languages are easily available.

      My guess is that the big issue is that being able to create and modify prims opens the door to huge security and gray goo problems. Note that if this is a fundamental limitation, it implies that an SL type environment can never become a general online platform. In any case, these problems are the focus of my third bullet below.

    • Lack of a robust model of behavioral constraints
      Right now, SL has a variety of behavioral constraints, based on ownership, scripting limitations, administrator controls, etc. These make possible property (in some sense), a degree of privacy, tolerable freedom from griefing in most cases, rather porous defenses against gray goo, etc.

      On the other hand, these behavioral constraints seem ad hoc, require continuing and often urgent interventions by Linden staff, and frequently fail in inconvenient or damaging ways.

      If SL is going to become a general platform, this is one thing it needs that can’t be copied from some existing good example: a unified model of behavioral constraint that enables a socially viable world, and that doesn’t require continual tweaks and/or expensive staff support.

    Because the need for a good model of behavioral constraints is so central, and so difficult, it deserves some further elaboration.

    To enable a socially viable world, such a model has to support something close to the kind of ownership and control we currently expect of private property, and the level of personal security we normally have in our daily lives. Note that neither of these is perfect or seamless, nor are they free — we not only pay taxes for police and military security, we pay for locksmiths, title insurance, car registrations, etc. On the other hand, we don’t have to continually fiddle with security mechanisms or install security upgrades.

    I can think of three further design requirements on any such model:

    • Manageable by users and developers
      Typical computer security models are very easy to screw up. Putting the wrong permissions on some file, forgetting to update some configuration information, etc. can open up a world of hurt. Most users and casual developers won’t accept this level of fragility. So any viable model has to be relatively easy to understand and to manage reliably, at least for the things ordinary users want to do.
    • Enforceable by servers alone
      Clients can and will be hacked. The behavior constrained by the security model has to be mediated by the server. This is in tension with the desire to off-load as much to the client as possible, to reduce latency and make the whole system more scalable.
    • (Almost) fully automated
      Human maintenance and enforcement will always be required, but the amount and level of administrative support must be very low relative to the level of user activity. This is essential if we want to create a platform that can move toward the ubiquity and low cost of the web.

    Obviously, creating a new behavioral constraint model that meets all these requirements will be very difficult. I do not think it will be impossible, in fact I think we’ll have one within ten years, maybe less.

    However I think it behooves us to recognize that the lack of such a model, and the difficulty of creating one, imposes very severe limitations on the potential of virtual worlds for the time being.

    What’s special about Second Life?

    Second Life is getting worked over by the folks at Terra Nova, and also the folks at Many2Many, and I’m sure in lots of other places. I’m not a Second Lifer myself (and neither are they, as far as I can tell). Also I’m not interested in most of the issues they’re discussing. But Second Life is clearly an interesting phenomenon, at least for the moment, and so I ask myself: What is SL introducing that is new and will survive, either in SL or through imitation in other virtual worlds? And once we roughly understand that, how easy will it be to duplicate or go beyond the success of Second Life, especially in more open systems?

    Based on reading various accounts, and talking to people with a little experience of Second Life, below are my lists of what’s new in SL, what’s integrated in an interesting way, what is typical of MMOs in general, and what emerges in SL more than other MMOs. Quite likely I’ve gotten some of these wrong and missed significant points, so I welcome correction and extension.

    • Unusual or unique in Second Life:
      • Internal economy with micro-payments, plus currency exchange
      • In-game crafting of objects, including 3D modeling and scripting
      • Highly customizable avatars, including movement scripting
      • In-game crafting of avatar customizations, scripts and clothes
      • Client-server support for “dynamic” world model, which requires different mechanisms than the more pre-built worlds of most MMOs
    • Newly integrated in Second Life:
      • Streaming audio for performances
      • Imported graphics, streaming video?
      • Users buy hosting for parts of the environment
    • Similar to other MMO environments:
      • 3D experience with landscape, avatars, buildings, objects, etc.
      • Scripted objects (but letting users script is unusual or unique)
      • Large scale geography
      • Property “ownership”, sales, etc.
      • Chat
      • Social activities and social structures
    • Emergent in Second Life more than other MMOs:
      • Complex user-built landscapes
      • Businesses based on user-built objects
      • Complex economics
      • Complex social organization

    Several of the things that are currently unique to Second Life are natural extensions of existing technology, including in-game crafting and scripting, customizable avatars, and the dynamic world model. Crafting and scripting can probably be implemented much better than they are in SL, using existing open source languages and 3D modeling techniques.

    Other aspects of Second Life, however, depend on a critical mass of motivated users. The economic model, including micro-payments, and the creation of a diverse environment and economy, depend on a fairly large population, investing considerable effort over a reasonable period. This dependence on scale and long term investment will make these aspects of SL hard to duplicate or surpass, especially through relatively fragmented efforts.

    Why programmers understand abstractions better than philosophers

    In an interesting post Joel on Software discusses many examples of specific “leaky abstractions”, and how our daily work as software developers requires us to understand, not just the abstractions we work with, but the underlying mechanisms that maintain them (and that fail in some cases).

    I’m sorry to say that in my experience, philosophers tend to treat abstractions as though they behave as defined, and tend to ignore the actual mechanisms (typically made out of human cognition and social interaction) by which those abstractions are maintained.

    As a result, they don’t seem to have good conceptual tools for dealing with the inevitable “leakiness” of all abstractions. Of course an implicit point of Joel’s article is that our abilities to maintain abstractions allow us to ignore this leakiness most of the time — and some disciplines, such as mathematics, for example, have suppressed the leaks very well. However I think we could find ways in which even the best understood mathematical abstractions leak, though I won’t argue that point here. It would be interesting to rank disciplines by how well they manage the leakiness of their abstractions.

    Philosophy has a different relationship to leaky abstractions than most disciplines, because it is mostly about abstractions (rather than mainly about the things the abstractions describe). The inherent leakiness of abstractions raises substantive issues throughout philosophy. It can’t be regarded as a “boundary problem” that can be ignored in “normal” situations, as it can in most disciplines (except during rough transitions). Note that this need to pay explicit attention to mechanisms of abstraction also applies to computer systems design — good system design has to manage leakiness, and must accept that it cannot be eliminated. This is true for the same reason — system design is about abstractions, and only indirectly about the things those abstractions describe.