Привет! Меня зовут Дмитрий Павлов, я работаю в GridGain, а также являюсь коммиттером и участником PMC в Apache Ignite и контрибьютором в Apache Training. Недавно я выступал c докладом о работе коммиттера на митапе Сбербанка по open source. С развитием opensource-сообщества у многих все чаще стали возникать вопросы: как стать коммиттером, какие задачи брать и сколько строчек кода надо написать, чтобы получить эту роль. Когда мы думаем о коммиттерах, нам сразу представляются всемогущие и всезнающие люди с короной на голове и томиком «Чистый код» вместо скипетра. Так ли это? В своем посте я постараюсь ответить на все важные вопросы о коммиттерах, чтобы вы могли понять, действительно ли вам это нужно.
У всех новичков в opensource-сообществе проскакивают мысли о том, что им никогда не стать коммиттерами. Ведь для многих это престижная роль, которую можно получить только за особые заслуги, написав тонну кода. Но все не так просто. Взглянем на коммиттера со стороны коммьюнити.
При создании нового opensource-продукта мы всегда разрешаем пользователям использовать и исследовать его, а также модифицировать и распространять модифицированные копии. Но когда происходит неконтролируемое распространение копий ПО с внесенными изменениями, то мы не получаем контрибьюшенов в основную кодовую базу и проект не развивается. Вот тут уже необходим тот самый коммиттер, который имеет право собирать вклады пользователей в проект.
Начнем с того, что коммиттерство — это плюс к резюме, а для новичков в области программирования — еще больший плюс, ведь часто при устройстве на работу просят примеры кода.
Вторым несомненным преимуществом коммиттерства является возможность общаться с топовыми специалистами и тянуть какие-то крутые идеи из open source в свой проект. К тому же, если вы хорошо знаете некий продукт с открытым кодом, то можете устроиться в компанию, которая его поддерживает или использует. Существует даже мнение, что если не участвуешь в open source, то на высокие карьерные позиции не попасть.
Помимо плюшек в плане карьеры и трудоустройства, коммиттерство само по себе приятно. Тебя признает профессиональное сообщество, ты четко видишь результат своей работы. Не то что в какой-нибудь корпоративной разработке, где иногда вообще не понимаешь, зачем перекладываешь туда-сюда поля в XML.
В opensource-сообществах можно познакомиться с топовыми специалистами уровня Линуса Торвальдса. Но если вы не такой, не стоит думать, что там вам нечего делать — есть задачи разного уровня.
Ну и еще бывают дополнительные бонусы: коммиттеры Apache, например, получают бесплатно лицензию IntelliJ Idea Ultimate (хоть и с некоторыми ограничениями).
Все просто — нужно коммитить.
Если вы считаете, что на проектах для вас нет задач — вы ошибаетесь. Просто присоединяйтесь к интересующему вас сообществу и делайте то, что необходимо именно ему. В Apache Software Foundation есть отдельный гайд с требованиями к коммиттерам.
Самые разные — от разработки до написания тестов и документации. Да-да, вклад тестировщиков и документаторов в сообществе ценится наравне с вкладом разработчиков. Бывают нестандартные задачи — например, вести канал на YouTube и рассказывать другим пользователям, как вы используете opensource-продукт. Например в Apache Software Foundation есть отдельная страница, где указано, какая помощь требуется.
Нет. Это совсем не обязательно. Коммиттер не должен писать тонны кода. Но если вы написали большую фичу, комитету по управлению проектом легче будет оценить вас. Вклад в сообщество — это не только фичи, программирование и тестирование. Если вы пишите письмо и рассказываете о какой-то проблеме, предлагаете аргументированное решение — это тоже вклад.
Важно понимать, что коммиттерство — это доверие. Сделать вас коммиттером или нет, решают такие же люди как и вы на основании своих взглядов на вас, как на человека, который приносит пользу продукту. Поэтому вам, своими действиями и поступками в сообществе, надо завоевать это самое доверие.
Быть конструктивным, позитивным, вежливым и терпеливым. Помните, что в open source все волонтеры и никто никому ничего не должен. Вам не отвечают — подождите и напомните о своем вопросе через 3-4 дня. Вам постоянно не отвечают — что ж, open source дело добровольное.
Не просите что-то сделать для вас или за вас. У опытных участников сообщества есть чутье на таких «попрошаек» и тут же возникает аллергия на тех, кто хочет спихнуть им свою работу.
Если вам помогают, это здорово, но не злоупотребляйте. Не стоит писать: «Ребята, пофиксите это, а то я годовую премию теряю». Лучше спросите, куда вам двигаться дальше, и расскажите, что вы уже накопали по данному багу. А если пообещать по результатам решения проблемы обновить вики, то вероятность, что вам ответят, возрастет в разы.
Наконец, читайте Code of Conduct и учитесь задавать вопросы.
В проектах часто используется схема RTC, когда сначала все проходят ревью, а затем изменения сливаются в мастер. При такой схеме абсолютно все проходят ревью, даже коммиттеры. Поэтому в проект можно успешно контрибьютить, не являясь коммиттером. А для того чтобы легче быть выбранным в новые коммиттеры, можно заняться наставничеством над новыми участниками, делиться знаниями, создавать новые материалы.
Diversity — в понимании Apache Software Foundation, это, в том числе, аффилированность участников opensource-проекта несколькими компаниями. Если все аффилированы только одной организацией, то с потерей ее интереса к проекту все участники оттуда лихо сбегают. Diversity обеспечивает долгосрочность, стабильность проекта, разносторонний опыт и широкий спектр мнений участников.
В opensource-проектах встречается два типа людей: те, кто работает в организации, что контрибьютит в данный продукт, и те, кто трудятся здесь по любви, то есть волонтеры. Кто из них продуктивнее? Как правило, участники, которые поддерживают продукт со стороны организации-контрибьютора. У них попросту больше времени и есть явная мотивация докопаться до истины, они сфокусированы на задаче и ближе к пользователю.
Те, кто делает это «из любви», тоже мотивированы, но по-другому — они жаждут изучить проект, сделать мир лучше. И как раз именно такие участники более стабильны и ориентированы на долгосрочную перспективу, потому что тот, кто пришел в сообщество по собственной инициативе, вряд ли покинет его одним днем.
Как найти баланс между продуктивностью и стабильностью? Есть два варианта. Первый вариант: когда участник работает в компании, которая официально занимается этим opensource-проектом, и делает в нем что-то дополнительно, из собственного интереса — например, поддерживает новичков. Второй вариант — это компания, пережившая opensource-трансформацию. Например, когда сотрудники четыре дня в неделю пилят основной бизнес-проект, а остальное время занимаются open source.
Коммиттерство — хорошая и полезная тема, но не стоит стремиться именно к тому, чтобы стать коммиттером. Данную роль можно получить не за код, и она не доказывает ваших знаний. Важна только экспертиза, то есть те знания и опыт, которые вы приобретете, изучая проект, копаясь в нем и помогая другим решать проблемы.
У всех новичков в opensource-сообществе проскакивают мысли о том, что им никогда не стать коммиттерами. Ведь для многих это престижная роль, которую можно получить только за особые заслуги, написав тонну кода. Но все не так просто. Взглянем на коммиттера со стороны коммьюнити.
Кто такой коммиттер и зачем он нужен?
При создании нового opensource-продукта мы всегда разрешаем пользователям использовать и исследовать его, а также модифицировать и распространять модифицированные копии. Но когда происходит неконтролируемое распространение копий ПО с внесенными изменениями, то мы не получаем контрибьюшенов в основную кодовую базу и проект не развивается. Вот тут уже необходим тот самый коммиттер, который имеет право собирать вклады пользователей в проект.
Зачем становиться коммиттером?
Начнем с того, что коммиттерство — это плюс к резюме, а для новичков в области программирования — еще больший плюс, ведь часто при устройстве на работу просят примеры кода.
Вторым несомненным преимуществом коммиттерства является возможность общаться с топовыми специалистами и тянуть какие-то крутые идеи из open source в свой проект. К тому же, если вы хорошо знаете некий продукт с открытым кодом, то можете устроиться в компанию, которая его поддерживает или использует. Существует даже мнение, что если не участвуешь в open source, то на высокие карьерные позиции не попасть.
Помимо плюшек в плане карьеры и трудоустройства, коммиттерство само по себе приятно. Тебя признает профессиональное сообщество, ты четко видишь результат своей работы. Не то что в какой-нибудь корпоративной разработке, где иногда вообще не понимаешь, зачем перекладываешь туда-сюда поля в XML.
В opensource-сообществах можно познакомиться с топовыми специалистами уровня Линуса Торвальдса. Но если вы не такой, не стоит думать, что там вам нечего делать — есть задачи разного уровня.
Ну и еще бывают дополнительные бонусы: коммиттеры Apache, например, получают бесплатно лицензию IntelliJ Idea Ultimate (хоть и с некоторыми ограничениями).
Что делать, чтобы стать коммиттером?
Все просто — нужно коммитить.
Если вы считаете, что на проектах для вас нет задач — вы ошибаетесь. Просто присоединяйтесь к интересующему вас сообществу и делайте то, что необходимо именно ему. В Apache Software Foundation есть отдельный гайд с требованиями к коммиттерам.
Какие задачи придется решать?
Самые разные — от разработки до написания тестов и документации. Да-да, вклад тестировщиков и документаторов в сообществе ценится наравне с вкладом разработчиков. Бывают нестандартные задачи — например, вести канал на YouTube и рассказывать другим пользователям, как вы используете opensource-продукт. Например в Apache Software Foundation есть отдельная страница, где указано, какая помощь требуется.
Надо ли написать большую фичу, чтобы стать коммиттером?
Нет. Это совсем не обязательно. Коммиттер не должен писать тонны кода. Но если вы написали большую фичу, комитету по управлению проектом легче будет оценить вас. Вклад в сообщество — это не только фичи, программирование и тестирование. Если вы пишите письмо и рассказываете о какой-то проблеме, предлагаете аргументированное решение — это тоже вклад.
Важно понимать, что коммиттерство — это доверие. Сделать вас коммиттером или нет, решают такие же люди как и вы на основании своих взглядов на вас, как на человека, который приносит пользу продукту. Поэтому вам, своими действиями и поступками в сообществе, надо завоевать это самое доверие.
Как себя вести?
Быть конструктивным, позитивным, вежливым и терпеливым. Помните, что в open source все волонтеры и никто никому ничего не должен. Вам не отвечают — подождите и напомните о своем вопросе через 3-4 дня. Вам постоянно не отвечают — что ж, open source дело добровольное.
Не просите что-то сделать для вас или за вас. У опытных участников сообщества есть чутье на таких «попрошаек» и тут же возникает аллергия на тех, кто хочет спихнуть им свою работу.
Если вам помогают, это здорово, но не злоупотребляйте. Не стоит писать: «Ребята, пофиксите это, а то я годовую премию теряю». Лучше спросите, куда вам двигаться дальше, и расскажите, что вы уже накопали по данному багу. А если пообещать по результатам решения проблемы обновить вики, то вероятность, что вам ответят, возрастет в разы.
Наконец, читайте Code of Conduct и учитесь задавать вопросы.
Как внести вклад, если ты не коммиттер?
В проектах часто используется схема RTC, когда сначала все проходят ревью, а затем изменения сливаются в мастер. При такой схеме абсолютно все проходят ревью, даже коммиттеры. Поэтому в проект можно успешно контрибьютить, не являясь коммиттером. А для того чтобы легче быть выбранным в новые коммиттеры, можно заняться наставничеством над новыми участниками, делиться знаниями, создавать новые материалы.
Diversity — польза или вред?
Diversity — в понимании Apache Software Foundation, это, в том числе, аффилированность участников opensource-проекта несколькими компаниями. Если все аффилированы только одной организацией, то с потерей ее интереса к проекту все участники оттуда лихо сбегают. Diversity обеспечивает долгосрочность, стабильность проекта, разносторонний опыт и широкий спектр мнений участников.
По любви или по расчету?
В opensource-проектах встречается два типа людей: те, кто работает в организации, что контрибьютит в данный продукт, и те, кто трудятся здесь по любви, то есть волонтеры. Кто из них продуктивнее? Как правило, участники, которые поддерживают продукт со стороны организации-контрибьютора. У них попросту больше времени и есть явная мотивация докопаться до истины, они сфокусированы на задаче и ближе к пользователю.
Те, кто делает это «из любви», тоже мотивированы, но по-другому — они жаждут изучить проект, сделать мир лучше. И как раз именно такие участники более стабильны и ориентированы на долгосрочную перспективу, потому что тот, кто пришел в сообщество по собственной инициативе, вряд ли покинет его одним днем.
Как найти баланс между продуктивностью и стабильностью? Есть два варианта. Первый вариант: когда участник работает в компании, которая официально занимается этим opensource-проектом, и делает в нем что-то дополнительно, из собственного интереса — например, поддерживает новичков. Второй вариант — это компания, пережившая opensource-трансформацию. Например, когда сотрудники четыре дня в неделю пилят основной бизнес-проект, а остальное время занимаются open source.
Коммиттер — быть или не быть?
Коммиттерство — хорошая и полезная тема, но не стоит стремиться именно к тому, чтобы стать коммиттером. Данную роль можно получить не за код, и она не доказывает ваших знаний. Важна только экспертиза, то есть те знания и опыт, которые вы приобретете, изучая проект, копаясь в нем и помогая другим решать проблемы.
MicroNovaX
А почему именно коммитер? Разве это называется не контрибутор?
Есть какие-то весомые различия между этими двумя словами? Первая вариация звучит ужасно, имхо ;c
mwambanatanga
Контрибьютер шлёт патчи. Коммиттер вливает их в код. Как-то так.
dspavlov Автор
Комиттер (калька с английского Committer) — это контрибьютор (девелопер) с правом пушить изменения в мастер. Да, можно достаточно успешно вносить вклад именно как разработчик, не являясь коммиттером.
ex3ger
Committer — это тот, чьи коммиты вошли в репозиторий, контрибьютить можно не только коммитами, например, создавая issues и проводя review, а правом push'ить в master обычно обладает maintainer или admin.
Hilbert
По-моему, общепринятое значение всё-таки другое — это человек, который может пушить сам, а не только отправлять пулл-реквесты. По крайней мере, в Python это понимают именно так:
A tracker admin should also flip your “is committer” bit in the tracker’s account screen. This will add the Python logo next to your name in discussions on the tracker.
https://devguide.python.org/coredev/
ex3ger
Это скорей следует из модели сопровождения проекта… Например, в Git есть разделение Author и Committer на каждый коммит в истории. Например, если автор шлет патч почтой, а Maintainer делает commit + push сразу в master branch, то да, последнего можно назвать Committer.
dspavlov Автор
Важно отметить, что пост написан по опыту участия именно в Apache Software Foundation и нескольких проектах в ней.
От проекта к проекту процесс коммита, роли и требования немного изменяются. В других Foundations (a их еще минимум десяток) могут быть немного другие определения коммитера.
ex3ger
Конечно, важно. Я отвечал на изначальный вопрос — в чем отличия между словами, а для этого важнее понимать терминологию и контекст их появления, от этого может меняться их смысл.
everyonesdesign
<зануда мод>«Комиттер» в данном случае это не калька а заимствование. Если «commit» — это «совершать», то калька была бы «совершитель».
dspavlov Автор
да, согласен, или «фиксирователь».
Кстати, хорошее замечание, что вклад можно делать не только коммитами. При этом участник может быть избран «фиксирователем», возможно, без единой «фиксации» именно в коде. А для дальнейшего продвижения в Комитет управления проектом (PMC) не-только-код в участии в сообществе становится еще более важной составляющей.
armab
Разница между Committer vs Contributor описана здесь: