Главная » Хабрахабр » [Перевод] Де-факто закрытые исходники: аргументы в пользу понятного софта

[Перевод] Де-факто закрытые исходники: аргументы в пользу понятного софта

По следам истории «Бэкдор в одной из зависимостей библиотеки EventStream» — прим. пер.

Меня как давнего сторонника FOSS исключительно удручает то, что происходит в последние несколько лет с разными сообществами FOSS (за некоторым исключением, конечно).

Рассмотрим один из последних эпизодов в саге индустрии open source, которая понятия не имеет, что она делает в целом:

Скорее всего, в ваших зависимостях много других модулей, заброшенных авторами. Это не какой-то уникальный случай. Я учился, а учиться весело. Я писал этот код не ради альтруизма, а для развлечения. Думаю, что большинство небольших модулей на npm созданы по тем же причинам. Я опубликовал его, потому что это было легко сделать и потому что обмен кодом тоже помогает учиться. С тех пор я перешёл от этого модуля к другому, а потом ещё к одному, а сейчас в процессе перехода и от него. Однако это было очень давно. Я написал намного лучшие модули, чем этот, интернет просто не полностью догнал.

— @dominictarr, в заявлении о бэкдоре в библиотеке event-stream

TL;DR: Тарр отказался от поддержки своего популярного пакета для node.js. Ни один нормальный пользователь не захотел взять поддержку на себя, даже кто использовал библиотеку в своих проектах. Тарр передал пакет «полезному» незнакомцу, который сразу же монетизировал его с помощью кражи криптовалюты. Мнения публики разделились.
Наверное, у «полезного» незнакомца был удачный день. А вот для Тарра не очень. На которого свалилась куча дерьма со всего интернета за передачу пакета незнакомцу без проверки. Мне совершенно непонятно, как он мог осуществить передачу на 100% безопасным способом, но давайте предположим, что такое возможно.

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

Так, как это делается в корпоративном мире.

Такая логика быстро заводит нас в тупик, ведь публикация даже небольшого фрагмента кода становится невыгодной.

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

Это значит, что в любой момент времени любой мейнтейнер FOSS может заменить свой код чем угодно, будь то криптомайнер или console.log("ur mom, lol"), сделать его недоступным постоянно или только по вторникам и полнолуниям, а также, как и с любым имуществом, передать его кому-либо, не спрашивая вашего мнения. Так что это значит?

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

Нам ведь нужно выпускать какие-то модные новые веб-приложения. Но ни у кого нет на это времени, верно? Нет, это мейнтейнеры FOSS должны придерживаться более высоких стандартов, чтобы мы больше им доверяли! Нет времени читать весь код с 40 000 зависимостей, если у нас нет времени даже на свои модульные тесты. Как они посмели на нас наплевать?!

Вот в чем дело:

FOSS никогда не говорил о доверии к мейнтейнерам.

Для начала не нужно было им доверять.

Код — единственное, чему вы можете доверять, если хотите знать, что делает программа, что происходит с бизнесом или почему ваша система — уже не та, что создавалась изначально.

Не читая его, вы утратили самое важное преимущество этой экосистемы: возможность не доверять авторам в отношении поведения или неизменности кода. Код — единственное, чему вы можете доверять.

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

Если вы не собираетесь в полной мере использовать FOSS, может лучше потратить свои деньги на поддержку? Но как это отличается от использования несвободных программ? Может, даже сможете подать на кого-то в суд! По крайней мере, вы сможете жаловаться до посинения.

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

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

Вот что меня огорчает больше всего.

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

Экосистема FOSS извлекает огромную пользу из прочной базы доверия, поскольку та позволяет распределить работу. В таких условиях не удивляет тот факт, что некоторые акценты смещаются в сторону доверия.

В настоящее время это надежда и принятие желаемого за действительное. Но на самом деле это не доверие.

Конечно, я не могу в одиночку проверить всё ядро, тем более весь остальной код, патчи и скрипты сборки для всех пакетов для всех этих дистрибутивов. Я использую много дистрибутивов Linux. Я провожу аудит только тех частей, которые меня больше всего интересуют, и я надеюсь, что: 1) мейнтейнеры дистрибутивов не действуют из зловредных побеждений; 2) если так, кто-нибудь другой проверит части, которые я не посмотрел; 3)  если кого-то интересуют те же части, что и меня, он выловит баги, которые от меня ускользнули.

Это рисует мрачную картину будущего, когда количество строк кода или патчей намного опередит рост числа разработчиков и мейнтейнеров.

Как же этого избежать?

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

Вот ещё один мысленный эксперимент: может ли новый (но опытный) разработчик за 2 недели (80 часов) понять 80% кодовой базы, за которую он будет отвечать?

Если он уходит, вы никак не сможете подготовить замену в положенный срок. Если нет, то этот человек перегружен работой с первого дня, поскольку он по определению не сможет передать свои обязанности в течение стандартного для США периода времени. Как следствие, плавный переход невозможен, а некоторые знания о предметной области неизбежно будут потеряны.

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

Суть FOSS для сводится к одному фундаментальному праву: праву отказаться от выполнения на моих машинах кода, который я не имею возможности понять. Программное обеспечение должно быть понятным. Вот и всё.

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

Я принципиально не против софта с закрытым исходным кодом, но только если он работает на чужом компьютере.

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

В конце концов, они поддерживают вас. И если упомянутые «услуги» основаны на FOSS от частных лиц, то рассмотрите возможность поддержки этих людей. Они не могут пожаловаться, если вы их не поддерживаете, но и вы не можете жаловаться, когда что-то идёт не так.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Векторные представления товаров, или еще одно применение модели Word2Vec

Когда видов товаров тоже много, решить задачу помогает модель Word2Vec. Каждый день полтора миллиона людей ищут на Ozon самые разные товары, и к каждому из них сервис должен подбирать похожие (если пылесос все-таки нужен помощней) или сопутствующие (если к поющему ...

[Перевод] Внутренняя и внешняя линковка в C++

Всем добрый день! Надеемся, что она будет полезна и интересна для вас, как и нашим слушателям. Представляем вам перевод интересной статьи, который подготовили для вас рамках курса «Разработчик C++». Поехали. Хотите узнать, для чего используется ключевое слово extern, или как ...