Фото — James Sutton — Unsplash
Open source — основа интернета
По данным Linux Foundation, 72% компаний из Fortune 2000 используют open source инструменты для решения своих задач. При этом 55% задействуют открытый код в коммерческих продуктах. Открытое ПО распространено в дата-центрах — например, с ним работают Facebook, Rackspace, NASA и AT&T. Ряд облачных провайдеров и ИТ-компаний даже основал организацию Open Compute Project. Она разрабатывает открытый стандарт архитектуры серверных стоек (Open Rack) и требования к модульному серверу для облачных дата-центров (OpenCloud Server).
Значительная часть популярных open source продуктов — это масштабные проекты вроде Kubernetes, TensorFlow или Ansible. Их разрабатывают и финансируют крупные ИТ-компании. Но есть и небольшие продукты (например, cURL), которые поддерживают энтузиасты. Часто они делают это на добровольной основе и в свободное время. И здесь кроются подводные камни.
Почему такую модель критикуют
Концепция open source подразумевает, что модифицировать исходники и исправлять в них ошибки могут все желающие. Коллективные усилия повышают качество кодовой базы и сокращают число багов. Но к сожалению, эта модель работает не всегда.
Значительную часть изменений в open source проект вносит или маленькая команда, или один мейнтейнер. Например, из 25 тыс. коммитов в репозитории cURL, 14 тыс. принадлежат автору — Даниэлю Стенбергу (Daniel Stenberg). Долгое время число разработчиков библиотеки OpenSSL не превышало четырех человек. Большую часть коммитов сделал один из них — Стив Хенсон (Steve Henson). Поэтому в таких условиях легко недоглядеть и «пропустить» баг.
Так, пять лет назад в OpenSSL обнаружили одну из самых крупных уязвимостей в софте — Heartbleed. Она позволяет несанкционированно читать память на сервере или клиенте. Тогда число уязвимых веб-сайтов оценили в полмиллиона. Патч выпустили сразу, но еще в 2017 году работали 200 тыс. сайтов, подверженных Heartbleed.
Фото — James Sutton — Unsplash
Многие open source проекты испытывают проблемы с финансированием. Тот же OpenSSL существует за счет пожертвований комьюнити и доходов с корпоративных контрактов — сумма не превышает миллиона долларов в год. Бывший CEO проекта говорит, что одной из причин появления Heartbleed стал именно недостаток финансирования. Инженерам бывает сложно привлечь средства даже за консультации. По словам Даниэля Стенберга, к нему часто обращаются международные компании с просьбами помочь решить проблему в cURL. Но каждый раз, когда он просит оплатить его работу, беседа почему-то прекращается.
«Иногда разработчики занимаются открытыми проектами в свободное время в качестве хобби. Поэтому неудивительно, что некоторые приложения забрасывают. Если никто не хочет поддерживать проект на плаву, сформированное вокруг него комьюнити распадается.
В худшем случае пользователи системы могут стать целью хакерской атаки. Пример — прошлогодняя атака на npm-модуль event-stream».
Автор проекта, Доминик Тарр (Dominic Tarr), переключился на другие задачи и оставил свое детище без внимания. Некий пользователь предложил взять поддержку модуля на себя.
Тарр согласился и предоставил ему доступ к репозиторию на GitHub и npm. Со временем новый мейнтейнер внедрил в утилиту скрипт, который воровал данные биткоин-кошельков и загружал их на его сервер. Уязвимость затронула большое число пользователей, учитывая, что у event-stream 1,9 млн скачиваний в неделю.
Как исправляют ситуацию
По данным Национального бюро экономических исследований США, главный мотивирующий фактор развития open source — это экономическая выгода. Поэтому разработчики открытого ПО ищут способы его монетизировать. Например, переводят часть модулей на ограничивающие или даже коммерческие лицензии. По этому пути пошли MongoDB, Redis и другие компании.
Подробнее о ситуации мы уже говорили. Разработчики считают, что даже частичная коммерциализация кода позволит открыть дополнительный источник дохода и привлечь новых людей в проект. Но такая модель часто воспринимается ИТ-сообществом в штыки.
Есть мнение, что подход противоречит концепции открытого ПО. При этом он годится не для всех. В 2017 году HTTP/2 веб-сервер Caddy анонсировал коммерческую лицензию. Но по каким-то причинам месяц назад проект вновь вернули в open source.
Фото — Artem Beliaikin — Unsplash
Мировая интернет-инфраструктура зависит от открытых проектов. Поэтому важно уделять внимание их поддержке. И работа в этом направлении ведется. В Linux Foundation регулярно появляются новые резиденты. Все больше в open source инвестируют крупные компании. Возможно, такие инициативы помогут избежать повторения истории, аналогичной Heartbleed.
Дополнительное чтение в блоге 1cloud.ru:
Спасет ли облако ультра-бюджетные смартфоны Почему Apple изменила требования к разработчикам приложений Эволюция архитектуры облака 1cloud Что нового в Linux kernel 5.3 — графические драйверы, виртуализация и другие обновления Почему разработчики мейнстрим-браузера снова отказались от отображения поддомена Комментарии (19)
shurup
10.11.2019 10:30+1В статье стоило затронуть проблематику появления/актуальности лицензий вроде BSL (Business Source License) ввиду предложений Open Source-решений в виде сервисов (DBaaS и т.п.) крупными облачными провайдерами. Это о проектах, которые не так малы, как curl, но и не создаются гигантами вроде Facebook… Тема (на примере CockroachDB) в полной мере раскрывалась здесь.
Areso
10.11.2019 11:32По словам Даниэля Стенберга, к нему часто обращаются международные компании с просьбами помочь решить проблему в cURL. Но каждый раз, когда он просит оплатить его работу, беседа почему-то прекращается.
К нему обращаются не международные компании, а рядовые специалисты из этих самых компаний. У них нет бюджета, чтобы его тратить, и нет возможности выделить бюджет, чтобы, опять же, тратить. Поэтому, как только речь заходит за деньги, они сливаются.
А человеку надо себя позиционировать как independent contractor с максимальными знаниями о продукте и навыками решения проблем и выставлять ценник по $100/час.
Хотите помощь? Пожалуйста, вот моя (e)-визитка, сайт, часовая ставка, документы фискальные по образцу страны проживания автора инструмента.
А международные компании обращаются по-другому. Типа, мы хотим использовать вашу либу или инструмент в очень важном проекте для очень важного заказчика, поэтому нам нужен SLA 99,9%, реакция в течение 3 часов, и т.п., за, скажем, 50 тысяч долларов в год. Подпишите пожалуйста типовой контракт на 500 страниц, где каждый чих расписан очень подробно (и, скорее всего, в нашу пользу).
Chosen_One
10.11.2019 17:12+1Не понимаю как из «По данным Linux Foundation, 72% компаний из Fortune 2000 используют open source инструменты для решения своих задач. При этом 55% задействуют открытый код в коммерческих продуктах.» следует «Open source — основа интернета». Можно уйти в дебри и сказать, что опенсорс разрабатывается в том числе и на софте, которое не опенсорс. И на железе, которое спроектировано, наверно в большинстве случаев не в опенсорс софте. Неопенсорс — основа опенсорс? Как вступление реферата прочитал.
trolley813
10.11.2019 23:40+2Например, из 25 тыс. коммитов в репозитории cURL, 14 тыс. принадлежат автору — Даниэлю Стенбергу (Daniel Stenberg).
А вот из этого я сделал прямо противоположный вывод (и, вероятно, был далеко не один) — наоборот, 11 тысяч коммитов (почти половина) сделана не автором, а другими разработчиками, как раз-таки сообществом — правда, хвост распределения довольно быстро убывает: 100 или больше коммитов у 11 человек, 50 или больше — у 17. (Вообще, количество коммитов — метрика тоже довольно такая себе, по-моему, еще хуже, чем количество строк кода.)
alexandrtovmach
11.11.2019 01:42Даже не представляю какое можно придумать решение на сегодня. При переводе опенсорса на платные или частично платные лицензии аутсорсинговые компании СНГ, особенно ориентированные на JS просто сгорят.
Почему я говорю про СНГ? Потому что у нас нет культуры и понимания "зачем платить за контент, если он есть без смс и регистрации". Не берусь утверждать что так по всему миру, но для нас это одна из ключевых проблем почему "сообщество против".
Почему загнётся аутсорс JS? Ну пожалуй потому что сложно найти продукт на JS без
webpackилиnodejs, а платить мы не понимаем, вот и придется либо клиенту говорить что мол "нужен бюджет побольше", либо разрабам говорить что "ваши инвойсы пошли на вебпак, но вы держитесь".
pas9x
12.11.2019 20:23+2Представьте что будет, если завтра каждая либа, каждая программулька и каждый сайт станет платным, или будет пытаться извлечь из вас выгоду. Я не хочу жить в таком мире.
А ведь всё к тому идёт, сейчас на некоторых сайтах уже даже статьи дают читать только платно.
quaer
12.11.2019 20:23+2Может, всё проще?
Создатель кода не знает как/не может его монетизировать;
Боится нести ответственность, ведь если купят, скорее всего потребуется дорабатывать и править баги, причем некоторые в срочном порядке;
gitKroz
На мой взгляд, при словах open-source у многих людей сразу возникают ложные ожидания.
Например, считается что open-source проекты развиваются сообществом. Во-первых, у всех разные определения понятия «сообщество» в плане численности и объема вклада. Во-вторых, какое бы вы ни дали определение сообщества, такие проекты вы в природе найдете; но это будут скорее исключения. Правильней было бы сказать так: open-source — это проекты, в которых сообщество имеет возможность принять развитие; но вовсе не обязано, и не факт, что оно это делает. Собственно, в этой статье это и описано. Для компаний имеет смысл выбирать open-source компоненты для критичных компонент только в том случае, если имеется возможность привлечь людей/партнеров для поддержки; но ни в коем случае нельзя рассчитывать на бесплатную поддержку некоего абстрактного сообщества.
Также, есть расхожее мнение о том, что open-source проекты более безопасны, так как любой желающий может проверить код. Опять же, ключевое слово «может»: не факт, что кто-то это в реальности делает. Но лично вы — да, можете. Я бы сказал так: если вам важна безопасность, и вы можете найти компетентных спецов, которые могут проверить код, и вы намереваетесь это делать, то, да, open-source имеет для вас преимущество.
Open-source часто ассоциируют с финансовой выгодой: никто не требует покупать лицензии, не навязывает тех. поддержку — снижение операционных затрат вроде как налицо. Как по мне, корпоративный проект, основанный на open-source компонентах и на таком вот видении, скорее всего потерпит крах. Не обязательно, но с довольно большой вероятностью.
Правда, с точки зрения рынка open-source имеет неоспоримое преимущество в том, что потенциально много компаний могут осуществлять тех. поддержку. Опять же — «потенциально», «могут», и там еще нюансы.
Еще один неоспоримый плюс в том, вы имеете возможность добавить свои фичи даже если создатели/мейнтейнеры не поддержат ваши изменения. При условии что, вас устраивает лицензия, у вас есть спецы, вы готовы далее поддерживать форк и т. п.
То есть open-source — это скорее о возможностях, но не о дивном новом мире, где всё делается за вас.
gecube
Я думаю, что вообще термин опен-сурс сейчас очень неверно понимается. Что такое опен-сурс и зачем он нам нужен? Является ли опен-сурсом ситуация, когда вендор нам даёт исходники и мы действительно можем их изменять? А если исходники дают, но под ограниченной лицензией? Короче, все сложно и "бытовое" понимание опен-сурс создаёт реально ложные ожидания
Возможно, что мы находимся на пороге, когда родится какой-то новый подход, который избавлен от недостатков существующей ситуации. А возможно, что и нет и мы дальше будем "катить квадратное и гласить круглое" и страдать.
kdmitrii
В чем проблема понимать что такое опенсорс? Исходники есть — опенсорс, нет — не опенсорс.
gecube
Одна из плоскостей — не любой код, выложенный на гитлабе/гитхабе, можно переиспользовать. В силу лицензии. Это как "не любая картинка или статья из интернета может быть размещена (скопирована) в Ваш блог/сайт и пр."
VuX
Интересно, а в чем смысл такого кода? Академический или просто ознакомительный или еще что-то?
gecube
Я думаю, что кейсов можно придумать массу.
Hardcoin
Корпоративный проект, основанный на docker+nginx+postgres+symfony+vuejs скорее всего потерпит крах? Как-то очень необоснованно звучит, не находите?
Конечно не все открытые продукты настолько массовые, но проводить параллель между платой за лицензию и вероятностью успеха проекта нет никаких оснований.
gitKroz
А что вы подразумеваете под успехом проекта?
На самом деле есть четкое определение: проект успешен тогда, когда он выполнен 1) в срок 2) в бюджет 3) достигнуты цели проекта.
Цитата, которую вы привели, относилась к проектам, целью которых являлась снижение операционных затрат, связанных с сопровождением ПО. То есть простыми словами: финансовому директору подавался на стол проект, который говорил: вот сейчас мы за время Х и с бюджетом Y перейдем на open-source технологии, и будем тратить на Z меньше. Так вот в большинстве случаев такие проекты терпят крах. Да, не всегда, конечно, но чаще чем другие. Переформулирую: ожидания по X (сроки), Y (бюджет), Z (цель — снижение затрат) как правило занижены в несколько раз по сравнению с реальностью. Особенно если у компании был не большой опыт работы с open-source. То есть такие проекты имеют очень, очень высокий уровень риска.
Если не брать во внимание новости и слухи, то лично я работал на проектах в продуктовой компании, которая использовала в частности Oracle базы данных. Потом решили перейти на PostgreSQL. А что — почти то же самое, только за лицензию платить не нужно. У нас есть аксакалы Оракла, они быстро освоят PostgreSQL — это было общее видение. Как бы не так. Я не девелопер, но участвовал в общих митингах, и был свидетелям того, с каким скрипом всё продвигалось. В конце-концов мы справились, но явно не в ожидаемое время и бюджет.
Hardcoin
Если переходить с postgres на оракл, тоже успех не гарантирован. Или внедрение какого-нибудь SAP.
Из ваших слов можно сделать вывод, что именно опенсорсность увеличивает риски перехода, однако к этому нет оснований. При переходе риски есть всегда. Банально, может просто не хватить квалификации и ума у участников проекта (не говоря уж о других проблемах).
gitKroz
Не гарантирован. Но есть разница.
Если вы будете переходить с Postgres на Oracle, то при заключении контракта, Oracle вам будет очень настойчиво предлагать тренинги. И, если вы дадите себя уговорить, то ваш спец Петя уже сходу хоть немного узнает специфику Orcale и сможет сравнить с Postgres. Определенный процент проблем на старте это уберет. В отличии от перехода Oracle->Postgres, когда Петя будет в авральном режиме шерстить StackOverflow после заведения блокера. Очень мало кто при переходе на бесплатные open-source компоненты заказывает специализированные тренинги для своих сотрудников, и это первый фактор риска.
Еще Oracle предложит вам тех. поддержку, так что Петя даже сможет написать кому-то и ожидать получение ответа в оговоренные сроки. Для вашего примера: какой процент компаний подписывает контракт со сторонней компанией на тех. поддержку docker, nginx, postgres, symfony, vuejs, ...? Этого обычно не закладывают в бизнес-кейс, ибо тогда он становится не таким привлекательным.
gecube
Эта разница… исчезающе мала. Для того же постгреса есть постгрес про, которые с радостью возьмут деньги за поддержку. Для кубернетеса есть условный флант, который будет поначалу поддерживать кластер, обучит инженеров, а потом… сами знаете, что потом.
Тут скорее вопрос в том, что успех проекта зависит от кучи факторов и использование или неиспользование опенсурс не является решающим. Ну, а чо — давайте тогда вообще не пользоваться открытыми стандартами на языки типа С, С++, Джава....
gitKroz
Конечно есть. Но вот только мало кто этим пользуется. Большинство рассчитывают, что без этого получится обойтись.
А это к чему? Мы здесь говорим про нереалистичные ожидания в финансовом аспекте.