[Перевод] Судьба проекта с открытым кодом после смерти программиста
Вы, наверное, никогда не слышали о недавно умершем Джиме Вайрихе [Jim Weirich] или его программах. Но вы почти наверняка пользовались приложениями, построенными на основе его работы.
Вайрих помог создать несколько ключевых инструментов для Ruby, популярного языка программирования, код на котором написан для таких сайтов, как Hulu, Kickstarter, Twitter, и огромного числа других. Исходники его кода были открытыми, что означает, что использовать и изменять их могли все желающие. «Он был плодовитым членом западного сообщества Ruby», — говорит Джастин Сёрлс [Justin Searls], разработчик Ruby и сооснователь компании, разрабатывающей ПО, Test Double.
Когда Вайрих умер в 2014-м, Сёрлс заметил, что уже никто не поддерживает один из инструментов Вайриха для проверки софта. Это означало, что никто не будет одобрять изменения, если другие разработчики пришлют в проект исправления багов, патчи для безопасности или другие улучшения. Любые тесты, основывающиеся на этом инструменте, в итоге будут проваливаться, поскольку код устареет и станет несовместимым с новыми технологиями.
Этот случай отражает растущее беспокойство в сообществе ПО с открытым кодом. Что случается с кодом после смерти программиста? Уже написано много статей по поводу того, что случится в соцсетях с социальными учётными записями после смерти пользователя. Но для программистов эта проблема была не такой острой. Частично потому, что большая часть компаний и правительств полагается на коммерческое ПО, которое поддерживают команды людей. Но сегодня больше программ полагается на такое малоизвестное, но критически важное ПО, какое делал Вайрих.
Некоторые проекты с открытым кодом хорошо известны — ОС Linux или платформа искусственного интеллекта от Google TensorFlow. Но каждый такой проект зависит от более мелких библиотек с открытым кодом. А эти библиотеки зависят от других. В результате появляется сложная, по большей части скрытая сеть программных зависимостей.
Это может привести к большим проблемам, как случилось в 2014 году с уязвимостью в безопасности, получившей название Heartbleed, обнаруженной в OpenSSL — программе с исходным кодом, используемой практически всеми веб-сайтами, обрабатывающими платежи с банковских карт. Это ПО поставляется с большинством версий Linux, но его поддерживала небольшая команда добровольцев, у которых не было времени или ресурсов для всестороннего аудита безопасности. Вскоре после такого фиаско проблема с безопасностью была обнаружена в другой часто используемой программе с открытым кодом, Bash, из-за чего бесчисленное количество веб-серверов и других устройств оказались уязвимыми для атак.
Наверняка существует ещё больше нераскрытых уязвимостей. Группа людей, анализирующих связи между проектами ПО, Libraries.io, обнаружила более 2400 библиотек с открытым кодом, используемых по меньшей мере в 1000 других программ, и не получавших должного внимания со стороны open-source сообщества.
И недостатки в безопасности — лишь часть проблемы. Если библиотеки ПО не обновлять, они могут перестать работать с новыми программами. Это значит, что приложение, зависящее от устаревшей библиотеки, может перестать работать после обновления другого ПО. Когда разработчик умирает или бросает проект, могут пострадать все, кто зависят от этого ПО. В прошлом году, когда программист Азер Кочулу [Azer Koçulu] удалил крохотную библиотеку Leftpad из интернета [только не Leftpad, а left-pad, и не из интернета, а из системы хранения пакетов npm / прим. перев.], что привело к расходящемуся эффекту, добавившему головной боли поддержке Facebook, Netflix и других проектов.
Фактор автобуса
Чем меньшее число людей владеет частью кода, тем больше риск, что он останется без владельца. У разработчиков есть даже мрачный термин для таких случаев — фактор автобуса, означающий количество людей, которых должен сбить автобус перед тем, как проект некому будет поддерживать. Libraries.io определили порядка 3000 библиотек с открытым кодом, используемых во многих других программах, у которых число поддерживающих их программистов очень мало.
Осиротевшие проекты — это риск использования ПО с открытым кодом, хотя и коммерческие производители ПО могут оставить пользователя в таком же положении, перестав поддерживать или обновлять старые программы. В некоторых случаях ответственные программисты усыновляют осиротевшие проекты с открытым кодом.
Это сделал Сёрлс с одним из проектов Вайриха. Самые популярные его проекты на момент его смерти управлялись им совместно с кем-то ещё. Но Сёрлс нашёл один проект, инструмент для тестирования Rspec-Given, который никому не достался, и захотел взять на себя ответственность за его обновление. Но он столкнулся с некоторыми трудностями.
Rspec-Given обитал на популярном сайте для совместной работы и размещения кода GitHub, где расположено порядка 67 млн проектов. Страница Вайриха для Rspec-Given на GitHub была основным местом для того, чтобы другие люди могли сообщать об ошибках или предлагать помощь по улучшению кода. Но GitHub не хотел давать Сёрсу управление страницей, поскольку Вайрих не передал ему таких прав перед смертью. Поэтому Сёрлсу пришлось создать новую копию кода и разместить его в другом месте. Также ему пришлось уговорить операторов Ruby Gems, системы управления пакетами, распространяющей код, использовать его версию Rspec-Given вместо версии Вайнриха, чтобы у всех пользователей был доступ к изменениям, проделанным Сёрлсом. GitHub отказался комментировать свои правила по передаче управления проектами.
Это решило возможные проблемы, связанные с Rspec-Given, но открыло Сёрлсу глаза на то, как много всего может пойти не так. «Легко относиться к проектам с открытым кодом как к чисто техническому явлению, — говорит Сёрлс. — Но как только что-то взлетает, если от него зависит работа сотен других людей, оно становится ещё и социальным явлением».
У групп поддержки большинства систем управления пакетами есть по крайней мере один процесс передачи управления над библиотекой, но он обычно зависит от того, чтобы кто-нибудь заметил, что проект осиротел, и затем вызвался его поддерживать. «У нас нет официальных правил на этот счёт, поскольку такие проблемы не часто возникают», — говорит Иван Финикс из проекта Ruby Gems. «У нас есть экспертный совет, который решает подобные вопросы индивидуально».
Некоторые системы управления пакетами отслеживают библиотеки и отмечают широко используемые проекты, которые давно не обновлялись. Нил Бауэрс, помогающий поддерживать систему пакетов для языка программирования Perl, говорит, что иногда он ищет добровольцев для поддержки осиротевших проектов.
Триггер мертвеца
Получение контроля над Rspec-Given вдохновило Сёрлса, которому на тот момент было всего 30 лет, на написание завещания и плана передачи его проектов с открытым кодом. Разработчики могут предпринять и другие действия для обеспечения будущего своих проектов. Например, передать права какому-нибудь фонду, вроде Apache Foundation. Но многие проекты с открытым кодом часто начинаются как хобби, поэтому программисты могут не задумываться над передачей прав до тех пор, пока уже не будет поздно.
Сёрлс предлагает, чтобы GitHub и такие системы управления пакетами, как Gems, добавили себе «триггер мертвеца», позволяющий программистам автоматически передавать управление проектом или учётной записью кому-то ещё, если этот создатель не залогинивался или не вносил изменений в проект в течение определённого периода времени.
Но план передачи — это не просто открытие доступа к коду другим людям. Майкл Дротбом, взявший на себя разработку популярной математической библиотеки Matplotlib после смерти её создателя Джона Хантера в 2012-м, указывает на то, что преемникам нужно ещё и понять код. «Иногда в коде встречаются части, понятные только одному человеку, — говорит он. — Знание существует только в голове одного человека».
Это значит, что людей нужно привлекать в проект на ранней стадии, в идеале, сразу после того, как его начинают использовать другие люди, кроме разработчика. Сёрлс говорит, что у такого подхода есть ещё одно преимущество — распределение работы по поддержке проекта, помогающее избежать «выгорания» разработчика.
