Многие на ранних порах знакомства с программированием выбирают «напишу своё», вместо участия уже в чьём-то проекте. В принципе, этот выбор весьма понятен, т.к. никакой критики, рамок и кодревью от олдов, ИМХО. Со временем, конечно, выбор меняется, но бывают и исключения. Об одном из них и пойдёт речь.

2016 — Hellow, World!

Моей идей была переработка старого игрового движка, чем я и решил заняться. Однако, мой форк был не единственным, поэтому нужно было как-то заинтересовать комьюнити. Примерно пол года реализации мелких, никому ненужных правок, пока не пришла интересная идея. Поддержка x64. И отсюда же первые проблемы: нужен человек, который в этом хоть что-то понимает. С этого момента и начались проблемы с командой.

Более опытный участник

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

Первые успехи — первые участники

Успехи идёт рядом с интересом, поэтому какое-то время будет поток людей, желающих поучаствовать в разработке. Моей первой ошибкой стал выбор приоритета количества, а не качества такой помощи. Что и привело к большому количеству багов, которые исправляли и исправляем с 2017 по сей день. Со временем, народ отсеется сам, в хорошем случае — останутся пару человек, которые будут иметь по прежнему хоть какой-то интерес к этому. Вторая ошибка была в попытках удержать оставшихся людей, а не развивать проект в выбранном направлении, что превратило его в песочницу. Разный кодстайл, постоянные споры в команде, отсутствие единой идеи и хоть какого-то руководства. Каждый участник тащил одеяло в свою сторону. Из ситуации получилось выйти, убрав всех, кто слишком сильно пытался настаивать на своём. Таким образом более спокойные участники стали более податливыми, что позволило более-менее стабилизировать ситуацию. Но, не всё так хорошо… Последствия происходящего убили практически весь интерес коммьюнити к проекту, что и возвращает нас к первому пункту нашей статьи. Нужно сделать что-то стоящее.

Форки, форки и ещё раз форки

Следующая проблема — это соседние форки. Проект был OpenSource, поэтому всё интересное утекало из него в соседние проекты, что привело к проблеме уникальности. Решением стала переработка базового API, для усложнения переноса правок. Конечно, любой, кто более-менее разбирается в языке и API движка, мог перенести нужный код, потратив n-ное количество времени, на изучение изменений. Но всё же часть форков не стала с этим мучатся.

Ушёл по английски

Одна из самых странных ситуаций, это когда человек в какой-то момент бросает всё и просто уходит, обрывая все контакты. Приходится либо отказываться от частично готовой фичи или же дорабатывать её самому/искать кого-то на доработку. При втором варианте чаще всего разработка начнётся заново, т.к. «на вкус и цвет фломастеры разные». За частую не стоит настаивать об обратном, т.к. большая вероятность появления костылей и моральному истощению как у Вас, так и у него.

Ревью

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

• Отсутствие единого стиля
• Ошибки, баги, исключения
• Отсутствие контроля контента

Причём, желательно, чтоб ревью проводилось несколькими людьми, думаю и так понятно почему…

Заключение

Итак, повторю вкратце всё сказанное выше: выбирайте качество фичи, а не их количество. Следите за тем, что попадает в master. Не пытайтесь удержать в команде тех, кто создаёт больше проблем, чем контента.