- PVSM.RU - https://www.pvsm.ru -
На последней встрече сообщества Apache Ignite в Москве [1] я рассказывал про:
Ограниченное время доклада не позволило привести больше примеров, поэтому расширенную версию выкладываю на Хабре. Всё изложенное основано на моем личном опыте и не является официальной позицией какой-либо компании или организации.
Это может казаться очевидным, но всё-таки давайте уточним, что мы понимаем под сообществом. Прежде всего, мы говорим об онлайн-сообществе. Это некая площадка для взаимодействия людей друг с другом. Если сообщество посвящено, к примеру, здоровью, фитнесу и подобной деятельности, то его задачей может быть поддержка своих участников. Или сообщество может создавать общественно полезное благо. Как раз это справедливо в отношении сообщества по разработке open source-софта. Кроме того, если у вас есть желание разработать какой-то софт, то вы вряд ли найдете людей с похожими взглядами, например, на своей лестничной площадке или в соседнем подъезде. Такие проекты бывают, но обычно как студенческие. А онлайн-сообщество стирает барьеры между континентами и часовыми поясами, позволяет найти больше энтузиастов.
История Apache началась в 1999 году с веб-сервера HTTPD: группа людей начала разрабатывать веб-сервер, к ним стали приходить пользователи, некоторые из которых стали присылать патчи, потому что хотели что-то улучшить в этом продукте или исправить баги. Разработчики постепенно начали выделять наиболее активным участникам этого сообщества права на push в репозиторий, что сейчас называется коммитерскими правами.
Применяя этот же подход к развитию open source, Apache стала сейчас крупнейшей организацией (foundation), которая разрабатывает open source-ПО. Организация разделена на 319 (пока что) диверсифицированных проектов, из которых около 200 Top-Level. Единого процесса для всех проектов не существует, все участники являются волонтерами, их труд никогда не оплачивается организацией.
Apache в обязательном порядке требует от всех проектов наличия:
Чтобы построить сообщество, все проекты Apache в обязательном порядке проходят через Apache Incubator. Это промежуточная стадия становления даже не проекта, а сообщества вокруг него. Никто в Apache не будет диктовать, какую технологию использовать. Более того, даже не будут подсказывать, какое решение выбрать. Задача Apache Incubator — построить сообщество, которое совместно принимает решения. Очень важно, чтобы участники понимали, как и кто принимает решение, где они могут высказываться, где их голос будет услышан. Организация ASF помогает, прикрепляя к проекту ментора.
Если проект выходит из Apache Incubator, он может стать top level-проектом. Apache помогает проекту участвовать в конференциях, оказывает посильную помощь в продвижении бренда, поддерживает инфраструктуру.
Сообщество top level-проекта гарантирует пользователям, что:
Теперь поговорим о власти и деньгах, и о том, как принимаются решения. Это не всегда очевидно даже для участников сообществ. В Apache-проекте есть несколько ролей и им соответствуют несколько mailing-листов:
Далее можно расти уже в рамках самой Apache Software Foundation, стать ментором какого-то проекта, помогать другим проектам строить сообщество.
Чем выше роль, тем меньше людей её выполняют, то есть образуется перевёрнутая пирамида: больше всего пользователей, меньше всего PMC. Обычно все заинтересованы в том, чтобы участники росли и выполняли более высокую роль.
В отличие от коммерческих компаний, где штат и рост ограничен бюджетом, в open source такого нет, ничто не ограничивает количество коммитеров или PMC. Группа регулирует себя самостоятельно.
Пользователи — это все мы. Наверняка каждый из вас пользуется каким-нибудь open source софтом. Для сообщества важно, что пользователь не только пользуется или даёт обратную связь в виде отчётов о багах или запросов на фичи, но и помогает другим. То есть, с точки зрения сообщества участник становится пользователем только тогда, когда он подписывается и отвечает на user-list и помогает остальным освоить продукт, делится своими знаниями.
Если пользователь готов внести вклад в проект, то с первым contribution он автоматически становится контрибьютором, или разработчиком — это синонимы. Контрибьютор участвует в рассылке для разработчиков, в которой обсуждается всё, что связано со вкладами в сообщество. Все разработчики влияют на принятие решений сообществом, все критикуют решения и предлагают альтернативы.
Если сообщество считает, что человек внёс достаточный вклад, он может быть наделен правом push’а в репозиторий, то есть минимальное количество рецензентов его кода сокращается до нуля (хотя в Apache Ignite коммитеры всё равно иногда проходят через разбор кода). Коммиттеры подписывают лицензию ICLA (Individual Contributor License Agreement [2]). Впрочем, её можно подписать и до получения коммитерских прав. Коммитер получает почтовый ящик на apache.org и может принимать решения, связанные с каждым вкладом в проект.
PMC (Project Management Committee) Member — член комитета управления проектом. Этот участник сообщества уже внёс большой вклад в развитие продукта и наделён правом принимать долгосрочные решения о развитии, контролирует проект, следит за многими аспектами, в частности, за совместным принятием решений. Он помогает участникам сообщества приходить к консенсусу. В Apache у PMC очень много обязанностей, например, он может голосовать за принятие релиза. Коммитер и контрибьютор тоже могут, но, в отличие от них, у PMC binding-голос. PMC может предлагать кандидатуры в коммитеры или новые PMC.
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: «Идея классная, мне нравится, но у меня нет времени/знаний, чтобы помочь».
Существует такая политика принятия решений, как ленивый консенсус, или одобрение через тишину. Эта процедура тоже длится минимум 72 часа. Если человек явно написал: «я хочу провести это решение через ленивый консенсус», то через три дня, даже если никто не ответил, решение считается принятым сообществом.
Голосования за релиз проходят активнее: в этом случае необходимо одобрение большинства участников сообщества: три binding-голоса (от PMC) «за», и больше голосов «за», чем «против».
Консенсус — самый лучший вариант: все «за», причём должно быть как минимум трое PMC.
Квалифицированный контрибьютор, обычно это PMC member, может наложить вето. Он голосует -1 за модификацию кода и пишет подробное объяснение. Такое решение PMC member не может обойти никто. Нельзя наложит вето на релиз, но если правка очень плохая, к примеру, делает брешь в безопасности или очень сильно ухудшает производительность, то PMC может проголосовать -1. И пока он не отзовёт вето, применить правку невозможно.
Ещё один принцип, который близок к дуократии. Дословно «меритократия» означает «власть достойных». В open source это означает, что если пользователь, как считает группа, сделал для сообщества достаточно много, то его повышают до коммитера. Вы можете спросить, насколько это справедливое решение, всегда ли оно абсолютно честное и взвешенное? Это исключительно субъективное решение всех PMC данного сообщества. В крупных сообществах, как Apache Ignite, эта политика может быть более-менее формализованной. Важны определенные вклады человека, обязательно активное участие в рассылке для разработчиков. Но «достаточность» определяется каждым проектом в отдельности.
Важный момент — это человеческие качества участника. В политике Apache прямо написано, что оценивается взаимодействие человека с остальными участниками, как он ведёт себя, если с его мнением не согласны. Чтобы участника повысили до коммитера или PMC, другие PMC должны проголосовать в private list, при этом не должно быть голосов «против».
Эта важная тема всплывает так или иначе: как зарабатывать деньги с продуктами Apache Software Foundation. Организация предоставляет самую дружелюбную к коммерческим организациям лицензию из всех, какие только есть. Можно продавать продукты на базе Apache или поддержку продуктов Apache, можно использовать их в коммерческих продуктах.
Важное требование: всегда должна оставаться возможность бесплатного использования продуктов Apache. Они управляются вне зависимости от коммерческих интересов. За этим следит PMC.
Коммитер может получать от сторонней организации деньги за вклад в проект. Коммитер может быть нанят сторонней организацией. Недавно участники сообщества рассказали на Хабре [3], как работают с open source сообществом Apache Ignite в Сбербанк-Технологиях. Но Apache Foundation никогда не платит коммитерам. Это принципиальная позиция. Для Apache коммитер — всегда волонтер и частное лицо. То есть компания не может участвовать в проектах Apache, может только один разработчик.
Это хорошая возможность прокачать свои навыки и заработать профессиональную репутацию. Коммерческие компании ценят участие в open source. Многие знаменитые разработчики участвуют в различных проектах, становятся коммитерами и PMC.
Что мешает людям участвовать в open source?
Если хотите участвовать в проектах Apache, то нужен будет аккаунт на Github, почтовый ящик, регистрация в Apache JIRA [4] и, возможно, в Wiki [5]. У любого сообщества есть для новичков статья How To Contribute [6], в 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.
Пока ты новичок в сообществе, вряд ли сможешь определить, какой тикет является приоритетным. Возможно, имеет смысл связаться с тем, кто сопровождает компонент, ему будет очень важна ваша помощь. Также можно спросить в dev list, какие тикеты важнее.
Если нет ответа, опять-таки вспоминаем, что все являются волонтерами. Возможно, хорошей идеей будет через три дня напомнить о том, что вы предлагали сделать.
В проектах Apache, в том числе Ignite, нет роли проект-менеджера, который следил бы за бэклогом, поэтому там могут встречаться и неактуальные тикеты. Рекомендуется сначала написать в dev list и уточнить.
Ещё одна особенность Apache: в коммерческой компании может быть четкая политика, что сотрудник определенного уровня может получить доступ к документации и править её, а сотрудник более низкого уровня не может. В Apache такого нет. Если есть что законтрибьютить, — никаких проблем. Думаю, ни в каком проекте у вас не будет проблем с получением прав доступа, и неважно, если формально человек не является коммитером.
Сообществу очень сильно помогают статьи о продукте. Сама Apache Software Foundation помогает конференциями. Вы тоже можете описывать свой опыт взаимодействия, не обязательно только с Apache Ignite. Это могут быть и какие-то интересные use-case, студенческие работы. Они всегда публикуются в dev list.
Автор: dspavlov
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/java/288354
Ссылки в тексте:
[1] последней встрече сообщества Apache Ignite в Москве: https://www.meetup.com/ru-RU/Moscow-Apache-Ignite-Meetup/events/252272163/
[2] Individual Contributor License Agreement: http://www.apache.org/licenses/#clas
[3] рассказали на Хабре: https://habr.com/company/sberbank/blog/418777/
[4] Apache JIRA: https://issues.apache.org/
[5] Wiki: https://cwiki.apache.org/confluence/
[6] How To Contribute: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
[7] Источник: https://habr.com/post/419391/?utm_campaign=419391
Нажмите здесь для печати.