Что такое Open Source, и с чем его едят в наше время

Вопрос определений

Начнём с определений, а не с хронологии, чтобы прежде всего понять, каков предмет рассмотрения.

Существуют два близких, но различных понятия - Open Source Software (OSS) или Free Software (СПО). Иногда их объединяют в понятии FOSS — Free & Open Source Software, или даже FLOSS (добавляется слово «Libre», чтобы подчеркнуть, что «Free» - это не бесплатное, а свободное). За двумя понятиями стоят две различные общественные организации — Free Software Fondation (FSF) и Open Source Initiative (OSI). В русских текстах OSS иногда переводится как ОПО (открытое ПО), но в данной статье мы обойдемся без этого неблагозвучного перевода.

Известный программист и идеолог СПО Ричард Столлман в 1985 году основал FSF, и определил СПО как предоставляющее 4 основные «свободы», с современной версией которых^[1] можно ознакомиться на сайте FSF. Для американского читателя это перекликается со знаменитой речью Ф.Рузвельта (1941г) о четырёх свободах (слова, вероисповедания, от нужды, от страха), которая в дальнейшем легла в основу принятой ООН в 1948 г. Всеобщей декларации прав человека. ПО, не являющееся свободным, FSF называет проприетарным (собственническим).

Open Source является очевидным мировым трендом последних десятилетий

В России определение СПО официально дано ГОСТом Р 54593-2011^[2]. Это перевод на русский язык четырёх базовых свобод Столлмана, а именно (далее цитата из ГОСТ): ... программное обеспечение, распространяемое на условиях простой (неисключительной) лицензии, которые позволяют пользователю:

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

Разработано несколько десятков публичных лицензий, наиболее популярны из которых GPL, LGPL, BSD, MIT, Apache^[3]. Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft

Новым словом являются лицензии типа SSPL^[4], ставшие ответом на распространение облачной модели доступа к ПО.

Open Source Initiative – НКО, основанная в 1991 г Эриком Раймондом, известным программистом, автором знаменитой статьи «Собор и Базар»^[5], прекратившим сотрудничество со слишком авторитарным и радикальным Столлманом.

Справедливости ради надо сказать, что основатели движения СПО/OSS часто придерживались радикальных политических взглядов — анархизма, отрицания собственности и т. п., и пытались воплотить свои взгляды в концепции распространения программного обеспечения и работы над ним. Однако в наше время в FOSS наступила эпоха прагматизма, и горячность общественно-политических радикалов сменилась экономическим расчётом и соображениями об эффективности бизнеса.

В определении, которое OSI даёт Open Source, целых 10 пунктов, с которыми можно ознакомиться на сайте OSI^[6], смысл которых в отсутствии ограничений на распространение исходных кодов. В отечественных стандартах аналога нет.

Поскольку большинство популярных публичных лицензий удовлетворяет как требованиям СПО, так и OSS, люди часто путают эти понятия. Однако это не одно и то же. Столлман объясняет разницу в статье^[7], различия более философские, чем практические, и в большинстве случаев речь идёт об одном и том же ПО. Но когда мы говорим о нём, как о СПО, мы имеем ввиду философскую сторону – насколько оно обеспечивает фундаментальные свободы. Когда мы говорим о нём как об Open Source, нас прежде всего интересуют прагматичные вещи – модель разработки и распространения этого ПО, его пригодность для решения конкретных задач, его применение в бизнесе и т.п.

Как возник Open Source?

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

В 1969 году компания IBM начала продавать ПО отдельно от компьютеров. Во второй половине 70-х — начале 80-х ПО было признано в США объектом авторских прав. Возникло соответствующее законодательство и судебная практика, возникло понятие лицензии на использование ПО, которая может быть продана и куплена.

Параллельно разрабатывалось и открытое ПО. В 1969 г Кен Томпсон и Деннис Ритчи из Bell Labs создали первую версию свободной операционной системы UNICS. Они делали это для себя и своих коллег. В 1973 г. операционная система была опубликована под именем UNIX и распространялась по цене носителей, в основном в научной среде. Тогда же возник и первый дистрибутив свободной операционной системы — BSD (Berkeley Software Distribution), содержащий саму систему UNIX и ряд полезных утилит. Затем Bell Labs закрыла код UNIX и подняла цены. Начали возникать клоны этой операционной системы. Ученым же понравился свободный обмен программным кодом, и в их среде идея Open Source, хоть и никак не оформленная, продолжала жить и созревать.

В 1988 г. университеты MIT и Berkeley опубликовали свои Open Source лицензии. В 1989 г. FSF Ричарда Столлмана опубликовала свою «заразную» лицензию GPL.

На рубеже 1980х и 1990х годов родился интернет, который радикально увеличил возможности обмениваться информацией, в том числе — программными кодами. Он же резко увеличил и потребности в новых программах, расширив сферу применения компьютеров. В 1991 г. финский студент Линус Торвальдс создал первую версию новой операционной системы Linux, которой суждено будет перевернуть мир и стать знаменем СПО и Open Source. 90-е годы стали временем роста OSS, обусловленным появлением интернета. В 1991 г. Ларри Уолл выпустил 4-ю версию своего языка Perl, который начал резко набирать популярность как универсальный инструмент для программирования. В 1993 г вышла свободная операционная система FreeBSD. В 1995 г. Майкл Стоунбрейкер открыл код СУБД Postgres.

В 1990-е и начале 2000х годов OSS развивалось преимущественно учеными и интернет-компаниями (такими как Yahoo, Рамблер, Google и др.). Как и для программистов в 60е годы, для них это ПО было побочным продуктом, который помогал решать их основные задачи. Сложилась ситуация, когда различные компании, в том числе конкурирующие, были заинтересованы в развитии этого ПО, при этом его продажа никого из них не интересовала.

Поэтому в начале 2000х годов OSS плотно заняло сервера интернет-компаний и университетов, на ПК же царил Microsoft Windows.

Но уже в 1998 году Microsoft почувствовала угрозу со стороны OSS для своего рынка. Об этом недвусмысленно говорят т.н. Хеллоуинские документы^[8], ставшие достоянием общественности благодаря утечке информации. В 2003-2007 г. Microsoft проводила рекламную компанию Get The Facts, в которой, манипулируя цифрами и фактами, заявляла о том, что Linux во всех отношениях хуже, чем Windows. Глава этой компании Стив Балмер открыто называл OSS «раковой опухолью».

Тем временем Apple отказался от ядра операционной системы собственной разработки и начал развивать ОС для своих ПК на базе BSD. Google приступил к разработке ОС нового поколения для мобильных устройств – Android – на базе Linux (выпущен в 2008 г.). В том же году сообщество Postgres начало активно заявлять о том, что PostgreSQL готов к использованию в Enterprise секторе благодаря общей зрелости продукта, возможности репликации и организации отказоустойчивых кластеров, и, конечно, полноценной работе под Windows.

История заканчивается, и начинается наше время

К 2021 г. ландшафт интересным образом изменился:

• Open Source и коммерческое ПО — более не два разных враждующих лагеря, а два способа разработки, дополняющие друг друга и занимающие свои ниши, определяемые пригодностью этих способов для решения задач разных классов.
• Разработкой OSS занимаются уже не только отдельные энтузиасты, но прежде всего крупные компании, реализующие свои планы ради своих интересов. Например, основными контрибьютерами Linux сейчас являются Microsoft (как это ни странно), Red Hat, Google, Huawei и другие гиганты. Этот процесс обусловлен тем, что и потребителями OSS стали корпорации и правительства, а их потребности могут быть удовлетворены только разработчиками соответствующего масштаба. Второе десятилетие XXI века стало парадом «каминг-аутов» компаний, заявивших о том, что они используют, причём существенным образом, OSS.
• Сложность крупнейших продуктов OSS достигла такого уровня, что сама по себе публикация исходников уже не означает полной открытости. Чтобы заняться разработкой чего-то на базе этих исходников, требуются огромные временные и трудовые затраты. Разобраться в десятках миллионов строк, без какой-либо проектной документации (не только её публикации, но и даже её наличия принципы Open Source не требуют) — вовсе непросто. Иногда – практически невозможно, с учетом того, что продукт продолжает развитие и код меняется. Пока ещё не родилось понятие Open Design по отношению к программному коду — когда не только сами коды открыты, но и документы, объясняющие внутреннее устройство системы, обязательно присутствуют и тоже открыты.

То, как идеалисты-основоположники Столлман, Раймонд и другие видели OSS и СПО – в наше время уже не совсем применимо.

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

Классический Open Source, в котором часть пользователей оплачивает продукт своим вкладом в его разработку, в облаках не работает. Поэтому многие деятели Open Source заметили в облаках угрозу, благодаря этому возникла лицензия SSPL [5], по которой с 2018 г. распространяется Mongo DB, а с 2021 г. - и Elasticsearch. SSPL является более «заразной», чем GPL, поскольку она требует от того, кто использует продукт для предоставления какого-либо сервиса, должен полностью открыть исходные коды абсолютно всего ПО, используемого в сервисе. «Заражается» весь сервис целиком. В каком-то смысле, это является логичным расширением GPL на случай облаков, но тем не менее, OSI и FSF эту лицензию не признали. Вроде бы, исходники открыты, но это не Open Source. И не СПО.

Конвергенция Open Source и коммерческого ПО

Для классического Open Source свойственна «Developer-driven» модель разработки, в которой основным источником разработки являются идеи разработчиков. Естественно, разработчику трудно встать на позицию конечного пользователя, если этот пользователь не является грамотным ИТ-специалистом. А института аналитиков, наводящих мосты между пользователями и разработчиками, в классическом Open Source нет. Это не удивительно: Open Source зародился стихийно, люди писали программы, которые нужны им самим.

Основными принципами Developer-driven подхода являются:

• «Пользователи не знают, чего хотят»
• «Мы лучше знаем, что им нужно»
• «Потому что мы сами – лучшие пользователи»

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

• «Сделайте мне как у соседа»
• «А ну ка, быстро удовлетворили клиента!»
• «Почему они снова делают не то, что мы хотим!»

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

Если рассмотреть эволюцию сообществ, разрабатывающих крупные Open Source проекты, как правило, можно заметить три стадии:

1. Индивидуальные разработчики (энтузиасты) разрабатывают ПО для себя и подобных себе;
2. Разработчики, нанятые компаниями, использующими OSS, разрабатывают ПО с учетом интересов этих компаний;
3. Возникают специализированные компании, развивающие и коммерциализующие OSS.

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

Для любого ли применения хорош Open Source?

Если посмотреть на примеры удачных применений Open Source, это будут прежде всего продукты, относящиеся к системному ПО — операционные системы, СУБД, средства виртуализации, Web-сервера, компиляторы и интерпретаторы языков, системные библиотеки, и т. п. Относительно удачным можно считать OSS-офис LibreOffice, который впрочем, происходит от StarOffice, созданного компанией Sun Microsystems. Компания Oracle через год после поглощения Sun'а прекратила разработку офиса, и он постепенно начал собственную жизнь.

Найти удачный Open Source проект типа бухгалтерии, ERP-системы, CAD/CAM системы довольно трудно. Что-то такое есть, но оно сильно уступает своим коммерческим собратьям.

Итак, Open Source хорош для системного ПО, и заметно менее эффективен для прикладного. Причины этого, по всей вероятности, такие:

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

Open Source и государства

С 1999 г. дальновидные китайцы развивали свой дистрибутив Linux под названием RedFlag. Но тогда и Linux был незрел, и возможности Китая были гораздо меньше, чем сейчас. Перевести всю страну на RedFlag не удалось, и проект был закрыт^[9]. Однако, встретившись с американскими санкциями, Китай решил укрепить свою технологическую независимость и снова начал активно разрабатывать OSS^[10].

В 2003 г. городской совет Мюнхена, видя страдания пользователей Windows NT4, принял решение о переходе на OSS^[11]. Проект занял 10 лет. Многие приводили мюнхенский проект как пример успеха OSS. Однако страдания пользователей лишь увеличились. Проблема в том, что пользовательское OSS в то время было ещё недостаточно зрело. Серверное ПО можно было перевести, и это не вызвало проблем. Поэтому пришлось переезжать обратно на Windows, что было многими воспринято как эпический провал OSS. В начале 2020 г. Мюнхен снова анонсировал намерение двигаться в сторону OSS, но уже осторожнее^[12]. Напоминает гартнеровский Нype Сycle, не правда ли?

В 2012 г. премьер-министр Франции Жан-Марк Эйро распространил циркулярное письмо^[13], в котором предложил французским министерствам и ведомствам переходить на Open Source. За несколько лет это было сделано. Крупнейшие системы, в т.ч. налоговая и пенсионная, МВД, таможня и другие были переведены на OSS — Linux, Postgres и т.п. Одновременно увеличилась и доля OSS в бизнесе — в т.ч. благодаря наращенной за счет правительственной программы компетенции.

В конце 2010 г., в бытность Владимира Путина премьер-министром, правительство РФ приняло план перехода органов государственнной власти и федеральных бюджетных учреждений на СПО на 2011-2015 гг.^[14], но этот план не был выполнен. Анализ причин невыполнения не был опубликован, но, очевидно, в России не хватало компаний, способных взять на себя ответственность за функционирование СПО в государстве. Зрелость самих продуктов СПО уступала современной, но пример Франции показывает, что при продуманном подходе и наличии должной компетенции в стране задача могла бы быть решена, хотя бы частично.

Когда в России начался процесс перехода госорганов на отечественное ПО и с 2016 г. начал заполняться Единый реестр Российского ПО^[15], оказалось, что системное российское ПО практически полностью представляет собой продукты на базе международных проектов OSS.

6 сентября 2018 г. Минцифры опубликовало на своем сайте статью «СПО в госорганах»^[16], в которой приведен ряд интересных тезисов, которые мы рассмотрим, чтобы проиллюстрировать важные особенности и популярные заблуждения.

• Прежде всего, СПО отождествляется с OSS, что не совсем корректно.
• Мнимая бесплатность СПО. Отсутствие лицензионных отчислений не означает бесплатности. В реальности, необходимость приобретения техподдержки, затраты на адаптацию и эксплуатацию ПО, переобучение персонала — это расходы, которыми часто пренебрегают, положившись на бесплатность СПО. Напомним слова Столлмана: Free Software — это не Free as beer, но Free as speach.
• Мнимая бо́льшая безопасность СПО. Открытость часто рассматривается как гарантия отсутствия уязвимостей. Эрик Раймонд сформулировал «Закон Линуса» как "Given enough eyeballs, all bugs are shallow", т.е. при достаточном количестве глаз все баги на поверхности. Увы, это оказалось не так. Вероятно, такой «закон» работает только для довольно простого ПО. В СПО находилось много ошибок, в том числе критических^[17], вот, например, недавнее:^[18]. Группа исследователей из университета Миннесоты решила проверить «закон Линуса», намеренно пронося в ядро системы уязвимости, которые оказывались не обнаруженными до тех пор, пока учёные хакеры не признались в содеянном^[19]. Уязвимости в СПО оказалось искать трудно, особенно если его разрабатывали другие. Отечественным разработчикам поможет в этом созданный ИСП РАН совместно с ФСТЭК некоммерческий Центр исследования безопасности Linux^[20].
• «СПО легко адаптируется: большое количество доступных свободных приложений позволяет приспосабливать их под конкретные нужды пользователей и создавать на их основе новые необходимые программы». К сожалению, СПО не адаптируется само. В отличие от коммерческого ПО, вендоры которого предоставляют пользователям готовые решения, СПО представляет собой набор отдельных элементов, которые можно связать в готовое решение. Это требует определенных, и немалых, трудозатрат, и в целом более высокой квалификации со стороны тех, кто внедряет СПО.
• «использование СПО учитывает национальные интересы. Несмотря на то, что создание свободных программ неотделимо от мирового сообщества разработчиков, сервисные услуги по их адаптации, внедрению, поддержке и развитию оказывают, как правило, национальные фирмы, что более выгодно государству и обществу.» Это верно лишь отчасти. Правильнее сказать — разработка СПО соответствует национальным интересам. Дело в том, что без глубокого понимания внутреннего устройства продукта, которое может быть получено только в ходе его разработки, невозможно качественно оказывать упомянутые сервисные услуги, в том числе техническую поддержку (которая включает, кстати, исправление ошибок и уязвимостей, см. выше о том, насколько «легко» их найти). Без развития разработки СПО и соответствующих компетенций мы заменим шило на более дешёвое (но довольно тупое) мыло: вместо зависимости от иностранных корпораций, которые хоть что-то могут гарантировать, получим зависимость от международных сообществ, которые явным образом отказываются от гарантий.

«Бум» 2021 года

Бум назрел давно и созревал постепенно, поскольку в основе наиболее фундаментального отечественного ПО — операционных систем – лежит Linux, который является Open Source.

10 февраля 2021 г. газета "Ведомости" сообщила^[21], что Минцифры готовит проект постановления, изменяющего условия для попадания в реестр отечественного ПО, согласно которому российским разработчикам не потребуется подтверждать «существенную доработку» свободно распространяемого программного продукта с открытым кодом. Иными словами, открыт путь в Реестр и далее в госзакупки для мастеров наклеивания своих шильдиков на бесплатные продукты. Возможно, это не соответствовало истинным замыслам министерства, но вызвало определенную обеспокоенность в отрасли.

В конце мая 2021 г. член Наблюдательного совета фонда РФРИТ, одного из ведущих государственных институтов развития, Андрей Ванин сообщил^[22], что Open Source как перспективному направлению в ИТ будет уделяться особое внимание.

В начале июня на ПМЭФ прошла дискуссия на тему «Open Source в России: быть или не быть», на которой заместитель министра цифрового развития Максим Паршин заявил о необходимости принятия в России стратегии развития Open Source^[23]. Эта стратегия в настоящий момент готовится министерством с привлечением экспертов из отрасли.

Зачем Open Source российскому государству?

Open Source является очевидным мировым трендом последних десятилетий. Его популярность непрерывно росла, и сейчас её уже невозможно заткнуть под ковёр. Соответствие мировым трендам (лучше, конечно, их опережение) — это то, что необходимо отечественной отрасли для того, чтобы быть конкурентоспособной. На взгляд автора, речь идет о попытке дать нашим ИТ-шникам своеобразного пинка, чтобы они проснулись и побежали. Конечно, в наш цифровой век государство заинтересовано в сильной ИТ-отрасли, как для того, чтобы решать свои проблемы, так и для роста конкурентоспособности на мировом рынке, и для того, чтобы во внешнем мире страна рассталась с образом «бензоколонки с ракетами».

И ещё, Open Source — это путь к модернизации ИТ-образования (но это тема для отдельной статьи).

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

Но, занимаясь Open Source в России и насаждая его повсюду, государству важно не перегнуть «палку». Сообщества по-прежнему перестают работать, когда ими пытаются управлять менеджеры или государства. Не хотелось бы, чтобы из Open Source начали делать «лекарство от всего», или новые «нанотехнологии». Есть надежда, что этого удастся избежать. Публикация драфта стратегии поддержки Open Source и её обсуждение, ожидающееся осенью 2021 г., многое покажет.

Автор - Иван Панченко.

Примечания