Что действительно входит в модель с открытым исходным кодом в первую очередь, так это проблема цепочки поставок.

Как только такая тема будет записана как «запечатанная», внимание будет обращено на чересчур драматичную картину. Более распространенные изменения в проекте менее драматичны: публичный источник загрузки становится нестабильным, начинают всплывать зеркала, определенная версия удаляется с полок, прерывается ритм непрерывных обновлений, и цепочка рассуждений в руках команды внезапно вынуждена держаться сама собой.

Хостинговый уровень первым берет на себя нагрузку

Чем больше обсуждается модель с открытым исходным кодом, тем легче ясно увидеть одну вещь: политики, экспортный контроль и правила платформы могут непосредственно затрагивать не взвешенные документы, которые были распространены, а публичный хостинг, онлайн-выводы, распространение версий и входы по умолчанию.

Это означает, что, хотя кажется, что путь «запечатан», на самом деле отрезанный путь часто оказывается самым легким путем. То, что раньше было простым процессом получения URL-адреса, настройки интерфейса хостинга и однажды его вызова, внезапно сменилось поиском изображения, добавлением подписи, проверкой хеша, проверкой лицензии и подтверждением версии отката. Действия могут показаться незначительными, но в совокупности они образуют полную цепочку поставок.

После разветвления версии название больше не объясняет проблему.

Самая сложная часть модели с открытым исходным кодом никогда не состоит в том, «есть ли она». Как только вес распространится на несколько образов, несколько организационных складов и несколько ветвей тонкой настройки, под одним и тем же именем начнут расти разные модели поведения.

На данный момент уже недостаточно обсуждать, «существует ли еще модель». Более трудный вопрос: какая из них является основной, какая — всего лишь зеркальным отражением, какая обучена дважды, а какая всё ещё сохраняет исходное поведение рассуждения. Название все еще может указывать на один и тот же проект, но результаты начали расходиться. На этом этапе, если команда по-прежнему считает «то же самое имя» «одним и тем же», онлайн-результаты рано или поздно изменятся.

Это также самая большая разница между моделями с открытым исходным кодом и API с закрытым исходным кодом. API с закрытым исходным кодом отключен, и производительность очень проста; модель с открытым исходным кодом разделена, и на первый взгляд служба все еще работает, но за кулисами версия, зависимости и границы поведения были изменены. Что действительно беспокоит, так это зачастую не неудача, а «похоже, что это все еще работает».

Что действительно необходимо исправить, так это источник, откат и повторение в автономном режиме.

Когда в проекте происходят такого рода изменения, первое, что нужно компенсировать — это не эмоции, а три вещи: источник, откат и оффлайн-повторение.

Источник должен прослеживаться до конкретных складов, конкретных материалов и документов определенного веса. Откат должен иметь возможность вернуться к предыдущей версии поведения, а не только к имени. Автономное воспроизведение должно иметь возможность снова провести тот же цикл экспериментов, когда сеть колеблется, зеркало потеряно или восходящий пакет удален.

Многие команды обычно чувствуют, что эти вещи далеки от них. И только однажды, когда обновление вышестоящего уровня изменит стиль вывода или определенная синхронизация изображений замедлится, они обнаружат, что проблема вовсе не в возможностях модели, а в цепочке зависимостей, которая не управляется как первоклассный гражданин. Чем более открытым исходный код является модель, тем очевиднее это. Потому что открытый исходный код приносит не всегда стабильный «свободный вход», а все более длинную цепочку поставок.

Самая физическая часть обычно не тело модели.

Когда дело доходит до производственной среды, наиболее вероятным местом ошибки обычно является не онтология веса, а запись по умолчанию, автоматические обновления и неявные зависимости.

Если команда считает определенный онлайн-портал единственным источником, она все равно может позвонить на него сегодня, но завтра ей, возможно, придется временно найти замену; если он считает зеркальную станцию ​​истиной по умолчанию, дрейф версий незаметно прокрадется в обучение и оценку; если ритм обновлений слишком напряженный, сегодняшняя стабильность поведения не ясна, и завтрашняя новая версия будет в сети.

Так что такого рода проблемы похожи на международную политику, но когда дело доходит до инженерии, они больше похожи на управление цепочками поставок. Кто контролирует запись, кто отвечает за подпись, кто определяет откат, кто сохраняет старую версию и кто может пересобирать в автономном режиме — это границы, которые будут продолжать влиять на доставку. После обнародования самой модели места для внешних действий станет меньше; пространство, оставленное команде для самостоятельной разработки уроков, станет больше.

Будет ли модель с открытым исходным кодом «запечатана» — это довольно узкий вопрос. Более реалистичное суждение таково: чем более открытый исходный код, тем труднее сдержать его одним действием; но чем более открытым исходный код, тем больше ему нужно управлять версиями, источниками, откатами и автономными повторениями. Если эту цепочку поставок не контролировать, любые внешние колебания будут перерастать в аварию, которая будет выглядеть как «модельная авария».