I picked up Nadia Eghbal’s Working in Public: The Making and Maintenance of Open Source Software after listening to a long now talk of hers that I really enjoyed.
While I make a few minor / infrequent open source contributions here and there (and I am a prolific user / beneficiary of open source libraries as components of larger projects I work on), I didn’t read the book because have a particular interest in the topic of open source software in and of itself; rather, what interests me about open source software is that it’s a model for production (of a good – code, a particular kind of knowledge) in the commons.
Over the past few years, I’ve done a bunch of thinking and writing about intellectual property (mostly in my notebooks, I plan to publish more on this topic, but part iii of this essay touches on some of it). The main thing that strikes me about IP is there is a lot of motivation to create (“produce”) knowledge that I don’t think necessitates laws that grant monopoly rights on ideas to the individuals or corporations that happened to write them down first.
Because I’ve often thought about IP law from the perspective of a blueprint or patent or book or movie, I have mostly focused on the “production” side. (Of course there’s the “distribution” side, and people who disagree with me on IP law are quick to point out that profits / rents currently captured by IP holders would fall to distributors if we dispensed with some of the IP laws I find distasteful, but we’ll leave that aside for now.)
Eghbal’s book deals in depth with a 3rd cost of knowledge: the “maintenance of open source software.” While the open source software community does manage to (sometimes) cover these costs, it’s clearly far more challenging than motivating the production of new libraries.
If you’re interested in economics of the commons and alternatives to corporate capitalism, I highly recommend this book as a case study of an alternative model that is sort of working but clearly not perfectly.
Notes and quotes…
“Creation is an intrinsic motivator, maintenance usually requires extrinsic motivation.”
—@BALUPTON, via isaacs/github139
Benkler proposes that, in order to keep people motivated, tasks must be modular and granular:
When a project of any size is broken up into little pieces, each of which can be performed by an individual in a short amount of time, the motivation necessary to get any given individual to contribute need only be very small.116
Modularity refers to how the project is organized. Can it be broken into clear subcomponents, and do they fit easily back together? Granularity refers to the size of each module. It should be easy for anyone to jump in and complete the task without too much preexisting knowledge.
The modular, granular approach to software is embodied by the Unix philosophy, originating from the developers of the Unix operating system, which heavily influenced the design of open source software. As Doug McIlroy, one of its developers, counsels, “Write programs that do one thing and do it well. Write programs to work together.”117
Finally, Benkler suggests that low coordination costs are necessary to produce in a commons. In open source, coordination costs include both “quality control over the modules” (such as reviewing code) and “integrating the contributions into the finished product” (such as merging pull requests).118
“Living” code (or knowledge) vs archived or static. This got me thinking about what other forms of knowledge are living (government policy, for example, or even more than legislation, the whole judicial branch of government is much more “active.”)
Software doesn’t die, because someone out there—someone its developers may not even be aware of—will continue to use it. The author Neal Stephenson once described Unix as “not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic . . . Unix is known, loved, and understood by so many hackers that it can be re-created from scratch whenever someone needs it.”192 Code is not a product to be bought and sold so much as a living form of knowledge.
…
Code that runs in production, like C, is in active state. It’s a living organism, like a tree in a forest. It depends on other things, and other things depend on it to survive.
Software as public infrastructure:
Code, in active state, carries its value in its dependencies, or who else is currently using it. If I publish code and nobody uses it, it’s worth less than other code I’ve written that’s embedded in software used by millions. I may derive personal value from the other code I wrote, but its value to others is negligible.
In this way, software is comparable to public infrastructure, and similar valuation methodologies apply. Like code, infrastructure derives its value from its active dependencies, irrespective of the cost of its construction or maintenance.
Imagine we need to determine the value of two bridges. One costs $10 million to maintain, while another costs $100 million. We don’t assume the second bridge is worth more simply because it costs more to maintain. Instead, we would evaluate which bridge provides greater public value in order to determine which is worth maintaining. As economist Randall W. Eberts, who studies public systems, notes,
The cost of maintaining the existing infrastructure is not necessarily a measure of the value of transportation capital to the economy. Even if each previous investment decision that built the current capital stock was optimal when the project was constructed, the economy and population continue to change, which also changes the value of the infrastructure.243
Infrastructure is recursively defined by public consensus. It’s the set of structures that we’ve collectively decided are most valuable in any given moment, and, therefore, its boundaries and definitions are expected to change over time.
Dependencies don’t give us the full story, however. While some open source code might be widely used and depended upon, it might also be trivial to maintain or easy to replace, which affects its overall value.
- Read Nadia Eghbal’s Working in Public: The Making and Maintenance of Open Source Software