Как стать автором
Обновить
0
Philtech Initiative
Общественное благо через цифровые технологии

Как построить сообщество. Перевод книги «Социальная архитектура»: Глава 6. Живые Системы

Время на прочтение 21 мин
Количество просмотров 8.8K
Автор оригинала: Pieter Hintjens
image«Живой Системой» называется такая система, которая развивается в естественной среде, самостоятельно приспосабливаясь к новым условиям. Живые Системы могут существовать довольно долгое время, легко адаптируясь к любым изменениям, являясь, таким образом, чрезвычайно эффективными. В отличие от них, “Спланированные Системы” являются, как правило, неустойчивыми, плохо реагирующими на изменения и, как следствие, недолговечными. В этой статье я расскажу о Живой Системе на примере программного обеспечения и общества, а также расскажу о том, как создать подобную систему.

Почему “Живые Системы”


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

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

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

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

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

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

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

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

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

Что из себя представляют Живые Системы


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компоненты Живой Системы


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

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

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

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

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

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

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

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

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

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

Протоколы Живой Системы


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

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

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

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

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

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

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

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

Пример из практики: библиотека ZeroMQ и сообщество


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

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

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

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

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

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

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

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

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

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

Трансформация в Живую Систему


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

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

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

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

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

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

Экономика Живых Систем


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

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

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

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

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

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

Заключение


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

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

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

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

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

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

Перевод книги «Социальная архитектура»:





Об авторе
»К сожалению, мы не выбираем себе смерть, но мы можем встретить ее достойно, чтобы нас запомнили, как мужчин."
— к/ф «Гладиатор»



Питер Хинченс (Pieter Hintjens) — бельгийский разработчик, писатель. Занимал должность CEO и chief software designer в iMatix, компании, производящей free software, такие как библиотека ZeroMQ (библиотека берет на себя часть забот о буферизации данных, обслуживанию очередей, установлению и восстановлению соединений и прочие), OpenAMQ, Libero, GSL code generator, и веб-сервиса Xitami.

  • Автор более 30 протоколов и распределенных систем.
  • Основатель проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети.
  • Президент ассоциации Foundation for a Free Information Infrastructure (FFII), которая воевала с патентным правом.
  • CEO сервиса по созданию собственных вики-проектов Wikidot.
  • Он был активистом open standards и основателем Digital Standards Organization.
  • Питер в 2007-м был назван одним из 50 самых влиятельных людей в области «Интеллектуальная собственность».

Подробнее тут: Тридцать пять лет я, как некромант, вдыхал жизнь в мертвое железо при помощи кода

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

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

Сайт Питера Хинченса
Статья в Википедии

Мысли и идеи Питера Хинченса на Хабре:



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


Call to action
Если у вас есть на примете проекты/стартапы с высокой долей технологий, направленные на общественное благо в первую очередь и на получение прибыли как на вспомогательную функцию (например, как Википедия), пишите в личку или регистрируйтесь на программу акселератора.

Если вы пришлете ссылки на статьи, видео, курсы на Coursera по управлению/построению/улучшению сообществ, ориентированных на создание продукта, с меня шоколадка.
Теги:
Хабы:
+11
Комментарии 3
Комментарии Комментарии 3

Публикации

Информация

Сайт
philtech.global
Дата регистрации
Дата основания
2018
Численность
11–30 человек
Местоположение
Россия

Истории