Власть, деньги и open source. Рассказываем, как работает сообщество на примере Apache Ignite06.08.2018 13:32

tl9gc1ladaoia_7h8sigu8z5glk.jpeg

На последней встрече сообщества Apache Ignite в Москве я рассказывал про:

  • Open source-сообщество;
  • Власть и деньги в open source;
  • Как стать контрибьютором и коммитером, и зачем это нужно.


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

Что такое сообщество?


Это может казаться очевидным, но всё-таки давайте уточним, что мы понимаем под сообществом. Прежде всего, мы говорим об онлайн-сообществе. Это некая площадка для взаимодействия людей друг с другом. Если сообщество посвящено, к примеру, здоровью, фитнесу и подобной деятельности, то его задачей может быть поддержка своих участников. Или сообщество может создавать общественно полезное благо. Как раз это справедливо в отношении сообщества по разработке open source-софта. Кроме того, если у вас есть желание разработать какой-то софт, то вы вряд ли найдете людей с похожими взглядами, например, на своей лестничной площадке или в соседнем подъезде. Такие проекты бывают, но обычно как студенческие. А онлайн-сообщество стирает барьеры между континентами и часовыми поясами, позволяет найти больше энтузиастов.

Apache Foundation


История Apache началась в 1999 году с веб-сервера HTTPD: группа людей начала разрабатывать веб-сервер, к ним стали приходить пользователи, некоторые из которых стали присылать патчи, потому что хотели что-то улучшить в этом продукте или исправить баги. Разработчики постепенно начали выделять наиболее активным участникам этого сообщества права на push в репозиторий, что сейчас называется коммитерскими правами.

Применяя этот же подход к развитию open source, Apache стала сейчас крупнейшей организацией (foundation), которая разрабатывает open source-ПО. Организация разделена на 319 (пока что) диверсифицированных проектов, из которых около 200 Top-Level. Единого процесса для всех проектов не существует, все участники являются волонтерами, их труд никогда не оплачивается организацией.

Apache в обязательном порядке требует от всех проектов наличия:

  • Правовой политики;
  • Политики использования брендов;
  • Голосования по принятию релизов;
  • Использование почтовых рассылок;
  • Информационной безопасности.


Apache Incubator


Чтобы построить сообщество, все проекты Apache в обязательном порядке проходят через Apache Incubator. Это промежуточная стадия становления даже не проекта, а сообщества вокруг него. Никто в Apache не будет диктовать, какую технологию использовать. Более того, даже не будут подсказывать, какое решение выбрать. Задача Apache Incubator — построить сообщество, которое совместно принимает решения. Очень важно, чтобы участники понимали, как и кто принимает решение, где они могут высказываться, где их голос будет услышан. Организация ASF помогает, прикрепляя к проекту ментора.

Top Level-проект Apache


Если проект выходит из Apache Incubator, он может стать top level-проектом. Apache помогает проекту участвовать в конференциях, оказывает посильную помощь в продвижении бренда, поддерживает инфраструктуру.

Сообщество top level-проекта гарантирует пользователям, что:

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

Open source и власть


Теперь поговорим о власти и деньгах, и о том, как принимаются решения. Это не всегда очевидно даже для участников сообществ. В Apache-проекте есть несколько ролей и им соответствуют несколько mailing-листов:

  • Пользователь (user@project.apache.org);
  • Разработчик (dev@project.apache.org);
  • Коммитер (committer) (dev@project.apache.org);
  • PMC (private@project.apache.org);
  • PMC Chair (private@project.apache.org).


Далее можно расти уже в рамках самой Apache Software Foundation, стать ментором какого-то проекта, помогать другим проектам строить сообщество.

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

В отличие от коммерческих компаний, где штат и рост ограничен бюджетом, в open source такого нет, ничто не ограничивает количество коммитеров или PMC. Группа регулирует себя самостоятельно.

Пользователь


Пользователи — это все мы. Наверняка каждый из вас пользуется каким-нибудь open source софтом. Для сообщества важно, что пользователь не только пользуется или даёт обратную связь в виде отчётов о багах или запросов на фичи, но и помогает другим. То есть, с точки зрения сообщества участник становится пользователем только тогда, когда он подписывается и отвечает на user-list и помогает остальным освоить продукт, делится своими знаниями.

Разработчик/Контрибьютор


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

Коммитер


Если сообщество считает, что человек внёс достаточный вклад, он может быть наделен правом push«а в репозиторий, то есть минимальное количество рецензентов его кода сокращается до нуля (хотя в Apache Ignite коммитеры всё равно иногда проходят через разбор кода). Коммиттеры подписывают лицензию ICLA (Individual Contributor License Agreement). Впрочем, её можно подписать и до получения коммитерских прав. Коммитер получает почтовый ящик на apache.org и может принимать решения, связанные с каждым вкладом в проект.

PMC Member


PMC (Project Management Committee) Member — член комитета управления проектом. Этот участник сообщества уже внёс большой вклад в развитие продукта и наделён правом принимать долгосрочные решения о развитии, контролирует проект, следит за многими аспектами, в частности, за совместным принятием решений. Он помогает участникам сообщества приходить к консенсусу. В Apache у PMC очень много обязанностей, например, он может голосовать за принятие релиза. Коммитер и контрибьютор тоже могут, но, в отличие от них, у PMC binding-голос. PMC может предлагать кандидатуры в коммитеры или новые PMC.

PMC Chair


PMC Chair — это связующий мостик с Советом Apache Software Foundation. Пожалуй, особой власти у PMC Chair по сравнению с PMC Member нет. Но он должен решать возникающие проблемы и отчитываться в Apache Board о состоянии проекта.

Принятие решений: дуократия


В Apache главенствует принцип дуократии (do-ocracy, от do — «делать»). Чем больше делаешь, тем больше у тебя возможностей делать, тем больше влияешь на проект.
Если по какому-то решению нужна скоординированная позиция всех участников, проводится голосование. Оно длится минимум 72 часа, чтобы все успели проголосовать.

Участники голосования ставят:

+1: «за решение».
0: «мне всё равно».
-1: «против решения». В этом случае нужно предложить что-то другое и подробно объяснить, почему голосуешь против.

Бывают и другие виды голосов:

+0: «Идея не очень нравится, но меня устраивает».
-0: «Мешать не буду, но лучше этого не делать».
-0.5: «Идея не нравится, но я не могу найти рациональных доводов против».
++1: «Супер, давайте сделаем!»
-0.9: «Мне это не нравится, но если все хотят, то палки в колёса вставлять не буду, валяйте».
+0.9: «Идея классная, мне нравится, но у меня нет времени/знаний, чтобы помочь».

Ленивый консенсус (Lazy consensus)


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

Одобрение большинством и одобрение консенсусом


Голосования за релиз проходят активнее: в этом случае необходимо одобрение большинства участников сообщества: три binding-голоса (от PMC) «за», и больше голосов «за», чем «против».
Консенсус — самый лучший вариант: все «за», причём должно быть как минимум трое PMC.

Вето


Квалифицированный контрибьютор, обычно это PMC member, может наложить вето. Он голосует -1 за модификацию кода и пишет подробное объяснение. Такое решение PMC member не может обойти никто. Нельзя наложит вето на релиз, но если правка очень плохая, к примеру, делает брешь в безопасности или очень сильно ухудшает производительность, то PMC может проголосовать -1. И пока он не отзовёт вето, применить правку невозможно.

Меритократия


Ещё один принцип, который близок к дуократии. Дословно «меритократия» означает «власть достойных». В open source это означает, что если пользователь, как считает группа, сделал для сообщества достаточно много, то его повышают до коммитера. Вы можете спросить, насколько это справедливое решение, всегда ли оно абсолютно честное и взвешенное? Это исключительно субъективное решение всех PMC данного сообщества. В крупных сообществах, как Apache Ignite, эта политика может быть более-менее формализованной. Важны определенные вклады человека, обязательно активное участие в рассылке для разработчиков. Но «достаточность» определяется каждым проектом в отдельности.

Важный момент — это человеческие качества участника. В политике Apache прямо написано, что оценивается взаимодействие человека с остальными участниками, как он ведёт себя, если с его мнением не согласны. Чтобы участника повысили до коммитера или PMC, другие PMC должны проголосовать в private list, при этом не должно быть голосов «против».

Open source и деньги


Эта важная тема всплывает так или иначе: как зарабатывать деньги с продуктами Apache Software Foundation. Организация предоставляет самую дружелюбную к коммерческим организациям лицензию из всех, какие только есть. Можно продавать продукты на базе Apache или поддержку продуктов Apache, можно использовать их в коммерческих продуктах.

Важное требование: всегда должна оставаться возможность бесплатного использования продуктов Apache. Они управляются вне зависимости от коммерческих интересов. За этим следит PMC.

Коммитер может получать от сторонней организации деньги за вклад в проект. Коммитер может быть нанят сторонней организацией. Недавно участники сообщества рассказали на Хабре, как работают с open source сообществом Apache Ignite в Сбербанк-Технологиях. Но Apache Foundation никогда не платит коммитерам. Это принципиальная позиция. Для Apache коммитер — всегда волонтер и частное лицо. То есть компания не может участвовать в проектах Apache, может только один разработчик.

Зачем и как присоединяться к open-source


Почему стоит начать вносить вклад в open source-проекты?


Это хорошая возможность прокачать свои навыки и заработать профессиональную репутацию. Коммерческие компании ценят участие в open source. Многие знаменитые разработчики участвуют в различных проектах, становятся коммитерами и PMC.

Что мешает людям участвовать в open source?

  • «Нужно быть олимпиадником или senior«ом с 20-летним опытом, иначе не справлюсь». На самом деле, нет. Apache Ignite — сложный проект, но даже здесь можно найти простые задачи. Например, easy ticket«ы и задачи по написанию документации, которые призваны лучше описать проект. Нигде в Apache не сказано, что для того, чтобы стать коммитером, нужно писать код.
  • «Нужен свободный английский, иначе я не справлюсь». Те, кто участвуют в dev list«ах, подтвердят: там не нужно владеть английским в совершенстве. Кроме того, общение письменное и вовсе не в режиме реального времени, есть время подумать и написать взвешенный ответ.
  • «Если я отправлю свой компонент в open source, то никогда больше не смогу его использовать». В Apache это не так. Вы можете продолжать использовать свой компонент в коммерческом продукте, просто он будет существовать и в рамках Apache Foundation под лицензией Apache.
  • «Все будут читать то, что я пишу в интернете». Даже в Apache Ignite-сообществе далеко не все читают то, что мы пишем. Это как в анекдоте про неуловимого Джо: его никто не может поймать, потому что он никому не нужен. Я уверен, что мои друзья и родственники не читают, что я пишу в dev list, потому что им всё равно.
  • «Это займёт всё мое свободное время». Отчасти это так: участие в сообществе затягивает. Если начинаешь участвовать в обсуждении, это займёт какое-то время. И по мере твоего роста будет занимать всё больше. Чем больше знаешь, тем больше можешь рассказать, тем больше участвуешь в user и dev.list. Но, опять же, нет никаких обязательств перед Apache. Каждый регулирует свою вовлеченность сам. Если можешь сделать один патч, сделай один патч. И всё, никто не будет тебя заставлять. Даже когда человек назначается коммитером, в письме с предложением прописывается, что от него не требуется большей вовлеченности, чем он готов дать.


Как начать


Если хотите участвовать в проектах Apache, то нужен будет аккаунт на Github, почтовый ящик, регистрация в Apache JIRA и, возможно, в Wiki. У любого сообщества есть для новичков статья How To Contribute, в Apache Ignite она тоже есть.

Хорошим тоном является написать приветственное письмо: «Здравствуйте! Я такой-то. Хочу сделать такой-то тикет, мой ник в JIRA такой-то». Это письмо важно с точки зрения присвоения пользователю роли контрибьютора.

Почтовые рассылки


Для взаимодействия с другими участниками Apache требует использовать почтовые рассылки. Я иногда слышу недовольство: почему так старомодно? Есть же куча чатов, мессенджеров. Так сделано потому, что каждый участник проектов Apache — волонтер. У него может быть своя семья, работа, которая не связана с open source, свои увлечения. Он не может в чате отвечать в режиме онлайн. Возможно, он и почту может проверять раз в три дня. И в подобных ситуациях почтовые рассылки работают отлично.

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

Пример письма:

Hi, □□□□□□□, I am not sure I agree, because…

Сообщество важнее кода


Один из принципов Apache: сообщество важнее кода. Это значит, что первым делом проект Apache нацелен на создание сообщества вокруг open source-проекта. А потом уже начинается магия и появляется хороший код. Если вы не согласны с каким-то письмом, отложите его на 4 часа, перечитайте и снова отложите. Тогда велик шанс, что вы ответите сдержанно, не оттолкнув неосторожным словом других участников сообщества. Все мы волонтёры, и если людям будет некомфортно, они начнут уходить, а для open source-проекта это очень серьезный риск.

Рекомендации по переписке


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

Пример не очень хорошего письма:

Hi, □□□□□.
This solution looks a bit ugly for me.

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

Что контрибьютить?


В каждом сообществе есть список того, что ему нужно сейчас в данный момент. В Ignite есть список простых тикетов. Если у вас во время использования обнаружился баг и вы его у себя в форке исправили, то вполне можно создать под это дело JIRA issue, сделать pull request и написать в dev list.

Как пройти code review


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

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

В проектах Apache, в том числе Ignite, нет роли проект-менеджера, который следил бы за бэклогом, поэтому там могут встречаться и неактуальные тикеты. Рекомендуется сначала написать в dev list и уточнить.

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

Рассказывайте о проекте


Сообществу очень сильно помогают статьи о продукте. Сама Apache Software Foundation помогает конференциями. Вы тоже можете описывать свой опыт взаимодействия, не обязательно только с Apache Ignite. Это могут быть и какие-то интересные use-case, студенческие работы. Они всегда публикуются в dev list.

© Habrahabr.ru