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

Тема рисков, связанных с возможностью так называемого форкинга (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) – того, какое ПО и как именно используют эти лидеры.

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

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

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

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