The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Практические советы по созданию правильного сообщества Open Source

10.01.2011 20:50

Дэйв Нири (Dave Neary), в прошлом входивший в совет директоров организации GNOME Foundation и возглавлявший его, поделился своим видением того, как нужно строить и взращивать сообщество разработчиков свободного и открытого программного обеспечения. В настоящее время многие компании пытаются построить вокруг своих проектов сообщество и часто терпят неудачу. Дэйв Нири попытался обобщить наиболее распространённые и самые смертельные ошибки, которые совершают компании в своих стараниях привлечь сообщество к разработке.

По мнению Нири, перед началом создания сообщества необходимо подумать о том, что компании нужно от сообщества. Является-ли Open Source средством для роста популярности её бренда и увеличения распространённости продукта компании? Компании нужно взрастить экосистему разработки, построенную на основе разработки продукта? Компании нужно включить существующие наработки в свой проект, настроив его под свои нужды, чтобы сократить издержки? Каждая из этих целей, а также любые другие причины открытой разработки ПО, требуют конкретной стратегии и инструментов, направленных на достижение успеха. Действительно, успех зависит от поставленных целей.

Самая распространённая и большая ошибка, которую совершают компании - это уход с головой в свободные и открытые проекты, и связанные с этим нереалистичные ожидания. Крис Грамс (Chris Grams) однажды описал привлечение сообщества к разработке как "модель Тома Сойера" - это когда компании ожидают, что кто-то другой сделает за них их работу. Важно не попасть в эту ловушку.

Две типичные модели создания сообщества - это когда компании находят себя в сотрудничестве с существующим проектом Open Source, или взращивают сообщество вокруг своего собственного открытого проекта.

Модель присоединения компании к сообществу.

При присоединении к существующему сообществу, укрепление доверия и репутации занимает много времени. Первый шаг к продуктивной работе с сообществом - это понимание структуры этого сообщества. Кто такие лидеры данного сообщества, каковы их приоритеты? В первую очередь на решение компании об участии в открытом проекте может повлиять несовпадение культуры открытого или свободного проекта, и коммерческих целей компании.

Как только компания принимает решение сотрудничать с сообществом и выбирает для этого подходящий проект, первое и самое важное решение состоит в том, кто будет работать над проектом. Это решение часто не получает должного внимания высшего руководства компании.

Часто сообщества документируют свои нормы поведения - многие проекты, включая ядро Linux и проект Gnome, имеют свои собственные правила поведения, кодексы, политики, отражённые в их списках рассылки и в других источниках. Для большинства сообществ они могут быть кратко сформулированы так: "Грести вместе со всеми, не раскачивая лодку".

Одно из искушений, которого необходимо избегать любой ценой - это чрезмерное использование рычагов воздействия на сообщество, которые получил один из участников проекта из числа сотрудников компании. Безусловно, компании нужно иметь своего "старшего парня", который бы был своего рода "наставником" для других, и помогал бы им в процессе работы над проектом, но нужно избежать ситуации, когда "наставник" становится "привратником", отгородив разработчиков компании от сообщества.

Модель взращивания сообщества.

Второй сценарий - взращивание сообщества. Если компания решила выпустить ПО под свободной лицензией, её первым решением будет вопрос о том, будет-ли проект позиционироваться исключительно как проект сообщества или нет, и до какой степени это будет проект сообщества?

Саймон Филипс (Simon Philips) писал о различных типах сообществ, которые могут вырасти вокруг СПО. Он описывал сообщества разработчиков программного кода, непрофильных разработчиков, разработчиков, работающих над дополнениями, интеграторов, распространяющих и настраивающих ПО, но не обязательно изменяющих его, и, наконец, пользователей ПО. Каждое из этих сообществ имеет разные потребности и требует различного подхода.

Если компания хочет взрастить сообщество вокруг своего проекта, есть несколько практических советов, которым необходимо следовать:

  • Управление: если компания установит правило, согласно которому она будет единолично решать, какой код будет добавлен в ядро продукта, то она потеряет многие преимущества открытых проектов.

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

  • Инструменты разработки и инфраструктура: компании необходимо убедиться, что она предоставляет пользователям удобные возможности распространения своих работ и общения друг с другом - будь то через специальные модули, или через систему управления версиями (GIT, Bazaar). Вклад в проект компании должен рассматриваться как важный социальный опыт каждого члена сообщества.

  • Процессы в сообществе: компания должна создать простую экосистему - никто не хочет быть гражданином второго сорта. Нужно документировать процессы получения доступа к ключевым ресурсам, таким как права модератора, принятие кода в основную ветку или доступ редактора к сайту проекта.

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

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

Некоторые типичные ситуации, которых стоит избегать:

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

  2. Отстранение от сообщества. Когда команда компании работает слишком много в частном порядке, созданное ей сообщество может не принять мотивы компании и её приоритеты. Работая через списки рассылки или иные формы публичного обмена информацией, компания позволяет людям вне компании быть наравне с ней по скорости работы и понимать суть проекта.

  3. Долгие дискуссии. Слишком долгое обсуждение незначительных решений. Когда в компании начинают чувствовать, что сообщество тянет её вниз, ей нужно знать, когда необходимо переходить от слов к делу.

  4. Чёрная дыра. Заманчиво нанять разработчиков, которые уже заработали себе хорошую репутацию и навыки в проектах, построенных компанией. Но нужно остерегаться приёма на работу разработчиков из числа активных членов сообщества. Это может ухудшить сообщество. В компании должны убедиться, что работа в сообществе является частью должностной инструкции.

  5. Необходимо остерегаться чрезмерного вклада одних разработчиков в ущерб возможностей других. Нужно внести ясность - что компания будет делать при разработке, а что не будет.



  1. Главная ссылка к новости (http://www.visionmobile.com/bl...)
  2. OpenNews: Устранение препятствий, мешающих успешному развитию программного проекта
  3. OpenNews: Интервью с Stormy Peters, исполнительным директором GNOME Foundation
  4. OpenNews: Открытое сообщество должно уделять больше внимания созданию собственного бренда
Автор новости: timurkin
Тип: Обобщение
Короткая ссылка: https://opennet.ru/29232-community
Ключевые слова: community, opensource, contribute
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (12) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, pavlinux (ok), 21:09, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Чёй-то я тут не понял

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

    Кто себя почувствует вторым сортом? Явно не сообщество, так как написано,
    что компания решит передать управление именно ему.

     
     
  • 2.2, Аноним (-), 21:24, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да честно говоря перевод кривоватый. Смысл некоторых предложений очень трудно уловить, в некоторых предложениях просто не возможно.
     
     
  • 3.17, crypt (??), 11:18, 13/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >"Плыть по течению, не раскачивая лодку".

    "Плыть по течению" у нас имеет негативный смысл. В оригинале скорее имеется ввиду "плыть, грести вместе со всеми", в команде то есть.

     
  • 2.4, тоже Аноним (ok), 22:00, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, кавычки обозначают не отрицание, а корявость и аллегоричность термина.
    То есть имеется в виду: члены сообщества, не желающие быть лемурами, БУДУТ РАДЫ, если управлять проектом станет сообщество.
     
     
  • 3.5, тоже Аноним (ok), 22:06, 10/01/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Впрочем, нет. Просто переводчик наврал.
    В оригинале: Компании должны контролировать продукт, который они выпускают. Но попытка так же жестко контролировать открытый проект будет негативно воспринята сообществом. Вот и все...
     

  • 1.8, stimpack (?), 06:55, 11/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тяжелое это дело. Социально, морально и технически нужно быть на высоте. И, конечно, времени не жалеть. А в итоге:
    1. +На небольшую долю процентов снижаем стоимость разработки (вклады со стороны чаще всего мелкие)
    2. +Реклама среди IT-спецов методом повышения узнаваемости бренда.
    3. +Получение дополнительных клиентов из числа сообщества.
    4. -Сокращение возможных каналов дохода из-за открытости проекта и соответствующей лицензии.
    5. -Трата времени и сил на создание общества, осознавая, что единый неверный шаг может испортить дело навсегда.
    6. Повышение отчуждаемости ПО, что для развития ПО несомненный плюс, однако для вашего кармана в некоторые моменты может стать откровенным минусом.
     
     
  • 2.9, Forth (??), 09:45, 11/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если продавать копии на компашках, то оно конечно не выгодно. А если сервис, то какахренразница?
     
     
  • 3.10, kid (??), 12:15, 11/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не хочу Вас огорчать, но профит от продажи поддержки сильно преувеличен:)
     
     
  • 4.12, Forth (??), 13:10, 11/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Чем докажете?
     
     
  • 5.13, kid (??), 14:58, 11/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем докажете?

    Наверное тем, что Ubuntu еще только предстоит стать безубыточным проектом:)

     
     
  • 6.14, torvn77 (?), 14:49, 12/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    К стати,как я понимаю,если бесплатным дожен быть только код,тогда почему никто не пытаеться продавать доступ к бинарным репозитариям ??Ну или там ввести платные привелегий по скорости?(К стати это и рынок саппорта подогреет).
    Уже 3 года использую сетевую установку mirror.yandex.ru,очень удобно,но для бесплатно слишком хорошо.
     
     
  • 7.16, stimpack (?), 08:02, 13/01/2011 [^] [^^] [^^^] [ответить]  
  • +/
    мне кажется, геммороя больше, чем копеек. И конкуренции еще больше. Все это так или иначе подрывает "лубофь" пользователей к тому или иному дистру. Большая часть пользователей линукса вплоть до недавнего времени являлась нищебродами. И уж драть копейку со своих же адептов тяжеловато. Много ли бабла получила та же мандрива своим платным поверпаком? Недавно ж разваливалась по новостям.

    Пусть лучше они использованием всего наибесплатнейшего дерут копейку за поддержку каких-нибудь монстроидальных решений с тех, у кого бабло действительно есть и кому требуется делегирование знаний в IT-отрасли. То есть классический вариант.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру