Иван Панченко: Глобальные свободные проекты могут вытеснить проекты корпораций и быть эффективными

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

CNews: Какие проблемы вы видите на рынке импортозамещения системного ПО?

Иван Панченко: Начнем с того, что перед российскими разработчиками стоят вызовы, с которыми ранее не справилась ни одна страна мира. Импортозамещение системного ПО — чрезвычайно сложная и трудоемкая задача, сопряженная с рядом проблем.

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

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

CNews: В чем преимущества и недостатки Open Source продуктов?

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

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

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

CNews: Как отличить хороший форк от плохого?

Иван Панченко: Критерии очень простые: хороший форк — это по сути самостоятельный продукт, сделанный по технологической причине и обладающий набором объективных характеристик, которые легко проверить: разработка уникальной функциональности (включая разработку ядра), регулярные обновления продукта до последних версий, открытая исчерпывающая документация, признанные эксперты в команде продукта, постоянный обмен кодом с Open Sourсе сообществом, соблюдение лицензий и другие факторы, свидетельствующие, что перед вами не просто красивая обертка, но и уникальная начинка.