Личный опыт: почему я не контрибьютил в 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 — нельзя).
Но пока таких механизмов нет. И мы можем оказаться в ситуации, когда:
ваша любимая библиотека, в которой есть баг, не захочет принимать ваши изменения.
Не потому что вы плохой разработчик.
А потому что платформа не даёт нормальных механизмов для защиты от «сгенерированного нейросетью багованного, плохого, непроверенного кода».
Что это значит для разработчиков?
- Эпоха «свободного контрибьютинга» может измениться.
- Open source становится жертвой массовой AI-генерации.
- Мейнтейнеры защищают своё время и качество проекта.
- Платформы должны адаптироваться к новой реальности.
И главный вопрос остаётся открытым:
сможет ли open source сохранить открытость в эпоху нейросетей?