июнь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

показать все 

21.06.2024

RAMAX Group расскажет об инструментах повышения операционной эффективности на «RPA Connect: Магия притяжения»

Читать далее 

21.06.2024

Коллаборация ARZip с DLP-системой InfoWatch Traffic Monitor позволяет компаниям повысить свою защищенность

Читать далее 

30.05.2024

Компания «Газинформсервис» объявила о старте работы собственного SOC

Читать далее 

27.04.2024

RAMAX Group рассказала на Smart Mining & Metals об особенностях пилотирования ML-проектов

Читать далее 

показать все 

27.06.2024

Национальный интерес в ИТ

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

07.06.2024

Open Source в бизнесе

Читать далее 

19.05.2024

«Лишние люди» в бизнесе

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

показать все 

Главная / Статьи / Опросы / Open Source в бизнесе

Open Source в бизнесе

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

1. Когда и почему поставщики свободного ПО решают отказаться от открытого исходного кода? Кто выигрывает от этого решения?
2. Какие риски при этом возникают для разработчиков опенсорсного ПО, клиентов и партнеров компании, поменявшей лицензию на свою программу и ограничив ее использование для прежних пользователей?
3. Что в подобной ситуации они могут предпринять?
4. Можно ли совместить интересы компании, ее клиентов и разработчиков при отказе от опенсорсного решения?
5. При каких условиях бизнес-модель компаний ПО с открытым исходным кодом может быть перспективной?

Игорь Глебачев, системный архитектор, группа «Рексофт»

«Единственное условие перспективности компании-разработчика ПО с открытым исходным кодом – это потенциал и компетенции сотрудников»

1. За последние три года неизвестно об отказе поставщиков ПО от открытого исходного кода. Известны факты смены полностью свободных лицензий на ПО с открытым исходным кодом на лицензии, ограничивающие предоставление возмездных сервисных услуг на основе такого ПО с открытым исходным кодом. Например, компании Elastic, Redis и HashiСorp поменяли лицензию с открытым исходным кодом со свободной на лицензию с открытым исходным кодом, ограничивающую коммерческое использование.

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

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

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

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

Денис Беляев, ведущий инженер в ИТ-компании Proscom

«Разработчики, поддерживавшие проект, могут сделать свой форк и развивать его под открытым исходным кодом»

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

В некоторых случаях компании действуют на опережение. Хороший пример – ситуация с Elasticsearch. Компания Elasticsearch BV изменила лицензию в 2021 году на более ограниченную после того, как посчитали упущенную прибыль за использование своего ПО у крупных облачных провайдеров как Amazon.

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

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

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

3. Разработчики, поддерживавшие проект, могут сделать свой форк и развивать его под открытым исходным кодом. А поставщики ПО – обеспечить наиболее безболезненные условия для миграции на новые условия использования ПО.

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

Другой пример, Microsoft. Компания разделила свой продукт VSCode на две лицензии. Исходный код доступен по лицензии MIT, но сами исполнительные файлы с проприетарными библиотеками доступны по закрытой лицензии. При этом каждый пользователь может собрать из исходников свои бинарные файлы и распространять их с открытой лицензией. Например, так сделали VSCodium.

5. Перспективные условия для бизнес-модели компаний ПО с открытым исходным кодом:

1) Продукт с открытым исходным кодом имеет премиум-функционал, не доступный в обычном исходном коде. При этом пользователи готовы за него платить.

2) Продукт с открытым исходным кодом предлагает для крупных компаний платную поддержку, которая покрывает расходы команды.

3) Вендор предлагает не только исходники для самостоятельной развертки, но и свое облачное решение, которое позволяет быстро и легко использовать ПО с открытым исходным кодом с поддержкой от самого производителя. Например, так делают Grafana, Supertokens, Ory, Supabase и другие провайдеры.

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

Григорий Урьев, генеральный директор компании «Синтерра Медиа»

«Open-source, разработанный за рубежом, всегда будет оставаться котом в мешке для пользователя»

Одним из интересных примеров использования open-source программного обеспечения на телевизионном рынке может служить разработанный канадской компанией Haivision протокол потоковой передачи данных SRT (Secure Reliable Transport), который не первый год используется вещателями и операторами для доставки ТВ-сигналов.

SRT – это протокол с открытым исходным кодом, который использует интеллектуальный механизм повторной передачи пакетов данных на основе сетевого протокола для интернета – UDP-протокола (User Datagram Protocol) – совместно с AES-256 шифрованием (симметричный алгоритм блочного шифрования). В свою очередь UDP-протокол курируется рабочей группой по разработке интернет-технологий (IETF), юридическим сопровождением которой занимается опять же зарубежная IETF Administration Llc (IETF Llc). Впрочем, и AES-шифрование, изобретено не в России.

В 2017 году Haivison сделали протокол открытым для всех, после чего множество компаний стали использовать его в своих продуктах, обеспечивая совместимость по приему ТВ-сигналов по данному протоколу от сторонних решений. У доставки ТВ-сигналов через интернет с использованием SRT есть своя армия поклонников: протокол прост в развертывании, универсален, нужен только доступ в интернет заданной полосой пропускания в точках приема и передачи.

Однако есть несколько нюансов, которые, в том числе и приводят к тенденции отказа российских компаний от использования решений с открытым исходным кодом. За любой программой, в том числе open-source, стоит разработчик, компания или ассоциация, которые диктуют правила и могут ставить ограничения в использовании решения. Как видно на примере протокола SRT, за всеми его составляющими стоят иностранные организации, которые подчиняются законам своих стран. И если государство, в котором зарегистрирована конкретная организация, не дружественна к России, то она может заставить внести в лицензию какие-либо ограничения на использование продуктов на территории России.

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

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

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

Евгений Осьминин, директор по развитию и цифровой трансформации компании РДТЕХ

«По результатам нашего исследования “Монитор технологий”, почти треть респондентов не доверяют качеству и функционалу Open Source-решений»

2. Благодаря санкциям и политике импортозамещения, тема OpenSource в нашей стране получила новый виток развития. В переходе на ПО с открытым кодом крупные компании увидели средство снижения рисков для критически важных систем и процессов, а также сокращение затрат. Однако, преодолев риски функционирования санкционных решений, подход к оценке качества ПО несколько изменился.

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

5. На мой взгляд, самая успешная модель в средне- и долгосрочной перспективах, это создание продукта на OpenSorce, что позволяет разработчикам быстро и относительно недорого вывести его на рынок, сформировать пул заказчиков, получить финансовые результаты, после чего, в последующих релизах, планомерно замещать OpenSource-ные решения.

Евгений Гаврилов, руководитель проекта vStack

«Для владельцев и разработчиков, меняющих лицензии, наиболее ощутимым видится риск ухода от использования продукта. Увеличение операционных расходов потребителей никогда не добавляло доверия»

1. Следует разделять смену лицензии и переход от открытого исходного кода к закрытому. Объединяет эти явления одно: желание владельцев интенсивнее монетизировать продукт. Для примера: это возможно путём ограничения формата использования ПО, например, в облачных сервисах, как это сделала компания Redis Ltd, владеющая СУБД Redis.

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

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

3. Вариантов несколько:

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

4. Вероятность такого тройственного компромисса видится ничтожным; практика показывает, что кто-то один, не в полной мере получивший удовлетворение своих потребностей, пойдём своим путём.

5. Наиболее работоспособной показала себя модель монетизации через профессиональные сервисы, практикуемые компаниями RedHat/IBM. На второе место я бы поставил модель с открытой основой и платными опциями на примере компании Confluent. Третий вариант: двойное лицензирование, однако потребители всё чаще стали с недоверием относиться к таким продуктам.

Роман Карпов, директор по стратегии и развитию технологий Axiom JDK

«Можно найти альтернативу, можно договориться с компанией об условиях поддержки опенсорсной версии программы, можно реализовать функционал программы своими силами»

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

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

Например, компания Oracle последовательно прекращала бесплатную поддержку Java 6, 7 и 8. А с 2019 года дистрибутивы Oracle JDK, начиная с 11 версии, и их поддержка стали платными. Это позволило другим компаниям, например, Red Hat, участвовавшим в проекте OpenJDK, предложить свои дистрибутивы и их поддержку.

В России это –  среда исполнения Java Axiom JDK. Дистрибутив внесен в реестр российского ПО и предлагает ряд дополнительных преимуществ, например, версию, сертифицированную ФСТЭК, а также оптимизацию для облаков и микросервисов.

2. Риски могут быть финансовые, связанные с тем, что надо платить, и технологические, связанные с регулярными обновлениями и устранениями уязвимостей безопасности. Если программа, изменившая лицензию, использовалась в решениях, где применение свободного ПО было обязательным, то надо либо искать альтернативную программу, что не всегда возможно, либо самим обновлять и поддерживать ее, что тоже не всегда возможно, так как лицензия может этого не позволять и может требоваться серьезная внутренняя экспертиза, либо обращаться за поддержкой к внешней компании, эксперты которой специализируются на этом продукте или как раз выпускают свой дистрибутив. Например, в России поддержку OpenJDK, Tomcat и TomEE предоставляют инженеры Axiom JDK, которые занимаются Java c 1997 г.

3. Можно найти альтернативу, можно договориться с компанией об условиях поддержки опенсорсной версии программы, можно реализовать функционал программы своими силами. Зависит от сложности решения и рисков для разработчиков, а точнее критичности систем, которые они создают. Например, операционная система или платформа Java – это более 10 миллионов строк кода. Здесь нужна серьезная экспертиза.

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

Ключевые слова: продукт с открытым исходным кодом, бизнес-модель компании, поставщики ПО, проприетарное ПО.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи