Как управляются проекты с открытым исходным кодом [закрытые]

Question

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

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

Answer 1

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

Состоите ли вы в каких-либо списках рассылки с открытым исходным кодом?Я подписан на мой любимый дистрибутивсписок рассылки и разработчики переписываются по электронной почте друг с другом много раз в день.Кроме того, существуют другие способы коммуникации, такие как IRC / Instant Messenger.

Я не являюсь разработчиком RoR, но я бы посоветовал пролистать Становление Реальным для некоторого вдохновения.

Answer 2

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

Приведем один пример.В сообществе Python Гвидо ван Россума называют Доброжелательным пожизненным диктатором (BDFL).Его слово является (более или менее) окончательным.Во многих случаях есть люди, которые с ним не согласны - но ради блага сообщества Python - они, похоже, соглашаются с его суждением.

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

Вернувшись в былые времена, Фред Брукс (Мифический Человеко - Месяц) описал "команды главных программистов".Та же концепция.Кто-то отвечает за техническое наполнение.Акцент на одном.В настоящее время мы называем его "архитектор" или каким-то подобным термином.

Answer 3

Здесь нет реальной методологии, но я думаю, что важны 2 вещи:

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

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

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

Answer 4

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

Answer 5

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

У Лайнуса было несколько довольно известных проблем с той же проблемой.Обратите внимание на эту тему от 2006 года: Разговоры стоят дешево.Покажи мне код.

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

Answer 6

Я бы подумал о вашей мотивации и целях в этом проекте и вашего товарища по команде.Должны ли они:

а) Создать потрясающий продукт

или

б) поиграйте с программным обеспечением и узнайте кое-что новое

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

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

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

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

Удачи.