Текст книги "Собор и Базар"
Автор книги: Эрик Рэймонд
сообщить о нарушении
Текущая страница: 1 (всего у книги 3 страниц) [доступный отрывок для чтения: 1 страниц]
Я проанализировал один из успешных проектов открытой разработки – fetchmail, который я использовал, чтобы проверить некоторые теоретические соображения о разработке программного обеспечения, возникшие из истории Linux'a. Я обсуждаю эти соображения с позиций двух совершенно разных стилей разработки: модели «собора», распространенной в коммерческом мире, или модели «базара», предложенной в мире Linux'a. Я показал, что эти модели происходят от разного подхода к задаче отладки программ.
1. Собор и Базар
Linux – удивительная система. Кто бы мог подумать, что несколько тысяч разработчиков, разбросанных по всей планете и сотрудничающих только через Интернет, смогут создать операционную систему мирового класса. Я во всяком случае так не думал. К тому времени как Linux оказалась в поле моего зрения в начале 1993 года, я уже около десяти лет участвовал в разработке UNIX'a и открытых программ. Я был одним из первых участников GNU в середине 80-х. Я был автором многих открытых программ, и в частности участвовал в разработке nethack, Emacs VC и GUD modes, xlife, которые широко используются и по сей день. Я думал, что я знаю, как это делается.
Linux перевернула мои представления о том, что я знаю. Я считал, что основным в разработке небольших инструментов для UNIX'a является их быстрое проектирование и эволюционирующее программирование в течение многих лет. И в то же время я верил, что по мере того как сложность разработки увеличивается, необходим более централизованный подход. Я верил, что разработка самого сложного программного обеспечения (например, операционных систем или просто больших инструментов, таких как Emacs) должна быть подобна строительству собора. Такие программы должны создаваться мастерами-индивидуалистами или небольшими группами волшебников, работающими в строгой изоляции, не допуская преждевременных бета-версий.
Меня очень удивил стиль разработки Линуса Торвальдса – частый выпуск релизов, доступность всех исходных текстов и терпимость к разнородным программам. Это совсем непохоже на размеренное строительство собора, сообщество Linux скорее напоминает шумный базар, с множеством различных подходов и направлений. То, что на этом базаре рождается согласованная стабильная операционная система, кажется чудом из чудес.
Меня потрясло, что этот базарный стиль работает и работает хорошо. Я не только участвовал в разработке индивидуальных проектов, но также пытался понять, почему в мире Linux'a не только не возникает беспорядка, но напротив он движется вперед со скоростью, которой строители собора могут только позавидовать.
К середине 1996 года мне показалось, что я начал понимать. Судьба предоставила мне прекрасный шанс проверить мою теорию. Это был проект разработки открытого пгораммного обеспечения, который я сознательно провел в базарном стиле. Успех этого проекта превзошел все ожидания.
В этой статье я расскажу вам историю этого проекта, и на его примере покажу несколько правил эффективной разработки свободного программного обеспечения.
Не все эти приемы я узнал из мира Linux'a, но если я прав, они помогут понять, почему сообщество Linux'a производит столько полезных программ и помогут вам повысить производительность.
2. Проблемы с пересылкой почты
C 1993 года я занимался решением технических проблем небольшого свободно доступного ISP, который назывался Chester Counter InterLink (CCIL). Я был одним из основателей CCIL и написал свою собственную BBS (вы можете проверить это, сделав telnet на locke.ccil.org). Сегодня он поддерживает почти три тысячи пользователей на девятнадцати линиях. Благодаря этой работе, я имел неограниченный доступ к Internet через линию 56K! Итак, мне пришлось использовать почту Internet. По некоторым причинам мне было сложно соединить CCIL и мою домашнюю машину по протоколу SLIP. В конце концов, когда мне это удалось, оказалось, что очень неудобно делать telnet для проверки своей почты. Я хотел, чтобы когда почта приходила на snark, я получал об этом сообщение и мог бы обрабатывать ее локальными инструментами.
Простой sendmail мне помочь не мог, потому что моя домашняя машина не всегда находится в сети и не имеет статического IP адреса. Мне нужна была программа, которая бы через SLIP соединие забирала мою почту. Я знал, что такие вещи существуют, и большинство из них использует простой протокол POP (Post Office Protocol). К тому же в операционную систему BSD/OS на locke был включен POP3 сервер.
Мне нужен был POP3 клиент. Одну такую программу я нашел через сеть (на самом деле я нашел три или четыре). Некоторое время я использовал pop-perl, но в нем отсутствовала одна необходимая возможность: он не умел выбирать адреса так, чтобы можно было правильно отвечать на письма.
Проблема заключалась в следующем. Допустим, что кто-то по имени 'joe' прислал мне на locke письмо. Если я пытался ответить на него, после того как забрал его на snark, мой mailer пытался адресовать ее несуществующему joe на snark. Исправлять вручную '@ccil.org' было утомительно.
Нужные мне возможности были очевидны, но ни один из существующих POP клиентов не знал как это сделать. Это приводит нас к первому уроку:
1. Все хорошие программы появляются для личных нужд разработчиков.
Необходимость – мать изобретения. Слишком часто программисты работают над программами, из которых они не могут извлечь ни пользы ни удовольствия – ничего кроме денег. Но в мире Linux – все по-другому, и это объясняет высокое качество программ для Linux.
Вы думаете, я тут же начал разрабатывать свой POP3 клиент, соревнуясь с уже имеющимися? Ни в коем случае! Я внимательно осмотрел все POP утилиты, которые были у меня под рукой, и спросил себя, которая из них наиболее соответствует моим требованиям. Потому что
2. Хорошие программисты знают, что можно написать; а великие знают, что можно переписать.
Я не претендовал на великого программиста, а попытался его имитировать.
Характерная черта великих – это их лень. Они знают, что судят не по усилиям, а по результатам. Почти всегда легче начать с чего-то сделанного, чем с нуля.
Линус Торвальдс, например, не пытался написать свою систему с нуля. Он начал использовать идеи и исходники от Minix, небольшой UNIX-подобной системы для 386 машин. Почти весь исходный текст Minix был переписан, однако, он послужил основой для того что позже стало Linux'ом.
Действуя в том же духе, я начал искать существующую POP утилиту, чтобы использовать ее как основу для разработки.
В мире UNIX'a всегда существовала традиция делать исходные тексты открытыми и дружественными к повторному использованию кода. Именно поэтому проект GNU выбрал UNIX как основную операционную систему. Мир Linux'a полностью перенял эту традицию. Здесь вы можете найти терабайты исходных текстов, и поэтому шансов найти что-нибудь подходящее в мире Linux'a выше, чем где бы то ни было.
Мне это подошло. Вместе с теми программами, которые я нашел раньше, у меня оказались девять кандидатов: fetchpop, PopTart, get-mail, gwpop, pimp, 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. Когда вы теряете интерес к программе, ваша последняя обязанность передать ее компетентному преемнику.
Карл и я знали, что наша общая цель – поиск наилучшего решения. Мне нужно было только доказать свою компетентность. Как только я это сделал, он быстро предал мне все полномочия. Надеюсь, что когда-нибудь я поступлю также.
3. Как важно иметь пользователей
Итак я унаследовал popclient. Но гораздо важнее то, что я унаследовал пользователей popclient'a. Иметь пользователей – это замечательно. Не только потому что это означает, что вы предоставляете нужную услугу. Дело в том, что правильно воспитанные пользователи могут стать сотрудниками.
Сильная традиция Unix'а, а особенно Linux'a заключается в том, что большинство пользователей являются хакерами. Так как исходный текст программ доступен, они могут стать эффективными хакерами. Это может значительно уменьшить время отладки. Если вы сможете воодушевить пользователей, они будут диагностировать проблемы, предлагать решения и помогать улучшить код намного быстрее, чем сможете это сделать вы.
6. Если пользователи будут вашими сотрудниками, то вам обеспечены улучшение кода и эффективная отладка.
Сила этого эффекта часто не дооценивается. На самом деле все мы, разработчики мира открытых систем, сильно недооценивали насколько это может повысить число пользователей и уменьшить сложность системы, пока Линус Торвальдс не показал нам это.
Я действительно думаю, что наиболее значительное и результативное творение Линуса – это не создание ядра Linux'a, а изобретение модели его разработки.
Когда я поделился с ним своим мнением, он улыбнулся и просто повторил то, о чем часто говорил: «Я просто очень ленивый человек, которому нравится получать пользу от того, что делают другие люди.» Ленивый, как лиса, или, как сказал бы Роберт Хейнлейн, слишком ленивый чтобы проиграть.
Один из успешных методов работы в стиле Linux'a можно было наблюдать при разработке GNU Emacs Lisp – библиотеки и кода Lisp'a. В отличие от соборного стиля, разработка ядра Emacs С, а также многих других FSF инструментов в значительной степени управлялась пользователями. Все исходные тексты были преписаны три или четыре раза, прежде чем приняли свою окончательную форму.
Моей первой успешной программой, разработанной в стиле Linux'a, стал VC режим Emacs'a. Я разработал ее с тремя людьми, сотрудничая по e-mail'у. С одним из них (это Ричард Столлмэн – автор Emacs и основатель FSF) я встречаюсь и по сей день. Разработка VC была успешной, потому что в отличие от Emacs, код Emacs Lisp может быстро пройти через поколения release/test/improve.
При попытках FSF легально встроить код в GPL обнаруживается неожиданный сторонний эффект. Использовать модель базара для FSF сложнее, так как необходимо получать copyright на каждые 20 строчек кода.
4. Выпускать релизы нужно часто и рано
Ранние и частые релизы – это существенная часть модели разработки Linux'a.
Раньше большинство разработчиков, включая меня, считали, что это плохая идея для больших проектов. В ранних версиях всегда очень много ошибок, и никто не хочет чтобы пользователи потеряли терпение.
Так утвердилась разработка в стиле строительства собора. Для того чтобы пользователи видели как можно меньше ошибок, вы выпускаете релиз не чаще, чем раз в шесть месяцев, а остальное время между релизами упорно работаете над отладкой. Ядро Emacs C разрабатывалось именно таким способом, а библиотека Lisp'a разрабатывалась по-другому. Дело в том, что существует очень много архивов Lisp'a вне контроля FSF, где каждый может найти новую версию исходного текста, независимо от цикла релизов Emacs'a.
Наиболее важный из этих архивов – архив в штате Огайо, перенял многие черты сегодняшних архивов Linux'a. Примерно в 1992 году я сделал первую серьезную попытку добавить исходники этого архива в официальную Emacs Lisp библиотеку.
Мне пришлось вступить в политическую борьбу, которая закончилась неудачно.
Годом позже, по мере того как Linux становилась все более распространенной системой, стало ясно, что хотя идеи разработки этой системы отличаются от традиционных, в них очень много здравого смысла. Проводимая Линусом политика открытой разработки была совершенно противоположна стилю строительства собора. Появились архивы sunsite и tsx-11, многочисленные дистрибуции Linux'a, и все это при частых релизах ядра системы.
Линус сотрудничал со своими пользователями наиболее эффективным способом.
7. Выпускайте ранние релизы. выпускайте частые релизы. Слушайте своих пользователей.
Изобретение Линуса заключается не только в том, что он делал (нечто похожее долгое время было традицией мира UNIX'a). Удивляет уровень интенсивности и сложности того, что он разрабатывал. В начале работы (около 1991 года) бывали случаи, когда новая версия ядра выходила чаще, чем один раз в день.
Это работало, потому что Линус призывал своих пользователей к сотрудничеству через Интернет, активнее, чем кто-либо другой.
Но как это работало? Было ли там что-нибудь, что я мог повторить или дело было в гениальности Линуса Торвальдса?
Я так не думал. Линус – отличный хаккер (кто из нас сможет полностью разработать качественное ядро операционной системы?), но Linux не является принципиальным скачком вперед. Линус – это не гений разработки, такой как, например, Ричард Столмен или Джеймс Гослинг (NeWS или Java). Линус кажется мне скорее гением инженерного мастерства, обладающим шестым чувством избегать ошибки, доводить разработку до конца и с минимальным усилием находить кратчайший путь из точки А в точку В.
Поставленный таким образом вопрос отвечает сам на себя. Сохраняя постоянным отношение числа хакеров к числу пользователей, Линус получал и стимул и вознаграждение. Стимул – удовлетворенность своими действиями, вознаграждение – ежедневное улучшение своей работы.
Линус стремился максимизировать количество человеко-часов, затраченных на отладку и разработку, даже ценой нестабильности, если какая-то ошибка окажется трудно устранимой. Линус считал что:
8. При достаточном количестве бета-тестеров и сотрудников, почти любая проблема будет быстро обнаружена и окажется для кого-то очевидной.
Или менее формально: «При достаточном количестве глаз, ошибки выплывают на поверхность.» Я назову это – законом Линуса.
Мое собственное утверждение состоит в том, что всякая проблема является для кого-то прозрачной. Однако по мнению Линуса, человек, который понимает проблему и находит ее решение, не всегда первый ее обнаруживает. «Кто-то находит проблему», – говорит он, – «А кто-то еще ее понимает. И я часто замечаю, что поиск требует наибольшего навыка.» Суть заключается в том, что и то и другое должно происходить быстро.
Существенная разница здесь в различии соборного и базарного стиля. С точки зрения соборного стиля программирования, ошибки – хитрые, коварные и страшные явления. Месяцы работы, не имеющей отношения к разработке, уходят на то, чтобы выловить все ошибки. Таким образом мы получаем длительные промежутки между релизами и разочарование, когда столь долгожданные релизы оказываются далеки от совершенства.
С другой стороны при работе в стиле базара, вы не считаете ошибки непреодолимым препятствием. По крайней мере они покажутся такими тысячам пользователям, работающим над каждым новым релизом. Вы выпускаете релизы часто, чтобы получить больше исправлений.
Вот и все. Если закон Линуса неверен, то при разработке сложной системы, такой как ядро Linux'a, многими пользователями, в некоторый момент времени, система развалится из-за плохого взаимодействия и недосмотренных серьезных ошибках. С другой стороны, если этот закон верен, то он обЪясняет отностительное отсутствие грубых ошибок.
Возможно, это не так удивительно, как кажется. Несколько лет назад социологи открыли, что среднее мнение людей, в равной степени являющихся либо экспертами, либо дилетантами более верно, чем мнение одного случайно выбранного наблюдателя. Это называется «эффектом Delphi». Линус показал, что это применимо даже в отладке операционной системы, – эффект Delphi может уменьшить сложность проекта даже на уровне разработки ядра ОС.
Я благодарен Джеффу Датки (Jeff Dutky), за то что он показал мне, как можно перефразировать закон Линуса: «Отладка может быть параллельной.» Джефф считает, что хотя во время отладки людям нужно общаться друг с другом с помощью какого-нибудь координатора-разработчика, это не требует серьезной координации между тестерами. Это значительно уменьшает издержки при добавлении тестеров.
На самом деле теоретическая потеря эффективности от того, что часть работы по отладке дублируется, в мире Linux'a очень небольшая. Эффект от частого выпуска релизов уменьшает вероятность двойной работы, так как ошибки фиксируются очень быстро.
Приведем замечание Брукса:" Общая стоимость поддержки широко используемой программы – это не меньше 40% от стоимости ее разработки." Удивительно, что эта стоимость зависит от числа пользователей. Больше пользователей найдут больше ошибок.
Больше пользователей найдут больше ошибок, потому что новые пользователи добавляют новые способы отладки программы. Этот эффект усиливается, когда пользователи являются сотрудниками. Каждый из них подходит к проблеме выявления ошибок под своим собственным углом. Эффект Delphi в этом случае хорошо работает.
Итак, если мы добавляем больше бета-тестеров, то с точки зрения разработчиков, мы не увеличиваем сложность возможной серьезной ошибки, но увеличиваем вероятность, что кто-то эту ошибку обнаружит, и для него она окажется прозрачной.
На самом деле в ядре Linux'a существуют серьезные ошибки. Однако, нумерация ядра Linux'a производится таким образом, что потенциальные пользователи могут выбрать: использовать стабильную версию или рискнуть и работать с новыми особенностями последней версии. Эта тактика еще не совсем поддерживается большинством хаккеров Linux, хотя возможность выбора делает ее привлекательной.
5. Роза или не Роза?
Изучая работу Линуса и формируя мою собственную теорию о том, почему Linux имеет такой успех, я решил проверить свои измышления на моем новом, значительно менее сложном проекте. Сначала я реорганизовал и упростил popclient. Реализация Карла Харриса была неплохой, однако много С – программистов находило в ней массу сложных и ненужных вещей. Код считался центральной частью, а структуры данных были просто поддержкой кода. В результате код был хорош, но дизайн структур данных по высоким стандартам хаккера, программирующего на LISP'e, был по меньшей мере ужасным.
Однако, у меня была другая цель, отличная от улучшения кода и организации данных. Мне было нужно полное понимание того, что я делаю. Согласитесь, не очень-то здорово отвечать за исправление ошибок в программе, которую ты не понимаешь.
В течение первого месяца, я просто следовал дизайну Карла Харриса. Первым изменением, которое я сделал стала поддержка IMAP-протокола. Я реализовал это, реорганизовав машинные протоколы в общий драйвер и три таблицы методов (для POP2, POP3 и IMAP). Это и предыдущие изменения продемонстрировали общий принцип, который следует помнить хорошему программисту, особенно тем кто пользуется С – подобными языками:
9. Хорошие структуры данных и плохой код работают несколько лучше, чем хороший код и плохие данные.
Брукс Глава 9: "Если вы покажете мне код и скроете структуры данных, я ничего не пойму в вашей программе. Однако, если вы покажете мне структуры данных, код скорее всего не понадобится. Он будет очевиден. " Прошло шесть месяцев, и я начал подумывать об изменении имени – это был уже не просто popclient. Однако, я колебался,потому что в дизайне не было ничего принципиально нового. Для уникальности моей версии popclient'a еще очень многого не хватало.
Все значительно изменилось, когда fetchmail научился направлять почту в SMTP порт. Наступил день, когда я пришел к этому. Я уже говорил, что я решил использовать этот проект для проверки моей теории о том, что действия Линуса Торвальдса были правильными. Вы спросите, как я делал это? Я использовал для этого следующие способы:
1 – Я часто выпускал релизы(не реже чем каждые 10 дней, а во время периодов интенсивной разработки каждый день.)
2 – Я увеличил список бета тестеров, добавив к нему каждого, кто контактировал со мной на тему fetchmail'a.
3 – Каждый раз когда я делал релиз, я рассылал обЪявления бета-тестерам, приглашая людей активно сотрудничать.
4 – Я слушал своих бета-тестеров и поддерживал с ними обратную связь.
Эффект от этих простых действий был незамедлительным. С самого начала проекта я получал отчеты об ошибках, за которые разработчиков следовало бы убить. Часто к этим отчетам прилагались элегантные решения. Я получал критику, я получал интересную почту, я получал остроумные решения. Вот к чему это привело:
10. Если вы относитесь к вашим бета-тестерам как к самому ценному ресурсу, очень скоро они станут вашим самым ценным ресурсом.
Очень интересно было наблюдать за увеличением списка бета-тестеров – друзей feetchmail'a. На время написания в нем было 249 членов, и каждую неделю к ним добавлялись два-три человека.
В мае 1997 года список начал терять своих членов по очень интересной причине. Люди стали отказываться от подписки, потому что fetchmail работал для них настолько хорошо, что необходимость доработки кода отпала.
