Сколько существует ПО, столько админы и программисты спорят о свободном и несвободном ПО.  Тема эта древняя и, казалось бы, все участвующие в споре стороны давно определились с лагерем, за который они “топят».

И так бы все и продолжалось, если бы в 2022 году картинка радикально не поменялась. Такие привычные и понятные продукты ушли из России, оставив многих перед необходимостью искать альтернативы. На встречах с заказчиками я начал снова все чаще слышать старые вопросы: «А объясните мне, что такого плохого в OpenSource?» и «Почему вы мне рекомендуете платное, если есть прекрасная бесплатная альтернатива?». Если на этом месте сразу захотелось прекратить читать и нажать на крестик, я дам быстрые ответы: между Open Source и проприетарным ПО гораздо больше общего, чем принято считать, а выбор по принципу «платное ПО или нет» – абсолютно неверная стратегия.

Если вы еще читаете, то давайте разбираться.

Выровняем понятийный аппарат

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

Впервые термин «свободное программное обеспечение» (“free software”) ввел программист Ричард Столлман. В этом определении отразились принципы открытой разработки программного обеспечения в научном сообществе, которые сложились в университетах Соединенных Штатов Америки в 1970-х годах. Переход на свободное программное обеспечение был необходим для сохранности авторства программ и одновременного предоставления возможностей для их критики и чтения всем научным сообществом.

Столлман сформулировал критерии этого процесса:

·          свободное использование;

·          свободное изучение;

·          свободное распространение;

·          свободное улучшение программ.

 Со временем термин «свободное программное обеспечение» стал вызывать вопросы. Некоторые бесплатные программы не поставлялись с открытым исходным кодом, и внешние разработчики не могли их улучшить. Кроме того, термин не запрещал продавать такое ПО: иногда его сначала покупали у производителя, а потом бесплатно распространяли дальше. В 1998 году разработчики придумали альтернативу термину «свободное ПО» и внедрили понятие Open Source, чтобы сменить парадигму с бесплатности на доступность.

Linux-дистрибутивы, распространяемые под свободными лицензиями, — типичный пример Free Software с открытым кодом (Open Source). А вот бесплатная, но закрытая программа вроде Skype — это, может быть и Free Software, но точно не Open Source.

Кто платит за Open Source

Open Source и бесплатность — не одно и то же. Термин “Open Source” указывает на то, что код программы открыт, но готовое решение может не быть бесплатным. Да, зачастую оно бесплатно, потому что по открытому коду другие разработчики тоже могут собрать продукт. Но бывает, что код открыт, а использование ПО стоит денег. И это тоже нормально.

Мир Open Source состоит из сообществ. Примеры — Linux-сообщество, вокруг которого выросла экосистема GNU/Linux или сообщества вокруг популярных библиотек и инфраструктурных проектов. Участие в сообществах может быть разным: от исправления одной опечатки в документации до крупных вкладов в код и архитектуру.

Но сообщества – это не только частные разработчики, и крупные IT-компании тоже не стоят в сторонке. Они очень активно контрибьютят в проекты, и они же активно их спонсируют. Настолько активно, что фактически именно коммерческие IT компании играют доминирующую роль в Open Source движении. Прошу прощения у всех, кто до сих пор думал, что Open Source, это как IT-хиппи – за все хорошее и бесплатное.

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

Apache Server

Все знают, что Apache HTTP Server — это свободное и самое популярное в мире программное обеспечение для веб-сервера. И еще все знают, что поставит его сегодня можно буквально одной командой и совершенно бесплатно. Так в чем смысл развивать бесплатное? А смысл есть.

История Apache началась в 1995 году, когда группа разработчиков, недовольных стагнацией разработки NCSA HTTPd, создала свой набор патчей к серверу — отсюда и название "a patchy server" (сервер из патчей), которое позже трансформировалось в "Apache".

NCSA – это National Center for Supercomputing Applications или Национальный центр суперкомпьютерных приложений. Основной источник финансирования – Национальный научный фонд США, расположен в Университете Иллинойса. Ну, то есть ребятки форкнули университетскую разработку. Просто и незатейливо.

В 1999 Основана Apache Software Foundation (ASF), которая по сей день ведет развитие Apache.

А теперь давайте посмотрим, кто финансирует ASF:

 Помимо этого, есть целевые спонсорские программы на конкретные активности и добровольные пожертвования сообщества. В общем не альтруисты они. Совсем.

Так для чего все эти IT-гиганты тратят такие деньги? Если кратко, то причины такие:

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

2.       Разработанное можно не просто использовать as-is, а использовать код для разработки своих продуктов. И тут уже не просто экономия. Тут настоящие деньги – на порядки больше вложенного.

 Вот только некоторые продукты, где используется то, что создали ASF:

 И это не исключение. Практически все известные Open Source-проекты имеют под собой вполне коммерческую основу.

Кстати, 2 интересных факта в тему:

1.      ГК Astra Linux имеет Серебряный статус участника в The Linux Foundation с 2011 года.

2.      В 2022 году аналитики подсчитали, что 44% от числа всех PR( Pool Request) в код Greenplum внесли специалисты Arenadata. Кстати, сейчас свободная версия дистрибутива Greenplum называется Greengage, и принадлежит Arenadata, в то время как Greenplum закрыл код и стал проприетарным.  

Выводы

Так что получается, что и свободное ПО часто имеет вполне понятную коммерческую основу. Просто оплачивается этот труд по более сложной схеме, чем просто плата за использование. Главный ресурс свободного Open Source ПО – комьюнити! Если у продукта большое комьюнити, то и продукт этот сильный. И привлекают финансирование такие проекты тоже более эффективно.

Но главное в ПО – это не то, какое классное оно сейчас. Самое главное – каким оно будет в будущем. Причем часто не очень даже далеком. Будет ли появляться новый функционал вслед за новыми требованиями вашего бизнеса и изменением окружения? Будут ли выпускаться патчи на баги и ИБ уязвимости?

Когда меня раньше спрашивали, что использовать – Open Source или коммерческое ПО, я автоматически рекомендовал коммерческое. Мотивация была простая, как палка – если Open Source, то ваши риски – только ваши. Если производитель ПО – какая-то IT компания, то вы часть рисков перекладываете на нее – за те деньги, что вы платите.

Но с тех пор мир сильно изменился. И не только в России.

Например, компания Red Hat однажды просто взяла и объявила, что практически закрывает проект CentOS (вместо точной копии дистрибутива Red Hat теперь есть только нестабильный экспериментальный CentOS Stream). Проблемы возникли у всех, ведь CentOS для тестовых и некритичных нагрузок была отличным вариантом. Но с этим ничего нельзя поделать – вы не платите за ПО, а значит просто не имеете права голоса. Потому что правило всегда одно: кто платит – у того больше прав. А уж про то, как «проверенные и надежные» производители проприетарных продуктов умеют «хлопать дверью», бросая пользователей с оплаченной техподдержкой на миллионы долларов, мы всё в России знаем.

Получается, что верить нельзя никому? И да, и нет. То есть, да, доверие к вендорам в принципе основательно подорвано. Но нет, принимать сложные решения придется даже так. На смену вере пришло мое любимое риск-ориентированное мышление. А оно нам говорит, что самое безопасное – просто нанять программистов, продактов, менеджеров, купить сотни и тысячи серверов, и через пару лет самим разработать все, что требуется. И мы знаем, что по такому пути в основном идут компании с безлимитными бюджетами. Например, бигтехи.

Всем остальным приходится искать баланс между собственной разработкой и использованием продуктов сторонней разработки. Если немного сместить угол зрения, то получается, что вы, используя продукт, разработанный третьей стороной, жертвуете гибкостью в пользу снижения TCO.

То есть если у вас нету сотни-другой программистов, и 2-5 лет в запасе, вы идете и покупаете у кого-то ERP, потом следуете в русле бэклога разработчиков этой ERP, и радуетесь экономии, несмотря на высокую цену дистрибутива (сарказм). Да, это зависимость. И работать с ней надо также, как с любой другой зависимостью – смотрим внимательно на вендора, на его бэклог, на его команду разработки, ресурсы и планы, и принимаем взвешенное и обоснованное решение. Ну и потом проводим оценку рисков, которую каждый CIO просто обязан регулярно!

Именно так мы, по сути, действуем с командой сами, когда составляем дорожные карты трансформации. Потому что мы делали так еще до того, как это стало мейнстримом. Например, упомянутая выше история с закрытием проекта CentOS встревожила почти всех наших клиентов, но не привела к каким-то серьезным потерям. Для нас решение Red Hat тоже было сюрпризом, но не катастрофой. Потому что никто никогда не рекомендовал использовать CentOS для Mission Critical систем. Поэтому за 1-2 года все спокойно ушли на альтернативные решения.

Так что постановка вопроса «OpenSourcevs проприетарный платный продукт» неверна в корне. Тут гораздо больше вводных, которые тоже необходимо учитывать. Бесплатных решений не бывает в принципе – это коммерческая уловка, не более.