Для чего бизнес выбирает опенсорс, и в каких случаях этого недостаточно

Долгое время гиганты ИТ-индустрии смотрели на опенсорс* свысока. Все изменилось, когда узнаваемые компании с миллиардными оборотами признались: бизнес использует множество опенсорс-решений в своих продуктах. Но чем именно такие разработки отличаются от коммерческих? Так ли на самом деле выгоден бизнесу бесплатный открытый код? И как отличить ситуацию, в которой опенсорс может спасти бизнес, от той, где подобные решения превращаются в ограничивающий фактор? Об этом в своей колонке рассуждает Иван Панченко, генеральный директор Postgres Professional.

Иван Панченко

Генеральный директор Postgres Professional

Опенсорс: от философии до лидера рынка

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

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

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

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

Объяснить принцип того, как работает сообщество, лучше всего помогает такая условная схема: из 1 млн пользователей некоторого ПО 100 тыс. хотели бы его изменить или доработать. Из этих 100 тыс. только 10 тыс. достаточно квалифицированы, чтобы действительно сделать это. Из них 1 тыс. не поленится это сделать, из которых 100 человек справятся хорошо. И лишь работа 10 человек из ста устроит сообщество и действительно войдет в итоговой продукт.

Этот пример объясняет, почему хорошо работает такая модель разработки только для того свободного софта, у которого очень много высококвалифицированных пользователей. Именно так развивались ядро Linux и СУБД PostgreSQL: свободный продукт, который возник из идеи и дорос до лидирующего положения на рынке.

Неудивительно, что опенсорс не смог избежать столкновения с коммерческими компаниями — и титаны ИТ-мира стали воспринимать его как конкурента. Это произошло, когда операционная система Linux захватила существенную часть серверного рынка. С Linux пытались бороться, над ним смеялись, считая открытый код чем-то несерьезным. Но уже в начале 2000-х стало ясно, что опенсорс постепенно занимает место на рынке, — стало известно, что большинство серверов в интернете и в сетях телекоммуникаций работают на Linux. А в 2002 году Skype, у которого на тот момент было 2 млрд абонентов, удивил всю индустрию, заявив, что работает на свободном PostgreSQL.

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

Почему разработчики делятся кодом

Поскольку опенсорсом начали пользоваться более серьезные организации, к его разработке стали присоединяться не только отдельные энтузиасты, разбросанные по всему миру, но и профессиональные компании. Они развивали свободные продукты и оказывали услуги для бизнеса. Например, появились несколько крупных поставщиков Linux и компании, создавшие собственные коммерческие версии PostgreSQL.

Интересно, что при активной коммерциализации принцип опенсорс-сообщества остался неизменным: дорабатывая код, компании делятся им с другими, отдавая в открытый доступ. Наша компания тоже этим занимается: мы разрабатываем коммерческую версию продукта, вносим в нее свои передовые разработки, а затем постепенно делимся ими с сообществом.

Казалось бы, какой смысл делиться тем, что ты продаешь? Но, оказывается, когда работаешь в международной кооперации, важно, чтобы не только ты один заботился о своем программном коде. Когда делишься им с другими, они помогают его развивать, берут на себя решение каких-то проблем, с которыми иначе ты бы остался один на один. Именно поэтому мы, как и другие аналогичные компании из разных стран, делимся друг с другом идеями и наработками. Это взаимовыгодно, если партнеры по сообществу честно участвуют в процессе на паритетных началах. В среднем так оно и есть.

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

Однако ошибкой будет думать, что любой программист может повлиять на опенсорс. Это сообщество, и в нем есть свое устройство, в успешных продуктах всегда довольно консервативное. В случае с PostgreSQL оно максимально децентрализованное, и принятие решений в нем скорее напоминает демократию новгородского типа: большинство должно быть как минимум не против изменений. Здесь есть определенное количество людей, авторитетных членов сообщества, которые имеют право вносить изменения в код. Любое предложение сначала проходит через кого-то из них. Если оно покажется им интересным, они возьмутся за работу. При этом важно, чтобы остальные участники не были категорически против.

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

Как открытое становится коммерческим

Сам по себе опенсорс и готовые продукты, в основе которых он лежит, — разные вещи. В мире PostgreSQL существует несколько компаний, которые разрабатывают коммерческие СУБД и одновременно совершенствуют их базу, то есть свободный PostgreSQL. Подобные компании вносят в свои продукты так много изменений, что уходят далеко от изначального кода.

В первый год после создания Postgres Professional мы предполагали, что обойдемся одним опенсорсом, улучшая его, распространяя коммерческие расширения или отдельные патчи к нему. Но как только появилось несколько клиентов, выяснилось, что индивидуальный набор патчей у каждого практически невозможно поддерживать. Мы быстро пришли к тому, что нужно выпускать собственные версии, то есть, по сути, создать отдельный продукт.

В первый год работы мы запустили стандартную версию, а в начале второго года — Postgres Pro Enterprise. Она сразу оказалась весьма далекой от опенсорса, поскольку включала те наши разработки, прием которых сообществом потребовал бы многих лет и огромных трудозатрат.

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

Плюсы и иллюзии: что мотивирует выбирать опенсорс

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

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

В случае с чистым опенсорсом никто пользователю ничего не должен, и можно не надеяться на своевременную и бесплатную помощь. Так попытка сэкономить на «бесплатном» может вылиться в крупные расходы. Если в компании нет специалистов достаточного уровня, а таких специалистов на всех не хватит, то интеграция опенсорса может обернуться безрассудством.

Важный аргумент в пользу выбора СУБД — производительность. Многие заказчики ставят ее на первое место, поэтому и для нас повышение производительности превратилось в задачу номер один. Мы решаем ее, совершенствуя различные механизмы внутри СУБД.

На российском рынке символом требовательности к СУБД стала платформа «1С», которая создает довольно сложную нагрузку для базы данных. Это настоящий вызов для оптимизатора и других подсистем Postgres, поэтому мы много работаем над повышением производительности Postgres Pro в расчете на использование в приложениях на базе «1С». Для международного сообщества такого приоритета нет, но для российского рынка эти оптимизации критически важны. Тут мы достигли хороших результатов, в ряде характерных задач они приводят к росту от десятков процентов до нескольких порядков, в том числе при одновременной активности в системе нескольких тысяч пользователей. Этих и многих других улучшений нет не только в опенсорсной версии СУБД PostgreSQL, но и в других рыночных решениях на ее базе.

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

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

Почему PostgreSQL не заменит коммерческие решения для бизнеса

В подкасте Ивана Панченко подробнее рассказано о том, почему PostgreSQL нельзя назвать полноценной заменой коммерческих решений, а также как в Postgres Professional развивают собственную линейку СУБД для большого бизнеса

Опенсорс в эру ИИ: новые возможности или начало конца?

Технологические тренды неминуемо влияют на опенсорс и быстро сменяют друг друга: то, что вчера было свежей тенденцией, сегодня уже потеряло актуальность. К примеру, облачные вычисления — модный современный тренд, хотя и далеко не новый. К ним сейчас относятся с опаской, особенно в России, так как что излишняя централизация данных делает компании более уязвимыми. Тем не менее, сами по себе облачные вычисления — перспективная тема, поскольку они дают технологические возможности для более гибкого распределения вычислительных ресурсов, что приводит в конечном счете к существенному снижению затрат.

Значительно более свежий тренд в области СУБД — искусственный интеллект (ИИ). В последние годы мы активно исследуем области применения ИИ для работы с базами данных. У нас есть ИИ-продукт, который позволяет пользователю получать ответы, базирующиеся на документации PostgreSQL, коммерческой СУБД Postgres Pro и других опубликованных источниках. В дальнейшем мы сделаем так, чтобы продукт на основе ИИ мог автоматически подстраивать параметры базы данных под текущую нагрузку, что поможет администратору.

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

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