Привет, Хабр! На связи Александр Чебанов, product owner компании Modus.

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

Итак, для начала разберемся, что же это такое.

Суть подходов

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

При этом, набирают популярность гибридные проекты, так называемые форки. Например, взял вендор бесплатный Apache Superset, доработал, прикрутил фронтенд в корпоративном стиле – и продает как новую аналитическую платформу. Минус в том, что на российском рынке форки иногда продают по такой же стоимости, как и индивидуальную разработку. И на этом, я считаю, основано большинство претензий к проприетарному ПО, кроме высокой (не всегда) стоимости.

Например, наш Modus – это проприетарное решение, которое мы писали сами. Но нужно понимать, что разработка никогда не обходится совсем без применения opensource-ресурсов – это как каждый раз заново изобретать колесо. Все дело в процентном соотношении. Я имею в виду, что мы не строим целиком продукт на чем-то вроде Apache Superset, но активно используем открытые библиотеки и фрейморки. Например, на фронтенд частично применяем Material UI. Также используем библиотеки визуализаций - ECharts, платные GoJS, amCharts и т.п. Для карт мы используем некоммерческую библиотеку Leaflet.

На backend используем библиотеки и драйверы, которые частично есть на Github. Используя открытые библиотеки, мы, в том числе, можем непосредственно повлиять на их развитие и сделать их лучше.

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

Из определения кажется, что ответ очевиден: бесплатно,
есть комьюнити, можно дорабатывать – «конечно», выбираем открытый код! Но не
все так просто – давайте посмотрим поглубже.

Когда опенсорс – не опенсорс

Главный принцип Opensource, на мой взгляд, можно процитировать из книги Роберта Мартина «Идеальный программист»:

«Разработчики пишут программы с открытым кодом для самих себя, когда им понадобится работоспособное решение».

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

Второй принцип – это бесплатное использование. Если разработки можно приобрести только после оплаты – то такой продукт можно отнести к платным библиотекам, но не к opensource.

Приведу пример. Вот здесь я писал, что мы при решении некоторых задач используем технологическую платформу 1С. Несмотря, на то что бизнес логика приложения описывается как правило открытым исходным кодом на языке 1С, это проприетарная low code платформа.

У 1С нет открытого сообщества, кроме самой фирмы 1С, которая развивает и разрабатывает модули, новые библиотеки и т.п., кроме того, доступ к ним всегда платный.  

Еще есть комьюнити Infostart, достаточно популярное – более 8 млн подписчиков. Оно создает сервисы, которые помогают выполнять проекты на платформе 1С.  Казалось бы, первый пункт совпадает. Но в конечном счете цель этого ресурса – монетизация разработок, поэтому это также не opensource.

Минусы двух подходов

Сравним минусы:

Минусы проприетарного продукта

• бюджет и лицензирование. Проприетарное ПО, как правило, платное, а free-лицензии имеют ограниченный функционал. Это необходимо для существования вендора, как бизнес-единицы.

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

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

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

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

• vendorlock. Как правило, платное ПО имеет закрытый код, поэтому все доработки возможны только через вендора, что порождает зависимость от него. На самом деле, это можно отнести к минусам только частично, т.к. этот вопрос у современных BI-систем все больше и больше решается с помощью low(no)-code. Например, та же платформа 1С.

Минусы opensource

• разработчики разрабатывают для разработчиков. Это значит, что его цель - не получение прибыли, поэтому нет необходимости упрощать функционал для менее опытной аудитории. К тому же, opensourse-продукты часто перенасыщены функционалом и имеют несколько путей решения одной и той же задачи, что делает их не дружелюбными к пользователям. У каждого решения задачи есть свои «подводные камни», которые не всегда возможно определить, если вы не погружены в продукт.  

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

• низкий уровень пользовательской поддержки. Поскольку открытое ПО поддерживается целиком и полностью сообществом, то пользователь может столкнуться с проблемами, которые не сможет решить сам или для которых не разработана документация.

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

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

• более долгий срок внедрения или разработки, т.к. в бизнесе, не связанном с IT, как правило, нет готовых разработчиков – то их придется нанимать, обучать и погружать в проект.

Плюсы двух подходов

Поговорили про недостатки, теперь посмотрим плюсы:

Преимущества Opensource

• бесплатность. Такое ПО можно скачать, использовать и распространять без ограничений. Но, на самом деле, на проект opensource нужно закладывать гораздо больший бюджет на поддержку и развитие системы внутри компании, чем на «коробку».

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

• независимость - пользователи не зависят от одного поставщика или разработчика, что означает, что они могут не бояться, что бизнес перестанет существовать или выпускать новые релизы и фичи.

• новые идеи. В сообществе появляются новые разработчики, которые разрабатывают новые модули, библиотеки, вносят новые идеи и добавляют новые функции.

• поддержка комьюнити. Для того, чтобы ответить на вопрос или исправить ошибку у пользователя есть целое сообщество разработчиков – как правило, это быстрее, но не гарантирует точного и четкого ответа.

Преимущества проприетарного ПО

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

• гарантированная поддержка. В коробке с ПО вендоры, как правило, предоставляют более качественную техническую поддержку в определенные сроки. То есть, вам гарантированно помогут решить возникшую проблему.

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

• высокое качество. Вендор, как правило, несет ответственность за решение, которое он продает. Поэтому разработчики обычно проводят более тщательное тестирование и контроль качества перед выпуском продукта на рынок. В случае обнаружения ошибок их исправляет вендор.

Что выбрать

Если бы я был заказчиком, то не ориентировался бы на какой-то конкретный тип продукта – у них, как мы увидели, есть плюсы и минусы. Есть плохая проприетарная разработка и качественный opensource, и наоборот.

Нужно смотреть, прежде всего, на бюджет, ресурсы и задачи, которые у вас есть. Если бюджет ограничен или его нет, нет специфических требований, есть свои разработчики и вам не нужен продукт «вчера» – выбирайте из популярных opensource-продуктов или недорогих форков.

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

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