Я всегда старался выносить в опенсорс все, что может быть полезно людям вне моей компании. Помимо стремления не только брать от сообщества, но и отдавать, это приносит ряд бенефитов для самой организации.

Всю статью я построил на примерах опыта Taiga UI — огромной библиотеки компонентов под Angular, которая долго развивалась внутри компании, а 10 месяцев назад была выложена в опенсорс. Несмотря на то, что примеры взяты из опыта фронтовой библиотеки, все пункты применимы и актуальны для любого другого стека.

Причина 1: растет ИТ-бренд

Хороший опенсорс положительно влияет на ИТ-бренд компании. Компанию чаще упоминают, ее решения обсуждают и рекомендуют. Люди начинают пользоваться технологией и с большей вероятностью захотят прийти работать в вашу компанию. Лучше всего это работает, когда весь код проекта хорошо написан и аккуратно структурирован. Пару раз слышал мнение: «О, если ребята пишут подобный код, то, похоже, круто работать с такими профессионалами» — и сам его разделяю.

В качестве небольшого эксперимента в последние несколько месяцев я попросил включить в первичную беседу с кандидатами на Angular вопрос о том, сталкивались ли они с опенсорсами нашей компании. В выборку попало более ста кандидатов, и около четверти из них слышали или использовали Taiga UI. Это радует.

Было и несколько случаев, когда кандидат изначально шел с желанием попасть в команду Taiga UI, но в процессе собеседований находил себе иную команду.

Также подобные проекты повышают публичность и узнаваемость отдельных разработчиков. Как один из создателей Taiga UI, я спросил на конференции MoscowJS 50, есть ли в зале те, кто пришел на доклад исключительно потому, что знает, что я сделал эту библиотеку. Было десятка полтора поднятых рук.

Причина 2: тестирование лучше, идей больше

Это скриншот из Taiga UI с поиском issue по слову BUG. За 10 месяцев опенсорса пользователи из комьюнити зарепортили и поправили несколько сотен как мелких, так и довольно серьезных багов. Это значит, что в библиотеке были какие-то проблемы, которые могли всплыть у реальных пользователей наших интерфейсов. Но уже никогда не всплывут, потому что их обнаружили внешние пользователи библиотеки, зарепортили, а мы вовремя их пофиксили. Чем больше пользователей, тем меньше вероятность пропустить какой-то косяк к себе на реальный продакшен.

Кроме того, люди не только репортят баги, но и приходят с отличными идеями. У разработчиков другой компании может быть иной взгляд на то, как решать ту или иную проблему. Еще более непривычный взгляд будет у людей из других стран и культур. В первые месяцы нам принесли несколько хороших идей, часть из которых сильно поменяли Тайгу, а другая часть будет включена в следующий мажорный релиз.

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

Причина 3: получаете дополнительные руки

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

За 10 месяцев в Taiga UI пришло больше 50 внешних контрибьюторов. Порой люди приходят сами: могут поправить пару строчек в документации, а могут и принести солидную глобальную фичу. За счет сообщества библиотека уже переведена на 10+ языков.

Мы стараемся мотивировать такие активности: вешаем бейджики вроде Good first issue или Contributions welcome, участвуем в Hacktoberfest. Если человек пришел с хорошей идеей, поддерживаем и спрашиваем, не желает ли он реализовать ее самостоятельно. В ответ предлагаем детальное ревью, советы и поддержку процесса.

Причина 4: решения становятся универсальными 

Когда вы работаете над опенсорс-проектом, то отвязываетесь от бизнес-контекста. Это может показаться минусом, ведь так вы фокусируетесь не на конкретных проблемах компании, которая платит вам деньги. 

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

Такой подход можно использовать и при обычной разработке внутри компании, но не всегда в команде есть человек, который готов поставить гибкость инструмента превыше удобства текущего конкретного заказчика и грамотно обосновать это. С опенсорсом такой ситуации не возникает.

Причина 5: бесплатная инфраструктура и тулинг

Еще один плюс опенсорса — вы пользуетесь практически всем бесплатно. Компании не нужно платить за машины для CI/CD, хостинг или какой-то продвинутый тулинг. Многие платные сервисы или инструменты для простоты и ускорения разработки позволяют пользоваться ими абсолютно бесплатно, если вы делаете это в рамках опенсорс-проектов.

Наша Taiga UI полностью построена на подобных бесплатных технологиях: CI/CD от Github, хостинг на Github Pages, фича окружения на Firebase, все выполнения команд и сборки кэшируются облачным NX Cloud и прочие инструменты, которые решают массу проблем и стоят приличных денег для корпоративных клиентов.

Вместо заключения

Конечно, плюсы опенсорса на этом не заканчиваются. Developer Experience репозитория стал гораздо лучше, к нам стали чаще контрибьютить и разработчики внутри компании. А время диагностики багов сократилось в десятки раз за счет возможности быстро воспроизвести их в независимом окружении в онлайн-IDE вроде Stackblitz, что также упростило и создание примеров. Но это все уже более мелкие детали работы.

Для меня эти пять пунктов наиболее важные и приятные, и я рад, что наша библиотека обросла подобным сообществом. Думаю, этот пример хорошо отражает суть опенсорса.