Что убивает консорциумы: 4 провала и выводы для SplitBuild

Maersk и IBM потратили $250M на блокчейн-платформу для логистики. Проблема: Maersk воспринимался как фактический владелец инициативы. Конкуренты не присоединились — зачем помогать строить платформу, которую контролирует твой главный конкурент?

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

Вывод для SplitBuild: оператор не должен быть участником. SplitBuild представляет интересы всех сторон одинаково — это заложено в модель с первого дня.

Университетские консорциумы Kuali и Sakai показали типовую проблему: слишком много сторон, слишком много пожеланий, слишком слабая дисциплина по ядру и кастомизациям.

Если не разделить общее и индивидуальное, продукт начинает одновременно пытаться угодить всем и в итоге не решает задачу никому. Scope creep — убийца номер один для совместных проектов.

Вывод для SplitBuild: группы ограничены 2–6 участниками. Мы не начинаем проект без 80%+ совпадения требований. Ядро и кастомизации разделены архитектурно, а не только организационно.

Открытые или полузакрытые инициативы часто сталкиваются с участниками, которые хотят получать выгоду, но не брать на себя долю расходов и обязательств. В open-source это терпимо. В коммерческом консорциуме — смертельно.

Поэтому в SplitBuild вход, права и обязательства фиксируются до старта: кто финансирует ядро, кто получает лицензию, как принимаются изменения. Закрытая модель: продукт получают только плательщики.

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

Мы специально проектируем модель вокруг этих ограничений, а не вокруг абстрактной идеи «давайте всем миром строить софт». Каждый из четырёх рисков имеет конкретный механизм защиты.