§ 2-3 Отпечатыватели (Imprimers)

“Сейчас, стыд является ментальной мерой позора, в которой мы сжимаемся от осознания позора, а не от последствий действий, и нам остается только предполагать, какое составляется о нас мнение, из этого следует, что люди, перед которыми мы чувствуем стыд- это те, чье мнение имеет для нас значение. Эти люди являются: те, кем мы восхищаемся; те, кто восхищается нами; те, восхищение которых мы желаем добиться; те, с которыми мы противоборствуем; и те, чье мнение мы уважаем.”
— Аристотель в Риторике 2,6

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

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

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

2.1. Играя с грязью

«Это не просто изучение вещей, которые важны. Это обучение тому, что делать с тем, что вы учите и познанием, почему вы изучаете все эти важные вещи» — Нортон Джастер, рассказ Фантомный Киоск (The Phantom Tollbooth)

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

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

Что может извлечь из этой ситуации Кэрол? Она получила знание методом проб и ошибок, о том, что вилки не очень-то приспособлены для переноса грязи. Но благодаря опыту с ложкой она приобрела знание, что ложки являются хорошим инструментом для переноса жидкости. Благодаря ошибкам мы понимаем какой метод не работает — в то время как успех учит нас какой метод принесёт успех. [Пояснения в §9-2.]

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

О жизнь — великий песенный цикл,
Переплетение случайностей,
А любовь — то, что всегда верно,
И я — Мария Румынская.
— Дороти Паркер.

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

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

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

Любовь должна быть такой,
Влекущей и всеобъемлющей,
Исключительной и ужасающей,
Почитаемой и всё же скорбящей,
Расцветающей, словно звёзды,
И безмерной — как поцелуй.
— Из «Экстравагарио».

Что есть любовь и как она работает? Нужно ли нам пытаться её понять, или может, стоит воспринимать подобную поэзию как намёк на наше нежелание разбираться в вопросе? Давайте взглянем на попытку нашего товарища Чарльза описать собственное недавнее увлечение:

Чарльз: Я только что влюбился в замечательного человека. У меня с трудом получаеться думать хоть о чём-то, кроме неё. Моя любимая невероятно совершенна — неописуемой красоты, безупречного характера, невообразимого ума. Нет ничего, чего я не сделал бы ради неё.

Нора Джойс мужу Джеймсу: «Почему бы тебе не написать понятную людям книгу?»

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

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

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

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

Не так давно я услышала очень уникальную информацию о Кремниевой долине. Она объясняла кое-что, что интересовало меня годами.

Но я не могу сказать, что это было.

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

В последнее время многие беспокоятся о «фейковых новостях». И это действительно проблема, но существует и другая: правдивые вещи, о которых не говорят.

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

Введение

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

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

Наименее важное время в которое мы живём — это настоящее.
Алан Кей

Ещё в 2014 году, когда Алан Кей выступал с этой речью в Сан Франциско, один друг присутствовал там лично. Его крайне впечатлило выступление, и он попросил перевести его для исследователя, который уже в возрасте и не знает английского. Искренне интересуясь теми, кто двигает мыслью в Долине, я согласился. Перевод лежал невостребованным долгое время, но вдруг пришла шальная мысль: взять и опубликовать.
Спасибо MagisterLudi за редакцию и помощь!

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

Большие Данные — это ниша, в которой многие сегодня пытаются делать деньги, которая также является любимицей маркетологов из-за её вездесущности. Все слышат фразу, но не все знают её значение, именно это служит отличным поводом чтобы маркетологам говорить: “это использует Большие Данные, то использует Большие Данные”. Но интересное будущее лежит за значением, за смыслом, а не данными. Стивен показал вам идею, которая у большинства людей и не появлялась — что если бы язык программирования реально знал что-нибудь о своём пользователе, о контексте, что если бы он знал бы что-нибудь и обо мне. Эти идеи довольно стары, и появились тогда, когда и многие скачкообразные открытия. Но они не были поняты в 80-е, и были просто отброшены. И это интересная тема для размышления.

«Это эссенция тридцатилетнего опыты разработки программного обеспечения.»

Процесс ZeroMQ: C4

Когда мы говорим о ZeroMQ, мы иногда имеем в виду libzmq — основную библиотеку. В начале 2012 года мы синтезировали процесс libzmq в формальный и многоразовый протокол для совместной работы, который мы назвали “Контрактом на разработку коллективного кода” или C4. Вы можете рассматривать это как слой над лицензией (например, MPLv2). Это наши правила, и я объясню причины возникновения каждого из них.

C4 — это эволюция модели GitHub Fork + Pull. Вы можете подумать, что я поклонник git и GitHub. И это точно: эти два инструмента оказали положительное влияние на нашу работу в последние годы, особенно когда речь идет о создании сообщества.

Язык

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе следует интерпретировать так, как описано в RFC 2119.

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

Питер Хинченс (Pieter Hintjens), автор книги «Социальная Архитектура», на основе многолетнего опыта управлением open source сообществом предлагает свою систему оценки организованности.

Коллективный Индекс Интеллекта или КИИ (CII)

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

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

1. Википедия
2. Твиттер
3. Реддит
4. Фейсбук
5. Индустрия моды
6. Нигерийский кинематограф, т.н. Нолливуд (Nollywood)
7. Адвокаты как профессия
8. Киноиндустрия Голливуда
9. Сеть The Fox News
10. Военные (в какой-то случайной восточной стране)

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

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

Немного о торговых марках

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

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

«Размер и разнообразие сообщества является ключевым фактором.»

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

Я собираюсь обсудить два основных архетипа большой организации — замок и город — и сравнить их. А что насчет вашего проекта? Это замок или город?

Замок

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

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

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

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

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

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

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

Важность контрактов

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

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

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

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

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

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

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

Можем ли мы целенаправленно строить сообщества?

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

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

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

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

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

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

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

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

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

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

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

«Что же до рассудительности и постоянства, то уверяю вас, что народ постояннее и много рассудительнее всякого государя. Не без причин голос народа сравнивается с гласом Божьим: в своих предсказаниях общественное мнение достигает таких поразительных результатов, что кажется, будто народ ясно предвидит».

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

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

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

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