Home

В жизни многих разработчиков и большого количества IT-компаний настаёт момент, когда создание open source-проектов становится не менее важным, чем написание кода для внутренней разработки. По просьбе «Лаборатории Касперского» Евгений Мацюк, один из создателей open source-фреймворка для автотестов Kaspresso, делится своими рассуждениями, почему это решение оказалось полезно как для сообщества, так и для самой компании.

Что такое современный open source

Сейчас любой проект, любую свою разработку можно легко выложить в свободный доступ в онлайн-репозиторий. Самый популярный, конечно, GitHub, там крупное и активное коммьюнити из СНГ, а зарубежных пользователей ещё больше. Но есть и альтернативные платформы, их несложно найти.

Ещё до работы в «Лаборатории Касперского» я выкладывал на GitHub свои open source-проекты, например архитектурный CookBook по оформлению Android-проектов. Kaspresso мы с командой тоже выложили на GitHub.

Как зарождался Kaspresso

В 2018 году в «Лаборатории Касперского» уже был отдел автотестирования. Перед коллегами стояла задача — сделать круто работающие интеграционные и E2E-автотесты, которые позволят значительно сократить релизный цикл. На одной конференции мы услышали доклад про автотестирование, из которого узнали несколько важных фактов. Во-первых, у коллег из компании-докладчика тестирование не просто работало, а сильно сокращало релизный цикл. Во-вторых, они основывали свои автотесты на нативных инструментах, например Espresso. Там был ряд преимуществ по сравнению с использовавшимся у нас на тот момент Appium, который позволял писать E2E-тесты, но не давал, например, разрабатывать более быстрые и стабильные функциональные и интеграционные тесты.

Я до этой конференции вообще не был причастен к теме автотестов, занимался в компании мобильной разработкой. Но после доклада и пары выпусков подкаста AndroidDev Podcast загорелся. Где-то полгода изучал вопрос, а потом постепенно убедил менеджмент, что будущее именно за нативными автотестами и что нам нужно выделить людей на такой проект. Мы начали разрабатывать Kaspresso с начала 2019 года.

Почему мы решили сделать Kaspresso опенсорсным

В ходе разработки мы довольно быстро начали оформлять все наши наработки в полноценный фреймворк. Сперва объединили их в библиотеку, потом допиливали к ней фасад, прихорашивали, чтобы другие разработчики внутри «Лаборатории Касперского» тоже могли пользоваться автотестами. Уже на этом этапе и у меня, и у коллег появилась мысль, что выходит хорошо и проект надо бы сделать опенсорсным.

Сначала мы решили оценить, насколько вообще сообществу нужен Kaspresso. На крупной конференции в 2019 году представили доклад о том, как идёт работа, какие получены результаты. После этого выступления нам начали активно писать: «Ребята, очень круто, а опенсорс планируется?». Кроме того, я пообщался на тему автотестирования с руководителем Android-разработки HeadHunter. У их команды были похожие идеи и результаты. Мы поняли, что сообщество заинтересовано, есть другие команды, с которыми можно объединить усилия, значит, нужно опенсорсить. Я, как руководитель проекта, пошёл к менеджменту и предложил сделать разработку по Kaspresso открытой.

Почему менеджмент иногда выступает против open source

Зададимся простым вопросом: о чём больше всего заботится бизнес? Очевидно, что о финансовом благополучии. О том, чтобы разрабатываемые продукты приносили прибыль.

Первая причина, почему опенсорс пугает бизнес, тоже простая и понятная: как заработать на опенсорсной разработке? Её, очевидно, не всегда можно монетизировать, ведь она не повышает напрямую показатели и метрики продукта. Её зачастую сложно конвертировать в деньги.

Дело, конечно, не только в прибыли. Каждая разработка в идеале — это в том числе конкурентное преимущество для компании. Например, компания создала уникальный проект с крутыми фичами и теперь может делать что-то, что недоступно другим игрокам на рынке. Уступать подобные преимущества, отдавать их даром всем, в том числе и конкурентам, бизнес тоже зачастую не готов.

Наконец, стоит помнить, что на любую разработку уходят время и человеческие ресурсы. Когда менеджмент решает, что лучше: сделать новую фичу для уже существующей внутренней разработки или направить разработчиков на трудоёмкий open source-проект —  выбор практически всегда очевиден.

Аргументы в защиту open source перед менеджментом

Разумеется, диалог о старте Open source-разработки или переводе туда уже существующего проекта будет в каждой компании разным. С Kaspresso нам повезло. Виктор Яблоков, руководитель мобильной разработки в «Лаборатории Касперского», поддерживает open source-проекты, так что отчасти менеджмент сразу был на нашей стороне.  В другой компании руководство может быть идеологически против, и тогда никакие аргументы не помогут.

Чтобы убедить оппонента в споре, нужно приводить аргументы с его позиции. Бизнесу зачастую всё равно, почему open source — это хорошо для вас, команды и мира в целом. Но если донесёте, что это выгодно именно для самого бизнеса, тогда он заинтересуется.

Первый и самый важный довод: да, open source не конвертируется напрямую в деньги. Зато отлично конвертируется в таланты, которые будут эти деньги зарабатывать для компании в будущем. Сейчас в IT-сегменте идёт бескомпромиссная война за крутых специалистов. Одними деньгами её не выиграть: все крупные компании сейчас предлагают примерно одинаковые по уровню зарплаты. Поэтому разработчик смотрит не только на деньги и условия, но и на сам бренд. Чего за последнее время добилась компания? Хорошие ли у неё продукты? Сильная ли команда? В этой ситуации open source для бизнеса — возможность «прорекламировать» бренд всем потенциальным соискателям. К нам с момента запуска Kaspresso пришло немало ребят, которые на собеседовании честно говорили: «Да, впечатлился. Крутая разработка, пользуюсь сам, здорово, что такой open source-проект. Возьмёте поработать?».

То, насколько силён бренд с технической точки зрения, играет важную роль в долгосрочной перспективе. Да, выкладывая разработку в свободный доступ, бизнес может лишиться определённой части прибыли и в какой-то степени уникального технического преимущества перед конкурентами. Но зато узнаваемость бренда в сообществе при этом растёт, как и доверие рынка. Ведь open source нельзя выложить сырым и костыльным. Сообщество не оценит. В СНГ люди не стесняются честно и жёстко говорить, что думают о подобных продуктах, поэтому команда, которая занимается такой разработкой, должна приложить все усилия, чтобы на выходе пользователи, внешние и внутренние, получили понятное и работающее решение.  Если компания в состоянии сделать крутой open source-продукт, на который переходят конкуренты, это показатель того, что она лидирует в своей сфере. IT-гиганты вроде Google и Apple регулярно делятся с сообществом своими открытыми наработками, в том числе ради вот такого технического престижа.

Источник https://opensource.com/article/18/9/benefits-company-open-source-programs

С open source-продуктом проще подсветить свой бренд на международном рынке, а это тоже дорогого стоит. Нужно только организовать хорошую поддержку как минимум на английском. Если решение классное, то его начнут использовать люди из разных стран. Сейчас Kaspresso чаще всего скачивают американские пользователи, на втором месте немецкие и только на третьем — российские.

Перед выпуском Kaspresso мы провели большое количество исследований, постоянно общались с коллегами из других команд «Лаборатории Касперского», которые использовали автотесты в работе. По их отзывам многое меняли, прихорашивали. Мы встречались с коллегами из Авито и HeadHunter, у которых тоже был опыт в разработке подобных проектов, чтобы с ними обсудить возможные ошибки и способы их обойти. Затем мы написали подробные и понятные гайды по использованию. В итоге получилось, что наши коллеги из других подразделений сразу получили мощный и при этом доступный набор инструментов, который после запуска не требовал никаких заплат и дополнений. Таким образом мы сохранили для бизнеса немало потенциальных человеко-часов.

Подытоживая, можно сказать, что open source дает бренду возможность привлечь к созданию решения специалистов извне, собрать профессиональное комьюнити вокруг себя, что может упростить решение многих проблем.

Почему разработчики должны быть заинтересованы в open source-проекте не меньше менеджмента

По опыту могу сказать, что классный open source рождается только у команд, которые готовы работать упорно, долго и с большой самоотдачей. Понятно, что если потребовать open source-продукт с новичков, которые пока не научились качественно делать фичи, то ничего толкового не выйдет. Но неужели что-то может пойти не так у опытной команды, которая просто будет работать без огонька?

Да, но далеко не сразу. Специалисты могут дотянуть продукт до релиза, и это будет хороший продукт. Но жизнь проекта в опенсорсе с версии 1.0 только начинается. Впереди годы более-менее активной поддержки и дорожная карта обновлений. Если самим разработчикам продукт не интересен (а менеджмент, как мы помним, в нём заинтересован далеко не в первую очередь), его не будут поддерживать должным образом, и со временем он зачахнет и забудется.

Вот почему важно, чтобы инициатива создания open source-проекта исходила в том числе и от разработчиков. Разберемся, чем могут быть полезны такие проекты им самим.

Преимущества, которые опыт создания open source проектов даёт разработчикам

Когда я присмотрелся к сфере автотестов, они меня очень заинтересовали. Я увидел в них настоящий «голубой океан», то самое решение, на которое ещё нет особого спроса только потому, что никто не создал должного предложения. Мне очень захотелось окунуться в воды этого океана. Плюс open source в том, что в таком проекте каждый может попробовать раскрыть себя с новой стороны.

Если человек найдёт какую-то боль своей компании и грамотно предложит менеджменту найти решение для неё с помощью open source-разработки, он будет решать крутые необычные проблемы. Будет непросто, но очень интересно. Если непросто, значит, качаются навыки: уникальные в зависимости от проекта hard skills и универсальные soft skills. Я, например, пока занимался Kaspresso, сильно прокачал владение Kotlin. Ранее почти на нём не писал, так что в процессе многое узнал. Что касается мягких навыков, то при работе над open source-проектом учишься организовывать команду, общаться с людьми, с которыми до этого не работал, делать исследования, потому что в open source их действительно много.

Есть возможность попробовать себя в разных ролях. Я на проекте Kaspresso почувствовал себя в роли одновременно разработчика, продакта, проджекта, аналитика и техсаппорта. Это такой отрезвляющий опыт, сразу понимаешь, сколько задач стоит перед командой, кто чем занят, пока ты пишешь код, а также куда можно расти в будущем.

Признаем, что иногда, в том числе для роста, работу приходится менять. Так вот, очень скудно смотрится, когда просто пишешь в резюме:

— Четыре года занимался внутренней разработкой для <ABC_нужное подчеркнуть>

Даже если компания крутая. Занимался и занимался. По этой строчке совершенно непонятно, что именно ты там делал. Даже если расписать подробнее, работодателю будет очень сложно это проверить и увидеть твой уровень. Не зря же разработка внутренняя

Другое дело, когда пишешь:

— Разрабатывал фреймворк Android-автотестов Kaspresso: <ссылка на GitHub>.

Если проект, которым ты занимался, выложен в open source и у него две тысячи звёздочек от пользователей на GitHub, то любой работодатель поймёт — ты умеешь нащупывать волнующие людей проблемы и придумывать крутые решения этих проблем. Значит, к тебе нужно присмотреться.

К тому же, по проекту сразу ясно, насколько ты владеешь теми hard skills, которые в своём резюме заявляешь. Это всё работает на твой личный бренд.

***

Open source — это полезно и интересно, как для компаний, так и для разработчиков. Более того, если подходить к такой разработке с умом, она сыграет свою роль в узнаваемости бренда, поднимет престиж компании и принесёт немало преимуществ, пусть порой и не таких мгновенно осязаемых, как разработка внутренняя.

Надеюсь, мои рассуждения помогут тем, кто сейчас готовится или только начинает разрабатывать open source проект. Призываю разработчиков в комментариях делиться собственным опытом и рассказывать свои истории о свободной разработке.

Обсудить в форуме