«При достаточном количестве глаз баги выплывают на поверхность», — Эрик Рэймонд.
Закон Линуса утверждает, что с достаточным количеством пользователей и достаточным количеством разработчиков, проверяющих код, ошибки в открытом коде будут найдены и постепенно исправлены, результатом чего станет более правильный и безопасный код в сравнении с закрытым/проприетарным программным обеспечением.
Книга «Факты и заблуждения профессионального программирования» ссылается на это как на восьмое заблуждение. В книге цитируется исследование, утверждающее, что частота, с которой находятся новые баги, не увеличивается линейно с количеством проверяющих. Я считаю, что факт того, что люди плохо справляются с поиском багов в программном обеспечении, должен быть очевиден любому разработчику. В то время, как очевидные баги типа синтаксических проблем или использования антипаттернов можно легко выловить на этапе проверки кода, многие другие баги могут быть раскрыты только при использовании программы.
Поэтому частью задачи становятся пользователи. Конечно, если баги были пропущены на этапе проверки кода, они будут найдены во время реального использования конечной программы, верно? Опять же, это оказывается не так. Как и в случае с проверкой кода, легко находятся только очевидные ошибки. Проблема, которая проявляет себя только при очешь специфических условиях или в тех условиях, которые неочевидны для конечного пользователя, может оставаться необнаруженной длительные периоды времени. Чем более сложной является программа, и чем более она выполняет задач для пользователя, тем труднее со стороны пользователя удостовериться в её правильности. Поскольку программы обычно выполняют задачи, которые для человека требуют куда больше времени, бывает очень сложно повторить процесс вручную для гарантии правильности.
Heartbleed иллюстрирует это правило: OpenSSL используется миллионами компаний по всему миру, многие из которых имеют конкретных инженеров программного обеспечения, работающих на полную ставку, обслуживая миллионы пользователей. И всё же эта дыра оставалась необнаруженной на протяжении почти двух лет и могла оставаться неизвестной, если бы команда безопасности не начала действовать.
Комментарий, который я видел на Hacker News пару дней назад хорошо подоводит итог:
Ложное заявление о «множестве глаз» распространяется не только на официальные проверки. Оно также несёт идею того, что степень окрытости проекта не особо важна в отношении привилегий чтения кода: не слишком важно, открыт проект или закрыт, в основном его будут проверять мейнтейнеры и их коллеги. В действительности в большинстве случаев в мире Open Source круг людей, которые на самом деле понимают конкретные коммиты, лишь ненамного больше, чем он мог бы быть при закрытом коде. Баги лишь ненамного чаще «выплывают на поверхность», если такое вообще случается. Факт того, что в случае с Heartbleed код проверялся лишь одним человеком, несмотря на открытость, лишь подтверждает это.
Таким образом, преимущества открытого кода относительно закрытого, касающиеся правильности и безопасности, является минимальными, если они вообще есть. Сила открытого программного обеспечения в возможности закрыть баг собственноручно, хотя в этом случае большинство людей (и разработчиков) ожидали официального исправления, поскольку исправление программных средств защиты данных и, особенно, уровня OpenSSL, проекта, известного сложностью своего кода, вне пределов возможностей большинства программистов.
Как показал Heartbleed, даже критические программные проекты, используемые большой частью Интернета, не всегда имеют ресурсы для профессиональной поддержки. Команда OpenSSL получает лишь 2000 долларов ежегодно посредством пожертвований. Мноиге статьи, касающиеся уязвимости Heartbleed, были написаны в обвинительном тоне, и пока никто не предположил, что эти люди работают добровольно в своё свободное время, выполняя то, что можно считать лишь неблагодарной общественной деятельностью.
Разработчик, который допустил появление этого бага, даже не является профессиональным программистом — он лишь доктор наук. Профессионалом же является тот, кто живёт за счёт своей деятельности. Даже несмотря на то, что он в состоянии помогать разработке очень специлизированной библиотеки уровня OpenSSL, нельзя ожидать от человека, занимающегося наукой, того же стандарта кода, как и от профессионалов, работающих в отрасли многие годы, — людей того уровня, которого мы ожидали видеть в качестве мейнтейнеров ключевых средств защиты данных.
Это и есть одна из сильных сторон и слабостей открытого программного обеспечения, заключающаяся в том, что любой может вносить свой вклад, несмотря на его биографию или профессионализм. Многие проекты с открытым кодом были созданы любителями, что является красотой и, одновременно, риском, о котором должны помнить пользователи.
В то время, как некоторые имеющие большое значение проекты имеют компаний-спонсоров, что позволяет иметь среди участников работающих в режиме полной занятости профессионалов, большинство проектов открытого программного обеспечения едва сводят концы с концами путём получения пожертвований. Я считаю, что предоставление миру open source тех же ресурсов, что и коммерческим программам, может быть лучшим свособом создать жизнеспособные проекты более высокого качества, что будет полезно для всех.
Для проектов, которые не получают помощи от компаний (а частные компании неподконтрольны обычным пользователям), доступны модели альтернативного существования типа Open-Core (к примеру, MySQL), а также услуги и кураторство (например, Red Hat). В большинстве случаев полагаться только на пожертвования может быть недостаточно.
Надеюсь, кто-то примется за дальнейшую разработку OpenSSL, поскольку проект важен для паутины Интернета. Если же нет, я надеюсь, что мейнтейнеры всерьёз задумаются над альтернативными моделями монетизации, которые позволят им поддерживать проект постоянно, если это то, чего они хотят. Я не уверен в этом.
Многие пользователи чувствуют, что им обязаны, даже несмотря на то, что они получают что-то бесплатно. На мейнтейнеров OpenSSL посыпалось множество жалоб и обвинений, хотя разработчики проделывали важную добровольную работу годами. Они бесплатно предоставляли библиотеку, которая позволяла частным лицам и компаниям шифровать свои передаваемые сообщения и защищать данные. Программисты работали в своё свободное время и без особого признания их усилий.
Некоторые зашли настолько далеко, что даже предположили, что Heartbleed был добавлен намеренно. Если вы только не сторонник теорий заговора, предположение, что выполняющие такой бесплатный труд люди стали бы вводить этот баг намеренно, звучит нелепо.
Правда в том, что программное обеспечение всегда будет иметь ошибки. Это то, что знает любой разработчик по своему опыту с первого дня работы. Неважно, сколько тестов было проделано, или как строго идёт процесс разработки, какие-то баги всегда будут проявляться. Можно уменьшить их число с помощью ресурсов, но вам никогда не избавиться от них польностью. Мог ли Heartbleed быть выловлен в процессе разработки, если бы все его мейнтейнеры работали над проектом в режиме полной занятости и имели больше времени для более строго тестирования и процесса проверки? Возможно, но мы никогда не узнаем этого.
Это то, о чём пользователи открытого программного обеспечения должны помнить. Баги будут существовать во всех программах, включая Open Source, также разработчики программ с открытым кодом обычно имеют куда меньше ресурсов для их поиска.
Поэтому вместо того, чтобы негодовать и бросяться обвинениями, будьте благодарны за бесплатные (в стоимости и процессе использования) инструменты, которые доступны вам. Если это возможно, возвращайте должное мейнтейнерам, чтобы продемонстрировать вашу благодарность и помочь поддержать их усилия. Если вы серьёзно зависите от использования решений на основе программ с открытым исходным кодом, мотивируйте их разработчиков работать над ними полный рабочий день, пусть даже это встанет вам в копеечку.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий