Геммінг у масштабі цивілізації
Принцип системної інженерії Річарда Геммінга: оптимізуйте систему, а не компоненти. Компонент, оптимізований ізольовано, погіршує продуктивність системи, руйнуючи інтерфейси, які він поділяє з іншими компонентами.
Він застосовував це до дослідницьких команд, мов програмування та освітнього дизайну. Принцип масштабується. Russell Ballestrini застосував його до самої інфраструктури.
Russell Ballestrini заснував unturf.com і написав ago — бібліотеку Python, яка перетворює часові інтервали на фрази на кшталт «три дні тому». Він опублікував її як відкритий код. Суспільне надбання. Бібліотека працює на платформах, які він не контролює. Коли він припиняє її підтримувати, форк підхоплює її. Код не потребує його існування.
Його маніфест пермакомутера: інфраструктура, яка зберігається, самовідновлюється та служить своїй спільноті, не стягуючи орендної плати. Вона нарощує інтелектуальний та соціальний капітал як побічний продукт роботи. Їй не потрібна бізнес-модель, бо вона не потребує прибутку від кожної взаємодії.
Ключові властивості дизайну пермакомутера:
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²) застосовується, коли комісії платформи накопичуються: підрядник на платформі всередині майданчика всередині платіжного процесора сплачує три рівні ренти.
Інфраструктура пермакомп’ютера усуває платформний податок на власному рівні. Безкоштовні обчислення, безкоштовне виконання коду. Інфраструктура не стягує плату за транзакцію. Цінність проходить крізь неї без мита.
Це не означає, що інфраструктура нічого не коштує. Це означає, що модель витрат не масштабується з використанням таким чином, щоб витягувати ресурси з учасників. Сервер, на якому працює відкрите програмне забезпечення, споживає електроенергію; ця вартість не множиться на кожну транзакцію.
Гаммінг про системи: мета системи — це те, що вона робить, а не те, що вона заявляє. Шар обміну, який каже «ми з’єднуємо покупців і продавців», але стягує 30 % за транзакцію: його мета, як показує поведінка, — це вилучення ренти. З’єднання — це послуга; вилучення — це бізнес-модель.
Контент як підлога, Інтерактивність як стеля
Геммінг вчив: проєктуйте системи так, щоб компоненти відмовляли граційно. Система, яка залежить від бездоганної роботи кожного компонента, постійно виходить з ладу. Резервування, резервні шляхи та режими з обмеженою, але функціональною роботою подовжують термін служби системи.
Capability-driven presentation застосовує цей принцип до програмних інтерфейсів. Джерело: russell.ballestrini.net/capability-driven-presentation/
Принцип: спочатку подавайте контент, а потім покращуйте його за допомогою можливостей. Сторінка повинна видавати свій контент без потреби в будь-яких конкретних можливостях переглядача. JavaScript збагачує: оновлення в реальному часі, автоматично розширювані текстові поля, плавна навігація, чат-інтерфейси. JavaScript не блокує: видалення JavaScript не повинно видаляти контент.
Патерн на практиці:
- блоки <noscript> приховують UI, що залежить від JS (кнопки чату, елементи автоматичного розгортання)
- HTML, відрендерений на сервері, містить повний зміст уроку
- форми надсилаються через стандартний HTTP POST, коли JS недоступний
- Покращення чату: контент надходить разом зі сторінкою, інтерактивний чат накладається для переглядачів із підтримкою JS
Цей принцип виходить за межі веб-сторінок. CLI-інструменти повинні працювати без графічного інтерфейсу. API повинні працювати без клієнтського SDK. Інфраструктура повинна працювати без пропрієтарних розширень конкретного постачальника. Можливості визначають презентацію на кожному рівні.
Контраст із дизайном, залежним від JS: контент завантажується через JavaScript-запити fetch. Без JavaScript користувач бачить спінер або порожню сторінку. Контент потребує JavaScript для існування. Межа опустилася нижче доступності.
Чому це важливо для пермакомп’ютера: сторінка, яка працює без JavaScript, працює в Lynx, у програмі зчитування з екрана, в архівному краулері, в середовищі з обмеженнями безпеки JavaScript, у браузері 2010 року, у браузері, який ще не створено. Контент переживає припущення переглядача.
JS-залежний дизайн: порушення
Сценарій: розробник створює навчальну платформу, де весь навчальний контент завантажується через JavaScript-запити fetch. Без JavaScript сторінка показує спінер. Розробник стверджує: «Ніхто більше не користується вебом без JavaScript».
Graceful Degradation Across Layers
Презентація, керована можливостями, застосовується на кожному рівні системи:
- Веб-рівень: контент без JavaScript. Покращення за допомогою JavaScript.
- Рівень API: функціональність без клієнтської бібліотеки. Клієнтські бібліотеки забезпечують зручність, а не доступ.
- Рівень інфраструктури: працездатність без розширень конкретного постачальника. Розширення постачальника забезпечують продуктивність або зручність, а не основну функцію.
- Рівень даних: читабельність без пропрієтарних інструментів. Стандартні формати (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: кожна виправлена вада супроводжується upstream PR. Кожен upstream PR супроводжується до злиття. Оприлюднення без upstream PR — це половинчасте виправлення.
Застосовується формулювання Геммінга: «посадити жолудь». PR — це жолудь. Злиття в upstream запускає відлік гравітаційного поширення. Автор виправлення може бути забутий; виправлення залишається в канонічній гілці.
Закриття: Інфраструктура як дар
Геммінґ садив жолуді. Його лекції переживають його. Його коди переживають його. Його студенти викладають.
Рассел Баллестріні садив жолуді. Його бібліотека ago працює без нього. Його есе про пермакомп’ютер поширюються. Unhomeschool працює на інфраструктурі, яку він спроєктував.
Конвеєр MOAD садить жолуді. Кожен upstream merge засіває виправлення в канонічне джерело. Гравітація поширює його. Майбутні версії проєктів, які ніколи не чули про оригінального патчера, запускають чистіший код завдяки роботі, виконаній сьогодні.
Дизайн пермакомп’ютера — це не альтруїзм. Це хороша інженерія. Система, яка потребує, щоб її творець існував, є крихкою. Система, спроєктована так, щоб пережити свого творця, є надійною. Вибір дизайну не потребує додаткових витрат на етапі створення; він вимагає лише наміру.
Інфраструктура як дар: не в сентиментальному сенсі, а в технічному. Дар зберігається після дарування. Код під дозвільною ліцензією, документація, написана для наступного супроводжувача, тести, що запускаються в публічному CI: це дари в технічному сенсі. Вони зберігаються. Вони ростуть. Вони переживають.
Останнє запитання Геммінґа до своїх студентів: «Що ви робите такого, що матиме значення через 20 років?» Відповідь пермакомп’ютера: усе, що ви покладете на підлогу, яка тримається.