Эрик Рэймонд - Собор и Базар

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

Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можно тестировать, отлаживать и улучшать программы, работая в стиле базара, но начать проект очень трудно, Ни я, ни Линус даже не пытались это сделать.

Вашему сообществу разработчиков нужно что-то, что можно отлаживать и тестировать.

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

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

Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я же позаимствовал их у родового popmail'a (хотя мне пришлось переделывать значительно больше, чем Линусу). Так ли уж необходим координатору исключительный талант разработчика или он может использовать чужие идеи?

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

И Linux, и fetchmail показали очевидность этого утверждения. Линус – отличный разработчик, который к тому же показал свое умение распознавать хороший дизайн и встраиваить его в ядро Linux. А я, в свою очередь, уже описывал, как единственная наиболее мощная идея в разработке fetchmail (SMTP forwarding) была получена со стороны.

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

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

Итак, я уверен, что fetchmail удался, потому что я ограничил свою изобретательность. Давайте рассмотрим Linux. Предположим, что Линус Торвальдс стремился убрать основные изобретения в дизайне операционных систем, разве получили бы мы такое мощное и стабильное ядро?

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

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

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

Техническая часть, конечно, очень существенна, но и ваша личность имеет немаловажное значение.

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

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

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

18.Чтобы решить интересную проблему, найдите проблему которая вас заинтересует. Это произошло с Карлом Харрисом и его родовым popclient'ом, это произошло со мной и fetchmail'ом. В этом нет ничего нового, гораздо интереснее другое. История с Linux'ом и fetchmail'ом указывает на следующую стадию в эволюции программного обеспечения – активное сообщество пользователей и разработчиков.

В «The Mythical Man-Month» Фред Брукс рассматривал различные зависимости времени разработки. Он показывает, что сложность проекта и его коммуникационные издержки квадратично зависят от числа разработчиков, в то время как проделанная работа зависит только линейно. Это утверждение называется «закон Брукса», и большинство признает его правильным. Однако, если бы дело было только в законе Брукса, Linux не мог бы существовать.

Пять месяцев назад, Джеральд Венберг в «Психологии программирования» предложил теорию, которую мы можем рассматривать, как жизненную поправку к закону Брукса. Обсуждая «неэгоистичное программирование» (egoless programming), Венберг замечает, что если разработчики не являются безраздельными владельцами исходников программ и приветствуют, когда другие люди помогают искать ошибки и предлагают различные улучшния, программа прогрессирует намного быстрее.

Возможно, терминология Венберга не способствует тому, чтобы его утверждения приняли. Многие люди улыбаются при описании хакеров Интернет как «неэгоистичных». Однако, я думаю, что его аргументы лучше всего соответствуют сегодняшней ситуации.

История UNIX подготовила нас к тому, что мы узнали от Linux (и тому, что я проверил на небольшом проекте, копируя методы Linux'a). В то время как кодирование является в основном индивидуальной деятельностью, гениальные хаккерские решения приходят от всего сообщества. Разработчик, который работает в замкнутом проекте и пользуется только своей головой, уступает разработчику, создающему открытый проект, в котором участвуют сотни людей, занятых поиском ошибок и предлагающих различные улучшения.

Однако, в традиционном мире UNIX этот подход не является единственным. Одна из причин – это коммерческие и торговые секреты, ограничения различных лицензий и т. д. Другая причина заключается в том, что Интернет недостаточно хорошее средство общения.