Как правило, мейнтейнеры проектов с открытым исходным кодом ничего вам не должны. Несмотря на то, что мейнтейнеры часто бывают добровольцами, некоторые пользователи заявляют свои права на время мейнтейнеров, отправляя feature requests и ожидая, что мейнтейнеры реализуют всё, что они захотят. Но это ошибка. Повторюсь, мейнтейнеры open source ничего вам не должны.
Но это утверждение применимо не ко всем мейнтейнерам open source: в последнее время меня раздражает то, что некоторые компании, обладающие достаточными ресурсами, перекладывают ношу поддержки (и совершенствования) проектов с открытым исходным кодом с себя на пользователей.
Я говорю об официально поддерживаемых корпоративных «клиентах» в open source для проприетарных продуктов. Среди подобных проектов официальный Python-клиент Stripe (пользоваться которым может только потребитель Stripe) и поддерживаемые Google компоненты BigQuery проекта Apache Beam в open source (который полезен только пользователям Google Cloud). Эти проекты — «обёртки» с открытыми исходниками, позволяющие интегрировать проприетарные продукты (за которые платите вы!) в своё приложение.
Если вы столкнётесь с багом в одном из таких проектов, то мейнтейнеры предложат вам устранить проблему самостоятельно (или игнорировать баг). Чтобы использовать эти проекты-обёртки, вы должны быть клиентом поддерживающих их компаний, и эти проекты часть продуктов этих компаний. Мне кажется, что баги в них должны устранять компании, а не вы.
На создание этого поста меня сподвиг недавний опыт работы с 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, чтобы аутсорсить ответственность за поддержку всего проекта «сообществу добровольцев, которое вам ничего не должно». Но это уже тема для другого поста.
А теперь давайте взглянем на 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».
Но это утверждение применимо не ко всем мейнтейнерам 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».
