Я начинаю проект с открытым исходным кодом. Любой совет?

Question

Прежде всего, я рассмотрел this question, но я думаю, мне нужно немного больше информации, так как я никогда раньше не работал над проектом с открытым исходным кодом.

Я начинаю проект с открытым исходным кодом, в настоящее время размещенный в коде Google. Это фреймворк для создания флеш-игр в ActionScript3 (ориентированный на программиста). Пока что так хорошо, но я хочу начать создавать сообщество вокруг него. Проект завершен на 60% с первого официального стабильного выпуска (я использую Scrum для руководства процессом разработки, в настоящее время у нас 3 человека в команде разработчиков). Кстати, проект имеет лицензию MIT.

Есть ли у вас какие-либо советы относительно того, как руководить разработкой, какие инструменты я должен смотреть?

Assembla vs Google code vs Trac vs Pivotal tracker?

Что вы испытываете по этому поводу?

Answer 1

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

Я бы рекомендовал потратить некоторое время на размышления о том, как вы собираетесь обнимать сообщество. Готовы ли вы потратить время на ответ на сообщения об ошибках? Как вы будете обрабатывать запросы на повышение? Вы хотите что-то вставить в код, если этого хотят несколько человек, но нет? Это все критические проблемы, которые в конечном итоге будут гораздо важнее, чем Assmebla vs Trac.

Возможно, вы захотите ознакомиться с книгой Карла Фогеля «Создание программного обеспечения с открытым исходным кодом» или «Сообщество сообщества» Джона Бэкона для получения дополнительных рекомендаций по управлению и созданию сообщества.

Answer 2

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

Удачи вам в вашем проекте!

Answer 3

Не размещайте код на кодовой сцене. Недавно я начал проект с открытым исходным кодом в качестве основы для article series on DotNetSlackers .com, чтобы показать людям, как построить сайт, такой как SO. Я ошибочно принимал этот проект на CodePlex. Моя автоматическая сборка будет периодически отправлять мне неработающие электронные письма, так как CodePlex будет беспорядочно ходить по часам за раз. ЭТО ДВИГАЕТ МЕНЯ!

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

Answer 4

Для меня руководство по разработке более важно для определения приоритетности того, что должно быть сделано, поэтому я соблазн сказать: почему бы вам просто не использовать трекер Track Code, поскольку ваш проект уже размещен там? Я думаю, что он предлагает все, что вам нужно. Настройте его, чтобы добавить Оценки поле, если вы хотите (для Scrum), и там вы идете.

Почему, по-вашему, вам нужно что-то еще? У вас уже есть исходный репозиторий, средства проверки кода, вики, списки рассылки, трекер ошибок, защищенный доступ для участников. Вам не нужно много больше для совместной работы. Что вам не хватает? Мгновенное сообщение? Используйте Skype или Gtalk. IRC? На данный момент это вам не нужно.Нет, на самом деле, я не думаю, что инструмент будет решать что-то еще здесь (даже если вы не можете нарисовать схему выгорания, а не крупную сделку для проекта IMO без полного времени).

Так как любой другой инструмент будет менее хорошо интегрирован с другими службами Google Code (например, мне нравится связывать мои коммиты с вопросами, используя «Issue #ID» в комментариях, которые автоматически связаны), я бы придерживался с тем, что у вас есть в настоящее время (возможно, просто добавьте Gtalk/Skype, чтобы облегчить общение/сотрудничество), и я бы начал создавать проблемы, а определил приоритеты. Хорошая приоритизация работы является ключом к успешному проекту, нет инструмента для серебряных пулей, который сделает это за вас. Затем планируйте фиксированные даты (выпуски) и присвойте наиболее важные проблемы предстоящей вехе. Закройте столько вопросов, сколько вы можете до крайнего срока. Когда придет время выпуска, отпустите то, что было сделано, отложите нереализованную проблему на следующую веху и начните заново.

Answer 5

• Стремитесь принять. Чем больше пользователей вы получите, тем больше людей будут возвращаться.

• Включите большое количество образцов кода в вики и разрешите пользователям загружать пример приложения.

• Убедитесь, что ваш API хорошо документирован ASDoc.

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

• Будьте внимательны к определению приоритетов запросов и ошибок. У вас и вашей команды нет времени на все.

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

• Релиз на раннем этапе выпуска. I Ненавижу, чтобы загрузить и использовать ревизию HEAD из репозитория, потому что команда только официально выпустила одну версию своего проекта, и ей уже год.

Answer 6

Я хотел бы предложить проверить эту книгу: http://producingoss.com/

Я считаю, что это бесплатный онлайн и PDF версии.

Я перепутал с Trac некоторыми, и он, безусловно, может выполнить эту работу, но если вы уже делаете гибкий процесс разработки, я бы посмотрел Pivotal Tracker. Я использую его на побочном проекте, и он довольно гладкий, не говоря уже о бесплатном использовании. В Pivotal есть все, что вы ожидаете: истории, отставание, расчет скорости, несколько диаграмм и т. Д.

Answer 7

Если вам нужно программное обеспечение для поддержки вашего проекта по схватке ... agile42 предлагает free Licenses of Agilo for Scrum Pro для проектов с открытым исходным кодом.