Книга «Open Source. Разработка программ с открытым исходным кодом»

Привет, Хаброжители! Наши представления об открытом исходном коде сильно отличаются от того, что происходит на самом деле. Оптимистичная модель общественного сотрудничества давно ушла в прошлое, теперь — это царство одиночек. Еще совсем недавно информация была качественной, и работало правило — чем ее больше, тем лучше. Внезапно информации стало слишком много. Чем больше уведомлений на нас сыпется, тем меньше мы обращаем на них внимания. В мире программного обеспечения с открытым исходным кодом все происходит точно так же. Работа подразумевает коллективное взаимодействие, но пишущие и публикующие код разработчики настолько перегружены разнообразными запросами, что просто перестают на них реагировать. Open Source — это «дороги и мосты» цифрового мира. Старт работ всегда связан с большим вложением сил и средств, но каждый дополнительный пользователь обходится относительно дешево. Мы не замечаем их пока все нормально, воспринимаем как что-то должное, но большинство таких проектов создаются энтузиастами. Как современному творцу разработать стратегию, создать продукт, обеспечить поддержку и заработать? Надья Эгбал проанализировала платформу GitHub, чтобы рассказать нам что такое современные проекты с открытым исходным кодом, который пишут отдельные разработчики, а используют миллионы.

Cкрытые издержки программного обеспечения

Три основных типа затрат, связанных с программным обеспечением, это затраты на его создание, распространение и поддержку.

Процесс создания обычно мотивирован изнутри. Здесь речь идет о фиксированных затратах на «первую копию». Распространение происходит через платформы, которыми пользуются творцы. Из-за масштабности обходится оно недорого или вообще бесплатно. Но ситуация с поддержкой до сих пор остается загадкой. Затраты на обслуживание программы обычно ложатся на плечи ее создателя. Но как мы уже видели, внутренняя мотивация здесь отсутствует.

Затраты на обслуживание ПО делятся на предельные (зависят от количества пользователей) и временные (связанные с энтропией или ухудшением кода со временем).

Считается, что информационные товары имеют нулевые или незначительные предельные издержки. Это означает, что даже если производство первой единицы товара стоит дорого, каждая дополнительная единица будет дешевле (информационные товары — те, ценность которых определяется информацией в них, например статьями, книгами, музыкой или кодом).
На затраты человека, опубликовавшего свой код на платформе GitHub, никак не повлияет количество тех, кто пользуется результатами его работы.

Дэвид Хайнемайер Ханссон, доказывая, почему мы не должны думать о программном обеспечении в контексте рынка, использует нулевые предельные издержки:

Магия программного обеспечения — в почти полном отсутствии предельных издержек! Это экономическая реальность, на базе которой Гейтс построил империю Microsoft. Именно она позволила Столлману «раздать» свое свободное ПО (хотя и с оговорками). Любители бесплатного ничего нам не стоят, ведь истощения ресурса, о котором стоило бы беспокоиться, не происходит.

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

Предельные издержки

Мы считаем, что у ПО нулевые предельные издержки из-за следующих свойств. Их совокупность удешевит производство дополнительных копий:

— Неконкурентность: если я загружу код с GitHub, это никак не повлияет на возможность других людей загрузить тот же код (а вот если откусить от яблока и передать его другому, ему достанется меньше);

— Неисключаемость: если у человека есть копия моего кода, мне трудно запретить ему делиться ею с другими (но если я построю тематический парк, я могу установить турникет и брать плату за вход).

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

Естественное общее достояние в основном ограниченно и постепенно расходуется (леса могут быть спилены, грунтовые воды могут истощиться), но цифровое общее достояние носит по большей части социальный и информационный характер. Обычно в нем содержатся неконкурентные товары, которыми можно пользоваться и делиться, не истощая ресурсы.

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

Конкурентность и исключаемость экономических благ

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

Представьте дорогу, на которую в час пик выезжает огромное количество автомобилей. При переходе от одного пользователя ПО к двум предельные издержки настолько малы, что их невозможно обнаружить. Но чем больше будет пользователей, тем вероятнее пользователь N начинает влиять на возможность доступа пользователя N + 1 к программному обеспечению. Если программой начнут пользоваться не десять человек, а десять тысяч, разница станет ощутимой.

Физическая инфраструктура

Для надежного обслуживания большой аудитории без простоев, попыток взлома и перерывов программному обеспечению нужна физическая инфраструктура. Сегодня эти расходы берут на себя центральные провайдеры, но это не делает затраты на инфраструктуру менее реальными. При этом провайдеры делают все, чтобы скрыть их от пользователей. Сегодня мало кто хранит выкладываемые в Сеть материалы на своем сервере. Ведь публикация на платформах Medium или GitHub позволяет не думать о стоимости размещения, а за загрузку фото- или видеоматериалов в Instagram или на YouTube платят сами платформы.

Облачные сервисы упростили процедуру обновления инфраструктуры, позволив не прерывать обслуживание. Любой может хранить свои фотографии в iCloud или файлы на Google-диске, оплачивая только дополнительное место, так и для обновления инфраструктуры ПО достаточно нескольких кликов на сайте Fastly, Cloudflare или Netlify. Такие крупнейшие провайдеры, как Amazon Web Services и Microsoft Azure, сделали размещение очень дешевым или даже бесплатным.

Но размещение все еще может быть дорогим. По оценкам мейнтейнера диспетчера пакетов Python PyPI Дональда Стаффта, стоимость предоставленной провайдером Fastly инфраструктуры для размещения этого проекта составляет от двух до трех миллионов долларов в год. Все больше разработчиков начинают использовать PyPI, и затраты на проект растут. Стаффт указывает, что в апреле 2013 года проект PyPI использовал общую пропускную способность 11,84 Гбайт. К апрелю 2019 года эта цифра увеличилась до 4,5 Пбайт. Вот пример поменьше. Размещение проектов с открытым исходным кодом на арендованном сервере обходится разработчику Дрю Де Волту в 380 долларов в месяц. Эту сумму он оплачивает из пожертвований пользователей.

Технический директор Amazon и архитектор Amazon Web Services Вернер Фогельс описывает, как при масштабировании меняются предельные затраты на физическую инфраструктуру:

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

Распределенные атаки типа «отказ в обслуживании» или DDoS-атаки — одна из ситуаций, при которых выходит на поверхность стоимость физической инфраструктуры. При DDoS-атаке злоумышленник останавливает работу сервера, перегружая его запросами. Жертвами крупных DDoS-атак становились как DNS- (управляющие доменными именами), так и CDN-провайдеры (хранящие данные, например, файлы и мультимедиа) и другие критически важные службы. Две крупнейшие DDoS-атаки в истории были направлены против платформы GitHub: в 2015 и в 2018 годах.

Постоянные высокие затраты на физическую инфраструктуру тоже объясняют, почему мы рассматриваем экономию масштаба как адаптивный механизм. Если бы потребление ПО действительно имело нулевые предельные издержки, любой смог бы легко поддерживать свою версию GitHub. Но единая платформа гораздо эффективнее может управлять кодом, безопасностью, инфраструктурой, поддержкой и всем, что связано с сопровождением программного продукта. Разработчики предпочитают платформу GitHub инструменту GitLab не только из-за сетевого эффекта, но и из-за большей безопасности и надежности. По этим же причинам люди используют продукты Google вроде Gmail или Google Docs вместо аналогичных продуктов какого-нибудь стартапа. Для хорошей работы таких сервисов нужны деньги и трудовые резервы.

Наконец, существуют предельные издержки, связанные с инструментами поддержки программного обеспечения. К примеру, разработчики могут использовать программу отслеживания ошибок Sentry, инструмент для управления конфигурацией Puppet или Chef или систему оповещения PagerDuty, и за все эти программы нужно платить.

Поддержка пользователей

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

Если продукт непривлекателен для пользователя, то поддержка будет недорогой. Подавляющее большинство пользователей просто загрузят код, никак себя не проявив.

Но по мере роста привлекательности стоимость поддержки может сильно вырасти. Допустим, она нужна только 0,1 % пользователей. Если продукт используют тысяча человек, то поддержка будет нужна всего одному. Но 0,1 % от миллиона — это тысяча. Как видите, разработчику совсем не все равно, сколько человек используют его ПО: тысяча или миллион. У Facebook нет линии поддержки пользователей, потому что этой социальной сетью в месяц пользуются более двух миллиардов человек. В итоге поддерживать пользователей становится сложнее по сравнению с компаниями, которые работают с физическими товарами. Менеджер по продукту в Google Девитт Клинтон рассказывает об этом так:

Пусть у компании миллиард пользователей, и у 0,1 % из них возникает проблема, требующая обращения в службу поддержки (в среднем на человека приходится один такой случай раз в три года). На решение проблемы уходит около 10 минут. В этом случае на поддержку пользователей каждый день будет уходить 19 человеко-лет.

С учетом того, что сотрудник службы поддержки каждый день работает по восемь часов, для обслуживания всех поступающих запросов нужен постоянный штат в 20 833 человека.
Да, ребята, в интернете именно такие масштабы.

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

Вот как описывает свой опыт работы в службе поддержки пользователей мейнтейнер проекта PouchDB Нолан Лоусон:

У вашей двери очередь из нескольких сотен человек. Они терпеливо ждут, когда вы ответите на их вопросы, жалобы, запросы на включение и на новый функционал…
Когда появляется свободное время, вы открываете дверь для первого в очереди. Он исполнен благих намерений. Он пытался использовать ваш проект, но запутался в API, вставил свой код в комментарий GitHub, но забыл или не знал, как его отформатировать, поэтому его код — нечитаемая каша…

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

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

Но в книге «Мифический человеко-месяц», увидевшей свет за два десятилетия до заявления Рэймонда, Фред Брукс иронично пишет, что, несмотря на постулат «чем больше пользователей, тем больше ошибок они находят», рост их числа сильно увеличивает стоимость поддержки. По мере того как программой с открытым исходным кодом начинает пользоваться все больше людей, растет число вопросов и обнаруженных ошибок, но при этом нужен кто-то, кто будет читать, анализировать и обрабатывать все присылаемые отчеты.

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

Модерация сообщества

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

Во всех популярных лицензиях на ПО с открытым исходным кодом есть пункт «как есть». Он снимает с авторов ответственность в случае ущерба, причиненного в результате использования кода. В лицензии MIT, самой популярной на сегодня среди проектов GitHub, говорится:

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

Конечно, поставщики ПО не хотят ассоциироваться с нежелательным контентом, ведь это сулит проблемы в будущем. Но здесь речь не о «материальных» затратах на производство (если программное обеспечение выйдет из строя, никто не сможет получить к нему доступ). Модерирование сообщества — это «нематериальные» затраты, которые предписываются социальными нормами (их можно игнорировать на свой страх и риск).

Если платформа или проект станут неприятным местом, люди начнут уходить. В 2017 году GitHub провела опрос пользователей проектов с открытым исходным кодом. Он показал, что пятая часть респондентов перестала участвовать в проекте после того, как они прочувствовали негативное поведение по отношению к себе или стали его свидетелями.

Временные издержки

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

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

Техническое обслуживание составляет значительную часть скрытых затрат на программное обеспечение. Исследование компании Stripe в 2018 году показало, что 42 % своего времени разработчики тратят на поддержку кода. Профессор информатики Натан Энсменгер отмечает, что с начала 1960-х годов затраты на обслуживание составляют от 50 до 70 % всех расходов на разработку.

Технический долг

«Чище всего» код в момент его первого выпуска, потому что проект, который пишется «с нуля», воспринимается разработчиками как единое целое. По мере добавления кода программное обеспечение становится громоздким. Его можно сравнить со зданием 1850-х годов, куда постепенно добавляли новые комнаты, водопровод и электричество.

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

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

Рефакторинг — это процесс, путем которого разработчики закрывают технический долг, переписывая, упрощая или иначе очищая кодовую базу без изменения ее функциональности. Рефакторинг можно сравнить с редактированием рукописи книги. Зачастую это неприятная и неблагодарная работа. Разработчики программ с открытым исходным кодом — творческие люди, поэтому их проекты не только более подвержены накоплению технического долга, но и имеют меньше стимулов для приведения запутанного кода в порядок.

Самая большая проблема для проектов с открытым исходным кодом — это управление инфраструктурой тестирования. При разработке современного ПО часто практикуется непрерывная интеграция (continuous integration, CI), когда рабочие копии постоянно сливаются в основную ветвь разработки. Для снижения вероятности критических изменений прибегают к автоматическим тестам. Они показывают, «безопасен» ли предназначенный для слияния код (на GitHub это описывается выражением «сделать кнопку Merge зеленой»).

Запрос на включение, готовый к слиянию

Для управления разными аспектами сборки, тестирования и развертывания разработчики используют такие службы непрерывной интеграции, как Jenkins, Travis CI и CircleCI. Они особенно важны для проектов с открытым исходным кодом, куда добавляются вклады от неизвестных людей.

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

Но все они выполняются перед добавлением каждого запроса на включение в основной репозиторий, что занимает массу времени. Один мейнтейнер большого проекта с открытым исходным кодом жаловался, что для каждого запроса на включение запуск службы CI занимал полтора часа. При этом ожидалось, что он будет просматривать и объединять 40–50 запросов в день. Такие проблемы бывают и в компаниях, разрабатывающих проприетарное ПО. ­Инженер-программист из Uber Алан Зейно писал, что до обновления архитектуры «время сборки стремительно росло вместе с ростом компании. Общее время, потраченное сотнями инженеров в ожидании, пока CI внесет изменения в код, ежедневно исчислялось тысячами часов».

Более подробно с книгой можно ознакомиться на сайте издательства:
» Оглавление
» Отрывок

Для Хаброжителей скидка 30% по купону — OpenSource

• Обратите внимание, сейчас проходит Распродажа от издательства «Питер».