        ќрик ‘.ђэймонд. ‘обор и Ѓазар

---------------------------------------------------------------
 Ћригинал перевода расположен на сайте "“рбансофт"
 http://www.usoft.spb.ru/Graphic/Russian/FreeSoftware/baz.html і http://www.usoft.spb.ru/Graphic/Russian/FreeSoftware/baz.html
---------------------------------------------------------------


џ  проанализировал  один  из  успешных  проектов   открытой   разработки   -
fetchmail, который Я использовал, чтобы  проверить  некоторые  теоретические
соображениЯ  о  разработке  программного  обеспечениЯ,  возникшие из истории
Linux'a. џ обсуждаю эти соображениЯ с позиций двух совершенно разных  стилей
разработки:  модели  "собора",  распространенной  в  коммерческом  мире, или
модели "базара", предложенной в мире Linux'a.  џ  показал,  что  эти  модели
происходЯт от разного подхода к задаче отладки программ.

1. ‘обор и Ѓазар.
2. Џроблемы с пересылкой почты.
3. Љак важно иметь пользователей.
4. ‚ыпускать релизы нужно часто и рано.
5. ђоза или не ђоза?
6. Popclient превращаетсЯ в Fetchmail.
7. Fetchmail расширЯетсЯ.
8. Ќесколько уроков из опыта работы над fetchmail'ом.
9. Ќеобходимые условиЯ длЯ разработки в стиле базара.
10. ‘оциальный контекст открытых программ.
11. Ѓлагодарности.
12. „лЯ дальнейшего чтениЯ.
13. ќпилог: Netscape приветствует Ѓазар!
14. ‚ерсиЯ и историЯ изменений.

        1. ‘обор и Ѓазар.

Linux  -  удивительнаЯ  система.  Љто  бы  мог подумать, что несколько тысЯч
разработчиков, разбросанных по всей планете и  сотрудничающих  только  через
€нтернет,  смогут  создать операционную систему мирового класса. џ во всЯком
случае так не думал. Љ тому времени как Linux оказалась в поле моего  зрениЯ
в  начале 1993 года, Я уже около десЯти лет участвовал в разработке UNIX'a и
открытых программ. џ был одним из первых участников GNU в середине  80-х.  џ
был  автором многих открытых программ, и в частности участвовал в разработке
nethack, Emacs VC и GUD modes, xlife, которые широко используютсЯ и  по  сей
день. џ думал, что Я знаю, как это делаетсЯ.

Linux  перевернула  мои  представлениЯ  о  том,  что  Я  знаю. џ считал, что
основным в разработке небольших инструментов длЯ UNIX'a ЯвлЯетсЯ их  быстрое
проектирование и эволюционирующее программирование в течение многих лет. € в
то   же   времЯ   Я  верил,  что  по  мере  того  как  сложность  разработки
увеличиваетсЯ,  необходим  более  централизованный  подход.  џ  верил,   что
разработка  самого сложного программного обеспечениЯ (например, операционных
систем или просто больших инструментов, таких как Emacs) должна быть подобна
строительству     собора.     ’акие     программы     должны     создаватьсЯ
мастерами-индивидуалистами  или небольшими группами волшебников, работающими
в строгой изолЯции, не допускаЯ преждевременных бета-версий.

ЊенЯ очень  удивил  стиль  разработки  ‹инуса  ’орвальдса  -  частый  выпуск
релизов,  доступность  всех  исходных  текстов  и  терпимость  к разнородным
программам.  ќто  совсем  непохоже  на  размеренное  строительство   собора,
сообщество  Linux  скорее  напоминает  шумный  базар, с множеством различных
подходов и направлений. ’о,  что  на  этом  базаре  рождаетсЯ  согласованнаЯ
стабильнаЯ операционнаЯ система, кажетсЯ чудом из чудес.

ЊенЯ  потрЯсло,  что  этот  базарный  стиль работает и работает хорошо. џ не
только участвовал в разработке индивидуальных  проектов,  но  также  пыталсЯ
понЯть, почему в мире Linux'a не только не возникает беспорЯдка, но напротив
он  движетсЯ  вперед  со  скоростью,  которой  строители собора могут только
позавидовать.

Љ  середине  1996  года  мне  показалось,  что  Я  начал  понимать.   ‘удьба
предоставила  мне  прекрасный  шанс  проверить  мою  теорию.  ќто был проект
разработки открытого пгораммного обеспечениЯ, который Я сознательно провел в
базарном стиле. “спех этого проекта превзошел все ожиданиЯ.

‚ этой статье Я расскажу вам историю этого проекта, и на его примере  покажу
несколько правил эффективной разработки свободного программного обеспечениЯ.
Ќе  все  эти  приемы  Я  узнал  из мира Linux'a, но если Я прав, они помогут
понЯть, почему сообщество Linux'a производит  столько  полезных  программ  и
помогут вам повысить производительность.

        2. Џроблемы с пересылкой почты.

C 1993 года Я занималсЯ решением  технических  проблем  небольшого  свободно
доступного  ISP,  который  называлсЯ Chester Counter InterLink (CCIL). џ был
одним из  основателей  CCIL  и  написал  свою  собственную  BBS  (вы  можете
проверить  это,  сделав  telnet  на locke.ccil.org). ‘егоднЯ он поддерживает
почти три  тысЯчи  пользователей  на  девЯтнадцати  линиЯх.  ЃлагодарЯ  этой
работе,  Я  имел неограниченный доступ к Internet через линию 56K! €так, мне
пришлось использовать почту Internet. Џо некоторым причинам мне было  сложно
соединить  CCIL  и  мою  домашнюю  машину по протоколу SLIP. ‚ конце концов,
когда мне это удалось, оказалось,  что  очень  неудобно  делать  telnet  длЯ
проверки  своей  почты.  џ  хотел,  чтобы  когда почта приходила на snark, Я
получал об этом сообщение и мог бы обрабатывать ее локальными инструментами.

Џростой sendmail мне помочь не мог, потому что моЯ домашнЯЯ машина не всегда
находитсЯ в  сети  и  не  имеет  статического  IP  адреса.  Њне  нужна  была
программа,  котораЯ  бы  через SLIP соединие забирала мою почту. џ знал, что
такие вещи существуют, и большинство из них использует простой протокол  POP
(Post Office Protocol). Љ тому же в операционную систему BSD/OS на locke был
включен POP3 сервер.

Њне нужен был POP3 клиент. Ћдну такую программу Я нашел через сеть (на самом
деле  Я  нашел три или четыре). Ќекоторое времЯ Я использовал pop-perl, но в
нем отсутствовала одна необходимаЯ возможность : он не умел выбирать  адреса
так, чтобы можно было правильно отвечать на письма.

Џроблема  заключалась  в  следующем.  „опустим,  что  кто-то  по имени 'joe'
прислал мне на locke письмо. …сли Я пыталсЯ ответить на него, после того как
забрал его на snark, мой mailer пыталсЯ адресовать ее несуществующему joe на
snark. €справлЯть вручную '@ccil.org' было утомительно.

Ќужные мне возможности  были  очевидны,  но  ни  один  из  существующих  POP
клиентов не знал как это сделать. ќто приводит нас к первому уроку:

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

Ќеобходимость  -  мать  изобретениЯ. ‘лишком часто программисты работают над
программами, из которых они не могут извлечь ни  пользы  ни  удовольствиЯ  -
ничего  кроме  денег.  Ќо  в  мире  Linux  - все по-другому, и это обљЯснЯет
высокое качество программ длЯ Linux.

‚ы думаете, Я тут же начал разрабатывать свой POP3 клиент, соревнуЯсь с  уже
имеющимисЯ?  Ќи  в  коем  случае!  џ  внимательно  осмотрел все POP утилиты,
которые были у менЯ под рукой, и  спросил  себЯ,  котораЯ  из  них  наиболее
соответствует моим требованиЯм. Џотому что

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

џ не претендовал на великого  программиста,  а  попыталсЯ  его  имитировать.
•арактернаЯ черта великих - это их лень. Ћни знают, что судЯт не по усилиЯм,
а  по  результатам.  Џочти  всегда  легче начать с чего-то сделанного, чем с
нулЯ.

‹инус ’орвальдс, например, не пыталсЯ написать свою систему с нулЯ. Ћн начал
использовать идеи и исходники от Minix, небольшой UNIX-подобной системы  длЯ
386  машин.  Џочти  весь  исходный  текст  Minix  был  переписан, однако, он
послужил основой длЯ того что позже стало Linux'ом.

„ействуЯ в том же духе, Я  начал  искать  существующую  POP  утилиту,  чтобы
использовать ее как основу длЯ разработки.

‚  мире UNIX'a всегда существовала традициЯ делать исходные тексты открытыми
и дружественными к повторному использованию кода. €менно поэтому проект  GNU
выбрал UNIX как основную операционную систему. Њир Linux'a полностью перенЯл
эту  традицию.  ‡десь  вы можете найти терабайты исходных текстов, и поэтому
шансов найти что-нибудь подходЯщее в мире Linux'a выше, чем  где  бы  то  ни
было.

Њне  это  подошло. ‚месте с теми программами, которые Я нашел раньше, у менЯ
оказались девЯть кандидатов: fetchpop, PopTart, get-mail, gwpop, pimp,  pop-
perl,  popc,  popmail  и  upop.  ‘начала  Я остановилсЯ на fetchpop, автором
которой ЯвлЯетсЯ Seung-Hong Oh. џ добавил туда мою  процедуру  переписываниЯ
заголовка и другие возможности, которые автор принЯл в версии 1.9

Ќесколькими неделЯми позже Я наткнулсЯ на код 'popclient' -       программу,
написанную Љарлом •аррисом - и обнаружил одну проблему. •отЯ у fetchpop были
оригинальные идеи (например, режим демона), но написан он был любителем. Љод
Љарла  был  значительно  профессиональнее,  но  его  программе   недоставало
несколько  важных  возможностей, в том числе и тех, которые Я реализовал длЯ
fetchpop'a.

—то делать? Ћставить все как есть или начать заново? …сли бы Я начал  заново
мне  пришлось  бы пожертвовать своими программами ради более надежной основы
длЯ разработки.

‘амым существенным поводом длЯ того  чтобы  начать  заново,  была  поддержка
нескольких  протоколов. POP3 один из наиболее часто используемых post-office
протоколов сервера, однако он далеко  не  единственный.  Fetchpop  и  другие
подобные программы не используют POP2, RPOP или APOP, а у менЯ уже поЯвилась
мысль  использовать IMAP - недавно разработанный, очень мощный post - office
протокол.

3. "„аже если вы не планировали выбрасывать первую версию; выбрасываЯ ее, вы
все равно выигрываете." (”ред Ѓрукс "The Mythical Man-Month", глава 11)

„ругими словами, когда вы первый раз реализуете какоелибо решение, вы  часто
не понимаете проблему до конца. ‚о второй раз вы  уже  набираете  достаточно
знаний,   чтобы  сделать  это  правильно.  €так,  если  вы  хотите  написать
что-нибудь стоЯщее, лучше хотЯ бы один раз начать все заново.

џ сказал себе, что изменениЯ в fetchpop были моей первой попыткой.  €так,  Я
решил начать все заново.

25  июнЯ  Я послал набор программ длЯ popclient'a Љарлу •аррису и обнаружил,
что он  практически  потерЯл  интерес  к  этой  работе.  Љод  был  не  очень
аккуратный,   и  содержал  несколько  ошибок.  Њне  пришлось  сделать  много
изменений, и мы согласились, что мне следует стать владельцем программы.

џ и не замеитл, как проект начал расширЯтьсЯ. џ больше не  писал  программы,
дополнЯющие popclient. џ стал работать с целой программой. ‚ моей голове уже
кипели идеи о глобальных изменениЯх.

…сли  культура программированиЯ приветствует разделение исходных текстов, то
это  самый  естественный  способ  развитиЯ   проекта.   џ   руководствовалсЯ
следующим:

4. Џри правильном отношении интереснаЯ проблема найдет вас сама.

Ћтношение Љарла •арриса больше не имело значениЯ. Ћн понЯл, что :

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

Љарл и Я знали, что наша общаЯ цель - поиск наилучшего  решениЯ.  Њне  нужно
было только доказать свою компетентность. Љак только Я это сделал, он быстро
предал мне все полномочиЯ. Ќадеюсь, что когда-нибудь Я поступлю также.


        3. Љак важно иметь пользователей

€так  Я  унаследовал  popclient.  Ќо  гораздо  важнее  то, что Я унаследовал
пользователей popclient'a. €меть пользователей - это замечательно. Ќе только
потому что это означает, что вы предоставлЯете нужную услугу.  „ело  в  том,
что правильно воспитанные пользователи могут стать сотрудниками.

‘ильнаЯ   традициЯ  Unix'а,  а  особенно  Linux'a  заключаетсЯ  в  том,  что
большинство пользователей ЯвлЯютсЯ хакерами. ’ак как исходный текст программ
доступен, они могут  стать  эффективными  хакерами.  ќто  может  значительно
уменьшить  времЯ  отладки.  …сли  вы  сможете воодушевить пользователей, они
будут диагностировать проблемы, предлагать решениЯ и помогать  улучшить  код
намного быстрее, чем сможете это сделать вы.

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

‘ила  этого  эффекта  часто  не  дооцениваетсЯ.  Ќа  самом  деле   все   мы,
разработчики  мира открытых систем, сильно недооценивали насколько это может
повысить число пользователей  и  уменьшить  сложность  системы,  пока  ‹инус
’орвальдс не показал нам это.

џ  действительно  думаю, что наиболее значительное и результативное творение
‹инуса - это не создание Ядра Linux'a, а изобретение модели его  разработки.
Љогда  Я поделилсЯ с ним своим мнением, он улыбнулсЯ и просто повторил то, о
чем часто говорил:  "џ  просто  очень  ленивый  человек,  которому  нравитсЯ
получать  пользу  от  того, что делают другие люди." ‹енивый, как лиса, или,
как сказал бы ђоберт •ейнлейн, слишком ленивый чтобы проиграть.

Ћдин из успешных методов работы в стиле Linux'a  можно  было  наблюдать  при
разработке GNU Emacs Lisp - библиотеки и кода Lisp'a. ‚ отличие от соборного
стилЯ,  разработка  Ядра  Emacs ‘ , а также многих других FSF инструментов в
значительной степени управлЯлась пользователЯми. ‚се  исходные  тексты  были
преписаны три или четыре раза, прежде чем принЯли свою окончательную форму.

Њоей  первой  успешной  программой,  разработанной  в стиле Linux'a, стал VC
режим Emacs'a. џ разработал ее с тремЯ людьми, сотрудничаЯ  по  e-mail'у.  ‘
одним  из  них  (  это  ђичард  ‘толлмэн  - автор Emacs и основатель FSF ) Я
встречаюсь и по сей день. ђазработка VC была успешной, потому что в  отличие
от   Emacs,   код   Emacs   Lisp   может   быстро   пройти  через  поколениЯ
release/test/improve.

Џри попытках FSF легально встроить  код  в  GPL  обнаруживаетсЯ  неожиданный
сторонний  эффект.  €спользовать  модель  базара  длЯ  FSF  сложнее, так как
необходимо получать copyright на каждые 20 строчек кода.

        4. ‚ыпускать релизы нужно часто и рано

ђанние и частые релизы - это существеннаЯ часть модели  разработки  Linux'a.
ђаньше большинство разработчиков, включаЯ менЯ, считали, что это плохаЯ идеЯ
длЯ больших проектов. ‚ ранних версиЯх всегда очень много ошибок, и никто не
хочет чтобы пользователи потерЯли терпение.

’ак  утвердилась  разработка  в  стиле  строительства собора. „лЯ того чтобы
пользователи видели как можно меньше ошибок, вы выпускаете  релиз  не  чаще,
чем  раз  в шесть месЯцев, а остальное времЯ между релизами упорно работаете
над  отладкой.  џдро  Emacs  C  разрабатывалось  именно  таким  способом,  а
библиотека  Lisp'a  разрабатывалась  по-другому.  „ело в том, что существует
очень много архивов Lisp'a вне контролЯ FSF, где каждый  может  найти  новую
версию исходного текста, независимо от цикла релизов Emacs'a.

Ќаиболее  важный из этих архивов - архив в штате Ћгайо, перенЯл многие черты
сегоднЯшних архивов Linux'a. Џримерно в 1992 году Я сделал первую  серьезную
попытку добавить исходники этого архива в официальную Emacs Lisp библиотеку.
Њне пришлось вступить в политическую борьбу, котораЯ закончилась неудачно.

ѓодом  позже,  по мере того как Linux становилась все более распространенной
системой, стало Ясно, что хотЯ идеи разработки этой  системы  отличаютсЯ  от
традиционных, в них очень много здравого смысла. ЏроводимаЯ ‹инусом политика
открытой  разработки  была  совершенно  противоположна  стилю  строительства
собора.  ЏоЯвились  архивы  sunsite  и  tsx-11,  многочисленные  дистрибуции
Linux'a, и все это при частых релизах Ядра системы.

‹инус сотрудничал со своими пользователЯми наиболее эффективным способом.

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

€зобретение ‹инуса заключаетсЯ не только в том, что он делал (нечто  похожее
долгое  времЯ  было традицией мира UNIX'a). “дивлЯет уровень интенсивности и
сложности того, что он разрабатывал.  ‚  начале  работы  (около  1991  года)
бывали  случаи,  когда новаЯ версиЯ Ядра выходила чаще, чем один раз в день.
ќто работало, потому что ‹инус призывал своих пользователей к сотрудничеству
через €нтернет, активнее, чем кто-либо другой.

Ќо как это работало? Ѓыло ли там что-нибудь, что Я мог  повторить  или  дело
было в гениальности ‹инуса ’орвальдса?

џ  так  не  думал.  ‹инус  -  отличный  хаккер  (кто из нас сможет полностью
разработать качественное Ядро операционной системы?), но Linux  не  ЯвлЯетсЯ
принципиальным  скачком  вперед. ‹инус - это не гений разработки, такой как,
например, ђичард ‘толмен или „жеймс ѓослинг (NeWS или Java).  ‹инус  кажетсЯ
мне   скорее  гением  инженерного  мастерства,  обладающим  шестым  чувством
избегать ошибки, доводить  разработку  до  конца  и  с  минимальным  усилием
находить кратчайший путь из точки Ђ в точку ‚.

Џоставленный  таким образом вопрос отвечает сам на себЯ. ‘охранЯЯ постоЯнным
отношение числа хакеров к числу пользователей,  ‹инус  получал  и  стимул  и
вознаграждение. ‘тимул - удовлетворенность своими действиЯми, вознаграждение
- ежедневное улучшение своей работы.

‹инус  стремилсЯ  максимизировать  количество человеко-часов, затраченных на
отладку и  разработку,  даже  ценой  нестабильности,  если  какаЯ-то  ошибка
окажетсЯ трудно устранимой. ‹инус считал что:

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

€ли менее формально: "Џри достаточном количестве глаз, ошибки  выплывают  на
поверхность." џ назову это - законом ‹инуса.

Њое  собственное утверждение состоит в том, что всЯкаЯ проблема ЯвлЯетсЯ длЯ
кого-то прозрачной. Ћднако  по  мнению  ‹инуса,  человек,  который  понимает
проблему  и  находит  ее  решение, не всегда первый ее обнаруживает. "Љто-то
находит проблему", - говорит он, - "Ђ кто-то еще  ее  понимает.  €  Я  часто
замечаю,  что поиск требует наибольшего навыка." ‘уть заключаетсЯ в том, что
и то и другое должно происходить быстро.

‘ущественнаЯ разница здесь в различии соборного и базарного стилЯ.  ‘  точки
зрениЯ  соборного  стилЯ  программированиЯ,  ошибки  -  хитрые,  коварные  и
страшные ЯвлениЯ. ЊесЯцы работы, не имеющей отношениЯ к  разработке,  уходЯт
на  то,  чтобы  выловить  все  ошибки.  ’аким образом мы получаем длительные
промежутки между релизами и разочарование, когда столь  долгожданные  релизы
оказываютсЯ далеки от совершенства.

‘  другой  стороны  при  работе  в  стиле  базара,  вы  не  считаете  ошибки
непреодолимым препЯтствием. Џо крайней мере  они  покажутсЯ  такими  тысЯчам
пользователЯм,  работающим  над  каждым  новым релизом. ‚ы выпускаете релизы
часто, чтобы получить больше исправлений.

‚от и все. …сли закон ‹инуса неверен, то  при  разработке  сложной  системы,
такой  как Ядро Linux'a, многими пользователЯми, в некоторый момент времени,
система развалитсЯ из-за плохого взаимодействиЯ и  недосмотренных  серьезных
ошибках.   ‘  другой  стороны,  если  этот  закон  верен,  то  он  обљЯснЯет
отностительное отсутствие грубых ошибок.

‚озможно, это не так удивительно, как кажетсЯ. Ќесколько лет назад социологи
открыли,  что  среднее  мнение  людей,  в  равной  степени  ЯвлЯющихсЯ  либо
экспертами,  либо  дилетантами  более  верно,  чем  мнение  одного  случайно
выбранного наблюдателЯ. ќто называетсЯ "эффектом Delphi". ‹инус показал, что
это применимо даже в отладке операционной системы,  -  эффект  Delphi  может
уменьшить сложность проекта даже на уровне разработки Ядра Ћ‘.

џ  благодарен „жеффу „атки (Jeff Dutky), за то что он показал мне, как можно
перефразировать закон  ‹инуса:  "Ћтладка  может  быть  параллельной."  „жефф
считает,  что  хотЯ  во  времЯ  отладки людЯм нужно общатьсЯ друг с другом с
помощью какого-нибудь координатора-разработчика, это  не  требует  серьезной
координации   между   тестерами.  ќто  значительно  уменьшает  издержки  при
добавлении тестеров.

Ќа самом деле теоретическаЯ потерЯ эффективности от того, что  часть  работы
по  отладке  дублируетсЯ,  в мире Linux'a очень небольшаЯ. ќффект от частого
выпуска  релизов  уменьшает  вероЯтность  двойной  работы,  так  как  ошибки
фиксируютсЯ очень быстро.

Џриведем  замечание  Ѓрукса:"  ЋбщаЯ стоимость поддержки широко используемой
программы - это не меньше 40% от стоимости ее разработки." “дивительно,  что
эта  стоимость  зависит  от числа пользователей. Ѓольше пользователей найдут
больше ошибок.

Ѓольше пользователей найдут больше ошибок,  потому  что  новые  пользователи
добавлЯют  новые  способы  отладки программы. ќтот эффект усиливаетсЯ, когда
пользователи ЯвлЯютсЯ  сотрудниками.  Љаждый  из  них  подходит  к  проблеме
выЯвлениЯ  ошибок  под  своим собственным углом. ќффект Delphi в этом случае
хорошо работает.

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

Ќа  самом деле в Ядре Linux'a существуют серьезные ошибки. Ћднако, нумерациЯ
Ядра Linux'a производитсЯ  таким  образом,  что  потенциальные  пользователи
могут  выбрать:  использовать  стабильную  версию  или рискнуть и работать с
новыми  особенностЯми  последней  версии.  ќта   тактика   еще   не   совсем
поддерживаетсЯ  большинством  хаккеров Linux, хотЯ возможность выбора делает
ее привлекательной.

        5. ђоза или не ђоза?

€зучаЯ работу ‹инуса и формируЯ мою собственную теорию о том,  почему  Linux
имеет  такой  успех,  Я  решил  проверить  свои  измышлениЯ  на  моем новом,
значительно менее  сложном  проекте.  ‘начала  Я  реорганизовал  и  упростил
popclient.  ђеализациЯ  Љарла  •арриса  была  неплохой,  однако  много  ‘  -
программистов находило в ней массу сложных и ненужных  вещей.  Љод  считалсЯ
центральной  частью,  а  структуры  данных  были  просто  поддержкой кода. ‚
результате код был хорош, но дизайн структур данных  по  высоким  стандартам
хаккера, программирующего на LISP'e, был по меньшей мере ужасным.

Ћднако,  у  менЯ  была другаЯ цель, отличнаЯ от улучшениЯ кода и организации
данных. Њне было нужно полное понимание того, что Я делаю.  ‘огласитесь,  не
очень-то  здорово  отвечать за исправление ошибок в программе, которую ты не
понимаешь.

‚ течение первого месЯца, Я просто следовал дизайну  Љарла  •арриса.  Џервым
изменением,  которое  Я  сделал стала поддержка IMAP-протокола. џ реализовал
это, реорганизовав машинные протоколы в общий драйвер и три таблицы  методов
(длЯ POP2, POP3 и IMAP). ќто и предыдущие изменениЯ продемонстрировали общий
принцип,  который  следует  помнить  хорошему программисту, особенно тем кто
пользуетсЯ ‘ - подобными Языками:

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

Ѓрукс  ѓлава  9:  "…сли  вы  покажете  мне код и скроете структуры данных, Я
ничего не пойму в вашей программе. Ћднако, если вы  покажете  мне  структуры
данных,  код  скорее всего не понадобитсЯ. Ћн будет очевиден. " Џрошло шесть
месЯцев, и Я начал подумывать об изменении имени - это  был  уже  не  просто
popclient.   Ћднако,  Я  колебалсЯ,потому  что  в  дизайне  не  было  ничего
принципиально нового. „лЯ уникальности моей  версии  popclient'a  еще  очень
многого не хватало.

‚се значительно изменилось, когда fetchmail научилсЯ направлЯть почту в SMTP
порт.  Ќаступил  день,  когда  Я  пришел к этому. џ уже говорил, что Я решил
использовать этот проект длЯ проверки моей теории о том, что действиЯ ‹инуса
’орвальдса были правильными. ‚ы спросите, как Я делал это? џ использовал длЯ
этого следующие способы:

1. џ часто выпускал релизы( не реже чем каждые 10 дней, а во времЯ  периодов
интенсивной разработки каждый день.)
2.  џ  увеличил  список  бета  тестеров,  добавив  к   нему   каждого,   кто
контактировал со мной на тему fetchmail'a.
3.  Љаждый  раз  когда  Я  делал релиз, Я рассылал обљЯвлениЯ бета-тестерам,
приглашаЯ людей активно сотрудничать.
4. џ слушал своих бета-тестеров и поддерживал с ними обратную свЯзь.

ќффект от этих  простых  действий  был  незамедлительным.  ‘  самого  начала
проекта  Я  получал отчеты об ошибках, за которые разработчиков следовало бы
убить. —асто к  этим  отчетам  прилагались  элегантные  решениЯ.  џ  получал
критику,  Я  получал  интересную  почту, Я получал остроумные решениЯ. ‚от к
чему это привело:

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

Ћчень  интересно было наблюдать за увеличением списка бета-тестеров - друзей
feetchmail'a. Ќа времЯ написаниЯ в нем было 249 членов, и  каждую  неделю  к
ним добавлЯлись два-три человека.

‚  мае  1997  года  список  начал  терЯть  своих  членов по очень интересной
причине. ‹юди стали отказыватьсЯ от подписки, потому что  fetchmail  работал
длЯ них настолько хорошо, что необходимость доработки кода отпала.

        6. Popclient превращаетсЯ в Fetchmail.

‚се  решительно  изменилось,  когда  •арри  •очхейзер  принес  мне  набросок
исходного текста длЯ почты в SMTP порт клиентской машины. џ сразу понЯл, что
надежнаЯ  реализациЯ  этой  особенности  сделает  другие   режимы   доставки
практически ненужными.

ђазмышлЯЯ  об  SMTP  forwarding,  Я  понЯл, что popclient может делать очень
много вещей. џ разработал транспортного  почтового  агента  (mail  transport
agent)  и  агента  локальной доставки (local delivery agent). €спользуЯ SMTP
forwarding, от MDA можно было избавитьсЯ совсем и использовать  чистый  MTA,
доставлЯЯ почту другим программам примерно так же, как это делает sendmail.

‡ачем  нужна  всЯ  эта путаница с конфигурированием агента почтовой доставки
или с установлением на почтовый Ящик lock-and-append, если 25-ый порт  почти
навернЯка находитсЯ на каждой платформе с поддержкой TCP/IP ?

Ћтсюда  можно  извлечь  несколько  уроков. ‚о-первых идеЯ об SMTP-forwarding
была  главным  вознаграждением,  которое  Я  получил  за  то,  что   пыталсЯ
воспроизвести  методы ‹инуса. Џользователи подкинули мне эту идею и все, что
мне оставалось сделать - это понЯть выводы.

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

€нтересно, что чем больше вы сознаете, скольким вы обЯзаны другим людЯм, тем
больше людей считают, что программа написана вами от начала  до  конца.  ќто
особенно  заметно  у  ‹инуса.  (Љогда  Я  читал эту статью на конференции по
Perl'у в августе 1997 года, Larry Wall сидел на первом рЯду.  Љак  только  Я
произнес вышенаписанные строки, он воскликнул:" ‘кажи, скажи им, брат!". ‚се
в  зале  засмеЯлись,  потому  что  знали,  что он тоже работал над созданием
Perl'a.)

Џосле  нескольких  недель  работы  над  проектом  в  таком  духе,  Я   начал
чувствовать  гордость  не  только  перед  своими  пользователЯми, но и перед
остальными людьми, которые узнавали обо мне. џ снова и снова смотрел на свою
почту и удивлЯлсЯ, неужели, моЯ жизнь настолько стоЯщаЯ.

Ћднако, существуют более фундаментальные уроки, которые не имеют отношениЯ к
политике, зато имеют отношение к общему стилю разработки.

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

џ  пыталсЯ  решить  проблему,  разрабатываЯ  popclient  как  комбинированный
MTA/MDA cо  всевозможными  режимами  локальной  доставки  почты.  ђазработку
fetchmail'a требовалось пересмотреть с позиций чистого MTA.

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

€так, Я переформулировал свою проблему. Ћчевидно, что нужно было (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.

        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.

Ќекоторые  европейские  пользователи  просили  менЯ   добавить   возможность
ограничивать  число  писем  за  один  сеанс  (чтобы они могли контролировать
издержки своих дорогих телефонных сетей). џ долго сопротивлЯлсЯ этому, и  до
сих  пор  не уверен, что поступил правильно. Ћднако если вы пишете не только
длЯ себЯ, вы должны слушать ваших покупателей. Ќезависимо от того  получаете
ли вы от них деньги.


        8. Ќесколько уроков из опыта работы над fetchmail'ом.

Џрежде  чем  мы  вернемсЯ  к  общим  рекомендациЯм по разработке программ, Я
расскажу  о  нескольких  уроках,  которые  Я  вынес  из  опыта  работы   над
fetcnmail'ом.

‘интаксис  файла  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.   Џредположим,   что   ‹инус
’орвальдс  стремилсЯ  убрать  основные  изобретениЯ  в  дизайне операционных
систем, разве получили бы мы такое мощное и стабильное Ядро?

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

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

Ќеобходимость  этого  очевидна.  „лЯ  созданиЯ сообщества разработчиков, вам
необходимо как-то привлечь людей, заинтересовать их  тем,  что  вы  делаете.
’ехническаЯ  часть,  конечно,  очень  существенна,  но и ваша личность имеет
немаловажное значение.

‹инус не случайно ЯвлЯетсЯ симпатичным парнем,  который  нравитсЯ  людЯм,  и
которому  люди  с  удовольствием помогают. ’акже не ЯвлЯетсЯ совпадением то,
что Я - очень энергичный экстраверт, которому нравитсЯ работать  в  команде.
…сли  вы  знаете  как  понравитьсЯ  людЯм,  это  очень  сильно поможет вам в
разработке модели в стиле базара.

        10. ‘оциальный контекст открытых программ.

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

18.  —тобы  решить  интересную  проблему,  найдите  проблему   котораЯ   вас
заинтересует.  ќто  произошло  с Љарлом •аррисом и его родовым popclient'ом,
это произошло со мной и fetchmail'ом. ‚  этом  нет  ничего  нового