文明規模での Hamming
Richard Hamming のシステム工学原則：システム全体を最適化せよ、個々のコンポーネントを最適化するな。孤立して最適化されたコンポーネントは、他のコンポーネントと共有するインターフェースを破壊し、システム全体のパフォーマンスを低下させる。
彼はこの原則を研究チーム、プログラミング言語、教育設計に適用した。この原則はスケールする。Russell Ballestrini はそれをインフラそのものに適用した。
Russell Ballestrini は unturf.com を設立し、時間差を「3日前」のようなフレーズに人間化する Python ライブラリ ago を書いた。彼はそれをオープンソースとして公開した。パブリックドメイン。このライブラリは彼が管理しないプラットフォーム上で動作する。彼がメンテナンスをやめても、フォークが引き継ぐ。コードは彼の存在を必要としない。
彼のパーマコンピュータ・マニフェスト：永続し、自己修復し、コミュニティに奉仕し続けるインフラ。家賃を搾取することなく運営される。知的・社会的資本を、運用することの副産物として育む。利益を必要としないため、ビジネスモデルを必要としない。
パーマコンピュータ設計の主要な特性：
1. コードは作者より長く存続する — パブリックドメインまたはオープンソースとして公開されたソフトウェアは、個人の寿命を超えて存続する。作者が関心を失っても、コミュニティが継続できる。
2. インフラは構築者より長く存続する — 他の人がフォークし、修正し、元の設計者の関与なしに継続できるように設計されたシステム。
3. プラットフォーム税なし — 取引からのレント抽出はゼロ。交換におけるO(N²)の摩擦課金もない。インフラは各インタラクションから価値を抽出しない。
4. プログレッシブエンハンスメント — JavaScriptなしで動作し、特定のブラウザなしで動作し、特定のクライアントなしで動作する。機能がプレゼンテーションを駆動し、コンテンツがアクセスを駆動する。
対比：一つのチームが作成したAWS Lambda関数。ドキュメントなしで、独自のランタイム内で、独自のAPIの背後で動作し、そのチームが料金を支払っている間のみトラフィックを処理する。チームが解散すると、関数は消滅する。計算は構築されたのではなく、借りられたものだった。
作者より長く存続するコード
Russell Ballestrini が ago を書きました。彼はもうメンテナンスしていないかもしれません。コードは動き続けます。
プラットフォーム税：O(N²)摩擦
プラットフォーム税：交換レイヤーにおけるすべての取引から抽出されるレント。マーケットプレイスは各取引の15〜30%を取ります。決済プロセッサは2.9% + $0.30を取ります。クラウドプロバイダは各APIコールに対して課金します。これらの手数料はどれも新たに生み出された価値を表すものではなく、取引からの抽出を表しています。
小規模では：見えない。N=1,000,000件の取引では：プラットフォームは膨大な準備金を蓄積する一方、貢献者は比例して少なくなる。O(N²)の定式化は、プラットフォーム手数料が複合する場合に適用されます：マーケットプレイス内のプラットフォーム上のコントラクターは、決済プロセッサの中で3層のレントを支払います。
Permacomputerインフラは自らのレイヤーからプラットフォーム税を排除します。無料のコンピュート、無料のコード実行。インフラはトランザクションごとに課金しません。価値は手数料なしで流れます。
これはインフラにコストがかからないという意味ではありません。コストモデルが利用量に比例して参加者から搾取しないという意味です。オープンソースソフトウェアを実行するサーバーには電力コストがかかりますが、そのコストはトランザクションごとに累積しません。
Hammingのシステム論：システムの目的は、それが実際にすることであり、言っていることではない。「買い手と売り手を繋ぐ」と言いながらトランザクションごとに30%を徴収する取引レイヤー：その振る舞いが示す目的はレント抽出である。接続はサービスであり、抽出はビジネスモデルである。
コンテンツを床に、インタラクティビティを天井に
Hammingは教えた：コンポーネントが優雅に故障するようにシステムを設計せよ。すべてのコンポーネントが完璧に機能することに依存するシステムは、常に故障する。冗長性、フォールバック経路、劣化しても機能するモードが、システムの寿命を延ばす。
Capability-driven presentationはこれをソフトウェアインターフェースに適用する。参考：russell.ballestrini.net/capability-driven-presentation/
原則：まずコンテンツを提供し、capabilityで強化する。ページは、特定の閲覧者capabilityを必要とせずにコンテンツを提供しなければならない。JavaScriptは豊かにする：リアルタイム更新、自動拡張テキストエリア、スムーズなナビゲーション、チャットインターフェース。JavaScriptは門番ではない：JavaScriptを削除してもコンテンツが消えてはならない。
実践におけるパターン：
- <noscript>ブロックはJS依存のUI（チャットボタン、自動展開コントロール）を非表示にする
- サーバーレンダリングされたHTMLがレッスンコンテンツ全体を保持する
- フォームはJSが利用できない場合、標準的なHTTP POSTで送信される
- チャット強化: コンテンツはページ到着と同時に表示され、JS対応の閲覧者にはインタラクティブなチャットオーバーレイが表示されます
この原則はウェブページを超えて適用されます。CLIツールはGUIなしで動作する必要があります。APIはクライアントSDKなしで動作する必要があります。インフラストラクチャは特定のベンダーの独自拡張なしで動作する必要があります。ケイパビリティはすべてのレイヤーでプレゼンテーションを駆動します。
JSゲート設計との対比: コンテンツはJavaScriptのfetch呼び出しで読み込まれます。JavaScriptなしでは、ユーザーはスピナーまたは空のページを見ることになります。コンテンツが存在するにはJavaScriptが必要です。アクセシビリティの床が崩れました。
パーマコンピュータにとってこれが重要な理由: JavaScriptなしで動作するページは、Lynx、スクリーンリーダー、アーカイブクローラー、JavaScriptにセキュリティ制限がある環境、2010年のブラウザ、まだ構築されていないブラウザでも動作します。コンテンツは閲覧者の前提を超越します。
JSゲート設計: 違反
シナリオ: 開発者がすべてのレッスンコンテンツをJavaScriptのfetch呼び出しで読み込む学習プラットフォームを構築します。JavaScriptなしでは、ページにスピナーが表示されます。開発者は「もう誰もJavaScriptなしでウェブを使わない」と主張します。
レイヤー全体にわたるGraceful Degradation
Capability-driven presentationは、システムのあらゆるレイヤーに適用されます:
- Web tier: JavaScriptなしのコンテンツ。JavaScriptによる拡張。
- API tier: クライアントライブラリなしで機能する。クライアントライブラリは利便性を提供するものであり、アクセスを提供するものではありません。
- Infrastructure tier: 特定のベンダーの拡張機能なしで運用可能。ベンダー拡張機能は、パフォーマンスや利便性を提供するものであり、コア機能を提供するものではありません。
- Data tier: 独自のツールなしで読み取り可能。標準フォーマット（CSV、JSON、SQLite）により、データを書き込んだアプリケーションなしでアクセス可能になります。
各レイヤーには床がある：能力の前提なしで提供されるもの。各レイヤーには天井がある：能力が存在するときに可能になるもの。
パーマコンピュータの設計目標：何十年も保つ床。2004年のSQLiteデータベースは移行なしで2024年のSQLiteで開く。2004年のPostgreSQLダンプは2024年のPostgreSQLでインポートできる。2004年のJSONファイルは2024年の任意の言語でパースできる。これらの形式は床を維持してきた。
対比：2004年のFlashアプリケーション。天井は高かった（リッチな対話性）。床はプロプライエタリなプラグインを必要とした。Adobeが2020年にFlashを終了したとき、床は崩壊した。Flash形式で保存されたすべてのコンテンツは、特別な努力なしにはどのビューアーからもアクセスできなくなった。
どんぐりを植える
Hamming: 「どんぐりを植えれば、オークの木は見えない。」1995年の彼の講義は、2025年もなお教え続けている。彼の学生たちは自らの研究を続けている。その伝達は彼を超えて広がっていく。
Russell Ballestriniの枠組み：来年死ぬかもしれないと思ってコードを公開せよ。誰でも継続できるようにライセンスを設定せよ。将来のメンテナーが原作者なしで理解できるようにAPIを設計せよ。読者があなたに会ったことがないかのようにコミットメッセージを書け。
MOADパイプラインはこのように動作する。上流のマージはすべて、正規ソースに修正を埋め込む。重力のように伝播する：依存関係を更新する下流のフォークは、その修正を継承する。パッチ作成者は忘れ去られても、パッチは生き残る。
対比：企業が保守するプロプライエタリなSDK。後方互換性は、企業が非推奨スケジュールを管理しているため維持される。企業が解散すると、下流のすべての依存関係が同時に破綻する。SDKの存続は、企業の存続に依存していた。
コミュニティによって維持されるオープンなプロトコルは、無期限に存続する。HTTPは、それを最初に実装したすべての企業を凌駕してきた。TCP/IPは、最初の設計者たちを凌駕してきた。Gitは、数十の競合するバージョン管理システムを凌駕してきた。プロトコルはインフラとなり、インフラは不可視となり、不可視のインフラは永続的になる。
コードが作者を凌駕する理由：
- 寛容またはパブリックドメインのライセンス（継続に対する法的障壁がない）
- 包括的なドキュメント（将来のメンテナーが元の作成者を必要としない）
- 公開CIで合格するテストスイート（新しいメンテナーが自分の変更を検証できる）
- 安定版リリースのタグ付け（下流プロジェクトが既知の安定バージョンを固定できる）
- メンテナー募集のお知らせの公開（作成者がいなくなる前にコミュニティが支援を必要としていることを知る）
- アーキテクチャのドキュメント化（将来の再構築者が構造的な決定を理解できる）
- コードを個人アカウントではなく組織に移管（GitHubの個人名前空間リポジトリはアカウントとともに消滅するが、組織リポジトリは存続する）
優雅な引き継ぎの設計
シナリオ：あなたは50の下流プロジェクトが依存するライブラリをメンテナンスしている。6ヶ月後にメンテナンスを停止する予定である。
MOADの重力：アップストリームマージが重要な理由
MOADパイプラインは「アップストリームマージ」で終了します。そのステップは詳しく検討する価値があります。
フォークにのみ適用されたパッチは、そのフォークを助けます。アップストリームにマージされたパッチは重力のように伝播します：依存関係を更新するすべてのダウンストリームプロジェクトは、知らないうちに修正を継承します。エコシステムは通常のバージョンアップデートという副作用として自己修復します。
重力による伝播には3つの条件が必要です：(1) 修正が正規ソースにマージされること、(2) 正規ソースがリリースを公開すること、(3) ダウンストリームプロジェクトが依存関係のピンを更新すること。各条件には人間の行動が必要です。重力は自動的ではなく、有効化されるものです。
対比：公開はされたが上流に提出されていないセキュリティ修正。修正を知っているフォークは手動でパッチを適用できる。修正を知らないフォークは脆弱なままになる。重力は働かず、手動伝播のみ。知識は存在するが、広がらない。
MOADパイプラインの約束：修正された欠陥はすべて上流PRとして提出される。すべての上流PRはマージまで追跡される。上流PRなしの公開は半分の修正に過ぎない。
Hammingの枠組みが当てはまる：「どんぐりを植える」。PRがどんぐりである。上流マージが重力伝播の時計を始動させる。パッチ作成者は忘れ去られるかもしれないが、修正は正統なブランチに残る。
結び：Infrastructure as Gift
ハミングはドングリを植えた。彼の講義は彼の死後も残る。彼の符号は彼の死後も残る。彼の学生が教える。
ラッセル・バレストリーニはドングリを植えた。彼の ago ライブラリは彼がいなくても動作する。彼の permacomputer エッセイは回覧される。Unhomeschool は彼が設計したインフラ上で動作する。
MOAD パイプラインはドングリを植える。上流の各マージは、正規ソースに修正の種をまく。重力がそれを伝播する。元のパッチ作成者を知らないプロジェクトの将来バージョンも、今日行われた作業のおかげで、よりクリーンなコードを実行する。
Permacomputer の設計は利他主義ではない。それは優れたエンジニアリングである。作成者の存続を必要とするシステムは脆弱である。作成者を凌駕するよう設計されたシステムは堅牢である。この設計選択は構築時に余分なコストを必要としない。必要なのは意図だけである。
インフラを贈り物として：感傷的な意味ではなく、技術的な意味で。贈り物は与えた後も残る。寛容なライセンスの下のコード、次のメンテナのために書かれたドキュメント、パブリック CI で実行されるテスト：これらは技術的な意味での贈り物である。それらは残る。それらは成長する。それらは凌駕する。
ハミングが学生に最後に投げかけた問い：「20 年後に意味を持つことを、あなたは何をしているか？」Permacomputer の答え：床に置いたものは何であれ。