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

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

Проблема подробно рассматривается в статье Пола Рубенса, опубликованной на сайте CIO.com.

Перед тем, как начать искать ответы на эти вопросы, ИТ-директору следует убедиться, что он правильно трактует само понятие форка. Исследователи Грегорио Роблес и Хесус М. Гонсалес-Барахона из испанского Университета имени короля Хуана Карлоса определяют форк следующим образом.

Форк возникает, когда часть сообщества разработчиков (или некая третья сторона, не имеющая никакого отношения к проекту) продолжает развитие продукта на основе уже созданного в рамках проекта исходного кода. Форк должен отвечать следующими условиям:

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

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

Тем не менее, есть некоторая вероятность, что такое произойдёт с проектом, от которого зависит ИТ-инфраструктура компании. Поэтому вопрос имеет не только теоретическое значение.

Президент Open Source Initiative Эллисон Рэндал уверен, что форк — это очень здорово, поскольку именно он зачастую способен спасти умирающий проект. Пример успешного форка — LibreOffice, фактически заменивший OpenOffice.org, страдающий от многочисленных проблем.

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

Тем не менее, чаще всего хотя бы один из проектов продолжает успешно развиваться. И главное для корпоративного пользователя — выбрать именно его.

Эллисон Рэндал считает, что главный критерий в данном случае — количество разработчиков. Второе, на то следует обратить внимание — критическая масса пользователей. И при этом совершенно не важно, за каким именно проектом стоят компании. Если форк окажется успешным, то всегда найдётся бизнес, обеспечивающий его поддержку.

Разумеется, это простейший случай, в котором есть очевидное решение. Значительно сложнее ситуация, когда ни одна из сторон не может набрать явное большинство разработчиков и критическую массу пользователей. Рэндал считает, что тут у пользователя есть только два варианта: либо ждать, либо искать аналогичное приложение.

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

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

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

Ещё одна потенциальная проблема для ИТ-директора заключается в сложности прогноза успешности форка на основании нетехнических факторов и возможного влияния нетехнических причин. На это обращает внимание один из ключевых участников проекта LibreOffice Майкл Микс.

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

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

Может быть, ИТ-директорам проще опираться на статистику? Согласно исследованию Роблеса и Гонсалес-Барахона, по состоянию на август 2016 г. она выглядит следующим образом:

  • форки появились у 220 проектов;
  • в менее 9% случаев были прекращены и оригинальный проект, и его форк;
  • если форк появляется из-за угрозы прекращения первичного проекта, то в 10% случаев бывает прекращён первичный проект, а в 14% — его форк.

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