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 производит столько полезных программ и помогут вам повысить производительность.

      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, popperl, 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.Когда вы теряете интерес к программе, ваша последняя обязанность передать ее компетентному преемнику.
      Карл и я знали, что наша общая цель – поиск наилучшего решения. Мне нужно было только доказать свою компетентность. Как только я это сделал, он быстро предал мне все полномочия. Надеюсь, что когда-нибудь я поступлю также.

      Итак я унаследовал 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 строчек кода.

      Ранние и частые релизы – это существенная часть модели разработки 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, хотя возможность выбора делает ее привлекательной.

      Изучая работу Линуса и формируя мою собственную теорию о том, почему 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 работал для них настолько хорошо, что необходимость доработки кода отпала.

      Все решительно изменилось, когда Харри Хочхейзер принес мне набросок исходного текста для почты в 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.

      В работе над этой программой я использовал много изящных нововведений.
      Программа работала хорошо, потому что я использовал ее каждый день, и часто прислушивался к моим бета-тестерам. Я вдруг осознал, что это не просто тривиальная хаккерская задача, которая может быть полезна разве лишь нескольким людям. У меня была программа нужная каждому хаккеру, имеющему 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.
      Некоторые европейские пользователи просили меня добавить возможность ограничивать число писем за один сеанс (чтобы они могли контролировать издержки своих дорогих телефонных сетей). Я долго сопротивлялся этому, и до сих пор не уверен, что поступил правильно. Однако если вы пишете не только для себя, вы должны слушать ваших покупателей. Независимо от того получаете ли вы от них деньги.

      Прежде чем мы вернемся к общим рекомендациям по разработке программ, я расскажу о нескольких уроках, которые я вынес из опыта работы над fetcnmail'ом.
      Синтаксис файла rc, включает в себя некоторые 'шумные' ключевые слова, которые полностью игнорируются синтаксическим анализатором. Предлагаемый синтаксис (напоминающий английский язык) значительно более читаемый, чем традиционные пары слово-значение, которые вы получите после того, как уберете все лишнее.
      Этот эксперимент начался поздно ночью, когда я заметил, насколько обЪявления в файле rc стали напоминать небольшой императивный язык. (Вот почему я заменил ключевое слово 'server' на 'poll').
      Традиционно программисты стремятся использовать точные и краткие управляющие конструкции. Это правильно, потому что вычислительные ресурсы дорогие, и процесс синтаксического анализа должен быть максимально простым и дешевым.
      Потому брать за основу английйский язык невыгодно, так как в нем около 50% избыточных конструкций.
      Для меня это не является причиной, чтобы избегать синтаксиса естественного языка. Дешевое исполнение инструкций и краткость не должны стать конечной целью. В первую очередь язык должен быть удобным для людей, а не дешевым для компьютеров.
      Существуют еще несколько поводов для беспокойства. Во-первых, нежелательно, чтобы возросшая стоимость синтаксического анализа, стала сама по себе источником ошибок. Во-вторых, при попытке сделать язык «англоподобным», часто требуется, чтобы «английский» потерял свою форму настолько, чтобы он походил на естественный язык, не больше, чем традиционный синтаксис. (Это можно часто видеть в языках запросов «четвертого поколения» и языках коммерческих баз данных.) В управляющих конструкциях fetchmail'a этих проблем удалось избежать, так как область действия языка сильно ограничена. Он практически не является общецелевым языком,и поэтому несложно перейти от небольшого подмножества английского языка к действительному языку управления. Отсюда можно извлечь еще один урок:
       16.Если ваш язык не является полным по Тьюрингу, добавьте немного синтаксического сахара.
      Другой урок касается безопасности. Некоторые пользователи fetchmail'a просили меня изменить программу так, чтобы она хранила зашифрованные пароли в файле rc.
      Я не сделал этого, потому что это не добавляет никакой защиты. Любой человек, имеющий право читать ваш файл, мог бы запустить fetchmail под вашим именем и, возможно, декодировать ваш пароль. Шифрование пароля в .fetchmailrc могло бы дать людям ложное чувство защищенности. Общее правило здесь следующее:
       17.Система безопасности надежна, пока надежны ее секреты. Избегайте псевдо-секретов.

      Читатели ранних версий этой статьи обязательно поднимали вопрос о необходимых условиях для разработки проекта в стиле базара, Здесь обычно рассматривали квалификацию лидера проекта и состояние системы на момент, когда принимается решение опубликовать исходные тексты и создать сообщество сотрудничающих разработчиков.
      Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можно тестировать, отлаживать и улучшать программы, работая в стиле базара, но начать проект очень трудно, Ни я, ни Линус даже не пытались это сделать.
      Вашему сообществу разработчиков нужно что-то, что можно отлаживать и тестировать.
      Когда вы начинаете создавать сотрудничающее сообщество, вам необходимы убеждающие доводы. Ваша программа может не всегда правильно работать. Она может быть неполной, содержать ошибки или иметь плохую документацию. Однако, она должна обязательно убедить потенциальных сотрудников, в том что их собираются вовлечь в нечто стоящее.
      Linux и fetchmail были представлены публике как программы, имеющие строгую основу. Многие люди, когда-либо размышлявшие о модели базара, поначалу относились к этому утвверждению критически. Однако позже почти все они приходили к мнению, что лидеру проекта крайне важно иметь высокую квалификацию и интуицию разработчика.
      Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я же позаимствовал их у родового popmail'a (хотя мне пришлось переделывать значительно больше, чем Линусу). Так ли уж необходим координатору исключительный талант разработчика или он может использовать чужие идеи?
      По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных.
      И Linux, и fetchmail показали очевидность этого утверждения. Линус – отличный разработчик, который к тому же показал свое умение распознавать хороший дизайн и встраиваить его в ядро Linux. А я, в свою очередь, уже описывал, как единственная наиболее мощная идея в разработке fetchmail (SMTP forwarding) была получена со стороны.
      Прежние читатели этой статьи отмечали, что я склонен недооценивать первоначальный дизайн в проектах базара, так как сам я отлично с ним справляюсь, и, поэтому принимаю это как должное. Возможно, в этом есть доля правды, дизайн, в отличие от кодирования и отладки, – мой конек.
      Проблема первоначального дизайна заключается в том, что вы начинаете проект, усложняя себе задачу, в то время как следует оставлять ее простой и понятной. Некоторые мои проекты проваливались из-за того, что я совершал эту ошибку, и поэтому я старался не допустить ее при разработке fetchmail.
      Итак, я уверен, что fetchmail удался, потому что я ограничил свою изобретательность. Давайте рассмотрим Linux. Предположим, что Линус Торвальдс стремился убрать основные изобретения в дизайне операционных систем, разве получили бы мы такое мощное и стабильное ядро?
      Конечно, определенные знания в области дизайна, а также навык кодирования необходимы, но мне кажется, что каждый, кто всерьез думает о такой разработке, превосходят требуемый минмиум. Репутация внутреннего рынка открытых программ оказывает давление, которое предостерегает недостаточно компетентных людей.
      Существует другое важное качество, не менее важное для успеха проекта в стиле базара. Координатор такого проекта должен иметь хороший опыт общения с людьми.
      Необходимость этого очевидна. Для создания сообщества разработчиков, вам необходимо как-то привлечь людей, заинтересовать их тем, что вы делаете.
      Техническая часть, конечно, очень существенна, но и ваша личность имеет немаловажное значение.
      Линус не случайно является симпатичным парнем, который нравится людям, и которому люди с удовольствием помогают. Также не является совпадением то, что я – очень энергичный экстраверт, которому нравится работать в команде.
      Если вы знаете как понравиться людям, это очень сильно поможет вам в разработке модели в стиле базара.

      Верно сказано: лучшие программы начинаются с решения проблем автора, с которыми он сталкивается каждый день, и расширяются, потому что эти проблемы оказываются типичными для большого класса пользователей. Это возвращает нас к первому правилу, которое можно сформулировать более точно:
       18.Чтобы решить интересную проблему, найдите проблему которая вас заинтересует. Это произошло с Карлом Харрисом и его родовым popclient'ом, это произошло со мной и fetchmail'ом. В этом нет ничего нового, гораздо интереснее другое. История с Linux'ом и fetchmail'ом указывает на следующую стадию в эволюции программного обеспечения – активное сообщество пользователей и разработчиков.
      В «The Mythical Man-Month» Фред Брукс рассматривал различные зависимости времени разработки. Он показывает, что сложность проекта и его коммуникационные издержки квадратично зависят от числа разработчиков, в то время как проделанная работа зависит только линейно. Это утверждение называется «закон Брукса», и большинство признает его правильным. Однако, если бы дело было только в законе Брукса, Linux не мог бы существовать.
      Пять месяцев назад, Джеральд Венберг в «Психологии программирования» предложил теорию, которую мы можем рассматривать, как жизненную поправку к закону Брукса. Обсуждая «неэгоистичное программирование» (egoless programming), Венберг замечает, что если разработчики не являются безраздельными владельцами исходников программ и приветствуют, когда другие люди помогают искать ошибки и предлагают различные улучшния, программа прогрессирует намного быстрее.
      Возможно, терминология Венберга не способствует тому, чтобы его утверждения приняли. Многие люди улыбаются при описании хакеров Интернет как «неэгоистичных». Однако, я думаю, что его аргументы лучше всего соответствуют сегодняшней ситуации.
      История UNIX подготовила нас к тому, что мы узнали от Linux (и тому, что я проверил на небольшом проекте, копируя методы Linux'a). В то время как кодирование является в основном индивидуальной деятельностью, гениальные хаккерские решения приходят от всего сообщества. Разработчик, который работает в замкнутом проекте и пользуется только своей головой, уступает разработчику, создающему открытый проект, в котором участвуют сотни людей, занятых поиском ошибок и предлагающих различные улучшения.
      Однако, в традиционном мире UNIX этот подход не является единственным. Одна из причин – это коммерческие и торговые секреты, ограничения различных лицензий и т. д. Другая причина заключается в том, что Интернет недостаточно хорошее средство общения.
      Прежде чем появилась дешевая связь через Интернет, существовало несколько географически компактных сообществ, традиции которых поощряли «неэгоистичное программирование», и разработчики сотрудничали друг с другом. 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, которые могут бросить гораздо большие силы на решение одной проблемы.

      Эта статья была значительно улучшена, благодаря тому что очень многие люди участвовали в ее обсуждении. Особенно я благодарен Джеффу Датки 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 за тестирование первой публичной версии этой статьи. И, конечно, мне очень помогли комментарии Линуса Торвальдса.

      Я процитировал несколько отрывков из 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, рассматриваемые условия, необходимые для творческой работы, помогут тем, кто попытается перенести некоторые принципы модели базара в более коммерческий контекст.

      Очень странно осознавать, что ты помогал вершиться Истории… 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 вернет себе существенную часть рынка – это будет означать запоздалую революцию в компьютерной промышленности.
      Следующий год обещает быть и поучительным и интересным.

      $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