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

Тобиас Копперс (Tobias Koppers) не работает в Instagram. И никогда не работал. Но с 2014 года он отвечает за поддержку важного компонента веб-версии Instagram.

Копперс является создателем webpack — Open Source-инструмента для сборки (или «бандлинга») кода JavaScript. По сути, webpack позволяет разработчикам оптимизировать JavaScript-код, разбивая его на мелкие части, чтобы при запуске веб-приложения в первую очередь загружались наиболее важные куски кода. Это благоприятно сказывается на скорости работы, поскольку больше не нужно загружать веб-приложение целиком перед его использованием.

Webpack стартовал в 2012 году как часть академического проекта. Как и многие другие Open Source-проекты, он начинался с простого экспериментирования и попытки воплотить в жизнь свежие идеи. «Я работал над веб-приложением для магистерской диссертации по информатике и искал инструмент для оптимизации кода», — объясняет он в недавнем выпуске подкаста The ReadME. Недовольный тем, как другие инструменты разбивают код, Копперс написал свой собственный и опубликовал его на GitHub. «Я и раньше, бывало, "красноглазил" на благо Open Source'а, но у меня не было собственных проектов, поэтому затея показалась интересной», — говорит он.

Три года спустя бывший технический директор Instagram Пит Хант (Pete Hunt) заявил, что компания активно использует webpack. Это поставило Копперса в странное положение: он занимается поддержкой важной и в то же время практически невидимой части одного из самых популярных приложений в мире.

Работа webpack «под капотом» у Instagram — отличный пример того, что Open Source-код используется гораздо шире, чем представляет среднестатистический пользователь. Проприетарные приложения и веб-сервисы — даже самые неочевидные — полагаются на Open Source. Например, бесчисленные приложения для iOS, включая Hulu, Poshmark и TikTok, применяют сетевую библиотеку с открытым исходным кодом AlamoFire или ее предшественницу AFNetworking для загрузки изображений и данных, хотя пользователи никогда не взаимодействуют с этими библиотеками напрямую.

OS-софт часто сравнивают с чем-то материальным. Писатель и исследователь Надя Эгбал (Nadia Eghbal) называет Open Source «дорогами и мостами» цифрового мира. Но зачастую такой софт остается незамеченным для конечного пользователя.

Свободные библиотеки, такие как curl, — это скрытые источники энергии, и их существование не стоит принимать как должное. Как и всё материальное в нашем мире, Open Source-библиотеки требуют обслуживания и поддержки. curl включен в большинство дистрибутивов Linux и нуждается в периодическом обновлении для поддержки новейших веб-стандартов, как, например, и любой стандартный веб-браузер. «Многие не осознают, что curl — приложение, а не функция операционной системы, — говорит создатель curl Дэниел Стенберг (Daniel Stenberg). — А те, кто осознают, часто задаются вопросом: зачем мне заниматься его поддержкой?»

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

Испытания и невзгоды

Безопасность — самая важная причина позаботиться об Open Source-инфраструктуре. Независимо от того, является код свободным или проприетарным, он нуждается в аудите и обслуживании, иначе возникает угроза безопасности для любого ПО, которое его использует. Увы, большинство Open Source-проектов создаются энтузиастами, которые, как правило, работают над ними в свободное время. В результате у таких проектов нет ни надежной финансовой основы (например, для оплаты аудитов), ни гарантий нормальной работы. Весьма вероятно, что там нет никого, кто бы активно следил за уязвимостями и оперативно исправлял их.

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

Прим. перев. Кстати, эту проблему отчасти пытались решить в The Linux Foundation созданием инициативы Core Infrastructure Initiative (CII), которая со временем превратилась в Open Source Security Foundation (OpenSSF).

Программистам с полной занятостью необходимо платить зарплату. Пока что ни одна из моделей финансирования Open Source-проектов не зарекомендовала себя как универсальная, хотя этот вопрос был весьма актуальным в последние годы. Одни разработчики монетизируют свою работу с помощью стартапов. Другие полагаются на корпоративное спонсорство в вопросах разработки на full-time. Некоторые берут плату за дополнительные консультации и поддержку для финансирования своих программ и приложений. Развивая несколько лет curl исключительно на добровольных началах, Стенберг устроился в wolfSSL, тем самым обеспечив материальную поддержку своему проекту.

Прим. перев. И как тут, говоря о curl и его авторе, не вспомнить такое необычное происшествие, что мы переводили ранее в этом году…

Еще одна популярная модель финансирования включает работу над Open Source-проектами в обязанности разработчика. Для таких разработчиков, как Копперс, это идеальный вариант. Благодаря корпоративному спонсорству он смог бросить прежнюю работу и сосредоточиться на webpack. Работа на полную ставку в Vercel позволила ему заняться любимым делом. Некоторые компании признают зависимость бизнеса от надежности, безопасности и целостности свободных библиотек, нанимают maintainer’ов на полный или неполный рабочий день (как и для любой другой критической инфраструктуры). Когда-то Кэролин Ван Слик (Carolyn Van Slyck) в свободное время работала над Porter — системой автоматизации развертываний с открытым исходным кодом. Теперь обслуживание и поддержка этого проекта входит в ее обязанности в Microsoft. При этом она подчеркивает, что такого рода договоренности не обязательно являются постоянными. Если компания более не намерена использовать какой-либо проект в своих продуктах, она может прекратить его финансирование.

Не все проекты поддаются монетизации. В некоторых случаях они лучше работают как независимый стартап. «Тысяча Open Source-проектов — это всё равно что тысяча стартапов с разными бизнес-моделями, — заявил Эван Ю (Evan You), автор популярного JavaScript-фреймворка Vue, на GitHub Universe-2020. — Я в основном занимаюсь краудфандингом, поскольку, несмотря на известность Vue, тот плохо вписывается в конкретные проекты».

Сэмюэл Колвин (Samuel Colvin), автор популярной Python-библиотеки pydantic, говорит, что не видит четкого способа монетизировать свою работу. pydantic проверяет данные, помогая разработчикам убедиться, что пользователь вводит данные правильного типа. Например, pydantic следит за тем, чтобы пользователь не ввел буквы вместо цифр.

С одной стороны, pydantic — это широко используемая утилита, ядро многих других популярных пакетов Python, таких как библиотека обработки естественного языка spaCy и FastAPI (третий по популярности фреймворк Python согласно опросу более 28 тыс. разработчиков Python, проведенному в октябре 2020 года). «Это неотъемлемая часть SpaCy, — говорит автор SpaCy Инес Монтани (Ines Montani). — На таких инструментах, как pydantic, построена целая экосистема». С другой стороны, Колвин считает, что библиотека ещё не настолько значима, чтобы спонсорской помощи или пожертвований хватило на зарплату разработчика на full-time. Также нет очевидного способа создать стартап на её основе.

Кроме того, финансирование не решит всех проблем, с которыми сталкивается современный Open Source. Экосистема Open Source становится всё более сложной, и с этой сложностью приходят новые трудности, связанные с поддержкой совместимости проектов с другими проектами, кодом и приложениями, для работы с которыми они были разработаны.

Например, в 2017 году команда разработчиков ядра Python предложила изменение, которое бы частично поломало pydantic и, соответственно, все производные проекты, включая FastAPI. Осознание того, что изменение скоро будет реализовано, пришло к Колвину в апреле 2021 года после письма от заинтересованного разработчика Python. «В нем он писал, что только узнал о FastAPI и pydantic и понял, что изменение может негативно повлиять на них», — вспоминает Колвин.

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

Данный инцидент отлично иллюстрирует проблемы поддержки программного обеспечения. «Одно только слежение за списками рассылки разработчиков Python — работа на full-time», — поясняет Колвин. Даже полностью сконцентрировавшись на pydantic, он не смог бы успевать за всем, что происходит в экосистеме Python, отслеживать все моменты, способные повлиять на его проект. Точно так же не стоит ожидать, что ключевые maintainer’ы Python будут вникать во внутреннюю работу каждой существующей Python-библиотеки, не говоря уже о частных случаях.

«Даже с финансированием работы всегда больше, чем реально можно сделать, — считает Ван Слик. — И планка постоянно растет. Раньше можно было просто выложить код в сеть. Теперь же все ждут от вас отдельного сообщества. Ответственность растет и приходится делать кучу дел одновременно».

Счастье — в модульности

Некоторые разработчики нашли себя, сосредоточившись на создании небольших, легко обслуживаемых, фрагментов кода и тем самым сознательно избавились от избыточной ответственности. «Я не люблю разрабатывать ПО, требующее масштабной поддержки, — говорит Джеймс Халлидей (James Halliday), создатель большого количество модулей Node.js. — Вообще стараюсь делать модули минималистичными. Уверен, многие инструменты выиграли бы от того, что над ними перестали работать, перестали вносить изменения без объективных причин». Дополнительные функции приводят к избыточной сложности, и каждое изменение влечет за собой риск появления новых багов.

Хэллидей (более известный под ником substack) — сторонник политики невмешательства и пассивного подхода. «У меня отключены все уведомления от GitHub», — говорит он. В самом деле, любой разработчик может форкнуть код и исправить обнаруженную проблему или добавить новый функционал в модуль. В конце концов, именно так работает Open Source. Джеймс перестает отслеживать issues или pull request’ы для пакетов, которые считает завершенными. «Постоянно следить за каждой мелочью, которую я написал много лет или десятилетий назад, — это не про меня, — отмечает он. — Я всегда занят новыми проектами, что было бы невозможно, если бы постоянно возвращался к старым».

Не существует идеального подхода к разработке, который пришёлся бы по вкусу всем разработчикам открытого и свободного ПО. Многие из них счастливы поддерживать свои проекты или работать с сообществом над улучшениями. Установка в духе «меньше — значит больше» становится все более популярной альтернативой для поддержания крупных проектов и сообществ. Как отмечает Эгбал в своей книге Working in Public: The Making and Maintenance of Open Source Software, добавление новых участников в проект фактически означает дополнительную работу для его авторов. Те рискуют оказаться на своеобразном крючке, связанном с необходимостью не только проверять чужой код, но и поддерживать новые функции, если новички уходят из проекта. Эгбал обнаружила в сообществе Open Source тенденцию к более модульному проектированию и разработке, когда авторы создают компактные пакеты, требующие меньшего числа maintainer’ов и меньшего объема работ. Даже такие крупные проекты, как Ruby on Rails, постепенно переходят на модульный подход.

Между тем, в отчете GitHub State of the Octoverse-2020 говорится, что Open Source-разработчики предпочитают вносить небольшие, постепенные изменения, тем самым создавая меньше проблем для тех, кто занимается поддержкой. «Главной лучшей практикой был признан небольшой охват pull request’ов, поскольку такой подход облегчает их рассмотрение (review), способствует более качественному анализу и упрощает откат в случае возникновения проблем, — сказано в отчете. — Также он улучшает обратную связь, стимулируя и способствуя повышению производительности команды».

Хотя модульный подход может облегчить жизнь Open Source-разработчикам, он также создаёт новые проблемы для крупных предприятий, увеличивая число пакетов, которые необходимо проверять и обновлять. «Объём потенциальных проблем ещё больше. Слишком много зависимостей, при этом за каждую отвечают разные программисты», — пишет Эгбал.

В некотором смысле такова цена использования свободного программного обеспечения. «Помните, что Open Source-программисты обычно делают эту работу ради общего блага, часто безвозмездно, и не могут контролировать то, как их софт используется, — говорит руководитель отдела безопасности GitHub Майк Хэнли (Mike Hanley). — Полагаясь на Open Source и стороннее ПО, необходимо проявлять должную осмотрительность в отношении того, какое ПО вы включаете в проект и как его используете. При этом не забывайте делиться своими улучшениями, интересными примерами использования или багфиксами».

Помимо этого, у компаний и энтузиастов имеется множество возможностей для более активного участия в сообществах Open Source, начиная с финансирования и поддержки и заканчивая основанием новых сообществ. Начинать рекомендуется с более пристального изучения софта, лежащего в основе вашего кода, и открытия ранее невиданной инфраструктуры, которая за ним стоит.

P.S. от переводчика

Читайте также в нашем блоге:

• «Обратная сторона Open Source-славы: как угрожают автору curl»;

• «Чудной трюк, чтобы сделать день мейнтейнеру Open Source-проекта».