Перевод книги «Социальная архитектура»: Глава 5. Дизайн, разработка, инновации

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

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

История двух мостов

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

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

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

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

Как ZeroMQ потерял свою дорожную карту

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

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

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

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

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

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

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

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

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

1. Есть безграничная область проблем/решений.
2. Область меняется с течением времени в зависимости от внешних обстоятельств.
3. Мы можем точно воспринимать только те проблемы, которые нам близки.
4. Мы можем оценить прибыльность/затратность проблемы, используя рынок решений.
5. Есть оптимальное решение для любой решаемой проблемы.
6. Мы можем достичь этого оптимального решения эвристическим и механическим путем.
7. Наш интеллект может ускорить этот процесс, но не заменить его.

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

• Индивидуальная креативность менее важна, чем процесс. Более умные люди могут работать быстрее, но при этом двигаться в неверном направлении. А коллективное видение реальности помогает нам следовать актуальным путем и не обманывать ни себя, ни других.
• Нам не нужны дорожные карты, если у нас хорошо налажен процесс. Со временем, по мере того, как решения будут конкурировать за долю рынка, функциональность будет расти.
• Мы не столько изобретаем решения, сколько находим их. Соболезнования творческим натурам: творчество является лишь обрабатывающим информацию големом, начищающим до блеска свое собственное эго и озабоченным поднятием кармы.
• Интеллект — это социальный эффект, хотя он и ощущается как что-то личное. Человек, отрезанный от других, перестает думать. Мы не можем ни определить проблемы, ни оценить их решения без других людей.
• Размер и разнообразие сообщества является ключевым фактором. Более крупные и разнообразные сообщества охватывают больше релевантных задач, решают их более точно и делают это быстрее маленькой группы экспертов.

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

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

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

Trash-Oriented Design

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

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

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

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

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

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

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

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

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

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

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

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

Complexity-Oriented Design

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

• Менеджмент правильно идентифицирует некоторые интересные и сложные проблемы, привлекательные с экономической точки зрения. Вот тут-то они как раз и попадают на колею ТOD.
• Команда с энтузиазмом начинает создавать прототипы и работать над ядром. Все это работает, как и было задумано, и команда, загоревшись еще больше, углубляется в напряженную разработку и обсуждение архитектуры, создание элегантных схем, прекрасных и стройных.
• Менеджмент возвращается и воодушевляет команду на решение еще более сложных проблем. Нам свойственно приравнивать затраты к стоимости, поэтому чем сложнее и дороже решение проблемы, тем больше за него можно будет выручить — так им кажется.
• Команда состоит из инженеров, которые любят создавать штуки, и они вступают в дело. Они создают и создают и создают, и кончается все это массивной прекрасно спроектированной сложностью.
• Рынок при знакомстве с продуктом, чешет за ухом и спрашивает: «Что, серьезно, и это лучшее решение, которые вы нашли?». Да, люди используют продукцию, если при этом им не придется тратить свои собственные деньги на подъем на гору мануалов.
• Менеджмент получает позитивные отклики от своих крупных клиентов, которые разделяют мнение о том, что чем выше стоимость (обучения и использования), тем выше ценность, и продолжает толкать процесс.
• В это время где-то в мире маленькая команда занимается решением такой же проблемы, используя лучший подход, и через год разносит сложившееся положение на рынке на мелкие осколки.

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

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

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

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

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

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

Simplicity Oriented Design

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

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

• Мы составляем список интересных проблем (наблюдая за тем, как люди используют технологию или другие продукты) и располагаем их от простых к сложным, рассматривая и определяя способы использования.
• Мы берем самую простую, самую драматичную проблему и ищем для нее минимальное количество приемлемых решений, или «патчей». Каждый патч решает именно исходную и всеми одобренную проблему наиболее оптимальным способом.
• При оценке патчей мы руководствуемся следующим вопросом: «Можем ли мы найти более простое решение проблемы?» Мы можем измерить сложность количеством концепций и моделей, с которыми пользователю придется ознакомиться или перебирать наугад для использования патча. Чем меньше, тем лучше. Идеальный патч решает проблему, не требуя ничего от пользователя.
• Развитие нашего продукта заключается в создании патча, который решает проблему «доказательства концепции» и который потом встраивается в единую линию более зрелых продуктов, состоящих из сотен тысяч патчей один поверх другого.
• Мы не делаем ничего, что не являлось бы патчем. Мы принуждаем к этому формальными правилами, которые требуют, чтобы каждое действие или обязанность были привязаны к основной и одобренной всеми задаче, четко сформулированной и задокументированной.
• Мы выстраиваем наши проекты как цепочку поставщиков решений, где каждый проект может обеспечить задачи своим «поставщикам» и получить в ответ патчи. Цепочка поставщиков является «стоп-краном», потому что когда люди нетерпеливо ждут ответа, нам волей неволей приходится работать в узких временных рамках.
• Индивидуумы могут работать над любым проектом и делать патчи для важных по их мнению проблем. Никто из них не «владеет» проектами, они могут лишь принуждать к следованию формальным правилам. У отдельно взятого проекта может быть много вариаций, каждый может обрастать разными патчами, конкурирующими между собой.
• Проекты экспортируют формальные и задокументированные интерфейсы, поэтому проекты-исходники (клиентские) находятся в неведении о проделываемой работе. При этом они могут соревноваться за внимание проектов-клиентов, создавая бесплатный и конкурентный рынок.
• Мы привязываем нашу цепочку поставок к реальным пользователям и внешним клиентам, и мы ведем весь процесс быстрыми циклами с тем, чтобы проблема, полученная от пользователей со стороны могла быть проанализирована, оценена и решена патчем за несколько часов.
• В каждый момент, начиная с первого патча, наш продукт готов к выпуску. Это важно, потому что большая часть патчей будет неправильными (10-30%), и только давая продукт пользователям, мы можем узнать, какие из патчей проблемные и требуют доработки.

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

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

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

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

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

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

• Предисловие. Мудрость толпы
• Глава 1. Инструментарий
• Глава 2
  — Эмоциональное выгорание волонтеров
  — Как захватить/защитить open-source проект
  — Миф об индивидуальном интеллекте
• Глава 3
  — Сообщество ZeroMQ
  — Психология архитектуры программного обеспечения
  — Важность контрактов
  — 4 шага к самоуправляемому сообществу
• Глава 5
  — Дизайн, разработка, инновации
  — Стратагемы для успеха open source проектов
• Глава 6. Живые Системы

---

Об авторе

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



Питер Хинченс (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. :)
Протокол ухода из жизни

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

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

• Протокол ухода из жизни
• Optimistic Merging: Сначала люди, потом код. Соберите правильное сообщество, и оно напишет нужный код
• Социальная архитектура: стратагемы для успеха open source проектов
• Как захватить/защитить open-source проект
• Как построить сообщество. Перевод книги «Социальная архитектура»: Глава 1. Инструментарий

О проекте по переводу книги

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

Прием заявок в акселератор для филтех стартапов продолжается

Если у вас есть на примете проекты/стартапы с высокой долей технологий совпадающие с ценностями филтеха, смело подавайте заявку.
До 25 февраля есть еще время!

Чат в Telegram
Сообщество людей, развивающих PhilTech-проекты или просто заинтересованных в теме технологий для социального сектора.

#philtech news
Новости о проектах в идеологии #philtech и ссылки на полезные материалы.

Страница в Facebook
Новости Philtech-стартапов, российские и международные события из мира технологий для филантропии.

Подписаться на рассылку
Еженедельная рассылка новостей из мира технологий и филантропии.