Хэмминг в масштабе цивилизации
Принцип системной инженерии Ричарда Хэмминга: оптимизируйте систему, а не компоненты. Компонент, оптимизированный изолированно, ухудшает производительность системы, нарушая интерфейсы, которые он разделяет с другими компонентами.
Он применял этот принцип к исследовательским командам, языкам программирования и образовательному дизайну. Принцип масштабируется. Расселл Баллестрини применил его к самой инфраструктуре.
Расселл Баллестрини основал unturf.com и написал ago — библиотеку Python, которая преобразует временные интервалы в фразы вроде «три дня назад». Он опубликовал её как открытый исходный код. Общественное достояние. Библиотека работает на платформах, которые он не контролирует. Когда он перестанет её поддерживать, её подхватит форк. Код не требует его существования.
Его манифест пермакомпьютера: инфраструктура, которая сохраняется, самовосстанавливается и служит сообществу, не взимая ренту. Она наращивает интеллектуальный и социальный капитал как побочный продукт своей работы. Ей не нужна бизнес-модель, потому что она не должна извлекать прибыль из каждого взаимодействия.
Ключевые свойства дизайна пермакомпьютера:
1. Код переживает авторов — ПО, опубликованное как общественное достояние или с открытым исходным кодом, переживает отдельного человека. Автор может перестать заботиться; сообщество может продолжить.
2. Инфраструктура переживает строителей — системы спроектированы так, чтобы другие могли форкать, исправлять и продолжать без участия оригинального разработчика.
3. Без платформенного налога — нулевое извлечение ренты из транзакций. Нет O(N²) трения при обменах. Инфраструктура не извлекает ценность из каждого взаимодействия.
4. Прогрессивное улучшение — работает без JavaScript, работает без конкретного браузера, работает без конкретного клиента. Возможности определяют представление; контент определяет доступ.
Контраст: AWS Lambda-функции, написанные одной командой, без документации, выполняемые в проприетарной среде, за проприетарным API, обслуживающие трафик только пока команда оплачивает счета. Когда команда распадается, функция исчезает. Вычисления были арендованы, а не построены.
Код, который переживает своего автора
Рассел Баллестрини написал ago. Возможно, он больше не поддерживает его. Код продолжает работать.
Платформенный налог: O(N²) трение
Платформенный налог: рента, взимаемая с каждой транзакции в слое обмена. Маркетплейс берёт 15–30 % с каждой сделки. Платёжный процессор — 2,9 % + $0,30. Облачный провайдер взимает плату за каждый API-вызов. Ни одна из этих комиссий не создаёт новой ценности; они представляют собой извлечение из обмена.
В малом масштабе: незаметно. При N=1 000 000 транзакций: платформа накапливает огромный резерв, а участники получают пропорционально меньше. Формулировка O(N²) применяется, когда платформенные комиссии накладываются: подрядчик на платформе внутри маркетплейса внутри платёжного процессора платит три уровня ренты.
Инфраструктура пермакомпьютера устраняет платформенный налог на своём уровне. Бесплатные вычисления, бесплатное выполнение кода. Инфраструктура не взимает плату за транзакцию. Ценность проходит сквозь без пошлины.
Это не означает, что инфраструктура ничего не стоит. Это означает, что модель затрат не масштабируется с использованием таким образом, чтобы извлекать ценность у участников. Сервер, работающий на открытом ПО, потребляет электричество; эта стоимость не умножается на каждую транзакцию.
Хэмминг о системах: назначение системы — это то, что она делает, а не то, что она говорит, что делает. Слой обмена, который заявляет «мы соединяем покупателей и продавцов», но взимает 30 % за транзакцию: его назначение, раскрываемое поведением, — извлечение ренты. Соединение — это услуга; извлечение — это бизнес-модель.
Контент как пол, интерактивность как потолок
Хэмминг учил: проектируйте системы так, чтобы компоненты отказывали изящно. Система, зависящая от безупречной работы каждого компонента, постоянно выходит из строя. Резервирование, резервные пути и режимы с ограниченной, но работоспособной функциональностью продлевают срок службы системы.
Capability-driven presentation применяет этот принцип к программным интерфейсам. Ссылка: russell.ballestrini.net/capability-driven-presentation/
Принцип: сначала предоставляйте контент, затем улучшайте его с помощью возможностей. Страница должна выдавать свой контент без необходимости в каких-либо конкретных возможностях зрителя. JavaScript обогащает: обновления в реальном времени, автоматически расширяющиеся текстовые области, плавная навигация, чат-интерфейсы. JavaScript не ограничивает: удаление JavaScript не должно удалять контент.
Паттерн на практике:
- блоки <noscript> скрывают UI, зависящий от JS (кнопки чата, элементы управления авто-расширением)
- HTML, отрисованный на сервере, содержит полный контент урока
- формы отправляются через стандартный HTTP POST при недоступности JS
- Улучшение чата: контент загружается вместе со страницей, интерактивный чат накладывается для зрителей с поддержкой JS
Этот принцип выходит за рамки веб-страниц. CLI-инструменты должны работать без GUI. API должны работать без клиентского SDK. Инфраструктура должна работать без проприетарных расширений конкретного вендора. Возможности определяют представление на каждом уровне.
Контраст с JS-gated дизайном: контент загружается через JavaScript fetch-запросы. Без JavaScript пользователь видит спиннер или пустую страницу. Контент требует JavaScript для существования. Порог доступности опустился ниже.
Почему это важно для пермакомпьютера: страница, работающая без JavaScript, работает в Lynx, в экранном ридере, в архивном краулере, в среде с ограничениями безопасности JavaScript, в браузере 2010 года, в браузере, который ещё не создан. Контент переживает предположения о просмотрщике.
JS-Gated Design: Нарушение
Сценарий: разработчик создаёт учебную платформу, где весь контент уроков загружается через JavaScript fetch-запросы. Без JavaScript страница показывает спиннер. Разработчик утверждает: «Никто больше не использует веб без JavaScript».
Graceful Degradation Across Layers
Capability-driven presentation применяется на каждом уровне системы:
- Web tier: контент без JavaScript. Улучшение с помощью JavaScript.
- API tier: функциональность без клиентской библиотеки. Клиентские библиотеки обеспечивают удобство, а не доступ.
- Infrastructure tier: работоспособность без расширений конкретного вендора. Расширения вендора обеспечивают производительность или удобство, а не базовую функциональность.
- Data tier: читаемость без проприетарных инструментов. Стандартные форматы (CSV, JSON, SQLite) позволяют получить доступ без приложения, которое записало данные.
У каждого слоя есть пол: то, что он предоставляет без предположений о возможностях. У каждого слоя есть потолок: то, что он позволяет при наличии возможностей.
Цель дизайна пермакомпьютера: полы, которые держатся десятилетиями. База данных SQLite 2004 года открывается в SQLite 2024 без миграции. Дамп PostgreSQL 2004 года импортируется в PostgreSQL 2024. JSON-файл 2004 года парсится любым языком 2024 года. Эти форматы сохранили свои полы.
Контраст: приложение на Flash 2004 года. Потолок был высоким (богатая интерактивность). Пол требовал проприетарного плагина. Когда Adobe прекратила поддержку Flash в 2020 году, пол обрушился. Весь контент, хранившийся в формате Flash, стал недоступен для любого просмотрщика без специальных усилий.
Посадка желудей
Хэмминг: «Вы сажаете жёлуди, а не видите дубы». Его лекции 1995 года продолжают обучать в 2025-м. Его студенты продолжают собственную работу. Передача знаний выходит за пределы его самого.
Формулировка Рассела Баллестрини: публикуйте код так, будто умрёте в следующем году. Лицензируйте его так, чтобы любой мог продолжить. Проектируйте API так, чтобы будущие сопровождающие могли понять их без оригинального автора. Пишите сообщения коммитов так, будто читатель никогда не встречался с вами.
Конвейер MOAD работает именно так. Каждое слияние upstream встраивает исправление в канонический источник. Гравитация распространяет его: downstream-форки, обновляющие зависимости, наследуют исправление. Автор патча может быть забыт; сам патч сохранится.
Контраст: проприетарный SDK, поддерживаемый компанией. Обратная совместимость держится, потому что компания контролирует график устаревания. Когда компания прекращает существование, все downstream-зависимости ломаются одновременно. Выживание SDK требовало выживания компании.
Открытый протокол, поддерживаемый сообществом, живёт неопределённо долго. HTTP пережил каждую компанию, которая изначально его реализовывала. TCP/IP пережил своих первоначальных разработчиков. Git пережил десятки конкурирующих систем контроля версий. Протокол становится инфраструктурой; инфраструктура становится невидимой; невидимая инфраструктура становится постоянной.
Что позволяет коду пережить своего автора:
- Разрешительная или общественная лицензия (нет юридических препятствий для продолжения)
- Полная документация (будущим сопровождающим не потребуется оригинальный автор)
- Прохождение тестового набора с публичным CI (новые сопровождающие могут проверить свои изменения)
- Стабильный релиз с тегом (нижестоящие проекты могут зафиксировать проверенную версию)
- Опубликовано уведомление о поиске сопровождающего (сообщество знает, что нужна помощь, прежде чем автор исчезнет)
- Документирована архитектура (структурные решения видны будущим переработчикам)
- Код передан в организацию, а не на личный аккаунт (репозитории в персональном пространстве GitHub умирают вместе с аккаунтами; репозитории организаций сохраняются)
Проектирование плавной передачи
Сценарий: вы сопровождаете библиотеку, от которой зависят 50 нижестоящих проектов. Вы планируете прекратить её сопровождение через 6 месяцев.
Гравитация MOAD: почему важно слияние в upstream
Пайплайн MOAD заканчивается на шаге «слияние в upstream». Этот шаг заслуживает отдельного рассмотрения.
Патч, применённый только в форке, помогает только этому форку. Патч, слитый в upstream, распространяется по гравитации: каждый downstream-проект, обновляющий свою зависимость, получает исправление автоматически, даже не зная об этом. Экосистема исцеляется сама собой как побочный эффект обычного обновления версий.
Гравитационное распространение требует трёх условий: (1) исправление сливается в канонический источник; (2) канонический источник публикует релиз; (3) downstream-проекты обновляют пин зависимостей. Каждое условие требует человеческого действия. Гравитация не работает автоматически — она включается.
Контраст: исправление уязвимости раскрыто публично, но не отправлено в upstream. Форки, которые знают о нём, могут применить патч вручную. Форки, которые не знают о нём, остаются уязвимыми. Нет гравитации; только ручное распространение. Знание существует; оно не распространяется.
Обязательство MOAD-пайплайна: каждое исправление дефекта сопровождается PR в upstream. Каждый PR в upstream доводится до мёржа. Раскрытие без PR в upstream — это половина патча.
Применяется формулировка Хэмминга: «посади жёлудь». PR — это жёлудь. Мёрж в upstream запускает часы гравитационного распространения. Автор патча может быть забыт; исправление сохранится в канонической ветке.
Заключение: Инфраструктура как дар
Хэмминг сажал жёлуди. Его лекции переживают его. Его коды переживают его. Его студенты преподают.
Рассел Баллестрини сажал жёлуди. Его библиотека ago работает без него. Его эссе о пермакомпьютерах распространяются. Unhomeschool работает на инфраструктуре, которую он спроектировал.
Пайплайн MOAD сажает жёлуди. Каждый upstream merge засеивает исправление в канонический источник. Гравитация распространяет его. Будущие версии проектов, которые никогда не слышали об оригинальном патчере, запускают более чистый код благодаря работе, выполненной сегодня.
Дизайн пермакомпьютера — это не альтруизм. Это хорошая инженерия. Система, требующая постоянного присутствия своего создателя, хрупка. Система, спроектированная так, чтобы пережить своего создателя, устойчива. Этот выбор дизайна не требует дополнительных затрат на этапе создания; он требует лишь намерения.
Инфраструктура как дар: не в сентиментальном смысле, а в техническом. Дар сохраняется после дарения. Код под разрешительной лицензией, документация, написанная для следующего сопровождающего, тесты, запускаемые в публичном CI: это дары в техническом смысле. Они сохраняются. Они растут. Они переживают.
Последний вопрос Хэмминга своим студентам: «Что вы делаете такого, что будет иметь значение через 20 лет?» Ответ пермакомпьютера: всё, что вы размещаете на полу, который держит.