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

  • 436 views
Uploaded on

"Собор и Базар" - эссе Эрика Рэймонда на тему методов разработки программного обеспечения, основанное на анализе процесса разработки ядра Linux и личном опыте управления открытым проектом fetchmail.

"Собор и Базар" - эссе Эрика Рэймонда на тему методов разработки программного обеспечения, основанное на анализе процесса разработки ядра Linux и личном опыте управления открытым проектом fetchmail.

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
436
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Эрик С. РэймондСобор и БазарЭрик С.РэймондСобор и БазарЯ проанализировал один из успешных проектов открытойразработки – fetchmail, который я использовал, чтобы проверитьнекоторые теоретические соображения о разработке программногообеспечения, возникшие из истории Linuxa. Я обсуждаю этисоображения с позиций двух совершенно разных стилей разработки:модели «собора», распространенной в коммерческом мире, или модели«базара», предложенной в мире Linuxa. Я показал, что эти моделипроисходят от разного подхода к задаче отладки программ.1. Собор и Базар.Linux – удивительная система. Кто бы мог подумать, что несколько тысячразработчиков, разбросанных по всей планете и сотрудничающих только через Интернет,смогут создать операционную систему мирового класса. Я во всяком случае так не думал. Ктому времени как Linux оказалась в поле моего зрения в начале 1993 года, я уже около десятилет участвовал в разработке UNIXa и открытых программ. Я был одним из первых участниковGNU в середине 80-х. Я был автором многих открытых программ, и в частности участвовал вразработке nethack, Emacs VC и GUD modes, xlife, которые широко используются и по сейдень. Я думал, что я знаю, как это делается.Linux перевернула мои представления о том, что я знаю. Я считал, что основным вразработке небольших инструментов для UNIXa является их быстрое проектирование иэволюционирующее программирование в течение многих лет. И в то же время я верил, что помере того как сложность разработки увеличивается, необходим более централизованныйподход. Я верил, что разработка самого сложного программного обеспечения (например,операционных систем или просто больших инструментов, таких как Emacs) должна бытьподобна строительству собора. Такие программы должны создаватьсямастерами-индивидуалистами или небольшими группами волшебников, работающими встрогой изоляции, не допуская преждевременных бета-версий.Меня очень удивил стиль разработки Линуса Торвальдса – частый выпуск релизов,доступность всех исходных текстов и терпимость к разнородным программам. Это совсемнепохоже на размеренное строительство собора, сообщество Linux скорее напоминаетшумный базар, с множеством различных подходов и направлений. То, что на этом базарерождается согласованная стабильная операционная система, кажется чудом из чудес.Меня потрясло, что этот базарный стиль работает и работает хорошо. Я не толькоучаствовал в разработке индивидуальных проектов, но также пытался понять, почему в миреLinuxa не только не возникает беспорядка, но напротив он движется вперед со скоростью,которой строители собора могут только позавидовать.К середине 1996 года мне показалось, что я начал понимать. Судьба предоставила мнепрекрасный шанс проверить мою теорию. Это был проект разработки открытого пгораммногообеспечения, который я сознательно провел в базарном стиле. Успех этого проекта превзошелвсе ожидания.В этой статье я расскажу вам историю этого проекта, и на его примере покажу несколько
  • 2. правил эффективной разработки свободного программного обеспечения.Не все эти приемы я узнал из мира Linuxa, но если я прав, они помогут понять, почемусообщество Linuxa производит столько полезных программ и помогут вам повыситьпроизводительность.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 утилиту, чтобыиспользовать ее как основу для разработки.
  • 3. В мире UNIXa всегда существовала традиция делать исходные тексты открытыми идружественными к повторному использованию кода. Именно поэтому проект GNU выбралUNIX как основную операционную систему. Мир Linuxa полностью перенял эту традицию.Здесь вы можете найти терабайты исходных текстов, и поэтому шансов найти что-нибудьподходящее в мире Linuxa выше, чем где бы то ни было.Мне это подошло. Вместе с теми программами, которые я нашел раньше, у меняоказались девять кандидатов: fetchpop, PopTart, get-mail, gwpop, pimp, popperl, popc, popmail иupop. Сначала я остановился на fetchpop, автором которой является Seung-Hong Oh. Я добавилтуда мою процедуру переписывания заголовка и другие возможности, которые автор принял вверсии 1.9 Несколькими неделями позже я наткнулся на код popclient – программу,написанную Карлом Харрисом – и обнаружил одну проблему. Хотя у fetchpop былиоригинальные идеи (например, режим демона), но написан он был любителем. Код Карла былзначительно профессиональнее, но его программе недоставало несколько важныхвозможностей, в том числе и тех, которые я реализовал для fetchpopa.Что делать? Оставить все как есть или начать заново? Если бы я начал заново мнепришлось бы пожертвовать своими программами ради более надежной основы дляразработки.Самым существенным поводом для того чтобы начать заново, была поддержканескольких протоколов. POP3 один из наиболее часто используемых post-office протоколовсервера, однако он далеко не единственный. Fetchpop и другие подобные программы неиспользуют POP2, RPOP или APOP, а у меня уже появилась мысль использовать IMAP –недавно разработанный, очень мощный post – office протокол.3. «Даже если вы не планировали выбрасывать первую версию; выбрасывая ее, вы всеравно выигрываете.» (Фред Брукс «The Mythical Man-Month», глава 11) Другими словами,когда вы первый раз реализуете какоелибо решение, вы часто не понимаете проблему доконца. Во второй раз вы уже набираете достаточно знаний, чтобы сделать это правильно.Итак, если вы хотите написать что-нибудь стоящее, лучше хотя бы один раз начать все заново.Я сказал себе, что изменения в fetchpop были моей первой попыткой. Итак, я решилначать все заново. 25 июня я послал набор программ для popclienta Карлу Харрису иобнаружил, что он практически потерял интерес к этой работе. Код был не очень аккуратный,и содержал несколько ошибок. Мне пришлось сделать много изменений, и мы согласились,что мне следует стать владельцем программы.Я и не замеитл, как проект начал расширяться. Я больше не писал программы,дополняющие popclient. Я стал работать с целой программой. В моей голове уже кипели идеио глобальных изменениях.Если культура программирования приветствует разделение исходных текстов, то этосамый естественный способ развития проекта. Я руководствовался следующим:4. При правильном отношении интересная проблема найдет вас сама.Отношение Карла Харриса больше не имело значения. Он понял, что:5. Когда вы теряете интерес к программе, ваша последняя обязанность передать еекомпетентному преемнику.Карл и я знали, что наша общая цель – поиск наилучшего решения. Мне нужно былотолько доказать свою компетентность. Как только я это сделал, он быстро предал мне всеполномочия. Надеюсь, что когда-нибудь я поступлю также.3. Как важно иметь пользователейИтак я унаследовал popclient. Но гораздо важнее то, что я унаследовал пользователейpopclienta. Иметь пользователей – это замечательно. Не только потому что это означает, чтовы предоставляете нужную услугу. Дело в том, что правильно воспитанные пользователимогут стать сотрудниками.Сильная традиция Unixа, а особенно Linuxa заключается в том, что большинство
  • 4. пользователей являются хакерами. Так как исходный текст программ доступен, они могутстать эффективными хакерами. Это может значительно уменьшить время отладки. Если высможете воодушевить пользователей, они будут диагностировать проблемы, предлагатьрешения и помогать улучшить код намного быстрее, чем сможете это сделать вы.6. Если пользователи будут вашими сотрудниками, то вам обеспечены улучшение кода иэффективная отладка.Сила этого эффекта часто не дооценивается. На самом деле все мы, разработчики мираоткрытых систем, сильно недооценивали насколько это может повысить число пользователейи уменьшить сложность системы, пока Линус Торвальдс не показал нам это.Я действительно думаю, что наиболее значительное и результативное творение Линуса –это не создание ядра Linuxa, а изобретение модели его разработки.Когда я поделился с ним своим мнением, он улыбнулся и просто повторил то, о чемчасто говорил: «Я просто очень ленивый человек, которому нравится получать пользу от того,что делают другие люди.» Ленивый, как лиса, или, как сказал бы Роберт Хейнлейн, слишкомленивый чтобы проиграть.Один из успешных методов работы в стиле Linuxa можно было наблюдать приразработке GNU Emacs Lisp – библиотеки и кода Lispa. В отличие от соборного стиля,разработка ядра Emacs С, а также многих других FSF инструментов в значительной степениуправлялась пользователями. Все исходные тексты были преписаны три или четыре раза,прежде чем приняли свою окончательную форму.Моей первой успешной программой, разработанной в стиле Linuxa, стал VC режимEmacsa. Я разработал ее с тремя людьми, сотрудничая по e-mailу. С одним из них (это РичардСтоллмэн – автор Emacs и основатель FSF) я встречаюсь и по сей день. Разработка VC былауспешной, потому что в отличие от Emacs, код Emacs Lisp может быстро пройти черезпоколения release/test/improve.При попытках FSF легально встроить код в GPL обнаруживается неожиданныйсторонний эффект. Использовать модель базара для FSF сложнее, так как необходимополучать copyright на каждые 20 строчек кода.4. Выпускать релизы нужно часто и раноРанние и частые релизы – это существенная часть модели разработки Linuxa.Раньше большинство разработчиков, включая меня, считали, что это плохая идея длябольших проектов. В ранних версиях всегда очень много ошибок, и никто не хочет чтобыпользователи потеряли терпение.Так утвердилась разработка в стиле строительства собора. Для того чтобы пользователивидели как можно меньше ошибок, вы выпускаете релиз не чаще, чем раз в шесть месяцев, аостальное время между релизами упорно работаете над отладкой. Ядро Emacs Cразрабатывалось именно таким способом, а библиотека Lispa разрабатывалась по-другому.Дело в том, что существует очень много архивов Lispa вне контроля FSF, где каждый можетнайти новую версию исходного текста, независимо от цикла релизов Emacsa.Наиболее важный из этих архивов – архив в штате Огайо, перенял многие чертысегодняшних архивов Linuxa. Примерно в 1992 году я сделал первую серьезную попыткудобавить исходники этого архива в официальную Emacs Lisp библиотеку.Мне пришлось вступить в политическую борьбу, которая закончилась неудачно.Годом позже, по мере того как Linux становилась все более распространенной системой,стало ясно, что хотя идеи разработки этой системы отличаются от традиционных, в них оченьмного здравого смысла. Проводимая Линусом политика открытой разработки быласовершенно противоположна стилю строительства собора. Появились архивы sunsite и tsx-11,многочисленные дистрибуции Linuxa, и все это при частых релизах ядра системы.Линус сотрудничал со своими пользователями наиболее эффективным способом.7. Выпускайте ранние релизы. выпускайте частые релизы. Слушайте своих
  • 5. пользователей.Изобретение Линуса заключается не только в том, что он делал (нечто похожее долгоевремя было традицией мира UNIXa). Удивляет уровень интенсивности и сложности того, чтоон разрабатывал. В начале работы (около 1991 года) бывали случаи, когда новая версия ядравыходила чаще, чем один раз в день.Это работало, потому что Линус призывал своих пользователей к сотрудничеству черезИнтернет, активнее, чем кто-либо другой.Но как это работало? Было ли там что-нибудь, что я мог повторить или дело было вгениальности Линуса Торвальдса?Я так не думал. Линус – отличный хаккер (кто из нас сможет полностью разработатькачественное ядро операционной системы?), но Linux не является принципиальным скачкомвперед. Линус – это не гений разработки, такой как, например, Ричард Столмен или ДжеймсГослинг (NeWS или Java). Линус кажется мне скорее гением инженерного мастерства,обладающим шестым чувством избегать ошибки, доводить разработку до конца и сминимальным усилием находить кратчайший путь из точки А в точку В.Поставленный таким образом вопрос отвечает сам на себя. Сохраняя постояннымотношение числа хакеров к числу пользователей, Линус получал и стимул и вознаграждение.Стимул – удовлетворенность своими действиями, вознаграждение – ежедневное улучшениесвоей работы.Линус стремился максимизировать количество человеко-часов, затраченных на отладкуи разработку, даже ценой нестабильности, если какая-то ошибка окажется трудно устранимой.Линус считал что:8. При достаточном количестве бета-тестеров и сотрудников, почти любая проблемабудет быстро обнаружена и окажется для кого-то очевидной.Или менее формально: «При достаточном количестве глаз, ошибки выплывают наповерхность.» Я назову это – законом Линуса.Мое собственное утверждение состоит в том, что всякая проблема является для кого-топрозрачной. Однако по мнению Линуса, человек, который понимает проблему и находит еерешение, не всегда первый ее обнаруживает. «Кто-то находит проблему», – говорит он, – «Акто-то еще ее понимает. И я часто замечаю, что поиск требует наибольшего навыка.» Сутьзаключается в том, что и то и другое должно происходить быстро.Существенная разница здесь в различии соборного и базарного стиля. С точки зрениясоборного стиля программирования, ошибки – хитрые, коварные и страшные явления.Месяцы работы, не имеющей отношения к разработке, уходят на то, чтобы выловить всеошибки. Таким образом мы получаем длительные промежутки между релизами иразочарование, когда столь долгожданные релизы оказываются далеки от совершенства.С другой стороны при работе в стиле базара, вы не считаете ошибки непреодолимымпрепятствием. По крайней мере они покажутся такими тысячам пользователям, работающимнад каждым новым релизом. Вы выпускаете релизы часто, чтобы получить большеисправлений.Вот и все. Если закон Линуса неверен, то при разработке сложной системы, такой какядро Linuxa, многими пользователями, в некоторый момент времени, система развалитсяиз-за плохого взаимодействия и недосмотренных серьезных ошибках. С другой стороны, еслиэтот закон верен, то он обЪясняет отностительное отсутствие грубых ошибок.Возможно, это не так удивительно, как кажется. Несколько лет назад социологиоткрыли, что среднее мнение людей, в равной степени являющихся либо экспертами, либодилетантами более верно, чем мнение одного случайно выбранного наблюдателя. Этоназывается «эффектом Delphi». Линус показал, что это применимо даже в отладкеоперационной системы, – эффект Delphi может уменьшить сложность проекта даже на уровнеразработки ядра ОС.Я благодарен Джеффу Датки (Jeff Dutky), за то что он показал мне, как можноперефразировать закон Линуса: «Отладка может быть параллельной.» Джефф считает, что
  • 6. хотя во время отладки людям нужно общаться друг с другом с помощью какого-нибудькоординатора-разработчика, это не требует серьезной координации между тестерами. Этозначительно уменьшает издержки при добавлении тестеров.На самом деле теоретическая потеря эффективности от того, что часть работы по отладкедублируется, в мире Linuxa очень небольшая. Эффект от частого выпуска релизов уменьшаетвероятность двойной работы, так как ошибки фиксируются очень быстро.Приведем замечание Брукса:" Общая стоимость поддержки широко используемойпрограммы – это не меньше 40% от стоимости ее разработки." Удивительно, что эта стоимостьзависит от числа пользователей. Больше пользователей найдут больше ошибок.Больше пользователей найдут больше ошибок, потому что новые пользователидобавляют новые способы отладки программы. Этот эффект усиливается, когда пользователиявляются сотрудниками. Каждый из них подходит к проблеме выявления ошибок под своимсобственным углом. Эффект Delphi в этом случае хорошо работает.Итак, если мы добавляем больше бета-тестеров, то с точки зрения разработчиков, мы неувеличиваем сложность возможной серьезной ошибки, но увеличиваем вероятность, чтокто-то эту ошибку обнаружит, и для него она окажется прозрачной.На самом деле в ядре Linuxa существуют серьезные ошибки. Однако, нумерация ядраLinuxa производится таким образом, что потенциальные пользователи могут выбрать:использовать стабильную версию или рискнуть и работать с новыми особенностямипоследней версии. Эта тактика еще не совсем поддерживается большинством хаккеров Linux,хотя возможность выбора делает ее привлекательной.5. Роза или не Роза?Изучая работу Линуса и формируя мою собственную теорию о том, почему Linux имееттакой успех, я решил проверить свои измышления на моем новом, значительно менее сложномпроекте. Сначала я реорганизовал и упростил popclient. Реализация Карла Харриса быланеплохой, однако много С – программистов находило в ней массу сложных и ненужныхвещей. Код считался центральной частью, а структуры данных были просто поддержкой кода.В результате код был хорош, но дизайн структур данных по высоким стандартам хаккера,программирующего на LISPe, был по меньшей мере ужасным.Однако, у меня была другая цель, отличная от улучшения кода и организации данных.Мне было нужно полное понимание того, что я делаю. Согласитесь, не очень-то здоровоотвечать за исправление ошибок в программе, которую ты не понимаешь.В течение первого месяца, я просто следовал дизайну Карла Харриса. Первымизменением, которое я сделал стала поддержка IMAP-протокола. Я реализовал это,реорганизовав машинные протоколы в общий драйвер и три таблицы методов (для POP2,POP3 и IMAP). Это и предыдущие изменения продемонстрировали общий принцип, которыйследует помнить хорошему программисту, особенно тем кто пользуется С – подобнымиязыками:9. Хорошие структуры данных и плохой код работают несколько лучше, чем хорошийкод и плохие данные.Брукс Глава 9: "Если вы покажете мне код и скроете структуры данных, я ничего непойму в вашей программе. Однако, если вы покажете мне структуры данных, код скорее всегоне понадобится. Он будет очевиден. " Прошло шесть месяцев, и я начал подумывать обизменении имени – это был уже не просто popclient. Однако, я колебался,потому что в дизайнене было ничего принципиально нового. Для уникальности моей версии popclienta еще оченьмногого не хватало.Все значительно изменилось, когда fetchmail научился направлять почту в SMTP порт.Наступил день, когда я пришел к этому. Я уже говорил, что я решил использовать этот проектдля проверки моей теории о том, что действия Линуса Торвальдса были правильными. Выспросите, как я делал это? Я использовал для этого следующие способы:
  • 7. 1 – Я часто выпускал релизы(не реже чем каждые 10 дней, а во время периодовинтенсивной разработки каждый день.)2 – Я увеличил список бета тестеров, добавив к нему каждого, кто контактировал сомной на тему fetchmaila.3 – Каждый раз когда я делал релиз, я рассылал обЪявления бета-тестерам, приглашаялюдей активно сотрудничать.4 – Я слушал своих бета-тестеров и поддерживал с ними обратную связь.Эффект от этих простых действий был незамедлительным. С самого начала проекта яполучал отчеты об ошибках, за которые разработчиков следовало бы убить. Часто к этимотчетам прилагались элегантные решения. Я получал критику, я получал интересную почту, яполучал остроумные решения. Вот к чему это привело:10. Если вы относитесь к вашим бета-тестерам как к самому ценному ресурсу, оченьскоро они станут вашим самым ценным ресурсом.Очень интересно было наблюдать за увеличением списка бета-тестеров – друзейfeetchmaila. На время написания в нем было 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 сидел на первом ряду. Как только я произнес вышенаписанные строки, онвоскликнул:" Скажи, скажи им, брат!". Все в зале засмеялись, потому что знали, что он тожеработал над созданием Perla.) После нескольких недель работы над проектом в таком духе, яначал чувствовать гордость не только перед своими пользователями, но и перед остальнымилюдьми, которые узнавали обо мне. Я снова и снова смотрел на свою почту и удивлялся,неужели, моя жизнь настолько стоящая.Однако, существуют более фундаментальные уроки, которые не имеют отношения кполитике, зато имеют отношение к общему стилю разработки.12. Часто самые удивительные решения приходят от понимая того, что постановказадачи была неправильной.Я пытался решить проблему, разрабатывая popclient как комбинированный MTA/MDA
  • 8. cо всевозможными режимами локальной доставки почты. Разработку fetchmaila требовалосьпересмотреть с позиций чистого MTA.Когда во время разработки программы вы натыкаетесь на препятствие, когда вамприходится серьезно размышлять над следующим шагом, самое время подумать: но не надтем правильный ли вы получили ответ, а над тем правильный ли вы поставили вопрос.Возможно задачу следует переформулировать.Итак, я переформулировал свою проблему. Очевидно, что нужно было (1)добавитьподдержку SMTP forwarding в родовой драйвер,(2) сделать это режимом по умолчанию,(3)выбросить все остальные режимы доставки, особенно возможности доставки в файл идоставки в стандартный выходной поток.Некоторе время я не решался делать шаг 3, чтобы не подводить пользователей,зависящих от альтернативных методов доставки. Теоретически, чтобы получить тот же самыйэффект они могли переключиться на использование.forward файлов или их не sendmailовскиеэквиваленты. Практически, такой переход мог вызвать проблемы.Однако, когда я решился на этот шаг, он принес много пользы. Значительная часть кодадрайвера исчезла, конфигурация заметно упростилась,стало не нужно заботиться об MDA,пользовательском mailboxe, поддержке блокировки файлов операционной системой.К тому же исчез единственный способ потерять почту. Если у вас определена доставкапочты в файл, а диск оказывается переполненным, то почту вы теряете. Это не можетслучиться при SMTP forwarding, так как SMTP listener не вернет OK, до тех пор покасообщение не будет доставлено или отложено для более поздней доставки.Также улучшилась производительность (хотя при единичном запуске вы бы этого незаметили). Другое незначительное улучшение заключалось в том, что справочная система(manual page) стала короче.Позже, мне пришлось добавить доставку через локальный MDA определенныйпользователем, для того чтобы справиться с некоторыми ситуациями связанными сдинамическим SLIPом. Однако, я нашел для этого более простой способ.Какой же из этого можно сделать вывод? Не колебайтесь выбрасывать устаревшиеособенности, если вы можете сделать это без потери эффективности. Антуан де Сент–Экзюпери – человек, который был летчиком и авиаконструктором, сказал:13. Совершенство в разработке достигается не тогда, когда нечего добавить, а тогдакогда нечего убрать.Если ваш код становится одновременно и лучше и проще, вы поступаете правильно. Впроцессе разработки fetchmail приобрел свое собственное лицо, отличное от старогоpopclienta.Наступило время для смены имени. Новый дизайн больше походил на двойственныйsendmail, чем старый popclient. Итак, через два месяца я переименовал его в fetchmail.7. Fetchmail расширяется.В работе над этой программой я использовал много изящных нововведений.Программа работала хорошо, потому что я использовал ее каждый день, и частоприслушивался к моим бета-тестерам. Я вдруг осознал, что это не просто тривиальнаяхаккерская задача, которая может быть полезна разве лишь нескольким людям. У меня былапрограмма нужная каждому хаккеру, имеющему UNIX-машину и SLIP/PPP соединение.Благодаря использованию SMPT-forwarding, эта программа могла бы стать «убийцейкатегории», т. е. программой, которая настолько плотно заполняет свою нишу,что всеостальные оказываются просто забытыми.Я думаю, что нельзя запланировать такой результат заранее. Обычно в разработку васвтягивают настолько мощные идеи, что результаты кажутся естественными и неизбежными.Единственный способ найти такую идею – это постоянно иметь множество всяких своихсобственных идей, или обладать талантом заимствовать хорошие идеи у других людей,
  • 9. прежде чем они их осознают.У Эндрю Таненбаума была идея построить простую 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%
  • 10. избыточных конструкций.Для меня это не является причиной, чтобы избегать синтаксиса естественного языка.Дешевое исполнение инструкций и краткость не должны стать конечной целью. В первуюочередь язык должен быть удобным для людей, а не дешевым для компьютеров.Существуют еще несколько поводов для беспокойства. Во-первых, нежелательно, чтобывозросшая стоимость синтаксического анализа, стала сама по себе источником ошибок.Во-вторых, при попытке сделать язык «англоподобным», часто требуется, чтобы«английский» потерял свою форму настолько, чтобы он походил на естественный язык, небольше, чем традиционный синтаксис. (Это можно часто видеть в языках запросов«четвертого поколения» и языках коммерческих баз данных.) В управляющих конструкцияхfetchmaila этих проблем удалось избежать, так как область действия языка сильно ограничена.Он практически не является общецелевым языком,и поэтому несложно перейти отнебольшого подмножества английского языка к действительному языку управления. Отсюдаможно извлечь еще один урок:16. Если ваш язык не является полным по Тьюрингу, добавьте немного синтаксическогосахара.Другой урок касается безопасности. Некоторые пользователи fetchmaila просили меняизменить программу так, чтобы она хранила зашифрованные пароли в файле rc.Я не сделал этого, потому что это не добавляет никакой защиты. Любой человек,имеющий право читать ваш файл, мог бы запустить fetchmail под вашим именем и, возможно,декодировать ваш пароль. Шифрование пароля в .fetchmailrc могло бы дать людям ложноечувство защищенности. Общее правило здесь следующее:17. Система безопасности надежна, пока надежны ее секреты. Избегайтепсевдо-секретов.9. Необходимые условия для модели базара.Читатели ранних версий этой статьи обязательно поднимали вопрос о необходимыхусловиях для разработки проекта в стиле базара, Здесь обычно рассматривали квалификациюлидера проекта и состояние системы на момент, когда принимается решение опубликоватьисходные тексты и создать сообщество сотрудничающих разработчиков.Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можнотестировать, отлаживать и улучшать программы, работая в стиле базара, но начать проекточень трудно, Ни я, ни Линус даже не пытались это сделать.Вашему сообществу разработчиков нужно что-то, что можно отлаживать и тестировать.Когда вы начинаете создавать сотрудничающее сообщество, вам необходимыубеждающие доводы. Ваша программа может не всегда правильно работать. Она может бытьнеполной, содержать ошибки или иметь плохую документацию. Однако, она должнаобязательно убедить потенциальных сотрудников, в том что их собираются вовлечь в нечтостоящее.Linux и fetchmail были представлены публике как программы, имеющие строгую основу.Многие люди, когда-либо размышлявшие о модели базара, поначалу относились к этомуутвверждению критически. Однако позже почти все они приходили к мнению, что лидерупроекта крайне важно иметь высокую квалификацию и интуицию разработчика.Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я жепозаимствовал их у родового popmaila (хотя мне пришлось переделывать значительнобольше, чем Линусу). Так ли уж необходим координатору исключительный талантразработчика или он может использовать чужие идеи?По-моему не очень существенно, способен ли координатор на оригинальный дизайн.Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хорошийдизайн от всех остальных.И Linux, и fetchmail показали очевидность этого утверждения. Линус – отличный
  • 11. разработчик, который к тому же показал свое умение распознавать хороший дизайн ивстраиваить его в ядро Linux. А я, в свою очередь, уже описывал, как единственная наиболеемощная идея в разработке fetchmail (SMTP forwarding) была получена со стороны.Прежние читатели этой статьи отмечали, что я склонен недооценивать первоначальныйдизайн в проектах базара, так как сам я отлично с ним справляюсь, и, поэтому принимаю этокак должное. Возможно, в этом есть доля правды, дизайн, в отличие от кодирования иотладки, – мой конек.Проблема первоначального дизайна заключается в том, что вы начинаете проект,усложняя себе задачу, в то время как следует оставлять ее простой и понятной. Некоторые моипроекты проваливались из-за того, что я совершал эту ошибку, и поэтому я старался недопустить ее при разработке fetchmail.Итак, я уверен, что fetchmail удался, потому что я ограничил свою изобретательность.Давайте рассмотрим Linux. Предположим, что Линус Торвальдс стремился убрать основныеизобретения в дизайне операционных систем, разве получили бы мы такое мощное истабильное ядро?Конечно, определенные знания в области дизайна, а также навык кодированиянеобходимы, но мне кажется, что каждый, кто всерьез думает о такой разработке, превосходяттребуемый минмиум. Репутация внутреннего рынка открытых программ оказывает давление,которое предостерегает недостаточно компетентных людей.Существует другое важное качество, не менее важное для успеха проекта в стиле базара.Координатор такого проекта должен иметь хороший опыт общения с людьми.Необходимость этого очевидна. Для создания сообщества разработчиков, вамнеобходимо как-то привлечь людей, заинтересовать их тем, что вы делаете.Техническая часть, конечно, очень существенна, но и ваша личность имеетнемаловажное значение.Линус не случайно является симпатичным парнем, который нравится людям, и которомулюди с удовольствием помогают. Также не является совпадением то, что я – очень энергичныйэкстраверт, которому нравится работать в команде.Если вы знаете как понравиться людям, это очень сильно поможет вам в разработкемодели в стиле базара.10. Социальный контекст открытых программ.Верно сказано: лучшие программы начинаются с решения проблем автора, с которымион сталкивается каждый день, и расширяются, потому что эти проблемы оказываютсятипичными для большого класса пользователей. Это возвращает нас к первому правилу,которое можно сформулировать более точно:18. Чтобы решить интересную проблему, найдите проблему которая вас заинтересует.Это произошло с Карлом Харрисом и его родовым popclientом, это произошло со мной иfetchmailом. В этом нет ничего нового, гораздо интереснее другое. История с Linuxом иfetchmailом указывает на следующую стадию в эволюции программного обеспечения –активное сообщество пользователей и разработчиков.В «The Mythical Man-Month» Фред Брукс рассматривал различные зависимости времениразработки. Он показывает, что сложность проекта и его коммуникационные издержкиквадратично зависят от числа разработчиков, в то время как проделанная работа зависиттолько линейно. Это утверждение называется «закон Брукса», и большинство признает егоправильным. Однако, если бы дело было только в законе Брукса, Linux не мог бысуществовать.Пять месяцев назад, Джеральд Венберг в «Психологии программирования» предложилтеорию, которую мы можем рассматривать, как жизненную поправку к закону Брукса.Обсуждая «неэгоистичное программирование» (egoless programming), Венберг замечает, чтоесли разработчики не являются безраздельными владельцами исходников программ и
  • 12. приветствуют, когда другие люди помогают искать ошибки и предлагают различныеулучшния, программа прогрессирует намного быстрее.Возможно, терминология Венберга не способствует тому, чтобы его утвержденияприняли. Многие люди улыбаются при описании хакеров Интернет как «неэгоистичных».Однако, я думаю, что его аргументы лучше всего соответствуют сегодняшней ситуации.История UNIX подготовила нас к тому, что мы узнали от Linux (и тому, что я проверилна небольшом проекте, копируя методы Linuxa). В то время как кодирование является восновном индивидуальной деятельностью, гениальные хаккерские решения приходят от всегосообщества. Разработчик, который работает в замкнутом проекте и пользуется только своейголовой, уступает разработчику, создающему открытый проект, в котором участвуют сотнилюдей, занятых поиском ошибок и предлагающих различные улучшения.Однако, в традиционном мире UNIX этот подход не является единственным. Одна изпричин – это коммерческие и торговые секреты, ограничения различных лицензий и т. д.Другая причина заключается в том, что Интернет недостаточно хорошее средство общения.Прежде чем появилась дешевая связь через Интернет, существовало несколькогеографически компактных сообществ, традиции которых поощряли «неэгоистичноепрограммирование», и разработчики сотрудничали друг с другом. Bell Labs, MIT AI Lab, UCBerkely стали родиной легендарных и до сих пор мощных изобретений.Linux – это первый проект, который пытался собрать таланты по всему миру. Я думаю,что период зарождения Linux неслучайно совпал с появлением World Wide Web. Линус былпервым, кто понял, как играть по новым правилам, которые стали возможными благодаряИнтернет.Дешевый Интернет является необходимым условием для развития модели Linux, но, какмне кажется, недостаточным. Другие жизненные факторы – это стиль руководства итрадиции, побуждающие разработчиков искать сотрудников для достижения максимальногоэффекта.Что же это за стиль руководства и каковы эти традиции? Они не могут быть основаны напринуждении, потому что тогда бы мы не получили таких результатов.Ранее я ссылался на эффект Delphi, как возможное обЪяснение закона Линуса.Также для этого безупречно подходят аналогии с адаптивными системами в биологии иэкономике. Мир Linux во многих отношениях ведет себя как свободный рынок или какэкологическая система. Это похоже на множество заинтересованных агентов, которыепытаются максимизировать полезность. В конечном итоге система, где эти агенты действуютнезависимо, оказывается более эффективной, чем та, в которой происходит централизованноепланирование.Функция полезности, которую максимизируют хаккеры Linux, не является классическойдля экономики. Она зависит от их самоудовлетворения и репутации среди другиххаккеров.(Можно было бы назвать их мотивацию альтруистической, однако альтруизм сам посебе является средством самоудовлетворения альтруиста.) Добровольные сообщества,работающие по этому принципу встречаются довольно часто. Я долгое время участвовал всообществе любителей научной фантастики, которое, в отличие от сообщества хаккеров,признает «egoboo» – улучшение репутации среди других фанатов – как единственнуюдвижущую силу добровольной работы.Можно рассматривать метод Линуса, как способ создать эффективный «egoboo» рынок.То есть соединить заинтересованность отдельных хаккеров и задачу, которая может бытьрешена только в сообществе. В проекте fetchmail я показал (в меньшем масштабе), что этиметоды могут давать хорошие результаты.Возможно, я даже сделал это более систематически.Многие люди (особенно те, которые не доверяют свободным рынкам по политическимпричинам) ожидают, что подобное сообщество эгоистов будет расточительно, скрытно ивраждебно настроено. Однако эти ожидания обманываются, что подтверждается одним яркимприером. Этот пример – ошеломляющее разнообразие, качество и глубина документации
  • 13. Linux. Известно, что программисты ненавидят писать документацию. Почему же тогдадокументация Linux столь обширна? Очевидно, что в этом случае свободный рынок Linuxработает эффективнее, чем производители коммерческих программ.Fetchmail и Linux показали, что опытный координатор может использовать Интернет длясвязи между разработчиками, не опасаясь, что проект превратится в хаос. Поэтому законуБрукса можно противопоставить следующее: 19. Если у координатора разработки естьсредство связи, по меньшей мере такое как Интернет, и он умеет лидировать без принуждения,то лучше пользоваться несколькими головами, чем одной.Я думаю, что будущее свободного программного обеспечения принадлежит людям,которые знают как играть в игру Линуса, которые оставляют стиль собора и разрабатываютпроекты в стиле базара. Это не означает, что индивидуальность не играет больше никакойроли. Наоборот, впереди окажутся те, кто начинал с индвидуального мастерств, а потомрасширил его через эффективное создание добровольных сообществ.Возможно, это будущее не только свободных программ. Ни один разработчиккоммерческих программ не сможет сравниться с сообществом Linux в решении проблемы.Немногие смогут нанять двести человек, которые участвовали в разработке fetchmail.Вероятно, в конце концов свободное программное обеспечение победит, не толькопотому что кооперация правильна с точки зрения морали, но просто потому, чтокоммерческий мир не сможет состязаться с сообществами free-software, которые могутбросить гораздо большие силы на решение одной проблемы.11. БлагодарностиЭта статья была значительно улучшена, благодаря тому что очень многие людиучаствовали в ее обсуждении. Особенно я благодарен Джеффу Датки dutky@wam.umd.edu, зато что предложил формулировку «отладка может быть параллельной» («debugging isparallelizable») и помог ее проанализировать.Также я благодарен Нэнси Лебовитц nancy@universe.digex.net. Много конструктивнойкритики поступало от Джоан Эслингер wombat@kilimanjaro.engr.sgi.com и Марти Францmarty@net-link.net из General Technics. Пол Эггерт eggert@twinsun.com отметил конфликтмежду GPL и моделью базара. Я благодарен членам PLUG, группы Philadelphia Linux Users затестирование первой публичной версии этой статьи. И, конечно, мне очень помогликомментарии Линуса Торвальдса.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:GoodNews, 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 приветствует Базар!
  • 14. Очень странно осознавать, что ты помогал вершиться Истории… 22 января 1998 года,приблизительно через семь месяцев после того как я впервые опубликовал эту статью,Netscape Communications, Inc. обЪявила о своих планах сделать открытыми исходные текстыNetscape Communicator.Однако, я и представить себе не мог, что предшествовало этому обЪявлению.Эрик Ханн, исполнительный вице-президент и глава технологического отдела Netscapeaнаписал мне: «От имени всех членов корпорации, я хочу поблагодарить Вас за то, что выпомогли нам понять эту проблему. Ваши убеждения и ваши статьи оказались наиболеевескими доводами в пользу принятия этого решения.» На следующей неделе я вылетел вSilicon Valley для однодневной стратегической конференции с исполнительными итехническими сотрудниками Netscapea. Мы вместе разработали лицензию и стратегиювыпусков релизов исходников Netscapea, а также составили планы по внесениюположительных вкладов в open-source сообщество. Еще рано слишком углубляться в детали,но где-нибудь через несколько недель мы получим подробности.Netscape готов к тому, чтобы проверить модель Базара на настоящем полномасштабномпроекте, взятом из коммерческого мира. Для мира открытых систем это предсттавляетопасность: ведь если проект Netscapea не будет работать, то концепция 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 Я изменил слова «freesoftware» на «open source» 9 февраля 1998 года в версии 1.27 Я добавил «13. Эпилог: Netscapeприветствует Базар!» 10 февраля 1997 года в версию 1.31 Остальные изменения содержатнебольшие редакторские исправления.Обращений с начала месяца: 54, Last-modified: Thu, 14 Jan 1999 13:25:29 GMT