¿Cómo se gestionan los proyectos de código abierto

Question

Estoy trabajando en un pequeño equipo en algunos proyectos en mi tiempo libre. Estamos teniendo el problema de que parece que damos vueltas y no podemos desarrollar nuestros productos; sin embargo, esto no es un problema durante mi trabajo diario. La falta de comunicación cara a cara parece tener un impacto real en la productividad.

Se agradecerá cualquier ejemplo de software o metodologías en uso por la comunidad de desarrolladores de código abierto.

Answer 1

Esta es una pregunta difícil de responder porque los "proyectos de código abierto" son una selección muy amplia de proyectos. Creo que la característica definitoria es que el proyecto tiene un único objetivo unificador (tal vez, un conjunto de objetivos relacionados).

¿Está en alguna lista de distribución de código abierto? Estoy suscrito a la lista de correo de mi favorite distro y los desarrolladores se envían correos electrónicos varias veces al día. Además, hay otras vías de comunicación, como IRC/Instant Messenger.

No soy un desarrollador de RoR, pero sugiero que revise Getting Real para obtener inspiración.

Answer 2

Supongo que sus proyectos privados son ejecutados y codificados por los desarrolladores. Los desarrolladores son conocidos por ... seguir desarrollando. La gran diferencia, según mi experiencia, es que una empresa tiene gerentes experimentados que pueden definir cuándo se HACEN las cosas. Recomiendo poner a alguien en la tarea de definir los objetivos y decidir cuándo se hacen las cosas.

Answer 3

No metodología real aquí, pero creo que 2 cosas son importantes:

1. tienen objetivos bien definidos y responsabilidades.
2. Deje que cada desarrollador tenga la última palabra en cómo se debe hacer su parte asignada .

En proyectos de código abierto, la única motivación real y más fuerte es la diversión de codificar el producto. En relación con el n. ° 2 anterior, si se les dice a las personas qué hacer y no están de acuerdo con él, la motivación comienza a faltar. Por supuesto, siempre habrá un poco de toma y daca como en cualquier otro tipo de relación.

también sobre el tiempo de la cara, Skype es genial para tener reuniones cara a cara, lo cual recomiendo al menos una vez a la semana o al mes (dependiendo del tamaño y el impulso del proyecto)

Answer 4

que he estado en algunos proyectos donde tuvimos muchos más conversadores que desarrolladores. Mi inclinación es ignorar a los habladores y escuchar a los codificadores. Incluso entonces generalmente hay una persona que está a cargo de aceptar parches. Puede haber problemas políticos que tienen que sortear ligeramente, pero para todos los efectos tienen la última palabra.

Linus ha tenido algunos problemas bastante famosos con el mismo problema. Tome nota de este hilo de 2006: Talk is cheap. Show me the code.

Una cosa más. Como dices en los comentarios que tienes código, solo un montón de reescrituras, te sugiero que leas el The Cathedral and the Bazzaar de Eric Raymond. Eric es un poco loco, pero el ensayo no tiene precio para cualquiera que quiera ejecutar un proyecto de Software Libre.

Answer 5

Si lee el historial de la mayoría de los proyectos de código abierto, comienzan con una persona que hace una gran parte del trabajo inicial. Si hay un equipo, es pequeño y una persona realmente lidera el equipo.

Para elegir un ejemplo. En la comunidad de Python, se refieren a Guido van Rossum como el dictador benévolo para la vida (BDFL). Su palabra es (más o menos) final. En muchos casos, hay personas que no están de acuerdo con él, pero por el bien de la comunidad de Python, parecen estar de acuerdo con su criterio.

Creo que cada proyecto de código abierto tiene un (singular) programador principal que asegura que las decisiones se toman y se hacen de manera consistente.

En los viejos tiempos, Fred Brooks (The Mythical Man Month) describió los "principales equipos de programadores". Mismo concepto. Alguien está a cargo del contenido técnico. Énfasis en el uno. Hoy en día llamamos al "arquitecto" o algún término similar.

Answer 6

Me gustaría pensar acerca de la motivación y los objetivos de su compañero y su equipo en este proyecto. Son ellos para:

a) Crear un producto impresionante

o

b) jugar con el software, y aprender algunas cosas nuevas

Ambas respuestas son igualmente válidas, y supongo sería una mezcla con una inclinación hacia uno u otro.

Si se trata más de (a) a continuación, consulte sugerencias sobre la metodología, etc. Tal vez incluso considere formar una empresa en torno a su idea impresionante. Porque hacer tal cosa requiere trabajo ... y bueno, es probable que tengas suficiente de eso en el trabajo.

Si es mayormente (b), tendrá más dificultades para fabricar un producto impresionante, pero le resultará más fácil perdonarse a sí mismo por no haberlo recibido de inmediato y sufrir varias reescrituras. Y todos aprenderán nuevas habilidades cada vez que lo miren y trabajen juntos, que son muy aplicables a sus carreras a largo plazo.

En primer lugar, sugiero que todos sean claros entre ustedes sobre por qué están allí. Luego, analice lo que está planeando hacer, y libérelo temprano y libérelo con frecuencia. Si su proyecto se compone de tres componentes y uno está completo, libérelo como un componente separado y comience a construir una comunidad de usuarios. Esto valdrá la pena ya que estos usuarios posiblemente lo ayuden con su código, además de formar un núcleo sólido de usuarios para el producto completo y le permitirá evaluar cómo va temprano en lugar de tarde.

Buena suerte.