Привет, Хабр! Каждый год штук тридцать российских IT‑компаний открывают исходники какого‑нибудь своего внутреннего инструмента на GitHub с идеей «сейчас соберём вокруг него комьюнити и получим бесплатный DevRel‑канал». Через полтора года из этой тридцатки выживают три‑четыре проекта, у которых реально есть внешние контрибьюторы и звёзды продолжают капать. Остальные превращаются в архивные репозитории с 40 звёздами, парой висящих issue и последним коммитом восьмимесячной давности.

Дело не в удаче и не в качестве кода. Дело в конкретных ошибках, которые повторяются с завидной регулярностью и убивают проект ещё до того, как о нём успевает узнать целевая аудитория. Разберём пять самых частых — из тех, что реально топят opensource‑инициативы российских компаний.

Открыть код, но не выделить людей на поддержку

Первая и самая массовая. Компания решает открыть внутренний инструмент — CLI, библиотеку, SDK, — назначает ответственного, тот пилит LICENSE и README, коммитит начальный код, компания публикует пресс‑релиз. Дальше проект живёт «постольку‑поскольку»: разработчик, который его открыл, занят основным продуктом, времени на issue от внешних пользователей у него нет, PR‑ы висят месяцами.

Через полгода первые контрибьюторы, которые пришли с надеждой поучаствовать, видят: их issue от февраля так и не разобрали в августе, их PR никто не смотрел. Они молча уходят. Информация быстро разлетается по чатам: «эти ребята опенсорс не поддерживают, туда контрибьютить бесполезно».

Восстановить репутацию после такого сложновато. Проще завести новый проект, чем возрождать мёртвый.

На входе нужно хотя бы 20% времени одного инженера, официально выделенных на opensource‑поддержку. Дополнительно нужен DevRel‑специалист, который общается в комьюнити, пишет release notes, ведёт discussions.

Если 20% времени инженера выделить нельзя — не открывайте код.

Открыть только огрызок продукта, оставив всё интересное внутри

Компания хочет поиграть в opensource, но не готова открывать реально полезные вещи. Открывают маленькую утилиту, которая когда‑то использовалась внутри и уже не поддерживается. Или SDK‑обёртку над публичным API, который и без обёртки хорошо документирован. Или демку с примерами использования продукта.

Такие проекты никому не нужны. Они не решают реальных задач разработчика — потому что реальных задач в них и нет. Пара человек звёздочку поставят из вежливости, кто‑то заметит на конференции — и всё.

Хороший opensource‑проект, как канал DevRel, — это то, что вы сами используете внутри компании как критичный инструмент. То, без чего у вас production бы падал. Открытие такого проекта показывает: компания реально доверяет комьюнити, готова делиться болью и решениями.

Примеры удачных случаев в русскоязычном IT последних двух лет.

YDB от Яндекса — открыли реально работающую распределённую БД, которую они сами используют для критичной нагрузки. Werf от Флант — их собственный CI/CD инструмент, на котором крутится продакшн клиентов. Postgres.ai — открыты собственные инструменты работы с БД, которые команда использует ежедневно.

Формула простая: то, что вы реально любите и без чего не можете работать, — потенциальный opensource‑канал.

Выбрать лицензию по принципу «чтобы никто у нас не украл»

Юридический отдел, который впервые сталкивается с opensource, естественным образом хочет максимально защитить компанию. Ставит лицензию с ограничением на коммерческое использование, или BSL с delay‑периодом, или требует CLA с широкими правами передачи, или пытается ограничить fork.

Это отпугивает большую часть сообщества. Разработчики, особенно из компаний, работают с open‑source‑лицензиями через юридические процессы: любое ограничение требует согласования с legal‑командой. Если лицензия «сложная» — большинство компаний просто пройдёт мимо, не будут разбираться.

BSL (Business Source License) — модный сейчас вариант, который в теории позволяет иметь и open‑source‑community, и защиту от прямых конкурентов. На практике превращается в ловушку. Elastic, HashiCorp, Redis Labs переходили на BSL — и каждый раз это заканчивалось форком (OpenSearch, OpenTofu, Valkey) и потерей значительной части комьюнити. Если проект нужен как канал DevRel — BSL не подходит, слишком много вопросов.

Что реально работает

1. Apache 2.0 — самый нейтральный вариант, устраивает почти всех. MIT — для маленьких библиотек, простой и понятный. Оба лицензии дают комьюнити ясный сигнал: код открыт, используйте свободно, коммерческое использование не запрещено.

2. CLA (Contributor License Agreement) — тоже спорная тема. Крупные проекты типа Kubernetes и Apache требуют CLA, и это норма. Но маленький проект с требованием подписать CLA перед первым PR отпугнёт 80% потенциальных контрибьюторов. Лучше начинать без CLA, добавлять его только когда проект вырос до размера, где это оправдано.

Затюнить README и getting‑started так, что первый запуск занимает больше пяти минут

Когда потенциальный контрибьютор находит ваш проект, у него ровно один шанс произвести впечатление. Он открывает README, пытается запустить, и если за пять‑десять минут ничего не получилось — уходит. Может быть навсегда.

Первый опыт может испортить README на пятьсот строк с историей проекта, философией разработки, benchmarks и roadmap, но без чёткой команды «сделай это, чтобы запустить». Getting‑started, где нужно установить пять зависимостей, поднять postgres и Redis, настроить переменные окружения. Docker‑compose, который падает на первом же запуске, потому что автор давно не проверял. Примеры в документации, которые не работают, потому что синтаксис изменился три версии назад.

Идеальный getting‑started — три команды, максимум четыре. Клонировать репозиторий, запустить make install, запустить пример. Если ваш проект не влезает в этот шаблон — что‑то не так с онбордингом.

Проверка простая. Возьмите свежий Ubuntu‑контейнер, добавьте только те зависимости, которые есть у вашей целевой аудитории (Node, Python, Go), и попробуйте с нуля запустить свой проект по инструкции из README. Засеките время. Если больше десяти минут — переписывайте getting‑started.

Второй уровень качества — «хочу посмотреть, как это работает, без установки». Живой playground на демо‑сайте, где можно потыкать проект прямо в браузере. Не для каждого проекта возможно, но там, где возможно, это сильно бустит конверсию из «услышал» в «попробовал».

Игнорировать первых внешних контрибьюторов

Пятая ошибка убивает проект уже после того, как первые четыре успешно пройдены. Проект набрал внимание, появились первые внешние pull request, первые issue от людей, которые не работают в компании. И тут проект задыхается — потому что команда компании относится к внешним contribution как к второстепенной задаче.

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

Что важно на этой стадии. Отвечать на issue не в пределах недели, а в пределах пары дней. Ревьюить PR не через месяц, а через два‑три дня максимум. Даже если ревью «нет, это не то, что нам нужно, спасибо» — отвечать нужно быстро, чтобы контрибьютор не сидел неделями в неведении.

Специальные лейблы good first issue и help wanted — не декорация. Их нужно наполнять реальными задачами, разбитыми до размера, который человек с нуля может закрыть за несколько часов. И когда кто‑то берёт такую задачу — сопровождать его: отвечать на вопросы в PR, помогать доводить до merge, а не бросать на полпути.

Публичное признание контрибьюторов работает как усилитель мотивации. Файл CONTRIBUTORS.md, упоминание в release notes («thanks to @username for this fix»), персональное «спасибо» в discussion. Мелочь, но люди её замечают и возвращаются.

Один пример, который в русскоязычном сообществе часто приводят как эталон: как Postgres Professional работает с внешними контрибьюторами в pg_probackup и других своих проектах. Ответы за сутки, тщательный ревью с объяснениями, регулярные release‑заметки с благодарностями. Результат — устойчивое комьюнити вокруг проектов, которые изначально были чисто внутренними.

Что делать, если у вас уже есть заброшенный opensource

Если вы читаете это и понимаете, что описанное совпадает с тем, что было в вашей компании год назад, — есть три варианта. Каждый имеет право на жизнь, каждый требует честного разговора с собой.

• Первый — тихо архивировать проект. GitHub‑репозиторию проставляется статус archived, в README добавляется прощальное сообщение с рекомендациями альтернатив. Это честнее, чем оставлять «полу‑живой» проект, который вводит людей в заблуждение.

• Второй — возродить с полной командой. Найти внутри компании людей, которые готовы официально взять проект как основную задачу, не как хобби. Опубликовать план возрождения (roadmap на квартал), разобрать накопленные issue, попросить сообщество вернуться. Это работает, но нужна серьёзная воля со стороны руководства: вложить время сильных инженеров в проект, который «мы вроде уже забросили».

• Третий, промежуточный — передать проект комьюнити. Найти внешних мейнтейнеров, дать им права, отойти в сторону как компания. Так получилось у OpenTofu после ухода Terraform в BSL. Компания теряет прямой контроль, но проект живёт. Это не для всех типов opensource‑проектов, но иногда единственный способ спасти технологию, в которую вложились время и деньги.

Худший вариант — оставить всё как есть и делать вид, что opensource‑канал работает. Это худший маркетинг: непрозрачный, разъедающий доверие, работающий против компании изнутри.

Куда смотреть дальше

Opensource как канал DevRel требует такого же серьёзного отношения, как продуктовая разработка, — со своими метриками, roadmap и командой. Если компания не готова инвестировать в проект хотя бы одного инженера на 20% времени плюс DevRel‑специалиста на постоянной основе — открывать код не стоит. Лучше пусть внутри останется, чем через год превратится в мёртвый репозиторий с надписью «ещё один заброшенный проект».

Обратная сторона: когда всё сделано правильно — хорошо поддерживаемый opensource‑проект приносит больше DevRel‑эффекта, чем десять митапов и двадцать статей вместе взятые. Это единственный DevRel‑канал, который работает 24/7 без прямого участия компании: люди находят проект в поиске, звёзды капают ночью, контрибьютор с другого конца страны вносит фикс в воскресенье. Такой ROI в других каналах DevRel не встречается.

А у кого из вас в компании есть opensource‑проект как часть DevRel‑стратегии? Интересно услышать тех, кто прошёл через реанимацию заброшенного проекта: получилось вернуть комьюнити или пришлось стартовать с нуля?

Open source редко умирает из‑за одного плохого коммита. Чаще — из‑за того, что инициативу не смогли нормально защитить внутри компании или не выстроили работу с сообществом. Про это можно будет поговорить на бесплатных открытых уроках OTUS:

• 7 июля в 20:00 — «Операция “Воркшоп”: как получить поддержку руководства для новой инициативы». Записаться
  _{Разберём, как упаковать идею так, чтобы она выглядела не как «давайте попробуем», а как понятный для бизнеса проект с ценностью, рисками и планом действий.}

• 22 июля в 20:00 — «DevRel в эру ИИ: зачем разработчики будут слушать вас в 2026 году». Записаться
  _{Поговорим о том, как меняется работа с разработчиками и техническими сообществами, когда одних митапов, статей и репозиториев уже недостаточно, чтобы удерживать внимание.}

Больше открытых уроков июля смотрите в дайджесте.