Как научить разработчиков не бояться Open Source и правильно с ним работать?
Все, так или иначе, используют Open Source. Но что делать, если нам нужна новая фича или мы нашли критический баг? Можно, конечно, форкнуть репозиторий и быстро что-то поправить. Но форк нужно поддерживать, а новая версия может оказаться несовместимой с вашей. Например, GitHub потратил полтора года, чтобы обновить фреймворк Ruby on Rails с версии 3.2 до версии 5.2.
Можно отправить pull request. Так вы решите не только свою проблему, но и поможете сообществу. Но у мейнтейнера есть свой Open Source проект и контрибьюторы ему обычно только мешают. Поэтому ваш pull request могут не принять. И первый, и второй, и десятый.
Как же тогда работать с Open Source? Михаил Грачёв, тимлид из Evrone, расскажет, как в компании выстроили работу с Open Source и превратили это в культуру. Для тех, кто предпочитает смотреть видео — запись его выступления на TeamLead Conf 2021.
Выгоды работы с Open Source более чем очевидны. Это улучшает лояльность клиентов и повышает доверие к компании, которая не только использует фреймворк, но и активно участвует в его разработке. Это улучшает HR-бренд компании. Разработчики охотней идут туда, где развита Open Source-культура, так как там можно позаниматься не только основным проектом.
Чем больше у нас опыта работы с Open Source проектами, тем лучше мы умеем выбирать нужное решение, а потом и поддерживать его. Но что делать, если разработчики считают Open Source сложным и в результате допускают одни и те же ошибки раз за разом? Со временем, это даже может перерасти в страх и отрешенность от участия в нём.
С чего начать?
Конечно, есть документация, но как показала практика, даже прочитав доку, разработчики допускают одни и те же ошибки. Поэтому мы используем другой вариант — Contributor-Friendly Open Source проекты внутри компании. Звучит несложно, хотя и не всё так просто. Покажу на примере проекта, с которого мы начинали развитие культуры Open Source в Evrone.
Откуда брать идеи?
Конечно, от проекта должна быть польза компании. Для этого можно изучить что-то новое — язык, фреймворк или технологию. Или можно решить проблему на своем проекте, что-то автоматизировать, а потом это заопенсорсить. В Evrone первым таким проектом стал линтер для .env файлов, написанный на Rust.
Наш Dotenv-linter проверяет .env файлы на наличие разного рода проблем. Также он может автоматически исправлять найденные проблемы и сравнивать .env файлы между собой. Мы используем его во всех наших проектах.
Но одного создания проекта вам будет недостаточно. Вашим разработчикам он должен быть интересен, иначе они, разумеется, не захотят в нем участвовать.
Как заинтересовать разработчиков?
Dotenv-linter оказался интересен разработчикам за счет своей простоты. Вторым аргументом было то, что — настоящий проект, а не из песочницы. Иначе разработчики быстро бы потеряли интерес. Всё должно выглядеть (и являться) серьезным, даже документация и общение в проекте должны быть на английском. Здорово иметь и логотип проекта, хоть и необязательно. Это добавляет некую солидность — видно, что проект пишут не на коленке.
У нас был также Roadmap со списком задач и конкретной целью. Это, в том числе помогло увидеть разработчикам, что проект не бесконечный. Для каждой задачи из Roadmap был создан Issue на GitHub и очень подробно описано, какой результат нужно получить. При этом мы сразу начали использовать специальные метки на GitHub, help wanted и good first issue, чтобы разработчики учились находить себе задачи:
Конечно, этого оказалось недостаточно. После анонса разработчики встретили проект с восторгом и даже взяли задачи в работу. Но прошла неделя, две, а результата все еще не было. Выяснилось, что, начав разбираться с Rust, не все до конца смогли понять, как устроена экосистема языка. Поэтому мы написали документацию о том, как поднять проект, запустить тесты, линтеры и всё скомпилировать.
Правда, этого тоже было недостаточно. Так как у разработчиков опыта в реализации таких задач не было, им понадобился некий шаблон, как решать подобные задачи. Для этого мы реализовали некий каркас приложения, в который можно добавлять новые проверки, а также написали пошаговую документацию, как это сделать.
Только после этого началась работа над проектом. И чтобы она не остановилась, у проекта также должен быть Changelog. Пользователям он нужен, чтобы видеть, как проект развивается и какие изменения есть между версиями. А разработчики видят, что работа идет, кто из коллег участвует, и в результате тоже присоединяются. Поэтому очень важно в Changelog добавлять ссылку на pull request и на автора.
Кроме того, напишите хороший Readme, чтобы пользователя было легче пользоваться вашим Open Source-проектом. Readme часто отталкивает, если там непонятно, как установить и использовать ваш инструмент.
Итак, мы создали Open Source-проект и выпустили его первый релиз. Настало время рассказать о нем сообществу.
Пиар
Какие есть каналы продвижения? Можно начать с awesome-репозитория — они есть, наверно, под все языки программирования и фреймворки. Или добавить ваш проект в новостные рассылки. Для этого тоже есть замечательный репозиторий. Можно написать в соцсети — например, в Twitter — пост с анонсом и попросить популярные аккаунты ретвиттнуть его.
Выступайте на конференциях и митапах и рассказывайте о вашем инструменте, пишите статьи. Последние лучше писать на английском, размещая их на профильных площадках — например, reddit.com, medium.com, dev.to. Про русскоязычное сообщество тоже не забывайте, хотя здесь вы можете получить больше негатива. Мы разместили анонс dotenv-linter на двух площадках: на OpenNet и linux.org.ru. Получили кучу гневных комментариев, но в этом был и плюс: большинство просто начинают пользоваться вашим инструментом и ставят звездочки на GitHub.
На этом этапе, конечно, очень нужна помощь компании. Для пиара важны все виды оформления — сделать крутой дизайн, нарисовать логотип или создать сайт, написать статью на русском и английском, разместить ее на различных профильных площадках. Но компания может помочь и административными ресурсами. Работа с Open Source (создание проекта и его пиар) отнимает немыслимое количество сил и времени — и Evrone оплачивает время, потраченное на работу с OSS.
Итак, мы создали проект, научили нашу команду работать с Open Source и распиарили проект.
Что дальше?
Растет число пользователей и появляются новые контрибьюторы со стороны. Но будьте готовы к встрече с их отдельными категориями, которые приходя на проект, начинают творить какую-то дичь. Например, берут задачи, назначенные на других разработчиков или задачи, которые уже почти сделаны. Мы однажды создали 5 задачек и попросили у сообщества помощи. К нам пришли 5 таких «индусов» и начали делать одну и ту же задачу. В результате мы получили 5 одинаковых pull requests и 4 несделанные задачи. Так бывает.
С ростом популярности проекта растет и увлеченность вашей команды. Люди видят, что проект интересен не только им, их мотивация участвовать растет. Ваши разработчики при этом выступают уже в роли мейнтейнеров, помогая новым контрибьюторам. И они со стороны видят все ошибки, которые допускали ранее. Они начинают лучше понимать мейнтейнеров других Open Source-проектов, и наконец осознают, что Open Source — это не сложно. Просто надо правильно с ним работать.
Расскажу об основных ошибках работы с OSS-проектами и как их можно решить.
Проект не развивается
Представьте, что вы отправляете pull request, а в ответ тишина. Мейнтейнер просто забросил проект. Единственное решение проблемы — не допустить такой ситуации и перед использованием проекта проверить, жив ли он, открыв Issue. В первую очередь смотрим метрики: например, дату и содержание последних коммитов. И очень важно, чтобы это были не коммиты с обновлениями зависимостей. Также можно посмотреть, уменьшается ли количество открытых Issues и pull requests. И активны ли вообще основные мейнтейнеры.
Не соблюдаются guidelines
Вы отправляете pull request и получаете +100500 комментариев, что вы всё сделали не так. Неправильно назвали ветку или коммит, использовали не тот code style. В итоге имеем кучу потраченного времени с обеих сторон: вам придется все это переделать, а мейнтейнер долго писал вам эти комментарии.
Решение проблемы — соблюдаем guidelines. В каждом проекте есть файл contributing.md, в котором собраны все правила проекта. Проверьте существующие pull requests — возможно, кто-то до вас уже все сделал — тогда вы не создадите дубликат.
Часто разработчики сразу открывают pull request вместо того, чтобы сначала протестировать код, прогнать тесты или запустить линтеры. Мейнтейнер понимает, что pull request не полный и пишет об этом разработчику. Зачем эти лишние шаги? Также важно подробно оформить pull requests, написав, что и зачем вы там сделали. Из кода не всегда очевидно, что вы пытались этим донести.
Новая фича
Иногда вы придумываете новую фичу, но она нужна только вам. При этом она увеличивает кодовую базу и усложняет код. Если вы уйдете из проекта после того, как ваши изменения будут приняты, мейнтейнерам придётся поддерживать ваш код. Поэтому вы можете получить непонимание в ответ на свою идею.
Решение проблемы — проверьте Issues и pull requests, в том числе закрытые. Может быть, кто-то уже пытался реализовать подобное, и их завернули. Вы также можете открыть Issue и обсудить идею с мейнтейнером — возможно, вам удастся его убедить.
Большой pull request
Если вы отправите мейнтейнеру +100500 изменений в одном Pull Request, то его вряд ли кто-то захочет проверять. Потому, что ревью вашего запроса займет очень много времени. Никто не хочет за такое браться.
Решение — не делать так. Не надо в одном Pull Request делать рефакторинг, исправлять несколько багов и добавлять несколько фич. Одна проблема — один pull request. И конечно, опишите подробно, для чего вы вносите изменения в код.
Выводы
Этому проекту Evrone уже 1,5 года. Мы сделали более 250 коммитов, хоть это и не так много. У проекта более 1000 звезд на GitHub и почти 80 контрибьюторов, из них 15 — из компании.
Взращивать культуру Open Source — это, конечно, не бесплатно. У нас тратится просто уйма времени и денег. Но при этом запускается и много OSS-проектов. Чтобы разработчики продолжали участвовать в Open Source проектах, важно упрощать для них вход в проект и не прекращать пиар в целом.
Для упрощения участия нужен ответственный (или даже несколько), к которому можно прийти, когда у разработчика появилось желание поучаствовать в Open Source, но он не знает, с чего начать. Ответственные лица должны периодически напоминать о себе и двигать направление вперед.
Пиар не должен быть только анонсом. Пишите о любых важных изменениях — вышла новая версия, появились ключевые изменения в коде. Пишите не только снаружи, но и внутри компании. Мы каждый месяц выпускаем Open Source-дайджест, где рассказываем о том, как наши разработчики участвовали в каких-то проектах, что сделали, что исправили. Указываем, какие новые Open Source проекты появились в компании, возможно, по каким-то из них нужна помощь.
У нас еще есть отдельный чат в Slack, где мы обсуждаем только Open Source. Разработчики постоянно туда скидывают задачки, которые можно делать. Мы там общаемся, обсуждаем идеи — и там же анонсируем новые проекты.
Попробуйте. Мой Twitter. И всем удачных OOS-проектов!
Saint TeamLead Conf 2021 пройдёт этой осенью — 16 и 17 сентября в Санкт-Петербурге. Расписание уже на сайте.
30 июля будет очередное повышение цен на билеты. Чем ближе к конференции, тем они дороже. Текущая стоимость.
До встречи офлайн и онлайн на Saint TeamLead Conf 2021!
