Вы решили присоединиться к разработке open source продукта. К чему готовиться?

    Здравствуйте, написать эту статью меня побудил мой опыт участия в 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 начинающим разработчикам перед тем, как начать искать реальную работу, поскольку это однозначно положительно повлияет как на опыт и навыки, так и на восприятие кандидата в глазах работодателя.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 12

      0
      Получается, что развитие оперсорсного продукта с точки зрения бюрократии и скорости разработки ничем не отличается от коммереского продукта большой фирмы, а то ещё и более замедлено, так?
        +3
        Я бы сказал, что «it depends». Вероятно, это сильно зависит от жизненного цикла продукта в продуктовой среде и от самого community. К примеру, для облачной платформы, которую без реальных стендов с железом, инфраструктурой, довольно проблемно протестировать (не все может быть сделано через unit-тесты и интеграционные тесты) развитие будет идти медленно. Если, вы делаете условный Minio, бежать можно быстрее.

        В целом, сам процесс переноса фич в основное дерево может идти очень медленно, хотя бы в силу того, что дизайн фич делается одними людьми, а их валидация и подтверждение другими. Те фичи, которые, к примеру, делает ShapeBlue, которые проходят через их кухню, вполне вероятно, что пройдут в master быстрее, чем мои.

        Короче, я не знаю как однозначно ответить на ваш вопрос)
        +5
        Да ну нафиг это ваше программирование. Пойду на токаря учиться…
          0

          А что мотивирует Вас тратить своё время на это?
          Я за открытые продукты и хочу развивать свой и мне не всегда понятно, что может двигать человеком, который сам захотел внести вклад в развитие продукта.
          Что получает этот человек взамен?

            +8
            Как я уже написал ранее, я сам использую Apache CloudStack в бизнесе, поэтому у меня есть непосредственный интерес в фичах и багфиксах. Я решил отправлять свои изменения в мэйнстрим, чтобы иметь к ним доступ в будущих релизах.

            Если я не буду этого делать, значит, что я не смогу использовать новые релизы CloudStack, поскольку это потребует портировать все мои изменения в новые релизы, что будет весьма затруднительно.
              +1

              Исправление ошибок, добавление новых фич, локализация.

                +1
                В первую очередь мотивирует личное использование продукта, и как следствие необходимость в новых фичах и исправленных багах.
                Кроме того, причиной может быть желание добавить дополнительную ценную строчку в резюме. Например, как мне кажется, наличие патчей в том-же ядре Linux может оказаться весьма ценной строчкой в резюме.
                0

                Иван, Помогите разобраться, кто является лидером в опен сорс проекте и кто принимает решения какие PR мержить и когда?

                  0
                  В каждом проекте свои правила игры, и зачастую ответ на этот вопрос не так уж тривиален. Мало того, внутренние войны между участниками, имеющими право на запись, тоже могут иметь место, как следствие, даже влитый код вполне может быть revert'нут другим человеком…
                  0

                  Здравствуйте. В широком смысле, кому владелец проекта дал права на запись, тот и может сливать изменения. Каждый проект имеет свою оргструктуру, например для Apache Software Foundation есть PMC: https://www.apache.org/dev/pmc.html


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


                  Если у вас в проекте другая организация, то и процессы могут быть иными.

                    0
                    UPD: важно еще разделять типы OSS-проектов. На мой взгляд можно выделить как минимум:

                    — квази-OSS — компания открывает свой продукт, сообщество неактивное, состоит из постоянных разработчиков компании, плюс нескольких активистов со стороны;

                    — user-based OSS — типа CloudStack, компактная группа основных пользователей совместно разрабатывает продукт под свои нужны, спонсируя своих разработчиков;

                    — community-based OSS — большАя группа контрибьюторов как от компаний, так и от индивидуальных разработчиков;
                    0
                    Поддерживаю автора, участие в крупных OpenSource проектах чаще боль, чем розовые порхающие бабочки…
                    С другой стороны наличие у человека принятых патчей в крупный проект, лично я бы рассматривал как огромный плюс к квалификации этого самого человека, поскольку это показывает насколько грамотно человек может аргументировать свою позицию и насколько хорошо умеет разбираться с чужим кодом.
                    А уж если человек сумел продавить новую фичу (а не просто исправил баг), то это уже плюс с восклицательным знаком…

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое