Польза open source для ГосИТ и вред для коммерции

Тема open source очень хайповая, неоднозначная и даже конфликтная, дискуссии на эту тему нередко перерастают в словесные баталии. Я не хотел касаться таких острых тем, мой блог больше про личный опыт. Но некоторые события недавних дней всё-таки подстегнули меня поделиться своим мнением и на эту тему. А поделиться я решил своими соображениями на тему - «Почему open source может быть крайне полезен для государства и крайне вреден для коммерческих компаний?»

На предыдущем месте работы я работал на государство. Компания, в которой я работал, являлась единственным поставщиком одного министерства и отвечала за развитие ГИС (государственная информационная система). За два года своей работы я наблюдал, как выполнялся топорный разворот в теме с open source на 180 градусов.

От open source — это благо для государства, которое позволяет развивать цифровизацию и экономить государственный бюджет. До полного запрета open source как представляющего угрозу национальной безопасности.

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

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

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

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

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

Требования об использовании только российского ПО или ПО дружественных стран (что на мой взгляд даже юридически звучит диковато, какие друзья в отношении государств?) свело всё к двум основным пунктам:

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

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

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

По моему личному мнению, основное отличие коробки от open source лежит в следующем: коробка требует от вас денег, open source — команды.

Многие ошибочно конвертируют команду в деньги, считая, что если у вас есть деньги на коробку (которая кажется по умолчанию дорогой), то у вас есть деньги и на команду, которая сделает нужный вам продукт, да ещё и дешевле.

Любой ресурс ограничен, в том числе и рынок специалистов по той или иной технологии, при том рынок может меняться от географии. Например, в Европейских странах очень много решений, которые продолжают эксплуатировать старые технологии. Я лично знаю одного специалиста, который 30 лет назад был в составе разработчиков системы, написанной на Каболе. Примерно раз в 1-2 года его приглашают доработать код решения и платят за это очень хорошие деньги. В то время как в нашей стране растет количество питонистов, гошников, при том, что подавляющее большинство программистов — джависты.

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

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

Государственные механизмы с их бюджетной политикой, тендерами, дефицитом времени и waterfall подходом к проектированию заточены под коробки. В условиях, когда бюджет и ТЗ согласовываются в от 25% до 75% времени от всего срока проекта, остаётся только купить коробку и попытаться уложить в неё свои требования.

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

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

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

Таким примером служит «1С Бухгалтерия». Этот продукт узкоспециализирован и адаптирован под российский рынок. Вряд ли вам стоит тратить силы и писать такой продукт с нуля, опираясь на какой-нибудь open source продукт, разработанный в США.

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

В первом случае нам пришлось разбираться c продуктом самим, и некоторые куски системы работали крайне странно. Так, например, для создания аккаунта клиента требовался некий уникальный ID, который предполагалось вносить при создании аккаунта, а не генерировать средствами системы. Мы обошли это поведение, сделав специальную заглушку, так и не поняв назначение этого ID.

Во втором случае внедрение происходило вместе с вендором, и я решил поинтересоваться у вендора назначением этой таблички. Оказалось, что этот уникальный ID был необходим для интеграции с другой системой налоговой службы США. Крупнейшим клиентом вендора была американская AT&T, и они не придумали ничего лучше, чем встроить эту особенность в исходный код. Разумеется, для нас был сделан хот фикс, и этот ID был исключен из сборки.

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

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

Для государственного управления, требующего постоянной адаптации решений под конкретные нужды, open source подходит лучше, при определённых условиях:

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

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

Общий репозиторий открытого кода государственных open source решений мог бы существенно ускорить развитие цифровизации государства, и при этом снизить затраты.

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

Государство же могло бы в свою очередь воспользоваться этим потенциалом и привлекать молодых специалистов к разработке на базе open source. Государство бы получало ресурс, а студенты – первый опыт. Понятно, что большинство покинет такие центры разработки после окончания ВУЗа, но такое происходит и коммерческими учебными центрами. Однако, какая-то часть людей останется и станет костяком ИТ-команды.

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

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

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

Как итог, приведу несколько ключевых принципов выбора open source: