Hamming at Civilization Scale
Richard Hamming's systems engineering principle: optimize the system, not the components. A component optimized in isolation degrades system performance by breaking interfaces it shares with other components.
He applied this to research teams, to programming languages, to educational design. The principle scales. Russell Ballestrini applied it to infrastructure itself.
Russell Ballestrini founded unturf.com & wrote ago, a Python library that humanizes time deltas into phrases like 'three days ago'. He published it as open source. Public domain. The library runs on platforms he does not control. When he stops maintaining it, a fork picks it up. The code does not require him to exist.
His permacomputer manifesto: infrastructure that persists, self-heals, & serves its community without extracting rent. It grows intellectual & social capital as a byproduct of running. It does not need a business model because it does not need to profit from each interaction.
Key properties of permacomputer design:
1. Code outlasts authors — software published as public domain or open source survives the individual. The author can stop caring; the community can continue.
2. Infrastructure outlasts builders — systems designed so others can fork, fix, & continue without the original designer's involvement.
3. No platform tax — zero rent extraction from transactions. No O(N²) friction charge on exchanges. The infrastructure does not extract value from each interaction.
4. Progressive enhancement — works without JavaScript, works without a specific browser, works without a specific client. Capability drives presentation; content drives access.
Contrast: AWS Lambda functions authored by one team, without documentation, run in a proprietary runtime, behind a proprietary API, serving traffic only as long as that team pays the bill. When the team dissolves, the function disappears. The computation was rented, not built.
Code That Outlasts Its Author
Russell Ballestrini wrote ago. He may no longer maintain it. The code runs on.
Platform Tax: O(N²) Friction
Platform tax: rent extracted from every transaction in an exchange layer. A marketplace takes 15-30% of each exchange. A payment processor takes 2.9% + $0.30. A cloud provider charges for each API call. None of these fees represent new value created; they represent extraction from the exchange.
At small scale: invisible. At N=1,000,000 transactions: the platform accumulates a vast reserve while contributors accumulate proportionally less. The O(N²) formulation applies when platform fees compound: a contractor on a platform inside a marketplace inside a payment processor pays three layers of rent.
Permacomputer infrastructure eliminates platform tax from its own layer. Free compute, free code execution. The infrastructure does not charge per transaction. Value flows through without a toll.
This does not mean infrastructure costs nothing. It means the cost model does not scale with usage in a way that extracts from participants. A server running open-source software costs electricity; that cost does not compound per transaction.
Hamming on systems: the purpose of a system is what it does, not what it says it does. An exchange layer that says 'we connect buyers and sellers' but charges 30% per transaction: its purpose, as revealed by its behavior, is rent extraction. The connection is the service; the extraction is the business model.
Content as Floor, Interactivity as Ceiling
Hamming taught: design systems so components fail gracefully. A system that depends on every component functioning perfectly fails constantly. Redundancy, fallback paths, & degraded-but-functional modes extend system lifespan.
Capability-driven presentation applies this to software interfaces. Reference: russell.ballestrini.net/capability-driven-presentation/
The principle: serve content first, enhance with capability. A page must deliver its content without requiring any specific viewer capability. JavaScript enriches: real-time updates, auto-growing text areas, smooth navigation, chat interfaces. JavaScript does not gate: removing JavaScript must not remove the content.
Pattern in practice:
- <noscript> blocks hide JS-dependent UI (chat buttons, auto-expand controls)
- Server-rendered HTML carries the full lesson content
- Forms submit via standard HTTP POST when JS unavailable
- Chat enhancement: content arrives with the page, interactive chat overlays for JS-capable viewers
This principle extends beyond web pages. CLI tools should work without a GUI. APIs should work without a client SDK. Infrastructure should work without a specific vendor's proprietary extensions. Capability drives presentation at every layer.
Contrast with JS-gated design: content loads via JavaScript fetch calls. Without JavaScript, the user sees a spinner or an empty page. The content requires JavaScript to exist. The floor dropped below accessibility.
Why this matters for permacomputer: a page that works without JavaScript works in Lynx, in a screen reader, in an archival crawler, in an environment where JavaScript has a security restriction, in a browser from 2010, in a browser that has not been built yet. The content outlasts the viewer assumptions.
JS-Gated Design: The Violation
Scenario: a developer builds a learning platform where all lesson content loads via JavaScript fetch calls. Without JavaScript, the page displays a spinner. The developer argues: 'Nobody uses the web without JavaScript anymore.'
Graceful Degradation Across Layers
Capability-driven presentation applies at every layer of a system:
- Web tier: content without JavaScript. Enhancement with JavaScript.
- API tier: functional without a client library. Client libraries provide convenience, not access.
- Infrastructure tier: operational without a specific vendor's extensions. Vendor extensions provide performance or convenience, not core function.
- Data tier: readable without proprietary tooling. Standard formats (CSV, JSON, SQLite) allow access without the application that wrote the data.
Each layer has a floor: what it delivers without capability assumptions. Each layer has a ceiling: what it enables when capabilities are present.
The permacomputer design goal: floors that hold for decades. An SQLite database from 2004 opens in 2024 SQLite without migration. A PostgreSQL dump from 2004 imports in 2024 PostgreSQL. A JSON file from 2004 parses in any language from 2024. These formats maintained their floors.
Contrast: a 2004 Flash application. The ceiling was high (rich interactivity). The floor required a proprietary plugin. When Adobe killed Flash in 2020, the floor collapsed. All content stored in Flash format became inaccessible to any viewer without special effort.
Planting Acorns
Hamming: 'You plant acorns, you don't see oaks.' His lectures from 1995 continue teaching in 2025. His students continue their own work. The transmission extends beyond him.
Russell Ballestrini's framing: publish code as if you will die next year. License it so anyone can continue it. Design APIs so future maintainers can understand them without the original author. Write commit messages as if the reader never met you.
A MOAD pipeline operates this way. Every upstream merge embeds a fix in the canonical source. Gravity propagates it: downstream forks that update their dependencies inherit the fix. The patcher may be forgotten; the patch survives.
Contrast: a proprietary SDK maintained by a company. Backward compatibility holds because the company controls the deprecation schedule. When the company dissolves, every downstream dependency breaks simultaneously. The survival of the SDK required the survival of the company.
An open protocol maintained by a community lives indefinitely. HTTP has outlasted every company that originally implemented it. TCP/IP has outlasted its original designers. Git has outlasted dozens of competing version control systems. The protocol becomes infrastructure; infrastructure becomes invisible; invisible infrastructure becomes permanent.
What makes code outlast its author:
- Permissive or public-domain license (no legal barrier to continuation)
- Comprehensive documentation (future maintainers do not need the original author)
- Passing test suite with public CI (new maintainers can verify their changes)
- Stable release tagged (downstream can pin a known-good version)
- Maintainer-wanted notice published (community knows help is needed before the author disappears)
- Architecture documented (structural decisions visible to future rebuilders)
- Code transferred to an organization rather than a personal account (GitHub person-namespace repos die with accounts; org repos persist)
Designing a Graceful Handoff
Scenario: you maintain a library that 50 downstream projects depend on. You plan to stop maintaining it in 6 months.
MOAD Gravity: Why Upstream Merges Matter
A MOAD pipeline ends at 'upstream merge.' That step deserves examination.
A patch applied only to a fork helps that fork. A patch merged upstream propagates by gravity: every downstream project that updates its dependency inherits the fix without knowing it. The ecosystem heals itself as a side effect of normal version bumps.
Gravity propagation requires three conditions: (1) the fix merges into the canonical source; (2) the canonical source publishes a release; (3) downstream projects update their dependency pins. Each condition requires human action. Gravity is not automatic; it is enabled.
Contrast: a security fix disclosed publicly but not submitted upstream. Forks that know about it can patch manually. Forks that do not know about it remain vulnerable. No gravity; only manual propagation. The knowledge exists; it does not spread.
A MOAD pipeline's commitment: every defect fixed gets an upstream PR. Every upstream PR gets followed through merge. Disclosure without upstream PR is half a patch.
Hamming's framing applies: 'plant the acorn.' The PR is the acorn. The upstream merge starts the clock on gravity propagation. The patcher may be forgotten; the fix survives in the canonical branch.
Closing: Infrastructure as Gift
Hamming planted acorns. His lectures survive him. His codes survive him. His students teach.
Russell Ballestrini planted acorns. His ago library runs without him. His permacomputer essays circulate. Unhomeschool runs on the infrastructure he designed.
A MOAD pipeline plants acorns. Each upstream merge seeds a fix into the canonical source. Gravity propagates it. Future versions of projects that have never heard of the original patcher run cleaner code because of work done today.
Permacomputer design is not altruism. It is good engineering. A system that requires its creator to persist is fragile. A system designed to outlast its creator is robust. The design choice costs nothing extra at construction time; it requires only intention.
Infrastructure as gift: not in the sentimental sense, but in the technical sense. A gift persists after the giving. Code under a permissive license, documentation written for the next maintainer, tests that run in public CI: these are gifts in the technical sense. They persist. They grow. They outlast.
Hamming's final question to his students: 'What are you doing that will matter in 20 years?' The permacomputer answer: anything you put on a floor that holds.