…Стиль разработки «Линукса», предложенный Торвальдсом, воспринимался как нечто удивительное. Не как спокойная… атмосфера строительства собора. Вместо этого сообщество «Линукс» напоминало огромный говорливый восточный базар со множеством разнообразных программ и подходов, которые надлежащим образом символизировали узлы и архивы «Линукса», куда отправляли свои решения все, кто хотел… Стабильная и логично связанная система могла возникнуть только благодаря чуду, да и не только одному.
Тот факт, что этот «базарный стиль», по всей видимости, работает, причем работает очень хорошо, вызвал шок. Оглядываясь в прошлое, я понял, что работал не только над конкретными проектами, но также и старался понять: почему мир «Линукс» не только не был погребен в этой хаосе, но, казалось, становился все сильнее и сильней, причем такими темпами, какие трудно представить для традиционных «строителей собора»…
Сильная сторона традиции «Линукс» – момент, в котором обеспечил успех… – в том, что огромное число пользователей является к тому же и хакерами. А поскольку исходный текст открыт, то они могут стать эффективными хакерами. Это может оказаться крайне полезным и значительно сократить время отладки. С незначительной поддержкой ваши пользователи будут диагностировать проблемы, предлагать варианты их решения… Отсюда родился принцип «Воспринимай своих пользователей как соразработчиков». Вы выбираете самый простой способ быстрой модернизации кода и эффективной его отладки.
Если говорить не столь формально, то при достаточном количестве пользователей все ошибки мельчают. Я назвал это «законом Линуса». Хотя первоначальная формулировка состояла в том, что любая задача для кого-то окажется очевидной, Линус возразил, что человек, который понимает и устраняет проблему – не обязательно и, как правило, не тот человек, который впервые охарактеризовал проблему. «Кто-то находит проблему, – сказал он, – а кто-то ее понимает. Я бы рискнул сказать, что обнаружить проблему намного сложнее». Но суть в том, что в данном случае и то, и другое происходит достаточно быстро.
В этом, как я считаю, и состоит коренное отличие соборного и базарного стиля разработки. С точки зрения строителей «собора от программирования», ошибки и задачи разработки сложны, коварны и уникальны. Они требуют многих месяцев тщательного изучения группой избранных с тем, чтобы убедиться, что устранены все из них. Отсюда – и редкое появление новых версий, и неминуемое разочарование, когда долгожданный вариант оказывается несовершенным. При базарном подходе вы предполагаете, что ошибки в целом – незначительное явление. Или, по крайней мере, они довольно скоро станут незначительными, когда будут отданы на растерзание тысячам сгорающих от нетерпения соразработчиков, разбирающим по косточкам каждую новую версию. Таким образом, вы выпускаете новую версию для того, чтобы получить больше исправлений и в качестве положительного эффекта вы меньше теряете в том случае, если внезапно окажется, что работа была сделана небрежно. И все. Этого достаточно…
Отличительная особенность ситуации, сложившейся вокруг «Линукса»… стал тот факт, что участники любого данного проекта определяются сами. Один из первых корреспондентов отметил, что вклад в разработку проекта вносят не случайные люди, а те, кто достаточно заинтересован в том, чтобы использовать это программное обеспечение, изучить, как оно работает, попытаться найти решение проблем, с которыми они сталкиваются и действительно найти очевидно разумное решение задачи. Каждый, кто соответствует этим условиям, с большой вероятностью предложит что-то полезное…»
Иными словами, читатель, перед нами – явление из области создания коллективного разума, процесса развертывания программы с помощью сотен и тысяч участников. Процесс идет лавинообразно, когда в дело совершенствования исходной программы вовлекаются все новые и новые ресурсы – причем совершенно добровольно, с большим энтузиазмом. Недостатки, недоработки вскрываются и исправляются очень быстро. И тут же рождается множество улучшений. Все это – гораздо более эффективная схема по сравнению с централизованной. Там, где узкому кругу «избранных умников» требуются годы, здесь срок сжимается до месяцев, а то и дней. В придуманной норвежцем схеме нет «генштаба умников», которые рассматривают себя повелителями над пассивной массой глупцов – здесь есть Общее Дело. Здесь нет отношений «я – начальник, который отдает приказы и навязывает свою волю, а ты – лишь исполнитель». Здесь – сотрудничество в общем проекте. Невозможно в одиночку или небольшой группой предвидеть все нюансы программы, предугадать все ситуации, в которой ей придется работать. Но это способны сделать тысячи соратников-соразработчиков, действуя как одна сверхличность, как «разумная нарастающая лавина», как «мыслящий рой» (или «базар» по Реймонду). И этот принцип, читатель, годится не только для создания компьютерных программ. Важно правильно начать процесс. Впрочем, послушаем-ка Реймонда:
«…Первые читатели этой статьи часто задавали вопрос о том, что необходимо для того, чтобы разработка, проповедующая „базарный подход“, оказалась успешной. Их интересовало то, насколько квалифицированным должен быть руководитель проекта и состояние текста программы в тот момент, когда она передается для широкого обсуждения, когда начинаются попытки создать сообщество соразработчиков.
…Никто в одиночку не может «с нуля» создать программу, опираясь на «модель базара»…Для зарождения сообщества разработчиков требуется уже работоспособный и готовый к испытаниям продукт…Вам необходимо иметь возможность для того, чтобы предложить правдоподобные обещания. Ваша программа не должна работать особенно хорошо. Она может оказаться «сырой», ошибочной, неполной и плохо документированной. Но она обязательно должна работать и убедить потенциальных соразработчиков в том, что из нее в обозримом будущем может получиться нечто действительно стоящее.
Я считаю, что не так уж важно то, способен ли сам координатор генерировать великолепные архитектурные идеи, но критически важно то, чтобы координатор мог разглядеть прекрасные проектные идеи, предлагаемые другими.
…Координатор и руководитель «базарного проекта» должен уметь работать с людьми…Чтобы создать сообщество разработчиков, нужно уметь привлекать людей, заинтересовывать их и уметь сделать так, чтобы они были довольны тем объемом работы, который выполняют.
…Самые лучшие проекты начинались как персональные решения проблем, с которыми сам автор или авторы сталкивались ежедневно, а затем эти решения превращались в широкомасштабные проекты потому, что проблемы, которые они были призваны решать, оказывались типичными для большого класса пользователей. Это замечание позволяет нам сформулировать следующий принцип: чтобы решить интересную проблему, начните с поиска проблемы, которая вам интересна.
…Действительно великие программы создаются тогда, когда к ним привлекается внимание и применяются мыслительные способности целого сообщества.
Процитируем автобиографию известного русского анархиста XIX века Петра Алексеевича Кропоткина «Воспоминания революционера»:
«Воспитывавшийся в семье помещика, я вступил в активную жизнь, как и многие молодые люди моего времени, с огромной верой в необходимость командования, приказания, ругани, суровости и тому подобного. Но когда я в самом деле был вынужден управлять серьезными предприятиями и иметь дело со свободными людьми, и когда каждая ошибка приводила к весьма тяжким последствиям, я начал ценить различие между действиями на командных принципах и дисциплины и действиями на основе взаимопонимания. Первые превосходно работали на военном параде, но ничего не стоили в том, что касалось реальной жизни и где цель могла быть достигнута только благодаря упорным усилиям многих объединенных желаний…»
«Упорные усилия многих объединенных желаний» – это именно то, что необходимо такому проекту, как «Линукс»…Командный принцип невозможно применить к добровольцам в «анархическом рае», как мы называем Интернет. Чтобы эффективно действовать и конкурировать, хакеры, желающие возглавить совместные проекты, должны понять, как сплотить и побудить к действию людей, объединенных общим интересом в режиме, смутно описываемом «принципом взаимопонимания»… Они должны изучить то, как использовать «закон Линуса».
…Мир закрытых исходных текстов не может выиграть нарастающую «гонку вооружений» с сообществами сторонников свободного распространения программного обеспечения, которые могут направить на решение проблем силу, на много порядков большую…»
Вот, читатель, теперь вы знакомы с едва ли не главным принципом Братства – принципом «разумной лавины», роевого и сетевого действия. В наше время централизованные структуры, похожие на армии с «генштабами» и «генералами», проигрывают вот таким сетевым сообществам, где, как говорил великий Александр Васильевич Суворов, «каждый солдат знает свой маневр». Этот процесс идет везде: и в бизнесе, и в разработке программного обеспечения, и в военном искусстве. В последнем случае все тоже наглядно: «рои» отлично подготовленных воинов и мелких групп, связанных между собой «боевым Интернетом», получающие благодаря чудесам связи и разведки полную картину боя, нещадно бьют тяжелые, неповоротливые и тугодумные дивизии, в коих есть «умный штаб» и десятки тысячи нерассуждающих подчиненных-«винтиков», действующих лишь по приказу. «Винтиков», лишенных инициативы, слепых и глухих по сравнению с воинами-«роевиками». Так сотня спецназовцев с дисплеями на шлемах способна громить целые полки старого, административно-командного типа.
