Book review: The Omnivore’s Dilemma

The Omnivore’s Dilemma: A Natural History of Four Meals
Author: Michael Pollan
Publisher: Penguin Press
Publication date: May, 2006
http://www.michaelpollan.com/omnivore.php

If you are looking for a truly thought-provoking book to give you new insights into the nature of open source software, I recommend reading The Omnivore’s Dilemma: A Natural History of Four Meals, by Michael Pollan.

Last year, Michael Pollan gave a guest lecture at the University of Chapel Hill. He began by saying:

“Socrates said that the unexamined life is not worth living, but what about the unexamined meal? Industrial agriculture depends upon us not examining–in fact, knowing as little as possible about–the food we eat.”

As somebody who thinks the unexamined code is not worth running, this got my attention.

Pollan’s device for examining his meals (four in all) is to trace the ingredients back to the point at which they were in their natural living state, and then examine how they came to be grown where they were grown, the way they were grown, how they came to be harvested, processed, transported, and ultimately prepared for him to consume them. As you might guess, some meals were easier to trace and account for than others, but each examination led to all sorts of new insights that gave me a deeper understanding of a subject I thought I knew well: open source software.

Pollan’s first meal, a selection of McDonald’s burgers, chicken nuggets, fries, milk shakes and/or sodas for the family, led him to the cornfields of the midwest. Why corn? Because, as measured by a mass pectrometer at UC Berkeley, the amount of corn-derived carbon in his meal was:

soda		        100%
milk shake	         78%
salad dressing	         65%
chicken nuggets	         56%
cheeseburger	         52%
french fries	         23%

On average, 75% of the carbon that Americans now consume from food comes from corn. How did we become such “children of the corn”? Because corn is the “perfect” industrial crop–with a large amount of fertilizer, it can be grown rapidly and predictably. Harvested by large machines, it can be processed and transformed into an incredibly wide variety of marketable items, (most edible, some not), and it comes with built-in DRM of sorts. First generation corn (grown from seeds you buy) will be marginally economically productive, but 2nd generation corn (grown from seeds you save from your crop) will have such poor yield as to make it not worth planting.

The more I understood about corn and its profound role in the industrialization of agriculture, the more I thought about the efforts to industrialize the software production process as described by Fred Brooks in The Mythical Man Month. The Mythical Man Month gets its name from the observation that “the bearing of a child requires nine months regardless of how many women are assigned the task.” It was an attempt to explain why, no matter how many smart people had been assigned to the OS/360 project, adding more smart people, paradoxically, only made it later. Industrial logic failed softare in its first and grandest entry,
and it continues to fail miserably today.

The more I learned how much one is simply not permitted to know about the industrial food supply, the more I thought about how little one is allowed to know about proprietary software. There are other ways in which the proprietary agricultural production model mirrors the proprietary software industry, but I’ll leave it to you to find them.

My favorite section of the book was the third section entitled “Grass”. The Grass chapter talks about Polyface Farms the absolute opposite of industrial agriculture. For starters, when Pollan called to order a chicken so he could see what all the fuss was about, Joel Salatin said “you can buy a chicken, but I’m not going to ship it to you. If you want it, you come to my farm and pick them up yourself.” Pollan was mortified at the idea of flying all the way to Virginia from California just to pick up some groceries, so he decided to spend a week at the farm and spend some face time with them (both the farmer and the chicken). By becoming a farm hand, Pollan made the leap from user to contributor.

When Pollan arrived at Polyface, he told Salatin “I want to understand how you do all this” (produce beef, pork, chicken, and eggs at six times the yield rates of 100 years ago with no external petroleum, pesticide, irrigation, hormonal, antibiotic, or fertilizer inputs) to which Salatin replied “Actually, the animals do all the work.” Which was not 100% true: the Sun and the rain did their part as well. What Salatin did, which was brilliant, was to design his farm around the growing of grass, and to stock it with animals that first improved the quality and quantity of the grass he could grow, and second, produced marketable food for humans by eating said grass (or other crops he grew on the farm). The success of the farm can be measured in many ways, but one measure is the rate at which Salatin is accumulating, rather than depleting, his topsoil.

The contrast between the industrial farmer and the sustainable, natural farmer mirrors what I see as a key difference between proprietary and open source software development methods. The industrial farmer makes the bet that with enough technology they can sufficiently control nature to make it predictable and discretionary. By applying 10 million metric tons of fertilizer per year to what is already some of the most fertile soil in the world, industrial farmers in the American midwest can force the production of commodity corn to grow from the same plot of land season after season. Ironically, this product is not consumable by man or beast without further technical processing. For beast, it must be combined with a pharmacopoeia of antibiotics and other medicines to keep grass-eating cows from getting too sick when eating corn, and for humans, the corn must be modified from cattlefeed to something more palatable (like corn syrup). Ignored in this equation are the “external” costs–irrigation and water table depletion, topsoil depletion, destruction of Gulf Coast fish stocks–or the health consequences that also require additional technological interventions.

By contrast, the sustainable farmer works with nature, orchestrating what happens naturally. True, the sustainable farmer cannot produce arbitrary crops at arbitrary times in arbitrary locations, but what they can grow is, remarkably enough, actually edible without extraordinary rendition.

The proprietary software developer must, from start to finish, take responsibility for every line of code that is specified, written, tested, integrated, tested, documented, shipped, and supported. This sounds like an ideal industrial optimization problem, but like the industrial farmer, every separation from nature–the collaborative, cooperative, nature of humankind–requires an additional technological intervention. Such interventions divert creativity from the problem to be solved to the industrial support system, and judging by numerous independent quality findings, seldom produces anything that can be used without further cost and risk.

By contrast, the open source developer is free to focus on the problem as they see it, where they see it, and are not confined to solving it in a particular way or within a particular business model. Rather than competing with, replacing, or trying to disable these natural production systems, a sustainable approach to open source software is to recognize the productive capacity of these developers and then to orchestrate and monitor the progress of their projects, to harvest the code when it is ready for market, and to keep sharing seeds so that there will always be a new harvest in the next season.

In February of 2001, Tim O’Reilly suggested that open standards, open source, and the free sharing of ideas was akin to the topsoil from which innovation flowers. Now, six years later, a more complete analogy of a sustainable (and satisfying) model of software development based on sustainable agriculture can be understood. The natural quality and robustness of open source software is something we should expect from 6,000 years of cultivational experience.

Consider this passage near the end of the book:

“Imagine for a moment if we once again knew, strictly as a matter of course, these few unremarkable things: What it is we’re eating. Where it came from. How it found its way to our table. And what, in a true accounting, it really cost.”

This is precisely what open source is can provide. A healthy choice for building the technology society of the 21st century.

This entry was posted by Michael Tiemann on Wednesday, March 14th, 2007 at 3:08 am and is filed under review. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.