От переводчика: данный перевод продолжает цикл публикаций по управлению Open Source проектами, начатый здесь.
Модель управления описывает роли, которые могут занимать участники проекта, а также процесс принятия решений внутри проекта. Кроме того, она описывает основы правил участия в проекте и процесс общения и обмена информацией между членами команды проекта и сообществом. Другими словами, именно модель управления предохраняет проект от скатывания в хаос. Этот документ объясняет, почему необходима модель управления, даёт некоторые рекомендации по решению проблем, возникающих при принятии проектом модели управления и описывает ключевые области, которые должны быть в модели. Также здесь вы найдёте описание процесса включения вашей модели управления в управляющую документацию.
Различных стратегий управления Open Source существует примерно столько же, сколько и самих Open Source проектов. Однако донесение до потенциальных пользователей и разработчиков своих политик и стратегий — критичный для проекта момент. Чёткая модель управления также позволяет потенциальным добровольцам понять, как им стоит взаимодействовать с проектом, чего от них ожидают и какова гарантия того, что их вклад будет всегда им доступен. В дополнение к этому, модель описывает процесс контроля качества, который поможет пользователям увериться в жизнеспособности проекта. Разработка и внедрение с чёткой и лаконичной модели управления — один из важнейших шагов, которые проект может предпринять на пути к устойчивому развитию через открытую разработку.
Модели управления разнятся от централизованного контроля со стороны одного человека или организации (великодушная диктатура) до распределённого контроля, возлагаемого в соответствии со вкладом (меритократия).
В любой точке этого спектра вы можете обнаружить модель управления; также возможно движение выбранной проектом модели управления вдоль этого спектра по мере его (проекта) созревания. Далее приведены некоторые примеры типичных моделей и типов проектов, в которых можно обнаружить эти модели. Таблица взята из работы, представленной в статье «Open Source Software: Is It Worth Converting?» Термины «Собор» и «Базар» объясняются в статье «Собор и Базар» на Wikipedia.
Таблица 1 Типичные модели управления
Давайте рассмотрим некоторые примеры моделей управления. Во-первых, модель управления Ubuntu. Эта модель фокусируется на описании структуры сообщества и сфер ответственности, связанных с каждым элементом этой структуры. Она также кратко характеризует процессы принятия решений внутри проекта. Проект Ubuntu выбрал отделение информации разработчиков от структурной информации, содержащейся в управляющем документе, однако процесс технического управления также чётко задокументирован.
Apache Software Foundation имеет два набора управляющих документов для каждого проекта. Первый касается управления фонда, который устанавливает иерархию организации в целом. Фонд также предоставляет набор документов по ключевым процессам внутри своих проектов, например о принятии решений. Однако, поскольку каждый проект свободен, в определённой степени, определять собственные вериации этих процессов, многие проекты имеют собственные управляющие документы. В качестве примера, изучите описание управления проектом Apache Forrest.
Нашим третьим и последним примером модели управления на практике будет модель проекта Taverna(прим. пер.: Документ PDF). Это пример open source проекта, который вырос внутри научного сообщества и, следовательно, демонстрирует модель, способную, как оказалось, работать в научной среде. Модель проекта Taverna, подобно моделям Ubuntu и ASF, фокусируется на иерархи проекта и процессах управления.
Несмотря на важность определения модели управления в самом начале, многим проектам не удаётся этого сделать. И для этого есть несколько причин. Среди типичных встречаются такие:
Хотя каждое из первых трёх опасений потенциально верно, эти страхи легко рассеиваются путём выбора подходящей модели управления. Однако последнее опасение, ставящее во внимание возраст проекта, не верно никогда. Это из-за того, что каждый потенциальный доброволец на проекте должен знать как эффективно и с пользой внести свой вклад и как распорядятся его вкладом. Без чёткого руководства по этим вопросам, большая часть людей пройдёт мимо вместо того, чтобы присоединиться к незрелому проекту. Но если этим ранним пользователям показать, что они могут помочь привести проект к его зрелости — они могут решить остаться. Один доброволец извне может иметь большое влияние на успех развития проекта, так что инициаторы проекта могут не учитывать риск потери этого добровольца в результате попытки сэкономить чуть-чуть сил на ранней стадии.
Полезно развеять каждое из вышеназванных опасений. И чем раньше это произойдёт — тем лучше для жизни проекта, так как иначе они могут стать препятствиями на пути к принятию чёткой модели управления. Давайте рассмотрим их чуть более детально.
Некоторые люди подозревают, что модель управления — это всего лишь волокита. Но описание модели управления вовсе не обязательно лишь ненужное бюрократическое упражнение: всё зависит от того как качественно прорисована модель. Основная цель — сделать модель простой но эффективной. В ней не должно быть правила на каждую ситуацию; напротив, не стоит даже пытаться это сделать. Вместо этого, модель должна предоставлять простой путь чёткого и ясного сопровождения процесса управления проектом. Эта ясность позволит третьим лицам смело подключаться к проекту. Они смогут увидеть как работает проект и предсказать как он отреагирует на их вклад до того, как потратят существенные усилия на свою деятельность.
Важно заметить, что модель управления должна делать процесс создания и проверки вклада в проект третьих лиц проще, а не сложнее. Она должна устранять неточности, которые могут привести к потере времени всех заинтерисованных лиц.
Боязнь того, что модель управления приведёт проект к потере адаптивности к изменяющейся среде может быть отнесён к факту, что в мире есть много плохо управляемых Open Source проектов, которые безусловно ограниченны в своей гибкости. Однако настоящая проблема вызвана недостатком прозрачной модели управления в большей степени, чем её наличием. Хорошая модель управления на самом деле увеличит гибкость проекта, поскольку она определяет как могут новые участники поддержать проект совершенно неожиданным образом, без оказания влияния на основные цели. Она предоставляет механизм, позволяющий сообществу в целом определять направление, в котором проект должен развиваться, при этом гарантируя основной команде проекта сохранение контроля. Проблема контроля обсуждается в следующем разделе, а здесь мы сфокусируемся на видении и направлении.
Поскольку проект на может быть всем и для всех, цель устройчивого проекта должна быть представлена как полноценное решение, видимое основными идеологами, не перестающее быть интересным для других потенциальных идеологов. Проект должен быть также готов принять вклад из неожиданных источников, и должен быть готов, по возможности, ответить потребностям добровольцев в своём видении будущего и направлении развития. Такая модель поведения значительно увеличивает пространство ресурсов, которые проект может задействовать в своём стремлении к устойчивому развитию. Однако попытки сделаться всеобъемлющим почти всего приводят проект к краху, поскольку усилия распределяются слишком тонким слоем по всему спектру проблем.
Основное решение состоит в том, чтобы реализовать у себя модель управления, которая предоставила бы механизмы для чёткого объявления и установления границ приемлемости внутри проекта. Модель должна быть спроектирована так, чтобы позволять лидерам проекта избегать ненужных и бесполезных диверсий потенциально опасными участниками сообщества. Также модель должна давать уверенность, что проекты с прописанной стратегией могут принять в себя работу путём конструктивного взаимодействия. Такой тип взаимодействия расширяет рамки проекта, не увеличивая при этом требования к первоначальной команде проекта.
Возможно самым сильным страхом из всех является страх, что модель управления откроет третьим лицам путь захвата управления проектом. В конце концов, модель управления благославляет участие третьих лиц в проекте путём выдичи этим лицам власти над проектом. Однако, как и во всех других упоминаемых здесь случаях, хорошо спроектированная модель управления даёт уверенность, что контроль останется там, где этого захочет лидер проекта. Это может означать, что все принимаемые решения контролируются центральной организацией (например, MySQL или SuragCRM), или что все решения принимаются сообществом всецело (например, Apache HTTPD Server или DoJo).
Принимая решение о требуемом уровне контроля над проектом, учитывайте, наколько устойчивы будут усилия, предпринимаемые вашей командой. Если, например, проект производит высокоприбыльный продукт, для которого планируется коммерческая эксплуатация, довольно выгодно обслуживать управление и поощрять взаимодействие. Совершенно верно, что выбор централизованной модели даёт гарантию, что развитие продукта будет направлено по выбранной модели использования. Однако он ограничивает ширину и глубину, на которой добровольные участники проекта могут обнаружить свой интерес, посольку их стратегические цели могут отличаться от ваших.
С другой стороны, если проект производит некий компонент, который сам по себе имеет низкую коммерческую ценность, основная задача — удостовериться, что компонент используется так широко, как это вообще возможно. В этих обстоятельствах целью может быть расширение возможных участников путём позволения заинтересованным и активным партёрам участвовать в стратегическом планировании.
Одна из сильных сторон лицензионной модели Open Source в том, что каждый может взять исходный код и начать независимую разработку. Это называется «форк». Это означает, что контроль, осуществляемый лидерами проекта, силён настолько, насколько сильна поддержка этих лидеров сообществом проекта.
Несмотря на содержание управляющего документа, для принципиально несогласных с контролем существует возможность начать новый проект. Предотвращение подобных инцидентов не входит в роль модели управления. Напротив, модель должна чётко определять влияние потенциального участника проекта, которое, возможно, распространяется за рамки направлений развития проекта. Только с помощью аккуратного управления сообществом лидеры Open Source проектов остаются у власти. Чёткое определение правил поведения сообщества в этом случае — важнейшая часть процесса управления.
Наконец, мы возвращаемся к проблеме того, что проект слишком молод, чтобы привлечь пользователей со стороны и добровольцев, и, следовательно, не нуждается в управлении ими внутри себя. Очень часто встречаются проекты, которые чувствуют, что модель управления им пока не нужна, но это, по нашему мнению, никогда не может быть причиной.
Никогда не бывает слишком рано выбрать подходящую модель управления. Без неё шансы, что третьи лица захотят принять участие в проекте, значительно уменьшаются. И для этого есть ряд причин:
Поскольку вы никогда не знаете, в какие моменты участник может влиться в проект, важно быть готовым к этому с самых первых шагов. Каждая упущенная возможность привлечь добровольца наносит урон устойчивому развитию проекта. Помните также, что именно первый контакт проекта с участником является самым важным. Например, исправление ошибки, предложенное третьей стороной, может привести к улучшению опыта использования, что в свою очередь влияет на приток пользователей. Это, в свою очередь, делает проект более привлекательным для пользователей и добровольцев.
Другое часто встречающееся заблуждение состоит в том, что у проекта нет достаточного количества пользователей или добровольцев, чтобы их беречь. Повторимся, мы настаиваем на том, что даже один доброволец, улучшающий качество и удобство использования продукта — это уже доброволец. Усилия, затраченные на создание адекватной модели управления обычно меньше, чем усилия, положенные на все самые маленькие вклады в проект.
Последнее заблуждение, которое часто встречается, состоит в том, что проект лишком мал, чтобы справиться с влиянием пользователей со стороны и участников. Это иллюстрирует недостаток понимания того, как работают открытые разработки: во первых, даже самые большие проекты никогда не привлекают никого, кроме активных разработчиков. Во вторых, хорошо управляемое сообщество будет во много самодостаточным. В частности это верно для децентрализованных сообществ.
Прим. пер.: статья большая, поэтому разбита на две части. Продолжение следует...
Модель управления описывает роли, которые могут занимать участники проекта, а также процесс принятия решений внутри проекта. Кроме того, она описывает основы правил участия в проекте и процесс общения и обмена информацией между членами команды проекта и сообществом. Другими словами, именно модель управления предохраняет проект от скатывания в хаос. Этот документ объясняет, почему необходима модель управления, даёт некоторые рекомендации по решению проблем, возникающих при принятии проектом модели управления и описывает ключевые области, которые должны быть в модели. Также здесь вы найдёте описание процесса включения вашей модели управления в управляющую документацию.
Зачем проекту вообще модель управления?
Различных стратегий управления Open Source существует примерно столько же, сколько и самих Open Source проектов. Однако донесение до потенциальных пользователей и разработчиков своих политик и стратегий — критичный для проекта момент. Чёткая модель управления также позволяет потенциальным добровольцам понять, как им стоит взаимодействовать с проектом, чего от них ожидают и какова гарантия того, что их вклад будет всегда им доступен. В дополнение к этому, модель описывает процесс контроля качества, который поможет пользователям увериться в жизнеспособности проекта. Разработка и внедрение с чёткой и лаконичной модели управления — один из важнейших шагов, которые проект может предпринять на пути к устойчивому развитию через открытую разработку.
Модели управления разнятся от централизованного контроля со стороны одного человека или организации (великодушная диктатура) до распределённого контроля, возлагаемого в соответствии со вкладом (меритократия).
В любой точке этого спектра вы можете обнаружить модель управления; также возможно движение выбранной проектом модели управления вдоль этого спектра по мере его (проекта) созревания. Далее приведены некоторые примеры типичных моделей и типов проектов, в которых можно обнаружить эти модели. Таблица взята из работы, представленной в статье «Open Source Software: Is It Worth Converting?» Термины «Собор» и «Базар» объясняются в статье «Собор и Базар» на Wikipedia.
Таблица 1 Типичные модели управления
| Тип проекта | Цель | Стиль контроля | Структура сообщества | Примеры |
|---|---|---|---|---|
| Ориентированный на исследования | Обмен инновациями и знаниями | Соборный метод, центральное управление | Лидер проекта, множество читателей | Perl, Ядро Linux |
| Ориентированный на использование | Удовлетворение индивидуальных потребностей | Базарный метод, децентрализованное управление | Много периферийных разработчиков, взаимная поддержка между пассивными пользователями | GNU/Linux (исключая ядро) |
| Сервис-ориентированный | Предоставлять стабильный сервис | Совещательное централизованное управление | Ведущие участники вместо лидера проекта, множество пользователей, разрабатывающих системы для конечных пользователей | Apache, PostgreSQL |
Модели управления в действии
Давайте рассмотрим некоторые примеры моделей управления. Во-первых, модель управления Ubuntu. Эта модель фокусируется на описании структуры сообщества и сфер ответственности, связанных с каждым элементом этой структуры. Она также кратко характеризует процессы принятия решений внутри проекта. Проект Ubuntu выбрал отделение информации разработчиков от структурной информации, содержащейся в управляющем документе, однако процесс технического управления также чётко задокументирован.
Apache Software Foundation имеет два набора управляющих документов для каждого проекта. Первый касается управления фонда, который устанавливает иерархию организации в целом. Фонд также предоставляет набор документов по ключевым процессам внутри своих проектов, например о принятии решений. Однако, поскольку каждый проект свободен, в определённой степени, определять собственные вериации этих процессов, многие проекты имеют собственные управляющие документы. В качестве примера, изучите описание управления проектом Apache Forrest.
Нашим третьим и последним примером модели управления на практике будет модель проекта Taverna(прим. пер.: Документ PDF). Это пример open source проекта, который вырос внутри научного сообщества и, следовательно, демонстрирует модель, способную, как оказалось, работать в научной среде. Модель проекта Taverna, подобно моделям Ubuntu и ASF, фокусируется на иерархи проекта и процессах управления.
Преграды для применения модели управления
Несмотря на важность определения модели управления в самом начале, многим проектам не удаётся этого сделать. И для этого есть несколько причин. Среди типичных встречаются такие:
- Боязнь превратить процесс в волокиту
- Опасения, что проект потеряет «чувство направления»
- Ощущение потери контроля над стратегией проекта в будущем
- Проект считается слишком молодым или слишком маленьким для того, чтобы привлечь активных пользователей или разработчиков
Хотя каждое из первых трёх опасений потенциально верно, эти страхи легко рассеиваются путём выбора подходящей модели управления. Однако последнее опасение, ставящее во внимание возраст проекта, не верно никогда. Это из-за того, что каждый потенциальный доброволец на проекте должен знать как эффективно и с пользой внести свой вклад и как распорядятся его вкладом. Без чёткого руководства по этим вопросам, большая часть людей пройдёт мимо вместо того, чтобы присоединиться к незрелому проекту. Но если этим ранним пользователям показать, что они могут помочь привести проект к его зрелости — они могут решить остаться. Один доброволец извне может иметь большое влияние на успех развития проекта, так что инициаторы проекта могут не учитывать риск потери этого добровольца в результате попытки сэкономить чуть-чуть сил на ранней стадии.
Полезно развеять каждое из вышеназванных опасений. И чем раньше это произойдёт — тем лучше для жизни проекта, так как иначе они могут стать препятствиями на пути к принятию чёткой модели управления. Давайте рассмотрим их чуть более детально.
Волокита
Некоторые люди подозревают, что модель управления — это всего лишь волокита. Но описание модели управления вовсе не обязательно лишь ненужное бюрократическое упражнение: всё зависит от того как качественно прорисована модель. Основная цель — сделать модель простой но эффективной. В ней не должно быть правила на каждую ситуацию; напротив, не стоит даже пытаться это сделать. Вместо этого, модель должна предоставлять простой путь чёткого и ясного сопровождения процесса управления проектом. Эта ясность позволит третьим лицам смело подключаться к проекту. Они смогут увидеть как работает проект и предсказать как он отреагирует на их вклад до того, как потратят существенные усилия на свою деятельность.
Важно заметить, что модель управления должна делать процесс создания и проверки вклада в проект третьих лиц проще, а не сложнее. Она должна устранять неточности, которые могут привести к потере времени всех заинтерисованных лиц.
Потеря направления
Боязнь того, что модель управления приведёт проект к потере адаптивности к изменяющейся среде может быть отнесён к факту, что в мире есть много плохо управляемых Open Source проектов, которые безусловно ограниченны в своей гибкости. Однако настоящая проблема вызвана недостатком прозрачной модели управления в большей степени, чем её наличием. Хорошая модель управления на самом деле увеличит гибкость проекта, поскольку она определяет как могут новые участники поддержать проект совершенно неожиданным образом, без оказания влияния на основные цели. Она предоставляет механизм, позволяющий сообществу в целом определять направление, в котором проект должен развиваться, при этом гарантируя основной команде проекта сохранение контроля. Проблема контроля обсуждается в следующем разделе, а здесь мы сфокусируемся на видении и направлении.
Поскольку проект на может быть всем и для всех, цель устройчивого проекта должна быть представлена как полноценное решение, видимое основными идеологами, не перестающее быть интересным для других потенциальных идеологов. Проект должен быть также готов принять вклад из неожиданных источников, и должен быть готов, по возможности, ответить потребностям добровольцев в своём видении будущего и направлении развития. Такая модель поведения значительно увеличивает пространство ресурсов, которые проект может задействовать в своём стремлении к устойчивому развитию. Однако попытки сделаться всеобъемлющим почти всего приводят проект к краху, поскольку усилия распределяются слишком тонким слоем по всему спектру проблем.
Основное решение состоит в том, чтобы реализовать у себя модель управления, которая предоставила бы механизмы для чёткого объявления и установления границ приемлемости внутри проекта. Модель должна быть спроектирована так, чтобы позволять лидерам проекта избегать ненужных и бесполезных диверсий потенциально опасными участниками сообщества. Также модель должна давать уверенность, что проекты с прописанной стратегией могут принять в себя работу путём конструктивного взаимодействия. Такой тип взаимодействия расширяет рамки проекта, не увеличивая при этом требования к первоначальной команде проекта.
Потеря управления
Возможно самым сильным страхом из всех является страх, что модель управления откроет третьим лицам путь захвата управления проектом. В конце концов, модель управления благославляет участие третьих лиц в проекте путём выдичи этим лицам власти над проектом. Однако, как и во всех других упоминаемых здесь случаях, хорошо спроектированная модель управления даёт уверенность, что контроль останется там, где этого захочет лидер проекта. Это может означать, что все принимаемые решения контролируются центральной организацией (например, MySQL или SuragCRM), или что все решения принимаются сообществом всецело (например, Apache HTTPD Server или DoJo).
Принимая решение о требуемом уровне контроля над проектом, учитывайте, наколько устойчивы будут усилия, предпринимаемые вашей командой. Если, например, проект производит высокоприбыльный продукт, для которого планируется коммерческая эксплуатация, довольно выгодно обслуживать управление и поощрять взаимодействие. Совершенно верно, что выбор централизованной модели даёт гарантию, что развитие продукта будет направлено по выбранной модели использования. Однако он ограничивает ширину и глубину, на которой добровольные участники проекта могут обнаружить свой интерес, посольку их стратегические цели могут отличаться от ваших.
С другой стороны, если проект производит некий компонент, который сам по себе имеет низкую коммерческую ценность, основная задача — удостовериться, что компонент используется так широко, как это вообще возможно. В этих обстоятельствах целью может быть расширение возможных участников путём позволения заинтересованным и активным партёрам участвовать в стратегическом планировании.
Когда сообщество разделяется (форк)
Одна из сильных сторон лицензионной модели Open Source в том, что каждый может взять исходный код и начать независимую разработку. Это называется «форк». Это означает, что контроль, осуществляемый лидерами проекта, силён настолько, насколько сильна поддержка этих лидеров сообществом проекта.
Несмотря на содержание управляющего документа, для принципиально несогласных с контролем существует возможность начать новый проект. Предотвращение подобных инцидентов не входит в роль модели управления. Напротив, модель должна чётко определять влияние потенциального участника проекта, которое, возможно, распространяется за рамки направлений развития проекта. Только с помощью аккуратного управления сообществом лидеры Open Source проектов остаются у власти. Чёткое определение правил поведения сообщества в этом случае — важнейшая часть процесса управления.
Проект ещё молодой или маленький
Наконец, мы возвращаемся к проблеме того, что проект слишком молод, чтобы привлечь пользователей со стороны и добровольцев, и, следовательно, не нуждается в управлении ими внутри себя. Очень часто встречаются проекты, которые чувствуют, что модель управления им пока не нужна, но это, по нашему мнению, никогда не может быть причиной.
Никогда не бывает слишком рано выбрать подходящую модель управления. Без неё шансы, что третьи лица захотят принять участие в проекте, значительно уменьшаются. И для этого есть ряд причин:
- потенциальные участники не знают, как им принять участие
- они не уверены, что понимают, что произойдёт с их вкладом в проект
- проект не выглядит достаточно серьёзным в том, что касается взаимодействия с третьими лицами
- нет очевидной гарантии того, что вкладом в проект распорядятся правильно, сохранив упоминание об участнике, сделавшим его
Поскольку вы никогда не знаете, в какие моменты участник может влиться в проект, важно быть готовым к этому с самых первых шагов. Каждая упущенная возможность привлечь добровольца наносит урон устойчивому развитию проекта. Помните также, что именно первый контакт проекта с участником является самым важным. Например, исправление ошибки, предложенное третьей стороной, может привести к улучшению опыта использования, что в свою очередь влияет на приток пользователей. Это, в свою очередь, делает проект более привлекательным для пользователей и добровольцев.
Другое часто встречающееся заблуждение состоит в том, что у проекта нет достаточного количества пользователей или добровольцев, чтобы их беречь. Повторимся, мы настаиваем на том, что даже один доброволец, улучшающий качество и удобство использования продукта — это уже доброволец. Усилия, затраченные на создание адекватной модели управления обычно меньше, чем усилия, положенные на все самые маленькие вклады в проект.
Последнее заблуждение, которое часто встречается, состоит в том, что проект лишком мал, чтобы справиться с влиянием пользователей со стороны и участников. Это иллюстрирует недостаток понимания того, как работают открытые разработки: во первых, даже самые большие проекты никогда не привлекают никого, кроме активных разработчиков. Во вторых, хорошо управляемое сообщество будет во много самодостаточным. В частности это верно для децентрализованных сообществ.
Прим. пер.: статья большая, поэтому разбита на две части. Продолжение следует...
