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

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

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

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

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


Интервью 2014 года.

Вопрос: Что вдохновило вас на создание Википедии?

Ответ: Я наблюдал за ростом свободного программного обеспечения и программного обеспечения с открытым исходным кодом. Я видел, как программисты со всего света сотрудничают друг с другом, чтобы построить замечательное программное обеспечение, на котором держится интернет: GNU/Linux, Apache, Perl, MySQL, PHP.

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

Это заставило меня задуматься над тем, что еще можно создать таким образом.

У нас была замечательная возможность. Благодаря интернету мы можем легко общаться друг с другом. Так что же можно создать?

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

Я загорелся этой идеей, и вот что мы имеем сейчас.

В: Когда это было?

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

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

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

• Четкая миссия – заявленная причина существования группы.
• Свободное участие – насколько легко люди могут присоединиться к группе.
• Прозрачность – насколько открыто и публично принимаются решения.
• Бесплатные участники – как много можно платить людям за участие.
• Свобода работы с материалами (ремиксабельность) – насколько свободно участники могут использовать работу друг друга.
• Четкость протокола – насколько хорошо прописаны правила.
• Компетентность власти – насколько хорошо следят за соблюдением правил.
• Нон-трайбализм – насколько далеко распространяются права группы над своими участниками.
• Самоорганизация – насколько свободно могут участники определять свои задачи.
• Толерантность – как группа разбирается с конфликтами.
• Измеримый успех – как хорошо группа может отслеживать свой прогресс.
• Высокое награждение – как группа вознаграждает своих участников.
• Децентрализация – насколько широко распределены участники группы.
• Свободная рабочая среда – насколько легко создавать новые проекты.
• Стандартная структура – насколько общая структура стабильна и предсказуема.
• Плавность обучения – насколько легко начать и продолжить учиться.
• Позитивность – насколько группа движима позитивными целями.
• Чувство юмора – насколько серьезно группа себя воспринимает.
• Минимализм – сколько лишней работы делает группа.
• Разумное финансирование – как группа борется за выживание в экономическом плане.

Спасибо Сергею Даньшину за помощь с переводом.

Нашей некоммерческой организации требовался более дешевый инструмент для емейл-рассылок. Поэтому мы (американское сообщество freeCodeCamp.org) его разработали.

Каждую неделю я делаю рассылку миллионам людей, которые подписаны на freeCodeCamp.org.

Рассылка является строго адресной и осуществляется через Amazon Web Services, что стоит нам $0.0001 за письмо.

Т.е. я могу разослать 1 млн. писем, обходя большинство спам-фильтров, всего за 100 долларов.

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

• HTML шаблоны;
• аналитические панели;
• отслеживание открытия писем (трекинговые пиксели);
• отслеживание переходов по ссылкам;
• встраиваемые виджеты для подписки;
• функция отказа от рассылки;
• список импортируемых/экспортируемых данных;
• ролевое разграничение доступа.

Этот инструмент — наша внутренняя разработка.
Он абсолютно бесплатный.
С полностью open source.
Он называется — Mail for Good.

И сегодня мы представляем его публике. Это бета-версия. Некоммерческие организации со всего мира могут сразу начать пользоваться им.

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

Почему Capture the Flag?

Как говорит «Ars Technica»: «Легко отдать что-нибудь, когда ты на последнем месте с нулевой долей рынка, как это было с Android в начале. Когда же ты на первом месте, немного сложнее быть таким открытым и доброжелательным».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс ZeroMQ: C4

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

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

Язык

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

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

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

Приветствую, Хабр.

Хочу представить лучшую (единственную) книгу по построению сообществ, написанную тру ИТишником.

Для себя я нашел применимые инструменты для анализа сообщества/организованности «на лету»(я и еще более 100 человек провели «аудит» Хабра), а так же подсказки, какой "генотип" закладывать при разработке нового продукта/брэнда/движухи. Читайте, сохраняйте, расшаривайте и пишите свой отзыв.

Об авторе

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



Питер Хинченс (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 самых влиятельных людей в области «Интеллектуальная собственность».

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

§1-5. Представление Разума Как Облака Ресурсов

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

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

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

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

§1-6. Взрослые Эмоции

Взгляните на ребенка, по любезному закону природы,
Он удовлетворяется погремушкой, и веселится из-за соломы:
И оживлённая игра ему придает ребяческий восторг,
Она немного громкая, но пуста внутри;
Шарфы, подвязки, золото, развлекают его в более зрелом возрасте,
А бусы и молитвенники представляют собой игрушки этого возраста;

— Александр Попе в «Эссе о человеке».

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

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