СПО сегодня развивается очень широким фронтом
Один из ярко выраженных трендов на ИТ-рынке — миграция на свободное программное обеспечение (СПО) и перенос отечественными вендорами программных приложений на платформу Linux. Первые проекты показали, что без трудностей не обойтись. О том, как избежать основных ошибок при портировании проприетарного ПО на платформу Linux, корреспонденту MSKIT рассказал Алексей Смирнов, генеральный директор компании «Базальт СПО» (компания-разработчик семейства операционных систем АЛЬТ).
Алексей Владимирович, миграция на СПО — это общемировая тенденция? С чем она связана?
Давайте уточним: речь идет не о миграции на свободное программное обеспечение, а о его развитии. Тема миграции на СПО в последнее время рассматривается в основном в русле импортозамещения, но переход осуществляется как на софт под свободными лицензиями, так и на несвободные программы. Доля последних в софтверном сегменте ИТ-инфраструктур сейчас преобладает.
Развитие свободного ПО — это действительно общемировая и очень динамичная тенденция. Показательно, что ведущие мировые фирмы — такие как Google, Facebook, Яндекс, Microsoft, IBM — широко используют решения на базе свободных лицензий. Microsoft, например, является одним из крупных контрибьюторов ядра Linux: у фирмы есть специальное подразделение в Редмонде, которое занимается свободными программами. На базе свободного софта работает Интернет — весь стек TCP/IP, веб-сервер Apach, большинство веб-браузеров.
Интерес организаций и предприятий к ПО под свободными лицензиями связан со стремлением обеспечить полноценный жизненный цикл используемых программных продуктов. Для этого потребителям нужны исходные коды программ, достаточный объем прав на их модификацию и возможность распоряжаться производным продуктом по своему усмотрению. И, что крайне важно, нужна инфраструктура и технологии разработки софта. Все эти возможности обеспечивает СПО.
Еще одна причина возрастающей популярности свободного софта — его экономичность. Использование свободных компонентов позволяет распределить весьма высокие затраты на разработку сложных систем между большим числом разработчиков и фирм, что снижает издержки каждой из них.
СПО хорошо вписывается в программу обеспечения технологической независимости. Отечественный софт действительно выгодно и целесообразно создавать на базе свободных проектов. Но взять свободный проект и слегка «перекрасить» его, внеся некоторые доработки — не значит создать собственный программный продукт на базе свободных компонентов. Важно, чтобы у разработчика были реальные компетенции, технологии и инфраструктура разработки. Эти условия очень хорошо описаны в ГОСТ Р 54593-2011 «Информационные технологии. Свободное программное обеспечение».
В России, наверное, как обычно, свое отношение к СПО? Или причины миграции такие же, как во всем мире?
Причины, в принципе, такие же, как во всем мире: это рациональное отношение к издержкам на разработку и понимание того, что ее открытость зачастую выгодна разработчику. Несомненно, выгода есть и для пользователей, которые в этом случае не становятся заложниками вендорской тактики скрытых и явных запретов vendorlock-in.
Справедливости ради надо отметить, что распространение СПО в России идет не без трудностей и ошибок. Всем нам памятен недавний не очень удачный госпроект перехода на свободное программное обеспечение. Принятые тогда постановления практически не были выполнены. Но актуальность развития свободного софта в стране осталась. Она вновь осознана на государственном уровне, уже в ключе технологической независимости.
Каковы основные заблуждения разработчиков, начинающих проекты портирования своих приложений на платформу Linux
Здесь мы от вопроса развития СПО переходим к вопросу миграции на отечественные программные продукты, в том числе на свободный софт. Возьмем для примера системное программное обеспечение — операционную систему, СУБД, другие системообразующие компоненты. Практически все они созданы на основе свободного софта: большинство отечественных ОС относятся к семейству Linux, отечественная СУБД PostgresPro разработана в рамках проекта свободной СУБД PostgreSQL, и т.п.
Поскольку организации начинают активно использовать это системное ПО, возникает вопрос совместимости с ним различных прикладных систем. Например, портированием на отечественную операционную систему сейчас активно занимаются компании, которые держат основную долю российского рынка СЭД: ЭОС — Электронные офисные системы, Интертраст, DocsVision, ИВК (система «Бюрократ» с повышенным уровнем защиты данных). Аналогичную работу уже проделали 1С, «Корпорация Парус», «Корпорация Галактика» и другие фирмы, чьи бренды хорошо известны российским пользователям.
Портирование — сам по себе достаточно сложный процесс, и дополнительные трудности привносит отсутствие у разработчиков нужных компетенций. Большинство российского прикладного ПО создавалось для работы на платформе Windows+Intel, поэтому у программистов нередко не хватает знаний и опыта работы с другими платформами. Например, мне встречались люди, которые уверены: если они обеспечат совместимость своего программного продукта с ОС, умеющей работать на неинтеловских архитектурах (например, на «Эльбрусе»), то и их приложение тоже автоматически начнет работать на компьютерах этих архитектур. Удивительно, как профессионалы не понимают, что такой механический перенос невозможен: после компиляции при создании бинарного кода система команд процессора используется разная.
Можно долго перечислять подобные ошибки, но надо ли? На мой взгляд, важнее ответить на вопрос: «Что делать»? Ничего ужасного в сложившейся ситуации нет, все разрешимо.
Мы в «Базальт СПО» сформировали и реализуем комплексную программу технологической поддержки разработчиков, в рамках которой проводим тестирование прикладных систем на совместимость с ОС АЛЬТ, консультируем разработчиков, обучаем и снабжаем необходимыми материалами. В этой программе также участвует наш стратегический партнер, компания ALP Group, которая помогает разработчикам организовать качественную техническую поддержку по схеме «одного окна» их программного продукта, портированного в Linux, а также ОС АЛЬТ, СУБД PostgresPro и ряда других видов инфраструктурного СПО, провести сайзинг оборудования для этого программного продукта, выявлять и ликвидировать причины снижения производительности. Уже есть первый опыт помощи в портировании: при содействии ALP Group создана специализированная версия для платформы «Эльбрус» одного из популярных российских приложений для совместной работы.
И все же — несколько советов: каких главных ошибок можно избежать? И как это сделать?
Если программа написана достаточно аккуратно, с разумным выбором библиотек при разработке, есть исходные тексты, то перенос под другую операционную систему не вызывает чрезмерных сложностей. Мы видим такие примеры, сотрудничая с разработчиками прикладного софта. Но видим, к сожалению, и другие.
Ряд характерных ошибок связан с организацией разработки. Например, разработчик придерживается не стандартов, а фирменных спецификаций, и очень жестко привязывает программу к каким-то очень узким библиотекам и средствам разработки. Так, работа портала «Госзакупки» базируется на активном использовании технологии MicrosoftActiveX. Эта технология уже не поддерживается разработчиком, но заменить решение — очень хлопотно и затратно. В результате, пользователи портала не имеют возможности перейти на отечественные программные продукты. А причина, как я уже говорил, в том, что вместо стандартов используются фирменные спецификации.
Другая категория ошибок произрастает из желания разработчиков создать себе «тепличные» условия: не использовать разделяемые системные библиотеки, а «принести их с собой». Это достигается разными способами — путем статической нединамической линковки, путем создания контейнера. Да, при этом программный продукт перестает зависеть от изменений системных библиотек в операционной системе. Но это иллюзорная стабильность. Дальше события развиваются, как правило, по следующему сценарию: в библиотеке обнаруживается уязвимость, библиотека обновляется на уровне ОС, но прикладная система использует не новую безопасную версию, а свой экземпляр с уязвимостью. В большинстве случаев прикладной разработчик не берет на себя труда поддерживать встроенные в свой продукт библиотеки в актуальном состоянии. Понятно, что использовать разделяемые библиотеки более хлопотно. Но в плане долгосрочной поддержки программного продукта, обеспечения его полного жизненного цикла — обладает массой преимуществ.
При переносе прикладного ПО на другую операционную систему, надо архитектурно грамотно в нее вписываться. Механический перенос Windows-версии невозможен, Linux существенно отличается от Windows по архитектуре, организации файловой системы и многим другим параметрам. Если разработчик по незнанию или нежеланию не учитывает эти особенности — он создает версию, которая будет неконкурентоспособной, и заведомо сдает позиции в тендерах для корпоративных программ импортозамещения.
Нам нужно повышать культуру программирования. С ее недостатком связана еще масса банальных вещей, даже не относящихся к портированию на Linux. Например, программа по ходу работы выдает сообщения. Если они вбиты в текст программы, то в случае ее локализации на другой язык, придется вносить изменения непосредственно в текст. А если понадобится выдавать сообщения на разных языках... Совсем сложно. Но между тем, есть стандартные библиотеки, которые берут организацию ввода-вывода сообщений на разных языках на себя и позволяют хранить отдельно текстовые данные, которые выводятся в виде сообщений. Заменять язык можно без пересборки программы, просто путем подготовки подстрочника. И еще масса такого рода нюансов.
Совсем недавно компания «Базальт СПО» провела 15-ю конференцию разработчиков свободных программ. Чем (какими идеями/задачами) живет сейчас сообщество разработчиков СПО?
Подчеркну, что это не маркетинговая конференция. Мероприятие собирает людей, участвующих в проектах (в том числе крупных международных) разработки свободного ПО. Обязательное условие участия в роли докладчика — ссылка на проект, подтверждение, что созданное ПО действительно распространяется под свободными лицензиями.
Конференция — это своего рода «хаб», к которому «подключаются» люди из ключевых международных проектов СПО. Возникает взаимообмен знаниями, размышлениями, опытом, контактами, который продолжается и за пределами мероприятия. Это дает участникам разных проектов единое понимание по целому ряду вопросов, что особенно ценно, если их разработки должны согласованно работать в составе сложных систем.
Проекты разработки свободных программ — это один из мощнейших каналов трансфера технологий. Активное участие в них чрезвычайно важно и для уровня разработки, и для обеспечения технологической независимости, о которой мы говорили.
На прошедшей конференции активно обсуждались вопросы, связанные с поддержкой различных аппаратных архитектур, в том числе отечественных, обеспечение защиты данных, юридические вопросы, связанные с особенностями свободных лицензий.
Какие еще интересные события и тенденции нас ожидают на рынке СПО?
СПО сейчас развивается очень широким фронтом, поэтому сложно отдать предпочтение нескольким тенденциям: практически во всех областях индустрии ИТ свободное ПО находится в первых рядах. Столь высокую динамику развития СПО дает привлечение ресурсов коллективной работы.
Из магистральных тенденций можно отметить поддержку различных аппаратных архитектур и обеспечение работы сложных автоматизированных систем — комплексных, многослойных, территориально распределенных. Традиционно много внимания уделяется вопросам информационной безопасности и развитию инструментов разработки и поддержания жизненного цикла ПО. Но, повторю, все современные тренды развития индустрии ИТ ярко проявляются и в свободном ПО.
