Январь 2009

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

Собор и базар

В настоящем документе мы представляем серию уроков о том, как эффективно запустить небольшой открытым исходным кодом сообщества. Эти уроки основаны на моем собственном опыте как лидера VoiceCode, проект, который направлен на разработку комплексного программирования по голосовой toolbox. Он предоставляет инструменты, которые позволяют программистам с повторяющимся деформации травмы (RSI) для записи компьютерного кода, поговорив с их машину, вместо того чтобы печатать.

Проект VoiceCode начался в 1999 году Национальный исследовательский совет Канады и впервые был официально выпущен в 2003 году. Система теперь находится в точке, где он может использоваться программистами для выполнения реальной работы, и там было более 9100 загрузок до сих. Проект также привлекла внимание средств массовой информации.

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

Неуловимое «правдоподобных обещание»

Когда я начал проект VoiceCode, я наивно ожидал, что я мог бы уйти с развивающейся небольшой основной частью системы. Просто достаточно, чтобы заставить людей возбужденных и способствовать появлению сообщества специальных вкладчиков, которые бы расширить его во что-то можно использовать. Ведь этот подход работал на Линуса Торвальдса, и это что Эрик Реймонд выступает под термином «правдоподобных обещание» (на странице 47 собор и базар):

Однако производство правдоподобными обещание оказалось более сложным, чем мы ожидали. На сегодняшний день, полный шесть лет после того, как проект VoiceCode был начат, только два других людей внесли свой код к нему: Дэвид Фокс (тогда Астрономия студент Гарварда, который в настоящее время работает в Nuance) и Стюарт Нортон (тогда студент в UC Санта-Крус который теперь работает в Borland). Наша самая большая ошибка была, что мы стараемся, чтобы заставить людей возбужденных по поводу VoiceCode's потенциал сосредоточив внимание сначала на его крутой особенность: способность переводить псевдо-код высказывания, как «для каждого индекса до десяти следующих» в собственный программный код. Мы продемонстрировали эту возможность на раннем этапе, но не способом, который мог бы использоваться для реальных. Вы должны были имитировать говорить путем ввода текста в окне консоли DOS, и результат появился в окне консоли, а не внутри фактического редактора. Хотя это получило нас много престижность от сообщества программистов, голос, это было очевидно не воспринимается как правдоподобный обещание, потому что никто на самом деле внесли код проекта.

По моему опыту люди только начинают верить обещание, когда они могут использовать систему для что-то реальное, даже если это мало. Тем не менее если вы кооптировать людей в инвестировать бесчисленное количество часов в развитии системы, это лучше быть прохладно тоже. Хороший баланс, как представляется, чтобы «Думать большой и прохладный, но начать малого и полезное». Другими словами запишите ясно, большой и прохладный видения, но начнем с реализации очень небольшой кусок до конца его, что люди могут использовать сразу. С VoiceCode мы сделали «Думать большой и круто», но нам не удалось начать «Малые и полезные».

Это все о людях и сотрудничестве, не программное обеспечение

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

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

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

Однако мы нашли контакт электронной почты, чтобы быть несколько ограничения. Поэтому в марте 2000 года, Эрик Йоханссон и организовал однодневный семинар лицом к лицу в Бостоне (парник для распознавания речи), где 21 человек заинтересован в программировании, голос встретились для обсуждения и обмена идеями. Этот семинар сыграл важную роль в формировании VoiceCode белой книге, документ, в котором изложены видение, которую команда на протяжении всего проекта.

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

В резюме:

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

Возьмите лист из экстремальных программирование книги

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

Затем в 2002 году, я присутствовал на одну неделю учебный семинар по экстремального программирования (XP). Я мог сразу увидеть, как практики XP были непосредственно применимы к открытым проектом. В частности практики как тесное сотрудничество с клиентами/пользователями, небольшие итераций, планирование выпуска, простота и не добавлена функция уже представила четкий и оперативный способ быстро доставки «правдоподобными обещание». Я мог бы также увидеть, как тест driven разработки, коллективного кодекса владения, стандарты и метафора системы кодирования поможет новичкам в понимании кодекса и делает их чувствовать себя комфортно с ним, (то, что важно для вербовки новых вкладчиков).

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

Заключение

Сброс кода на сайте SourceForge.net не делает не открытым исходным кодом проекта. Запуск проекта успешно открытым исходным кодом это тяжелый труд. Он требует, чтобы вы платите много внимания к доставке end-to-end значение на раннем этапе, обеспечения сотрудничества между разработчиками и с заинтересованными сторонами, и развитие свет передал процессы управления и используя несколько хаотический характер разработки открытого исходного кода.

Эта статья основана на публикации СРН 48551 Copyright © 2006 Национальный исследовательский совет Канады. Публикуется с разрешения СРН.

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!