Проект "Свободные голосования"

согласен.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

Я понимаю, ни у кого нет опыта создания и ведения опенсорс-проекта.
Предлагаю уделить несколько минут на прочтение вот этого Как построить Open Source сообщество и вот этого Модели управления Open Source проектами (Часть 1) и вот этого Эрик С.Рэймонд. Собор и Базар.

Беру на себя смелость составить краткий обзор моделей управления опенсорцами за сегодня и завтра.

Было-бы неплохо.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Возможно выглядит, как сумбурный набор советов и высказываний, но именно этим он и является. За несколько часов тяжело создать цельный документ.
Итак.

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

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

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

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

Программное заявление должно быть конкретным, устанавливающим четкие границы, и, прежде всего, коротким. Вот пример одного хорошего, от http://www.openoffice.org/:
"Для создания, в сообществе, лидирующего международного программного пакета для офиса, который будет работать на всех распространенных платформах и предоставлять доступ ко всем функциям и данным при помощи API, основанном на открытых компонентах и формате файлов, основанном на XML."

Главная страница сайта проекта должна однозначно ясно указывать на то, что это проект с открытым исходным кодом.

Должен быть краткий список функций, которые поддерживает программное обеспечение (если что-то еще не закончено, вы можете включить это в список, но поместить "запланировано" или "в разработке" рядом с ними), и тип вычислительной среды, требующейся для работы программного обеспечения. Подумайте о списке функций/требований как о чем-то, что вы предоставили кому-нибудь, попросившему краткое описание программного обеспечения. Это, часто, всего лишь логическое развитие программного заявления. Например, программное заявление могло бы сказать:
"Создать полнотекстовый индексатор и поисковый механизм с богатым API, для использования программистами, предоставляющими службы поиска по большим коллекциям текстовых файлов."

Список функциональных возможностей и требований давал бы подробные объяснения, проясняя область применения, описанную в программном заявлении:

" Функциональные возможности:
Поиск в простом тексте, HTML и XML
Поиск слова и предложения
(запланировано) Нечеткое совпадение
(запланировано) Инкрементное обновление индексов
(запланировано) Индексирование удаленных веб-сайтов
Требования:
Python 2.2 или выше
Достаточное дисковое пространство для хранения индексов (примерно в два раза больше изначального объема данных)"

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

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

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

Программное обеспечение должен быть доступно для загрузки настолько удобным, стандартным, и нетрудоемким насколько это возможно.

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

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

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

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

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

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

Документация должна быть доступна в двух местах: в интернете (напрямую с сайта), и в загружаемом пакете программного обеспечения.

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

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



Продолжение следует...

Существует огромное множество лицензий на свободное программное обеспечение на ваш выбор.

Если вы не хотите, чтобы ваш код был использован в проприетарных программах, используйте Открытую лицензию GNU. (http://www.gnu.org/licenses/gpl.html). Открытая лицензия (GPL), возможно, является самой признанной в мире свободной лицензией на программы.

Как только вы выбрали лицензию, вы должны заявить об этом на главной странице сайта проекта. Здень не нужно приводить полный текст лицензии; дайте только название лицензии и привяжите к нему ссылку на полный текст лицензии на другой странице.

Это укажет людям на то, под каким типом лицензии вы намерены выпустить программное обеспечение, но этого не достаточно для соблюдения законных прав. Для этого, сама программа должна содержать лицензию. Обычным способом это сделать является помещение полного текста лицензии в файл с названием COPYING (или LICENSE), и наличие маленькой метки в начале каждого файла исходного кода, указывающей на дату, владельца прав и лицензию, и информирующего, где найти полный текст лицензии.

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

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

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

Основная задача заключается в установлении правил хорошего тона в качестве "внутригруппового" поведения. Это поможет проекту, так как разработчики могут уйти из проекта (даже из проектов, которые им нравятся и которые они хотят поддержать) из-за язвительных писем. Вы можете даже не узнать о том, что они ушли; кто-то может просто следить за рассылкой, видеть что для участия в проекте нужно быть достаточно толстокожим, и принять решение вообще не связываться с этим проектом. Поддерживать доброжелательность на форуме—это стратегия для длительного выживания и ее легко придерживаться, пока проект все еще достаточно мал. Как только это станет частью проектной культуры, вам больне не нужно будет оставаться единственным человеком, поддерживающим ее. Она будет соблюдаться всеми.

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

Начинайте рецензирование с самого первого изменения. С помощью просмотра изменений проще всего поймать такие типы ошибок как уязвимости системы безопасности, утечка памяти, недостатоность комментариев или документации API, ошибки завышения или занижения на единицу (off-by-one), несовпадение порядка вызывающего/вызываемого и другие ошибки, которые требуют минимум окружающего контекста для их выявления.


Продолжение следует...

В большинстве своем проекты с открытыми исходниками предлагают, как минимум, стандартный набор средств информационного обеспечения:

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

Списки рассылки. Обычно самый активный круг общения проекта, так же выполняет роль протокола ("medium of record").

Система контроля версий. Дает разработчикам простой способ управления изменениями в исходных кодах, включая откат изменений и "change porting". Позволяет каждому отслеживать что творится с кодом.

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

Обмен сообщениями (чат). Средство для проведения оперативных дискуссий для диалогов в режиме вопрос-ответ. Не всегда имеет смысл архивировать эти диалоги.

Вики.

RSS выгрузки.


Продолжение следует...

Далее самое сложное...

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

Существует несколько путей достижения успеха. 1) Один подразумевает ведение формальных управляющих процедур, с помощью которых разрешаются споры, принимаются (и иногда исключаются) разработчики, планируются новые функции проекта, и так далее. 2) Другой полагается на менее формализованную структуру сознательного самоограничения, и создает тем самым атмосферу честности, которая и становится де факто формой управления. Оба подхода приводят к тому, что у участников возникает чувство организационной стабильности, подкрепляемое понятными всем привычками и процедурами.

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

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

Хотя мы обычно и употребляем термин "великодушный диктатор" (или ВД), лучше думать об этой роли как о "арбитре одобренном сообществом" или "судье". В общем, великодушные диктаторы, не принимают всех решений, и даже большей их части. Крайне маловероятно, что один человек обладает настолько широкими знаниями, чтобы постоянно принимать правильные решения во всех областях проекта. Даже если это будет так, хорошие разработчики не останутся в проекте, если не получат достаточно влияния на вектор развития проекта. Поэтому великодушные диктаторы обычно не диктаторствуют много. Вместо этого они позволяют случатся событиям и вырабатываться решениям в дискуссиях и посредством эксперимента. Они и сами участвуют в дискуссиях, как обычные разработчики, доверяя людям которые разбираются в предметной области. Они топают ногой и говорят "Будет так!" только если дискуссия зашла в тупик и большая часть группы хочет, чтобы кто-нибудь принял решение, дабы не тормозить разработку. Нежелание править с помощью указов присуще практически всем успешным великодушным диктаторам. Это одна из причин, по которой они все еще занимают эту роль.

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

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

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

В любом случае нет причин различать обсуждение до и после внесения изменений. Любое изменение можно отменить, по крайней мере до того как от него появятся зависимости (скажем, новый код который перестанет работать если убрать изменение). Система контроля версий смягчает последствия быстрых или поспешных решений. Это, в свою очередь, дает людям возможность оценивать необходимость обсуждения до внесения изменений самостоятельно.

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

Таким образом, если человек знает, что нужно сделать, он должен сделать это. Это относится не только к изменению кода ПО, но и к обновлению сайта, внесению изменений в документацию, и другим вещам, которые не должны вызывать бурного обсуждения. Как правило, будет не очень много случаев, в которых понадобится отменять изменения. C ними можно справляться по мере возникновения. Конечно, не стоит поощрять своеволие. Есть психологическая разница между решением принятым после обсуждения и решением, которое уже вступило в силу, даже если его можно отменить. Люди чувствуют что движущая сила связана с действием, и будут меньше сопротивляться уже принятому решению, чем принятию решения, которое только обсуждается. Если разработчик пользуется этим и вносит потенциально спорные изменения слишком быстро, другие участники могут и должны возразить ему, а также должны заставить его следовать более строгим стандартам пока он не научится.

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

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

Нет необходимости в тайном или анонимном голосовании, если обсуждение было публичным. Очевидно.

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

Опытные руководители проектов стремятся как можно реже прибегать к голосованию.

Возможность голосовать ставит трудную задачу - кто будет иметь право голосовать?

Некоторые проекты допускают такой вид управления, как вето.

Очень хорошо процесс голосования и вето описан в http://www.apache.org/foundation/voting.html (в процессе перевода - прим. Сперанского).


Продолжение следует... (финансирование, нумерация релизов, управление добровольцами)... Вероятно, только завтра... Тяжело читается, материал взят из нескольких источников, некоторые абзацы переведены роботом и подправлены вручную... но смысл понятен...

Интересные мысли. думаю что мы в этом направлении и движемся. хорошая мысль что воспользовавшийся правом вето, должен обязательно обосновать свою позицию.

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17

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

С открытым кодом однозначно нужно будет распространять софт агента, который будет облегчать пользователям работу с сервисом. А вот на счет кода самого сервиса у меня есть сомнения.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

_________________
89DC B598 306B 26C8 B9AA 5C0C CFB6 7184 B2B2 FF17