Социальная Архитектура: Создание онлайн сообществ

В «Рассуждениях о первой декаде Тита Ливия» Никколо Макиавелли есть следующие строки:

В своей книге «Мудрость толпы» Джеймс Шуровьески писал: «при правильных условиях группы могут быть очень умными, а зачастую могут быть намного умнее, чем даже самый умный человек внутри группы». Он заметил, что коллективный разум обычно показывает лучшие результаты, чем небольшая группа экспертов, даже если члены группы не владеют всеми фактами или ведут себя иррационально, поступая по-своему.

Другими словами, группа случайных людей в среднем будет умнее нескольких экспертов. Этот тезис противоречит здравому смыслу и выглядит насмешкой над накопленной веками мудростью. Эксперты в области человеческого интеллекта (социологи, антропологи, психологи) встретили идеи Шуровьески далеко не с распростертыми объятиями. Он пошел дальше: «добавив в группу специалистов, вы сделаете ее глупее, а добавив дилетантов, повысите опять ее интеллектуальный уровень. Как и любой рецепт, это работает только при определенных обстоятельствах».

Я наткнулся на Шуровьески, когда стал работать над универсальным рецептом по построению сообществ. И сразу увидел, что его работа тесно перекликается с моими собственными наблюдениями, и что я могу устроить ей испытание. У меня была возможность не только применить, но и обкатать его идеи на многих сообществах и поискать им опровержение: все по-научному.

Это намерение дало начало процессу по построению умных, самоуправляемых, успешных онлайн-сообществ, которые раз за разом опережали экспертные группы. Эту дисциплину я назвал Социальной Архитектурой, что позволяло мне некоторое время называть себя «Социальным Архитектором» (сегодня я — пытающийся пробиться писатель, это звучит романтичней).

Социальная Архитектура по аналогии с привычной архитектурой является процессом и результатом планирования, разработки и становления онлайн-сообщества. Социальная архитектура в виде онлайн-сообществ — это культурные и политические символы и произведения искусства цифрового общества. 21 век будет ознаменован зарождением Социальных Архитекторов.

Успешные онлайн-сообщества обычно основаны на договоренности о взаимной выгоде, подразумеваемой или явной. Т.е. это возможность построить бизнес на миллиард долларов, основанный на добровольном труде участников, действующих из эгоистических побуждений. Часто участники не осознают или не придают значения тому, что они являются частью сообщества. Однако подоплека любого нашего действия — получение выгоды. «Краудсорсинг» является эксплуатацией добровольного труда для получения прибыли. И это работает только в том случае, когда толпа на самом деле хочет решить проблему, которую вы подбросили, или которую она обнаружила.

Макиавелли не дал объяснений или подтверждений своему наблюдению. Однако понимание того, что коллективная воля является безошибочной и справедливой — vox populi, vox Dei — пронизывает современную культуру. Она поддерживает в нас веру в демократию и оправдывает наши требования прозрачности и доступа к информации. Это основа современной экономики, составляющие части которой — свобода выбора и торговли.

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

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

Есть много хороших объяснений для глупости многих толп, и я исследую детально этот вопрос в своей книге «Культура и Империя», откуда была взята эта часть. Мало кто пытался объяснить глупость толпы с точки зрения коллективного интеллекта. А без ясного понимания правильного действия, как мы можем надеяться объяснить неправильное?

Поэтому очевидная неудача коллективного разума убеждает многих в том, что это лишь забавная теория, которая не применима на практике. И все же если мы посмотрим на онлайн-сообщества, например на те, которые формируются вокруг популярного open-source проекта программного обеспечения вроде ZeroMQ, мы увидим группы, очень похожие на описанные толпы Шуровьески. И пока, может быть, сложно опознать умные толпы в реальной жизни, кажется, что они являются доминирующей моделью онлайн. Пробы и ошибки позволили цифровому обществу заново открыть принципы умной толпы и перенять их в качестве своих базовых принципов действия.

Решение цифрового общества древней проблемы коррумпированной власти элегантно и успешно. Существуют буквально миллионы сообществ, каждое из которых полагается на власть своих основателей. Граждане цифрового общества свободно выбирают, какие власти уважать и какие игнорировать. Основной фокус заключается в принятии власти без наделения ее «правом» командовать.

К тому же возникает острая конкуренция по созданию справедливой власти, которая бы не командовала, а принуждала соблюдать необходимые правила. Это взрывоопасная истина. Поколения, которые познакомятся с этой моделью, не согласятся — даже под угрозой смерти — уважать модель индустриального общества, где, при необходимости, для убеждения могут использоваться железные занавесы и вооруженные пограничники, где граждане буквально принадлежат Государству.

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

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

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

Изучая материалы сайта Cult Information Centre (CIC), меня вдруг осенило, что все эти техники по промывке мозгов имеют несколько общих черт. Во-первых, они определенно нацелены на уничтожение того, что делает нас сильными — они атакуют независимое мышление и поведение. Во-вторых, они напоминают мне обстановку, в которой мне уже приходилось работать (крупный бизнес часто похож в своей деятельности на секту). В третьих, казалось, что все они реверсивные, т.е. их можно использовать в обратную сторону для благих дел.

Последнее наблюдение необычно. Если молоток разбивает окно, то вряд ли что-то изменится, если вы перевернете молоток. Но на некоторых примерах это наглядно видно. Вот одна из техник с сайта CIC: «Социальное давление в группе: подавляйте сомнение и сопротивление новым идеям, играя на потребности в принадлежности к группе». Реверс — снижение стоимости присоединения к группе и выхода из нее будет способствовать возникновению новых идей и критики». Или вот: «Исключение уединения — способность давать логическую оценку будет снижаться при отсутствии возможности размышлять наедине». Ее реверс: «предоставьте людям пространство и время для уединения, и они станут логичней размышлять».

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

В 2000 г. интернет еще не стал достаточно дешевым для масс, и open-source сообщества были маленькими, региональными, сосредоточенными вокруг университетов. Такие open-source сообщества как Debian Foundation до сих пор функционируют как классические некоммерческие организации, как легальные юридические лица с советом директоров, казначеями и пр.

В 2005 г. я стал участником ряда совместных проектов. С одной стороны, я был вовлечен в проект FFII, направленный на борьбу с патентами на программное обеспечение в Европе. Мы (хорошие парни) выступали в европейском парламенте, спорили с Европейским патентным офисом (плохие парни), организовывали семинары, предлагали поправки, собирали голоса и, вообще говоря, участвовали в сильнейшем лоббировании, которому когда-либо подвергался Брюссель.

С другой стороны, я занимался разработкой открытых стандартов, начиная с Advanced Message Queuing Protocol (AMQP). Культурный контраст между этими двумя организациями был очень сильным. FFII была группой безумных добровольцев, невероятно креативных, преисполненных холодной, жесткой решительностью остановить SAP, Siemens, Microsoft и Nokia (еще более плохие парни) в их стремлении изменить европейское законодательство с целью легализации серого рынка патентов на программное обеспечение. В рабочую группу AMQP входили банки и крупные компании-разработчики программного обеспечения, которые тоже оказались по-своему безумны, и при этом более неприглядны.

Оказавшись окруженным со всех сторон безумием, я вдруг опять подумал о важности исследований социальных инстинктов и сектантских техник. С моими друзьями из FFII мы запускали компанию за компанией. Сайты, петиции, рассылки по эл. почте, конференции… этому не было конца. Большинство из наших компаний не достигали достойного масштаба, лишь некоторые из них. Но что важнее, в течение трех лет мы экспериментировали и собирали информацию.

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

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

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

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

Отправная точка создания любого сообщества – формулировка его миссии. Она определяет цели, которые мы разделяем, еще до того, как присоединиться к проекту. Это как заголовок сайта или рекламный лозунг фильма. Например, заголовок у Reddit звучит так: «главная страница интернета» – амбициозная миссия, которая, тем не менее, выполнена. Слоган Фейсбука: «помогает вам связаться и поделиться с людьми в вашей жизни».

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

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

Реакция людей на миссию компании не должна быть «да, это благоразумно», а наоборот: «вы же это не серьезно, так?!». Миссия Википедии – "«бесплатная энциклопедия, которую любой может редактировать»", – хороший тому пример. Это было изначальной целью, поэтому все прочие, кроме считанных идеалистов, отнеслись к этому как к чему-то невозможному и бредовому. На это и был расчет Википедии: чтобы эти идеалисты однажды взошли на борт. Невозможные цели привлекают правильных людей к молодому проекту.

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

Чтобы сформулировать хорошую миссию, ориентируйтесь на одну основную проблему, которой посвящен ваш проект. Reddit, например, решает проблему того, как получить новости из интернета при слишком большом количестве ресурсов с интересной информацией. Его «основная страница» представляет собой цифровую газету 21-го века. Википедия решает проблему аккумулирования знаний миллионом умов. Слова «любой может редактировать» – так же, как и «Глас народа – глас Божий», – говорят о том, что если и возможно найти истину, то только сообща.

СОВЕТ: При намерении сделать что-либо, много или мало, всегда старайтесь начать с определения проблемы, которую вы хотите устранить. Только когда у вас будет четкая и реальная проблема, с наличием которой все согласны, только тогда приступайте к обсуждению возможных ее решений. Решение вымышленной проблемы схоже с группой без четкой миссии. У вас может быть несколько миссий, случайно или преднамеренно. Если миссии тянут сообщество в разных направлениях, это может кончиться плохо. Например, рост группы может потребовать вложений, что вступит в противоречие с позицией по вопросу прибыли. Если бы Википедия стала коммерческой организацией, с рекламой и комплектом высокооплачиваемых менеджеров, то это, по-вашему, привело бы к ее расширению или упадку?

В случае с ZeroMQ наша миссия звучала так: «Быстрейшая. Передача сообщений. Всегда». Это хорошее и почти невозможное решение проблемы, насчет существования которой мы все соглашались, а именно: доступные на тот момент технологии были медленными и неповоротливыми. В то же время, мы с моим партнером-основателем Мартином расходились в целях. Он хотел создать лучший из возможных программных продуктов, я же хотел создать крупнейшее из возможных сообществ. По мере того как росло число пользователей, его значительные изменения в коде ломали существующие приложения, доставляя всё более усиливающуюся боль.

В данном случае мы смогли сделать всех счастливыми (Мартин ушел, чтобы работать над созданием новой библиотеки, названной «Nano»). Тем не менее, если вы не можете разрешить противоречия, касающиеся миссии, они могут серьезно навредить проекту. Проекты могут вынести многие споры, а вот разногласия между основателями довольно травмоопасны.

СОВЕТ: Если основатели согласны, что «успех» определяется как «максимально возможное число участников», то в последующие годы это может помочь в сохранении целеустремленности. Это также облегчает измерение вашего успеха по мере развития.

Определившись с миссией, вам нужно протестировать ее в реальном мире. Это значит, вам нужно дать краткий, но убедительный ответ на ту проблему, на которую вы нацелились. Я называю это «посевом». Этот процесс преследует две основные цели. Во-первых, начать собирать идеалистов и первопроходцев (в основном тех, кто был настолько безумен, чтобы поверить вам) в сообщество. Во-вторых, доказать или опровергнуть вашу миссию.

Проекты могут кончиться неудачей по многим причинам. Но главная причина — основополагающая идея или миссия были не настолько удивительными, как того ожидали люди. Неудача – нормально, даже отлично, если только она не стоила нескольких лет вашей жизни. Посадить семечко и показать его только нескольким людям не достаточно, потому что большинство людей не будет критиковать. Из жалости. Однако попросите их потратить хотя бы несколько часов своего времени на то, чтобы сделать проект лучше, и если они не скажут «да», тогда вы поймете их настоящее отношение.

СОВЕТ: Привлеките к «посевному» проекту внимание публики и вдохновляйте людей присоединяться к нему с самого начала. Если люди вовлекаются в проект, скорее их продвигайте. А если этого не происходит, то считайте это знаком того, что ваша миссия может быть ложной. Используйте «посевной» проект, чтобы создать сообщество.

Когда люди соглашаются помогать вам, нужно обеспечить им место для совместной работы. Вам нужна «платформа для сотрудничества». Две моих самых любимых: Wikidot для информационных сообществ и GitHub для проектов по разработке ПО. Платформа должна быть бесплатной. С ней должно быть легко и в учебе и в работе. Ваш посевной проект должен быть виден анонимным участникам. Он должен работать для кого угодно, вне зависимости от его или ее возраста, пола, образования или местоположения.

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

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

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

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

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

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

Прозрачность очень важна для быстрого получения критики идей и прогресса в работе. Если несколько людей из команды отчаливают и работают над чем-нибудь вместе некоторое время, например пару дней, ничего страшного, но вот когда речь идет о неделях, тогда то, чем они занимаются, следует представить группе как свершившийся факт. Если один человек так поступает, то группа может просто отмахнуться от него. Но если двое или больше – становится сложным откреститься от плохих идей. Секретность и некомпетентность идут рука об руку. Группам, работающим втайне, не постигнуть мудрости.

СОВЕТ: Когда один человек делает что-то в темном углу – это эксперимент. Когда двое или больше делают что-то в темном углу – это тайный заговор.

В случае с ZeroMQ ушло несколько лет на то, чтобы создать по-настоящему открытую и прозрачную атмосферу. До этого главные участники работали тайно, публикуя свою работу только тогда, когда считали, что она готова к общественному обозрению. Но когда они это делали, остальному сообществу было сложно сказать «нет». И зачастую работа была не в тему… да, отличным решением проблемы, но до которой никому нет дела. В конце концов, мы недвусмысленно запретили подобные вещи.

Иронично, что тайна кажется неотъемлемой в некоторых бизнес-моделях. Прибыль часто приходит от игнорирования потребителей. Большинство коммерческих предприятий, даже такие большие сообщества, как Twitter, зависят от строгого разграничения «их» и «нас». Однако цифровое общество лучше всего растет, когда масштаб приоритетней прибылей и когда относится к пренебрежению как к проблеме, требующей решения. Если ваши клиенты не допускаются до ваших внутренних процессов, то вам будет закрыт доступ к пониманию, где в них кроются ошибки.

Деньги – забавная вещь. Слишком мало – и сообщество будет умирать с голоду (я вернусь к этому позже). Слишком много – начнется разложение. Необходимо понимать, почему каждый из участников вообще занимается этим. Какие у них экономические мотивы? Даже в добровольных сообществах каждый участник преследует свои интересы.

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

Когда вы работаете на кого-то, то будете делать то, что он или она хочет. Когда вы работаете на себя, вы делаете то, что нужно вам. Это огромная разница. Люди с деньгами, но без навыков или вкуса, – шелуха общества. Мы презираем оплачиваемых участников Википедии, платных блогеров и модераторов на Reddit, потому что мы знаем, что выражаемые ими мнения почти по определению ложь. Будет ли блогер, проплаченный Голливудом, критиковать новый летний блокбастер?

Я не имею ничего против наемных сотрудников. Однако если вы нацелены на создание наиболее крупного, наиболее успешного сообщества, то вам нужны участники, который будут стараться по честным, понятным причинам. Если кинорежиссёр приходит на Reddit обсудить фильм – здорово. Если его маркетологи заходят, чтобы потереть критические комментарии, это отвратительно.

СОВЕТ: один бесплатный участник стоит десяти оплачиваемых сотрудников.

Хорошие протоколы позволяют посетителям участвовать без предварительного одобрения. Они разрешают деструктивные конфликты и превращают их в полезные состязания. То, что анархисты могут присоединяться к умной толпе так же успешно, как и любой другой, объясняется тем, что толпа может разрабатывать свои собственные правила. Обычно эти правила касаются переработки материала, идентичности, рангов и т.д. Не важно, какая у них форма, хорошие правила просты, четки, ясно прописаны и всеми одобрены.

Если вы создаете проект в области программного обеспечения, вы можете взять существующее руководство, например, протокол C4, который мы сделали для ZeroMQ. Или же вы можете начать с минимумом инструкций и добавлять их по мере определения тех проблем, с которыми сталкивается сообщество. К слову, так было и с руководством Википедии. Некоторые правила должны быть установлены с самого начала (например, об авторских правах и участии). Другие могут быть придуманы по мере необходимости (например, процедура разрешения конфликтов). Сложные, бесцельные или не прописанные правила отравляют группу. Они создают пространство для споров, путают людей и повышают стоимость входа в группу или выхода из нее.

СОВЕТ: Пишите аккуратно ваши правила, начиная с лицензии на контент, и оценивайте, насколько они помогают людям. Изменяйте их по мере необходимости.

Без органов власти правила не имеют силы. Основатели сообщества и основные участники являются де-факто их представителями. Если они злоупотребляют своим положением, они теряют участников – и проект умирает либо разветвляется в зависимости от различных правил. Власть должна быть масштабируемая (то есть быть способной охватывать деятельность группы любого размера) и допускать передачу по мере роста и изменения группы.

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

СОВЕТ: Назначайте самых активных участников на административные посты и побыстрее. У вас есть небольшой промежуток времени, чтобы успеть сделать это, иначе они уйдут в другие проекты.

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

В сообществе ZeroMQ мы сражались из-за вопроса о том, кто мог определять правила, и в конце это привело к торговой марке и доменному имени. Человек или компания, которая владеет именем проекта, является верховной властью и может определять правила. Если они идиоты, то проект умрет.

СОВЕТ: Если вы инвестируете деньги в сообщество, рассмотрите вариант использования торговой марки в США, чтобы иметь возможность предотвращать использование другими людьми похожих имитирующих названий, которые не имеют к вам отношения. Это стоит около 750 долларов.

Членство должно быть символом объединения, а не служить удостоверением. Как часто отмечал Мистер Спок, эмоции не логичны. Некоторые группы руководствуются логически обоснованными целями, в других же правят эмоциональные факторы, такие как давление со стороны членов своего круга, стадный инстинкт и даже коллективная истерия. Определяющим моментом, видимо, служат отношения между группой и ее участниками. Мы может выявить это вопросом: участники «исключительно привержены» группе? Под исключительной приверженностью имеется в виду придание большего значения существованию группы, а не ее работе. Подобная приверженность заканчивается конфликтом с другими группами.

СОВЕТ: Держитесь подальше от формальных моделей членства, особенно тех, которые стараются превратить людей в собственность группы. Позволяйте анонимное или не персонализированное участие. Поощряйте людей создавать свои конкурирующие проекты – пространство для экспериментов и для изучения нового.

Группы индустриальной эпохи, словно культы, владеют своими членами. Сотрудник принадлежит компании. Даже идеи, которые пришли вам в голову под душем, – тоже собственность вашего работодателя. А когда группа владеет своими участниками, то мотивирует их страхом, ненавистью, завистью и злостью, подменяя сознательные логичные мотивы. Страх исключения широко используется для подчинения людей одному стандарту: «Делай, что я говорю, или я уволю тебя!».

СОВЕТ: Для определения того, насколько группа похожа на племя, просто начните конкурирующий проект. Если реакция на это отрицательная и эмоциональная, в группе доминирует родоплеменная парадигма. В группе со здоровой атмосферой аплодисментами встретят своих соперников.

Некоторым людям нравится, когда им говорят, что делать. Лучшие участники и команды сами выбирают себе задачи. Успешное общество распознает проблемы и само организуется для их решения. Более того, оно делает это быстрее и лучше, чем любая иерархически управляемая структура. Это значит, что сообщество должно принимать помощь в любой области, без ограничений.

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

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

В сообществе ZeroMQ мы избавились от назначения задач. Например, мы не принимали запросы о каких-либо особенных функциях. Если кому-то нужна была специальная функция, то он либо посылает нам патч, либо предлагает оплатить добавление изменений, либо он ждет. Это значит, что люди делают только те изменения, которые на самом деле нужно сделать.

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

В разношерстной группе возникают конфликтующие мнения, и здоровая группа эти конфликты охватывает и перерабатывает. Критики, иконоборцы, вандалы, шпионы и тролли держат группу в напряжении. Они могут быть катализатором вовлеченности остальных участников. Википедия процветает благодаря, а не вопреки, тем, кто кликает «Edit» с целью превратить статью в мешанину. Это классический антипаттерн, подавляющий идеи и взгляды меньшинства, используя предпосылку, что они «опасны». К тому же это неизбежно подавляет новые идеи. Логика обычно в том, что слаженность группы важнее ее разнообразия. Потом же получается так, что на ошибки не реагируют, а лишь еще больше обособляются. На самом деле, группа может быть важнее, чем результаты ее деятельности, если она многообразна и открыта новым аргументам. Это трудный урок, который полезен и обществу в целом: нет опасных суждений, есть опасные ответы.

То, как сообщества разбираются с троллями и вандалами, это одно. Разобраться с фундаментальными отличиями мнений – это другое. Ранее я говорил, что конфликтующие друг с другом миссии могут стать проблемой. Лучшее решение, которое я знаю, – это превратить конфликт в состязание. К примеру, браузер Google Chrome стал более легкой, более быстрой альтернативой Firefox, который становился раздутым и медленным. Тогда команда Firefox взялась за дело с умом, и теперь Firefox работает быстрее, чем Chrome.

СОВЕТ: Если есть интересная проблема, сделайте так, чтобы несколько команд соревновались, пытаясь решить ее. Соревнование — очень веселая штука, и может породить лучшие решения, чем монополистический подход. Вы можете даже организовывать соревнования с призами.

Все это хорошо: пытаться обратить конфликт в состязание. Однако вам необходимо обеспечить участников группы информацией о том, как хорошо они справляются. Лучшие инструменты, такие как GitHub, показывают точное число людей, которые наблюдают или отметили проект или начали проект-ответвление (отражены различные уровни интереса и приверженности).

Конечно же, Сеть всегда была озабочена «хитами» и анализом траффика, который показывает популярность сайта или страницы. Это облегчает измерение успеха онлайн-проекта. В старые времена индустриальной эпохи команды получали отзывы о своей работе от начальства. Что превращалось в ужимки перед властью: вас больше наградят за послушность, чем за прилежность. Делать начальство счастливым ради того, чтобы вам повысили зарплату, – не здоровое отношение.

СОВЕТ: Если ваша платформа не поддерживает этого напрямую, найдите возможности информировать ваших участников о том, насколько хорошо развиваются их проекты.

Существует много причин, по которым люди принимают участие в сообществах. Преобладающая мотивация – потребность в восхищении за достигнутый успех. Как индивидуумом, так и в составе команды. Успех относительное явление, поэтому нам требуется метрика, какой-то высокий балл, на который люди будут ориентироваться в своих стремлениях.

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

Reddit, как многие другие сайты, использует «карму», которая показывает, сколько голосов получил аккаунт за свои публикации и поведение. Работает это довольно неплохо. Некоторые сайты не показывают всю карму, чтобы предотвратить попытки людей обойти систему и получить более высокий балл. Некоторые сайты, такие как StackOverflow, до крайности увлекаются «геймификацией», используя ордена, высокие баллы, достижения и т.д. Мне кажется, это отдает манипуляциями и отвлекает от миссии сообщества. Люди должны принимать участие, стремясь к успеху проекта, а не к большому количеству игровых баллов.

Социальное обязательство – делать группы разных людей счастливыми – задача, приносящая огромное удовлетворение, и она не загрязняет планету. Индустриальное общество нацелено на материальные награды (выше зарплата, больше дом, лучше машина), увязанные с иерархической структурой. Оно эффективно, потому что все мы любим богатство или у нас комплекс неполноценности; какая бы ни была причина, желание сделать начальство счастливей значит принятие меньших рисков.

СОВЕТ: Когда люди просят вас сделать что-то, а вы не знаете как, тогда объявите публично, что это «невозможно». Или предложите решение настолько нелепое и безнадежное, что настоящие эксперты от возмущения возьмутся за дело.

В своей книге Сероуиеки (Surowiecki) объясняет, что катастрофа шаттла «Колумбия» произошла по причине бюрократии в иерархичной структуре управления NASA, из-за которой были проигнорированы мнения обычных инженеров. Если группа децентрализована, ее члены более независимы, они получают большее различных входных данных, и они с самого начала разнообразны.

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

СОВЕТ: Вам нужны собрания, чтобы добиться от группы работы? Это знак того, что у вас есть глубокие проблемы в совместной работе. Вы исключаете людей, которые физически не находятся рядом.

Бывает сложно отойти от старой модели совместной работы «обсуждение-действие». И, конечно, вам будет легче, если вы собираете группы с самого начала, а не пытаетесь изменить уже существующие.

Сообществу нужно пространство для роста. В реалиях интернета это обычно сайт или набор сайтов и сопутствующие структуры вроде списков эл. почты, блогов и т.д. Мы видим, что это становится очень дешевым или даже бесплатным способом создания «пространства» в цифровом обществе. Вопрос в том, могут ли индивидуумы создавать свои личные пространства внутри сообщества. Если да, будут ли они приносить больше пользы общему проекту?

Свобода создания структуры раздражает людей, которые считают, что это вносит хаос и беспорядок. Однако если вы используете обычные структуры (смотрите следующий пункт), ущербу участникам от этого нет никакого. А вот что вредно, так это создание структуры исходя из необоснованного мнения о ее пользе людям. Когда я возглавил ассоциацию FFII в 2005 г., предыдущим президентом было создано несколько сотен списков эл. почты, так он отмечал те проекты, над которыми, по его мнению, люди должны были работать. Это не соответствовало тому, как люди хотели быть организованы, и было очень сложно удалить эти списки и создать новые, которые нам на самом деле были нужны.

Конечно, группы индустриальной эпохи распределяли работу и ресурсы для ее выполнения. Любая новая инфраструктура – такая как сайт, список адресов эл. почты или вики – требует одобрения и решительности. Может даже потребоваться юридическая оценка авторских прав и патентов. Цена высока, поэтому люди неохотно идут на риск. Получается, что не экспериментируя и продолжая работать, они связывают себе руки.

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

СОВЕТ: Сделайте создание новых проектов для зарегистрированных пользователей максимально простым. Если проект создается пользователем, то не стоит беспокоиться насчет мусора. Если они находятся в общем пространстве, то вам могут потребоваться инструменты для очистки мусора и заброшенных проектов.

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

Запутанность отпугивает людей – очень сложно становится разобраться. Решением является использование стандартных структур, выучив которые раз, вы можете распознавать всегда. Подойдет не любая структура. Нам бывает сложно выучить структуры глубже трех-четырех уровней. Однако мы с радостью исследуем очень широкие системы с тысячами или миллионами блоков, если эти блоки соответствуют отдельным задачам или проектам.

Представьте себе город.

Успешные онлайн-сообщества – это города, а не замки. Википедия состоит из нескольких вики со специфичным языком, многие разбиты на миллионы страниц (проектов), каждая структурирована секциями, обсуждением, историей, примечаниями и т.д. Несколько людей могут работать над одной страницей одновременно или один человек может медленно править или заботиться о дюжине или сотне страниц.

GitHub управляет миллионами программных хранилищ («репозиториями»), сгруппированными по учетным записям пользователей или организаций, и каждый обладает своей структурой (файлы-исходники, документация и т.д.), что зачастую зависит от языка (Java-репозитории используют один стиль, С-репозитории – другой и т.д.). Один репозиторий может насчитывать несколько участников, люди могут работать с разным количеством репозиториев. Сообщество ZeroMQ является организацией, которая состоит из растущего числа проектов.

СОВЕТ: Спроектируйте ваше сообщество как город поддающихся поиску проектов, где любой может начать новый проект – проекты представляют, наверно, дюжину работ людей, и у всех схожая структура, насколько это возможно. Бизнес тяготеет к замкам, которые неизбежно будут посвящены Важным Персонам, а не проектам, и, конечно же, не основным проблемам бизнеса. Эти организации всегда огромны и нестандартны. И нет никакой возможности разобраться в них, кроме как запоминать каждую их деталь. Но и тогда вы не сможете с легкостью прогуливаться по замку, поэтому мало толку изучать его планировку.

Когда ZeroMQ только начинался, это был лишь один проект с единственной страницей README. Сегодня это сто или больше небольших проектов, каждый из которых имеет свою документацию, сообщество и динамику. Попасть в уже взрослый проект может быть трудно. Как я уже сказал, использование стандартных структур жизненно необходимо. Более того, вам потребуется проследовать по довольно специфической траектории при изучении, от легкого к более сложному, от стадии праздного посетителя до участника-эксперта. Считайте ваше сообщество компьютерной игрой, где сложность уровней возрастает соразмерно с выигрышем. Люди будут играть «в соответствии со своим уровнем». Если вы все делаете правильно, вы привлечете многих. Если неправильно, то эксперты будут скучать на легком уровне, а новичков отпугнет сложность на старте.

СОВЕТ: Используйте классические инструменты обучения – презентации, видео, ответы на часто задаваемые вопросы (FAQ), обучающие материалы – чтобы люди могли начать. Вам будет легче, если вы состоите в сообществе, потому что тогда вы можете посмотреть, какие вопросы чаще всего задают начинающие.

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

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

На своем опыте знаю, что лучше задать позитивный тон с самого начала. Конкуренты – это благо, т.к. дают на возможность состязаться. Подражатели – тоже хорошо, потому что подтверждают, что рынку вы нужны. Тролли и вандалы – отлично, ведь они дают искренним людям дополнительный шанс доказать свою полезность. И так далее. Кажется, что это трудно, искать позитивную сторону во всем. Однако это всего лишь образ мышления.

СОВЕТ: Добро пожаловать всем, за исключением безнадежных смутьянов. Их немного, тех, которые просто не могут найти себе место в открытом, разнообразном сообществе. Вы можете попросить таких людей уйти, или, если необходимо, забанить их.

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

Вы когда-нибудь задумывались, почему в человеке заложена потребность шутить, почему люди, которые никогда не смеются, кажутся странными и неприветливыми? Моя теория такова, что мы все используем юмор как способ разрядить ситуацию (что имеет очевидное преимущество для выживания). Люди не побьют шутника – только если шутка старая или плохо рассказана. Если серьезно, то юмор сводит на нет трайбализм и эмоции, и позволяет людям работать вместе, даже если они сильно отличаются друг от друга. Общая шутка может создать сильные связи, потому что она свидетельствует о схожести взглядов. Юмор является неотъемлемой частью общества и уменьшает стресс.

СОВЕТ: Чем более серьезную тему затрагивает ваше сообщение, тем больше вам потребуется юмора. В моей книге о ZeroMQ мной написано много глупой чепухи вперемешку с тяжелым описанием технической части. Многим это понравилось. Если бы не алкоголь, то хмурое выражение лица индустриальной экономики никогда бы не сменялось улыбкой. Она себя очень серьезно воспринимает. Недостаток юмора в организации – явный признак того, что все там фундаментально убого. Хуже всего, что тогда группа становится уязвимой для конфликтов и расколов.

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

Общее правило – делайте всегда тот минимум объема работ, которого будет достаточно, чтобы всё работало. Остальное будете делать, когда люди начнут использовать вашу работу и жаловаться. Это относится как к вашему посевному проекту, так и к каждому изменению, которое вы вносите. Обратная связь – в большей степени, чем ваше собственное мнение, – лучший указатель того, где следует приложить усилия.

СОВЕТ: Перфекционизм препятствует участию. Публикация на половину оконченной и содержащей баги работы – прекрасный способ привлечь людей к участию. Для больших эго это трудно принять, но изъяны лучше привлекают участников, чем совершенный труд, который привлекает пользователей.

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

Одно из моих сообществ, Digistan, было разработано, развито и достигло своего результата (формирование нового поколения узаконенных шаблонов и политических аргументов для открытых стандартов) где-то за шесть месяцев. Все наши протоколы в ZeroMQ основываются на работе Digistan. Open Web Foundation, занимаясь теми же вопросами, потратило два года только на регистрацию юрлица, определение устава и выбор сотрудников.

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

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

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

СОВЕТ: Каждый раз, собираясь потратить деньги на сообщество, поинтересуйтесь, не может ли кто-нибудь вам помочь с проблемой.

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

У каждой из этих групп есть разные мотивы для прихода в проект, присоединения к нему и, в конечном счете, ухода. Если мы возьмем такую захватывающую новую технологию, как ZeroMQ, мы сможем исследовать ее и понять, как она работает:

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

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

Ранее я подчеркивал ценность добровольной работы как более аккуратной, честной и творческой по сравнению с оплачиваемой работой. Однако здесь нужно сделать важную оговорку. Некоторые инструменты Социальной Архитектуры таят в себе опасность. Поставив людям захватывающую цель, вы можете подтолкнуть их в сторону саморазрушения. Это было главной проблемой в FFII (Foundation for a Free Information Infrastructure), когда я пришел туда, и ее усугублял высокий накал эмоций, характерный для родоплеменной корпоративной культуры организации в то время. Многие ключевые участники были изнурены и эмоционально истощены. Не понаслышке знакомое мне самому состояние.

Исследования эмоционального выгорания, о которых вы можете прочитать в Википедии, на мой взгляд, не соответствуют тому, что происходит в реальной жизни. А реальность всё-таки важнее теории. Я неоднократно наблюдал такую характерную особенность выгорания в добровольных сообществах:

Что приводит меня к мысли о том, что дело тут в проблеме оптимального вложения профессиональных усилий.

Люди много вкладывают в свои профессии, идут на большой риск, особенно в молодости в надежде на награду потом. Мы долгое время можем не придавать значения материальному вознаграждению, если мы уверены в том, что следуем верным путем. Например, молодой писатель или музыкант готов терпеть бедность многие годы, если он считает, что слава и богатство ждут его впереди.

И не важно, насколько пожухшая морковка свисает перед нами с палки — она всегда маячит у нас в подсознании. Мы по своей сути экономические животные. Вся жизнь — бухгалтерия. Мы превосходно умеем врать себе, но все же за каждым действием и решением стоит экономический мотив. Мы инвестируем в проекты, потому что чувствуем, что они будут способствовать нашему успеху, даже если на это уйдут годы. Мы соревнуемся с другими, пытаясь найти ниши, где наши таланты засияют во всей красе.

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

Подобное выгорание похоже на расплату (like a reckoning). Мы бросаем проект так, будто он вдруг стал ядовитым, словно поняли, что проглотили какой-то протухший кусок. Вот несколько способов снизить вероятность подобного развития событий:

Наверно, вы уже поняли, что я не сторонник одинокой гениальности. По большому счету это объясняется тем, что, несмотря на членство в организации Менса (крупнейшая, старейшая и самая известная организация для людей с высоким IQ), я помню, как совершал на удивление гениальные ошибки. Со временем я стал думать, что любое упоминание об индивидуальном интеллекте является опасно упрощенным мифом.

В нем всегда гениальные личности думают над важными проблемами, и в результате упорного труда они генерируют решения и шлифуют их до совершенства. Иногда они переживают «эврика-моменты», когда им открываются гениально простые ответы на сложные проблемы. Изобретатель, его процесс изобретения, исключительное, драгоценное явление, и остальным лучше не вмешиваться. История полна героями-одиночками. Мы обязаны им нашим современным миром.

Однако если присмотреться внимательнее, то станет понятно, что эта сказка не соответствует фактам. История не показывает одиноких изобретателей. Она рассказывает нам о везении людей, которые украли или присвоили себе право собственности на идеи, над которыми работали многие. Она полна примеров про гениальных людей, которые после удачного попадания тратят десятилетия на бесполезные и безрезультативные поиски. Самые известные крупные изобретатели вроде Томаса Эдисона были хороши в систематическом поиске, который выполнялся крупными командами. Это как заявить, что Стив Джобс изобрел каждую примочку, сделанную командой «Apple». Этот приятный миф годится для маркетинга, но он далек от истины.

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

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

Хотя, вот и альтернативная теория инноваций:

Есть несколько последствий этого:

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

Я собираюсь предложить инструмент по измерению интеллекта сообщества, другими словами, как точно и эффективно сообщество работает в любой взятый период времени. Он также показывает, насколько приятно будет участвовать в сообществе.

Для его демонстрации я ранжирую несколько сетей, организаций, сайтов и онлайн-сообществ. Это не наука, просто творческая и небрежная прикидка. Как всем известно, 87% статистики изобретается на месте, и 91% людей принимают это без вопросов. Я выбрал следующие жертвы:

Я не буду судить о ценности отдельно взятого сообщества. Это невозможно, и будет обманчиво. Миссия Твиттера — «набрать больше подписчиков» — звучит слабее, чем у Википедии «собираем знания всего мира». Однажды сформированная, умная и гибкая толпа может запросто создавать новые миссии, например «свергнуть диктатора». Онлайн-сообщество, возможно, ценно (для человечества) не благодаря своей продукции, а само по себе. В случае Википедии или ZeroMQ сложно отделить толпу от контента. А в случае Твиттера это очевидно. Контент — явление преходящее и зачастую бесполезное, а толпа — нет.

Я придумал такую оценочную таблицу:

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

На «Ars Technica» есть интересная статья о том, как Google понемногу закрывает Android. Это классическая игра Capture the Flag, которая ведется против open-source сообщества. Я собираюсь объяснить, как этот захват работает, и как его предотвратить.

Товарные знаки. Что это такое, нужны ли они вам и сколько они стоят? Это вопросы, которые часто возникают, когда мы создаем проекты с открытым исходным кодом. Товарные знаки могут быть ключом к защите проекта от злоумышленников. Тем не менее, в интернете мало советов. Итак, вот мое руководство по использованию товарных знаков в открытом исходном коде. Это практический совет, я не адвокат, и уж точно не ваш адвокат.

Вы знаете, что ZeroMQ является проектом с лицензией LGPL (примечание автора: мы склоняемся к Mozilla Public License v2, которая действует также, но является более простой). На самом деле это набор проектов, построенных вокруг корневой библиотеки libzmq. Я представляю эти проекты как расширяющуюся вселенную:

Libzmq, большинство биндингов и некоторые из внешних проектов присутствуют в «организации» сообщества ZeroMQ на GitHub. Эта организация «управляется» группой наиболее младших авторов биндингов. Там мало чем нужно управлять, т.к. оно почти самоуправляемо и в настоящее время конфликтов не наблюдается.

iMatix, моя компания, играет специфическую роль в сообществе. Мы владеем торговыми марками и следим за каждой, чтобы быть уверенными в том, что если вы скачаете пакет с названием «ZeroMQ», вы можете быть доверять его содержимому. Было несколько попыток несанкционированного использования имени: видимо пираты думали, что «свободное программное обеспечение» - значит ничейное и беззащитное. Прочитав эту главу, вы увидите, как серьезно мы воспринимаем работу, проделанную над нашим программным обеспечением (а под «нами» я имею в виду сообщество, а не компанию). iMatix поддерживает сообщество, следя за функционированием всего, что называется «ZeroMQ». Мы также вкладываем деньги и время в программное обеспечение и его развертывание.

Мы не занимаемся благотворительностью. ZeroMQ является коммерческим проектом и довольно прибыльным. Прибыль делится на большое количество людей, участвовавших в его развитии. Всё обстоит именно так, незамысловато: потратьте время на то, чтобы стать экспертом в ZeroMQ, или надстройте что-то полезное поверх ZeroMQ, и вы выиграете от роста как индивидуум, команда или компания. iMatix получает те же выгоды, что и все остальные в сообществе. Это взаимовыгодные отношения для всех, кроме наших конкурентов, которые понимают, что с этой угрозой им не справится и не миновать ее. ZeroMQ будет доминировать в будущем мире широко распределенного программного обеспечения.

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

Существуют два способа сделать по-настоящему масштабное программное обеспечение, как уже говорилось (по крайней мере, теми, кто читает это предложение вслух).

Первый способ

— бросить огромные объемы денежных средств и проблем на усмотрение умных людей и надеяться, что результатом будет не крест на вашей карьере. Если вы очень везучи, и создаете продукт, основываясь на огромном опыте, и вы смогли удержать команды в сборе, и не стремитесь к техническому совершенству, и впредь удача от вас не отвернется, это сработает.

Но азартные игры на чужие сотни миллионов подходят не всем. Для всех прочих, кто хочет создать масштабное программное обеспечение, есть

Второй способ

— open source, точнее, свободное программное обеспечение. И если вы спрашиваете, какая связь между лицензией программного обеспечения и его масштабом, то это правильный вопрос.

Гениальный и прозорливый Эбен Моглен (Eben Moglen) однажды сказал, что лицензия свободного программного обеспечения словно контракт, на основе которого строится сообщество. Когда я первый раз это услышал, около десяти лет назад, у меня появилась идея — можем ли мы целенаправленно строить сообщества?

Полученный десять лет спустя ответ — «да», более того, теперь это почти наука. Я говорю «почти», потому что у нас до сих пор нет достаточного количества доказательств того, что люди делают это целенаправленно, нет документации и уверенности, что этот процесс возможно точно воспроизвести. Именно это я и пытаюсь исправить с помощью Социальной Архитектуры. ZeroMQ появился после Wikidot, после Digital Standards Organization (Digistan) и после Foundation for a Free Information Infrastructure (FFII, негосударственная организация, которая борется против патентов на программное обеспечение). Все это появилось после множества менее успешных сообществ, вроде Xitami и Libero. Вывод, который я сделал из долгой работы с различными проектами, заключается в следующем: если вы хотите создать по-настоящему масштабное и долговечное программное обеспечение, стремитесь к построению сообщества свободного программного обеспечения.

Диркжан Октман (Dirkjan Ochtman) обратил мое внимание на определение архитектуры программного обеспечения в Википедии: «совокупность структур, требуемых для понимания системы, которая объединяет элементы программного обеспечения, связи между ними и их принадлежность». Для меня эта бессодержательная и цикличная болтовня служит хорошим примером того, как унизительно мало мы знаем о том, что на самом деле важно при создании масштабной архитектуры программного обеспечения.

Архитектура — это искусство и наука создания крупных искусственных структур, используемых человеком. Если я что и понял и успешно применял на протяжении тридцати лет при создании все более крупных систем программного обеспечения, так это то, что программное обеспечение — это все о людях. Крупные структуры сами по себе бессмысленны. Важно то, как они функционируют для использования их людьми. А в программном обеспечении, человеческое начинается с программистов, которые делают его.

Основные проблемы в архитектуре программного обеспечения кроются в человеческой психологии, а не в технологиях. Наша психология по-разному может влиять на нашу работу. Я могу привести примеры того, как группа людей словно становится глупее по мере того, как она расширяется, или когда им приходится работать, будучи разделенными огромным расстоянием. Значит ли это, что чем меньше команда, тем она эффективней? Как же тогда такое крупное глобальное сообщество как ZeroMQ умудряется успешно работать?

Сообщество ZeroMQ возникло не случайно. Его конструкция была целенаправленно разработана — мой вклад в те ранние дни, когда на чердаке в Братиславе появился код. Разработка основывалась на моем научном питомце, «Социальной Архитектуре», которую Википедия определяет как «сознательная разработка среды, которая поощряет проявление определенных паттернов социального поведения в целях достижения какой-либо цели или целей». Мое определение более конкретно: «процесс или продукт планирования, разработки и создания онлайн сообщества».

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

Итак, вот мой короткий список психологических элементов Социальной Архитектуры:

Эти стратегии годятся как для крупных, так и для маленьких организаций или команд.

Давайте обсудим спорный, но важный вопрос о том, какую лицензию выбрать. Я бы выделил «BSD» вместе с MIT, X11, BSD, Apache и прочими похожими лицензиями, и «GPL» с GPLv3, LGPLv3 и AGPLv3. Главным отличием является распространение прав на любые версии форков, что защищает любую организацию от захвата программного обеспечения, и тем самым делая его «свободным».

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

Вы можете спросить, зачем нам вообще нужны контракты при работе с open source? Ведь главное доброжелательность, бескорыстная совместная работа людей. Вы уверены, что принцип «лучше меньше да лучше» всегда здесь уместен? Не значит ли, что больше правил — меньше свободы? Нам на самом деле нужны адвокаты, чтобы рассказывать, как нам работать вместе? Кажется циничным и даже контрпродуктивным насаждать ограничения и правила в счастливом open source, в сообществе свободного программного обеспечения.

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

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

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

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

Альтернативной кажется вариант с поглощением проекта более крупной организацией, которая страхом потери обеспечения и бренда сможет сплотить команду. По своему опыту знаю, что у этого есть своя цена, и часто это заканчивается получением преимуществ более богатыми участниками (которые могут позволить себе иногда огромные расходы).

В open source проекте или проекте по свободному программному обеспечению, распад обычно принимает форму форка, когда сообщество разделяется на две или более группы, у каждой из которой есть свое видение будущего. Во время медового месяца, который может растянуться на годы, проекту не страшен разрыв. Но вот когда проект начинает стоить денег, или когда основные его авторы эмоционально выгорают, добросовестность и благородство улетучиваются.

Поэтому при обсуждении лицензий на программное обеспечение, когда речь идет о вашем коде или используемом вами коде, немного цинизма не повредит. Не задавайтесь вопросом: «какая лицензия привлечет больше последователей?», т.к. ответ зависит от формулировки миссии и процесса участия. Спросите себя: «если проект окончится боем и разделится на три части, какая лицензия спасет нас?». Или: «если всю команду подкупит враждебная фирма с целью присвоения себе кода, какая лицензия убережет нас?».

Долгое выживание требует быть стойкими в тяжелое время, но позволяет наслаждаться хорошими временами.

Когда BSD-проекты ветвятся, они не могут с легкостью слиться опять. На самом деле, когда возникает односторонний форк BSD-проекта, планомерно происходит следующее: BSD-код становится частью коммерческого проекта, вот что происходит. Когда же случается форк GPL-проекта, его слияние — обычное дело.

Приведу уместную здесь историю о GPL. Хотя сообщества программистов, работающих с открытым кодом, уже были широко распространены в 1980-х годах, они все еще использовали простые лицензии, которые работали до того момента, пока проект не начинал привлекать настоящие деньги. В то время был солидный текстовый редактор Emacs, изначально построенном на Lisp Ричардом Столлманом. Другой программист Джеймс Гослинг (который потом явил нам Java) переписал Emacs на С с помощью сообщников, предполагая, что он будет открытым. Столлман взял этот код за основу для своей С версии. Гослинг позже продал код компании, которая взяла и заблокировала возможность для кого бы то ни было распространение конкурирующего продукта. Столлман посчитал эту продажу совместной работы крайне неэтичным поступком и начал развивать многоразовую лицензию, которая бы защитила сообщества от подобного.

В итоге это вылилось в Универсальную общественную лицензию GNU (GNU General Public License), которая использовала традиционное авторское право для защиты возможности повторной переработки материла (ремиксабельности). Это был элегантный прием, который переняли и в других сферах, например, Creative Commons для фотографий и музыки. В 2007 г. вышла в свет версия 3 лицензии, которая была ответом на запоздалые атаки Microsoft и прочих. Она превратилась в длинный и сложный документ, но корпоративные специалисты по авторскому праву хорошо знакомы с ним, и на моей памяти очень мало компаний осмеливаются использовать программное обеспечении библиотеки под лицензией GPL, при условии, что границы обозначены четко.

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

Да, есть много процветающих BSD-проектов и много мертвых GPL-проектов. Обобщать всегда плохо. Судьба проекта зависит от многих причин. Однако в спортивных соревнованиях стоит использовать любые преимущества.

Другой важной чертой противостояния BSD и GPL является «утечка» — так я называю ее потому, что она напоминает мне процесс наполнения водой емкости, на дне которой есть отверстие, небольшое, но существенное для результата.

Вот вам история. Она произошла со старшим шурином двоюродного брата друга моего коллеги по работе. Его звали, и все еще зовут, Патрик.

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

Но однажды кто-то показал ему новый проект, под лицензией GPL, который представлял собой форк его работы с некоторыми улучшениями. Он был раздражен, расстроен и все спрашивал, как друзья по открытому коду! как они могли подобным бесстыжим образом украсть его код? Тогда было много долгих рассуждений о том, законно ли выпускать его BSD-код под лицензией GPL. Оказалось, что да. Он пытался игнорировать новый проект, но вскоре понял, что выходящие к нему новые патчи уже нельзя слить с его собственной работой!

Дальше хуже: GPL-проект стал набирать популярность, и некоторые основные последователи Патрика начали делать сначала небольшие, а потом все более солидные патчи к нему. И опять он не мог использовать эти дополнения, и тогда он почувствовал себя покинутым. Патрик впал в депрессию, его подружка ушла от него к валютному брокеру, которого, что забавно, зовут Патрис, и он перестал работать над проектом вообще. Он чувствовал себя преданным и до слез жалким. Он уволил своего друга, который воспринял это тяжело и потом всегда очень не лестно о нем отзывался («closet banjo player»). В итоге Патрик устроился на работу на должность проектного менеджера в облачной компании и к сорока годам совсем прекратил программировать ради удовольствия.

Бедный Патрик. Мне его почти стало жаль. Когда я спросил его: «Почему ты не выбрал GPL?», — он ответил: «Потому что ограничивающая вирусная лицензия». «Пусть у тебя и есть докторская степень и пусть ты старший шурин двоюродного брата друга моего коллеги по работе, но ты - идиот, и Моника правильно сделала, что бросила тебя. Ты опубликовал свою работу, предлагая людям украсть твой код, а когда люди сделали именно это, ты расстроился. Что еще хуже, ты вел себя лицемерно, ведь пока они делали это тайно, ты был счастлив, но когда они открыто заявили об этом, ты почувствовал себя, видите ли, покинутым».

Наблюдать за тем, как твою работу захватила более хитрая команда и использует ее против тебя — пытка, так зачем допускать такую возможность? Любой проприетарный проект, который использует BSD-код, захватывает его. Публичный GPL-форк, может показаться оскорбительным, но так вы точно не подставитесь.

BSD — словно лакомство. Я буквально (на самом деле метафорически) слышу шепот «выпей меня», таким тихим голоском, которым, бывает, говорит с вами бутылка лучшего пива в мире — а это, без сомнения, Orval, сваренное древним и почти исчезнувшим орденом молчаливых бельгийских монахов Les Gars Labas Qui Fabrique l’Orval. Лицензия BSD, как и его близкий клон MIT/X11, была специально разработана университетом (Калифорнийским университетом в Беркли) чтобы без корыстолюбивых побуждений выдать работу или усилия. Это был способ протолкнуть субсидируемые разработки по цене ниже себестоимости, ценовой демпинг с целью выхода на рынок. BSD — отличное стратегическое решение, но подходит только крупным, хорошо финансируемым институтам, которые могут позволить себе использовать Первый способ. Лицензия Apache — та же BSD, только в костюме.

Для нас, капитанов малого бизнеса, которые пересчитывают свои средства как последние пули, утечка работы или усилий не приемлема. Здорово было бы перекроить рынок, но мы не можем позволить себе субсидировать наших конкурентов. Сетевой стек BSD привел к появлению Windows в интернете. Мы не можем позволить себе битвы с теми, с кем мы по природе своей должны быть союзниками. Мы не можем позволить себе ошибки фундаментального бизнеса, потому что в итоге нам придется увольнять людей.

Все сводится к поведенческой экономике и теории игр. Тип лицензии, которую мы выбираем, влияет на экономику тех, кто использует нашу работу. В индустрии программного обеспечения есть друзья, враги и пища. BSD выставляет нас в глазах других обедом. Закрытый код — врагами (вам нравится платить людям за программы?). Однако GPL (за исключением Патриков сего мира) — союзниками. Любой форк ZeroMQ является лицензионно совместимым с ZeroMQ до того момента, когда мы поощряем форки в качестве ценных инструментов для экспериментирования. Да, кажется непривычным наблюдать как кто-то забирает у тебя игрушку и возится с ней, но вы можете в любой момент взять ее обратно.

Если вы до сих пор соглашались со мной — отлично! Теперь я объясню сам процесс построения open source сообщества. Вот как мы построили или вырастили или чутко ввели сообщество ZeroMQ в мир.

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

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

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

Вам нужна такая цель, которая будет достаточно безумной и простой, чтобы вытащить людей из кровати утром. Ваше сообщество должно привлекать лучших людей, а это требует чего-то особенного. В случае с ZeroMQ мы говорили, что мы собираемся создать «Быстрейшую. Передачу сообщений. Всегда», и это пример хорошего мотиватора. Если бы мы сказали, что мы собираемся сделать «изящный транспортный уровень, который соединит все движущиеся элементы вашего предприятия дешево и гибко», мы бы провалились.

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

Ваш труд должен быть простым для понимания, использования и присоединения. Слишком многие проекты обременены препонами для присоединения к ним: поставьте себя на место другого человека и увидьте причины, по которым он пришел к вам на сайт, думая «хм, интересный проект, но…», и потом ушел. Вы хотите, чтобы они остались и попробовали, хотя бы раз. Используйте GitHub и поставьте там трекер задач.

Если вы правильно все это сделаете, ваше сообщество будет умным, но что более важно, оно будет интеллектуально и географически разнообразно. Это на самом деле важно. Группа схоже мыслящих экспертов не сможет хорошо исследовать ландшафт проблемы. Они имеют тенденцию допускать большие ошибки. Разнообразие всегда превалирует над образованностью.

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

Вам потребуются хорошо написанные правила, разработанные кем-нибудь циничным, вроде меня, чтобы призвать незнакомцев к взаимовыгодному сотрудничеству вместо того, чтобы конфликтовать. GPL будет хорошим стартом. GitHub и с его стратегией «форк-слияние» будут хорошим продолжением. А потом вам потребуется что-то вроде нашей книги правил C4 для контроля того, как на самом деле осуществляется работа.

C4 (я использую ее теперь для каждого нового open source проекта) содержит детальные и проверенные ответы на большинство типичных ошибок, которые совершают люди: например, такой грех, как работа офлайн в укромном месте с другими «потому что это быстрее». Прозрачность имеет ключевое значения для обретения доверия, без чего в свою очередь не будет масштаба. Пусть каждое изменение будет на виду так же, как и весь процесс, и тогда вы сможете полностью доверять результатам.

Другим смертным грехом, в который впадают многие open source разработчики, является мнение о том, что они выше остальных. «Я основал этот проект, к тому же мой уровень интеллекта выше, чем у других». Это не только не скромно и грубо, а часто и неверно, это еще и плохая деловая среда. Правила должны распространяться на всех одинаково, без различий. Вы — часть сообщества. Ваша работа, как основателя проекта, заключается не в том, чтобы навязать ваше видение продукта остальным, а в том, чтобы установить хорошие, честные и соблюдаемые правила.

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

Идеи дешевы. А вот что является собственностью, так это та тяжелая работа, которые мы делаем, создавая рынок. «Как потопал, так и полопал» — это правильная модель для вдохновения людей на трудную работу. Будь то моральный авторитет в проекте, деньги за консультации, продажа торговой марки богатой и крупной компании: если вы сделали это, вы этим владеете. Но на самом деле ваш главный актив, который определяет ваш потенциал — «посещаемость», участники в вашем проекте.

Для этого потребуется неограниченное количество свободного пространства. К счастью, GitHub решил эту проблему за нас, так что на смертном одре я буду ему благодарен (в жизни слишком много вещей, за что я благодарен, и всё здесь не перечислить, т.к. у нас есть только сто страниц или около того, но это одна из таких вещей).

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

Поэтому в ZeroMQ мы стремились облегчить процесс написания биндингов поверх корневой библиотеки, а сами перестали пытаться их делать. Это дало возможность другим заняться этим, стать их владельцами и поставить себе это в заслугу.

Я бы хотел, чтобы сообщество было полностью самоуправляемо, и, возможно, когда-нибудь так и будет, но пока это не так. ZeroMQ близко к этому, но по моему опыту сообществу требуется четыре вещи:

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

Во-вторых, сообществам требуются правила жизни, и еще юрист, способный эти правила сформулировать и записать их. Правила критически важны — будучи хорошо составленными, они исключают трения. А неправильно составленные, или игнорируемые, приведут к раздорам и сложностям, которые отпугнут большую часть, оставив спорящую группу во главе горящего дома. Я сам пробовал создать универсальные правила для ZeroMQ и предыдущих сообществ, поэтому, наверно, нам не так уж и нужны юристы.

В-третьих, сообществам нужна некоторая финансовая поддержка. Эти острые рифы потопили не один корабль. Если вы держите сообщество на сухом пайке, оно будет более креативным, но ключевые участники будут эмоционально выгорать. Если вы вольете в него слишком много денег, то привлечете профессионалов, которые никогда не скажут «нет», и сообщество потеряет свое разнообразие и креативность. Если вы создадите общий фонд на раздачу, то люди будут бороться (и яростно) за него. В ZeroMQ мы (iMatix) тратили наши деньги и время на маркетинг и продвижение (вроде этой книги), а также на базовые вещи, например, на исправление багов, релизы и сайты.

И последнее, продажи и коммерческое посредничество также важны. Естественно, есть рыночные отношения между специалистами-участниками и потребителями, но и у тех и у других не очень получается общаться между собой. Потребители считают, что поддержка должна быть бесплатна или стоить очень дешево, ведь программное обеспечение свободное. Участники же слишком стесняются просить достойную плату за свою работу. Это затрудняет рыночные отношения. Все большая часть моей работы и прибыли моей компании обеспечивается деятельностью по соединению пользователей ZeroMQ, которым требуется помощь, с экспертами сообщества, способных ее оказать, таким образом, чтобы обе стороны были довольны результатами.

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

Лучшим решением, к которому я пришел, является сочетание двух пунктов. Первый — это GPL, т.к. она обеспечивает возможность повторной обработки материала (ремиксабельность). Не важно, насколько плохим будет руководство, не важно, насколько упорно оно будет стараться приватизировать и захватить работу сообщества — если она под лицензией GPL, то работа просто уйдет и найдет себе руководителей получше. Прежде, чем вы скажете «любой open-source предлагает тоже самое», подумайте. Я могу покончить с проектом с лицензией BSD, наняв ключевых участников и прекратив выпуск новых патчей. Но, даже имея миллиард долларов, я не могу убить проект с лицензией GPL. Второй пункт — отношение к руководству с позиции философии анархизма, которое проявляется в том, что мы выбираем руководство, оно нами не владеет.

Начиная с RFC 2119, в тексте про C4 четко указано, что он намерен выступать в качестве протокола, а не как случайно написанный набор рекомендаций. Протокол — это договор между сторонами, который определяет права и обязанности каждой стороны. Они могут быть знакомы в сети, или могут быть незнакомцами, работающими в одном проекте.

Я думаю, что C4 — это первый пример того, как кто-то пытался кодифицировать нормативы сообщества как формальную и многоразовую спецификацию протокола. Раньше наши правила были распространены на нескольких страницах вики и были во многом специфичны для libzmq. Но опыт учит нас, что чем более формальные, точные и многоразовые правила, тем легче становится незнакомым между собой людям сотрудничать. А меньшее количество разногласий означает более масштабируемое сообщество. Во время C4 у нас также было некоторое несогласие в проекте`libzmq`над тем, какой процесс мы использовали. Не все чувствовали себя связанными одними и теми же правилами. Скажем так, некоторые люди считали, что у них особый статус, и это создавало конфликт с остальной частью сообщества. Таким образом, спецификация сделала вещи понятнее.

Использовать C4 легко: просто разместите свой проект на GitHub, заставьте другого человека присоединиться и откройте функцию pull request. В своем README поместите ссылку на C4, и все. Мы сделали это в целом ряде проектов, и, похоже, это работает. Я не раз испытывал приятное удивление, применяя эти правила к своей собственной работе, например в проекте CZMQ. Никто из нас не бесподобен настолько, что мог бы работать без остальных.

Вкратце причина создания C4 заключалась в том, чтобы положить конец разногласиям в процессе сотрудничества в libzmq. Инакомыслящие ушли в другие места. Сообщество ZeroMQ плавно и легко расцветало, как я и предсказывал. Большинство людей были удивлены этому, но и удовлетворены. Не было никакой реальной критики C4, кроме ее ветвящейся политики, о которой я расскажу позже, поскольку она заслуживает отдельного обсуждения.

Есть причина, по которой я рассматриваю историю создания здесь: как основатель сообщества, вы просите людей инвестировать в вашу собственность, товарный знак и брендинг. В свою очередь, как мы и поступаем в случае с ZeroMQ, вы можете использовать этот брендинг, чтобы установить планку качества. Когда вы загружаете продукт маркированный «ZeroMQ», вы знаете, что он был выпущен по определенным стандартам. Это основное правило качества: запишите свой процесс; иначе вы не сможете его улучшить. Наши процессы не идеальны, они никогда и не станут таковыми. Но любой недостаток в них может быть исправлен и протестирован.

Поэтому очень важно сделать C4 пригодным для многократного использования. Чтобы узнать больше о наилучшем возможном процессе, нам нужно собрать результаты максимально широкого спектра проектов.

Целью номер один является размер и жизнеспособность сообщества — не техническое качество, не прибыль, не производительность, не доля рынка. Цель — просто количество людей, которые вносят свой вклад в проект. Наука здесь проста: чем больше сообщество, тем точнее результаты.

Возможно, худшей проблемой, с которой мы столкнулись в`libzmq`, была зависимость от людей, которые могли понять код, управлять ветками GitHub и делать чистые релизы — все в одно и то же время. Это похоже на поиск спортсменов, которые могут бегать марафоны и спринты, плавать, а также поднимать вес. Мы, люди, можем быть очень хороши, соблюдая специализацию. Просить нас быть действительно хорошими в двух противоречивых вещах не лучшая идея: это резко сократит число кандидатов, что плохо для любого проекта. У нас была эта проблема в`libzmq`в 2009 году или около того, и она была решена путем разделения роли Мейнтейнера на две: один человек делает патчи, а другой выпускает релизы.

Это теория — не полностью доказанная, но и не сфальсифицированная. Чем больше сообщество и число людей, которые могут участвовать в дискуссиях, не опасаясь быть подвергнутыми критике или увольнению, тем быстрее и точнее разрабатывается программное обеспечение. Скорость здесь довольно субъективна. Быстрое движение в неправильном направлении не просто бесполезно, оно сильно наносит ущерб проекту (а мы испытали много чего в`libzmq`, прежде чем перешли на C4).

Это занимательное влияние на процесс: git-ветка мастер обычно всегда идеально стабильна. Это связано с размером изменений и временем ожидания, т.е. периодом от написания кем-то кода до его полноценного использования кем-то еще. И все же нормальный процесс обучения проектировки обычно повторяется в проектах, пока не становится стабильным и незыблемым.

Любопытное наблюдение: люди, которые преуспевают в сложных ситуациях, любят повышать градус запутанности, потому что тогда они сохраняют свою высокую ценность. Это эффект Кобры (загуглите это). Git сделал ветви легкими и оставил нас со слишком распространенным синдромом «git прост, если вы понимаете, что ветвь git — это просто сложенное пятимерное лептонное пространство, которое имеет оторванную историю без промежуточного кеша». Разработчики не должны чувствовать себя глупыми из-за своих инструментов. Я видел слишком много высококлассных разработчиков, запутавшихся в структурах репозитория и не принимающих общепринятую мудрость о ветвях git. Мы скоро вернемся, чтобы разобраться с git-ветвями, дорогой читатель.

В конечном счете, все мы — экономические существа, и ощущение, что «мы владеем этим, и наша работа никогда не может быть использована против нас», значительно облегчает людям жизнь, чтобы инвестировать в проект с открытым исходным кодом, такой как ZeroMQ. И это не может быть просто чувство, это должно быть реальностью. Существует целый ряд аспектов для создания коллективной собственности, мы рассмотрим их один за другим, когда мы пройдемся по C4.

У Git есть свои недостатки. Его API-интерфейс командной строки ужасно непоследовательный, и у него сложная, неряшливая внутренняя модель, которой он тычет вам в лицо по любому поводу. Но, несмотря на то, что он делает все возможное, чтобы заставить своих пользователей чувствовать себя глупо, git делает свою работу действительно очень хорошо. Более прагматично, я обнаружил, что если вы держитесь подальше от определенных областей (ветвей!), люди быстро учатся git и не совершают много ошибок. Это подходит для меня.

Я уверен, что однажды какая-нибудь крупная фирма купит GitHub и сломает ее, и на ее место встанет другая платформа. До сих пор Github обслуживает почти идеальный набор минимальных, быстрых, простых инструментов. Я направил туда сотни людей, и все они до сих пор там, словно мухи, застрявшие в блюдце с медом.

Мы допустили ошибку в`libzmq`, перейдя на Jira, потому что мы тогда еще не научились правильно использовать трекер GitHub. Jira — отличный пример того, как превратить что-то полезное в запутанный беспорядок, потому что бизнес зависит от продажи большего количества «функций». Но даже не критикуя Jira, сохранение трекера задач на той же платформе означает, что на один пользовательский интерфейс, который придется учить, станет меньше, одним логином станет меньше, появится плавная интеграция между проектами и патчами.

Это плагин протокола: вставьте здесь правила стиля кода. Если вы не документируете стиль кода, который вы используете, у вас нет оснований, кроме предубеждений, чтобы отклонить патчи.

Теперь мы переходим к определениям сторон и разделению ролей, которые избавили нас от пагубной структурной зависимости от редких людей. Это хорошо работает в`libzmq`, но, как вы увидите, это зависит от остальной части процесса. C4 — не скатерть-самобранка, вам понадобится весь процесс (или что-то очень похожее), чтобы все не рассыпалось на части.

Чего мы хотели избежать, так это того, чтобы люди проталкивали свои изменения непосредственно в мастер-ветку. Это был самый большой источник проблем в`libzmq`исторически: большие массы сырого кода, на стабилизацию которых потребовались бы месяцы или годы. В конечном итоге мы следовали другим проектам ZeroMQ, таким как PyZMQ, с использованием запросов на загрузку. Мы пошли дальше и указали, что все изменения должны идти по тому же пути. Никаких исключений для «особых людей».

Мы должны были указать это прямо. Раньше было так: сторонники libzmq отказывались от патчей просто потому, что им это не нравилось. Теперь это может показаться разумным для автора библиотеки (хотя`libzmq`не был написан одним человеком), но давайте вспомним о нашей цели создания работы, которая принадлежит как можно большему количеству людей. Говорить «Мне не нравится ваш патч, поэтому я собираюсь его отклонить», это эквивалентно высказыванию: «Я утверждаю, что владею этим, и я думаю, что я лучше тебя, и я тебе не доверяю». Это токсичные сообщения для тех, кто думает стать вашими соинвесторами.

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

Я уже объяснил, как полная ремиксабельность (возможность повторной работы с материалом) создает лучший масштаб, и почему MPLv2 или GPL и их варианты кажутся оптимальным контрактом на ремиксабельное программное обеспечение. Если вы крупный бизнес, нацеленный на то, чтобы сбрасывать код на рынке, вам не нужен C4, но тогда вам и нет дела до сообщества.

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

Здесь мы подходим к основной причине того, что люди уверены в своем вкладе в ZeroMQ: логически невозможно купить авторские права на создание конкурента с закрытым исходным кодом для ZeroMQ. iMatix тоже не может этого сделать. И чем больше людей посылают патчи, тем сложнее это становится. ZeroMQ не просто свободен и открыт сегодня — эта его особенность позволит ему оставаться таким всегда. Обратите внимание, что это не относится ко всем проектам MPLv2 / GPL, многие из которых по-прежнему требуют возврата авторских прав своим мейнтейнерам.

Другими словами, мейнтейнеры не являются карма-бухгалтерами. Любой, кто хочет добиться одобрения, должен сам заявить об этом.

В этом разделе мы определяем обязательства Участника: в частности, что представляет собой «годный» патч, чтобы у Мейнтенеров были правила, в соответствии с которыми они могут принимать решения о принятии или отклонении патча.

В худшем случае, когда кто-то разместил вредный код (запатентованный или принадлежащий кому-то другому), мы должны уметь отслеживать, кто это сделал и когда, чтобы мы могли удалить код. Указывать настоящие имя или известный псевдоним — это теоретическая стратегия по снижению риска появления фиктивных патчей. Мы не знаем, работает ли это, потому что у нас еще не было проблем с этим.

Это реализация принципа Ориентированной на простоту разработки, про который я расскажу в этой главе позже. Одна явная проблема — одно минимальное решение, применение, тестирование, повторение.

Это просто здравомыслие. Я потратил время на очистку чужих патчей, потому что они настаивали на том, чтобы ставить else рядом с if, а не ниже, как того требует Вселенная. Последовательный код выглядит здоровым.

Ах, боль, боль. Я не говорю о том времени, когда мне было восемь лет, и я наступил на доску с торчащем из нее 4-дюймовым гвоздем. Это было еще ничего. Я говорю о 2010-2011 годах, когда у нас было несколько параллельных релизов ZeroMQ, каждый из которых имел разные несовместимые API или проводные протоколы. Это были упражнения в плохих правилах, бессмысленно соблюдаемых, которые и сегодня все еще причиняют нам боль. Правило гласило: «Если вы измените API или протокол, вы ДОЛЖНЫ создать новую основную версию». Проткните мою ногу гвоздем, это менее болезненно.

Одним из больших изменений, которые мы сделали с C4, является запрет подобного санкционированного саботажа. Удивительно, но это даже не сложно. Мы просто не разрешаем нарушать существующие публичные контракты, и точка, если только все не согласятся с этим, тогда да. Как сказал Линус Торвальдс 23 декабря 2012 года: «МЫ НЕ НАРУШАЕМ ПОЛЬЗОВАТЕЛЬСКОЕ ПРОСТРАНСТВО!»

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

Для кросс-платформенных проектов справедливо условие, чтобы патч работал в среде разработки, используемой Участником.

Это хороший формат для сообщений коммита, который подходит для эл. почты (первая строка становится темой, а остальная часть — телом письма).

Если вдруг это не понятно, возвращаемся к формулировкам и определениям.

В этом разделе мы поэтапно описываем процесс разработки.

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

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

«Проблема: нам нужна функция X. Решение: сделать это» — вот так не правильно. «Проблема: пользователь не может выполнять простые задачи A или B, кроме как с помощью сложного обхода. Решение: сделать функцию X» является достойным объяснением. Т.к. каждый, с кем я когда-либо работал, должен был усвоить это, то стоит еще раз повторить: сначала определяйте реальную проблему, а только затем ее решение.

И поскольку многие очевидные проблемы иллюзорны, ясно излагая проблему, мы даем другим возможность исправить нашу логику. «Вы используете только A и B, потому что функция C ненадежна. Решение: сделайте функцию C работоспособной».

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

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

Здесь мы объясняем модель GitHub fork + pull request, чтобы вновь прибывшим приходилось изучать только один процесс (C4), чтобы стать участником.

GitHub сделал это настолько простым, что нам не нужно для этого изучать команды git. Иногда я рассказываю людям, которые мне особенно не нравится, что командная строка git потрясающая, и все, что им нужно сделать, — это детально изучить внутреннюю модель git, прежде чем пытаться использовать ее в реальной работе. Когда я вижу их несколько месяцев спустя, они выглядят… измененными.

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

Случайно распределенные дискуссии могут сбивать с толку, но GitHub решает это для всех текущих участников, отправляя электронные письма тем, кто должен следить за тем, что происходит. У нас был тот же опыт и то же решение в Wikidot, и оно работает. Нет никаких доказательств того, что обсуждение в разных местах имеет какой-либо негативный эффект.

Работа через веб-интерфейс GitHub означает, что Pull Request’ы регистрируются как проблемы с рабочим процессом и обсуждением. Я уверен, что есть и более сложные способы работы. Все усложнить очень просто, а вот за простотой стоят огромные усилия.

Было правило, которое мы определили много лет назад, чтобы остановить выгорание людей: не менее двух человек на проект. Проекты одного человека, как правило, заканчиваются слезами или, по крайней мере, горькой тишиной. У нас довольно много данных о выгорании, почему это происходит и как его предотвратить (даже вылечить). Я расскажу об этом позже в этой главе, потому что, если вы работаете с открытым исходным кодом, вам нужно знать о рисках. Правило «не принимать свой собственный патч» преследует две цели. Во-первых, если вы хотите, чтобы ваш проект был сертифицирован C4, вам нужно взаимодействовать хотя бы с одним человеком, который мог бы помочь. Если никто не хочет вам помочь, возможно, вам нужно переосмыслить свой проект. Во-вторых, контроль за каждым патчем делает его намного более удовлетворительным, удерживает нас в правильном направлении и останавливает нас, если мы нарушаем правила из-за спешки или лени.

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

Существует критерий, который я называю период ожидания изменений, который равен периоду от определения проблемы до тестирования ее решения. Чем быстрее — тем лучше. Если Мейнтейнеры не могут реагировать на Pull Request’ы так быстро, как люди от них того ожидают, значит они не выполняют свою работу (или им нужно больше рук).

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

Обычная практика (пессимистичное слияние, ПС) – ждать, пока не будет окончено длительное интеграционное тестирование (CI), потом выполнить ревизию кода, потом протестировать патч в отдельной ветке, и позже отписать автору отзыв. Автор может исправить патч, и тогда цикл тест/ревизия запускается снова. На этой стадии мейнтейнер может сделать (и часто делает) ценное суждение вроде «мне не нравится, как вы это сделали» или «это не соответствует нашему видению проекта».

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

ПС характерно для большинства проектов, и я уверен, что в большинстве случаев не правильно.

Начну с перечисления проблем, которые создает ПС:

А теперь посмотрим, как все работает при Оптимистичном слиянии (ОС). Для начала необходимо понять, что не все патчи или участники одинаковы. В наших open source проектах мы наблюдали следующие четыре группы:

ПС утверждает, что все патчи вредоносные, пока не доказано обратное (4). А на самом деле большинство патчей полезны и стоят того, чтобы заняться их улучшением (2).

Посмотрим на сценарии ПС и ОС:

В любом случае у ОС результат лучше, чем у ПС.

В большинстве случаев (когда патчи требуют дальнейшей доработки) ОС создает условия для наставничества и менторства. И мы на самом деле наблюдали это в проектах ZeroMQ, и именно поэтому над ними так весело работается.

Когда один человек открывает задачу, а другой работает над ней, лучше позволит первому человеку закрыть задачу. Это будет двойной проверкой того, что задача была решена правильно.

По сути, целью здесь является позволить пользователям пробовать патчи, а не тратить время в спорах, обсуждая «за» и «против». Насколько легко сделать патч, настолько легко его откатить и применить другой. Вы можете предположить, что это приведет к «войне патчей», но такого не случалось. У нас было несколько случаев в работе с`libzmq`, когда патчи одного участника уничтожались другим участником, который чувствовал, что эксперимент не двигается в правильном направлении. Это легче, чем пытаться достигнуть консенсуса.

Держите трекер задач в чистоте.

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

Это процесс, который мы объясняем в этом разделе.

Понятно, что каждый патч что-то да добавляет, но не лишне об этом напомнить. Если мастер-ветка не развивается (и проходит свои тесты), кому-то нужно проснуться.

Вскоре я вернусь к веткам. Вкратце (или «tl;dr», как говорят в интернете), ветки делают репозиторий сложным и разреженным, требуют единогласия – все это дорого, и этого следует избегать.

Под «публичными контрактами» я подразумеваю API и протоколы. До конца 2011 года естественное счастливое состояние`libzmq`было омрачено нарушенными обещаниями и нарушенными контрактами. Мы полностью прекратили давать обещания (т.н. «дорожные карты») для`libzmq`, и наша доминирующая теория изменений теперь заключается в том, что они внедряются внимательно и аккуратно со временем. На встрече в Чикаго в 2012 году Гарретт Смит и Чак Ремес назвали это «пьяной спотыкающейся походкой в сторону величия», так я сейчас об этом думаю.

Мы прекратили нарушать публичные контракты, просто запретив эту практику. Раньше это было «хорошо» (как и в случае с нами, и все горько жаловались, а мы их игнорировали) — ломать API или протокол до такой степени, что нам приходилось менять номер версии. Звучит неплохо, пока вы не получите одновременно находящиеся в стадии разработки версии ZeroMQ 2.0, 3.0 и 4.0, не совместимые друг с другом.

Вы думаете, что это было придумано для профессиональных инженеров-программистов, но нет, это не так. Это — правило. Если вы хотите сертификации C4 для своего проекта, убедитесь, что ваши публичные договоренности задокументированы. Никаких отговорок вроде «это указано в коде». Код не является договором. (Да, я намерен в какой-то момент создать процесс сертификации C4, как индикатор качества проектов с открытым исходным кодом).

Так, на самом деле общественные договоры меняются. Дело не в том, чтобы не менять их, а в том, что менять их следует безопасно. Это значит обучать (особенно протокольных) разработчиков создавать для этих маневров пространство заранее.

Иногда патч исправляет плохой API, который никем не используется. Нам нужна свобода, но она должна базироваться на консенсусе, а не догматах одного человека. Однако делать рандомные изменения «просто потому что» не есть хорошо. В ZeroMQ v3.x разве мы выиграли от переименования ZMQ_NOBLOCK в ZMQ_DONTWAIT? Конечно, это ближе к POSIX сокету recv(), но разве это повод разрушать тысячи приложений? Никто никогда не заявлял это как задачу. Искажение цитаты Столлмана: «ваша свобода создавать идеальный мир заканчивается в дюйме от моего приложения».

В ZeroMQ мы раз или два сталкивались с новыми функциями, которые использовали старые имена (или хуже – имена, которые еще использовались где-то). В ZeroMQ v.3.0 был недавно представленный сокет «ROUTER», который был полностью другим, нежели существующий сокет «ROUTER» в 2.х. Господи, фейспалм, почему? Причина: очевидно, даже умных людей иногда стоит контролировать, чтобы они не совершали глупых поступков.

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

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

Ах, да, помню радость от того, что в ZeroMQ v3.x переименовали топовые функции API (zmq_send[3] и zmq_recv[3]) и выбросили старые названия новых методов, которые были крайне несовместимы (и которые, я подозреваю, мало кто использовал). Вы, должно быть, опять запутались, ударили себя по лбу, но это реально то, что произошло, и я был также виновен, как и все остальные. Ведь, в конце концов, мы же сменили номер версии! Единственная польза этого опыта была в том, что мы вывели это правило.

Кто-то должен управлять проектом, и имеет смысл, что учредители должны начать с этого.

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

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

Это было предложение Яна Барбера: нам нужен способ убирать неактивных Мейнтейнеров. Первоначально Мейнтейнеры были самоизбранными, но это затрудняет удаление нарушителей спокойствия (которые редки, но не неизвестны).

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

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

«Мы соорудили его над речным ущельем», — сказал он своему другу. «Оно было широким и глубоким. Мы потратили два года, изучая грунт и отбирая проекты и материалы. Мы наняли лучших инженеров и спроектировали мост, на что ушло еще пять лет. Мы наняли крупнейшие инженерные компании для создания структур, башен, контрольных постов и дороги, которые соединили бы мост с основными автомагистралями. Десятки человек умерли в ходе строительства. Ниже уровня дороги мы пустили поезда и проложили специальную дорожку для велосипедистов. С этим мостом связаны годы моей жизни».

Второй человек задумался ненадолго, а потом заговорил. «Как-то вечером мой друг и я, накидавшись водкой, решили перебросить веревку через ущелье», — сказал он. «Просто веревку, привязанную к деревьям. Там было две деревни, по одной на каждой стороне. Сначала люди тянули тюки по этой веревке, используя ремни и шкивы. Потом кто-то перебросил вторую веревку и сделал дорожку, по которой можно пройти. Она была опасной, но дети ее обожали. Потом группа людей переделала ее, сделав более крепкой, и женщины со своими изделиями стали ходить по ней каждый день. По одну сторону моста вырос рынок, который постепенно превратился в крупный город, т.к. там было полно места для домов. Веревочный мост заменили на деревянный, чтобы его могли пересекать лошади и повозки. Потом город построил настоящий каменный мост, с металлическими перекладинами. Позже они заменили камни сталью и сегодня на том самом месте — вантовый мост».

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

Когда я представлял ZeroMQ на конференции Mix-IT в Лионе (Франция) в начале 2012 г., меня несколько раз спросили про «дорожную карту». Мой ответ был: нет больше дорожной карты. У нас они были, и мы их ликвидировали. Вместо нескольких экспертов, пытающихся определить следующие шаги, мы позволили событиям развиваться естественным путем. Аудитории не очень понравился мой ответ. Слишком не по-французски.

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

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

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

В итоге мы столкнулись с травматическими изменениями в ZeroMQ, от которых дорожные карты нас не уберегли, несмотря на кучу сил и слов, потраченных на то, чтобы «делать все правильно». Результатом этого стали несовместимые изменения в API и протоколах. Было ясно, что нам нужен новый подход, определяющий процесс внесения изменений. Разработчикам программного обеспечения не нравится идея о том, что мощные, эффективные решения могут появляться без того, чтобы умные разработчики их тщательно выверяли и обдумывали. И все же тогда в Лионе никто не поставил бы под вопрос эволюцию. Это странно и иронично, поэтому далее я еще поразмышляю об этом явлении, ведь на его основе сообщество ZeroMQ развивается с начала 2012 года.

В главенствующей теории инноваций говорится о том, что гениальные индивидуумы, обдумав проблемную ситуацию, выдают точное и аккуратное решение. Иногда у них случаются озарения в стиле «эврика!» — и решение готово. Изобретатель и сам процесс изобретения редкие, драгоценные, единоличные. История знает многих таких героев-одиночек. Мы обязаны им нашим современным миром.

Однако приглядевшись внимательней, вы увидите, что тут кое-что не сходится. История не повествует об одиноких изобретателях. Она рассказывает нам о людях, которым повезло, которые украли или присвоили себе авторство над идеями, появившимися в результате труда многих других людей. Она рассказывает нам о гениальных людях, которые сделали удачный ход, а потом проводили десятилетия в безрезультативных и бессмысленных поисках. Такие крупные и известные изобретатели как Томас Эдисон на самом деле были хороши в систематизации разнообразных исследований, выполняемых большими группами ученых. Это похоже на утверждение о том, что Стив Джобс придумал каждый девайс, созданный Apple. Неплохой миф, хорош для маркетинга, но абсолютно бесполезный для практики.

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

Поэтому, вот альтернативная теория инноваций:

Из этого следует:

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

Можем ли мы применить вышеописанную теорию на практике? В конце 2011 г. я начал документировать C4 и похожие контракты и использовать их в ZeroMQ и в проектах с закрытом кодом. Лежащий в основе процесс я называю «Ориентированной на простоту разработкой» («Simplicity Oriented Design», SOD). Это воспроизводимый способ разработки простых и элегантных продуктов. Он организует людей в гибкие цепочки поставщиков решений, которые могут быстро и дешево сориентироваться в проблемной области. Они делают это, создавая, тестируя и сохраняя минимальные приемлемые решения, называемые «патчами», или отказываясь от них. Жизнеспособные продукты состоят из длинной череды патчей, применяемых один поверх другого.

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

Чтобы лучше понять то, как мы пришли к SOD, давайте рассмотрим альтернативы.

Наиболее популярным типом разработки в крупных организациях является «Мусоро-ориентированная разработка», или сокращенно TOD («Trash-Oriented Design», TOD). TOD основывается на убеждении, что для того, чтобы делать деньги нам нужны крутые идеи. Это упорно всплывающая чушь является мощным костылем для тех, кто лишен воображения. Теория гласит так: идеи редки, поэтому весь фокус в том, чтобы схватить их. Словно далекие от музыки люди восторгаются гитаристом, не понимая, что великие таланты настолько дешевы, что они буквально играют на улицах за копейки.

Основным выхлопом TOD является дорогостоящее «мышление»: концепции, инженерная документация и продукция, которая отправляется прямиком в мусорное ведро. Получается это так: приходят Творческие Люди с длинным списком «мы можем сделать X и Y». Я видел бесконечно детализированные списки всех тех удивительных вещей, которые мог бы делать продукт. Мы все были повинны в этом. Как только свершилась творческая работа по генерации идей, то дело лишь за исполнением их.

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

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

Тогда погоняемые кнутом и униженные инженеры бредут обратно в свои берлоги, чтобы строить гигантскую и «очень изящную» рухлядь. И работа эта надрывная, потому что эксизы не учитывают реальные трудозатраты. Даже мелкие капризы могут обернуться неделями работы. По мере того, как проект замедляется, менеджеры вынуждают разработчиков работать сверхурочно по вечерам и выходным.

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

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

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

А в это время еще один менеджер-визионер где-то там в организации наливает себе точно лишний стаканчик текилы и рассказывает сотрудникам отдела маркетинга о своей Гениальной Идее.

TOD мог бы быть карикатурой, если бы не был так распространен. Около девятнадцати из двадцати продуктов, готовых к выпуску на рынок большими компаниями, ждет провал (да, 87% статистики делается на месте). Из двадцати лишь один возможно преуспеет, да и то благодаря агрессивной рекламе и слабости конкурентов.

Основная мораль TOD ясна, но трудноусвояема: идеи дешевы. Без исключений. Не существует гениальных идей. Любой, кто начинает разговор со словами «О! Еще мы можем сделать вот это!» должен быть побит с рвением странствующих евангелистов. Это тоже самое, что сидеть в кафе у подножия горы, пить горячий шоколад и говорить другим: «Эй, у меня есть классная идея, мы ведь можем взобраться на эту гору! И построить там на вершине прекрасный дом! С двумя саунами! И садом! Эй, а еще мы можем обеспечить его электричеством с помощью солнечных батарей! Чувак, это же круто! В какой цвет мы его покрасим? В зеленый! Нет, в синий! Ок, идите и сделайте это, а я пока побуду тут и займусь таблицами и графиками!».

Для хорошего начала успешного процесса разработки соберите реальные проблемы, с которыми сталкиваются люди. Вторым шагом будет оценка этих проблем с помощью основного вопроса «Во сколько обойдется решение этой проблемы?». После этого можно сделать список проблем, которые стоит решать. Хорошие решения реальных проблем будут успешным продуктом. Их успех будет зависеть от того, насколько хороши и дешевы решения, и насколько важна проблема (и, к сожалению, насколько большие расходы на маркетинг можно себе позволить). Но их успех будет также зависеть от того, сколько усилий требует их применение, другими словами насколько простыми они будут.

Теперь, сразив дракона абсолютной бесполезности, атакуем демона сложности.

По настоящему хорошие команды разработчиков и маленькие компании могут обычно заниматься созданием приличных продуктов. Но большая часть продуктов все равно получится слишком сложными и менее успешными, чем могли бы быть. Это все потому, что команды специалистов, даже лучшие из них, часто упрямо практикуют «Ориентированную на сложность разработку» («Complexity-Oriented Design», COD), как я ее называю. И работает она так:

Для COD характерны команды, которые одержимы решением неправильных проблем и которые подвержены коллективной мании.

Продукты COD обычно крупные, амбициозные, сложные и непопулярные. Многое из программного обеспечения open source является следствием COD. Для разработчиков безумно сложно остановиться и прекратить расширять проект с целью охватить еще и еще потенциальных проблем. Они спорят: «А что, если кто-то захочет сделать Х?», но они никогда не спрашивают себя: «Сколько на самом деле стоит сделать Х?».

Хорошим примером COD на практике оказался Bluetooth, сложный, с излишне-усложненной конструкцией комплект протоколов, которые пользователи ненавидят. Он продолжает существовать только потому, что в сплошь запатентованной отрасли нет реальных альтернатив. Bluetooth прекрасно защищен, что почти бесполезно для бесконтактного протокола. В то же время ему не достает стандартного API для разработчиков, что значит, его реально накладно использовать в приложениях. На канале групповых дискуссий #zeromq участник Wintre однажды написал, как он был взбешен, обнаружив, что в XMMS 2 была рабочая plugin система, но он не мог проигрывать музыку.

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

Основные уроки COD просты, но горьки на вкус:

Наконец, мы подошли к редкой и ценной Ориентированной на простоту разработке (Simplicity Oriented Design, SOD). Этот процесс начинается с реализации: мы не знаем, что мы должны сделать, пока не начнем делать что-то. Выдвижение идей или крупных проектов не просто бесполезно, а мешает разрабатывать по-настоящему точные решения. Действительно лакомые задачи спрятаны, как заветные оазисы, и любая деятельность, кроме разыскивания их, лишь больше окутывает их туманом. Вам нужно быть мобильным, двигаться быстро и налегке.

SOD работает следующим образом:

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

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

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

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

В open source проектах мы делаем эту работу публично. Нет такого момента «а давайте откроем код». Когда так делают, по-моему, это говорит о том, что люди не понимают смысл open source проектов — вовлечь пользователей в ваше исследование и построить сообщество вокруг основной архитектуры.

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

С другой стороны, не все проекты столь удачны и, если вы работаете с open source, то должны понимать риски, связанные с эмоциональным выгоранием участников. Это относится ко всем сообществам, основанным на добровольном участии. В этой главе я объясню что именно вызывает выгорание, как его распознать и предотвратить, и, если это всё-таки произошло, как его преодолеть. Дисклеймер: я не психиатр и эта статья основывается на моём собственном опыте работы в сообществах добровольцев на протяжении 20 лет, включая проекты свободного программного обеспечения и общественные некоммерческие организации, такие как FFII.

Когда мы говорим о добровольном участии, мы подразумеваем работу без прямого или косвенного экономического вознаграждения. Мы жертвуем личной жизнью, профессиональным развитием, свободным временем и здоровьем, чтобы достичь той цели, которую…​ решили достичь. В любом обычном проекте нам нужно какое-то вознаграждение, чтобы продолжать заниматься им изо дня в день, тогда как в большинстве добровольных проектов вознаграждения носят косвенный и, как правило, неденежный характер. Как правило, когда мы далаем что-либо на добровольной основе, нам достаточно лишь услышать в ответ "Эй, это очень круто!". Карма - это мощный мотиватор.

В тоже время, если мы, как экономические агенты, вкладываем значительные усилия в проект и при этом не получаем за это никакого вознаграждения(денег, славы, новой работы), то начинаем страдать. На каком-то этапе начинает казаться, что наше подсознание просто испытывает отвращение, говорит "С меня хватит!" и отказывается идти дальше. И если мы пытаемся заставить себя, мы становимся по-настоящему больны.

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

Когда я сгорал на проектах с открытым исходным кодом, таких как Xitami, я отчетливо помню, что чувствовал. Я просто перестал работать, отказался отвечать на электронные письма и сказал людям забыть об этом. Это заметно. Они отключаются, и все вокруг начинают говорить: "Он ведет себя странно…​ подавлен или устал…​"

Диагноз прост. Много ли кто-то работал над проектом, который никак не окупался? Принесла ли она исключительные жертвы? Он потерял или бросил свою работу или учебу, чтобы сделать проект? Если вы отвечаете "да", то это выгорание.

Есть три простых метода, которые я разработал за эти годы, чтобы снизить риск выгорания в командах, с которыми я работаю:

Когда кто-то работает в одиночку над критическим проектом, //знайте// - они рано или поздно слетят с катушек. На самом деле это довольно предсказуемо: что-то вроде 18-36 месяцев в зависимости от человека и того, с каким экономическим стрессом он сталкивается в своей личной жизни. Я не видел, чтобы кто-нибудь выгорал ни за полгода, ни за последние пять лет в проекте без экономических стимулов.

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

Я завершу эту главу серией шаблонов поведения для достижения успеха в разработке программного обеспечения. Они стремятся включить всё, что отделяет успех от славной трагической неудачи. Они были написаны за один день как “религиозно-маниакальные догматы” руководителем и “всё остальное безумное” — коллегой. Для меня они являются наукой. Но относитесь к Ленивым перфекционистам и другим инструментам так, как вы относитесь к обычным инструментам — заточите их, используйте и выбросите, если подвернется что-то получше.

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

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

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

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

Идеальная команда состоит из двух частей-сторон: одна для написания кода, другая для обратной связи.

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

Точность знаний приходит из разнообразия.

Открытая дверь принимает вклад в дело от почти любого. Она не рассуждает о качестве или направлении, взамен позволяя другим поспорить и проявить более активное участие. Она рассчитывает, что даже тролль принесет разнообразие в мнение группы. Она позволяет формировать группе свое мнение о том, что сделает код стабильным, и применяет эти решения с помощью Доброжелательного тирана.

Совершенство исключает участие.

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

Ничего не планируйте. Разрабатывайте стратегию и тактику, а не ставьте цели.

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

Если вы знаете своего врага и знаете себя, вам не нужно бояться и ста сражений. — Сунь-Цзы

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

Тот победит, чья армия воодушевлена единым духом во всех своих рядах.— Сунь-Цзы

Преданный садовник выращивает процесс из маленького семени, шаг за шагом, с каждым новым человеком, приходящим в проект. Он вносит каждое изменение, имея точную причину и согласие ото всех. Он никогда не “спускает причину сверху”, но позволяет другим прийти к консенсусу, а затем обеспечивает соблюдение этого консенсуса. Таким образом, каждый владеет и управляет процессом и управляется в нём: они прикреплены к нему.

После пересечения реки, вы должны оказаться вдалеке от нее. — Сунь-Цзы

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

Код, как и все знания, лучше всего работают как частная неколлективная собственность.

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

Вода формирует свой курс в зависимости от грунта, по которому протекает.— Сунь-Цзы

Флешмобы объединяются вместе в пространстве и времени по мере необходимости, а затем эти объединения очень быстро исчезают. Физическая близость имеет большое значение для связи с высокой пропускной способностью. Но со временем это создает технические гетто, где Земля отделяется от Неба. Флешмоб старается собрать много “частых пассажиров”.

Боль, как правило, не является хорошим знаком.

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

Никогда не мешай другим совершать ошибки.

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

Сохранение общих записей может быть утомительным, но это единственный способ избежать сговора.

Историк принуждает к публичному обсуждению, чтобы избежать “сговора” на его поле деятельности. Пиратская банда подразумевает полные и равные коммуникации, которые не зависят от сиюминутного присутствия. Никто не читает архивы, но просто сама вероятность останавливает большинство от злоупотребления. Историк поощряет правильный инструмент для работы: электронная почта для быстрых обсуждений, IRC для болтовни, вики для знаний, а отслеживание ошибок для записи на всякий случай.

Когда человек знает, что будет повешен через две недели, это невероятно концентрирует мысли.— Сэмуэль Джонсон

Провокатор создает дедлайны, врагов, а иногда и невыполнимое. Команды работают лучше, когда у них нет времени на фигню. Крайние сроки объединяют людей и сосредотачивают коллективный разум. Внешний враг может сподвигнуть пассивную команду к действию. Провокатор никогда не принимает дедлайн слишком серьёзно. Продукт всегда готов к отправке. Но это немного напоминает пропасть с кольями: одна ошибка, и мы все ищем новую работу.

Когда люди спорят или жалуются — просто отправьте им цитату Сунь-Цзы. — Микко Коппанен

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

Согласно Википедии, «Живые Системы» — “это сущности, состоящие из самоорганизующихся элементов, активно взаимодействующих с окружающей средой. Эти системы поддерживаются благодаря потокам информации, энергии и веществ.” Данный термин был предложен психологом Джеймсом Гриером Миллером для обозначения концепций жизни.

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

Хочу сказать, что “психология программного обеспечения — это психология людей”.

Сегодня большинство программных продуктов хорошо спланированы, но они не становятся «Живыми Системами». Они неумолимо проваливаются на стадии доставки, будучи проданными силой или обманом. Для того, чтобы программное обеспечение стало «Живой Системой», оно должно использоваться организацией, которая его разрабатывает, и тогда оно «живет» или «умирает» вместе с этой организацией. «Организация» может быть чем-то большим, чем компания или команда. Она может включать в себя тысячи команд, предприятий, клиентов и поставщиков, состоящих в необъяснимых, но реально значимых связях.

Ничто не демонстрирует это так наглядно, как интернет, который является «Живой Системой» из программного обеспечения, людей, предприятий и других организаций. Организация, создавшая интернет, представляет собой ни что иное как само по себе человеческое общество. Существует множество «Живых Систем», достаточно посмотреть вокруг. Это удивительно простая истина: чем лучше качество создаваемых нами крупномасштабных систем программного обеспечения, тем больше они напоминают окружающую нас реальность.

Существуют также спланированные системы, которые представляют собой полную противоположность Живым Системам. Гораздо легче спланировать систему, чем вырастить ее. Однако планы неминуемо строятся на ложных предположениях и недальновидных решениях. Спланированные Системы в каком-то смысле выглядят привлекательными и эффективными, однако, они неизбежно терпят поражение. В жизни можно встретить много подобных примеров: колхозы, спланированные города, Microsoft Windows 8 и так далее.

В программном обеспечении это разделение на живое и спланированное лучше всего отражено в противостоянии свободного и закрытого программного обеспечения. Свободное программное обеспечение (и его брат открытый исходный код) обычно формируется при реальном использовании, в то время как закрытый исходный код обычно спланирован. Это является главной причиной того, почему я не работаю с закрытым исходным кодом: его “смерть” скора и ожидаема. Я предпочитаю, чтобы моя работа сохранялась так долго, как это только возможно.

Я сделаю несколько резких заявлений, начиная с: самые успешные крупномасштабные системы программного обеспечения — “Живые Системы”. Так, в условиях конкурентного рынка, живая система безусловно победит спланированную. Она гораздо быстрее, дешевле и точнее выявит и решит серьезные проблемы. Если в основе вашего бизнеса лежит Спланированная Система, то он уязвим, так как вам не справиться с атаками Живой Системы.

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

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

Живая Система состоит из слабосвязанных компонентов. Она находится вне пространства (таким образом, “распределена”) и времени (таким образом, «асинхронна”). Это значит, что многие процессы происходят в неожиданных местах, в непредсказуемое время. Для главного плановика это представляется опасным хаосом.

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

Спланированную Систему мы строим, а живая — развивается сама. Моя цель — понять и научить, как искусственно создать живую систему. Я изучаю факторы развития, модели ухода и движущие силы саморазвивающейся системы. На самом деле я говорю о создании искусственной жизни и искусственного разума, но в форме, непривычной для исследователей искусственного интеллекта. Я считаю, что отдельные компоненты — включая вас и меня — не могут быть “умными”, если только в узком и поверхностном смысле: ведь интеллект это свойство, присущее только системам.

Живые Системы характеризуются отсутствием центрального планирования или принятия решений. Посмотрите на проект по разработке программного обеспечения и спросите “кто дизайнер?” Если там есть конкретный дизайнер (а он почти всегда есть) — будь то отдельный человек или организация, то это Спланированная Система. В Живой Системе нет ни дизайнеров, ни планов работы, ни каких-либо определенных планов на будущее, кроме как “выживать и развиваться”.

Живая Система больше похожа на свободный рынок Адама Смита, чем на пятилетку Сталина. Экономика, политика, психология так же важны — наверное, даже более важны — в процессе развития Живой Системы, как и технологии. Свободный рынок зависит от таких ключевых положений как: четкие законы, стандарты, контракты и справедливое управление. Работа Живой Системы зависит от этих же положений.

Живая система не имеет центрального планировщика, но может иметь центральные регуляторы. Позвольте мне объяснить разницу. В планируемом городе комитет решает где строить школы, дома, фабрики, офисы, железнодорожные станции, магазины, спортивные сооружения и так далее. В Живом городе все это решается независимыми агентами (школьными советами, предприятиями, домовладельцами и т.д.), а город обеспечивает их электричеством и чистой водой, производит утилизацию мусора и т.д.. Помимо этого, в городе работают полиция и суды для противодействия преступникам и мошенникам.

Управляющий орган принимает законы, которые определяют справедливый рынок, а затем претворяет их в жизнь. Единицы измерения, валюты, контракты и многое другое. В системах программного обеспечения таковыми законами, например, являются лицензия на исходный код или правила участия(contribution policy). Справедливый рынок позволяет любому создавать новое предприятие и конкурировать с другими. Для создания реальной конкуренции (то есть свободного выбора клиентов), клиенты могут запрашивать четкие контракты, которые в программном обеспечении являются задокументированные программные интерфейсы приложений и протоколы.

ДНК Живых Систем это, по сути, набор регулируемых контрактов. Так, интернет развивается из набора Рабочих Предложений (RFCs (protocols called Requests for Comments)), которые регулируются Инженерным Советом Интернета (Internet Engineering Task Force (IETF)). “Живые города” развиваются благодаря уголовному и гражданскому праву, установленных стандартов относительно воды, энергии и отходов, транспорта и так далее.

Если бы все были честными, необходимости в управлении и регулировании не было бы и вовсе. Однако каждая Живая Система уязвима перед мошенничеством. Есть определенная группа людей, которые обманывают — систематически или в зависимости от ситуации. Зная, как работает рынок, они всегда будут пытаться обернуть ситуацию в свою пользу, даже если это плохо скажется для остальных. Они будут лгать, красть, обманывать, запугивать и принуждать и т.д.

Не проявляя сопротивления подобному мошенничеству, рынок будет страдать и вся система рано или поздно умрет. Централизованная власть — один из способов защиты от мошенничества. Однако и она значительно уязвима: мошенники могут и даже часто захватывают власть сами. В Живых Системах они могут захватить только управляющих, что и происходит постоянно, на самом деле.

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

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

Что касается Спланированной Системы, то подстроить ее под меняющийся окружающий мир очень сложно, часто даже невозможно. Ресурсы определяют власть. Поэтому Спланированные Системы активно и агрессивно противятся изменениям, отрицают их, а когда без изменений уже не обойтись — они перестают существовать.

Живая же Система получает только выгоду от изменений. Для нее не имеет значения, когда заниматься изучением ландшафта — “сегодня” или “завтра. Она развивается благодаря непрерывному обучению. Чтобы действительно уничтожить ее, вы должны нанести ей большой ущерб, что тяжело сделать, если Живая Система уже успешна и сильно развита.

Для нее работа с небольшими неполадками ничем не отличается от обычной деятельности. На самом деле Живая Система развивается благодаря сложным ситуациям, только если они не являются очень тяжелыми, непреодолимыми. Сложная ситуация это то, что помогает компонентам конкурировать между собой и разрабатывать лучшие решения. То, что не убивает Живую Систему, делает ее только сильнее.

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

Давайте обратимся к отдельным компонентам Живой Системы. Помните, что Живая Система похожа на рынок, где компоненты конкурируют за предоставление определенных услуг. Компоненты живой системы обладают определенными чертами, которые отличают их от компонентов спланированных систем. У каждого компонента Живой Системы есть определенная группа владельцы и инвесторы, и за каждым компонентом закреплена отдельная группа (в то время как в Спланированной Системе у каждого компонентов одни и те же владельцы). Компоненты объединяются в сети поставщиков и клиентов, данные, имена и адреса которых всегда доступны для удобства клиента. Легким способом смошенничать является подмена высококачественного компонента низкопробным. Поэтому управляющему органу возможно придется обеспечить соблюдение идентификации профиля и защитить идентификационные данные.

Компоненты максимально независимы от своего местонахождения. Этот факт создает более крупный и эффективный свободный рынок. Это значит, что мы стремимся к тому, чтобы наша Живая Система была независимой. Это противопоставляется Спланированной Системе, где местоположение играет очень важную роль, а конкуренция между компонентами либо очень мала, либо вовсе отсутствует.

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

Компоненты максимально независимы друг от друга. Это значит, что они существуют и изменяются в своем темпе, в своем направлении. Изменение в одном компоненте практически незаметно для другого, разве что через открытый интерфейс. Эта свобода необходима для свободного рынка, движимого специализацией и торговлей. Так, один компонент может сфокусироваться на скорости, а другой — на безопасности.

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

Компоненты абстрагированы, что означает, что они могут сами по себе являться целыми системами. Например, веб-адрес может представлять собой отдельную, небольшую часть программного обеспечения (один веб-сервер) или крупную инфраструктуру (интернет-бизнес). В свою очередь, только от владельцев каждой группы зависит, какую систему они будут создавать — Живую или Спланированную. Живая Система сможет благополучно принять в себя компоненты Спланированной Системы. Обратный процесс, однако, невозможен.

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

На самом деле, собрания с их повестками дня и протоколами представляют собой олицетворение общего изменяющегося состояния, от которого зависит Спланированная Система. Спланированные Системы не могут функционировать без систематического предварительного соглашения. При проектировании многопоточного ПО мы используем “блокировки” для достижения подобного результата. Доказано, что система ПО, использующая блокировки для того, чтобы поделиться состоянием компонентов, не будет развиваться. Вы можете попытаться создать распределенное программное обеспечение наподобие Спланированное Системы: поначалу все работает хорошо, но почти или вовсе не растет. В то время как хоть запуск Живой Системы и занимает немного больше времени, ее последующий рост безграничен.

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

Пример: на запланированную конференции организаторы выбирают определенные темы, основываясь на опыте прошлого года. Сейчас, за месяц до конференции, очень важное событие привлекло интерес публики к совершенно другой проблеме. Как быстро среагируют организаторы конференции? Конференция, которой управляют участники, может изменяться в режиме реального времени, в то время как запланированной конференции понадобится чуть ли не год, чтобы как-то ответить на это.

Между компонентами Живой Системы существуют определенные связи. Каждая связь представляет собой комбинацию из потока информации, знаний или обращений, в обоих направлениях. Лучшим способом для моделирования данных отношений являются дискретные события или “сообщения”, которые несут в себе определенный набор связей, взаимоотношений, который мы и называем “протоколами”. В естественных Живых Системах мы также можем наблюдать сообщения и протоколы. Клетки, например, поддерживают связь между собой посредством химических сообщений. Мы, люди, общаемся с помощью набора протоколов, лежащих в основе нашей речи. Например, иерархии, в которых мужчины занимают доминирующее положение, являются характерной особенностью человеческого общества, свидетельствуя о том, что протоколы управления и контроля, на которых эти иерархии основаны, встроены в наши умы, а не познаны. Я могу даже предположить, что мужской разум, руководствующийся нуждой предков организовывать охотничьи кампании, отвечает за Спланированные Системы.

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

Мы видим также протоколы “один к одному”, где два компонента обмениваются знаниями, заданиями, запросами и так далее. Такие протоколы более официальные и в идеале полностью асинхронны. Менее официальные протоколы формируются дольше, создавая, таким образом, всеобщую “задержку”. Если я, например, готовлю, пиццу и я должен узнать про каждый ингредиент, естественно, это займет больше времени. “Вы любите грибы?”, “как насчет чеснока?”, “Хорошо, какой сорт сыра вы предпочитаете?”.

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

Для создания эффективных асинхронных систем нам нужны очереди и стратегическое планирование очередности. В идеале, мы всегда сталкиваемся с очередями, когда ожидаем сообщения и стараемся как можно скорее перенаправить их получателю, в целях избежания задержек. Нам необходимы стратегии для работы с полными очередями (пространство не бесконечно): можно просто удалить старые сообщения или приостановить отправку сообщений (только это работает для диалогов “один к одному”, а не для “один ко многим”). Нам может понадобится очереди входящих сообщений, одна за поток, и способность ждать сообщения на этой очереди.

Протоколы — неотъемлемая часть Живой Системы. Они реализуют формальные контракты. Если я спрашиваю “Вы любите чеснок?”, в качестве ответа я ожидаю либо да, либо нет. Разговор о погоде в данном случае будет нарушением контракта. Когда мы развиваем наши Живые Системы, мы должны зафиксировать протоколы, чтобы изучить его и заверить. И чем проще и четче он будет, тем лучше. Сложные, неоднозначные протоколы тяжелы как для изучения, так и для реализации и не вписываются в концепцию свободного рынка.

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

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

ZeroMQ сообщество — это Живая Система людей, которая строит Живую Систему программного обеспечения (подборка программного обеспечения под тем же названием). Хотя я изначально разрабатывал ZeroMQ сообщество с большинством свойств Живой Системы, она вышла только в 2012, отказавшись от услуг своих главных планировщиков.

Это сообщество состоит из слабо связанных проектов, имеющих общую цель, которая заключается в обеспечении очередей или сообщений для других систем ПО. Я утверждал и все еще верю в то, что только Живая Система может оптимально применяться с ZeroMQ.

Проекты ZeroMQ связаны в цепочки поставок формальными отношениями на основе API и протоколов прикладного уровня. Оформление этих API и протоколов и обеспечение контроля за их эффективностью занимает очень много времени. При этом мы обычно не документируем внутренние компоненты, а только внешние API.

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

Любой может начать новый проект ZeroMQ или создать ее новое ответвление для конкурирования и экспериментов. Мы поощряем это, поэтому у нас несколько разных типов конкуренции на разных уровнях. Это хорошо работает на практике. Основными лицензиями являются LGPLv3 или MPLv2, гарантирующие, что ответвления всегда защищены (разработки могут совершаться в обоих направлениях).

Управляющей группой в сообществе ZeroMQ является группа, возглавляемая iMatix - фирмой, которая разработала первое ПО. Особо управлять, в принципе, нет необходимости, за исключением того, чтобы прекратить злоупотребление именем “ZeroMQ”. Четкого документального оформления протоколов достаточно, чтобы клиенты могли проверять своих поставщиков.

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

Полная трансформация ZeroMQ в Живую Систему оказалась сложным процессом, поскольку первоначально не было никаких шансов на успех. Основная часть проектов бесплатного ПО все еще зависит от тщательного планирования. Нарушение стандартных процедур казалось очень странным, если не безумным. Потеря главных участников — которые предоставляли те полномочия, на которых основывалось центральное планирование, — казалась, в перспективе, катастрофой.

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

Сегодня ZeroMQ является примером того, как должна правильно работать Живая Система. Она предоставляет большую ценность как хранилище данных, так как предпринимались многочисленные попытки заменить ее, как предыдущими главными планировщиками, так и другими командами. Примечательно, что каждая Спланированная Система, которая претендовала на то, чтобы быть “лучше, чем ZeroMQ” потерпела крах, тогда как каждая Живая Система, которая начинала конкурировать с ZeroMQ, в конце концов становилась ее частью.

Можно ли превратить Спланированную Систему в Живую? Предположим, что у нас есть техническое право (соглашение от достаточного количества участников или законное право — наличие лицензии); каковы тогда практические требования?

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

Размер компонентов обычно зависит от людей, так что подходящий это такой “с которым могли бы работать несколько людей”. Масштаб Живой Системы связан с тем, что туда добавляется все больше компонентов, которые могут использовать и замещать друг друга как угодно, без увеличения своих размеров. Компонент слишком маленький, когда он не может сам по себе обеспечить что- или кого-либо, и слишком большой, когда он не может сфокусироваться на чем-то одном.

И, наконец, вам нужны контракты. Мы получили хорошие результаты для систем ПО, просто приняв контракт ZeroMQ C4.1 использовать его вместе с руководством по стилю программирования и ПО лицензией.

По нескольким причинам я настоятельно рекомендую такую общую лицензию как LGPL (моя теория: если вы пользуетесь слабенькой лицензией как, например, Apache или BSD, у вас точно не получится создать Живую Систему).

Ранее запуск подобной Живой Системы осложнялся тем, что самоорганизующиеся ПО экосистемы не находили надлежащего отражения в документах, да и вообще плохо принимались. Нам не хватало эмпирических данных, демонстрирующих, что такие процессы, как C4.1 могут работать, не говоря уже о том, что могут работать так хорошо. Насколько я знаю, тот контракт был первым контрактом в ПО для Живых Систем.

Как же зарабатывать деньги на свободном программном обеспечении? Мне часто задают этот вопрос. Я всегда даю разный ответ, в зависимости от того, с кем я имею дело — с отдельным человеком, небольшой фирмой, крупной фирмой.

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

Живая Система принадлежит каждому ее участнику, поэтому ее ценность гораздо сложнее измерить, в то время как Спланированная Система, которой владеют несколько людей из “верхов”, представляет собой определенную видимую ценность как для своих владельцев, так и для сторонних наблюдателей. Однако общая ценность Живой Системы всегда будет превосходить любую конкурирующую ей Спланированную Систему. Живая Система может приносить невероятную прибыль, которая делится между всеми ее участниками.

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

Второй ответ заключается в том, что мы можем построить новые рынки в успешных Живых Системах, что является невозможным в спланированных. Хорошим примером этого является интернет: он позволяет создавать новые крупномасштабные экономические проекты, что прежде было невозможно в старых сетях. Эти новые рынки могут быть очень прибыльными.

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

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

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

У Живой Системы нет главного владельца, который бы осуществлял контроль, однако, там могут выбираться власти для управления (определения и обеспечения исполнения) контрактами. У нее нет ни одной точки отказа. Вместо того, чтобы воспринимать неполадки, неудачи как что-то экстраординарное или то, чего следует избегать, Живая Система учится на них. Неисправный компонент заменяется на исправный.

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

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

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

Другие книги того же автора: ZeroMQ - Messaging for Many Applications (O’Reilly), Culture and Empire: Digital Revolution (Amazon.com), The Psychopath Code (Amazon.com).