Две популярные JavaScript-библиотеки с открытым исходным кодом — faker.js и colors.js — после обновления перестали работать: при попытке вызвать код из первой возникает ошибка, а вторая запускает бесконечный цикл с выводом в консоль слова «LIBERTY». Судя по твиттеру, разработчик Марак Сквайрс испортил библиотеки сознательно — и это не первый случай, когда популярное ПО с открытым исходным кодом неожиданно перестает работать по вине его создателей. Разбираемся, что делать, если подобная ситуация произошла с вашим приложением.
Что произошло
Faker.js — опенсорсный проект, который позволяет генерировать случайные данные для тестирования. Colors.js добавляет в консоль Node.js цвета и форматирование, чем помогает читаемости текста. По данным GitHub, где был опубликован исходных код обеих библиотек, faker.js за последнюю неделю скачали 2,4 млн раз, colors.js — 23 млн раз. По статистике GitHub, эти библиотеки используются в 19 тыс. проектов, среди которых, например, Amazon Cloud Development Kit.
4 января исходный код faker.js был удален с GitHub, а в описании библиотеки осталась одна строчка: «Что на самом деле произошло с Аароном Шварцем?». Спустя несколько дней перестала работать colors.js — теперь пакет заставляет любое приложение с зависимостью от него бесконечно отрисовывать последовательность случайных символов со словом «LIBERTY», записанным в три строчки.
В ответ на жалобы пользователей Марак Сквайрс писал, что знает о ситуации и обещал исправить проблемы. 7 января GitHub заблокировал разработчику доступ к его репозиториям.
Сквайерс никак не прокомментировал причины своего поступка. В 2020 году в своем твиттере он писал, что «больше не готов бесплатно поддерживать компании из списка Fortune 500 и потребовал либо выдать ему «контракт с шестизначной зарплатой, либо форкнуть проект и заниматься им самостоятельно». После удаления faker.js Сквайерс написал в твиттере «Что на самом деле произошло с Аароном Шварцем?» и приложил ссылку на Reddit, где осуждалась теория заговора о Шварце: якобы он был убит после того, как обнаружил детское порно на серверах Массачусетского технологического института.
Что-то подобное уже случалось?
В 2016 году произошла похожая ситуация — разработчик Азер Кочулу из-за конфликта с мессенджером Kik (это же название носил один из его пакетов) отозвал все 250 созданных им библиотек с открытым исходным кодом для Node.js из пакетного менеджера NPM. В результате менеджер фактически перестал работать — без созданного Кочулу left-pad он не смог установить зависимости между пакетами. Тогда руководство NPM отменило отзыв пакета и запретило удалять библиотеки старше 24 часов.
Читайте также: В Java нашли уязвимость, угрожающую сотням тысяч серверов. Разбираемся, в чем суть проблемы и как ее решить
Другая история произошла с аналогом faker.js для PHP, Faker. В 2019 году разработчики перестали поддерживать библиотеку, но сообщество сделало форк и продолжает её развивать.
Как защититься от таких ситуаций?
Существует несколько подходов:
- Бэкапы зависимостей. Например, инфраструктурые инженеры (девопсеры) используют подход, когда репозиторий вместе с кодом для изменения конфигурации содержит зависимости модулей и библиотек. Это помогает защититься в ситуации, если модуль будет внезапно удален. Но у такого подхода есть минус — пакеты реже получают обновления.
- Форк библиотеки. Как в ситуации с Faker, когда исходный код из основного репозитория был удален, а версия сообщества осталась и существует до сих пор.
- Дублирование библиотек. Хранение библиотек в корпоративной сети, например, в закрытом репозитории.
Как выбрать опенсорс-библиотеку
Основной риск при выборе пакета с открытым исходным кодом — высокая вероятность того, что в какой-то момент он перестанет поддерживаться и развиваться. Разработчики опенсорс-проектов крайне редко получают деньги за свою работу. Кроме того, они могут перегореть, заболеть или умереть. В этом случае либо в библиотеку перестанут вноситься изменения, либо, как в случае с Faker, будет удален исходный код.
Поэтому при выборе библиотеки стоит проверить, как часто происходят изменения в коде, как выглядят issue и pull request, участвует ли разработчик в жизни проекта или активно ли сообщество. Стоит обращать внимание на оценки и количество скачиваний: чем популярнее проект, тем выше вероятность того, что он будет развиваться и не будет удален.
Преимущество опенсорса заключается в том, что любой человек может скопировать код и изменить его. Чем больше сообщество у проекта, тем выше вероятность, что он будет существовать долго.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
