Библиотека сайта rus-linux.net
Свой свободный программный проект. Часть 1
Оригинал: Running a free software project
Автор: John Calcote
Дата: 9 октября 2007
Перевод: Александр Тарасов aka oioki
Дата перевода: 16 октября 2007
При копировании материала обязательны указание автора, переводчика и ссылки на оригинал статьи и настоящую страницу как первоисточник перевода!
Участие в свободном программном проекте может подарить вам бесценный опыт, но для этого нужна предварительная подготовка. По моему личному опыту, поверхностного знания о существующих свободных программах недостаточно для начала своего собственного проекта. Вам может помочь базовая информация, приведенная в этой статье.
История
В 2001 году я работал на Novell в команде разработчиков eDirectory. Перед нами стояла задача создания системы оповещения о доступности сервисов для новой версии eDirectory, и мы выбрали в качестве основы OpenSLP - свободную реализацию стандарта протокола обнаружения сервисов от IETF. Мой начальник попросил меня написать патч для OpenSLP, который бы добавлял поддержку DHCP - эта функция планировалась в будущих версиях OpenSLP. При написании этого патча вместе с администратором проекта OpenSLP мы решили включить его в OpenSLP, а я стал разработчиком OpenSLP. Короче, довольно скоро я остался единственным человеком в проекте, потому что все остальные ушли.
В прошлом я загружал, компилировал и запускал множество свободных программ, и как многие другие, думал, что я стал "крутым". Я заблуждался; но учился. Благодаря моему новому ответственному положению (хорошо еще, что проект был не очень популярным) в течение следующих 5 лет я постепенно освоил все: создание пакетов, списки рассылки, форумы и управление сайтом. Эта статья является попыткой облегчить жизнь программистам - новичкам в мире свободных программ. Надеюсь, что в какой-то мере это получилось.
Чтобы быть во главе свободного программного проекта, вы должны быть на все руки мастер. Прежде, чем мы начнем, я хочу упомянуть одну замечательную электронную книгу, которая пересекается с этой статьей. Она называется "Producing Open Source Software", ее автор Карл Фогель.
Начало проекта
Начать проект на самом деле тривиальная задача. Хотя скоро вы обнаружите, что это маленький снежок, который вы запустили с высокого холма. Но давайте начнем с самого начала. Итак, вам нужно найти хостинг - сайт, который будет хранить веб-страницы и файлы вашего свободного проекта. Вот короткий список:
- http://www.sourceforge.net
- http://code.google.com
- http://dotsrc.org
- http://developer.berlios.de
- http://www.freepository.com
- http://gforge.org
- http://icculus.org
- http://savannah.gnu.org
- http://www.seul.org
- http://www.bountysource.com
В дополнение к этому сокращенному списку публичных серверов общего назначения также есть несколько сайтов, принадлежащих компаниям, таким как Novell, Microsoft, Sun, HP, IBM и т.д., которые также предоставляют хостинг для свободных проектов. Вообще говоря, эти сайты более нацелены на корпоративные цели компании и предназначены для хостинга проектов, которые развивают какую-либо технологию, относящуюся к компании. Тем не менее, большинство этих сервисов принимают проект любого типа (лишь бы он не шел вразрез с интересами компании).
Некоторые сервисы имеют конкретные цели и стремятся к их достижению при помощи особых правил и предписаний. Проект Eclipse (который спонсируется и управляется IBM), к примеру, принимает лишь проекты, которые расширяют или любым другим образом улучшают среду разработки Eclipse. По этим причинам, и так как Eclipse написан на Java, практически все, что находится на eclipse.org также написано на Java. Новые проекты также тщательно рассматриваются на предмет полезности для среды Eclipse, и каждый Eclipse-проект должен использовать свободную лицензию, разработанную специально для Eclipse.
Рисунок 1: Начинаем новый проект на SourceForge.net
Итак, сайт выбрали, теперь нужно ввести информацию о своем проекте, заполнив небольшую веб-форму. Обычно задают несколько вопросов о назначении вашего проекта и таких деталях как краткое название проекта (которое будет использоваться при именовании пакетов), полное название и краткое описание. Некоторые сервисы могут задать вопрос, как вы оцениваете значимость своего проекта для мира свободного ПО. Я начинал несколько проектов, и никогда мне не отказывали, так что я склонен считать, что регистрация - больше формальный процесс.
Также в анкете поинтересуются, какую свободную лицензию вы примените к своему проекту.
Выбор свободной лицензии
Чтобы правильно выбрать свободную лицензию, вы должны быть знакомы с основными свойствами каждого типа лицензий. Настоятельно рекомендую прочитать обзор основных свободных программных лицензий на OpenSource.org. Концепция свободного программного обеспечения была придумана Ричардом Столлманом, основателем Фонда свободных программ. Часто эти лицензии называют copyleft-лицензии ("авторское лево", каламбур от слова copyright, "авторское право"). Любая свободная программная лицензия нацелена на сохранение свободы использования программ. Такие лицензии запрещают людям или компаниям заимствовать программный код, чтобы сделать его проприетарным, но в то же время позволяет использовать его в своих личных целях.
Все значимые свободные лицензии имеют особенности, которые делают их более или менее подходящими для какой-либо цели. К примеру, GNU General Public License (GNU GPL) - свободная программная лицензия общего назначения. Она позволяет использовать любую GPL-программу свободно и бесплатно. Однако лицензия GPL содержит один часто неудобный пункт, согласно которому любая программа, содержащая в себе код GPL-программы, также должна распространяться по лицензии GPL, т.е. бесплатно, со свободными исходными кодами и прочее. Эта особенность лицензии GPL часто называют "вирусной", особенно те компании, которые хотели бы использовать GPL-код в своих проприетарных коммерческих программах. Они просто не могут использовать GPL-программы.
С другой стороны, лицензию MIT можно назвать хорошей лицензией для тех проектов, которые просто предполагаются быть свободными, без каких-либо ограничений по использованию кода в других проектах. Говоря по-простому, потребители кода должны включать лицензию в свое проприетарное соглашение, чтобы лицензия была видна, либо при установке программы, либо в окне "О программе", тем самым отдавая должное авторам оригинального кода.
Так если MIT такая хорошая лицензия, почему же все ее не используют? Ироническое замечание: лицензия MIT слишком свободна для проприетарных компаний, желающих опубликовывать части кода. Иногда проприетарные компании делают код доступным для "маленьких" людей, и в то же время вводят двойную лицензию для крупных потребителей, также желающих использовать код в своих проприетарных целях. Я сказал "ироническое", ибо не сомневаюсь в том, что Ричард Столлман допускает такой эффект и при использовании GPL. Его цели были идеалистическими - заставляя потребителей GPL-кода выпускать получившийся продукт также под лицензией GPL, он надеялся, что в итоге все программное обеспечение станет свободным.
Вот некоторые популярные свободные программные лицензии, упомянутые на OpenSource.org, в порядке увеличения ограничений: MIT, BSD, LGPL и GPL. С тех пор как Фонд свободных программ создал GPL, появилось большое множество других свободных лицензий. Читайте литературу и попробуйте понять истинные цели каждой. Выбирайте ту, которая лучше подходит целям проекта и целевой аудитории, потому что плохой выбор может быть губителен для проекта.
Выбор категории для проекта
После выбора хостинга и лицензии для своего проекта нужно сделать несколько административных решений. После запроса на создание нового проекта придется подождать 1-2 дня, пока человек не одобрит ее. Когда это случится, вы будете оповещены по электронной почте.
Следующий шаг - настроить сайт проекта. Будем рассматривать этот процесс на примере SourceForge.net - просто потому, что он мне знаком. Настройки сайта включают средство категоризации Trove, списки рассылки, чат-комнаты, RSS-ленты, форумы технической поддержки, системы отслеживания ошибок, документацию, репозиторий исходного кода, веб-сервисы и сервисы compile-farm.
Trove - механизм тегов, который объединяет ваш проект с похожими проектами. Люди, которым нужен проект какого-либо типа, могут производить поиск по категории и находить соответствующие проекты. Проекты группируются в категории по различным критериям, и важно выбрать нужные trove-категории для вашего проекта. Этот инструмент часто оставляют без внимания, хотя он может облегчить поиск вашего проекта каким-то людям.
Использование списков рассылки
Список рассылки - не более чем email-ящик, с которым связан список автораспределения. Когда вы отсылаете письмо в список рассылки, письмо отсылается сразу всем. Люди могут включать и исключать себя из списка по собственному желанию. Членами списка рассылки проекта являются, конечно же, и сами разработчики проекта. Некоторые просто наблюдают за ходом событий в списке, а значит и в проекте. Но это не лучший способ оценить активность проекта. Беглого взгляда на архивы списка рассылки обычно достаточно, чтобы понять, жив проект или нет. Списки рассылки управляются специальными программами, наиболее популярная среди своего класса - это GNU Mailman (рисунок 2).
Рисунок 2: Экран администрирования GNU Mailman
Рекомендуется настроить как минимум два списка рассылки вашего проекта - малообъемный список анонсов и более объемный список обсуждения. В списке анонсов, как правило, анонсируют новые версии вашего проекта или какие-нибудь новости о проекте. Обычно на список анонсов подписано большее количество пользователей, чем на список обсуждения, потому что большинству людей не нужно знать подробностей, им интересны лишь новые версии программ. Где происходит настоящая работа, так это в списке обсуждения, который можно назвать вашим виртуальным рабочим местом. Это то место, где разработчики могут обменяться идеями о новых функциях или о том, как исправить старые ошибки.
Иногда администраторы проектов разделяют списки рассылки для разработчиков и для вопросов пользователей. В проектах, которые более-менее популярны, пользовательский список рассылки как бы самоорганизуется. То есть разработчику проекта не придется отвечать на множество вопросов в пользовательском списке рассылки, так как ответы будут даны другими, более опытными пользователями. Зачастую в списке рассылки проекта есть два типа людей: те, которые любят программировать и те, кому нравится использовать программы и они преуспели в этом. Программисты нацелены на технические детали реализации, а опытные пользователи - эксперты в правильном использовании программ.
Обычно со свободными проектами ассоциируется три списка рассылки: для анонсов, для разработчиков и для пользователей. Список анонсов малообъемен, и позволяет лишь администраторам проекта и разработчикам писать в него. Списки разработчиков и пользователей более объемны. Обычные имена списков рассылки таковы:
- проект-announce@lists.sourceforge.net
- проект-devel@lists.sourceforge.net
- проект-user@lists.sourceforge.net
Немного об этикете в списках рассылки
При общении с другими людьми в списке рассылки должны соблюдаться некоторые правила: не спрашивайте о помощи, пока вы точно не будете уверены, что сами не можете решить свою проблему. Это правило распространяется как на пользователей, так и на разработчиков. Предполагается, что и те, и другие сообразительны (хотя не всегда на одном уровне или в одной области). Предполагается, что пользователи будут с пониманием читать всю предложенную документацию, прежде чем задать свой вопрос. Аналогично, разработчики должны изучить исходный код и прочитать текущую документацию для разработчиков, прежде чем задавать вопросы в списке для разработчиков.
Часто на те вопросы, ответ на которые можно найти при беглом взгляде на документацию, пользователями списка рассылки дается ответ RTFM. 'R' означает 'Read' (Прочитай), а 'M' - 'Manual' (руководство). Другие две буквы означают английское ругательство. Надо помнить, что большинство свободных проектов не приносят прибыли и зачастую живы лишь благодаря энтузиазму разработчиков. Таким образом, время разработчиков очень ценно, и не стоит напрягать их лишними вопросами, тем более теми, ответ на которые можно найти самостоятельно в документации.
С другой стороны, вы как разработчик и публичный человек должны быть вежливы. Злобные или вульгарные письма в список рассылки иногда называют "флейм". Флейм удручает, но его нужно игнорировать, чтобы не провоцировать его дальнейшее распространение. Проблема флейма состоит в том, что он отдаляет целевую аудиторию. По этим причинам флейм можно чаще встретить в списках рассылки популярных проектов.
Продолжение следует...