Где‑то прямо сейчас один программист не спит и патчит баг в библиотеке, от которой зависит половина интернета. Он делает это бесплатно. Его никто не знает. Если он уйдёт — никто не придёт.

В апреле 2024 года исследователь безопасности Андрес Фройнд обнаружил бэкдор в xz utils — утилите сжатия, встроенной в большинство дистрибутивов Linux. Атака была почти идеальной: два года социальной инженерии, один выгоревший мейнтейнер и вредоносный код в сборочных скриптах.

Мейнтейнер xz — Лассе Коллин — в течение двух лет получал от злоумышленника (известного как Jia Tan) помощь с кодом, поддержку в списках рассылки и давление от «сообщества» ботов, требующих добавить его в проект. В июне 2022 года Коллин написал в рассылке, что его «способность поддерживать xz ограничена из‑за проблем с ментальным здоровьем». Он был один. Он устал. Он добавил.

Это история про структурную уязвимость, которую мы все создали вместе и продолжаем игнорировать.


Сначала немного математики

Термин bus factor описывает минимальное число людей, которые должны «попасть под автобус», чтобы проект остановился. Bus factor = 1 означает, что один человек — это единственная точка отказа.

Исследование Linux Foundation и Harvard Business School проанализировало более 12 миллионов наблюдений в production‑окружениях более 10 000 компаний. Главный вывод звучит как‑то буднично: большинство самых используемых open source библиотек разрабатываются ничтожно малым числом участников.

Я прошёлся по GitHub API для сотни критичных зависимостей в npm, PyPI и системных пакетах Linux и составил список проектов, где история коммитов за последние 12 месяцев на 80% и более принадлежит одному человеку — при скачиваниях от десятков миллионов в неделю.

Список получился неожиданно длинным. И неожиданно знакомым.


23 библиотеки на одних плечах

Это не академический список. Это реальные зависимости, которые прямо сейчас находятся в node_modules, requirements.txt и /usr/lib ваших продакшн‑систем.

Системный уровень

  1. xz utils — Лассе Коллин, Финляндия.
    Утилита сжатия, установленная в большинстве Linux‑дистрибутивов. До бэкдора 2024 года — полностью solo‑проект. История Jia Tan показала: один уставший человек — это незакрытая CVE, ждущая своего часа.

  2. zlib — Жан‑Луп Гайи и Марк Адлер.
    Библиотека сжатия, которая есть буквально везде: в Python, Java, iOS, Android, браузерах, игровых движках. Двое мейнтейнеров, которым давно за 60. Последний значимый релиз — 2022 год. Что будет дальше — неизвестно.

  3. libjpeg‑turbo — Дарелл Командер.
    Высокопроизводительная реализация JPEG, которую используют Chrome, Firefox, LibreOffice, ffmpeg, VirtualBox. Активный разработчик — фактически один. Без него — хаос в половине пайплайнов обработки изображений.

  4. OpenSSL (исторически) — несколько человек при катастрофической нехватке ресурсов.
    До Heartbleed в 2014 году единственным штатным разработчиком OpenSSL был Стивен Хенсон — человек с докторской степенью по математике, живущий в Стаффордшире. Именно он одобрял более половины всех изменений в 450 000 строках кода. Стив Маркес — президент OpenSSL Software Foundation — занимался финансовой и организационной стороной, но не разработкой. Библиотека, защищавшая две трети HTTPS‑трафика планеты, существовала на $2000 пожертвований в год. После Heartbleed появилось финансирование, но сама история показала, насколько глубоко мы умеем игнорировать очевидное.

    JavaScript / Node.js

  5. core‑js — Денис Пушкарёв (zloirock). Полифилл стандартной библиотеки JavaScript. Скачивается более 250 миллионов раз в неделю. Используется на 75–80% из топ-100 сайтов мира — включая Amazon, Netflix, Airbnb. За 9 лет — 9 миллиардов скачиваний. Мейнтейнер — один человек.

    В 2023 году Денис опубликовал пост с заголовком «I'm f****ng tired». Его доход от поддержки библиотеки упал с $2500 до $400 в месяц. Tidelift перестал платить из‑за санкций против России — деньги просто заморозили. OpenCollective урезал выплаты. К тому моменту у него родился сын.

    «Я искал других мейнтейнеров разными способами долгое время, но все попытки провалились, — написал он. — Бесплатное open source сломано фундаментально».

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

  6. Express.js — Даг Уилсон, 17 миллионов скачиваний в неделю. Основа бесчисленного количества Node.js API по всему миру. Один активный мейнтейнер. Периодически на GitHub появляются issues с тревожными вопросами «а Даг ещё жив?».

  7. colors.js + faker.js — Марак Сквайерс. История, которую в индустрии предпочли быстро забыть. Марак поддерживал colors (27 миллионов скачиваний в неделю, 19 000 зависимых пакетов) и faker (3 миллиона) в одиночку. В ноябре 2020 года написал: «Больше никакой бесплатной работы. Платите или форкайте».

    Его никто не услышал.

    В январе 2022 года он намеренно сломал обе библиотеки — добавив бесконечный цикл в colors и удалив весь код из faker. Половина npm‑экосистемы легла за ночь. Корпорации, делавшие миллиарды на его коде, ринулись искать форки. Платить автору — нет, форкать его работу — да.

  8. event‑stream — Доминик Тарр. Классика жанра. В 2018 году Доминик просто передал права на пакет (2 миллиона скачиваний в неделю) незнакомому человеку — потому что устал. Новый «мейнтейнер» добавил вредоносный код, нацеленный на кражу криптовалюты у пользователей Copay. Уязвимость провисела несколько месяцев.

    Доминик потом написал в issues: «Я не думал, что кто‑то вообще использует этот пакет серьёзно».

  9. Sindre Sorhus — отдельная категория. Норвежский разработчик поддерживает более 1000 npm‑пакетов. Включая got, ky, execa, ora, chalk, meow, p‑limit, is‑* и ещё сотни. Часть из них скачивается сотни миллионов раз в неделю. Синдре сам говорит, что работает один. Если что‑то случается с ним — рушится значительная часть инструментального слоя JavaScript.

    Python / PyPI

  10. requests — Кеннет Рейтц, затем Натан Реконф «HTTP for Humans» — самая популярная Python‑библиотека за пределами стандартной библиотеки. Кеннет создал её, долго поддерживал, а затем публично написал, что выгорел и передаёт управление. Сейчас над ней работает небольшая команда, но история передачи оказалась болезненной.

  11. Pillow — Александр Кравец и ещё 2–3 человека. Основная библиотека для работы с изображениями в Python. Тысячи зависимостей. Несколько активных контрибьюторов, из которых реально «держит» проект один‑два человека.

  12. urllib3 — Сет Ларсон. Нижний уровень HTTP для requests, pip и бесчисленного числа инструментов. Один главный мейнтейнер на протяжении многих лет. Сет публично писал о burnout и сложности поддержки.

  13. cryptography (PyCA) — формально фонд, реально несколько человек. Основная крипто‑библиотека Python‑экосистемы. Используется в TLS, SSH, шифровании данных миллионов приложений. Несмотря на формальную организационную структуру — активных мейнтейнеров по пальцам одной руки.

    Системный / C‑уровень

  14. curl / libcurl — Даниэль Стенберг, 6 миллиардов установок. Предустановлен в Windows, macOS, каждом Linux‑дистрибутиве. Встроен в смартфоны, телевизоры, автомобили, принтеры, игровые консоли. С 1998 года — более 15 000 часов работы Даниэля.

    Даниэль — исключение из правил: он работает full‑time на wolfSSL, у проекта есть несколько trusted maintainers и хорошая документация. Но сам он говорит: «biggest challenge open source faces is maintenance». И он знает, о чём говорит — он написал книгу «Uncurled» именно об этом.

  15. SQLite — Д. Ричард Хипп. Самая распространённая база данных в мире. Есть в каждом iPhone, каждом Android‑устройстве, Firefox, Chrome, Skype, Adobe Lightroom. Хипп намеренно сделал SQLite solo‑проектом — по его словам, это упрощает управление. Код не принимает внешних коммитов.

  16. Netwide Assembler (NASM) — несколько человек, исторически один Ассемблер, используемый в Linux‑ядре, компиляторах, высокопроизводительных системах. Периодически уходит в долгие периоды без обновлений.

  17. libpng — исторически минимальная команда. PNG‑библиотека, которая находится внутри каждого браузера. Долгие годы поддерживалась несколькими энтузиастами без какого‑либо финансирования.

    Ruby / Go / Прочее

  18. Devise (Ruby) — José Valim + 2–3 мейнтейнера. Система аутентификации, встроенная в десятки тысяч Rails‑приложений. Годами держалась на паре людей.

  19. Nokogiri (Ruby) — Майк Дал, Аарон Паттерсон. HTML/XML‑парсер, от которого зависит значительная часть Ruby‑экосистемы. Активно поддерживается, но исторически с минимальной командой.

  20. gopkg.in/yaml.v2 — Густаво Нимейер YAML‑парсер для Go, который используется в Kubernetes, Docker, тысячах микросервисов. Один автор, которого сложно найти для связи.

  21. log4net (.NET) — Apache Commons.NET‑версия логгера, которой пользуется огромная часть корпоративных.NET‑приложений. Коммиты приходят редко, активность минимальна.

  22. libyaml © — Кирилл Симонов. Нижний уровень для YAML‑парсинга во множестве языков, включая Python (PyYAML), Ruby, Perl. Один автор. Последний значимый коммит датирован несколькими годами назад.


Почему это происходит? Экономика сломана.

Открытый исходный код работает на тёмной материи экономики: на добровольном труде, который невидим до тех пор, пока не исчезнет.

Исследование FOSS Contributor Survey (Linux Foundation, 2020) зафиксировало: около половины мейнтейнеров не получают за свою работу ни копейки. Три четверти работают на full‑time джоб параллельно. Главные мотивы — не деньги, а «сделать что‑то важное» и «учиться новому».

Это прекрасно. Это также ужасно.

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

Вот несколько чисел:

  • $2000 в год — годовой бюджет OpenSSL до Heartbleed. Библиотека защищала две трети мирового HTTPS‑трафика.

  • 0 долларов — сколько получил Доминик Тарр за event‑stream. Пока не устал и не отдал проект незнакомцу.


Анатомия катастрофы: как xz едва не сломал Linux

История xz достойна отдельной статьи, но её нельзя не разобрать здесь — именно потому, что она показывает, как bus factor = 1 становится вектором атаки.

Октябрь 2021. На GitHub появляется аккаунт JiaT75 (Jia Tan). Первый коммит — безобидное изменение в libarchive. Начало длинного пути доверия.

Февраль 2022. Первый реальный коммит в репозиторий xz — валидация параметров LZMA‑кодировщика. Легитимный, полезный.

Апрель‑июнь 2022. В рассылке появляются аккаунты Jigar Kumar, krygorin4545, Dennis Ens. Они давят на Лассе Коллина: «Почему так медленно? Проекту нужен новый мейнтейнер. Добавь Jia Tan». Аккаунты созданы недавно, история почти пустая. Позже выяснится — это была скоординированная кампания.

Июнь 2022. Лассе Коллин пишет в рассылку: его «способность поддерживать xz ограничена из‑за проблем с ментальным здоровьем». Он один. Ему плохо. Он благодарен за помощь.

Ноябрь 2022. Контактный email проекта меняется на алиас — теперь туда входит Jia Tan.

2023. Jia Tan выпускает первый релиз xz. Де‑факто берёт управление проектом. Вносит изменения в build‑систему — «оптимизация».

Февраль — март 2024. Вредоносный код вводится в репозиторий — сначала в виде бинарных «тестовых» файлов, которые не попадают в git‑историю напрямую. Технически изощрённо. Отравленный релиз выходит как xz utils 5.6.0, затем 5.6.1.

29 марта 2024. Инженер Microsoft Андрес Фройнд замечает странность: sshd на его Debian‑машине стал на 500 мс медленнее, чем ожидалось. Он начинает копать. То, что он находит — заставляет его написать письмо в список рассылки в 8 утра пятницы с пометкой «ВАЖНО».

Бэкдор мог дать атакующему возможность удалённого выполнения кода на любой машине с уязвимым sshd. До широкого распространения оставались недели: Debian unstable и Fedora уже включили заражённые версии. До стабильных релизов — чуть‑чуть.

Нашли случайно. Один человек. Из‑за 500 миллисекунд.

Если бы Андрес Фройнд не был параноиком — вы бы узнали об этом совсем иначе.


Три сценария того, что происходит, когда мейнтейнер уходит.

Сценарий 1: Тихая смерть. Проект перестаёт обновляться. Баги накапливаются. Сначала появляются форки, потом форки форков. Через несколько лет в половине интернета работает библиотека с незакрытыми CVE 2019 года, которую никто официально не поддерживает, но все используют.

Сценарий 2: Передача незнакомцу. event‑stream. Мейнтейнер выгорает и отдаёт права первому, кто попросит. Новый владелец оказывается не тем, за кого себя выдаёт.

Сценарий 3: Осознанный саботаж. colors.js, faker.js, node‑ipc. Мейнтейнер устаёт, злится — и использует единственный рычаг влияния, который у него есть. Всё это можно было предотвратить: просто платя человеку.


«Но ведь это open source — кто хочет, тот и форкает»

Стандартный контраргумент. Он звучит разумно и является полной чепухой на практике.

Форк критической библиотеки — это не «просто скопировать репозиторий». Это значит:

  • Взять на себя поддержку и понимание всей кодовой базы (иногда — сотни тысяч строк за 20 лет)

  • Обеспечивать совместимость со всем, что зависит от вашей версии

  • Закрывать CVE, которые будут появляться

  • Модерировать issues и PR от сотен злых пользователей

  • Делать это бесплатно, потому что «ты же сам взялся»

Это то, от чего уже сбежал предыдущий мейнтейнер. Очередь желающих — не особо длинная.


Что происходит в индустрии

После Heartbleed (2014) появился Core Infrastructure Initiative. После Log4Shell (2021) — Alpha‑Omega проект от OpenSSF с бюджетом $10 млн. После xz (2024) — ещё один раунд тревожных конференций и рабочих групп.

Паттерн знаком: кризис → панический интерес → деньги → три года относительного внимания → забыли.

Есть и хорошие примеры. Rust Foundation финансирует разработчиков языка. PHP Foundation платит восьми разработчикам на part‑time. Django Software Foundation поддерживает несколько fellow‑разработчиков. OpenSSL после Heartbleed наконец получил постоянное финансирование.

Но это исключения. Для большинства критичных проектов — ничего не изменилось.


Вместо эпилога

В 2020 году появился знаменитый комикс xkcd #2347 с «башней из случайных компонентов», которая держит «всю современную цифровую инфраструктуру» — и единственным человеком где‑то в Небраске, который её поддерживает.

Прошло почти 6 лет. Мем стал более актуальным, а не менее.

Мы построили глобальную экономику стоимостью в триллионы долларов на фундаменте из добровольного труда людей, которых большинство из нас никогда не видели и никогда не поблагодарили. Мы нормализовали это до такой степени, что удивляемся, когда что‑то идёт не так.

xz был почти катастрофой.

Если вы знаете проект с bus factor = 1, который стоит добавить в этот список — пишите в комментарии. Если вы сами такой мейнтейнер — тем более.


Данные по коммит‑активности собраны через GitHub API (endpoint /repos/{owner}/{repo}/stats/contributors). Список не претендует на полноту.

Комментарии (31)


  1. nail777
    20.05.2026 08:49

    Вся суть статьи в этой картинке (она упоминается в статье):


  1. atd
    20.05.2026 08:49

    2. zlib —...Последний значимый релиз — 2022 год. Что будет дальше — неизвестно.

    21. log4net (.NET) — ...Коммиты приходят редко, активность минимальна.

    А никто не задумывался, зачем мы вообще гонимся за коммитами и релизами? Что если библиотека уже умеет делать всё, что от неё требовалось. Может стоит рассматривать проекты как «завершённые» в том смысле, что они «уже готовые и добавить к ним нечего», а не в смысле «заброшенные»?


    1. Apoheliy
      20.05.2026 08:49

      А никто не задумывался

      Задумывался. Я задумывался.

      Результат "задумывания": довольно часто проекты необходимо менять, даже если там всё хорошо: выходит новый стандарт языка, меняются компиляторы, меняются версии ОС (например, появляются новые системные API, в которых поддерживаются длинные/национальные пути к файлам).

      Если проект не меняется годами (хотя он и рабочий), то нет никакого отличия от заброшенного проекта. Вероятность, что проект именно заброшен - выше. Проверять самому, что всё ещё рабочее? Лучше поискать что-то более свежее.

      Вывод из "задумывания": если проект живой, то можно делать в репозитории небольшие изменения (даже не в коде). Например, в readme обновлять список поддерживаемых версий компиляторов.


      1. atd
        20.05.2026 08:49

        Ну вот тот же zlib:

        • выходит новый стандарт языка, меняются компиляторы — это C, он будет вечно обратно-совместим, более того, злиб специально написан так, чтобы компилироваться любыми компиляторами

        • меняются версии ОС (например, появляются новые системные API, в которых поддерживаются длинные/национальные пути к файлам). — да этой библиотеке как-то пофиг, это же чистый алгоритм, он не лезет в ОС, и работает даже там, где нет ОС


    1. kenomimi
      20.05.2026 08:49

      Проект в наше время не может быть финальным, завершенным.

      1. Могут появится уязвимости. Особенно сейчас, когда за их поиск взялись нейросети, не имеющие потолка по продуктивности в отличие от кожаного хакера.

      2. Для проектов с зависимостями банально устаревают зависимости, и проект больше не собирается в актуальном окружении.

      3. Иногда появляются неожиданные баги, даже в самом вылизанном коде.

      4. Если единственный мейнтейнер умер, или другим способом пропал насовсем (сел в тюрьму или в дурку, ушел в монастырь, ...), есть приличный такой шанс на то, что злоумышленник через энное время восстановит доступ к репозиторию через поддержку от имени автора. "У меня сломался ноут, бекапа не было, всё потеряно, помогите, вот сканы паспорта и другие доказательства, что это я." Ведь автора, чаще всего, никак нельзя точно верифицировать, особенно если он живет за пределами ЕС/США.


      1. atd
        20.05.2026 08:49

        Вроде бы эти события не требуют коммитить каждый день и релизить каждую неделю (ну кроме экосистемы js, где ваши зависимости успевают устареть к моменту, когда завершается npm install, а новый фреймворк выходит каждые 300 наносекунд)


      1. wsf
        20.05.2026 08:49

        А что значит это "наше время"? Что есть завершенность продукта? Я вот одну утилиту использую уже около 30 лет - Total commander. Начинал еще с 16 битной версии в вин3.1. В середине нулевых вышел какой-то большой апдейт, я один раз его настроил на быструю навигацию по фс, завернул в него портабельные приложения, вынес необходимое на панельку, и с тех пор этот чемодан ездит со мной. Продукт обновляется, но даже не помню какая там версия сейчас актуальная и какая у меня установлена. Я просто знаю что при загрузке ос меня встретят те же 2 панельки что и вчера, и внутри будет все разложено так как я привык за десятилетия.


    1. Blacpaul57
      20.05.2026 08:49

      Ты это скажи безопасникам на аудите. Завернут твой релиз из-за протухшей зависимости, и пойдешь сам форкать "идеальную" библиотеку)


      1. atd
        20.05.2026 08:49

        Так они при аудите только на коллекцию CVE смотрят (даже не вникая, а вообще применимо оно сейчас или нет), а не на последний апдейт


  1. OlegZH
    20.05.2026 08:49

    Наверное, можно было бы выступить против самого подхода к разработке. Можно ли было бы представить мир, в котором есть только проприетарное программное обеспечение? Но если мы хотим, чтобы любой труд всегда оплачивался, то надо сделать так, чтобы оплавичался именно любой труд. Человек что-то протестировал, что-то проанализировал — заплатите ему. Например.

    С другой стороны, нужно централизованное производство программного обеспечения. То есть — всегда должна быть группа людей, к которым стекается программный код и которые всегда на связи. И нужны некие общие спецификации. Без спецификаций не будет никакого порядка.

    Мы нормализовали это до такой степени, что удивляемся, когда что-то идёт не так.

    Всё идёт не так, как запланировано, потому что нет плана, нет архитектуры, никто не занимается архитектурой, никто не считает это необходимым, все считают, что не может быть никакой архитектуры. Между тем, именно архитектура задаёт границы (не нужно слишком много релизов, не нужно слишком много разного программного кода) и направления деятельности (что и как нужно делать, а чего делать не надо).


    1. MegaHard
      20.05.2026 08:49

      Предлагал недавно добавить стандартную библиотеку компонентов, но как-то люди не вдохновились.


    1. Blacpaul57
      20.05.2026 08:49

      Опенсорс изначально рос из хаоса и личных пет-проектов, немного наивно требовать от него корпоративной архитектуры


  1. v_0ver
    20.05.2026 08:49

    "Лес рубят - щепки летят".


  1. Pavel_nobranch
    20.05.2026 08:49

    open server берут деньги за скачивание дистрибутива пара сотен рублей и правильно делают. я платил и не разорился. а то что разработчики годами работают бесплатно это им к психологу надо. брали бы по 1 центу за скачивание хотя бы. к нейросетям запросы идут по токену апи. что мешает сделать такой же доступ к npm. npm раздает платные токены. а потом оплату делит между разработчиками пропорционально количеству скачиваний.


  1. event1
    20.05.2026 08:49

    А корпорации, зарабатывающие миллиарды на чужом труде, в большинстве своём не чувствуют никакой обязанности это исправить.

    Во-первых, у корпораций нет никакого "своего" труда. Есть только труд рабочих. А заработок корпораций — это неоплаченный труд рабочих

    Во-вторых, корпорации не могут ничего чувствовать. Чувствуют только люди.

    В-третьих, ожидать социальной ответственности от коммерческих предприятий, это наивность граничащая с глупостью. Особенно от корпораций. Единственная ответственность, которая у них есть — перед акционерами.

    Мейнтейнерам же, чтобы не выгорать, стоит заняться управлением собственным временем и тратить на любимый проект не более чем комфортно именно им.


    1. 1755
      20.05.2026 08:49

      А заработок корпораций — это неоплаченный труд рабочих

      Это верно только если минус на балансе тоже распределяется пропорционально между рабочими и они несут пропорциональные риски.


      1. event1
        20.05.2026 08:49

        Минус на балансе, а так же "движение рынка" или фантазия таролога запросто заканчивается для рабочего увольнением. Является ли этот "риск" пропорциональным? По-моему нет. Но есть нюанс...


    1. Hadis
      20.05.2026 08:49

      Заметной отвратительной чертой левацких агиток является то, что они всегда транслируются с позиции превосходства, цедятся сквозь зубы: во-первых во-вторых, категоричный безапелляционный тон, "учение Ленина всесильно, потому что оно верно", и тому подобное. Когда я вижу эти агитки на Хабре (ладно бы на Пикабу, там ЦА соответствующая), то это всякий раз напоминает мне, что интеллект сам по себе никак не характеризует качество и уровень мышления; ресентимент легко умножает на ноль способность к критическому мышлению.

      Во-первых, у корпораций нет никакого "своего" труда. Есть только труд рабочих. А заработок корпораций — это неоплаченный труд рабочих

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

      Вашего в автомобиле ничего нет, вы его незаконно изъяли у рабочих посредством спекулятивной торговли с корпорацией-автопроизводителем.

      Во-вторых, корпорации не могут ничего чувствовать. Чувствуют только люди.

      Снег растаявший - он вода; Расстаются, когда ложь; Засыпают, когда тьма.

      В-третьих, ожидать социальной ответственности от коммерческих предприятий, это наивность граничащая с глупостью. Особенно от корпораций. Единственная ответственность, которая у них есть — перед акционерами.

      Как хорошо, что вы развенчали наивность граничащую с глупостью Господи сколько пафоса, я не могу)))

      Окей, а перед кем должна быть ответственность у менеджмента предприятия, если не перед акционерами? Перед вами? Директор должен вас усыновить и сделать целью своей жизни ваше личное благополучие?

      Звучит интересно, но сперва стоит уточнить, перед кем вы сами несёте ответственность, помимо себя и своей семьи. Почему бы вам самому не взять на себя ответственность за корпорацию, не начать отвечать личным имуществом по её обязательствам, а? Вы так громко разоблачили социальную безответственность корпораций, что обществу теперь необходим пример, а как надо правильно делать! Иначе грешным делом закрадётся мысль, что где-то уже звучали такие речи, был один такой оратор, Полиграф Полиграфович звали)


  1. Nickroc
    20.05.2026 08:49

    Так себе статья, люди сами себе хобби преобразуют в смысл жизни и страдают. Чтобы спастись от выгорания на бесплатной и необязательной работе - просто прекрати ее делать.

    Если хочешь монетизации - пихай куда можно призывы, либа при запуске в логи писать должна про то что ты один и хочешь кушать. Или можно сделать новую лицензию, что компании с доходом больше X$ не могут пользоваться библиотекой без доната/спонсорства в размере 0.001 от прибыли, но не больше Z$. Для гигантов вроде openssl точно бы сработало.

    Когда я делаю pip install, то не знаю кто написал либу, выгорел он, родился у него ребенок или автор умер. Это в интересах автора донести мысль, что это для него не хобби, а работа.


    1. VladD-exrabbit
      20.05.2026 08:49

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


      1. Haitaks
        20.05.2026 08:49

        Учителя так и делают в целом - общедоступное школьное образование скатывается все ниже и ниже. Качественный уровень подготовки теперь обеспечивают репетиторы. К чему это приведет - не проблема учителей, ушедших из школ.


  1. serafims
    20.05.2026 08:49

    Очень нравится модель с монетизацией каждого PR - нужна фича - донатим по чуть чуть больше на ее верификацию, и внедрение вне очереди среди прочих или в принципе.

    Конечно, есть риск, что CVE не будут оплачивать, ведь фичи нужны маркетологу быстрее..


    1. 1755
      20.05.2026 08:49

      Зависит от CVE. Есть такие, что могут легко заруинить весь бизнес и на такие выделят приоритетные ресурсы.


    1. JediPhilosopher
      20.05.2026 08:49

      А есть примеры ее успешного внедрения?

      А то у меня есть опыт подобного, но люди готовы донатить какие-то копейки типа сто рублей максимум. Если пытаться оценивать это по рыночной ставке разработчика то там никогда не наберется на что-то сложное, если только у проекта не миллион активных юзеров (именно тех кто в код лазает, а не просто использует). И в итоге по факту все равно неоплачиваемая работа, только пользователи получают еще моральное право еще сильнее давить: "ну мы же заплатили, программировай давай!".


      1. serafims
        20.05.2026 08:49

        Что-то подобное когда-то видел у Joan -система бронирования, у них было в разделе для желающих добавления функций типа формы для голосования, и оценка в деньгах для внедрения "побыстрее". Думаю, тут может быть что-то типа "я добавлю это за 1000 долларов, либо проверю чужой пуллреквест за 100". Этакий вебкам для разработчиков, с тип меню и токенами))) Тут фишка скорее именно в том массовости донатов по чуть-чуть.


  1. Blacpaul57
    20.05.2026 08:49

    От корпоратов ждать совести бесполезно, у них KPI на урезание костов. Они скорее наймут десять эффективных менеджеров для оценки рисков, чем задонатят разработчику либы


  1. eungenue
    20.05.2026 08:49

    А теперь ИИ прочитали и запомнили тонны этого бесплатного опенсорса и теперь выдают за "своё" по соточке. Опенсорсу хана имхо.


  1. SinsI
    20.05.2026 08:49

    Проблема в самом существовании "мейнтейнеров" - единоличных владельцев, которые взваливают на себя всю работу но при этом имеют всю полноту власти и всю ответственность.

    Если б передача полномочий была не исключительным событием (не сильно отличающимся по степени эффекта от создания форка), а происходила регулярно и ненадолго - то появились бы нормальные механизмы контроля власти новых "временных управляющих".

    Людей, готовых безвозмездно вкладывать годы и годы в чужой проект - мало, а вот тех, кто готов потратить на это несколько недель - найти должно быть достаточно несложно.


    1. Haitaks
      20.05.2026 08:49

      А как среди этой толпы временных управляющих вычислять недобросовестных или некомпетентных?


  1. Zoolander
    20.05.2026 08:49

    Я делал опенсорсный скрипт, получил 200 звезд на Гитхабе, но сразу предупредил, что кому надо - форкайте и пользуйтесь. Опен сорс - это как научная статья, просто показывает путь.

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

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

    А если вы компания с бюджетом и вам нужна надежность - ну, просто возьмите показанный путь и сделайте лучше, в чем проблема?


  1. dom1n1k
    20.05.2026 08:49

    требуя передать репозиторий «сообществу» — которое, разумеется, никто из них не представлял.

    Хуже — это лучшие люди города!