Фонд LiMo Foundation выпустил интересный официальный документ "Mobile Open Source Economic Analysis" (PDF), с результатами исследования экономической стоимости работы с сообществом разработчиков. В документе описываются возможные модели уравновешивания между стабильностью, необходимой пользователям, и включением новейшей функциональности. В документе делается вывод, что осуществить "форк" компонентов свободной программы, настроить его под свои нужды, провести интенсивное тестирование (может отнять до двух лет) и ввести его в действие - значит выбросить деньги на ветер, поскольку в программу не смогут войти функции и исправления ошибок, появившиеся к тому времени в официальной ветке.

Строительство "супер-надёжной платформы на зыбучих песках" совсем не легко: многие проекты вообще не имеют стабильных версий, взять, например видео-кодеки для MPlayer, включённые в большинство дистрибутивов, для которых никогда не было релизов (стабильных или нестабильных). Или проект GIMP, проживший от версии 1.2.0 (декабрь 1999 г.) к версии 2.0.0 (март 2004) в нестабильном состоянии, имея только исправления ошибок для релизов серии 1.2.

Схема релизов через определённые промежутки времени, впервые введённая в проекте GNOME в 2001 г. и принятая в настоящее время в большинстве основных проектов СПО, нивелирует противоречие между необходимостью стабильности и одновременным включением новейших функций. Но ни одна программа не свободна от ошибок, ни свободная, ни проприетарная. В известной книге "Мифический человеко-месяц" Фред Брукс описал трудности интегрирования систем и рассчитал, что 25% процентов времени разработки проекта будет потрачено на интеграцию и тестирование связей между компонентами, которые уже были спроектированы, написаны и отлажены. В связи с этим построение системы дистрибутива Linux занимает гораздо больше времени, чем нужно на простую связку воедино стабильных версий каждого проекта в надежде, что всё это заработает.

Одной из оптимальных схем является "проведение черты" на определённом достигнутом этапе и начало подготовки релиза. Примером может служить система прогрессивной заморозки модулей в проекте GNOME. В свою очередь следующей трудностью будет решение вопроса "что делать после того, как черта проведена?" Приводятся три варианта действий на этом этапе, ни один из них не является идеальным: не выделять версии никогда (см., например, inotify), выделить позже или выделить сразу же.

Цена форка и потери связей с основной ветвью разработки делится на две части:

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

Например, если выразить в цифрах первую часть, в случае важнейших компонентов, таких, как GTK, WebKit, GStreamer и BlueZ, речь идёт о миллионах долларов. Некоторые цифры, приводимые в PDF-документе: для разработки GTK с нуля потребовалось бы 30 миллионов долларов, WebKit - 89 миллионов, GStreamer - 45 миллионов, BlueZ - 5,25 миллиона.