колхоз vs. фермерство
Метод коллективной работы "добровольный колхоз" в открытых проектах не работает: невозможно собрать желающих, а потом на основании принадлежности к колхозу выдавать задачи - желающие не наберутся. Первично желание что-то сделать, а не принадлежность к группе. Поэтому командная работа возможна только в том случае, когда принадлежность к группе - не привилегия, а признание заслуг. Вышесказанное не относится к тем случаям, когда группа de facto формируется для обеспечения безопасности: выдача commit access, изменения репозитория и подобных push-привилегий.
Метод коллективной работы "добровольный колхоз" в открытых проектах не работает: невозможно собрать желающих, а потом на основании принадлежности к колхозу выдавать задачи - желающие не наберутся.
Первично желание что-то сделать, а не принадлежность к группе. Поэтому командная работа возможна только в том случае, когда принадлежность к группе - не привилегия, а признание заслуг.
Вышесказанное не относится к тем случаям, когда группа de facto формируется для обеспечения безопасности: выдача commit access, изменения репозитория и подобных push-привилегий.
Ваше наблюдение точно описывает ключевой принцип успешных open-source проектов, который часто называют моделью "Ядро и сообщество" или "Путь меррита" (Meritocracy Path). Рассмотрим, как она работает: Небольшая группа основных разработчиков, которые уже доказали свою компетентность и получили право на доверие (commit access, право на merge PR). Они формируются не "сверху" по желанию, а "снизу" — вырастают из самых активных и квалифицированных участников сообщества. Внешний круг — все желающие. Их мотивация — решить конкретную проблему ("первично желание что-то сделать"). Они участвуют через Issues, Pull Requests, обсуждения. Примеры: Так работают Linux Kernel, Python, React. Никто не "записывается" в разработчики ядра Linux. Люди начинают с патчей, затем становятся мейнтейнерами подсистем, и лишь немногие со временем входят в круг доверенных лиц Линуса Торвальдса. Создание формальной группы ("колхоза") до появления реальных задач и результатов создаёт несколько фатальных ловушек: Привилегия быть в группе становится самоцелью. Появляются участники, которые хотят статуса, но не хотят нести пропорциональную нагрузку. Это демотивирует реальных делателей. Группа тратит энергию на внутренние процессы (выборы, обсуждение правил, распределение ролей), а не на продукт. Создается иллюзия деятельности, но реальный выход отсутствует. Если группа создана искусственно, критика и здоровые конфликты воспринимаются как предательство, а не как инструмент улучшения. Это убивает инновации и качество. В "колхозе" энергия уходит на поддержание самой группы. В меритократической команде энергия фокусируется на проекте, а группа вокруг него формируется естественно и прочно. Вместо того чтобы создавать "колхоз", используйте следующий алгоритм для формирования работоспособного ядра: Если к вашему проекту не идут люди на этих условиях, проблема не в "добровольцах", а в самом проекте (он не решает чью-то боль, слишком сложен для старта или плохо представлен). Это сигнал к итерации над идеей, а не к смене метода организации. Таким образом, парадигма успешного open-source проекта смещается с устаревшей модели "Принадлежность → Деятельность" к эффективной модели "Вклад → Признание → Доверие". "Колхоз" ищет членов. Живой проект ищет решения проблем. Люди, мотивированные решать проблемы, в конечном итоге формируют настоящую, сплоченную команду, основанную на взаимном уважении и доказанной компетенции. Именно такая команда, а не формальное членство в списке, становится главным активом и движущей силой любого значимого открытого проекта.
Альтернатива "колхозу": Модель "Ядро и сообщество"
1. Ядро (Core Team)
2. Сообщество (Community)
Как происходит переход из сообщества в ядро?
Почему модель "колхоза" терпит крах: мотивационные ловушки
1. Ловушка "Бесплатного сыра" (Free Rider Problem)
2. Ловушка "Вымышленной легитимности"
3. Ловушка "Принудительной лояльности"
Итог:
Практические шаги: как строить команду на правильных принципах
Что НЕ делать
Что делать ВМЕСТО этого
Объявлять набор в команду проекта
Сфокусироваться на четкой цели и сделать первый прототип (даже если он кривой).
Распределять роли и задачи среди "записавшихся"
Публично вести работу (GitHub, форум) и фиксировать список проблем (Issues). Пусть задачи висят открытыми для всех.
Давать доступ "посторонним" в доверенную зону (репозиторий)
Строго охранять "зону безопасности" (main branch, продакшен). Доступ давать только после нескольких успешно принятых Pull Request'ов.
Ждать, пока группа "сплотится"
Привлекать людей через конкретные микро-задачи ("исправь опечатку в документации", "попробуй воспроизвести этот баг").
Требовать лояльности к группе
Признавать заслуги публично: упоминать контрибьюторов в релизах, добавлять в AUTHORS файл, предлагать роль мейнтейнера для части кода.
Ключевой индикатор:
Вывод: От Принадлежности к Вкладу
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
- 2900 просмотров
