Не пишите отчеты. Пишите код.

Когда начинаешь делать серьезный проект, доступ к исходному коду движка, это не роскошь, а необходимость. Именно поэтому в свое время мой выбор пал на Amazon Lumberyard. Мне было критически важно иметь возможность заглянуть (под капот), чтобы понять, почему механика работает или не работает.

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

Потом случился большой переход: Lumberyard переродился в O3DE (Open 3D Engine) и стал полностью Open Source под эгидой Linux Foundation. Казалось бы, свобода! Но по инерции я продолжал вести себя как обычный пользователь софта. Я находил ошибку, либо нуждался в дополнительном функционале, далее создавал подробный (Issue) или описывал что бы мне помогло в разработке, но сам код в репозиторий не отправлял.

Переломный момент наступил после созвона с руководством O3DE. Наш проект их очень заинтересовал. Нам сказали прямым текстом: Ребята, то, что вы делаете, это круто. Ваш проект для нас теперь один из самых приоритетных, мы будем помогать. Мы выдохнули. Казалось, теперь-то заживем, для нас зеленый коридор обеспечен.

Реальность оказалась сложнее. Да, наш проект был в приоритете. Но у Core-команды O3DE гигантский объем задач: архитектурные изменения, поддержка платформ, планы релизов и многое другое. Даже с пометкой (High Priority) наши критические баги исправлялись медленнее, чем требовалось нашему продакшену. Нам нужно было вчера, а фиксы приходили завтра.

В какой-то момент в разговоре с разработчиками движка они сказали. А почему ты сам не зальешь фикс? Ты же знаешь, в чем проблема.

Честно говоря, меня это пугало. Стать контрибьютором огромного движка мирового уровня? Казалось, что там невероятно сложные процессы ревью, драконовские требования к коду и вообще кто они и кто я.

Но деваться было некуда, у нас горели сроки. Я изучил гайдлайны, подготовил свой первый Pull Request с исправлением и нажал кнопку отправки. К моему удивлению, это оказалось совсем не страшно.

Процесс прозрачен: Есть автоматические тесты и понятные требования.

Комьюнити помогает: Всегда и во всем, вместе получается лучше.

Результат: Скорость от недель и месяцев, до пары дней максимум. Оказалось (на тот момент это было не очевидным для меня), что для перегруженной команды разработчиков O3DE гораздо проще и быстрее провести Code Review готового решения от меня, чем погружаться в проблему с нуля, воспроизводить её и писать код самим.

Мы на тестах игры никак не могли настроить видимость (Out of View) Actor-а. Причем проблема была как со статичным AABB так и базирующейся на анимации костей. Актор постоянно фликерил (то появлялся то изчезал). В итоге разобравшись с проблемой я отправил Pull Request с доработкой и в течении пары дней, эти изменения уже были в основной ветке разработчиков. Данный пример https://github.com/o3de/o3de/pull/19149

Сейчас я понимаю простую истину: у разработчиков Open Source проектов всегда работы больше, чем рук. Ждать, пока до тебя дойдет очередь, это путь в никуда.

Став контрибьютором, я убил двух зайцев:

1) Ускорил разработку нашей игры и я больше не блокируюсь багами движка или недостатком функционала, я их внедряю и иду дальше.

2) Помогаю экосистеме. Мои фиксы помогают другим разработчикам, а я чувствую себя полноценным участником развития O3DE, а не просто пассажиром.

Если вы используете Open Source инструмент и знаете, как его улучшить то, не пишите отчеты. Пишите код.