[Из песочницы] Сколько стоит OpenSource01.04.2019 14:05

Значение термина Open Source очень часто отождествляют с отсутствием необходимости платить за программный продукт. Стремление к экономии, к «халяве» не чуждо большинству, и вроде как OpenSource должен являться той волшебной таблеткой, которая должна была уже давно спасти весь мир от таких монстров, как Microsoft, требующих за свои продукты не маленькую плату. Однако этого не происходит. В этой статье мы попробуем на верхнем уровне, без погружения в частности и детали разобраться каким бывает Open Source? Почему Open Source так и не стал той самой таблеткой. …И вообще нужна ли она?

Определение

Для начала все-таки определимся с тем, что такое OpenSource — это программное обеспечение с открытым исходным кодом. Таким программные обеспечением можно не только пользоваться, но и работать с его исходным кодом — просматривать его, изучать, вносить свои собственные изменения. По сути первый автор, создатель любой такой программы приглашает весь мир к соавторству, и обычно такие программы возникают как раз из-за специфических потребностей их создателей.

Оформилась даже собственная философия движения свободного программного обеспечения, целью которой является гарантия четырех базовых свобод пользователей:

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

Как это бывает

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

Ярким и широко известным примером программного обеспечения с открытым исходным кодом является Linux, как ядро операционной системы, созданное Линусом Торвальдсом в 1991 году. Само ядро Linux распространяется свободно на условиях лицензии General Public License (GNU). Торвальдс решил использовать этот вариант, когда стало очевидно что-то что было его личным хобби, стало быстро распространяться по всему миру.

Однако, как это ни странно, это не означает, что все версии операционных систем, основанные на этом ядре, являются бесплатными. Есть и чисто коммерческие продукты, например, SUSE Enterprise Linux, Red Hat Enterprise Linux — предназначенные для корпоративного использования. Приобретая этот дистрибутив (а по факту подписку на обновления), покупатель получает поддержку по тем обязательства, которые берет на себя производитель этой операционной системы. Компании SUSE и Red Hat, помимо классических способов заработка на продаже самих дистрибутивов (подписок), услуг по внедрению и технической поддержке продают официальную продукцию со своей символикой — поло, кепки, кружки, игрушки, канцелярия и т.п.

Еще один интересный момент, сколь бы бесплатным и открытым не был Linux, он не появился из ниоткуда, на его создание тоже были потрачены ресурсы. В разные годы были проведены различные исследования по различным методикам, оценивалась стоимость разработки ядра Linux версии 2.6.0. В 2004 году стоимость оценили в 612 млн долларов США (467 млн евро) используя модель оценки человеко-месяцев (способ, принятый для оценки разработки проприетарного программного обеспечения). В 2006 году очередное исследование было профинансировано Евросоюзом, в результате получили цифру в 1,09 млрд долларов США (882 млн евро). В 2008 году оценка стоимости разработки ядра достигла цифры в 1,3 млрд долларов США.

Существуют примеры, где само программное обеспечение действительно остается Open Source, в его каноничном понимании. Однако и оно тоже с успехом монетизируется. В качестве примера можно взять программный продукт Zabbix — универсальную систему мониторинга любой ИТ-инфраструктуры, облачных ресурсов, сервисов и приложений. Цитата с сайта компании: «Zabbix — Бесплатное программное обеспечение с открытым исходным кодом. Ограничения и скрытые расходы отсутствуют.» Однако производитель достаточно успешно монетизирует свой продукт, предлагая широкий спектр услуг по всему миру:

Услуги технической поддержки для корпоративных клиентов в рамках контракта;
Услуги обновления системы до последней LTS или стандартной версии;
Услуги разработки дополнительных возможностей мониторинга для конкретных потребностей клиента;
Услуги интеграции Zabbix с системами учета задач\заявок, управления складским хозяйством, управления конфигурациями, визуализации\отчетности, обмена сообщениями и другими информационными системами;
Разовые сессии по решению проблем (например, штатный специалист в отпуске и прям совсем не может подключиться, ну бывает же) используя удаленное подключение;
Создание шаблонов для устаревшего или уникального оборудования, для оборудования собственного производства, либо в том случае, когда имеющийся шаблон не позволяет получать полную картину о состоянии контролируемого устройства;
Инсталляция решения «под ключ», вплоть до проведения консультаций на месте, расширенной настройки и обучения сотрудников клиента на месте по курсу сертифицированного специалиста;
Консалтинговые услуги, в том числе и варианты с выездом специалиста компании к клиенту.

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

Безусловно большая часть программных продуктов, которые можно отнести к разряду Open Source проектов является именно каноничным свободным программным обеспечением. Они создаются энтузиастами, иногда для решения собственных задач, иногда для достижения какой-либо общественно-полезной цели. Широкое распространение и применение находят далеко не все. В основном это связано с прикладной задачей, решать которую призвана программа.

Но даже те программы, которые становятся достаточно популярны, могут столкнуться с большим количеством проблем. Например, основной разработчик (обычно все-таки это один человек или небольшая группа единомышленников) теряют интерес к дальнейшей разработке и внедрению нового функционала, либо не находят времени на поддержку проекта. Либо среди команды разработчиков возникают существенные разногласия в стратегии дальнейшего развития продукта. Очень часто в таком случае появляются ответвления от материнской версии проекта — копии репозитория, которые начинают развиваться отдельно от основного проекта. Тут далее 3 сценария:

Основной проект остается лидирующим «в своем классе»;
Форк получается более удачным, нежели проект из п.1;
Проект загибается, помирают и форки и их основа.

Что же в данном случае, когда продукт является классическим примером Open Source проекта стоит денег? Да по большому счету все то же что и в монетизируемых Open Source проектах — специалисты. Специалисты, которые знают или могут разобраться как работает та или иная система, которые в состоянии внедрить новую систему, обновить имеющуюся или интегрировать с другими системами. Очень часто такие специалисты уникальны, не то чтобы прям один на миллион (хотя думается что есть и такие примеры), но в пределах какой-либо не очень столичной территории их скорее всего не большой выбор.

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

Стоимость

Прикинуть уровень затрат (именно прикинуть, точно посчитать вообще не получится, хотя расчет может оказаться достаточно близким) на Open Source у себя в компании можно:

Сначала нужно определиться какой продукт предполагается использовать.
Исходя из этого появляются варианты по поддержке — ее либо оказывает разработчик системы на коммерческих условиях (что крайне важно с точки зрения понимания и соблюдения SLA), либо у разработчика нет такой услуги и необходимо искать другие способы. Минусы такой поддержки — дороговизна и не всегда оперативная реакция, если SLA составлен не на основании потребностей заказчика;
Другой способ, как уже писалось выше можно грубо разделить на три варианта:
Поиск и найм фрилансера — наименее затратный, но достаточно рискованный вариант, даже в случае, когда между фрилансером и организацией заключается договор, форс-мажорные риски самые сильные. При этом уровень экспертизы фрилансера может быть действительно очень высок. А может и наоборот;
Подбор специализированной аутсорсинговой организации, которая может оказать необходимый перечень услуг по поддержке выбранной системы. Нечто среднее между поддержкой со стороны производителя (где максимальный уровень экспертизы, и обычно стоимость) и фрилансом (где скорее дешевизна ресурса обусловлена низким уровнем компетенции в узкой специализации);
Найм сотрудника в штат — преимущество такого варианта в полной подконтрольности ресурса, возможности оперативно сориентировать сотрудника на решение определенной задачи. В минусы можно записать достаточно высокую стоимость, риск простоя сервиса при потере сотрудника.
Подбор сотрудника\компании — будь то выбор поддержки от производителя или со стороны независимого фрилансера\организации, либо найм сотрудника в штат, нужно точно понимать по каким критериям выбирать исполнителя. Т.е. по сути обладать экспертизой определять экспертизу. Либо опять же нанять кого-либо (организацию или физическое лицо) обладающее такой экспертизой.

Вывод

В конце статьи хочется подвести итог получившимся измышлениям.

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