AI в KDE за несколько дней превратился из доклада на конференции Akademy в конфликт с банами, удалённой веткой обсуждения и отдельной кампанией за полный запрет LLM. Для русскоязычных разработчиков и команд, которые живут на open source, это не драма ради драмы: сообщество KDE сейчас на практике выясняет, где проходит граница между полезной автоматизацией и мусорными AI-вкладами.
Как пишет The Register, поводом стал доклад на ежегодной конференции Akademy с названием «A lovable, sovereign, AI-native KDE». Его авторы предложили смотреть на KDE как на «AI-native» рабочее окружение, а презентация завершалась тезисом в духе: вопрос не в том, нужен ли AI, а в том, сколько его и какого именно. Формулировка явно попала в нерв: KDE — проект с сильной культурой автономии, открытой разработки и недоверия к навязанным сверху технологическим модам.
После конференции разработчик KDE Нейт Грэм открыл обсуждение в Invent, GitLab-инстансе проекта, где предложил ограничения для вкладов, созданных или изменённых с помощью LLM. Идея была не в том, чтобы безусловно открыть ворота для генеративного кода, а скорее наоборот — описать более строгие правила. Но разговор быстро ушёл в перегрев: модераторы выдавали предупреждения, затем ограничили комментарии, а позже ветку удалили. По данным источника, один участник был забанен после того, как обратил внимание на оскорбительные публикации другого участника; автор этих материалов тоже получил бан после проверки личности.
На этом история не закончилась. Появилась внешняя инициатива KDE for People, потребовавшая от проекта политики No-AI. До закрытия сбора подписей её поддержали около 250 человек. Параллельно разработчик GNOME Джордан Петридис опубликовал собственный вариант политики для GNOME: запретить использование LLM при создании или изменении всего, что отправляется в проект или размещается на его инфраструктуре. То есть спор быстро вышел за пределы одного десктопного окружения и стал частью более широкого разговора внутри Linux-экосистемы.
Контекст здесь важнее самого скандала. Open source-проекты давно живут на доверии к патчам, ревью и репутации участников. LLM ломают привычную механику: код может выглядеть уверенно, но не иметь понятного автора в инженерном смысле; документация может быть гладкой, но пустой; багрепорт может занимать время мейнтейнера, хотя его собрали без понимания проблемы. Для маленьких команд это особенно болезненно: у них нет бесконечного штата ревьюеров, чтобы отделять полезный вклад от «LLM slop».
Похожий спор уже прошёл через Debian. Там разработчики голосовали по вариантам политики в отношении AI, но проект в итоге не ввёл полный запрет на AI-вклады. The Register ранее обращал внимание, что несколько анти-AI вариантов могли раздробить голоса. Для крупных сообществ это типичная ловушка управления: почти все согласны, что правила нужны, но варианты от «запретить всё» до «разрешить с маркировкой и ответственностью автора» собирают разные группы сторонников.
Нейт Грэм позже извинился за свою роль в эскалации и написал, что случайно запустил «онлайн-шторм», пытаясь подготовить более ограничительную политику использования LLM для KDE. Он также отметил, что доклад на Akademy и последующий воркшоп встретили холодно. Это важная деталь: конфликт возник не между «староверами» и «прогрессорами», а внутри сообщества, которое пытается защитить качество проекта и одновременно не проигнорировать инструмент, которым уже пользуются многие разработчики.
Показательно, что после Akademy KDE выбрал три цели на следующие два года, и AI среди них нет. В список попали KDE for Enterprise and Deployments, улучшение документации и новое поколение стилизации KDE. Для части сообщества это, вероятно, хорошая новость: проект сначала займётся вещами, которые напрямую влияют на внедрение, поддержку и пользовательский опыт, а не будет превращать рабочий стол в витрину генеративных функций.
Для бизнеса и IT-директоров история с AI в KDE выглядит как предупреждение: внедрение LLM в инженерные процессы нельзя свести к лозунгу «давайте добавим AI». Нужны правила происхождения кода, маркировка AI-assisted вкладов, ответственность человека за результат и понятная политика для инфраструктуры проекта. Иначе вместо ускорения команда получает новые очереди на ревью, токсичные споры и риск принять в кодовую базу патчи, которые никто по-настоящему не понимает.
Похоже, ближайший год в open source пройдёт не под знаком вопроса «можно ли пользоваться LLM», а под более неприятным и практичным вопросом: кто отвечает за результат, если вклад написал человек, но большую часть решения подсказала модель. AI в KDE стал громким примером, потому что KDE заметен; похожие конфликты будут появляться в библиотеках, дистрибутивах, документации и внутренних корпоративных проектах, где мейнтейнеры уже устали быть бесплатным фильтром для чужой автоматизации.