Действительно ли модель открытых исходников предоставляет собой среду быстрой разработки программ?
"Идея открытых исходников работает, но это определенно не панацея... Программное обеспечение сложно. Возникающие проблемы не просты."
Джейми Завински
В меморандуме "Halloween I" была сформулирована гипотеза, что повторная реализация существующих систем и протоколов может быть реализована быстрее с использованием Интернета (и метода открытых исходников - прим. автора). Для проектов других типов использование метода открытых исходников может замедлять темпы разработки, по сравнению с реализаций той же системы традиционными методами. Существующий реализованный прототип может использоваться как определитель (своего рода, пробный камень) прогресса разработки; наличие прототипа может также стимулировать распараллеливание работы, которое позволяет более полно использовать преимущества распределенной группы разработчиков, связанных с помощью Интернета.
Когда программный проект требует, чтобы разработчики действовали последовательно, следуя единому нераспараллеливаемому плану разработки модулей, темпы разработки с открытыми исходниками могут сравняться с традиционными проектами, либо даже отстать от них. В подобных случаях Интернет не дает безусловных преимуществ. Ключевым фактором часто становится личность ведущего разработчика. Например, TeX был создан без помощи Интернета; я сомневаюсь, что Интернет или связанное с помощью Интернета сообщество разработчиков смогли бы ускорить работу.
// я искренне сожалею о тех поистине добрых старых временах, когда
// TeX еще помещался на одну дискету, не искалеченный доброжелателями
// вроде авторов teTeX, LaTeX, TDS и т.п.
В то же время, большие коллективы препятствуют инновации, так что данный проект может "загнить". Эту мысль удачно сформулировал Джейми Завински:
"Несмотря на существование контрпримеров, в общем случае выдающиеся разработки выполняются небольшими группами энтузиастов, которые мотивированы достичь успеха и объединены общей целью. Чем большее количество людей вовлечено в проект, тем более вялым и тупым становится такой творческий коллектив."
Но существует еще одна проблема, связанная со скоростью и разработкой программ с открытыми исходниками. Я полагаю, что когда скорость становится действительно важной, авторитарные методы управления получают явные преимущества над демократическими. "Скорость убивает" и ее первой жертвой становится демократия (впервые отмечено Фредериком Бруксом в его анализе разработки OS/360). Чисто авторитарный стиль ведет к созданию внутри проекта элиты и жесткой иерархии, которая рано или поздно может погубить проект с открытыми исходниками. Поэтому любая попытка ускорить существующий проект с открытыми исходниками может, по достижении определенного предела, привести к неожиданным последствиям, включая непредвиденные изменения в существующей социальной структуре проекта. Состязание с Microsoft (поощряемое некоторыми евангелистами Linux) являет собой опасную угрозу движению за открытые исходники в целом. В попытке соревноваться с авторитарной организацией скорость создания новых версий может стать вопросом жизни и смерти.
Небольшие проекты не требуют явных координационных структур. Координация обычно производится автоматически лидером проекта или группой лидеров. Такой подход начинает давать сбои по мере роста объема и сложности проекта. В больших проектах авторитарная модель является единственным выбором, если скорость разработки является определяющим критерием. Если скорость считается важной целью проекта, коллектив разработчиков будет действовать, сознательно или бессознательно, в направлении поощрения авторитарных тенденций своего лидера. В конце концов, это может вызвать проблемы.
Эту мысль удачно сформулировал Джордан Хаббард (Jordan Hubbard): "Вопреки периодическим заявлениям пропагандистов программ с открытыми исходниками, централизованные модели разработки, подобные применяемым в проекте FreeBSD, нельзя назвать устаревшими или неэффективными в мире свободного ПО. Внимательный анализ причин успехов анархической ("базарной") модели разработки программ зачастую выявляет существование значительной степени централизации, которая на самом деле является неотъемлемой чертой процесса разработки таких программ."
Также важно, имеет ли проект одну четко определенную цель (например, повторно реализовать UNIX или протокол HTTP), которая могла бы эффективно координировать действия участников распределенной группы.
В общем случае, любой быстро развивающийся проект с открытыми исходниками имеет высокий уровень централизации. Эта потребность в централизации может восприниматься участниками как "культ личности", когда один разработчик имеет огромный авторитет (например, как Линус Торвальдс в Linux). Это, в свою очередь, может привести к высокому уровню внутренних трений и разногласий, иногда вызывающему разделение проекта на два или более соревнующихся направления разработки. Примерами могут служить NetBSD/OpenBSD, Emacs/Xemacs и gcc/egcs. Если вдруг Линус Торвальдс начнет отвергать слишком многие важные исправления и будет считаться "узким местом" для разработки ядра Linux, то вы можете в будущем стать свидетелями раскола среди разработчиков.
Говоря об открытых исходниках, обычно подчеркивают качество и простоту, а не скорость разработки. Акцентирование качества как центральной цели проекта реально увеличивает шансы выживания проекта в открытых исходниках.
