Не вдаваясь глубоко в детали различий между Open Source и свободным программным обеспечением, будем использовать здесь общий термин ОСПО (открытое и свободное ПО), по аналогии с F(L)OSS (Free/Libre and Open-Source Software). Стоит, однако, заметить, что эти различия, а также важнейшие вопросы лицензий, несмотря на завершение работы над российским вариантом публичной лицензии на ПО («Государственная открытая лицензия»), заслуживают отдельного обсуждения.

Для иллюстрации произошедших изменений отлично подойдет история отношения компании Microsoft к Open Source.

К началу третьего тысячелетия операционная система Linux плотно оккупировала серверы интернет-компаний и лаптопы хакеров, а компании Microsoft оставался рынок ПО для массовых домашних и офисных ПК, серверов для малого бизнеса и бизнеса любого размера, не связанного с Сетью. Однако аналитики Microsoft почувствовали конкуренцию со стороны Linux, и была инициирована антирекламная кампания 'Get the facts', в которой общественности предлагалось ознакомиться с фактами о том, что Linux гораздо «хуже», чем Windows.

Чем хуже? Чем Windows

Стив Балмер, тогдашний руководитель Microsoft, сравнивал Open Source ни с чем иным, как с раковой опухолью. По-видимому, такое впечатление на него произвела «заразность» GNU General Public License. Согласно данным из утекших за периметр компании писем сотрудников Microsoft, известных как Halloween Documents, за патентной атакой SCO на Linux также стояла эта компания.

Однако попытки остановить Linux, как и ОСПО вообще, не удались. Вспомним красивую фразу, приписываемую Махатме Ганди: «Сначала вас не замечают, потом над вами смеются, потом борются с вами, потом вы побеждаете». Так случилось и с ОСПО.

XXI век ознаменовался расширением использования ОСПО в корпоративном сегменте. Это процесс с положительной обратной связью — чем больше ОСПО применяется в платежеспособных корпорациях, тем больше развиваются и сами свободные продукты. Потому развитие ОСПО сейчас и носит взрывной характер, но любой взрывообразный процесс либо что-то разрушает, либо критическим образом меняется сам. Изменились, например, разработчики ОСПО — это уже не столько талантливые одиночки, а сотрудники специализированных компаний и подразделений крупных корпораций: Google, Huawei, Microsoft и пр.

Теперь можно перейти и к самим тезисам — важным положениям, которые стоит учитывать, принимая решение о внедрении ОСПО. Пусть их будет шесть, а не десять, как в известной работе (Владимир Ленин. «О задачах пролетариата в данной революции (Апрельские тезисы)»).

Апрельские тезисы ОСПО

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

2. Открытость все труднее конвертируется в свободу. Многие проекты с открытым кодом существенно повзрослели, например в ОС Linux и Libre Office десятки миллионов строк кода. В таких огромных проектах сложно, практически невозможно разобраться даже при наличии исходников. Вместе с тем традиции и технологии работы над проектной документацией в сообществах Open Source не сложились. Open Source не породил Open Design или чего-то в этом роде. Просто публикация кода и публичная лицензия для таких мегапродуктов почти ничего не значат — если нет технической возможности, то право изучать и модифицировать код бесполезно. «Закон Линуса», сформулированный Раймондом, гласит: «При достаточно большом количестве глаз все баги — на поверхности» [1], однако Раймонд не указывает, какое количество глаз достаточно велико. Если код сложный и его много, то может не хватить глаз всех программистов Земли. Уязвимости в открытых проектах есть, и обнаруживать их нелегко. Если вы, ваша компания или ваши подрядчики не участвуют в разработке свободного/открытого мегапродукта — его открытость даёт вам только ощущение свободы, но самой свободы не дает.

3. Открытость все труднее конвертируется в безопасность. Сегодня много споров о том, как открытость кода влияет на безопасность. С одной стороны, если исходники доступны, то проще искать ошибки, в том числе автоматизированными средствами. Вопрос в том, в чью пользу сработает «закон Линуса»? Будут ли тысячи глаз добрыми или злыми? Как они воспользуются найденными уязвимостями? Обычно все верят, что уязвимости будут быстро и аккуратно исправлены, но открытость хороша в дружественном мире, а в эпоху конфронтации оружием может стать все, до чего дотянутся руки противоборствующих сторон.

4. Облака — угроза классической модели Open Source. Облачная модель потребления услуг предъявила ОСПО очень серьезный вызов. Получая сервис из облака, пользователь не получает копию его кода, не способен его изучать и улучшать. А значит, не может личным вкладом в продукт «оплатить» пользование им. Это нарушает принцип ОСПО как свободного обмена идеями. Ответом на это стала предложенная Mongo DB скандально известная лицензия Server Side Public License, которая признана сообществом несвободной и не открытой, хотя по сути лишь распространяет принцип «заразности» GPL на облака. Сообщества ОСПО еще не выработали единого подхода к облакам, но уже ясно, что облака являются серьезной угрозой для классической модели Open Source и потребуются ее серьезные изменения.

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

6 . ОСПО не ради OСПО. А для чего? Открывая исходный код своего продукта, отдавая его в свободное пользование или внедряя чужое ОСПО, надо четко понимать, зачем это делается, не забывая взвесить все плюсы и минусы.

***

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

Литература

1. Эрик С. Реймонд. Собор и базар // Открытые системы.СУБД. — 1999. — № 9–10. — С. 71–83. URL: https://www.osp.ru/os/1999/09-10/177856 (дата обращения: 21.05.2022).

Иван Панченко (i.panchenko@postgrespro.ru) – заместитель генерального директора, Postgres Professional (Москва).

В редакцию журнала статья была передана 4 апреля 2022 года