Эрик Рэймонд - Собор и Базар
Я и не замеитл, как проект начал расширяться. Я больше не писал программы, дополняющие 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), за то что он показал мне, как можно перефразировать закон Линуса: «Отладка может быть параллельной.» Джефф считает, что хотя во время отладки людям нужно общаться друг с другом с помощью какого-нибудь координатора-разработчика, это не требует серьезной координации между тестерами. Это значительно уменьшает издержки при добавлении тестеров.
