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

Question

Estoy trabajando en un pequeño equipo en algunos proyectos en mi tiempo libre. Estamos teniendo el problema que nos parece ir en círculos y no son capaces de obtener nuestros productos desarrollados - sin embargo, esto no es un problema durante mi trabajo del día. La falta de comunicación cara a cara parece tener un impacto real en la productividad.

Cualquier ejemplos de software o metodologías en uso por la comunidad de desarrollo de código abierto sería apreciada.

Answer 1

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

¿Está en alguna lista de correo de código abierto? Estoy suscrito a mi lista de correo favorito distro 's y los desarrolladores de correo electrónico entre sí muchas veces al día. Además, existen otras vías de comunicación, como IRC / Instant Messenger.

No soy un desarrollador de RoR, pero sugeriría hojear Conseguir real para algunos inspiración.

Answer 2

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

Para recoger un ejemplo. En la comunidad de Python, se refieren a Guido van Rossum como el Dictador Benevolente para la Vida (BDFL). Su palabra es (más o menos) final. En muchos casos hay personas no están de acuerdo con él - pero por el bien de la comunidad Python - que parecen consentir a su juicio

.

Creo que cada proyecto de código abierto tiene un (singular) jefe de programación que asegura que se toman las decisiones, e hicieron de una manera consistente.

De vuelta en los viejos tiempos, Fred Brooks ( El hombre Mes mítico ) describe "equipos de jefe de programación". El mismo concepto. Alguien es responsable del contenido técnico. Énfasis en el uno. Hoy en día llamamos el "arquitecto" o algo por el término.

Answer 3

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

1. Tener objetivos bien definidos y responsabilidades.
2. Que cada desarrollador tendrá la última palabra en la forma en que su parte asignada debe hacerse.

En proyectos de código abierto la única motivación real y más fuerte es el que se había divertido de codificación del producto. Relativa a # 2 anterior, si la gente se les dice qué hacer, y ellos no están de acuerdo con ella, la motivación empieza deficiente. Por supuesto que siempre habrá un poco de dar y tomar, 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

Mi conjetura es que sus proyectos privados son todos corren y codificados por los desarrolladores. Los desarrolladores se sabe que ... mantener en el desarrollo. La gran diferencia, en mi experiencia es que una empresa ha experimentado gerentes que pueden definir cuando se hacen las cosas. Me gustaría recomendar poner a alguien en la tarea de definir los objetivos y decidir cuándo se hacen las cosas.

Answer 5

He estado en algunos proyectos en los que tuvimos mucho más conversadores que los desarrolladores. Mi inclinación es hacer caso omiso de los habladores y escuchar a los codificadores. Incluso entonces por lo general hay una persona que está a cargo de aceptar parches. Puede haber cuestiones políticas que tienen que ir con cuidado alrededor, pero para todos los efectos que tiene la última palabra.

Linus ha tenido algunos problemas bastante famosas con el mismo problema. Tome nota de este hilo desde 2006: Hablar es barato. muéstrame el código.

Una cosa más. Puesto que se dice en los comentarios que usted tiene el código, sólo un montón de reescrituras, yo recomiendo que lea de Eric Raymond la catedral y el Bazzaar. Eric es un poco de un loco en realidad, pero el ensayo no tiene precio para cualquiera que desee ejecutar un proyecto de software libre.

Answer 6

Tendría un pensar acerca de su motivación y de su compañero de equipo y los objetivos de este proyecto. Están a:

a) Crear un producto impresionante

o

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

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

Si se trata de más de (a) y luego mirar sugerencias sobre metodología, etc. Tal vez incluso considerar la formación de una empresa en torno a su idea impresionante. Porque hacer tal cosa toma el trabajo .. y así es probable que obtener suficiente de que en el trabajo.

Si es en su mayoría (b), entonces vamos a tener más dificultades para hacer un producto impresionante, pero un tiempo más fácil en el que se puede perdonarse por no llegar de inmediato y sufrir múltiples reescrituras. Y todos ustedes van a aprender nuevas habilidades cada vez que se mire y trabajar juntos, que son muy aplicables a sus carreras a largo plazo.

En primer lugar, te sugiero que todo quedará más claro entre sí sobre qué está allí. Luego, busquen en recortar de nuevo en lo que usted está planeando en hacer, y la liberación temprana y liberar a menudo. Si el proyecto se compone de tres componentes y uno está completa, a continuación, suelte que como un componente separado y empezar a construir una comunidad de usuarios. Esto dará sus frutos ya que estos usuarios posiblemente le ayude con su código, además de formar un núcleo sólido de usuarios de todo el producto y le permiten evaluar cómo se va temprano que tarde.

Buena suerte.