Новое определение open должно учитывать реализацию, спецификацию и управление как три критически важных фактора, которые нужно связать воедино.
Open source никогда не был только моделью лицензирования. Это еще и философия общего труда, общей прозрачности и общего влияния. Общая цель — менять мир. В эпоху разработки с помощью AI и агентов есть мнение, что AI slop, то есть массово сгенерированный и отправленный код, станет концом open source-проектов. Напротив, я считаю, что open source ждет возрождение, какого мы еще не видели, если мы будем подчеркивать аспекты open source, выходящие за рамки отправки кода.
В этом новом мире философия, этика и мораль open source важны как никогда. Однако фокус open source должен выйти за пределы «сырого» кода: файлы спецификаций (spec files) и документы управления (constitutions) становятся столь же важны, как и сам исходный код. Задача не в том, чтобы выбирать между open source и AI, а в том, чтобы признать: open source теперь стал общественным механизмом контроля и определения границ для open технологий.
Разберу это подробнее. Спецификации описывают намерение и ожидаемый результат, а код показывает, как именно это намерение реализовано. Если что-то идет не так, путь все равно нужно прослеживать от спецификации к реализации. Доверие нужно заслужить, а не предполагать, поэтому обещание, что, например, приложение уважает вашу конфиденциальность или агент никогда не передает данные третьим сторонам, должно подтверждаться кодом и строиться на конвейерах, которые может проверить любой пользователь, например в Acquacotta Constitution.
Управление дополняет файлы спецификаций, показывая, как спецификация создается, принуждается к исполнению и соблюдается. Это «решения о людях» внутри проекта: кто принимает окончательное решение? Если что-то выносится на голосование, кто голосует? Как они голосуют? Именно такие на первый взгляд педантичные, но критически важные решения рождаются из governance и становятся основой того, как создаются и соблюдаются spec files, когда вклад в код становится таким же простым, как написание базового prompt для агента.
Open означает open даже для AI
Главная критика AI в open source в том, что вносить вклад в код становится доступно всем, а не только людям с глубокими техническими знаниями. Из-за этого опоры open source-сообщества вне кода становятся важнее, чем когда-либо. Пользователи по сути становятся участниками разработки, когда любой может создавать код, а значит, им нужна возможность влиять на спецификацию. Кроме того, эта новая категория участников сообщества должна иметь возможность влиять и на управление, и на спецификации, как это делали «обычные» контрибьюторы до эпохи AI. Spec files, отправляемые вместе с их AI-сгенерированным кодом, должны быть открыты для проверки и воспроизводимы, как и более традиционный вклад в код. Сохраняется и возможность форкнуть реализацию и запустить ее на внешней инфраструктуре, чтобы участники могли дальше дорабатывать собственные настройки, интеграции и оптимизации.
Именно так организации сохраняют реальную субъектность в эпоху, когда код стал товаром. Иными словами, spec files расширяют то, что мы должны держать открытым; они не отменяют необходимость сохранять открытыми и проверяемыми код, системы сборки и деревья зависимостей. Будущее — не спецификации вместо open source, а open source плюс open specs и open governance.
Спецификации нужно версионировать, рецензировать и обсуждать так же, как код. Архитектурные и управленческие артефакты нужно делать частью публичного архива, чтобы другие могли учиться на них, переиспользовать их и улучшать их. Это создает более богатый набор open source-активов. Репозиторий содержит не только код; он содержит конституцию проекта, архитектурное обоснование и ограничители, которые удерживают AI-инструменты и AI-ориентированный вклад в код в нужных рамках.
Нельзя недооценивать, насколько это снижает барьер входа. Теперь действительно любой может вносить вклад, а не только тот, кто понимает кодовые компоненты проекта. Предметные эксперты, дизайнеры и специалисты по эксплуатации могут предлагать изменения на уровне спецификации, а AI-агенты затем помогают реализовывать их. Для сообщества, которое опирается на ценности open source и на надежные фреймворки тестирования, зафиксированные в constitution, это ускоряет создание качественного ПО, сохраняя прозрачность, проверяемость и возможность форка, от которых зависит open source.
«Настоящий» open source
Мы действительно рискуем тем, что сближение open source и спецификаций превратится в тест на «чистоту» с двух сторон. Одни утверждают, что если большую часть кода написал AI, то это не «настоящий» open source. Такой аргумент подразумевает, что происхождение каждой строки синтаксиса важнее, чем прозрачность, возможность форка и открытое управление системой в целом. Другая сторона, наоборот, считает, что если реализацию можно заново сгенерировать из спецификации, то о лицензировании и открытости кода можно больше не беспокоиться — будто изящная constitution делает проверку реальной механики необязательной.
Обе позиции упускают суть. Если вам важны субъектность пользователя, безопасность и долгосрочная устойчивость, а именно это должно быть важно для всех open source-проектов, вам нужны и открытый код, и открытые конвейеры сборки, чтобы любой мог проверять, воспроизводить и усиливать то, что работает в продакшене. Вам нужны открытые спецификации и открытое управление, чтобы любой мог понимать, что система должна делать, как она должна себя вести и как со временем принимаются решения.
Новое «определение» open должно рассматривать реализацию, спецификацию и управление как три ключевых фактора, которые нужно переплетать между собой. Open implementation означает, что исходный код, зависимости и система сборки доступны под open source-лицензией, чтобы вы могли самостоятельно пересобрать, проверить и запустить ПО. Open specification означает, что требования, архитектура и constitution проекта задокументированы, версионированы и публичны, чтобы другие могли переиспользовать их, учиться на них и адаптировать под свои задачи. Open governance означает, что процессы предложения, рассмотрения и принятия изменений — как на уровне спецификаций, так и на уровне кода — прозрачны и предполагают участие сообщества.
Путь вперед для open source-сообществ — не отступать от разработки, основанной на спецификациях и поддерживаемой AI, и не объявлять старую миссию устаревшей. Нужно возглавить работу по определению и практике того, как open specification, governance и implementation существуют вместе в мире, ориентированном на AI, — и делать это с уверенностью, позволяющей мечтать масштабнее, чем простая инкрементальная автоматизация.
Именно способность людей и организаций мечтать масштабнее позволяет решать задачи, которые раньше были слишком крупными, слишком странными или слишком нишевыми, чтобы оправдать полноценную проектную команду. UX-дизайнер, который никогда не коммитил ни одной строки кода, внезапно может создать серьезный инструмент. Инженер по безопасности может от начала до конца прототипировать новый конвейер threat-hunting. Архитектор может поднять референсную реализацию более безопасного шаблона интеграции, а затем позволить другим клонировать и расширять ее. В каждом случае AI не заменяет экспертизу; он усиливает ее. Самые ценные люди в комнате тратят меньше времени на генерацию шаблонного кода и больше — на намерение, ограничения и компромиссы.
AI-инструменты — это не улица с односторонним движением
Но здесь есть одна очень важная вещь, о которой нужно помнить, когда вы начинаете мечтать масштабнее с AI-инструментами: доступ к ним есть не только у вас — он есть и у ваших конкурентов. И, что еще важнее, он есть и у плохих актеров.
Что касается первых, то мечтать масштабнее означает мечтать масштабнее, чем те, кто хотел бы отобрать у вас бизнес. Речь о том, чтобы ваши клиенты оставались вашими клиентами, а вы могли постоянно привлекать новых.
Что касается вторых, то нужно учитывать: у людей, которые хотят навредить вам и вашим клиентам, есть те же самые инструменты. И если кто-то и умеет мечтать масштабнее, то это именно те, кто хочет ломать ваши системы, обманывать ваших клиентов и манипулировать вашими пользователями.
Это одна из причин, почему традиционная рамка «open source = открытый код» начинает казаться слишком узкой. Если атакующие могут непрерывно смешивать мощные AI-инструменты в тени, защитникам нужны открытые, проверяемые шаблоны для обнаружения, реагирования и управления, которые любой может взять и улучшить.
Большой шатер open source
Та же открытость, которая когда-то превратила разрозненную группу хакеров в двигатель современного программного стека, теперь может быть применена к новому слою спецификаций и агентов. Это новый путь вперед, который делает open source еще доступнее для нового типа участников. Для open source задача не в том, чтобы бороться с AI slop. Напротив, как глобальному сообществу нам нужно продвигать позитивные стороны AI-ориентированного вклада, чтобы хорошего было гораздо больше, чем плохого.
—
New Tech Forum — это площадка, где технологические лидеры, включая вендоров и других внешних авторов, могут подробно обсуждать новые корпоративные технологии. Подбор материалов субъективен и основан на том, какие технологии, по мнению редакции, наиболее важны и интересны читателям InfoWorld. InfoWorld не принимает маркетинговые материалы к публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы направляйте по адресу doug_dineley@foundryco.com.
Материал — перевод статьи с английского.