«Это открытый исходный код! Мы позволим нашим клиентам это исправить ».


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

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

Я говорю об официально поддерживаемых корпоративных «клиентах» с открытым исходным кодом для проприетарных продуктов. К таким проектам относятся официальный клиент Stripe Python (для использования которого вы должны быть клиентом Stripe) и поддерживаемый Google Компоненты BigQuery проекта с открытым исходным кодом Apache Beam (который полезен только для клиентов Google Cloud), чтобы привести всего два примера. Эти проекты представляют собой «оболочки» с открытым исходным кодом, которые позволяют вам интегрировать проприетарные продукты (которые вы платите!) В свои

Если вы столкнетесь с ошибкой в ​​одном из этих проектов, я был бы разочарован, если бы сопровождающие предложили вам исправить проблему самостоятельно (или полностью проигнорировали ошибку). Чтобы использовать эти проекты-оболочки, вы должны быть заказчиком компаний, которые их обслуживают, и эти проекты являются частью этих компаний ». товарные предложения. На мой взгляд, исправлять ошибки лежит на компании, а не на вас.

Google и Apache Beam

Этот пост был вызван моим недавним опытом работы с Apache Beam . Beam – это проект с открытым исходным кодом, который обеспечивает «усовершенствованную унифицированную модель программирования» для написания «заданий пакетной и потоковой обработки данных, которые выполняются на любом механизме выполнения».

Beam изначально был разработан Google, и он поддерживает их проприетарный продукт Dataflow . Внутри Apache Beam находятся официальные компоненты, поддерживаемые Google для взаимодействия с BigQuery, еще одним проприетарным предложением. BigQuery – отличный продукт! Я использую его все время для работы, и у меня был фантастический опыт работы с ним.

Но в прошлом месяце я отправил отчет об ошибке Beam для довольно потрясающая проблема в интеграции Beam с BigQuery (которая, насколько я могу судить, официально поддерживается Google). Суть в том, что при использовании собственной реализации Python Beam вы не можете загружать данные в BigQuery большими партиями – вы можете только передавать их в потоковом режиме, что значительно медленнее, чем пакетная загрузка. Хотя он все еще в основном пригоден для использования (потоковая передача данных в BigQuery вместо загрузки их одним большим пакетом работает достаточно хорошо), проблема делает загрузка некоторых больших наборов данных чрезмерно медленная.

По состоянию на 7 сентября 2021, проблема, которую я подал, не была ни подтверждена, ни упорядочена. Это совершенно понятно! Я понимаю, что исправление ошибок может занять время даже в самых хорошо обеспеченных ресурсами проектах с открытым исходным кодом. И я понимаю, что у сопровождающих Beam много работы.

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

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

Некоторые специалисты по сопровождению Beam – добровольцы, чтобы внести ясность, и я не думаю, что мы обязаны Исправить этот вопрос тоже ложится на них. Google предоставил код BigQuery для Beam как часть своих продуктов Dataflow и BigQuery, поэтому я думаю, что бремя обслуживания этих вкладов ложится на Google. Тот факт, что конкретный сломанный код является открытым исходным кодом, не означает, что вы должны взять на себя бремя обслуживания.

Есть более широкий вопрос: перенесла ли Google Beam на Apache для передать бремя обслуживания проекта в целом на аутсорсинг, как сказал мой друг, «сообществу добровольцев, которые ничего вам не должны». Но это тема для другого поста.

Stripe делает это правильно

Теперь давайте взглянем на клиентскую библиотеку Stripe Python. Stripe – это компания, которая упрощает обработку онлайн-платежей. В обмен на обработку платежей Stripe берет небольшой процент от каждой транзакции. Stripe – какая бы замечательная компания она ни была – не поддерживает свою клиентскую библиотеку Python бесплатно. Они поддерживают свою клиентскую библиотеку Python, потому что это часть их продукта!

Хотя клиенты Stripe не платят конкретно за доступ к клиентской библиотеке, они платят Stripe за обработку онлайн-платежей. проще, и наличие хорошо поддерживаемой клиентской библиотеки Python является важной частью предложения продуктов Stripe.

Теперь представьте, что что-то сломалось в клиентской библиотеке Stripe Python, и вы отправили отчет об ошибке . Разве вы не расстроились бы, если бы Stripe ответил: «Эй, у нас нет пропускной способности, чтобы исправить это прямо сейчас, но вы можете отправить запрос на перенос и исправить это самостоятельно»? Простите?

Отправляя вопрос, вы уже бесплатно предоставляете свою работу Stripe. (Возможно, их команда по обеспечению качества должна была обнаружить проблему!) Отправив запрос на перенос, вы существенно улучшите их продукт для них. Stripe может ответить, сказав, что проблема не является приоритетной, но, конечно же, не ваша ответственность исправлять их ошибки.

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

Stripe, похоже, обрабатывает сортировку, ответы и поддержку пользователей их Python библиотека как еще одна форма их (исключительной) поддержки клиентов. Они осознают, что их библиотека Python является важной частью их продукта, поэтому поддержка пользователей библиотеки является важной частью их поддержки клиентов.

Что вы умеете?

Не все компании управляют своими проектами-оболочками с открытым исходным кодом, как Stripe. Итак, что вы можете сделать, когда столкнетесь с проблемой с официально поддерживаемым корпоративным «клиентом» с открытым исходным кодом для проприетарного продукта? Вы можете надеяться, что компания заметит вашу проблему и устранит ее самостоятельно. Или вы можете проголосовать с помощью своего кошелька и перейти к другому провайдеру (хотя это часто нецелесообразно). Или вы можете сдаться и внести исправление самостоятельно, как, возможно, скоро мне придется сделать с BigQuery в Beam.

Чтобы быть ясным, я не думаю, что это помогает крупным корпорациям прямо или косвенно это как-то неправильно, и я ничего не имею против проприетарного программного обеспечения (хотя я всегда предпочитаю открытое программное обеспечение проприетарному эквиваленту). Если вы хотите отправить запрос на перенос в клиентскую библиотеку Stripe Python или в интеграцию BigQuery в Beam, продолжайте – это ваш выбор! Я просто разочарован тем, что крупная корпорация с хорошими ресурсами перекладывает бремя обслуживания своего продукта на клиентов. И я беспокоюсь, что это не редкость.

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

Спасибо всем, кто предоставил ценные отзывы о более ранних черновиках этого сообщения, многие из которых Рекурсеры .