От Pout Ответить на сообщение
К BLS Ответить по почте
Дата 12.01.2002 16:27:44 Найти в дереве
Рубрики Программа; Версия для печати

Собор и Базар, или кооперативные эффекты при разработке"продукта"

Тут ниже цитируется статья, которая рассказывает про методологию создания программного продукта "многоголовой гидрой"в основном за счет кооперативных эффектов, благодаря сети и ее возможностям.
Программистам проще понять, но и другим наверно будет небезинтересно. Можно даже мораль вычленить из этой истории. Против ИХНЕГО"БИЛЛГЕЙТСОВСКОГО" МОНСТРА-
"базарный" кооперативный плод"народного творчества". Кстати, вполне способный победить даже монстра "молекуляиными воздействиями" , сотрудничеством"разработчиков"и"пользователей".
Автор - изветсный человек в сетевом мире, он составитель "Нового словаря хакера" - фактически энциклопедии и библии коренной, восходящнй к прародителям, сетевой субкультуры. Очень тоже непростое , но душеполезное чтение. Есть русский перевод.

отрывки
===========

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


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


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

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

Или менее формально: "При достаточном количестве глаз, ошибки выплывают на поверхность." Я назову это - законом Линуса.

Мое собственное утверждение состоит в том, что всякая проблема является для
кого-то прозрачной. Однако по мнению Линуса, человек, который понимает
проблему и находит ее решение, не всегда первый ее обнаруживает. "Кто-то
находит проблему", - говорит он, - "А кто-то еще ее понимает. И я часто
замечаю, что поиск требует наибольшего навыка." Суть заключается в том, что
и то и другое должно происходить быстро.

Существенная разница здесь в различии соборного и базарного стиля. С точки
зрения соборного стиля программирования, ошибки - хитрые, коварные и
страшные явления. Месяцы работы, не имеющей отношения к разработке, уходят
на то, чтобы выловить все ошибки. Таким образом мы получаем длительные
промежутки между релизами и разочарование, когда столь долгожданные релизы
оказываются далеки от совершенства.

С другой стороны при работе в стиле базара, вы не считаете ошибки
непреодолимым препятствием. По крайней мере они покажутся такими тысячам
пользователям, работающим над каждым новым релизом. Вы выпускаете релизы
часто, чтобы получить больше исправлений.

Вот и все. Если закон Линуса неверен, то при разработке сложной системы,
такой как ядро Linux'a, многими пользователями, в некоторый момент времени,
система развалится из-за плохого взаимодействия и недосмотренных серьезных
ошибках. С другой стороны, если этот закон верен, то он обЪясняет
отностительное отсутствие грубых ошибок.

Возможно, это не так удивительно, как кажется. Несколько лет назад социологи
открыли, что среднее мнение людей, в равной степени являющихся либо
экспертами, либо дилетантами более верно, чем мнение одного случайно
выбранного наблюдателя. Это называется "эффектом Delphi". Линус показал, что
это применимо даже в отладке операционной системы, - эффект Delphi может
уменьшить сложность проекта даже на уровне разработки ядра ОС.


....
9. Необходимые условия для модели базара.

Читатели ранних версий этой статьи обязательно поднимали вопрос о
необходимых условиях для разработки проекта в стиле базара, Здесь обычно
рассматривали квалификацию лидера проекта и состояние системы на момент,
когда принимается решение опубликовать исходные тексты и создать сообщество
сотрудничающих разработчиков.

Очевидно, что никто не сможет начать разработку в таком стиле с нуля. Можно
тестировать, отлаживать и улучшать программы, работая в стиле базара, но
начать проект очень трудно, Ни я, ни Линус даже не пытались это сделать.
Вашему сообществу разработчиков нужно что-то, что можно отлаживать и
тестировать.

Когда вы начинаете создавать сотрудничающее сообщество, вам необходимы
убеждающие доводы . Ваша программа может не всегда правильно работать. Она
может быть неполной, содержать ошибки или иметь плохую документацию. Однако,
она должна обязательно убедить потенциальных сотрудников, в том что их
собираются вовлечь в нечто стоящее.

Linux и fetchmail были представлены публике как программы, имеющие строгую
основу. Многие люди, когда-либо размышлявшие о модели базара, поначалу
относились к этому утвверждению критически. Однако позже почти все они
приходили к мнению, что лидеру проекта крайне важно иметь высокую
квалификацию и интуицию разработчика.

Однако не будем забывать, что Линус заимствовал идеи разработки от UNIX. Я
же позаимствовал их у родового popmail'a (хотя мне пришлось переделывать
значительно больше, чем Линусу). Так ли уж необходим координатору
исключительный талант разработчика или он может использовать чужие идеи?

По-моему не очень существенно, способен ли координатор на оригинальный
дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен
отличить хороший дизайн от всех остальных .


....
18. Чтобы решить интересную проблему, найдите проблему которая вас
заинтересует. Это произошло с Карлом Харрисом и его родовым popclient'ом,
это произошло со мной и fetchmail'ом. В этом нет ничего нового, гораздо
интереснее другое. История с Linux'ом и fetchmail'ом указывает на следующую
стадию в эволюции программного обеспечения - активное сообщество
пользователей и разработчиков.
...
(заключение)

Прежде чем появилась дешевая связь через Интернет, существовало несколько
географически компактных сообществ, традиции которых поощряли "неэгоистичное
программирование", и разработчики сотрудничали друг с другом. 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
=========
==========