11 сентября в Санкт-Петербурге прошел Java Meetup, полностью посвященный Apache Ignite. Огромное спасибо организаторам за приглашение и возможность рассказать об Open Source от лица разработчика этого самого Open Source. Учитывая позитивную реакцию зала, я решил поделиться презентацией и с теми, кто не смог присутствовать на митапе.
Под катом вас ожидает текстовая версия презентации, полная субъективного восприятия Open Source, как позитивного, так и негативного.
Итак, меня зовут Антон Виноградов, и последние 4 года я занимаюсь разработкой Open Source проекта Apache Ignite. На его примере я хочу рассказать о том, как делается Open Source, какую личную пользу вы можете извлечь из участия в сообществе, и в конечном счете, хочу вас на это участие вдохновить.
Рассказывать об Open Source я буду на примере Apache Ignite — одного из многочисленных проектов Apache Software Foundation. ASF — одно из самых крупных Open Source сообществ с почти 20-летней историей. Своими успехами оно обязано, в первую очередь, процессам и принципам мотивации, заложенным еще в далеком 1999 году, но актуальным до сих пор. Эту «философскую» сторону сообщества подробно описал в своей статье Дмитрий Павлов, мы же рассмотрим «прикладную» сторону разработки Open Source на примере Apache Ignite.
Допустим, вы решили внести вклад в развитие сообщества. Как это сделать?
В целом, нельзя говорить, что Open Source — это именно про код. Множество разных активностей может дать весомый вклад, и лишь некоторые из них непосредственно связаны с кодом.
— Если вы нашли проблему — изложите ее на юзерлисте, где ее проработают;
— Если вы готовы — можете поучаствовать в проработке задач на девлисте и в координации действий;
— Если вы крутой разработчик — для вас это возможность написать много хорошего кода;
— Который сможет отревьюить крутой ревьюер;
— Если вы хороший менеджер, то сможете помочь с выпуском релиза;
— Если вы хороший рассказчик или просто фанат проекта, как я, то сможете заняться популяризацией решения.
Наиважнейшим вкладом в Open Source является информирование сообщества о проблемах продукта, о его недостатках. Но здесь важно понимать, что Open Source — это не заказная разработка и сообщество вам ничем не обязано. 90% успеха зависит зависит от вас. Если вы нашли проблему, то вашим вкладом в Open Source будет ее детальный анализ и поиск вариантов решения. Ожидается, что вы будете активно участвовать в обсуждении проблемы. Если вы сообщите о ней и уйдете, то проблема решена не будет.
Идеальный вариант: вы пришли, рассказали о проблеме и готовы драйвить этот тред до самого финала, до решения проблемы.
Каждая проблема, обсужденная, но не решенная в юзерлисте, попадает в девлист, где происходит ее проработка. Здесь разработчики обсуждают, как правильно реализовать фичу или закрыть баг.
Девлист — это некое «место силы» проекта, где вы можете пообщаться с крутыми разработчиками, которые потенциально могли бы заработать огромные деньги на тренингах, семинарах, консультациях, написании статей. Но эти люди заняты тем, что пишут реальный код, именно тот код, который сейчас на острие прогресса двигает всё вперед. Мне кажется, у вас просто нет другого способа пообщаться с этими людьми, кроме как на девлисте.
Кроме того, девлист — это вдумчивая переписка, где у вас есть возможность подумать час-другой и только потом ответить письмом, в отличие от мессенджеров, где сложно читать переписку и понимать все глобально. В моем понимании девлист — это такой хороший профильный технический журнал, который можно не только читать, но и принимать непосредственное участие в его создании.
Работа в девлисте, как и любая работа в Open Source, публична. Если вы вносите в него какой-то вклад, то он будет нагуглен вашим текущим/будущим работодателем или коллегами. Лично для меня, при оценке кандидата при приеме на работу, его участие в девлистах имеет большую значимость, чем его профиль на гитхабе. Профиль на гитхабе характеризует только умение писать код, а опыт на девлисте характеризует еще и опыт командной разработки. Причем такой опыт, где важна именно индивидуальная ответственность, а не коллективная. На мой взгляд, этот навык наиболее важен для хорошего разработчика, и он лучше всего развивается при общении в девлистах в Open Source.
Переходим непосредственно к разработке.
После согласования доработок на девлисте, а обычно согласуются принципиальные дизайн-решения, задача готова к реализации. Задачу реализуют чаще всего те же люди, кто ее предлагал и драйвил, но не всегда. Одному человеку в разумные сроки некоторые фичи не осилить — особенно если это фича в половину Ignite.
Если вы хороший разработчик и готовы пилить Open Source — приходите и выбирайте одну из проработанных задач, согласуйте ее с автором и начинайте пилить.
В Open Source все коммуникации публичные. Обсуждение идет либо на девлисте, либо в issue-трекере. Важно стараться избегать реализации чего-либо без обсуждения, потому что высока вероятность сделать что-то неправильно. Хорошим тоном считается уточнить все принципиальные моменты перед началом разработки, чтобы не делать лишнюю работу.
Теперь о важном.
Разработка в Open Source — это хорошая и бесплатная школа. Крутые разработчики, профессионалы своего дела, декомпозируют задачи, позволяют вам их реализовать, помогают при любых сложностях — и в конечном итоге появляется коммит, характеризующий именно вас прекрасным разработчиком. Как я уже сказал, это может быть нагуглено, это часть вашего портфолио.
Если вы не хотите что-то реализовывать безвозмездно, подумайте о том, что этот вклад — грубо говоря, ваша кредитная история. В ней видно, что вы все делаете правильно, умеете писать код и обсуждать задачи, что с вами легко работать.
Опасный момент в Open Source-разработке — это то, что в нее может прийти абсолютно любой человек. Думаю, в каждом Open Source проекте есть такой человек, который годами отвлекает всех, а потом уходит, не внеся никакого вклада. И хорошо если уходит.
Не быть таким человеком — это уже важный вклад в Open Source сообщество!
Итак, вы решились запилить что-нибудь в Open Source. Велика вероятность, что с первого раза вы сделаете все неправильно. Со временем вы наберетесь опыта, который поможет делать все правильно — но не в первые разы.
В этом случае вам поможет ревью.
В большинстве проектов (в Apache Ignite точно) ревью происходит перед коммитом, что позволяет сохранять master- или development-бранчи чистыми. И у нас есть ряд принципиальных требований, которые должны быть выполнены перед тем, как код отдается на ревью.
Кодстайл.
В проекте очень много кода, он пишется разными людьми, с разной мотивацией и в разное время. Если бы он был написан по-разному, его невозможно было бы читать. Поэтому кодстайл для нас принципиален. Если на ревью вам говорят, что нужна пустая строка — это принципиально.
Каждая фича должна пройти регрессию.
Если проект большой, то вы никогда не угадаете, как ваша маленькая доделка повлияет на всю функциональность. На текущий момент у нас порядка 50 тысяч тестов, каждая фича покрыта одним или более. По упавшим тестам регрессия поможет определить, что вы что-то сломали. Для вас это хороший способ не думать лишнего и быстро все понять — есть поломки или нет. Если говорить о затратах на тестирование, у нас есть кластер из ~ ста машин, которые прогоняют регрессию по одному бранчу за два часа.
Изменения в существенных областях.
Если вы меняете что-то в «коре» — вы должны пройти через бенчмаркинг. Какой бы крутой и решающей все проблемы не была фича, если она ухудшит пару throughput/latency, то мерджить ее нельзя. Деградация быстродействия в нашем продукте недопустима.
API.
Есть два момента. Новый API не должен ломать компиляцию у того, кто использовал старую версию продукта. И не должно появляться методов, которые будут deprecated через пару месяцев. Делаешь API — делай сразу хорошо.
Вклад ревьюера — самый важный из самых трудных вкладов в Open Source. Ревьюер — это тот человек, кто готов тебе помочь, в некоторых случаях он делает до 90% работы. Ревьюер подталкивает, объясняет, чуть ли не пишет за тебя код, если необходимо. Проблема в том, что когда фича попадает в master, она числится за контрибьютором, а не за ревьюером. Цените безвозмездный труд ревьюера.
Если вы работаете в Open Source сообществе, старайтесь, чтобы работа ревьюера была удобной. Базовые правила — это сделать фикс минимальным по объемам, но максимально понятным. Если вы видите перед ревью, что можете сократить объем фикса и увеличить его понятность, сделайте это.
Актуальная версия Apache Ignite — 2.6. Релизы происходят примерно раз в 3 месяца.
Релиз версии 2.7 готовит сотрудник Сбертеха Николай Ижиков, уже почти год как коммитер в проекте. Это знаменательное событие для проекта, потому что впервые в его истории релиз проводит не сотрудник компании Gridgain, компании, создавшей Apache Ignite и передавшей его в ASF. Это очень хорошо, потому что мы движемся в направлении идеального Open Source, когда продукт отвязывается от конкретной коммерческой компании и существует самостоятельно. Надеемся, что опыт будет удачным, и следующие релизы будут проводить уже сотрудники других компаний, коммитеры из которых у нас есть — Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo и т.д.
Популяризация решения — как и в случае с девлистом — это вклад не только в проект, но и в вас самих. Такие вещи гуглятся и влияют на решения о найме. Также это способ для вас ненадолго отложить код и заняться чем-то интересным, но не менее полезным.
Переходим к главному вопросу: почему стоит участвовать в Open Source проектах?
Не перестану повторять: участие в Open Source — это ваш стремительный рост. По моим наблюдениям — где-то год за три, если не больше по сравнению с прикладной разработкой. Это ваш шанс на собеседовании ошарашить оппонента фразой «Эту штуку пилил я, я точно знаю, как она работает, а ты не прав!» — я так делал два раза, ощущения незабываемые.
Любой хороший программист должен следить за трендами. Open Source — это самый горячий, самый перспективный тренд современности в разработке ПО. Участие в этом тренде дает гарантию уважения от ваших коллег (прямо сейчас) и некоторую стабильность, финансовые гарантии (в будущем).
Во многих компаниях не так мало Open Source, как принято думать. Многие компании ищут сотрудников принципиально с опытом работы в Open Source, либо под конкретный проект именно на full-time. Компаниям важно иметь внутреннюю экспертизу по проекту, иметь возможность влиять на его развитие. Например, компания может попросить вас допилить безопасность в продукте или пофиксить тот баг, который есть только в ее продакшене. И сделать это быстро, а не когда сообщество с этим согласится. Если у вас если опыт работы в Open Source или в конкретном проекте, для вас это будет конкурентным преимуществом при найме или продолжении работы в своей компании.
В качестве доказательства — в нашей команде, которая пилит Open Source в Сбербанк-Технологиях, есть крайне интересные вакансии (MSK и SPB) и Apache Ignite — не единственный продукт, который мы дорабатываем.
Надеюсь, всем было интересно, и многие задумаются об участии в Open Source движении, а те кто уже задумался — перейдут к конкретным действиям.
P.s. Для тех кто любит теплый и ламповый звук — доступна аудио версия «Без купюр».
Автор: randoom
