Страница:
Итак, я переформулировал свою проблему. Очевидно, что нужно было (1)добавить поддержку SMTP forwarding в родовой драйвер,(2) сделать это режимом по умолчанию, (3)выбросить все остальные режимы доставки, особенно возможности доставки в файл и доставки в стандартный выходной поток.
Некоторе время я не решался делать шаг 3, чтобы не подводить пользователей, зависящих от альтернативных методов доставки. Теоретически, чтобы получить тот же самый эффект они могли переключиться на использование.forward файлов или их не sendmail'овские эквиваленты. Практически, такой переход мог вызвать проблемы.
Однако, когда я решился на этот шаг, он принес много пользы. Значительная часть кода драйвера исчезла, конфигурация заметно упростилась,стало не нужно заботиться об MDA, пользовательском mailbox'e, поддержке блокировки файлов операционной системой.
К тому же исчез единственный способ потерять почту. Если у вас определена доставка почты в файл, а диск оказывается переполненным, то почту вы теряете. Это не может случиться при SMTP forwarding, так как SMTP listener не вернет OK, до тех пор пока сообщение не будет доставлено или отложено для более поздней доставки.
Также улучшилась производительность (хотя при единичном запуске вы бы этого не заметили). Другое незначительное улучшение заключалось в том, что справочная система (manual page) стала короче.
Позже, мне пришлось добавить доставку через локальный MDA определенный пользователем, для того чтобы справиться с некоторыми ситуациями связанными с динамическим SLIP'ом. Однако, я нашел для этого более простой способ.
Какой же из этого можно сделать вывод? Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности. Антуан де Сент– Экзюпери – человек, который был летчиком и авиаконструктором, сказал:
13.Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать.
Если ваш код становится одновременно и лучше и проще, вы поступаете правильно. В процессе разработки fetchmail приобрел свое собственное лицо, отличное от старого popclient'a.
Наступило время для смены имени. Новый дизайн больше походил на двойственный sendmail, чем старый popclient. Итак, через два месяца я переименовал его в fetchmail.
Некоторе время я не решался делать шаг 3, чтобы не подводить пользователей, зависящих от альтернативных методов доставки. Теоретически, чтобы получить тот же самый эффект они могли переключиться на использование.forward файлов или их не sendmail'овские эквиваленты. Практически, такой переход мог вызвать проблемы.
Однако, когда я решился на этот шаг, он принес много пользы. Значительная часть кода драйвера исчезла, конфигурация заметно упростилась,стало не нужно заботиться об MDA, пользовательском mailbox'e, поддержке блокировки файлов операционной системой.
К тому же исчез единственный способ потерять почту. Если у вас определена доставка почты в файл, а диск оказывается переполненным, то почту вы теряете. Это не может случиться при SMTP forwarding, так как SMTP listener не вернет OK, до тех пор пока сообщение не будет доставлено или отложено для более поздней доставки.
Также улучшилась производительность (хотя при единичном запуске вы бы этого не заметили). Другое незначительное улучшение заключалось в том, что справочная система (manual page) стала короче.
Позже, мне пришлось добавить доставку через локальный MDA определенный пользователем, для того чтобы справиться с некоторыми ситуациями связанными с динамическим SLIP'ом. Однако, я нашел для этого более простой способ.
Какой же из этого можно сделать вывод? Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности. Антуан де Сент– Экзюпери – человек, который был летчиком и авиаконструктором, сказал:
13.Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать.
Если ваш код становится одновременно и лучше и проще, вы поступаете правильно. В процессе разработки fetchmail приобрел свое собственное лицо, отличное от старого popclient'a.
Наступило время для смены имени. Новый дизайн больше походил на двойственный sendmail, чем старый popclient. Итак, через два месяца я переименовал его в fetchmail.
7. Fetchmail расширяется.
В работе над этой программой я использовал много изящных нововведений.
Программа работала хорошо, потому что я использовал ее каждый день, и часто прислушивался к моим бета-тестерам. Я вдруг осознал, что это не просто тривиальная хаккерская задача, которая может быть полезна разве лишь нескольким людям. У меня была программа нужная каждому хаккеру, имеющему UNIX-машину и SLIP/PPP соединение. Благодаря использованию SMPT-forwarding, эта программа могла бы стать «убийцей категории», т. е. программой, которая настолько плотно заполняет свою нишу,что все остальные оказываются просто забытыми.
Я думаю, что нельзя запланировать такой результат заранее. Обычно в разработку вас втягивают настолько мощные идеи, что результаты кажутся естественными и неизбежными. Единственный способ найти такую идею – это постоянно иметь множество всяких своих собственных идей, или обладать талантом заимствовать хорошие идеи у других людей, прежде чем они их осознают.
У Эндрю Таненбаума была идея построить простую UNIX-подобную систему для 386 машины, чтобы использовать ее как обучающий инструмент. Линус Торвальдс использовал идеи Minix, прежде чем Эндрю понял, что из них может получиться.
Этот проект вырос в нечто значительноое. Используя этот же способ (только в гораздо меньшем масштабе), я позаимствовал идеи у Карла Харриса и Гарри Хочхейзера. Вряд ли кого-нибудь из нас можно назвать гением. Однако, обычно научная, инженерная и промышленная разработка совершается не гениями, хаккерами.
Результаты этой работы были и быстрыми, и хорошими. Это был успех, которого хаккер ждет всю жизнь. Теперь, чтобы улучшит fetchmail, я писал код не только для себя, но также добавлял некоторые особенности, необходимые другим людям. Программа же при этом оставалась и простой, и рациональной.
Первое и наиболее важное добавление состояло в поддержке multidrop – особенности, позволяющей выбирать почту из ящиков, предназначенных для группы пользователей, а затем направлять ее получателю.
Я реализовал эту особенность частично потому, что об этом просили пользователи, а частично потому, что это помогло обнаружить ошибки в single-drop. Мне пришлось обобщить проблему адресации. Усилия себя оправдали. Изучение RFC 822 заняло у меня очень много времени, так как пришлось изучить множество несвязанных меджу собой деталей.
Multidrop-адрессация была замечательным решением. Вот что я из нее вынес:
14.Любой инструмент должен быть полезен для тех целей, для которых он разрабатывался. Великий инструмент становится полезным там, где от него ничего подобного не ожидали.
Другим важным изменеием, сделанным по просьбе моих бета-тестеров, стала поддержка 8-битовой операции MIME. Реализовать это было просто, потому что я старался оставить код 8-битным. Не потому что я чувствовал, что придется реализовывать эту особенность, а потому что я старался следовать следующему правилу:
15.Когда вы разрабатываете gateway software, старайтесь не вмешиваться в поток данных, пока вас к этому не вынудят.
Если бы я не стал следовать этому правилу, поддержка 8-битового MIME, стала бы очень трудной. А так мне просто пришлось прочитать RFC 1652.
Некоторые европейские пользователи просили меня добавить возможность ограничивать число писем за один сеанс (чтобы они могли контролировать издержки своих дорогих телефонных сетей). Я долго сопротивлялся этому, и до сих пор не уверен, что поступил правильно. Однако если вы пишете не только для себя, вы должны слушать ваших покупателей. Независимо от того получаете ли вы от них деньги.
Программа работала хорошо, потому что я использовал ее каждый день, и часто прислушивался к моим бета-тестерам. Я вдруг осознал, что это не просто тривиальная хаккерская задача, которая может быть полезна разве лишь нескольким людям. У меня была программа нужная каждому хаккеру, имеющему UNIX-машину и SLIP/PPP соединение. Благодаря использованию SMPT-forwarding, эта программа могла бы стать «убийцей категории», т. е. программой, которая настолько плотно заполняет свою нишу,что все остальные оказываются просто забытыми.
Я думаю, что нельзя запланировать такой результат заранее. Обычно в разработку вас втягивают настолько мощные идеи, что результаты кажутся естественными и неизбежными. Единственный способ найти такую идею – это постоянно иметь множество всяких своих собственных идей, или обладать талантом заимствовать хорошие идеи у других людей, прежде чем они их осознают.
У Эндрю Таненбаума была идея построить простую UNIX-подобную систему для 386 машины, чтобы использовать ее как обучающий инструмент. Линус Торвальдс использовал идеи Minix, прежде чем Эндрю понял, что из них может получиться.
Этот проект вырос в нечто значительноое. Используя этот же способ (только в гораздо меньшем масштабе), я позаимствовал идеи у Карла Харриса и Гарри Хочхейзера. Вряд ли кого-нибудь из нас можно назвать гением. Однако, обычно научная, инженерная и промышленная разработка совершается не гениями, хаккерами.
Результаты этой работы были и быстрыми, и хорошими. Это был успех, которого хаккер ждет всю жизнь. Теперь, чтобы улучшит fetchmail, я писал код не только для себя, но также добавлял некоторые особенности, необходимые другим людям. Программа же при этом оставалась и простой, и рациональной.
Первое и наиболее важное добавление состояло в поддержке multidrop – особенности, позволяющей выбирать почту из ящиков, предназначенных для группы пользователей, а затем направлять ее получателю.
Я реализовал эту особенность частично потому, что об этом просили пользователи, а частично потому, что это помогло обнаружить ошибки в single-drop. Мне пришлось обобщить проблему адресации. Усилия себя оправдали. Изучение RFC 822 заняло у меня очень много времени, так как пришлось изучить множество несвязанных меджу собой деталей.
Multidrop-адрессация была замечательным решением. Вот что я из нее вынес:
14.Любой инструмент должен быть полезен для тех целей, для которых он разрабатывался. Великий инструмент становится полезным там, где от него ничего подобного не ожидали.
Другим важным изменеием, сделанным по просьбе моих бета-тестеров, стала поддержка 8-битовой операции MIME. Реализовать это было просто, потому что я старался оставить код 8-битным. Не потому что я чувствовал, что придется реализовывать эту особенность, а потому что я старался следовать следующему правилу:
15.Когда вы разрабатываете gateway software, старайтесь не вмешиваться в поток данных, пока вас к этому не вынудят.
Если бы я не стал следовать этому правилу, поддержка 8-битового MIME, стала бы очень трудной. А так мне просто пришлось прочитать RFC 1652.
Некоторые европейские пользователи просили меня добавить возможность ограничивать число писем за один сеанс (чтобы они могли контролировать издержки своих дорогих телефонных сетей). Я долго сопротивлялся этому, и до сих пор не уверен, что поступил правильно. Однако если вы пишете не только для себя, вы должны слушать ваших покупателей. Независимо от того получаете ли вы от них деньги.
8. Несколько уроков из опыта работы над fetchmail'ом.
Прежде чем мы вернемся к общим рекомендациям по разработке программ, я расскажу о нескольких уроках, которые я вынес из опыта работы над fetcnmail'ом.
Синтаксис файла rc, включает в себя некоторые 'шумные' ключевые слова, которые полностью игнорируются синтаксическим анализатором. Предлагаемый синтаксис (напоминающий английский язык) значительно более читаемый, чем традиционные пары слово-значение, которые вы получите после того, как уберете все лишнее.
Этот эксперимент начался поздно ночью, когда я заметил, насколько обЪявления в файле rc стали напоминать небольшой императивный язык. (Вот почему я заменил ключевое слово 'server' на 'poll').
Традиционно программисты стремятся использовать точные и краткие управляющие конструкции. Это правильно, потому что вычислительные ресурсы дорогие, и процесс синтаксического анализа должен быть максимально простым и дешевым.
Потому брать за основу английйский язык невыгодно, так как в нем около 50% избыточных конструкций.
Для меня это не является причиной, чтобы избегать синтаксиса естественного языка. Дешевое исполнение инструкций и краткость не должны стать конечной целью. В первую очередь язык должен быть удобным для людей, а не дешевым для компьютеров.
Существуют еще несколько поводов для беспокойства. Во-первых, нежелательно, чтобы возросшая стоимость синтаксического анализа, стала сама по себе источником ошибок. Во-вторых, при попытке сделать язык «англоподобным», часто требуется, чтобы «английский» потерял свою форму настолько, чтобы он походил на естественный язык, не больше, чем традиционный синтаксис. (Это можно часто видеть в языках запросов «четвертого поколения» и языках коммерческих баз данных.) В управляющих конструкциях fetchmail'a этих проблем удалось избежать, так как область действия языка сильно ограничена. Он практически не является общецелевым языком,и поэтому несложно перейти от небольшого подмножества английского языка к действительному языку управления. Отсюда можно извлечь еще один урок:
16.Если ваш язык не является полным по Тьюрингу, добавьте немного синтаксического сахара.
Другой урок касается безопасности. Некоторые пользователи fetchmail'a просили меня изменить программу так, чтобы она хранила зашифрованные пароли в файле rc.
Я не сделал этого, потому что это не добавляет никакой защиты. Любой человек, имеющий право читать ваш файл, мог бы запустить fetchmail под вашим именем и, возможно, декодировать ваш пароль. Шифрование пароля в .fetchmailrc могло бы дать людям ложное чувство защищенности. Общее правило здесь следующее:
17.Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.
Синтаксис файла rc, включает в себя некоторые 'шумные' ключевые слова, которые полностью игнорируются синтаксическим анализатором. Предлагаемый синтаксис (напоминающий английский язык) значительно более читаемый, чем традиционные пары слово-значение, которые вы получите после того, как уберете все лишнее.
Этот эксперимент начался поздно ночью, когда я заметил, насколько обЪявления в файле rc стали напоминать небольшой императивный язык. (Вот почему я заменил ключевое слово 'server' на 'poll').
Традиционно программисты стремятся использовать точные и краткие управляющие конструкции. Это правильно, потому что вычислительные ресурсы дорогие, и процесс синтаксического анализа должен быть максимально простым и дешевым.
Потому брать за основу английйский язык невыгодно, так как в нем около 50% избыточных конструкций.
Для меня это не является причиной, чтобы избегать синтаксиса естественного языка. Дешевое исполнение инструкций и краткость не должны стать конечной целью. В первую очередь язык должен быть удобным для людей, а не дешевым для компьютеров.
Существуют еще несколько поводов для беспокойства. Во-первых, нежелательно, чтобы возросшая стоимость синтаксического анализа, стала сама по себе источником ошибок. Во-вторых, при попытке сделать язык «англоподобным», часто требуется, чтобы «английский» потерял свою форму настолько, чтобы он походил на естественный язык, не больше, чем традиционный синтаксис. (Это можно часто видеть в языках запросов «четвертого поколения» и языках коммерческих баз данных.) В управляющих конструкциях fetchmail'a этих проблем удалось избежать, так как область действия языка сильно ограничена. Он практически не является общецелевым языком,и поэтому несложно перейти от небольшого подмножества английского языка к действительному языку управления. Отсюда можно извлечь еще один урок:
16.Если ваш язык не является полным по Тьюрингу, добавьте немного синтаксического сахара.
Другой урок касается безопасности. Некоторые пользователи fetchmail'a просили меня изменить программу так, чтобы она хранила зашифрованные пароли в файле rc.
Я не сделал этого, потому что это не добавляет никакой защиты. Любой человек, имеющий право читать ваш файл, мог бы запустить fetchmail под вашим именем и, возможно, декодировать ваш пароль. Шифрование пароля в .fetchmailrc могло бы дать людям ложное чувство защищенности. Общее правило здесь следующее:
17.Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.
9. Необходимые условия для модели базара.
Читатели ранних версий этой статьи обязательно поднимали вопрос о необходимых условиях для разработки проекта в стиле базара, Здесь обычно рассматривали квалификацию лидера проекта и состояние системы на момент, когда принимается решение опубликовать исходные тексты и создать сообщество сотрудничающих разработчиков.
Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можно тестировать, отлаживать и улучшать программы, работая в стиле базара, но начать проект очень трудно, Ни я, ни Линус даже не пытались это сделать.
Вашему сообществу разработчиков нужно что-то, что можно отлаживать и тестировать.
Когда вы начинаете создавать сотрудничающее сообщество, вам необходимы убеждающие доводы. Ваша программа может не всегда правильно работать. Она может быть неполной, содержать ошибки или иметь плохую документацию. Однако, она должна обязательно убедить потенциальных сотрудников, в том что их собираются вовлечь в нечто стоящее.
Linux и fetchmail были представлены публике как программы, имеющие строгую основу. Многие люди, когда-либо размышлявшие о модели базара, поначалу относились к этому утвверждению критически. Однако позже почти все они приходили к мнению, что лидеру проекта крайне важно иметь высокую квалификацию и интуицию разработчика.
Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я же позаимствовал их у родового popmail'a (хотя мне пришлось переделывать значительно больше, чем Линусу). Так ли уж необходим координатору исключительный талант разработчика или он может использовать чужие идеи?
По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных.
И Linux, и fetchmail показали очевидность этого утверждения. Линус – отличный разработчик, который к тому же показал свое умение распознавать хороший дизайн и встраиваить его в ядро Linux. А я, в свою очередь, уже описывал, как единственная наиболее мощная идея в разработке fetchmail (SMTP forwarding) была получена со стороны.
Прежние читатели этой статьи отмечали, что я склонен недооценивать первоначальный дизайн в проектах базара, так как сам я отлично с ним справляюсь, и, поэтому принимаю это как должное. Возможно, в этом есть доля правды, дизайн, в отличие от кодирования и отладки, – мой конек.
Проблема первоначального дизайна заключается в том, что вы начинаете проект, усложняя себе задачу, в то время как следует оставлять ее простой и понятной. Некоторые мои проекты проваливались из-за того, что я совершал эту ошибку, и поэтому я старался не допустить ее при разработке fetchmail.
Итак, я уверен, что fetchmail удался, потому что я ограничил свою изобретательность. Давайте рассмотрим Linux. Предположим, что Линус Торвальдс стремился убрать основные изобретения в дизайне операционных систем, разве получили бы мы такое мощное и стабильное ядро?
Конечно, определенные знания в области дизайна, а также навык кодирования необходимы, но мне кажется, что каждый, кто всерьез думает о такой разработке, превосходят требуемый минмиум. Репутация внутреннего рынка открытых программ оказывает давление, которое предостерегает недостаточно компетентных людей.
Существует другое важное качество, не менее важное для успеха проекта в стиле базара. Координатор такого проекта должен иметь хороший опыт общения с людьми.
Необходимость этого очевидна. Для создания сообщества разработчиков, вам необходимо как-то привлечь людей, заинтересовать их тем, что вы делаете.
Техническая часть, конечно, очень существенна, но и ваша личность имеет немаловажное значение.
Линус не случайно является симпатичным парнем, который нравится людям, и которому люди с удовольствием помогают. Также не является совпадением то, что я – очень энергичный экстраверт, которому нравится работать в команде.
Если вы знаете как понравиться людям, это очень сильно поможет вам в разработке модели в стиле базара.
Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можно тестировать, отлаживать и улучшать программы, работая в стиле базара, но начать проект очень трудно, Ни я, ни Линус даже не пытались это сделать.
Вашему сообществу разработчиков нужно что-то, что можно отлаживать и тестировать.
Когда вы начинаете создавать сотрудничающее сообщество, вам необходимы убеждающие доводы. Ваша программа может не всегда правильно работать. Она может быть неполной, содержать ошибки или иметь плохую документацию. Однако, она должна обязательно убедить потенциальных сотрудников, в том что их собираются вовлечь в нечто стоящее.
Linux и fetchmail были представлены публике как программы, имеющие строгую основу. Многие люди, когда-либо размышлявшие о модели базара, поначалу относились к этому утвверждению критически. Однако позже почти все они приходили к мнению, что лидеру проекта крайне важно иметь высокую квалификацию и интуицию разработчика.
Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я же позаимствовал их у родового popmail'a (хотя мне пришлось переделывать значительно больше, чем Линусу). Так ли уж необходим координатору исключительный талант разработчика или он может использовать чужие идеи?
По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных.
И Linux, и fetchmail показали очевидность этого утверждения. Линус – отличный разработчик, который к тому же показал свое умение распознавать хороший дизайн и встраиваить его в ядро Linux. А я, в свою очередь, уже описывал, как единственная наиболее мощная идея в разработке fetchmail (SMTP forwarding) была получена со стороны.
Прежние читатели этой статьи отмечали, что я склонен недооценивать первоначальный дизайн в проектах базара, так как сам я отлично с ним справляюсь, и, поэтому принимаю это как должное. Возможно, в этом есть доля правды, дизайн, в отличие от кодирования и отладки, – мой конек.
Проблема первоначального дизайна заключается в том, что вы начинаете проект, усложняя себе задачу, в то время как следует оставлять ее простой и понятной. Некоторые мои проекты проваливались из-за того, что я совершал эту ошибку, и поэтому я старался не допустить ее при разработке fetchmail.
Итак, я уверен, что fetchmail удался, потому что я ограничил свою изобретательность. Давайте рассмотрим Linux. Предположим, что Линус Торвальдс стремился убрать основные изобретения в дизайне операционных систем, разве получили бы мы такое мощное и стабильное ядро?
Конечно, определенные знания в области дизайна, а также навык кодирования необходимы, но мне кажется, что каждый, кто всерьез думает о такой разработке, превосходят требуемый минмиум. Репутация внутреннего рынка открытых программ оказывает давление, которое предостерегает недостаточно компетентных людей.
Существует другое важное качество, не менее важное для успеха проекта в стиле базара. Координатор такого проекта должен иметь хороший опыт общения с людьми.
Необходимость этого очевидна. Для создания сообщества разработчиков, вам необходимо как-то привлечь людей, заинтересовать их тем, что вы делаете.
Техническая часть, конечно, очень существенна, но и ваша личность имеет немаловажное значение.
Линус не случайно является симпатичным парнем, который нравится людям, и которому люди с удовольствием помогают. Также не является совпадением то, что я – очень энергичный экстраверт, которому нравится работать в команде.
Если вы знаете как понравиться людям, это очень сильно поможет вам в разработке модели в стиле базара.
10. Социальный контекст открытых программ.
Верно сказано: лучшие программы начинаются с решения проблем автора, с которыми он сталкивается каждый день, и расширяются, потому что эти проблемы оказываются типичными для большого класса пользователей. Это возвращает нас к первому правилу, которое можно сформулировать более точно:
18.Чтобы решить интересную проблему, найдите проблему которая вас заинтересует. Это произошло с Карлом Харрисом и его родовым popclient'ом, это произошло со мной и fetchmail'ом. В этом нет ничего нового, гораздо интереснее другое. История с Linux'ом и fetchmail'ом указывает на следующую стадию в эволюции программного обеспечения – активное сообщество пользователей и разработчиков.
В «The Mythical Man-Month» Фред Брукс рассматривал различные зависимости времени разработки. Он показывает, что сложность проекта и его коммуникационные издержки квадратично зависят от числа разработчиков, в то время как проделанная работа зависит только линейно. Это утверждение называется «закон Брукса», и большинство признает его правильным. Однако, если бы дело было только в законе Брукса, Linux не мог бы существовать.
Пять месяцев назад, Джеральд Венберг в «Психологии программирования» предложил теорию, которую мы можем рассматривать, как жизненную поправку к закону Брукса. Обсуждая «неэгоистичное программирование» (egoless programming), Венберг замечает, что если разработчики не являются безраздельными владельцами исходников программ и приветствуют, когда другие люди помогают искать ошибки и предлагают различные улучшния, программа прогрессирует намного быстрее.
Возможно, терминология Венберга не способствует тому, чтобы его утверждения приняли. Многие люди улыбаются при описании хакеров Интернет как «неэгоистичных». Однако, я думаю, что его аргументы лучше всего соответствуют сегодняшней ситуации.
История UNIX подготовила нас к тому, что мы узнали от Linux (и тому, что я проверил на небольшом проекте, копируя методы Linux'a). В то время как кодирование является в основном индивидуальной деятельностью, гениальные хаккерские решения приходят от всего сообщества. Разработчик, который работает в замкнутом проекте и пользуется только своей головой, уступает разработчику, создающему открытый проект, в котором участвуют сотни людей, занятых поиском ошибок и предлагающих различные улучшения.
Однако, в традиционном мире UNIX этот подход не является единственным. Одна из причин – это коммерческие и торговые секреты, ограничения различных лицензий и т. д. Другая причина заключается в том, что Интернет недостаточно хорошее средство общения.
Прежде чем появилась дешевая связь через Интернет, существовало несколько географически компактных сообществ, традиции которых поощряли «неэгоистичное программирование», и разработчики сотрудничали друг с другом. Bell Labs, MIT AI Lab, UC Berkely стали родиной легендарных и до сих пор мощных изобретений.
Linux – это первый проект, который пытался собрать таланты по всему миру. Я думаю, что период зарождения Linux неслучайно совпал с появлением World Wide Web. Линус был первым, кто понял, как играть по новым правилам, которые стали возможными благодаря Интернет.
Дешевый Интернет является необходимым условием для развития модели Linux, но, как мне кажется, недостаточным. Другие жизненные факторы – это стиль руководства и традиции, побуждающие разработчиков искать сотрудников для достижения максимального эффекта.
Что же это за стиль руководства и каковы эти традиции? Они не могут быть основаны на принуждении, потому что тогда бы мы не получили таких результатов.
Ранее я ссылался на эффект Delphi, как возможное обЪяснение закона Линуса.
Также для этого безупречно подходят аналогии с адаптивными системами в биологии и экономике. Мир Linux во многих отношениях ведет себя как свободный рынок или как экологическая система. Это похоже на множество заинтересованных агентов, которые пытаются максимизировать полезность. В конечном итоге система, где эти агенты действуют независимо, оказывается более эффективной, чем та, в которой происходит централизованное планирование.
Функция полезности, которую максимизируют хаккеры Linux, не является классической для экономики. Она зависит от их самоудовлетворения и репутации среди других хаккеров.(Можно было бы назвать их мотивацию альтруистической, однако альтруизм сам по себе является средством самоудовлетворения альтруиста.) Добровольные сообщества, работающие по этому принципу встречаются довольно часто. Я долгое время участвовал в сообществе любителей научной фантастики, которое, в отличие от сообщества хаккеров, признает «egoboo» – улучшение репутации среди других фанатов – как единственную движущую силу добровольной работы.
Можно рассматривать метод Линуса, как способ создать эффективный «egoboo» рынок. То есть соединить заинтересованность отдельных хаккеров и задачу, которая может быть решена только в сообществе. В проекте fetchmail я показал (в меньшем масштабе), что эти методы могут давать хорошие результаты.
Возможно, я даже сделал это более систематически.
Многие люди (особенно те, которые не доверяют свободным рынкам по политическим причинам) ожидают, что подобное сообщество эгоистов будет расточительно, скрытно и враждебно настроено. Однако эти ожидания обманываются, что подтверждается одним ярким приером. Этот пример – ошеломляющее разнообразие, качество и глубина документации Linux. Известно, что программисты ненавидят писать документацию. Почему же тогда документация Linux столь обширна? Очевидно, что в этом случае свободный рынок Linux работает эффективнее, чем производители коммерческих программ.
Fetchmail и Linux показали, что опытный координатор может использовать Интернет для связи между разработчиками, не опасаясь, что проект превратится в хаос. Поэтому закону Брукса можно противопоставить следующее: 19. Если у координатора разработки есть средство связи, по меньшей мере такое как Интернет, и он умеет лидировать без принуждения, то лучше пользоваться несколькими головами, чем одной.
Я думаю, что будущее свободного программного обеспечения принадлежит людям, которые знают как играть в игру Линуса, которые оставляют стиль собора и разрабатывают проекты в стиле базара. Это не означает, что индивидуальность не играет больше никакой роли. Наоборот, впереди окажутся те, кто начинал с индвидуального мастерств, а потом расширил его через эффективное создание добровольных сообществ.
Возможно, это будущее не только свободных программ. Ни один разработчик коммерческих программ не сможет сравниться с сообществом Linux в решении проблемы. Немногие смогут нанять двести человек, которые участвовали в разработке fetchmail.
Вероятно, в конце концов свободное программное обеспечение победит, не только потому что кооперация правильна с точки зрения морали, но просто потому, что коммерческий мир не сможет состязаться с сообществами free-software, которые могут бросить гораздо большие силы на решение одной проблемы.
18.Чтобы решить интересную проблему, найдите проблему которая вас заинтересует. Это произошло с Карлом Харрисом и его родовым popclient'ом, это произошло со мной и fetchmail'ом. В этом нет ничего нового, гораздо интереснее другое. История с Linux'ом и fetchmail'ом указывает на следующую стадию в эволюции программного обеспечения – активное сообщество пользователей и разработчиков.
В «The Mythical Man-Month» Фред Брукс рассматривал различные зависимости времени разработки. Он показывает, что сложность проекта и его коммуникационные издержки квадратично зависят от числа разработчиков, в то время как проделанная работа зависит только линейно. Это утверждение называется «закон Брукса», и большинство признает его правильным. Однако, если бы дело было только в законе Брукса, Linux не мог бы существовать.
Пять месяцев назад, Джеральд Венберг в «Психологии программирования» предложил теорию, которую мы можем рассматривать, как жизненную поправку к закону Брукса. Обсуждая «неэгоистичное программирование» (egoless programming), Венберг замечает, что если разработчики не являются безраздельными владельцами исходников программ и приветствуют, когда другие люди помогают искать ошибки и предлагают различные улучшния, программа прогрессирует намного быстрее.
Возможно, терминология Венберга не способствует тому, чтобы его утверждения приняли. Многие люди улыбаются при описании хакеров Интернет как «неэгоистичных». Однако, я думаю, что его аргументы лучше всего соответствуют сегодняшней ситуации.
История UNIX подготовила нас к тому, что мы узнали от Linux (и тому, что я проверил на небольшом проекте, копируя методы Linux'a). В то время как кодирование является в основном индивидуальной деятельностью, гениальные хаккерские решения приходят от всего сообщества. Разработчик, который работает в замкнутом проекте и пользуется только своей головой, уступает разработчику, создающему открытый проект, в котором участвуют сотни людей, занятых поиском ошибок и предлагающих различные улучшения.
Однако, в традиционном мире UNIX этот подход не является единственным. Одна из причин – это коммерческие и торговые секреты, ограничения различных лицензий и т. д. Другая причина заключается в том, что Интернет недостаточно хорошее средство общения.
Прежде чем появилась дешевая связь через Интернет, существовало несколько географически компактных сообществ, традиции которых поощряли «неэгоистичное программирование», и разработчики сотрудничали друг с другом. Bell Labs, MIT AI Lab, UC Berkely стали родиной легендарных и до сих пор мощных изобретений.
Linux – это первый проект, который пытался собрать таланты по всему миру. Я думаю, что период зарождения Linux неслучайно совпал с появлением World Wide Web. Линус был первым, кто понял, как играть по новым правилам, которые стали возможными благодаря Интернет.
Дешевый Интернет является необходимым условием для развития модели Linux, но, как мне кажется, недостаточным. Другие жизненные факторы – это стиль руководства и традиции, побуждающие разработчиков искать сотрудников для достижения максимального эффекта.
Что же это за стиль руководства и каковы эти традиции? Они не могут быть основаны на принуждении, потому что тогда бы мы не получили таких результатов.
Ранее я ссылался на эффект Delphi, как возможное обЪяснение закона Линуса.
Также для этого безупречно подходят аналогии с адаптивными системами в биологии и экономике. Мир Linux во многих отношениях ведет себя как свободный рынок или как экологическая система. Это похоже на множество заинтересованных агентов, которые пытаются максимизировать полезность. В конечном итоге система, где эти агенты действуют независимо, оказывается более эффективной, чем та, в которой происходит централизованное планирование.
Функция полезности, которую максимизируют хаккеры Linux, не является классической для экономики. Она зависит от их самоудовлетворения и репутации среди других хаккеров.(Можно было бы назвать их мотивацию альтруистической, однако альтруизм сам по себе является средством самоудовлетворения альтруиста.) Добровольные сообщества, работающие по этому принципу встречаются довольно часто. Я долгое время участвовал в сообществе любителей научной фантастики, которое, в отличие от сообщества хаккеров, признает «egoboo» – улучшение репутации среди других фанатов – как единственную движущую силу добровольной работы.
Можно рассматривать метод Линуса, как способ создать эффективный «egoboo» рынок. То есть соединить заинтересованность отдельных хаккеров и задачу, которая может быть решена только в сообществе. В проекте fetchmail я показал (в меньшем масштабе), что эти методы могут давать хорошие результаты.
Возможно, я даже сделал это более систематически.
Многие люди (особенно те, которые не доверяют свободным рынкам по политическим причинам) ожидают, что подобное сообщество эгоистов будет расточительно, скрытно и враждебно настроено. Однако эти ожидания обманываются, что подтверждается одним ярким приером. Этот пример – ошеломляющее разнообразие, качество и глубина документации Linux. Известно, что программисты ненавидят писать документацию. Почему же тогда документация Linux столь обширна? Очевидно, что в этом случае свободный рынок Linux работает эффективнее, чем производители коммерческих программ.
Fetchmail и Linux показали, что опытный координатор может использовать Интернет для связи между разработчиками, не опасаясь, что проект превратится в хаос. Поэтому закону Брукса можно противопоставить следующее: 19. Если у координатора разработки есть средство связи, по меньшей мере такое как Интернет, и он умеет лидировать без принуждения, то лучше пользоваться несколькими головами, чем одной.
Я думаю, что будущее свободного программного обеспечения принадлежит людям, которые знают как играть в игру Линуса, которые оставляют стиль собора и разрабатывают проекты в стиле базара. Это не означает, что индивидуальность не играет больше никакой роли. Наоборот, впереди окажутся те, кто начинал с индвидуального мастерств, а потом расширил его через эффективное создание добровольных сообществ.
Возможно, это будущее не только свободных программ. Ни один разработчик коммерческих программ не сможет сравниться с сообществом Linux в решении проблемы. Немногие смогут нанять двести человек, которые участвовали в разработке fetchmail.
Вероятно, в конце концов свободное программное обеспечение победит, не только потому что кооперация правильна с точки зрения морали, но просто потому, что коммерческий мир не сможет состязаться с сообществами free-software, которые могут бросить гораздо большие силы на решение одной проблемы.
11. Благодарности
Эта статья была значительно улучшена, благодаря тому что очень многие люди участвовали в ее обсуждении. Особенно я благодарен Джеффу Датки dutky@wam.umd.edu, за то что предложил формулировку «отладка может быть параллельной» («debugging is parallelizable») и помог ее проанализировать.
Также я благодарен Нэнси Лебовитц nancy@universe.digex.net. Много конструктивной критики поступало от Джоан Эслингер wombat@kilimanjaro.engr.sgi.com и Марти Франц marty@net-link.net из General Technics. Пол Эггерт eggert@twinsun.com отметил конфликт между GPL и моделью базара. Я благодарен членам PLUG, группы Philadelphia Linux User's за тестирование первой публичной версии этой статьи. И, конечно, мне очень помогли комментарии Линуса Торвальдса.
Также я благодарен Нэнси Лебовитц nancy@universe.digex.net. Много конструктивной критики поступало от Джоан Эслингер wombat@kilimanjaro.engr.sgi.com и Марти Франц marty@net-link.net из General Technics. Пол Эггерт eggert@twinsun.com отметил конфликт между GPL и моделью базара. Я благодарен членам PLUG, группы Philadelphia Linux User's за тестирование первой публичной версии этой статьи. И, конечно, мне очень помогли комментарии Линуса Торвальдса.
12. Что читать дальше.
Я процитировал несколько отрывков из Mythical Man-Month Фредерика Брукса. Я рекомендую его 25-ое юбилейное дополнение от Addison-Wesley (ISBN 0-201-83595-9), которое дополняет его статью «No Silver Bullet». Джеральд П.
Венбегр в Psychology Of Computer Programming (New York, Van Nostrand Reingold 1971) представил неудачно названное понятие «неэгоистичного программирования». Хотя он не смог осознать бесполезность «принципа команды», он, вероятно, был первым, кто рассмотрел эту проблему всвязи с программным обеспечением. Ричард П, Габриэл, рассматривая Unix до эры Linux, спорит о превосходстве примитивной модели базара в своей статье: Lisp:Good News, Bad News, and How to Win Big.
Де Марко и Листер Peopleware:Productive Projects and Teams (New York;Dorset House, 1987; ISBN 0-932633-05-6) – это бесценный джем, где я с удовольствием увидел цитаты из Фреда Брукса. Хотя только небольшая часть из высказываний авторов напрямую применима к Linux, рассматриваемые условия, необходимые для творческой работы, помогут тем, кто попытается перенести некоторые принципы модели базара в более коммерческий контекст.
Венбегр в Psychology Of Computer Programming (New York, Van Nostrand Reingold 1971) представил неудачно названное понятие «неэгоистичного программирования». Хотя он не смог осознать бесполезность «принципа команды», он, вероятно, был первым, кто рассмотрел эту проблему всвязи с программным обеспечением. Ричард П, Габриэл, рассматривая Unix до эры Linux, спорит о превосходстве примитивной модели базара в своей статье: Lisp:Good News, Bad News, and How to Win Big.
Де Марко и Листер Peopleware:Productive Projects and Teams (New York;Dorset House, 1987; ISBN 0-932633-05-6) – это бесценный джем, где я с удовольствием увидел цитаты из Фреда Брукса. Хотя только небольшая часть из высказываний авторов напрямую применима к Linux, рассматриваемые условия, необходимые для творческой работы, помогут тем, кто попытается перенести некоторые принципы модели базара в более коммерческий контекст.
13. Эпилог: Netscape приветствует Базар!
Очень странно осознавать, что ты помогал вершиться Истории… 22 января 1998 года, приблизительно через семь месяцев после того как я впервые опубликовал эту статью, Netscape Communications, Inc. обЪявила о своих планах сделать открытыми исходные тексты Netscape Communicator.
Однако, я и представить себе не мог, что предшествовало этому обЪявлению.
Эрик Ханн, исполнительный вице-президент и глава технологического отдела Netscape'a написал мне: «От имени всех членов корпорации, я хочу поблагодарить Вас за то, что вы помогли нам понять эту проблему. Ваши убеждения и ваши статьи оказались наиболее вескими доводами в пользу принятия этого решения.» На следующей неделе я вылетел в Silicon Valley для однодневной стратегической конференции с исполнительными и техническими сотрудниками Netscape'a. Мы вместе разработали лицензию и стратегию выпусков релизов исходников Netscape'a, а также составили планы по внесению положительных вкладов в open-source сообщество. Еще рано слишком углубляться в детали, но где-нибудь через несколько недель мы получим подробности.
Netscape готов к тому, чтобы проверить модель Базара на настоящем полномасштабном проекте, взятом из коммерческого мира. Для мира открытых систем это предсттавляет опасность: ведь если проект Netscape'a не будет работать, то концепция open-source будет очень сильно дискредитирована в коммерческом мире.
С другой стороны это замечательная возможность для эксперимента.
Предварительная реакция на продвижение в сторону Wall Street была положительной. Мы получаем шанс показать свои способности. Если, благодаря этому проекту, Netscape вернет себе существенную часть рынка – это будет означать запоздалую революцию в компьютерной промышленности.
Следующий год обещает быть и поучительным и интересным.
Однако, я и представить себе не мог, что предшествовало этому обЪявлению.
Эрик Ханн, исполнительный вице-президент и глава технологического отдела Netscape'a написал мне: «От имени всех членов корпорации, я хочу поблагодарить Вас за то, что вы помогли нам понять эту проблему. Ваши убеждения и ваши статьи оказались наиболее вескими доводами в пользу принятия этого решения.» На следующей неделе я вылетел в Silicon Valley для однодневной стратегической конференции с исполнительными и техническими сотрудниками Netscape'a. Мы вместе разработали лицензию и стратегию выпусков релизов исходников Netscape'a, а также составили планы по внесению положительных вкладов в open-source сообщество. Еще рано слишком углубляться в детали, но где-нибудь через несколько недель мы получим подробности.
Netscape готов к тому, чтобы проверить модель Базара на настоящем полномасштабном проекте, взятом из коммерческого мира. Для мира открытых систем это предсттавляет опасность: ведь если проект Netscape'a не будет работать, то концепция open-source будет очень сильно дискредитирована в коммерческом мире.
С другой стороны это замечательная возможность для эксперимента.
Предварительная реакция на продвижение в сторону Wall Street была положительной. Мы получаем шанс показать свои способности. Если, благодаря этому проекту, Netscape вернет себе существенную часть рынка – это будет означать запоздалую революцию в компьютерной промышленности.
Следующий год обещает быть и поучительным и интересным.
14. Версия и история изменений
$Id: baz14.txt,v 1.1 1998/07/03 10:27:42 aak Exp $ Я представил версию 1.16 на Linux конгрессе 21 марта 1997 года. Я добавил библиографию 7 июля 1997 года в версию 1.20 Я добавил анекдот о Perl конференции 18 ноября 1997 года в версию 1.27 Я изменил слова «free software» на «open source» 9 февраля 1998 года в версии 1.27 Я добавил «13. Эпилог: Netscape приветствует Базар!» 10 февраля 1997 года в версию 1.31 Остальные изменения содержат небольшие редакторские исправления.
Обращений с начала месяца: 54, Last-modified: Thu, 14 Jan 1999 13:25:29 GMT
Обращений с начала месяца: 54, Last-modified: Thu, 14 Jan 1999 13:25:29 GMT