Личный опыт: почему я не контрибьютил в open source

«За всю свою карьеру в IT я не написал ни одной строчки кода в чужие open source проекты».
Несмотря на то что у меня были свои проекты — я их сделал или сам, или по работе, и туда я контрибьютил — в чужие репозитории я никогда не заходил с намерением что-то исправить.

Сначала это было связано с тем, что у меня не было времени разбираться с проектом, понимать, как он устроен, смотреть, какие задачи надо выполнить. Я был «молодой начинающий», и мне казалось, что код, который я пишу, «не совсем подойдёт для open source проекта, в который много кто смотрит и много кто использует».

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

Например, с Whisper CPP — C++ и C-кодом для модели Whisper — я добавил проверку платформы и выбор правильного файла. Эти изменения я не коммитил в оригинальный репозиторий, потому что они были «очень специфически, грязно закоженные» и, скорее всего, нужны только мне.

Стандартная рекомендация — и что с ней не так

Существует популярная рекомендация:

Если вы хотите обучаться программированию и хотите, чтобы вас заметили — контрибьютите в open source.

Совет простой: найти проект, сделать исправления, обновить документацию, отправить pull request и стать контрибьютором.

Однако, по всей видимости, «этого больше не будет».

Почему проекты начинают отказываться от pull request’ов

Некоторые open source проекты — например, TLDraw, язык программирования Zig, Curl — решили больше не принимать пулреквесты и изменения кода от других разработчиков.

Причина серьёзная.

Автор TLDraw в большом посте описал главную проблему: люди делают изменения, которые нужны лично им, даже не смотрят в issue проекта, не проверяют, требуется ли такой функционал вообще. Они просто делают изменения и создают pull request.

На первый взгляд, в этом нет ничего плохого — возможно, человек фиксит баг. Но с ростом количества PR появилась новая проблема.

Нейросети и «slop»: поток плохого кода

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

При этом они:

  • не изучают проблему,
  • не смотрят, как устроен проект,
  • не проверяют требования,
  • просто открывают редактор кода,
  • просят сделать «то-то и то-то»,
  • получают огромное количество сгенерированного плохого кода.

В тексте появляется слово «slop» — намёк на нейросетевую генерацию бесполезного кода. В один из месяцев TLDraw стал получать огромное количество таких PR. Код выглядел плохо, правила не соблюдались, иногда он был «просто ужасно» написан.

Главная проблема: время мейнтейнеров

Если pull request плохой, это не просто «написать комментарий и закрыть его».

Чтобы понять, что код ужасный, его нужно:

  • прочитать,
  • разобрать,
  • понять логику,
  • проверить соответствие архитектуре.

Это «отнимает огромное количество времени».

Если один PR — ещё можно справиться. Но когда «валится огромное количество пулреквестов с нейрослопом», это может занять день, два или три.

И всё это — не для того чтобы принять полезный код, а чтобы просто написать комментарий:

код плохой — и закрыть пулреквест.

Отказ от open source контрибьюторов?

Уже есть проекты, которые решили отказаться от сторонних изменений. Причина проста:
«Не все люди понимают, как работает open source, как правильно с ним обращаться и действовать».

В ближайшее время можно ожидать, что многие другие проекты будут:

  • отказываться принимать pull request’ы,
  • запрещать сторонние изменения,
  • ограничивать контрибьюторов.

Надежда на GitHub

Главная надежда — что GitHub придумает механизмы защиты.

Например, предлагается разрешать делать pull request только тому, кто назначен на задачу (есть assignment — можно сделать PR, нет assignment — нельзя).

Но пока таких механизмов нет. И мы можем оказаться в ситуации, когда:

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

Не потому что вы плохой разработчик.
А потому что платформа не даёт нормальных механизмов для защиты от «сгенерированного нейросетью багованного, плохого, непроверенного кода».

Что это значит для разработчиков?

  1. Эпоха «свободного контрибьютинга» может измениться.
  2. Open source становится жертвой массовой AI-генерации.
  3. Мейнтейнеры защищают своё время и качество проекта.
  4. Платформы должны адаптироваться к новой реальности.

И главный вопрос остаётся открытым:
сможет ли open source сохранить открытость в эпоху нейросетей?