май    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	31

показать все 

27.04.2024

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

Читать далее 

22.04.2024

Сообщество цифровых управленцев «я-ИТ-ы» проводит ЗАКРЫТУЮ встречу в рамках выставки «Связь-2024»!

Читать далее 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

показать все 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

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

Читать далее 

22.03.2024

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

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Статьи / Опросы / Поможет ли стратегия развитию Open Source в России?

Поможет ли стратегия развитию Open Source в России?

Министерство цифрового развития, связи и массовых коммуникаций РФ (Минцифры России) планирует разработать стратегию развития рынка цифровых продуктов Open Source в стране. Предварительный срок подготовки документа – сентябрь 2021. По заявлению Минцифры стратегия должна создаваться совместно с ИТ-сообществом.

1. Какие основные приоритеты должны быть, на ваш взгляд, в стратегии развития Open Source в нашей стране?
2. Какие меры господдержки необходимы для развития разработки продуктов Open Sourcе?
3. Надо ли стимулировать создание компаний, разрабатывающих опенсорсные продукты? Если да, то как?
4. Правомерно ли вносить продукты на основе Open Source в Реестр отечественного ПО?
5. Как повлияет создание национальной независимой технологической платформы для разработки СПО на позиции российских разработчиков в мировом сообществе Open Source?
6. Где и как готовить массовых разработчиков СПО?

На вопросы «БИТа» отвечают эксперты компаний

Дмитрий Комиссаров, генеральный директор МойОфис

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

1. Необходимо смотреть шире и говорить о стратегии развития всей отрасли разработки, а не фокусироваться только на Open Source. Такая стратегия должна быть построена на тщательном анализе существующей ситуации – необходимо провести инвентаризацию и понять, где у нас вообще есть разработчики, и не важно при этом, опенсорсные они или проприетарные. Цель такого исследования в том, чтобы понять, насколько широко представлены российские продукты в существующих нишах и удовлетворяют ли они потребностям рынка.

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

Не так важно, какой модели лицензирования будут придерживаться разработчики, главное, чтобы они были российские. Но при этом если они опенсорсные, то они должны делать существенную часть и управлять проектом. Хорошим примером таких разработчиков является Postgress Pro – российское ответвление PostgreSQL, контрибьюторы которого обладают существенным влиянием на развитие всего проекта. Другой пример — «Базальт-СПО». За счет своих доработок, портирования на российские платформы и наличия собственного репозитория операционная система «Альт» фактически независима от развития основного ядра Linux.

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

Среди известных проблем – зависимость целого ряда ГИС от иностранных закрытых технологий. Например, в связи с этим в некоторых госорганизациях до сих пор используются компьютеры с Windows XP и Internet Explorer. Принятие и реализация четкого плана по замене этих технологий на отечественные – отличная мера поддержки разработчиков.

3. Надо стимулировать развитие компаний, которые разрабатывают российские продукты. Выбор модели распространения программного обеспечения должен быть предоставлен самим разработчиком. Необходимо стимулировать разработку программных продуктов определенных категорий, например, расширить программы поддержки РФРИТ, проводить целевые конкурсы на базе Сколково и т. д. Это приведет к появлению новых компаний, которые будут создавать новые продукты и (там, где уместно) сделают свои разработки открытыми. Отрасли не просто опенсорсные разработчики нужны – нам вообще разработчики нужны, на российском ИТ-рынке примерно 1 млн человек не хватает.

4. Для включения программного обеспечения в Реестр установлены критерии, которые нейтральны к форме лицензирования и открытости кода. Важно, чтобы разработка программного продукта происходила именно у нас в стране. Поэтому появление СПО-продуктов в Реестре – правомерно. Но нужно внимательно следить, чтобы не возникало злоупотреблений. Российский ИТ-рынок помнит ситуации, когда один человек необоснованно заявлял, что самостоятельно написал 40 млн строк кода. Не так сложно собрать свой дистрибутив известного программного продукта, укомплектовав его только оригинальным названием и не вложив при этом ни одного рубля в разработку его функций и алгоритмов. Таким «продуктам» в Реестре, конечно, не место.

5. Никак. Само по себе создание локальной платформы для разработки СПО не изменит позиции российских разработчиков в мировом сообществе Open Source. Но такая платформа может снять риск потери доступа к репозиториям разработанного кода, – сейчас GitHub, самый популярный хостинг проектов СПО, полностью принадлежит Microsoft и размещается на американских серверах. Необходимо выработать решение – либо GitHub переносит часть своей инфраструктуры в Россию и создает здесь копию основного ресурса, либо нам потребуется сделать в России аналогичный репозиторий СПО. Никаких других путей нет.

Улучшить же позиции российских разработчиков в сообществе СПО платформа может только при соблюдении следующих условий:

• наличие долгосрочного плана функционирования и гарантий бесперебойной доступности платформы не только в пределах календарного года (бюджетного цикла), но и на горизонте 10 и более лет;
• наличие на платформе крупных оригинальных проектов, которые будут востребованы мировым ИТ. Речь идет не о репозитории копий или постоянно обновляемых форков, а именно о публикации оригинальных разработок отечественных программистов;
• доступность платформы для разработчиков всего мира.

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

Вадим Сабашный, генеральный директор «ЛАНИТ-ТЕРКОМ» (входит в группу ЛАНИТ)

«Изобрести “серебряную пулю” пытались не единожды, но обычно это не удавалось. Платформа может помочь в популяризации и повышении удобства сборки комплексных решений, но ее одной будет недостаточно»

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

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

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

5. Прежде всего, необходимо готовить хороших специалистов, знакомых как с Open Source, так и с закрытыми решениями. Дополнить программы обучения в вузах курсами по Open Source, безусловно, необходимо, но такие программы уже есть в ведущих профильных университетах. Поэтому я бы не отделял обучение Open Source от других профильных программ.

Павел Гуральник, генеральный директор ISPsystem

«Самое главное, государство должно участвовать в Оpen Source-движении и открывать те решения, хотя бы частично, которые разрабатываются самим государством»

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

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

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

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

Второй приоритет – это поддерживаемость: должно быть четкое понимание, кто поддерживает решение и на каком уровне оказывается сервис.

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

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

2. На самом деле, меры поддержки, которые государство сейчас вводит для ИТ-компаний и для разработчиков программного обеспечения в частности, будут являться отличным подспорьем для программистов продуктов Open Source. Также разработчики Open Source-решений могут получить существенный толчок в развитии, если государство предоставит какие-то существенные гранты за разработки в области перспективных и приоритетных направлений.

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

3. При необходимом уровне поддержки стимулировать создание компаний не придется. Компании будут появляться благодаря обычным экономическим веяниям: если будет спрос от рынка на создание, развитие, поддержку и на внедрение Open Source-решений, то мы увидим рост количества компаний разработчиков, которые занимаются этими проектами. Поэтому я считаю, что дополнительное стимулирование не потребуется.

4. Надо разделять понятия открытого программного обеспечения и отечественного ПО. Основная цель импортозамещения – это технологическая независимость и суверенитет, т. е. создание собственных независимых решений, которые являются импортными аналогами и совместимы с другими продуктами. Реестр отечественного ПО, в том числе, создавался в рамках реализации стратегии по импортозамещению. И сейчас действительно возникают вопросы у участников рынка, потому что в Реестре отечественного программного обеспечения присутствуют продукты, которые де-факто являются Open Source-решениями с минимальной переработкой. Можно ли их назвать отечественными? Скорее, нет, они являются свободным программным обеспечением, над которыми работает мировая общественность. В этом случае, требуется критерий к степени переработки и доработки этих решений, а Open Source-решения определить в отдельную категорию. Но Open Source-решения безусловно подходят для достижения целей импортозамещения, обеспечения технологической независимости, но они не являются российскими как таковые.

5. Это консолидирует ресурсы, сподвигнет российских разработчиков вносить больший вклад, делает разработку эффективнее. Так мы получим конкурентоспособные и технологичные продукты на мировом уровне.

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

Сергей Кондратенко, к.т.н., технический директор интернет-агентства «Альянс+

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

Логично, что тот, кто больше всего работает с продуктом, вносит основной вклад в его развитие, по факту им и владеет. Основным приоритетом мы считаем важность включения в существующие международные OS-проекты отечественных разработчиков. Больше всего в данной нише пока заметно участие Китая. Кстати, продукт вполне может правомерно считаться отечественным ПО, если, например, вклад российских компаний в его создание больше 50 %.

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

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

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

Григорий Сизоненко, генеральный директор компании ИВК

«Может ли свободное ПО быть российским? Да, может. Ведь российская фирма управляет логикой его развития, владеет инфраструктурой разработки»

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

3. Безусловно, правомерно. Но давайте уточним: мы ведем речь именно о свободном ПО. А не о том ПО, которое создается «на основе Open Source», – такой софт, если позволяют лицензии на использованные в нем свободные компоненты, может быть и проприетарным.

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

5. Такая платформа уже существует в России более 20 лет. Это отечественный технологически независимый репозиторий «Сизиф», один из крупнейших в мире наряду с репозиториями Debian, Red Hat и SUSE. Он включает около 23 тысяч программных пакетов и собственную инфраструктуру распределенной разработки. Изначально он был создан как рабочая среда для разработчиков операционных систем, но сегодня на его основе создаются не только ОС, но и другое ПО. «Сизиф» полностью находится в российской юрисдикции и развивается более 20 лет. Политику его развития определяет международная (в основном, русскоговорящая) команда разработчиков свободного программного обеспечения ALT Linux Team. Благодаря собственным технологиям российские разработчики создают не клоны зарубежных ОС, а самостоятельные операционные системы.

«Сизиф» развивается в тесном взаимодействии с международными проектами разработки свободного ПО. В работе этих проектов активно участвуют и отечественные программисты. Такой подход к делу позволяет объединить усилия международного сообщества разработчиков на основе юридических правил, оговоренных в лицензиях на СПО. И таким образом – сэкономить время и средства на разработку софта. Квалификация российских программистов позволила им получить высокий статус в международных проектах СПО. Их код есть в ядре Linux, в основных системных библиотеках и других ключевых компонентах свободного ПО. Например, в криптографической подсистеме ядра Linux 5.0. присутствует созданная нашими разработчиками хеш-функция Streebog, она стандартизирована в РФ по ГОСТ 34.11-2012.

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

Присоединиться к проектам разработки свободного программного обеспечения совсем не сложно. В среде СПО каноническим стало требование, которое предъявляет Линус Торвальдс к программистам, желающим присоединиться к проекту разработки ядра Linux: «Покажи мне свой код!». По этому принципу, например, отбирает потенциальных кандидатов компания «Базальт СПО», разработчик семейства отечественных операционных систем «Альт» и координатор развития российского независимого репозитория «Сизиф». Аналогичную просьбу слышат и программисты, которые хотят, например, поместить свои разработки в репозиторий и распространять их в составе дистрибутивов операционной системы. Молодым разработчикам, работающим с «Сизифом», открыт доступ практически ко всем хранящимся в нем разработкам, к технологиям и сборочным системам. А, кроме того, они получают возможность заниматься интересным делом в сильном профессиональном окружении.

Сергей Курьянов, директор по стратегическому маркетингу «ДоксВижн»

«Для программиста не так важно, Open Source или нет, в любом случае он свой код сдает заказчику вместе с исключительными правами. Важнее, чтобы менеджмент и руководство четко понимали и умели делать бизнес в СПО»

1. Open Source – это не форма распространения ПО и точно не способ «бесплатной автоматизации». Это, в первую очередь, способ совместной разработки ПО открытыми сообществами. Поэтому во главу угла встает развитие соответствующей культуры разработчиков, интеграторов и заказчиков. Учитывая реальное отставание от ведущих западных стран, нам буквально необходима всеобщая ликвидация неграмотности, «социальная реклама», обучение, нормативная, юридическая и финансовая поддержка со стороны государства. В особенности поддержка российских проектов Open Source, но также и поддержка российских контрибьюторов зарубежных проектов.

2. Продвижение Open Source в госсекторе, налоговые льготы для Оpen Source-разработчиков (больше для владельцев проекта, меньше для контрибьюторов). Юридическая поддержка – нормативные документы, описывающие организацию Open Source-проектов, рекомендуемые лицензии, порядок определения налогооблагаемой базы и налогообложения, поддержка обучения заказчиков, интеграторов и разработчиков бизнес-аспектам Open Source.

3. Ни в коем случае. Стимулировать нужно деятельность по результатам.

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

5. Если имеется в виду собственный GitHub, не думаю, что это важно. Международные проекты охватывают множество стран, в том числе сдерживающих друг друга геополитически. Попытки ввести санкции в платформах навредят всем и немедленно.

6. Для программиста не так важно, Open Source или нет, в любом случае он свой код сдает заказчику вместе с исключительными правами. Важнее, чтобы менеджмент и руководство четко понимали и умели делать бизнес в СПО. Наверное, основы надо давать в базовом образовании, а основной упор делать на дополнительное последипломное образование.

Сергей Кондаков, директор по технологиям разработки программного обеспечения, компания «ФОРС – Центр разработки» (ГК ФОРС)

«Единственный действенный способ привлечения частных компаний к разработке СПО – это прямое финансирование таких Open Source-разработок через соответствующие фонды»

1. Полагаем, что основными приоритетами должны быть следующие:

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

2. Такие меры должны включать:

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

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

Единственный действенный способ привлечения частных компаний к разработке СПО – это прямое финансирование таких Open Source-разработок через соответствующие фонды.

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

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

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

6. Там же и так же, как и остальных разработчиков программного обеспечения. Будущая специализация по СПО не предъявляет каких-то специфических профессиональных требований, правила работы в сообществе могут быть изложены в течение пары лекций, а их знание закреплено на нескольких семинарах. Культура поведения в сообществе разработчиков обусловлена, скорее, не профессиональным образованием, а общим культурным уровнем конкретного человека.

Алексей Парфентьев, руководитель отдела аналитики «СёрчИнформ»

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

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

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

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

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

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

Резюмирую: хорошо стимулировать свободное распространение продуктов. Но стимулировать разработку ПО на Open Source или его покупку, на наш взгляд, неверно и чревато злоупотреблениями.

4. Эта дискуссия начата уже давно, и у государства есть ответ в виде минимальных требований процента переработки кода для OpenSource-решений. Если они выполняются – вносить продукты в Реестр правомерно. Другое дело, что этот минимальный процент нужно повышать. Процесс импортозамещения идет давно, и логично, что требования будут ужесточаться, а не упрощаться. Для старта они были адекватными, но сейчас рынок уже достиг достаточного уровня зрелости.

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

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

Евгений Осьминин, коммерческий директор РДТЕХ

«Время противостояния открытых и проприетарных решений постепенно уходит в прошлое. На его смену должны прийти новые формы их сосуществования»

1. В настоящий момент тема Open Source в нашей стране получила новый виток развития, связанный с санкционным режимом и политикой импортозамещения. В переходе на ПО с открытым кодом крупные компании увидели средство снижения рисков для критически важных систем и процессов, а также возможность оптимизации затрат.

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

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

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

Стратегия развития решений Open Sourcе России, на мой взгляд, должна способствовать:

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

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

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

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

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

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

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

4. Безусловно. Но для этого надо подготовить соответствующую нормативно-правовую базу. В частности, разработать дополнительные критерии, требования к продуктам Open Source, учитывающие их особенности. Например, они могут касаться отдельных инвариантных частей продукта, эволюции версий/этапов жизненного цикла и т. д.

Если говорить о нашей компании, то ряд решений РДТЕХ имеет аналоги на СПО. Два из них – «Электронный архив документов на базе ABBYY FlexiCapture и Alfresco Community» и «Система управления нормативно-справочной информацией» – уже включены в Единый реестр отечественного программного обеспечения. Кроме того, РДТЕХ реализовал ряд проектов, связанных с разработкой на СПО, в банковской и страховых сферах. Большая часть этих проектов связана с разработкой на базе ядра Linux, внедрением СУБД PostgreSQL, разработкой систем управления документами на платформе Alfresco. Расширение присутствия нашего ПО в реестре, конечно, способствовало бы его дальнейшему развитию.

5. Однозначно, создание национальной технологической платформы будет способствовать усилению позиций отечественных разработчиков. Платформа позволит интегрировать отдельные небольшие сообщества разработчиков, создаст благоприятную почву для появления новых, систематизирует существующие решения СПО, что в конечном счете обогатит репозиторий решений. А в Open Source, как известно, диалектический принцип перехода количества в качество является одним из основополагающих.

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

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

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

Еще один важный, на мой взгляд, элемент в подготовке разработчиков Open Source – попытаться создать (конечно, с поправкой на современные реалии) атмосферу романтики, вовлеченности, причастности, которая сопровождала первые подобные сообщества.

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

Сергей Игнатов, директор по развитию продуктовых направлений компании Syssoft

«Стимулирование СПО со стороны государство может быть только в льготах для разработчиков и помощи в раскрутке и донесении своих продуктов до заказчиков»

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

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

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

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

Максим Карчевский, ведущий консультант по информационной безопасности R-Vision

«Меры господдержки должны фокусироваться на развитии конкурентной среды в ИТ-отрасли»

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

2. Меры господдержки должны фокусироваться на развитии конкурентной среды в ИТ-отрасли. Если еще несколько лет назад Open Source-решения зарубежных разработчиков превосходили отечественные аналоги по всем параметрам, то сегодня картина меняется. Благодаря новым требованиям доверия ФСТЭК России промышленность всё чаще выбирает дистрибутивы отечественных разработчиков: РедОС, ALT Linux, Astra Linux и т. д. Качество и надежность программных продуктов растет: исполняемый код Open Sourсe-решений в ходе сертификации проходит проверку динамическими и статическими анализаторами, а испытательные лаборатории всё чаще переходят от формального подхода к практическому.

3. На мой взгляд, необходимости в этом нет. Предыдущие неудачи в создании национальных программных платформ на базе ПО с открытым кодом показали, что стимулирование государством таких продуктов не приводит к хорошему результату. Рынок должен самостоятельно решать, какие продукты достойны развития, а какие – нет. В нашей стране есть несколько успешных Open Source-проектов, существующих на энтузиазме сообщества или крупных компаний, так как в них есть потребность. Примерами являются СУБД PostgresPro, операционная система «РедОС», СУБД ClickHouse и другие популярные решения.

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

Алексей Ковязин, IBSurgeon/IBase, Директор по технологиям, Москва

«В стратегии развития Open Source надо уделить основное внимание возможности использования мирового открытого ПО в госструктурах»

1. Основных направлений должно быть два:

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

По оценке Evans Data Corporation («Global Developer Population and Demographic Study 2018 Vol. 2»), в России в 2018 году было 1.3 млн профессиональных разработчиков, в мире – 23 млн, т. е. примерно 5 % от общей численности. Примерно также можно оценить и объем открытого кода, создаваемый российскими программистами ~5 % от общемировой кодовой базы. 95 % открытого программного обеспечения является «не отечественным».

Открытое ПО как математика – у теорем есть авторство, но нет гражданства. Именно поэтому в стратегии развития Open Source надо уделить основное внимание возможности использования мирового открытого ПО в госструктурах. Открытое ПО включает не только разные виды Linux и LibreOffice, которые постоянно на слуху, но и множество узкоспециального ПО и библиотек высокого качества, например, TensorFlow (Machine Learning, лицензия Apache 2.0), Tesseract OCR (распознавание текста, лицензия Apache 2.0), SQLLite (СУБД, public domain) и множество других продуктов под лицензиями GPL, MIT, Public Domain и унаследованных от них.

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

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

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

В большинстве случаев, для небольшого по объему программного обеспечения, это не имеет экономического смысла, но для крупного ПО компании дорабатывают и расширяют открытое ПО и лицензируют эти расширенные версии на коммерческой основе. Наиболее оптимальным способом разрешения этой проблемы является исключение необходимости регистрации в Реестре отечественного ПО программного обеспечения с открытым кодом под лицензиями GPLv2, GPLv3, MIT, IPL, IDP, Apache Public License, Eclipse Public License, Public Domain (возможно, еще несколько вариантов, унаследованных от перечисленных).

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

2. А) Исключить необходимость регистрации в Реестре отечественного ПО программного обеспечения с открытым кодом под лицензиями GPLv2, GPLv3, MIT, IPL, IDPL, Apache Public License, Eclipse Public License, Public Domain (возможно еще несколько вариантов, унаследованных от перечисленных). Б) выделять гранты на разработку полезного для всех пользователей ПО с открытыми лицензиями.

3. Выделять целевые гранты на разработку полезного для всех пользователей ПО с открытыми лицензиями.

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

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

6. Нигде. Если программист способен написать библиотеку или ПО, которая повторно используется другими программистами, то он ее напишет, а приобретет ли она популярность или развитие – решат ее пользователи в процессе разработки. Государству вмешиваться в этот процесс незачем.

Константин Пылин, коммерческий директор компании IT_One

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

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

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

2. Государство может многое сделать для стимулирования развития открытого программного обеспечения:

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

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

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

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

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

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

Максим Жук, старший инженер-разработчик в компании Reksoft

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

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

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

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

Михаил Филиппенко, генеральный директор ООО «Фаст Репортс»

«От государства, как обычно, требуется, чтобы оно не мешало развиваться. Меньше “регуляторики”»

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

К примеру, есть компании, которые получают прибыль от внедрения и поддержки таких проектов, консалтинга, доработки. Другие используют такие проекты как собственное конкурентное преимущество на глобальном рынке. Третьи – на обучении. Гранты, пожертвования, реклама. Каждый приходит за чем-то своим в Open Source. И ведь это я еще не коснулся разницы в лицензионных моделях (!). Т. е., в любом случае, Open Source это всё равно про бизнес. Фактически – это обмен некой приватной, не публичной информации (исходные коды) на безопасность и популярность. Тем не менее это еще и инфраструктура (сегодня самые популярные и известные «рассадники» открытого кода – это github и sourceforge) и, самое главное-то, комьюнити. Об этом мало говорят – но очень немногие открытые проекты «взлетают». Есть такая молодежная «легенда», что «я сейчас что-то такое эдакое как всем выдам, мир осчастливлю, – и взлетит мой Open Source». Забывая, что за большинством успешных проектов стоят крупные корпорации, осуществляющие постоянное их финансирование.

От государства, как обычно, требуется, чтобы оно не мешало развиваться. Меньше «регуляторики». Компании, знающие, как монетизировать Open Source, – найдутся. А вот плохая практика получится, если компании с Open Source-проектами будут появляться исключительно для освоения бюджетов.

Мы уже несколько лет как выпустили свой Open Source (FastReport Open Source) – это целиком наш продукт, ядро которого используется в коммерческом (тоже нашем), который мы зарегистрировали в Реестре отечественного ПО. И вот мы меньше всего думали в тот момент о создании национальной независимой технологической платформы. У нас были достаточно утилитарные цели на мировом рынке. И, собственно, эти амбиции и помогают развитию. На то он и открытый, что не ограничивается территориально. А программисты – программисты бывают разные по всему миру. Учиться надо, корректному стилю, паттернам. Но главное, чтобы администратор проекта был грамотным и не пропускал, скажем так, неочевидные коммиты.

Алексей Смирнов, председатель совета директоров «Базальт СПО»

«Следует в обязательном порядке публиковать под свободными лицензиями всё ПО, разработанное на бюджетные деньги, если только на него не наложен гриф секретности»

1. Следует прежде всего развивать разработку СПО в стране и усиливать участие отечественных разработчиков в международных проектах СПО. Увеличение роли отечественных разработчиков в СПО-проектах предусмотрено, кстати, как одно из мероприятий «второго пакета мер поддержки ИТ-отрасли».

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

Следует поддерживать стипендиями разработчиков (не фирмы) за уже состоявшееся успешное участие в международных проектах разработки СПО. Прежде всего – молодежь. В том числе и зарубежных разработчиков.

3. Лицензирование – это выбор способа монетизации, выбор бизнес-модели. Не нужно искусственно стимулировать создание таких фирм, разработка СПО и так является достаточно конкурентоспособной.

4. Все преференции отечественным разработчикам ПО должны быть привязаны к Единому реестру отечественного ПО, в рамках единого механизма. Вносить в Реестр продукты, являющиеся производными произведениями от СПО или составными произведениями, в состав которых входит СПО, можно и нужно, но только в тех случаях, когда заявитель серьезно участвует в разработке этих продуктов. Критериями могут быть наличие патчей, принятых (именно принятых, а не просто отправленных) в соответствующий международный проект, а также наличие у заявителя инфраструктуры разработки и поддержки, например, в соответствии с ГОСТ Р 54593-2011 «Информационные технологии. Свободное программное обеспечение. Общие положения».

5. Для усиления роли отечественных разработчиков в мировом сообществе СПО надо вести разработку в ключевых международных проектах. Появление «национальной платформы» тут вряд ли поможет. Но для выпуска разработанного по госзаказу ПО под свободными лицензиями такая платформа может быть полезной. Например, в США есть code.gov.

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

6. Надо готовить разработчиков – не массовых, а квалифицированных. Разработчику СПО должно быть не стыдно показать исходный код своей программы коллегам. В учебные программы следует внести изучение лицензий, в том числе – свободных. Обучение ИТ-специалистов в вузах следует вести, прежде всего, на базе свободного ПО, чтобы студенты могли изучать и модифицировать исходный код, а не только правила использования готового чужого продукта. Не важно, разработкой какого ПО они потом будут заниматься – свободного или проприетарного.

Павел Мельник, заместитель директора по работе с корпоративными клиентами АЛП-ИС

«В нашей практике сочетание российского проприетарного ПО и собственных технологий, в том числе созданных с применением OS, давно является абсолютно естественной формой работы»

1. Я бы начал не с приоритетов, а с фундамента, а это эффективность разработок. В этой связи решения, созданные на базе OS, безусловно, имеют право на существование. И речь не о том, что «круче» – наше, зарубежное или Open Source, – а о том, как безопасно, правильно и продуктивно использовать те или иные продукты для автоматизации бизнес-процессов, являющихся основой работы предприятия.

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

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

4. Скорее, это вопрос к юристам. Как разработчик, я считаю, что любое высокоэффективное решение, созданное отечественными командами на базе российского или свободного ПО, может быть внесено в Реестр. Для нас важно, чтобы этот процесс был максимально отлажен, поскольку непродуманное включение в этот перечень ПО Open Source «as is» может не только девальвировать саму идею, но и навредить бизнесу.

5. Я считаю, что это тот самый случай, где эта работа уже давно идет полным ходом: с одной стороны, мощнейшим драйвером подготовки специалистов является широкая коммуникационная среда, объединившая квалифицированных разработчиков во всем мире (а это – регулярное общение, возможность тестировать и многое другое).

Ключевые слова: Реестр, свободное ПО, стратегия, разработка, ИТ-специалисты, кадры, Open Source, ИТ-решение, команда, господдержка

В начало⇑

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

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