Собор и Базар

«Собор и Базар» (англ. The Cathedral and the Bazaar; аббревиатура CatB) — эссе Эрика Рэймонда 1999 года на тему методов разработки программного обеспечения, основанное на анализе процесса разработки ядра Linux и личном опыте управления открытым проектом fetchmail.

Собор и Базар

Статья в Википедии

Цитаты

Все хорошие программы появляются для личных нужд разработчиков.

Хорошие программисты знают, что можно написать; а великие знают, что можно переписать.

Характерная черта великих - это их лень. Они знают, что судят не по усилиям, а по результатам.

Почти всегда легче начать с чего-то сделанного, чем с нуля.

…Когда вы первый раз реализуете какое-либо решение, вы часто не понимаете проблему до конца. Во второй раз вы уже набираете достаточно знаний, чтобы сделать это правильно. Итак, если вы хотите написать что-нибудь стоящее, лучше хотя бы один раз начать все заново.

При правильном отношении интересная проблема найдет вас сама.

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

Иметь пользователей - это замечательно. Не только потому что это означает, что вы предоставляете нужную услугу. Дело в том, что правильно воспитанные пользователи могут стать сотрудниками.

Если пользователи будут вашими сотрудниками, то вам обеспечены улучшение кода и эффективная отладка.

Я действительно думаю, что наиболее значительное и результативное творение Линуса - это не создание ядра Linux'a, а изобретение модели его разработки.

Выпускайте ранние релизы. выпускайте частые релизы. Слушайте своих пользователей.

При достаточном количестве бета-тестеров и сотрудников, почти любая проблема будет быстро обнаружена и окажется для кого-то очевидной.

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

Согласитесь, не очень-то здорово отвечать за исправление ошибок в программе, которую ты не понимаешь.

Хорошие структуры данных и плохой код работают несколько лучше, чем хороший код и плохие данные.

Если вы относитесь к вашим бета-тестерам как к самому ценному ресурсу, очень скоро они станут вашим самым ценным ресурсом.

Иногда использовать идеи пользователей лучше, чем использовать свои идеи.

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

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

Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности. Антуан де Сент-Экзюпери - человек, который был летчиком и авиаконструктором, сказал: «Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать».

…Обычно научная, инженерная и промышленная разработка совершается не гениями, хакерами.

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

Когда вы разрабатываете gateway software, старайтесь не вмешиваться в поток данных, пока вас к этому не вынудят.

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

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

Система безопасности надёжна, пока надёжны ее секреты. Избегайте псевдо-секретов.

По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных .

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

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

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

Я думаю, что будущее свободного программного обеспечения принадлежит людям, которые знают как играть в игру Линуса, которые оставляют стиль собора и разрабатывают проекты в стиле базара. Это не означает, что индивидуальность не играет больше никакой роли. Наоборот, впереди окажутся те, кто начинал с индивидуального мастерства, а потом расширил его через эффективное создание добровольных сообществ. Возможно, это будущее не только свободных программ. Ни один разработчик коммерческих программ не сможет сравниться с сообществом Linux в решении проблемы. Немногие смогут нанять двести человек, которые участвовали в разработке fetchmail. Вероятно, в конце концов свободное программное обеспечение победит, не только потому что кооперация правильна с точки зрения морали, но просто потому, что коммерческий мир не сможет состязаться с сообществами free-software, которые могут бросить гораздо большие силы на решение одной проблемы.