Как умирают открытые проекты
Принадлежность к сообществу открытых исходников ничего не гарантирует. Ни в коей мере оно не является чудодейственным средством, гарантирующим успех проекта. Смертность среди проектов с открытыми исходными текстами довольно высока; значительное число никогда не достигает магической версии1.0. Когда вы видите веб-страницу, не обновлявшуюся в течение года или около того, это обычно служит предупреждением, что здесь что-то не так. Существует несколько причин умирания:
Сгорание: Первое и очевидное причина состоит в том, что лидер данного проекта перенапрягся и просто "сгорел". Иногда задача попросту слишком сложна, и автор переоценил свои силы и наличные ресурсы. В этом случае он попросту не в состоянии создать более или менее завершенную версию, которая может породить поддержку со стороны пользователей (их попросту еще нет).
Неспособность набрать критическую массу пользователей: Даже если проект и был успешно завершен (достигнув уровня стабильной рабочей версии), другие проекты могут захватить ресурсы и поддержку пользователей, этим обрекая его на забвение. "Потеря критической массы" означает крупные проблемы. Без критической массы пользователей любой значительный проект становится бесплодным.
Уход ведущего разработчика: В некоторых случаях ведущий разработчик находит новую работу и более не имеет времени либо интереса продолжать нынешний проект. Личные проблемы и отвлекающие факторы также могут эффективно погубить проект. Проблемы со здоровьем тоже нередки среди авторов крупных проектов, которые работают, как проклятые.
Раскол: Конфликты на почве ущемленного самолюбия могут вести к расколу. Раскол проекта часто может привести к гибели и начального, и отделившегося проектов. Отношения между лидером и его последователями - довольно тонкая материя, они требуют очень умелого и осторожного использования власти. Ее лучше не применять, пока предмет разногласий не является очень критичным, поскольку конфликт может вызвать отчужденность в сообществе разработчиков.
Неаккуратное использование лидером своей власти может оттолкнуть пользователей и этим создать предпосылки для раскола проекта любым из его заместителей. Раскол сокращает ресурсы, доступные исходной и отделившейся версиям, что может увеличить влияние других негативных факторов, угрожающих существованию проекта. Часто это может быть вызвано нехваткой организационных и дипломатических способностей со стороны ведущего разработчика. Не случайно, что большинство лидеров успешных проектов с открытыми исходными текстами довольно компетентны в плане умения избегать внутренних склок и расколов, вызванных эгоизмом.
Я хотел бы также заметить, что успех не означает превосходство данного технического видения. Подобно науке, смена доминирующей парадигмы сложна и болезненна. Незначительные и менее драматичные перемены более привлекательны, чем перевороты, как в программном обеспечении, так и в науке. Инерция в разработке программ подобна инерции в академии. Это значит, что талантливые личности должны преодолеть не только технические проблемы - они должны сломить сопротивление общества своим идеям. Подобно академическому сообществу, прямые контакты с влиятельными членами общества и доступ к основным центрам разработки очень важны и могут существенно сократить препоны на пути восприятия некоторой идеи. Этот феномен - "трагедия провинциального таланта" - был впервые исследован нобелевским лауреатом Петром Леонидовичем Капицей. Его анализ работ некоторых русских физиков, никогда не популяризовавшихся и не признанных большей частью западного научного сообщества, прямо применим к программам с открытыми исходниками.
Капица понимал, что близость к ведущим исследовательским центрам и работающим там ученым существенно облегчает принятие открытий научным сообществом в целом. Как только открытие интегрировано в систему научного знания, начинается смена устаревшей, но господствующей теории (существующей парадигмы).
