Как ИИ меняет open source

Иржи Эйшман (Jiří Eischmann) работает в Red Hat и поддерживает проекты вокруг GNOME. Эту заметку он написал для своего чешского блога в июле 2026 года и перевёл после бурной реакции; читается она скорее как полевые заметки мейнтейнера, чем программный манифест. В ней три тренда, и ни один из них не претендует на пророчество: инфляция проектов, перегрузка ревью и спад желания вообще публиковать код.

Инфляция проектов

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

Эйшман настаивает на разнице между кодом на GitHub и настоящим open source проектом. Проект решает задачи своих пользователей; репозиторий может оказаться одноразовой поделкой под сиюминутную нужду одного человека, выложенной на публику без малейшего интереса ко всему остальному. В пример он приводит MeshCore, где накопились десятки форков подо всё подряд: в официальной прошивке чего-то не хватает, кто-то делает форк, навайбкодит кусок и выкладывает MeshCore-UltimateEdition. Автор к этому никак не привязан, через месяц ему становится скучно, и репозиторий превращается в заброшенный проект ещё до того, как успеет хоть немного устареть.

Его предположение: курируемые источники программ могут вернуться. Около десяти лет назад сошлись на том, что репозитории дистрибутивов Linux отжили своё: в 2000-х они были фактически единственным источником программ под Linux, затем проектов стало больше, чем дистрибутивы успевали упаковывать, и пользователи с авторами научились обходиться без них. Если публикация превратится в хаос, возможность опереться на то, что проверено человеком и останется на месте через полгода, снова обретёт ценность. Это тот же компромисс, на который идут high-friction-commons и build-a-new-internet в работе с контентом: добросовестное участие покупается ценой намеренно высокого барьера.

Перегрузка ревью

Написание кода служило фильтром, потому что требовало времени и сил. Фильтр исчез, а следующие за ним процессы ревью работают на пределе.

Этот раздел иллюстрируют два конкретных случая. В GNOME 50 убрали поддержку Google Drive, потому что её давно никто не поддерживал; пользователь вернул её и отправил upstream в gvfs. Коллега Эйшмана, мейнтейнер проекта, смотрит на изменение в 4000 строк: на базовом уровне оно вроде бы работает, написано явно через ИИ, и теперь его нужно построчно вычитать, прежде чем брать на себя обязательство поддерживать этот код годами. При этом автор охотно отвечает и искренне заинтересован в решении - что, как замечает Эйшман, сейчас уже редкость.

Его собственный пример ещё хуже. В репозиторий Meshy прислали pull request на 9000 строк с поддержкой macOS. Час беглого вечернего разбора выявил тысячи строк с простой заменой одинарных кавычек на двойные, беспричинные правки в постороннем коде и затирание всех коммитов, которые сам Эйшман сделал в main за предыдущие недели. На комментарии автор так и не ответил. Главный вывод: даже потраченный час был слишком дорогой инвестицией, и в следующий раз отклонять придётся быстрее.

Решение Flathub отклонять приложения, созданные с помощью ИИ, критиковали как самосаботаж, но Эйшман защищает его нехваткой ресурсов: несколько тысяч приложений, ежедневные новые заявки и всего три человека на ревью. Процесс во многом автоматизирован, но остаётся тщательным - цель в гигиене кодовой базы, а не только в отсеве откровенного мусора. Сам он подал два приложения за полгода и говорит, что ревью пошло обоим на пользу. Шаблон заявки на включение требует ответить на несколько вопросов и записать короткое видео с демонстрацией работы - минут на пятнадцать дела, но для авторов сгенерированного шлака даже это оказалось непреодолимым порогом. Некоторые объявили правила ударом по свободе Linux и навайбкодили открытую для всех альтернативу FlatFree, просуществовавшую около месяца.

Главная потеря здесь - даже не пропускная способность. Ревью было механизмом, через который мейнтейнеры растили новых контрибьюторов и будущих преемников. В заявке, которая ничего не стоила автору и в которой он сам не разбирается, менторить некого. Open source никогда не сводился к одному лишь результату: это был процесс, в котором люди выстраивали отношения с проектом и передавали его дальше. Это ровно то, о чём говорит contributor-poker: время на ревью - это ставка на человека, а не на содержимое первого PR, а PR от LLM такую ставку вернуть не может. В code-review-throughput-limits собраны цифры о потолке пропускной способности, а reviewing-ai-code спорит с подходом "просто проверяйте это как код стажёра". С другой стороны этот пересмотр роли мейнтейнера описан в i-dont-want-your-prs: зачем вообще нужен вклад со стороны, когда писать код стало так дёшево.

Спад желания публиковать

Здесь Эйшман вспоминает Фукуяму: в 1990-х демократию и либеральную экономику объявили окончательными победителями, и проверка временем оказалась безжалостной; точно так же несколько лет назад победителем среди моделей разработки объявили open source. Он задаётся вопросом, не настало ли время для аналогичной коррекции, и приводит четыре довода в пользу отказа от публикации, которые слышит вокруг.

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

Второй - обход лицензий, и это самый серьёзный аргумент. LLM обучаются на исходном коде без оглядки на лицензии, а затем способны выдать похожее решение под любой лицензией, какую выберет пользователь. Разрешительные лицензии от этого не страдают: их авторы заранее с этим согласились. С copyleft иначе: GPL создавалась как гарантия того, что улучшения вернутся обратно, а модель, натренированная на годах вашей работы и выдающая близкий эквивалент под проприетарной лицензией, обходит эту гарантию без формальных нарушений. llm-enshittification разбирает отмывание копирайта подробнее; control-the-ideas-not-the-code заходит с обратной стороны - ценность в архитектуре и идеях, а не в строках кода.

В качестве иллюстрации снова всплывает MeshCore. Протокол и прошивка у него открыты, а клиенты закрыты; сообщество выяснило, что один из ключевых участников втайне подал заявку на товарный знак MeshCore и начал вайбкодить собственные закрытые продукты на базе доступного кода. Основатель Скотт Пауэлл (Scott Powell) счёл это подтверждением того, что закрывать исходники клиентов было правильным решением:

В эпоху ИИ я вижу в open source способ отдать свой пот, кровь и слёзы на растерзание другим - причём бесчисленным количеством способов.

Эйшман не разделяет эту позицию целиком, но отмечает, что она звучит всё чаще: люди, годами ратовавшие за открытость и публиковавшие каждый вспомогательный скрипт, теперь придерживают код у себя и делятся только по запросу. Захват товарного знака - это ещё и кризис управления того типа, который описан в maintainer-governance-ambiguity, когда из-за размытых ролей сообщество не может отличить рейдерство от обычных разногласий.

Третий довод - слабеет сама необходимость делиться. Open source вырос из высокой стоимости написания и поддержки кода: реализовывать одно и то же по отдельности было расточительно, поэтому усилия объединяли. Когда от библиотеки нужно всего 10% возможностей, а модель может воспроизвести эти 10%, изучив оригинал, тащить зависимость перестаёт иметь смысл. А когда есть собственная копия, отдавать доработки upstream уже незачем. Этот механизм описан в port-not-patch-contribution в масштабах целой библиотеки: перенос кода становится настолько дешёвым, что цепочка возврата исправлений в upstream слабеет. Эйшман спорит с радикальной версией этого тезиса: мнение "WordPress мёртв, потому что я могу сам сгенерировать CMS" сильно недооценивает всё, что проект даёт помимо кода, а замена зависимости от open source проекта на зависимость от LLM может себя не оправдать.

Четвёртый - безопасность; аргумент, который звучит уже двадцать лет, но никогда ещё не звучал так громко. Классический спор: открытый код помогает злоумышленникам искать уязвимости, на что возражают, что безопасность через неясность - не безопасность вовсе, а при достаточном количестве глаз все ошибки лежат на поверхности. Новым стал поток автоматически сгенерированных отчётов об уязвимостях, причём в таких объёмах, что закрытый код начинает казаться безопаснее. Он обращает внимание на перекос в новостях: заголовки считают уязвимости, найденные ИИ, а не исправленные им, потому что исправление по-прежнему требует глубокого понимания кодовой базы и остаётся за людьми, чьи ресурсы ограничены так же, как и на ревью.

Эйшман рассчитывает, что эта последняя проблема со временем сойдёт на нет. Проекты разберутся с отчётами, поддерживаемый open source станет только надёжнее, и выиграют все. По поводу остальных трёх пунктов оптимизма он явно не испытывает.