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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выпей меня

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

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

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

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

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

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

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

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

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

Процесс

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

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

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

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

Безумство, красота и простота

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

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

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

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

Незнакомец, позвольте представить вам Незнакомца

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

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

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

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

Неограниченная собственность

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

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

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

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

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

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

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

---