Architecture of Cooperation?
I've long been interested in the idea that the architecture of an enterprise can enable individual self-interest to add up into a public good. Napster -- ethical arguments bracketed -- is an example: If you want to swipe music from another Napster user's computer, in which by default that other user has made their music collection swipeable, you have to make your own music collection swipeable. Other examples include open source software production (A developer fixes a bug they personally need fixed; a company improves infrastructure it depends on), Wikipedia (People want to share expertise, correct errors, gain status, defend truth, or improve pages they care about), Stack Overflow (Programmers want answers, reputation, visibility, or proof of competence ), Open Street Map (A cyclist, driver, hiker, planner, or local resident wants better maps of places they know ), Creative Commons (Creators want attribution, reach, reputation, reuse, or downstream improvement).
chatGPT has this to say about architectures of cooperation:
The deeper pattern is that these systems don’t merely exhort people to cooperate. They change the environment so that the easiest useful action for the individual also leaves something behind for others.
The most important design moves are:
Modularity: break the public good into small pieces people can improve independently. This is why open source, Wikipedia, and OpenStreetMap work.
Persistent shared substrate: contributions accumulate somewhere durable: a codebase, article history, map database, knowledge graph, forum archive, or institutional routine.
Low transaction costs: contributing must be easier than negotiating permission every time.
Feedback and reputation: votes, citations, commit history, edit history, leaderboards, authorship, and visible impact turn contribution into status or practical reward.
Governance against decay: moderation, maintainers, norms, licenses, sanctions, peer review, or version control prevent spam, vandalism, enclosure, and free-riding.
Non-exclusive or share-alike outputs: the value produced remains available to many, instead of being captured entirely by one actor.
The canonical theoretical frame here is commons-based peer production, associated with Yochai Benkler. He contrasts it with markets and hierarchies: people self-select tasks in decentralized systems, and the outputs are shared as commons rather than controlled by a single owner. Benkler’s examples include free software, Wikipedia, and other networked collaboration systems.
One useful caveat: not all of these are “public goods” in the strict economics sense. Open knowledge and open-source code are close to pure public goods because they are non-rival once created. Irrigation systems, fisheries, and forests are common-pool resources because they can be depleted. Enterprise knowledge systems are often club goods inside a firm. But architecturally, they share the same cooperation logic: self-interested local acts are captured, structured, and made cumulative for collective benefit.
The linked article concentrates on the design of incentives:
This wasn’t a miracle of consensus or top-down diktat. It was a triumph of mechanism design: the science of designing rules that align self-interest with the collective good. What Montgomery County’s planners figured out for housing and preservation, mechanism designers now see as a general principle: If you can rewrite incentives, you can build cooperation almost anywhere.
The specific example cited is about land use: how can farmland be preserved when that land becomes valuable for other purposes?
It’s a familiar arithmetic on the urban fringe: Farmland can suddenly be worth more than anything it grows because developers will pay for space to build. That’s often the moment communities fracture, too — preservationists go up against developers, farmers against town planners. The story typically ends in a courtroom.
But what saved the orchard was an unusual set of rules. In 1980, Montgomery County planners had created what they called the Agricultural Reserve: a 93,000-acre expanse of farmland stretching along the Potomac River, protected not by fences or subsidies but by a new kind of property right: Transferable Development Rights, or TDRs.
The design of these regulations was an instance of what the authors of this article call "reverse game theory:"
Montgomery County’s TDRs were a real-world experiment in a theory being formalized in economic journals around the very same time: what economists call mechanism design, or reverse game theory.
“If you can rewrite incentives, you can build cooperation almost anywhere.”
Traditional game theory assumes that the rules are fixed — the chessboard is set, the laws codified — and asks how rational people will behave within them. It predicts outcomes based on existing incentives. Mechanism design turns that question around: It asks, for example, what rules should we write to get a different outcome — say, preservation and housing?
In 2005, I gave a TED talk about the need for an interdisciplinary study of cooperation. These architectural instances hint that one productive aspect of such study should be the design principles of institutions that enable self interest to produce public goods.