Вестник цифровой трансформации

Крутые повороты открытого ПО
Крутые повороты открытого ПО




12:52 19.03.2017  |  Николай Смирнов | 5435 просмотров



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

Тема рисков, связанных с возможностью так называемого форкинга (forking) – возникновения ответвлений в открытых программных продуктах (см. «Так ли уж страшно ответвление в ПО с открытым кодом», «Директор информационной службы», №10, 2016), нашла довольно большой отклик в российском сообществе Open Source, причем многие эксперты уверены: ответвление вовсе не зло, да и рисков в нем отнюдь не больше, чем в проприетарных системах.

Ответвление – не трагедия

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

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

«Информацию о возможном ветвлении открытых продуктов нужно иметь в виду, когда принимается решение об их использовании в своих будущих проектах. Ситуация может измениться как в благоприятную, так и в неблагоприятную сторону – например, команда ответвления начнет работать более эффективно», – отмечает Дмитрий Метлин, ИТ-директор Mango Telecom, ориентирующейся на открытые продукты. Если платформа была выбрана изначально правильно (наиболее стабильная версия, широкое сообщество и т. п.), то бояться точно не стоит.

Павел Рыцев, ИТ-директор ALP Group: «Разумнее всего относиться к ветвлению не как к трагедии, а как к отличной возможности выбрать наиболее здоровую ветвь продукта, которая поможет компании развиваться максимально динамично»

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

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

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

«Это отличает работу с Open Source от привычной практики применения проприетарных разработок. Устаревшие практики надо менять, а не пытаться под них подстроиться», – подчеркивает Рыцев.

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

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

Семь раз отмерь

Неопределенность дальнейшей судьбы проекта, на который сделала ставку компания, – это в любом случае повод нервничать. Как ИТ-директору следует воспринимать эту ситуацию?

Дмитрий Метлин, ИТ-директор Mango Telecom: «Если есть моменты, которые заставляют нервничать, значит, ставка на данную платформу была изначально плохо продумана»

«Если есть моменты, которые заставляют нервничать, то это значит, что ставка на данную платформу была изначально плохо продумана. Нужно делать выводы на будущее, обращать внимание на проверенные, стабильные проекты с широким сообществом. Впрочем, вышесказанное в равной степени относится и к выбору проприетарного решения», – считает Метлин. Он рекомендует консервативный подход: не использовать самые последние версии систем на важных участках инфраструктуры или процессов, использовать продукты с понятным вектором развития и политикой изменений. Хорошо, если нововведения в платформе с каждой новой версией направлены на цели бизнеса (доступность сервиса, производительность, простота использования).

«Если с ситуацией, вызвавшей проблемы, ИТ-директор столкнулся “внезапно”, следует пересмотреть критерии выбора открытого ПО. К подобному развитию событий нужно быть готовым еще на этапе выбора открытого проекта и определить возможности “отступления”», – рекомендует Вислоцкий.

Как отмечает Романченко, ответвления обычно возникают как реакция на нетехнические разногласия. Например, после того как компания Oracle купила Sun Microsystems, несколько открытых проектов отделились под новыми названиями: MariaDB, LibreOffice, Jenkins. В этом случае «форк», то есть новый проект, сохраняет свою открытость и у пользователей появляется возможность выбора: сообщество или корпорация.

Есть и примеры, когда новый проект развивался гораздо быстрее, чем его предшественник (например, LibreOffice), и случаи, когда оба проекта развиваются одинаково успешно (например, MySQL и MariaDB). Так или иначе, с выбором всегда можно подождать, поскольку обычно оба проекта сохраняют совместимость друг с другом достаточно долгое время. Главное – определить для себя, что важнее: технические детали (развивается ли проект в нужном направлении), поддержка сообщества или корпорации, тонкости лицензирования и т. д.

Ответвления – крутые повороты открытого по

 

Правильная сторона

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

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

«Конечно, не следует ставить знак равенства между ИТ-инфраструктурами этих гигантов и “обычных” компаний, даже весьма крупных. Но важно оценивать заинтересованность солидных организаций в выбранной платформе, такой тест повысит безопасность работы с ней», – рекомендует Рыцев.

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

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

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

Причины – разные, результат – один

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

 

– Алексей Кирпичников, руководитель отдела DevOps компании «СКБ Контур»

 

Поддержка проекта снижает риски закрытия

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

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

– Роман Симаков, директор департамента развития системных продуктов компании «Ред Софт»

 

Раскол происходит не мгновенно

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

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

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

– Иван Панченко, заместитель генерального директора Postgres Professional

 

Конкуренция – это хорошо

Я бы не сказал, что появление ответвления обязательно означает, что будущее проекта «висит на волоске». Например, возьмем ветки MySQL: MariaDB существует уже семь лет, а Percona Server – еще дольше. Но и MySQL все это время тоже существует и развивается. Разработка ведется во всех трех ветках, новые функции из каждой ветки портируются или переписываются для других.

Наличие веток – это не только увеличение неопределенности, есть и явный позитивный эффект: ветки конкурируют между собой, и это заставляет их разработчиков внимательнее прислушиваться к пожеланиям пользователей, работать над новым интересным функционалом. Самое главное для пользователя – смотреть, кто и с какой целью создает ветку. MariaDB и Percona ориентировались на создание полезного продукта, на пользователей и потому выжили. А Drizzle, по причине внутренних разногласий, – нет.

– Сергей Петруня, разработчик MariaDB

 

Теги: Open Source Цифровая трансформация

На ту же тему: