Como são projetos de código aberto gerido [fechado]

Question

Eu estou trabalhando em uma equipe pequena em alguns projetos em meu tempo livre. Nós estamos tendo o problema que parece que estamos a andar em círculos e não são capazes de obter os nossos produtos desenvolvidos - no entanto este não é um problema durante meu trabalho do dia. A falta de comunicação face-a-face parece ter um impacto real sobre a produtividade.

Qualquer exemplos de software ou metodologias em uso pela comunidade de desenvolvimento open source seria apreciada.

Answer 1

Esta é uma pergunta difícil de responder porque "projetos de código aberto" é muito ampla seleção de projetos. Eu acho que a característica que define é o projeto tem um único objetivo unificador (talvez, um conjunto de metas relacionadas).

Você está em qualquer lista de discussão de código aberto? Estou inscrito em minha lista de favorito distro de discussão e os desenvolvedores de e-mail uns aos outros muitas vezes por dia. Além disso, existem outras vias de comunicação, como IRC / Instant Messenger.

Eu não sou um desenvolvedor RoR, mas gostaria de sugerir folhear Getting Real para alguns inspiração.

Answer 2

Se você ler a história da maioria dos projetos de código aberto, eles começam com uma pessoa que faz um monte de trabalho inicial. Se há uma equipe, é pequeno, e uma pessoa realmente leva a equipe.

Para pegar um exemplo. Na comunidade Python, eles referem-se a Guido van Rossum como o Benevolent Dictator for Life (BDFL). Sua palavra é (mais ou menos) final. Em muitos casos, há pessoas não concordar com ele - mas para o bem da comunidade Python - eles parecem concordar com o seu juízo

.

Eu acho que cada projeto de código aberto tem um programador principal (singular), que assegura que as decisões são tomadas, e fez de uma forma consistente.

Para trás nos dias antigos, Fred Brooks ( The Mythical Man Month ) descreveu "equipes principais programador". Mesmo conceito. Alguém está a cargo do conteúdo técnico. Ênfase no um. Hoje em dia chamamos de o "arquiteto" ou algum tal prazo.

Answer 3

Nenhuma metodologia real aqui, mas acho que 2 coisas são importantes:

1. Ter objetivos bem definidos e responsabilidades.
2. Que cada desenvolvedor ter a última palavra em como sua parte alocada deve ser feito.

Em projetos de código aberto a única real e forte motivação é a diversão para ser tido codificação do produto. Relativa ao item 2 acima, se as pessoas dizem o que fazer, e eles não concordam com ele, a motivação começa falta. É claro que haverá sempre um pouco de dar e receber como em qualquer outro tipo de relacionamento.

Também sobre o tempo de cara, o Skype é ótimo para ter cara a reuniões face, que eu recomendo, pelo menos uma vez por semana ou mês (dependendo do tamanho e da dinâmica do projecto)

Answer 4

Meu palpite é que seus projetos particulares são todos executados e codificados por desenvolvedores. Desenvolvedores são conhecidos por ... continuar a desenvolver. A grande diferença, na minha experiência é que uma empresa tem gestores experientes que podem definir quando as coisas são feitas. Eu recomendo colocar alguém na tarefa de definir metas e decidir quando as coisas são feitas.

Answer 5

Eu estive em alguns projetos onde tivemos muito mais faladores do que os desenvolvedores. Minha inclinação é ignorar os locutores e ouvir os codificadores. Mesmo assim, há geralmente uma pessoa que está no comando de patches de aceitar. Pode haver questões políticas que têm que pisar levemente ao redor, mas para todos os efeitos, eles têm a palavra final.

Linus teve alguns problemas bastante famosas com o mesmo problema. Tome nota deste segmento a partir de 2006: Falar é fácil. Mostre-me o código.

Só mais uma coisa. Desde que você dizer nos comentários que você tem o código, apenas um monte de regravações, eu sugiro que você leia de Eric Raymond a Catedral eo Bazzaar. Eric é um pouco de um maluco na verdade, mas o ensaio é inestimável para quem deseja executar um projeto de Software Livre.

Answer 6

Eu tenho uma opinião sobre motivação e objetivos seu e seu companheiro da equipe neste projeto. São eles para:

a) Criar um produto impressionante

ou

b) brincar com software, e aprender algumas coisas novas

Ambas as respostas são igualmente válidas, e eu estou supondo que seria uma mistura com uma inclinação para um ou outro.

Se for mais de (a), em seguida, olhar para sugestões sobre a metodologia etc. Talvez até mesmo considerar a formação de uma empresa em torno de sua idéia incrível. Porque fazer tal coisa dá trabalho .. e assim você provavelmente obter o suficiente de que no trabalho.

Se é na maior parte (b), então você vai ter mais dificuldade em fazer um produto impressionante, mas um tempo mais fácil na medida em que você pode perdoar a si mesmo por não chegar lá imediatamente e sofrendo múltiplas re-escreve. E você vai ser todos aprender novas habilidades cada vez que você olha para ele e, juntos, o trabalho que são muito aplicáveis ??às suas carreiras de longo prazo.

Em primeiro lugar, sugiro que tudo ficará mais claro com o outro sobre por que você está lá. Então olha para paring para trás sobre o que você está pensando em fazer, e liberar cedo e liberar muitas vezes. Se o seu projeto é composto de três componentes e um é completa, em seguida, solte isso como um componente separado e começar a construir uma comunidade de usuários. Isso vai pagar como esses usuários possivelmente irá ajudá-lo com o seu código, além de formar um núcleo sólido de usuários para o produto completo e deixá-lo a avaliar como você está indo mais cedo ou mais tarde.

Boa sorte.