The Neoclassical Lemonade Stand and Other Confusions

If you don’t normally read the comment section, I encourage you to click through to yesterday’s post about “clean slate” thinking. I particularly want to endorse this perspective from Jed Harris:

I think it turns on on whether one gives more weight to models or observations. The modernist architects and planners had very strong models, and ignored or had contempt for actually existing social reality, so they didn’t work very hard to observe or understand it. They didn’t feel any obligation to test their theories in the small before trying to apply them in the large. They didn’t have to listen to “the little people” who didn’t understand the theory and only knew what they personally observed.

This is exactly right, and it succinctly makes a point that I’ve tried to make in the past. Jed goes on to argue that “the most serious threat from theory run amok at the expense of observation seems to be neo-classical economics.” Prompting a thoughtful response from some other readers, especially Jess.

I think I share Jed’s sentiment but wouldn’t quite put it this way. Models by themselves aren’t threats to anything. What matters is how models are used. The neoclassical model, like all models, is an approximation of reality, and it fits some problems better than others.

To pick a silly example at random, a few weeks ago there was some online chatter about this article where Terry Savage chastises some little girls for running a lemonade stand where the product was available for free:

“You must charge something for the lemonade,” I explained. “That’s the whole point of a lemonade stand. You figure out your costs — how much the lemonade costs, and the cups — and then you charge a little more than what it costs you, so you can make money. Then you can buy more stuff, and make more lemonade, and sell it and make more money.”

This is, of course, ridiculous. There’s no reason all lemonade stands need to be for-profit enterprises. Kids learn a variety of lessons from lemonade stands. Charging might teach valuable lessons about budgeting and self-sufficiency, but giving lemonade away can teach equally valuable lessons about generosity and public service. Savage apparently doesn’t care what the girls’ parents might have hoped their kids would get out of the experience. The mere fact that the girls were failing to conform to the neoclassical model of homo economicus was enough to condemn their activity.

That’s a frivolous example, to be sure, but the same mixture of intellectual laziness and arrogance crops up in more serious contexts. I’ve written before about this Richard Epstein column where he criticizes the free software movement for, basically, failing to conform to the assumptions of the neoclassical model:

The open source movement shares many features with a workers’ commune, and is likely to fail for the same reason: it cannot scale up to meet its own successes. To see the long-term difficulty, imagine a commune entirely owned by its original workers who share pro rata in its increases in value. The system might work well in the early days when the workforce remains fixed. But what happens when a given worker wants to quit? Does that worker receive in cash or kind his share of the gain in value during the period of his employment? If not, then the run-up in value during his period of employment will be gobbled up by his successor – a recipe for immense resentment. Yet that danger can be ducked only by creating a capital structure that gives present employees separable interests in either debt or equity in exchange for their contributions to the company.

This passage bears no relationship to reality. Free software projects scale up just fine without “a capital structure that gives present employees separable interests in either debt or equity.” Contributors are not employees or shareholders. The inability to cash out does not, in fact, generate “immense resentment.” And Epstein could have learned all of this pretty easily if he’d talked to a few people in the free software community before writing his column. But why let facts clutter up a perfectly good theory?

I sometimes get the same vibe when I talk to legal academics about software patents. Many software patent supporters in academia hail from the law-and-economics tradition, and they have a coherent neoclassical story about how patents create incentives for innovation in the software industry. The problem with the story is that it’s utterly at odds with how the software industry actually works. And they don’t seem to understand (or maybe they don’t care) why software patents have generated so much opposition among the people who are actually responsible for producing software innovation.

A humble, bottom-up thinker takes this kind of disconnect between economic theory and lived reality as a reason to re-think the theory—or even better, to learn about a domain before trying to theorize about it. A top-down, “clean slate” thinker takes it as evidence that he needs to do a better job of explaining the theory to the uninitiated or, at worst, to tweak a few of the implementation details.

This “clean slate” vice isn’t unique to neoclassical thinkers by any means; all ideologies are prone to similar excesses. But I think Jed is right that abuses of neoclassical theory are pretty common. Precisely because the neoclassical model is such a powerful way to explain certain social phenomena, a lot of people have convinced themselves that it can be usefully applied to every problem. This isn’t a bad parlor game, but it’s a terrible way to do public policy.

This entry was posted in Uncategorized. Bookmark the permalink.

16 Responses to The Neoclassical Lemonade Stand and Other Confusions

  1. joe says:

    I wonder, though, about software patents and start-ups… that is, are patent-focused software start-ups more likely to be innovative and have the resources (VC funds) required to translate those innovations into real business models? I just don’t have my finger on that literature, but I’d hope someone is studying that. ::)

  2. Michael says:

    So economic modellers haven’t succesfully come to terms with the open source phenomenon? Why should we listen to people who are 20 years out of date?

  3. cm says:

    I think it is fair to say that it is not ‘economic modelers’ per se who haven’t come to terms with the dynamics of innovation, rather it is a particularly backwards subset thereof. There is good work on patent thickets, open source, DMCA/digital protection and much else.

  4. Tim Worstall says:

    I agree that some neo-classicists haven’t managed to come to terms with open source as yet….but the tweak to the model that is required to do so is really pretty simple.

    Stop assuming that rewards have to be monetary. Assume instead that rewards can be in such things as status (which, given that humans are both social animals and ones in which status influences all sorts of things, not least mating opportunities, really isn’t all that much of a stretch). Another way of putting it, assume that homo economicus attempts to maximise utility, not money, and neo-classical theories work just fine with open source.

  5. Meg says:

    Even patent-focused startups are more likely to be put out of business by a patent troll than they are to profit from their patents. Essentially, software patents are at the wrong level of abstraction for software. Software is more like literature than it is like engineering, but patents are able to be vague enough that Dances With Wolves would be able to keep Avatar from being made with a well-place lawsuit.

    The only people who make money off of patents in software are the people who don’t try to make money any other way. They are a barrier to entry, because even if they don’t apply the money spent defending against them or unfairly licencing them is a huge barrier to entry. Venture capitalists look for a lack of patent liability; this can be expressed in holding patents, but that is certainly not sufficient.

    Not to mention that the patent term is ridiculous for an industry where most technology if obsolete inside of five years. It essentially ties competition on the basis of quality or cost to variations in patent-ability. Inferior approaches become wide-spread because they are implemented with higher quality than the superior approaches, and superior solutions are discarded because they were mis-priced, rather than being picked up by someone able to produce a generic version.

    Software patents, at least, are a source of inefficiency and do not, in total, produce more innovation (http://www.researchoninnovation.org/patent.pdf and others). Patents are a hack that doesn’t do what we want; I wish the conversations could center around the intended goal (increase innovation) and not the particular method we had adopted 200 years ago to try to do this. In the last two hundred years, why have we not had any innovation in encouraging innovation?

  6. eightnine2718281828mu5 says:

    re open source…

    It’s not uncommon for open source projects to be started by bored engineers who have been told by management at their day jobs that they can’t work on any ‘cool’ projects because they lack experience in some arcane discipline. Open source provides them with a creative outlet, status (as mentioned above), and can be used to attract a more interesting position or lucrative offer from a future employer.

    addendum: On one side you have recent articles with management claiming that they’re having trouble finding high-skill talent and on the other hand you have high-skill talent claiming that there aren’t enough challenging projects.

  7. eightnine2718281828mu5 says:

    Meg: mod up

  8. Matt Rognlie says:

    I’m not sure that this is really a failure of neoclassical modeling. There is nothing inherent to the neoclassical paradigm that says open-source software won’t work. Indeed, it’s easy to imagine the rewarding feeling from being part of a vibrant and supportive programming community entering directly into a utility function, or the signal from writing particularly good software helping someone to get a good job later on, and hence providing a clear monetary reward. Basic economics also makes clear that to the extent open-source software is practical, it is a very good thing: it allows software and ideas contained in it to diffuse at zero marginal cost.

    I think that the neoclassical way of thinking gives us some good insights about the nature of open source software. Forgive me if this sounds too banal, but economically speaking, open source software should be common where the enjoyment or signaling value of writing software is relatively high compared with the cost of writing it. This tends to happen when a piece of software will have very wide use relative to the amount of time taken to write it, or when it’s important to a niche with a good sense of community. And indeed, as far as I can tell, this is where we see the most open source software being written. Meanwhile, we don’t see competitive open source attempts at implementing the tedious details of corporate accounting.

    I know virtually nothing about the economics of patents, but it still seems like even a basic neoclassical model would produce a result where patentability isn’t necessarily optimal. Suppose that inventors have a range of possible projects they can undertake, each with different returns. Patents increase the individual returns to each project, inducing inventors to pursue more projects, but decrease the externalities from the diffusion of ideas and techniques from each successful invention.

    From the perspective of social optimality, this could go either way. The ideal policy would allow patents only for the marginal projects that wouldn’t be completed without them, but since this is impossible in practice, the benefits from denying patents to the inframarginal cases could easily overwhelm the losses from a weakened incentive to innovate. And this result pops out of an extraordinarily simple neoclassical model! Considering the drawbacks of legal uncertainty, legal costs, patent hoarding, and so on only strengthens the case against software patents.

    I think the real story here is that many of the “Law and Economics” types who are inclined to comment on these issues just aren’t very good economists, relying mainly on half-assed price theory intuition that hasn’t moved a day beyond 1960. Epstein is a prime example.

  9. Jeremy Morlan says:

    It has occured to me that most lemonade stands are an exercises in charity. The parents usually foot the bill for the lemons, the glasses, and the stand. The only thing your teaching the child at this point is how to work in the service industry because all they are selling is their services.

    If you really wanted to teach your kid about business you would require them to take out a loan from you to buy they necessary items. They would have to write out a business plan showing that their lemonade stand would make money to pay you back. They would also have to give up a favorite toy for collateral. “Welcome to the REAL world kid.” you’d say as you peered over your Wall Street Journal.

  10. Matt:

    Again, I’m not criticizing neoclassical theory as such. I’m criticizing the attitude that knowledge of a theory is a substitute for careful study of the real world. If you study the real world carefully, you can probably find a way to adjust your theory to fit your observations.

    It’s easy to imagine the rewarding feeling from being part of a vibrant and supportive programming community entering directly into a utility function, or the signal from writing particularly good software helping someone to get a good job later on, and hence providing a clear monetary reward.

    I think there’s a lot of post-hoc reasoning going on here. Obviously, if the domain of possible utility functions is flexible enough, you’re going to be able to model any human behavior. But sticking “the rewarding feeling from being part of a vibrant and supportive programming community” into your utility function doesn’t really explain anything. You can’t use it to predict which other circumstances might give rise to phenomena like peer production, for example.

    If you’d asked an economist in 1990 to speculate on the viability of the Linux development model, I’ll bet you that the overwhelming majority of neoclassical theorists would have gotten it wrong. That’s not really their fault–most people, period, would have gotten it wrong–but it does suggest that economists should show some humility in trying to model social systems they don’t understand well.

  11. Jeremy: Exactly! Lemonade stands have never been genuinely independent businesses. So why is it better to have kids pretend they are?

  12. Matt Rognlie says:

    I think there’s a lot of post-hoc reasoning going on here. Obviously, if the domain of possible utility functions is flexible enough, you’re going to be able to model any human behavior. But sticking “the rewarding feeling from being part of a vibrant and supportive programming community” into your utility function doesn’t really explain anything. You can’t use it to predict which other circumstances might give rise to phenomena like peer production, for example.

    Sure. Attributing it all to a black-box utility function is a bit of a cop-out — although the alternative signaling explanation is very powerful and doesn’t involve tinkering around with the definition of utility, and for many open source projects you can also rationalize some participation through the personal benefits from bug-fixing, customization, and simply building a better product. I just wanted to point out that there’s no inherent inconsistency between the broad set of modeling principles underlying “neoclassical economics” and the existence of open-source software.

    I also still think that the neoclassical approach can be a good starting point for analyzing the issues you mention. One decent initial stab at this is here, where there are several good points like:

    “As to the tasks that may appeal to the open source community, one would expect that tasks such as those related to the operating systems and programming languages, whose natural audience is the community of programmers, would give rise to strong signaling incentives. (For instance, the use of Perl is largely restricted to system administrators.) By way of contrast, tasks aiming at helping the much-less-sophisticated end user–e.g., design of easy-to-use interfaces, technical support, and ensuring backward compatibility–usually provide lower signaling incentives.”

    Neoclassical economics can explain other varieties of open-source software as well. For instance, if you have corporations releasing parts of their software as open-source, you can interpret their behavior as a way to overcome the commitment problems inherent in selling technology with high switching costs. An open-source core helps to ensure that a future version of the company won’t screw over its customers by arbitrarily jacking up prices or doing something similarly malevolent, which makes customers more willing to buy today. Alternatively, if you’re in a business with substantial network effects, it can make sense to release one version of your software for free to make your ecosystem the standard, and then sell a higher-powered version of the software for a nonzero price to the most demanding users.

    All this doesn’t mean, of course, that people who deem themselves bearers of neoclassical wisdom will actually get these issues right. This is particularly true for a lot of “Law and Economics” gurus whose understanding of micro theory is very, very far from the research frontier. As you say, knowledge of a theory is never a substitute for study of the real world; all models abstract away from countless features of real markets, and empirical experience is necessary to determine which features are the essential ones to include. People who always base their decisions on a single kind of intuition will eventually be wrong. But neoclassical economics is still a really useful way to analyze these issues, despite the indiscretions of some of its cruder advocates.

  13. But neoclassical economics is still a really useful way to analyze these issues, despite the indiscretions of some of its cruder advocates.

    Completely agreed!

  14. Chris Brand says:

    @joe “I wonder, though, about software patents and start-ups…”
    There is some info in http://radar.oreilly.com/2010/07/why-software-startups-decide-t.html

  15. SamB says:

    Joseph Schumpeter, who these days seems have been adopted as a hero by the right wing, once observed:

    “If we economists were given less to wishful thinking and more to observation of facts, doubts would immediately arise as to the realistic virtues of a theory.”

    It is too bad that those who cite his theories on business cycles have not bothered to contemplate the insights expressed in that quote.

    SB

  16. Jess says:

    One might summarize the phenomenon thus: programmers contribute to open source/free software because of the value it has given them in the past, and that they expect it to give them in the future. A repeated game often has a different equilibrium than a corresponding one-off game would. But if that’s too neoclassical for you, consider that people are creatures of habit, and open source contribution is a continuously rewarding habit for many people.

    Actually, even that is too theoretical. There is only one reason anyone ever writes software: to scratch her own itch. Whether that itch is based on personal taste or employer mandate matters not. If I’d like to change how a program works, and the source code is available to me, I make the change. If I’d like to create a new project, I do. The only weighing involved in this decision is that of my time and effort vs. the value of the result TO ME. Programming qua programming is only altruistic when it is explicitly so, such as in work done for charities (even then, one is acting to further the charity’s interests, not those of the world in general).

    After deciding to create or modify software, the subsequent decision to release one’s work to the rest of the world as open source is another, much smaller decision. It costs very little to share computer code (nothing in terms of money, on the order of minutes in terms of time), which investment pales next to even minimal programming effort. Even so, most “improvements” that people make to OS/FS are never shared with the rest of the world. That is due to a combination of factors. It is somewhat inconvenient to contribute modifications back to most projects, especially if you haven’t already contributed other patches. Many improvements are local optimizations only, wouldn’t really be useful to the rest of the people using a particular project, and so even if contributed wouldn’t be merged into trunk. Some code violates (or might be construed to violate) patents, and is thus safe to use but not safe to distribute. Also, some programmers (or their employers) do have the myopic pennywise outlook that some common caricatures of neoclassicism would expect them to have, and won’t release their code for that reason. (We know this outlook exists, as exemplified by the cretins who complain when programmers release their work under a free license like the GPL rather than a mere open source license.) It is also remotely possible that a commercial enterprise might benefit in keeping its code private for competitive reasons, but those cases are vastly rarer than is commonly thought. Most businesses should pay more attention to customer service than to DB table normalization. (Some companies I’ve been at probably hide their code out of shame, though. b^)

    However, open source doesn’t rely on the joint efforts of all programmers in the world. It can thrive when only a tiny minority do “the right thing”. Each successful open source project (and in some sense these are probably outnumbered by the failures) is a ratchet, like Maxwell’s Demon come to life. Improvements are kept; regressions are obliterated without mercy. The quality of the software might change quickly or slowly, but it only goes in one direction. There are network effects, in that a successful project rewards those who contribute back to it: programmer A fixes bug 1, programmer B fixes bug 2, and both of them can use software that has both bugs fixed. The network effects act at a higher level, as well. The existence of Linux, gcc, perl, python, apache, etc. makes it easier to start new projects.

    I’ve blathered on long enough. RTFM!

Leave a Reply

Your email address will not be published.