Это может оказаться крайне полезным и значительно сократить время отладки. С незначительной поддержкой ваши пользователи будут диагностировать проблемы, предлагать варианты их решения… Отсюда родился принцип «Воспринимай своих пользователей как соразработчиков». Вы выбираете самый простой способ быстрой модернизации кода и эффективной его отладки.
Если говорить не столь формально, то при достаточном количестве пользователей все ошибки мельчают. Я назвал это «законом Линуса». Хотя первоначальная формулировка состояла в том, что любая задача для кого-то окажется очевидной, Линус возразил, что человек, который понимает и устраняет проблему – не обязательно и, как правило, не тот человек, который впервые охарактеризовал проблему. «Кто-то находит проблему, – сказал он, – а кто-то ее понимает. Я бы рискнул сказать, что обнаружить проблему намного сложнее». Но суть в том, что в данном случае и то, и другое происходит достаточно быстро.
В этом, как я считаю, и состоит коренное отличие соборного и базарного стиля разработки. С точки зрения строителей «собора от программирования», ошибки и задачи разработки сложны, коварны и уникальны. Они требуют многих месяцев тщательного изучения группой избранных с тем, чтобы убедиться, что устранены все из них. Отсюда – и редкое появление новых версий, и неминуемое разочарование, когда долгожданный вариант оказывается несовершенным. При базарном подходе вы предполагаете, что ошибки в целом – незначительное явление. Или, по крайней мере, они довольно скоро станут незначительными, когда будут отданы на растерзание тысячам сгорающих от нетерпения соразработчиков, разбирающим по косточкам каждую новую версию. Таким образом, вы выпускаете новую версию для того, чтобы получить больше исправлений и в качестве положительного эффекта вы меньше теряете в том случае, если внезапно окажется, что работа была сделана небрежно. И все. Этого достаточно…
Отличительная особенность ситуации, сложившейся вокруг «Линукса»… стал тот факт, что участники любого данного проекта определяются сами. Один из первых корреспондентов отметил, что вклад в разработку проекта вносят не случайные люди, а те, кто достаточно заинтересован в том, чтобы использовать это программное обеспечение, изучить, как оно работает, попытаться найти решение проблем, с которыми они сталкиваются и действительно найти очевидно разумное решение задачи. Каждый, кто соответствует этим условиям, с большой вероятностью предложит что-то полезное…»
Иными словами, читатель, перед нами – явление из области создания коллективного разума, процесса развертывания программы с помощью сотен и тысяч участников. Процесс идет лавинообразно, когда в дело совершенствования исходной программы вовлекаются все новые и новые ресурсы – причем совершенно добровольно, с большим энтузиазмом. Недостатки, недоработки вскрываются и исправляются очень быстро. И тут же рождается множество улучшений. Все это – гораздо более эффективная схема по сравнению с централизованной. Там, где узкому кругу «избранных умников» требуются годы, здесь срок сжимается до месяцев, а то и дней. В придуманной норвежцем схеме нет «генштаба умников», которые рассматривают себя повелителями над пассивной массой глупцов – здесь есть Общее Дело. Здесь нет отношений «я – начальник, который отдает приказы и навязывает свою волю, а ты – лишь исполнитель». Здесь – сотрудничество в общем проекте. Невозможно в одиночку или небольшой группой предвидеть все нюансы программы, предугадать все ситуации, в которой ей придется работать. Но это способны сделать тысячи соратников-соразработчиков, действуя как одна сверхличность, как «разумная нарастающая лавина», как «мыслящий рой» (или «базар» по Реймонду). И этот принцип, читатель, годится не только для создания компьютерных программ. Важно правильно начать процесс. Впрочем, послушаем-ка Реймонда:
«…Первые читатели этой статьи часто задавали вопрос о том, что необходимо для того, чтобы разработка, проповедующая „базарный подход“, оказалась успешной. Их интересовало то, насколько квалифицированным должен быть руководитель проекта и состояние текста программы в тот момент, когда она передается для широкого обсуждения, когда начинаются попытки создать сообщество соразработчиков.
…Никто в одиночку не может «с нуля» создать программу, опираясь на «модель базара»…Для зарождения сообщества разработчиков требуется уже работоспособный и готовый к испытаниям продукт…Вам необходимо иметь возможность для того, чтобы предложить правдоподобные обещания. Ваша программа не должна работать особенно хорошо. Она может оказаться «сырой», ошибочной, неполной и плохо документированной. Но она обязательно должна работать и убедить потенциальных соразработчиков в том, что из нее в обозримом будущем может получиться нечто действительно стоящее.
Я считаю, что не так уж важно то, способен ли сам координатор генерировать великолепные архитектурные идеи, но критически важно то, чтобы координатор мог разглядеть прекрасные проектные идеи, предлагаемые другими.
…Координатор и руководитель «базарного проекта» должен уметь работать с людьми…Чтобы создать сообщество разработчиков, нужно уметь привлекать людей, заинтересовывать их и уметь сделать так, чтобы они были довольны тем объемом работы, который выполняют.
…Самые лучшие проекты начинались как персональные решения проблем, с которыми сам автор или авторы сталкивались ежедневно, а затем эти решения превращались в широкомасштабные проекты потому, что проблемы, которые они были призваны решать, оказывались типичными для большого класса пользователей. Это замечание позволяет нам сформулировать следующий принцип: чтобы решить интересную проблему, начните с поиска проблемы, которая вам интересна.
…Действительно великие программы создаются тогда, когда к ним привлекается внимание и применяются мыслительные способности целого сообщества.
Процитируем автобиографию известного русского анархиста XIX века Петра Алексеевича Кропоткина «Воспоминания революционера»:
«Воспитывавшийся в семье помещика, я вступил в активную жизнь, как и многие молодые люди моего времени, с огромной верой в необходимость командования, приказания, ругани, суровости и тому подобного. Но когда я в самом деле был вынужден управлять серьезными предприятиями и иметь дело со свободными людьми, и когда каждая ошибка приводила к весьма тяжким последствиям, я начал ценить различие между действиями на командных принципах и дисциплины и действиями на основе взаимопонимания. Первые превосходно работали на военном параде, но ничего не стоили в том, что касалось реальной жизни и где цель могла быть достигнута только благодаря упорным усилиям многих объединенных желаний…»
«Упорные усилия многих объединенных желаний» – это именно то, что необходимо такому проекту, как «Линукс»…Командный принцип невозможно применить к добровольцам в «анархическом рае», как мы называем Интернет. Чтобы эффективно действовать и конкурировать, хакеры, желающие возглавить совместные проекты, должны понять, как сплотить и побудить к действию людей, объединенных общим интересом в режиме, смутно описываемом «принципом взаимопонимания»… Они должны изучить то, как использовать «закон Линуса».
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301
Если говорить не столь формально, то при достаточном количестве пользователей все ошибки мельчают. Я назвал это «законом Линуса». Хотя первоначальная формулировка состояла в том, что любая задача для кого-то окажется очевидной, Линус возразил, что человек, который понимает и устраняет проблему – не обязательно и, как правило, не тот человек, который впервые охарактеризовал проблему. «Кто-то находит проблему, – сказал он, – а кто-то ее понимает. Я бы рискнул сказать, что обнаружить проблему намного сложнее». Но суть в том, что в данном случае и то, и другое происходит достаточно быстро.
В этом, как я считаю, и состоит коренное отличие соборного и базарного стиля разработки. С точки зрения строителей «собора от программирования», ошибки и задачи разработки сложны, коварны и уникальны. Они требуют многих месяцев тщательного изучения группой избранных с тем, чтобы убедиться, что устранены все из них. Отсюда – и редкое появление новых версий, и неминуемое разочарование, когда долгожданный вариант оказывается несовершенным. При базарном подходе вы предполагаете, что ошибки в целом – незначительное явление. Или, по крайней мере, они довольно скоро станут незначительными, когда будут отданы на растерзание тысячам сгорающих от нетерпения соразработчиков, разбирающим по косточкам каждую новую версию. Таким образом, вы выпускаете новую версию для того, чтобы получить больше исправлений и в качестве положительного эффекта вы меньше теряете в том случае, если внезапно окажется, что работа была сделана небрежно. И все. Этого достаточно…
Отличительная особенность ситуации, сложившейся вокруг «Линукса»… стал тот факт, что участники любого данного проекта определяются сами. Один из первых корреспондентов отметил, что вклад в разработку проекта вносят не случайные люди, а те, кто достаточно заинтересован в том, чтобы использовать это программное обеспечение, изучить, как оно работает, попытаться найти решение проблем, с которыми они сталкиваются и действительно найти очевидно разумное решение задачи. Каждый, кто соответствует этим условиям, с большой вероятностью предложит что-то полезное…»
Иными словами, читатель, перед нами – явление из области создания коллективного разума, процесса развертывания программы с помощью сотен и тысяч участников. Процесс идет лавинообразно, когда в дело совершенствования исходной программы вовлекаются все новые и новые ресурсы – причем совершенно добровольно, с большим энтузиазмом. Недостатки, недоработки вскрываются и исправляются очень быстро. И тут же рождается множество улучшений. Все это – гораздо более эффективная схема по сравнению с централизованной. Там, где узкому кругу «избранных умников» требуются годы, здесь срок сжимается до месяцев, а то и дней. В придуманной норвежцем схеме нет «генштаба умников», которые рассматривают себя повелителями над пассивной массой глупцов – здесь есть Общее Дело. Здесь нет отношений «я – начальник, который отдает приказы и навязывает свою волю, а ты – лишь исполнитель». Здесь – сотрудничество в общем проекте. Невозможно в одиночку или небольшой группой предвидеть все нюансы программы, предугадать все ситуации, в которой ей придется работать. Но это способны сделать тысячи соратников-соразработчиков, действуя как одна сверхличность, как «разумная нарастающая лавина», как «мыслящий рой» (или «базар» по Реймонду). И этот принцип, читатель, годится не только для создания компьютерных программ. Важно правильно начать процесс. Впрочем, послушаем-ка Реймонда:
«…Первые читатели этой статьи часто задавали вопрос о том, что необходимо для того, чтобы разработка, проповедующая „базарный подход“, оказалась успешной. Их интересовало то, насколько квалифицированным должен быть руководитель проекта и состояние текста программы в тот момент, когда она передается для широкого обсуждения, когда начинаются попытки создать сообщество соразработчиков.
…Никто в одиночку не может «с нуля» создать программу, опираясь на «модель базара»…Для зарождения сообщества разработчиков требуется уже работоспособный и готовый к испытаниям продукт…Вам необходимо иметь возможность для того, чтобы предложить правдоподобные обещания. Ваша программа не должна работать особенно хорошо. Она может оказаться «сырой», ошибочной, неполной и плохо документированной. Но она обязательно должна работать и убедить потенциальных соразработчиков в том, что из нее в обозримом будущем может получиться нечто действительно стоящее.
Я считаю, что не так уж важно то, способен ли сам координатор генерировать великолепные архитектурные идеи, но критически важно то, чтобы координатор мог разглядеть прекрасные проектные идеи, предлагаемые другими.
…Координатор и руководитель «базарного проекта» должен уметь работать с людьми…Чтобы создать сообщество разработчиков, нужно уметь привлекать людей, заинтересовывать их и уметь сделать так, чтобы они были довольны тем объемом работы, который выполняют.
…Самые лучшие проекты начинались как персональные решения проблем, с которыми сам автор или авторы сталкивались ежедневно, а затем эти решения превращались в широкомасштабные проекты потому, что проблемы, которые они были призваны решать, оказывались типичными для большого класса пользователей. Это замечание позволяет нам сформулировать следующий принцип: чтобы решить интересную проблему, начните с поиска проблемы, которая вам интересна.
…Действительно великие программы создаются тогда, когда к ним привлекается внимание и применяются мыслительные способности целого сообщества.
Процитируем автобиографию известного русского анархиста XIX века Петра Алексеевича Кропоткина «Воспоминания революционера»:
«Воспитывавшийся в семье помещика, я вступил в активную жизнь, как и многие молодые люди моего времени, с огромной верой в необходимость командования, приказания, ругани, суровости и тому подобного. Но когда я в самом деле был вынужден управлять серьезными предприятиями и иметь дело со свободными людьми, и когда каждая ошибка приводила к весьма тяжким последствиям, я начал ценить различие между действиями на командных принципах и дисциплины и действиями на основе взаимопонимания. Первые превосходно работали на военном параде, но ничего не стоили в том, что касалось реальной жизни и где цель могла быть достигнута только благодаря упорным усилиям многих объединенных желаний…»
«Упорные усилия многих объединенных желаний» – это именно то, что необходимо такому проекту, как «Линукс»…Командный принцип невозможно применить к добровольцам в «анархическом рае», как мы называем Интернет. Чтобы эффективно действовать и конкурировать, хакеры, желающие возглавить совместные проекты, должны понять, как сплотить и побудить к действию людей, объединенных общим интересом в режиме, смутно описываемом «принципом взаимопонимания»… Они должны изучить то, как использовать «закон Линуса».
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301