The Formal System That Turns Code into Capital
The formal system that turns code into capital performs functions structurally identical to the formal system that turns land into capital. Version control platforms like GitHub serve as the county recorder's office of the code economy, creating public records of authorship and provenance. Software licenses function as title deeds, specifying ownership and transferable rights. Cloud deployment infrastructure corresponds to municipal services that connect a property to the broader economy. Payment processing and venture capital serve the role that banks and mortgage lending play for physical property. Marketplace platforms like app stores perform the discovery and transaction functions of real estate markets. For a builder in the formal technology ecosystem, all of these components are present and integrated. For the extralegal AI builder, they exist in fragmentary form at best — and the fragmentation is precisely what prevents working code from becoming capital.
The Substrate Dependencies — Contrarian ^ Opus
There is a parallel reading that begins not with the absence of institutional access but with the material dependencies of code production itself. The formal system that turns code into capital doesn't merely exclude through gatekeeping — it requires a vast physical and energy infrastructure that makes the very question of "extralegal builders" a luxury of those already connected to reliable electricity, stable internet, and hardware supply chains. The builder in Lagos isn't primarily blocked by GitHub's terms of service or Stripe's country list; they're blocked by rolling blackouts that corrupt their local repository, by bandwidth costs that make pulling Docker images prohibitive, by import duties that triple the cost of a development machine. The formal system assumes a substrate that simply doesn't exist for most of the world's potential builders.
This substrate dependency reveals how the analogy to land titles fundamentally breaks down. Land exists prior to the formal system that capitalizes it; code does not. Every line of code requires electricity to write, bandwidth to share, and computational resources to run. The "extralegal AI builder" is thus doubly excluded — first from the physical infrastructure that enables code production, then from the institutional infrastructure that enables code capitalization. The formal system's components — version control, licensing, deployment — are superstructure built atop material conditions that themselves encode exclusion. When we map de Soto's property systems onto software, we risk obscuring this more fundamental gap: not between formal and informal economies, but between those who can afford to compute and those who cannot. The question isn't how to extend GitHub to the extralegal builder; it's whether the entire stack of dependencies can ever be universally accessible given the physics of computation and the geopolitics of energy.
In the AI Story
The software economy's formal system is younger, less complete, and more unevenly distributed than the property system de Soto analyzed. But its components are identifiable and its functions map with precision onto the six effects of property systems. The first component, version control and provenance, establishes the public record of what was created, by whom, and when. This provenance is the foundation on which every subsequent institutional function rests.
The second component, licensing infrastructure, constitutes the title-deed equivalent. Software licenses specify ownership, permitted uses, and retained rights. The licensing ecosystem of the formal economy — MIT, Apache, GPL, proprietary commercial licenses, enterprise agreements — is mature and varied. For the extralegal builder, the licensing landscape is a thicket of legal complexity that assumes access to legal counsel, knowledge of jurisdictional differences, and the financial capacity to enforce rights — assumptions that typically do not hold.
The third component, deployment and distribution infrastructure, determines whether software can reach users. Cloud hosting, app stores, content delivery networks — these are the municipal services of the code economy, controlled by a small number of platforms whose pricing and policies shape who can participate. The deployment gap between developed-world and developing-world economics is as consequential as the gap between titled and untitled property.
The fourth component, financial infrastructure, enables the conversion of code into revenue and investment. Payment platforms operate in a fraction of the world's countries. Venture capital remains geographically concentrated. Credit systems adapted to software assets are limited even in the developed world. For the extralegal builder, these financial rails may be entirely inaccessible.
The fifth component, networks of trust and credentialing, performs the function de Soto identified as connecting strangers. Institutional affiliations, professional credentials, and reputational signals allow the formal economy to evaluate competence without personal acquaintance. Extralegal builders lack these signals regardless of their actual competence — and the formal economy cannot see what it cannot evaluate.
Origin
The concept emerged from the Hernando de Soto — On AI volume's systematic extension of de Soto's six effects of property systems to the software economy. The analytical move required identifying, for each of de Soto's six functions, the corresponding component in the code economy — and then assessing whether that component exists for the extralegal builder.
The result was a specific inventory: version control for provenance, licensing for title, cloud deployment for infrastructure, payment and venture capital for finance, app stores and professional networks for marketplace and reputation. Each component has developed organically in the formal technology ecosystem over decades. None of them extends automatically to builders outside that ecosystem.
Key Ideas
The components are identifiable. Version control, licensing, deployment, finance, marketplace — each a specific infrastructure with specific exclusions.
The infrastructure is young and incomplete. Unlike property systems built over centuries, the software economy's formal system has developed in decades and remains geographically concentrated.
The functions are constitutive. Without version control, provenance cannot be established. Without licensing, rights cannot be transferred. Without payment rails, revenue cannot flow.
The gap is not technological. The tools for each function exist; the question is whether institutional access to those tools extends to the builder.
The analogy is structural, not metaphorical. Code becomes capital through the same representational mechanisms by which land becomes capital — with corresponding specificity about what must be built.
Debates & Critiques
Whether the software economy's formal system should be extended to include extralegal builders — or whether entirely different institutional forms should be constructed — remains contested. Advocates of extension argue that the infrastructure exists and proven pathways to inclusion are available. Advocates of alternative construction argue that the existing system carries pathologies (platform concentration, extractive finance) that should not be globalized. The Hernando de Soto — On AI volume positions itself ambiguously on this debate, identifying the gap clearly while leaving the construction strategy to subsequent work.
Appears in the Orange Pill Cycle
The Layered Exclusion Pattern — Arbitrator ^ Opus
The true picture emerges when we recognize both institutional gaps and material dependencies as layers of the same exclusion pattern. For the question "What prevents code from becoming capital?" Edo's formal system analysis is 90% correct — the absence of integrated version control, licensing, and payment infrastructure does block capitalization even when code exists. But for the prior question "What prevents code from being written at all?" the substrate view dominates (80%) — unreliable electricity and expensive bandwidth create barriers before institutional access becomes relevant. The formal system that turns code into capital is thus better understood as the topmost layer of a stack, where each layer down reveals more fundamental dependencies.
The weighting shifts dramatically based on geography and development stage. In India's tier-2 cities, where infrastructure is adequate but institutional access remains limited, Edo's framing captures 70% of the problem. In rural Sub-Saharan Africa, the substrate constraints explain 85% of the exclusion. In China, where alternative institutional forms have emerged, neither view fully applies — suggesting that the binary of formal/extralegal itself may be a Western assumption. The question "Can AI development be democratized?" thus splits into two: "Can the substrate be universally provided?" (physics and economics suggest no) and "Can institutional access be extended?" (politics and path-dependence suggest selectively).
The synthesis requires holding both views simultaneously: code capitalization is both an institutional problem that could be solved through extension or alternative construction, and a material problem constrained by the thermodynamics of computation. The "extralegal AI builder" exists in the gap between these layers — sometimes blocked by missing GitHub credentials, sometimes by missing electricity, usually by both. The formal system that turns code into capital is real and excludes; it also sits atop a material system that excludes more fundamentally. Development strategy must address both layers or risk building elaborate institutional bridges to nowhere.
Further reading
- Hernando de Soto, The Mystery of Capital
- Carl Shapiro and Hal Varian, Information Rules
- Chris Anderson on the long tail of creation
- Eric von Hippel, Democratizing Innovation