[Перевод] Де-факто закрытые исходники: аргументы в пользу понятного софта
По следам истории «Бэкдор в одной из зависимостей библиотеки EventStream» — прим. пер.
Меня как давнего сторонника FOSS исключительно удручает то, что происходит в последние несколько лет с разными сообществами FOSS (за некоторым исключением, конечно).
Рассмотрим один из последних эпизодов в саге индустрии open source, которая понятия не имеет, что она делает в целом:
Это не какой-то уникальный случай. Скорее всего, в ваших зависимостях много других модулей, заброшенных авторами. Я писал этот код не ради альтруизма, а для развлечения. Я учился, а учиться весело. Я опубликовал его, потому что это было легко сделать и потому что обмен кодом тоже помогает учиться. Думаю, что большинство небольших модулей на npm созданы по тем же причинам. Однако это было очень давно. С тех пор я перешёл от этого модуля к другому, а потом ещё к одному, а сейчас в процессе перехода и от него. Я написал намного лучшие модули, чем этот, интернет просто не полностью догнал.
— @dominictarr, в заявлении о бэкдоре в библиотеке event-stream
TL; DR: Тарр отказался от поддержки своего популярного пакета для node.js. Ни один нормальный пользователь не захотел взять поддержку на себя, даже кто использовал библиотеку в своих проектах. Тарр передал пакет «полезному» незнакомцу, который сразу же монетизировал его с помощью кражи криптовалюты. Мнения публики разделились.
Наверное, у «полезного» незнакомца был удачный день. А вот для Тарра не очень. На которого свалилась куча дерьма со всего интернета за передачу пакета незнакомцу без проверки. Мне совершенно непонятно, как он мог осуществить передачу на 100% безопасным способом, но давайте предположим, что такое возможно.
Но это означает, что автор любого пакета или приложения FOSS после публикации его в интернете принимает на себя ответственность за любое неправомерное использование указанного программного обеспечения. Как минимум до тех пор, пока автор не сможет старательно и торжественно передать эту ответственность кому-то другому, словно горячую картошку.
Так, как это делается в корпоративном мире.
Такая логика быстро заводит нас в тупик, ведь публикация даже небольшого фрагмента кода становится невыгодной.
Проведём мысленный эксперимент. Предположим, что сам Тарр решил добавить новую «функцию» криптомайнера в свой собственный пакет. Чёрт, в конце концов, это всего лишь один из многих способов монетизации FOSS. Согласен, это будет нехорошо выглядеть в его резюме, но самое интересное, что такие действия полностью законны. Также не исключено, что если всё сделать правильно, никто долгое время ничего не заметит.
Так что это значит? Это значит, что в любой момент времени любой мейнтейнер FOSS может заменить свой код чем угодно, будь то криптомайнер или console.log("ur mom, lol"), сделать его недоступным постоянно или только по вторникам и полнолуниям, а также, как и с любым имуществом, передать его кому-либо, не спрашивая вашего мнения.
С другой стороны вы, продвинутый пользователь FOSS, наделённый властью бинарного копирования и четырьмя свободами GPL, говорите: «Ну что ж, не сегодня» и достаёте свою собственную, правильную копию программного обеспечения, вносите нужные изменения и дальше, если хотите, публикуете эту модифицированную версию кода.
Но ни у кого нет на это времени, верно? Нам ведь нужно выпускать какие-то модные новые веб-приложения. Нет времени читать весь код с 40 000 зависимостей, если у нас нет времени даже на свои модульные тесты. Нет, это мейнтейнеры FOSS должны придерживаться более высоких стандартов, чтобы мы больше им доверяли! Как они посмели на нас наплевать?!
Вот в чем дело:
FOSS никогда не говорил о доверии к мейнтейнерам.
Для начала не нужно было им доверять.
Код — единственное, чему вы можете доверять, если хотите знать, что делает программа, что происходит с бизнесом или почему ваша система — уже не та, что создавалась изначально.
Код — единственное, чему вы можете доверять. Не читая его, вы утратили самое важное преимущество этой экосистемы: возможность не доверять авторам в отношении поведения или неизменности кода.
Вы хотите бесплатно скачать тысячи строк полезного, но случайного кода из интернета, запустить его на производственном веб-сервере или, что ещё хуже, на машине вашего пользователя, доверить этому коду данные ваших платных пользователей — и наслаждаться успехом. Мы все такое любим. Но вы не хотите проверять лицензию и понимать программное обеспечение, на котором работаете, и по-прежнему обвиняете людей, которые обеспечивают ваш бизнес, когда случаются ошибки, не давая им ничего взамен? Это одновременно и некомпетентность, и ваше право.
Но как это отличается от использования несвободных программ? Если вы не собираетесь в полной мере использовать FOSS, может лучше потратить свои деньги на поддержку? По крайней мере, вы сможете жаловаться до посинения. Может, даже сможете подать на кого-то в суд!
Ваша система — это ваша ответственность, и вы обязаны своим пользователям, особенно если они платят. Эта ответственность не меняется, когда вы решаете взять чей-то код, чтобы не писать его самостоятельно, тем более бесплатно. Это не означает, что экосистема FOSS не выигрывает от высокой степени доверия (она это делает), однако она может работать и нормально работала без этой новой концепции доверия, потому что мы привыкли делать всё трудным способом: доверять путём проверки, изменения, а затем компиляции.
Я могу ошибаться, но в миллионах загрузок event-stream, а это 1500 зависимых пакетов, должно быть не менее пяти компаний, которые могли бы выделить 1 час разработчика в неделю на поддержку event-stream.
Вот что меня огорчает больше всего.
Возможно, мы достигли этапа, когда FOSS больше не представляет собой то, что раньше, просто потому его слишком много. Слишком много строк кода, слишком много конкурирующих решений, слишком быстрая скорость изменений. Мы хотим, чтобы обновления безопасности поступали прямо из апстрима, но как мы будем проводить аудит каждую неделю?
В таких условиях не удивляет тот факт, что некоторые акценты смещаются в сторону доверия. Экосистема FOSS извлекает огромную пользу из прочной базы доверия, поскольку та позволяет распределить работу.
Но на самом деле это не доверие. В настоящее время это надежда и принятие желаемого за действительное.
Я использую много дистрибутивов Linux. Конечно, я не могу в одиночку проверить всё ядро, тем более весь остальной код, патчи и скрипты сборки для всех пакетов для всех этих дистрибутивов. Я провожу аудит только тех частей, которые меня больше всего интересуют, и я надеюсь, что: 1) мейнтейнеры дистрибутивов не действуют из зловредных побеждений; 2) если так, кто-нибудь другой проверит части, которые я не посмотрел; 3) если кого-то интересуют те же части, что и меня, он выловит баги, которые от меня ускользнули.
Это рисует мрачную картину будущего, когда количество строк кода или патчей намного опередит рост числа разработчиков и мейнтейнеров.
Как же этого избежать?
Мы должны упростить программное обеспечение. Сделать его намного проще. И компании, которые предлагают свои услуги на основе программного обеспечения с открытым исходным кодом, должны принимать более активное участие в поддержании этой экосистемы.
Вот ещё один мысленный эксперимент: может ли новый (но опытный) разработчик за 2 недели (80 часов) понять 80% кодовой базы, за которую он будет отвечать?
Если нет, то этот человек перегружен работой с первого дня, поскольку он по определению не сможет передать свои обязанности в течение стандартного для США периода времени. Если он уходит, вы никак не сможете подготовить замену в положенный срок. Как следствие, плавный переход невозможен, а некоторые знания о предметной области неизбежно будут потеряны.
Можете изменить указанные выше цифры для конкретных стран, но основная предпосылка остаётся неизменной. Ни в одной другой отрасли людям не позволяют работать с вещами, которые они не понимают, а тем более разрабатывать их.
Программное обеспечение должно быть понятным. Суть FOSS для сводится к одному фундаментальному праву: праву отказаться от выполнения на моих машинах кода, который я не имею возможности понять. Вот и всё.
Конечно, есть преимущества информационной безопасности, экономические выгоды и некоторые другие, которые я не могу вспомнить прямо сейчас. Но если вы пытаетесь доказать, что для онлайн-системы сдачи налоговой декларации моей страны нормально требовать Adobe Flash и передачи этого перегруженного непрозрачного блоба в мой браузер, то вы получите ответ «публичные деньги, публичный исходный код», с изумлением имея в виду «матерь божья, как вы дышите».
Я принципиально не против софта с закрытым исходным кодом, но только если он работает на чужом компьютере.
Однако мы видим, что наличия исходного кода недостаточно, чтобы гарантировать понятность. Поэтому крайне важно, чтобы индустрия ПО немного притормозила с фейерверком новых функций, а больше внимания уделила стабильности, безопасности, конфиденциальности пользователей и пониманию собственных систем, которые лежат в основе всего. Это абсолютный минимум, что может сделать ответственная компания, особенно если она с радостью берёт с людей деньги за свои «услуги».
И если упомянутые «услуги» основаны на FOSS от частных лиц, то рассмотрите возможность поддержки этих людей. В конце концов, они поддерживают вас. Они не могут пожаловаться, если вы их не поддерживаете, но и вы не можете жаловаться, когда что-то идёт не так.
