Здравствуйте, написать эту статью меня побудил мой опыт участия в open-source проекте Apache Cloudstack, куда я периодически отправляю фичи и багфиксы. Меня нельзя назвать активным контрибьютором, поскольку я вношу вклад лишь время от времени, когда мне что-то требуется от продукта или я нахожу баг, от которого моему кластеру "зудит".
Опыт, описанный в этой статье — сугубо личный, причем характерный именно для продукта Apache Cloudstack.
CloudStack — продукт для создания средних и больших облачных сред приватного и публичного типа.
Apache CloudStack используется большим количеством компаний, в том числе, например частью из тех, которые приведены в Leaders и Challengers квадранта Gartner.
По моим сведениям, как минимум, BT (British Telecom), Interoute, KDDI, Datapipe, Leaseweb используют CloudStack. Неполный список известных пользователей можно посмотреть по ссылке в Wikipedia.
Все коммьюнити разные — прошу не проецировать мой опыт на все проекты, в каждом будут свои особенности и нюансы.
Научитесь использовать Git как бог. Если вы работаете с Git на уровне push/pull/checkout, как я, вы будете страдать. Вы должны уверенно уметь делать cherry pick, merge, squash и прочие фокусы, предназначенные для переноса кода между ветками.
К примеру, мой последний pull request "проболтался" в статусе рассмотрения с 27 января по 14 марта. За это время вы можете пройти все стадии принятия горя — отрицание, обиду, переговоры, депрессию, принятие. При этом, это будет сопровождаться фразами "Hey, USERNAME, please resolve the conflicts".
Если участок кода, куда вы отправляете свои изменения, находится в активной разработке, то вы можете разрешать конфликты 5-10 раз. Это является одним из основных демотиваторов для контрибьюторов, поэтому некоторые фичи остаются не слитыми годами — автор просто отчаивается, меняет работу, забивает.
Будьте терпеливым. В общем-то, в предыдущем абзаце все написано, вам надо быть терпеливым, объяснять, быть гибким. К примеру, опять же рассмотрим последний PR, который я отправил в CloudStack.
Сначала я открыл Issue, где спросил совета как лучше сделать. Совета я, конечно, никакого не получил, зато получил, "Hi @bwsw — I believe this is what you're looking for:#3510", что было, конечно же, не тем, о чем я писал — человек просто не разобрался, не захотел разобраться, это не уложилось в картину мира, и он написал то, что написал. Само собой, меня начало бомбить, но я постарался объяснить. На этом взаимодействие закончилось.
Поскольку фича мне была нужна, я решил все же код написать — написал и открыл PR, на PR были назначены аудиторы, один из которых мне написал "Hi @bwsw, I find the XML use case pretty similar to what's been introduced by this PR: #3510.". Я начал опять объяснять смысл фичи и слегка конфликтовать с неразумными европейцами, которые не могут понять, что то, что я сделал, в коде отсутствует. В итоге, немного жести, немного изменений, 45 дней ожидания, чуть-чуть конфликтов и PR был принят.
Из-за этого, русских, как мне говорили, недолюбливают — мы слишком директивны и легко тыкаем носом других.
Вы будете непоняты. См. предыдущий пункт. Если вы делаете то, что до этого в продукте не было широко использовано, вас просто могут не понять. Приложите усилия для того, чтобы вашу фичу поняли.
Ваш PR могут просто не принять. Если вы делаете какое-то изменение, которое никому кроме вас не нужно, возможно, ваш PR никогда не будет принят. Если вы что-то не понимаете в архитектуре, исправили свою ошибку, но другой код перестал работать — ваш PR не будет принят. В общем, довольно много вариантов, когда интродуцированные вами изменения не будут приняты. К счастью, в моей практике такого не было.
Вам не помогут начать. Хорошо, если в проекте есть Developer's Guide или какой-то вариант 101, который позволяет вам понять как настроить среду, скомпилировать проект и запускать тесты. Если вы начнете коммуницировать в духе "Я делаю X, ожидаю Y, а ничего не выходит! ПАМАГИТЕ!", никто вам не поможет. Вы должны будете сами со всем разобраться.
То есть, onboarding, понимание архитектуры будет полностью на вас. Возможно, вы просто потратите неделю на то, чтобы найти места в коде, которые вы хотите усовершенствовать или исправить. Это сложно.
Ваша блестящая идея никому не нужна. Не думайте, что открыв Issue с блестящей идеей, делаете великую работу. Если вы сами не реализуете ее, никто ее не реализует, она никому не будет нужна. Много кто может предложить улучшение — мало кто может протащить улучшение в релиз.
Не ждите благодарности. В определенный момент, вам может показаться, что вам должны быть благодарны за ваш труд. Это не так. Если вы не автор, который в режиме 160 часов в месяц контрибьютит в проект, никто не заметит, если вы уйдете. Кроме того, вам вряд ли скажут спасибо за фичи, которые нужны только вам.
Вас будут заставлять исправлять код. Если в проекте хорошие инженеры, вас будут многократно просить изменить код, если он не будет соответствовать критериям качества.
В проект будет просачиваться говнокод. Несмотря на то, что что вы будете раз за разом исправлять свой код, в проект будут попадать порции говнокода с плохим дизайном, который ангажирован участниками, имеющими влияние.
Real-life gossip. ShapeBlue — основной контрибьютор Apache CloudStack. Эти ребята делают очень много для продукта, у них несколько full-time инженеров и реальная клиентская база в лице BT, Apple и другого крупняка. Эту историю я услушал от немецких коллег на митапе. В CS был внесен код, который добавлял High Availability и watchdog-и для аппаратных узлов. По словам коллеги, код был сделан для Apple в рамках контракта и ускоренно проведен в релиз без требуемого широкого тестирования. Код был глючным и не работал как надо.
Надо отметить, что CS — большой сложный продукт, я, например, вышеуказанную фичу не использую, и мне на нее фиолетово. Даже релиз, в котором она появилась я не использовал на тот момент, то есть сообщество просто пропустило глючный код в релиз, а потом несколько релизов его исправляло.
Релиз-менеджер может привести релиз к катастрофе. У CS 4.10 был релиз-менеджер девушка (никакого сексизма не ищем здесь) из Accelerite, компании, которая у Citrix выкупила права на Citrix Cloud Platform (коммерческую поставку Apache CloudStack). Так вот, 4.10 был просто разочарованием — полная катастрофа. У релиза 4.11 релиз-менеджером был архитектор ShapeBlue Rohit Yadav — это один из впечатляющих релизов.
Иногда багфикс уже есть, но его нет в дереве проекта. Так произошло с багом, который я нашел в своем облаке. Баг для меня критичный, вообще удивительно, что я первым его нашел. В общем, я описал баг, и товарищ weizhouapache прислал патч для него из внутреннего дерева кода их компании (LeaseWeb). То есть, у людей был код, но они его не отправляли в основное дерево по каким-то причинам. Вполне может быть, что бюрократическим. В этом смысле наличие "воли" протащить что-то в код не менее важно, чем сам код.
Со временем вы можете решить сделать Fork. Если вам надоест бороться с системой, вы довольно крупный игрок и понимаете, что продукт будет вас устраивать в течение долгого времени, нужно лишь исправлять баги и делать нишевые фичи, то вы можете сделать Fork. С CloudStack так тоже было, когда Shuberg Philis заявил о fork-е и начал пилить отдельный продукт Cosmic — тоже open source продукт, но которым, кроме Shuberg Philis никто, похоже, не пользуется. Причиной Fork-а стало разногласие о темпах развития релизов: Shuberg Philis настаивал на более редких, но более качественных релизах, основная часть активного сообщества хотела быстрее интродуцировать новые фичи.
Вместо заключения
История получилась в темных тонах. Предполагаю, что для других проектов все может быть по-другому.
Безусловно, участие в open source проектах делат вас лучше, как инженера, позволяя прикоснуться к работе над сложным продуктом вне устоявшихся корпоративных процессов, где вы за итерацию scrum не только сделали много фич и пофиксили баги, но и выпустили релиз и провели демо. Здесь, вероятно, все будет по-другому.
В первую очередь, участвуйте в open source проектах для себя. Как только вам это больше не нужно, даже если вы запилили существенную часть кода — смело выходите, поскольку шоу будет продолжаться и без вас или оно того не стоит.
Я часто советую участвовать в проектах OSS начинающим разработчикам перед тем, как начать искать реальную работу, поскольку это однозначно положительно повлияет как на опыт и навыки, так и на восприятие кандидата в глазах работодателя.
Автор: Иван Кудрявцев
