Но это утверждение применимо не ко всем мейнтейнерам open source: в последнее время меня раздражает то, что некоторые компании, обладающие достаточными ресурсами, перекладывают ношу поддержки (и совершенствования) проектов с открытым исходным кодом с себя на пользователей.
Я говорю об официально поддерживаемых корпоративных «клиентах» в open source для проприетарных продуктов. Среди подобных проектов официальный Python-клиент Stripe (пользоваться которым может только потребитель Stripe) и поддерживаемые Google компоненты BigQuery проекта Apache Beam в open source (который полезен только пользователям Google Cloud). Эти проекты — «обёртки» с открытыми исходниками, позволяющие интегрировать проприетарные продукты (за которые платите вы!) в своё приложение.
Если вы столкнётесь с багом в одном из таких проектов, то мейнтейнеры предложат вам устранить проблему самостоятельно (или игнорировать баг). Чтобы использовать эти проекты-обёртки, вы должны быть клиентом поддерживающих их компаний, и эти проекты часть продуктов этих компаний. Мне кажется, что баги в них должны устранять компании, а не вы.
Google и Apache Beam
На создание этого поста меня сподвиг недавний опыт работы с Apache Beam. Beam — проект с открытым исходным кодом, предоставляющий «расширенную унифицированную модель программирования» для написания «задач для обработки пакетных и потоковых данных, выполняемых в любом механизме исполнения».
Изначально Beam разрабатывался Google, он используется в проприетарном продукте Dataflow компании. Внутри Apache Beam находятся официальные компоненты, поддерживаемые Google для обеспечения интерфейса с ещё одним проприетарным продуктом BigQuery. BigQuery — отличный продукт! Я постоянно использую его в работе и он потрясающе с ней справляется.
Но в прошлом месяце я отправил баг-репорт о проблеме интеграции Beam с BigQuery (который, насколько я понимаю, официально поддерживается Google). Вкратце проблему можно описать так: когда ты используешь нативную реализацию Beam на Python, то не можешь загружать данные BigQuery большими пакетами, их можно загружать только потоково, что гораздо медленнее пакетной загрузки. Хотя продукт по большей мере остаётся работающим (потоковая передача данных в BigQuery вместо загрузки одним большим пакетом вполне работает), эта проблема делает практически невозможной загрузку больших наборов данных из-за её чрезвычайной медленности.
На 7 сентября 2021 года отправленная мной issue не была ни подтверждена, ни рассмотрена. И это вполне объяснимо! Я понимаю, что на устранение багов нужно время, даже в проектах open source с самым большим объёмом ресурсов. И я понимаю, что мейнтейнерам Beam приходится много работать.
Но если эта проблема не будет разрешена в течение длительного времени, то мой работодатель может заплатить мне за самостоятельное устранение проблемы и за то, что я внесу исправление в общий проект. Это мне не очень нравится. Мы много платим Google за пользование их продуктами, и не подписывались на самостоятельное устранение багов в этих продуктах.
Да, мне повезло, что мой работодатель одобряет внесение улучшений в используемые нами проекты с открытым исходным кодом, но эти проекты, по сути, всегда поддерживаются добровольцами. Не думаю, что они ответственны за исправление интеграции Beam с BigQuery.
Будем справедливыми, часть мейнтейнеров Beam — это добровольцы, и я не думаю, что они должны брать на себя ответственность за устранение этого бага. Google внесла вклад в виде кода BigQuery в Beam как части своих продуктов Dataflow и BigQuery, поэтому я считаю, что ответственность за поддержку должна взять на себя Google. Только то, что конкретный поломанный код выложен в open source, не означает, что вы должны сами брать на себя ношу поддержки.
Есть и более общий вопрос — перенесла ли Google Beam на Apache, чтобы аутсорсить ответственность за поддержку всего проекта «сообществу добровольцев, которое вам ничего не должно». Но это уже тема для другого поста.
Stripe сделала всё правильно
А теперь давайте взглянем на Python-библиотеку клиента Stripe. Stripe — это компания, упрощающая обработку онлайн-платежей. В обмен на обработку транзакций Stripe берёт небольшой процент от каждой транзакции. Stripe, какой бы великолепной компанией она ни была, не поддерживает Python-библиотеку клиента бесплатно. Stripe поддерживает свою Python-библиотеку клиента, потому что она является частью продукта компании!
Хотя пользователи Stripe не платят конкретно за доступ к библиотеке клиента, они платят за упрощение обработки онлайн-платежей, а наличие Python-библиотеки клиента — важная часть продукта Stripe.
Теперь представим, что Python-библиотеке клиента Stripe что-то сломалось, и вы отправили баг-репорт. Были бы вы расстроены, если бы Stripe ответила: «Привет, у нас пока не хватает для этого мощностей, но вы можете отправить пул-реквест и исправить всё сами»? Простите, что?
Отправляя issue, вы уже бесплатно делаете работу для Stripe. (Наверно, отдел контроля качества компании должен был выявить эту ошибку!) Отправляя пул-реквест, вы бы, по сути, улучшили продукт компании. Stripe может ответить, что issue не приоритетна, но устранение багов совершенно точно не является вашей ответственностью.
К счастью, Stripe поступает иначе. Компания невероятно отзывчива и совместно с пользователями работает над разрешением проблем (даже когда эти проблемы касаются не самого клиента Stripe). В ответ на feature requests они не говорят, что примут вносящий изменений пул-реквест.
Похоже, Stripe считает рассмотрение проблем, ответы и поддержку пользователей их Python-библиотеки ещё одним видом своей (превосходной) технической поддержки. Компания понимает, что её Python-библиотека — важная часть её продукта, поэтому поддержка пользователей библиотеки является важной частью технической поддержки.
Что вы можете сделать?
Не все компании работают со своими проектами-обёртками в open source как Stripe. Что вы можете сделать, если столкнётесь с проблемой официально поддерживаемого корпоративного «клиента» в open source для проприетарного продукта? Вы можете понадеяться, что компания заметит отправленную вами issue и устранит баг сама. Или вы можете проголосовать кошельком и перейти к другому поставщику услуг (хотя на практике это зачастую невозможно). Или сдаться и самому стать контрибьютором, как мне, вероятно, предстоит вскоре сделать с BigQuery в Beam.
Честно говоря, я не думаю, что прямая или косвенная помощь крупным корпорациям — это что-то плохое, и ничего не имею против проприетарного ПО (хоть и всегда предпочту ПО в open source проприетарному аналогу). Если вы хотите отправить пул-реквест Python-библиотеки клиента Stripe или интеграции BigQuery с Beam, тогда вперёд — выбор за вами! Меня просто раздражает, что огромная корпорация с большим количеством ресурсов перекидывает бремя поддержки своего продукта на пользователей. И я боюсь, что такое бывает довольно часто.
Примечание: я осознаю, что не совсем понятно, можно ли вообще считать библиотеки-обёртки в open source настоящим open source. Как сказал один комментатор, если ты не можешь полностью отказаться от поставщика и работать с проектом только сам, то это вообще не «open source».
Комментарии (11)
gecube
25.01.2022 16:03+1В ответ на feature requests они не говорят, что примут вносящий изменений пул-реквест.
ничего не понял. Так примут или не примут? Хорошо ли это или плохо?
amarao
25.01.2022 16:21feature request = сделайте, пожалуйста.
pull request = я написал всё, что нужно, вмержите в мастер, пожалуйста
gecube
25.01.2022 16:40+1так о том и речь, что они не примут вносящий изменения PR (по крайней мере так в статье подано). Вот она фича готовая, бери и мержь, но нет, либо написано очень загадочно
fedorro
25.01.2022 18:33+3В ответ на feature requests они не попросят вас самих сделать пул-реквест.
Как то так это нужно понимать.
kryvichh
25.01.2022 16:16+3Как правило, мейнтейнеры проектов с открытым исходным кодом ничего вам не должны.
А разработчики платных программ кому-то что-то должны? Другие дело подписка на обновления, или сопровождение. Так это и для opensource есть.
impexp
25.01.2022 16:54Прямо-таки слышится боль души мейнтейнера отдела разработки перспективных идей от Билайна ;-) Да, никто никому ничего не должен, только не следует упускать из вида общую цель – прогресс, для начала, как вида.
AlexGluck
25.01.2022 18:48+13Всё познаётся в сравнении, если мне или бизнесу нужно пофиксить баг или новые фичи, то с проприетарным ПО мы платим деньги и сосём бамбук. С опенсорсным ПО мы можем платить деньги и можем сами пофиксить, от вендора\мейнтенера требуется (если платим) обработать пулреквест. А если не платим, то пользуемся с благодарностью тем что получили просто так.
amarao
Последний раз, когда я читал EULA от проприетарного ПО, там тоже было написано, что они ничего не должны. А у меня килограмм обязательств, включая обязательство предоставлять мой компьютер для внезапного аудита соблюдения лицензии, передачи телеметрических данных и ограничение ответственности вендора суммой в пять евро.
gecube
согласен, долой асимметрию!