¿Cómo hago para que los programadores se interesen en trabajar en un proyecto conmigo?

He comenzado algunos proyectos de oss, solo uno de los cuales ha sido realmente exitoso. En resumen, esto es lo que creo que contribuyó a su éxito:

  1. Apelar a los usuarios primero. Los contribuyentes son usuarios a quienes les gusta tanto el proyecto que se unen a usted;
  2. Asegúrese de que las personas que miren más profundamente lo que ven;
  3. Cultivar una comunidad amigable y acogedora;
  4. Aprende a dejar ir y compartir responsabilidades.

En más detalles ahora …

Lo primero que intenté hacer fue atraer a los usuarios del marco. Como regla general, los contribuyentes comienzan como usuarios que se entusiasman tanto que quieren echarte una mano. Aquí hay un par de aspectos que pueden haber contribuido a eso:

  • El proyecto es un marco general con una amplia audiencia potencial.
  • Responde a un problema real y bien documentado.
  • No trata de inventar algo nuevo, se basa en ideas recomendadas por actores conocidos y respetados en el campo (es decir, Ray Ryan, en Google)
  • Comenzó bifurcando dos marcos relativamente populares que ya tenían muchos usuarios pero que no veían lanzamientos frecuentes (a pesar de que todavía tenían algunos problemas)
  • Tiene un alcance más amplio que los proyectos de la competencia, pero aún está enfocado: la mayoría de los usuarios necesitan todos los módulos ofrecidos en el marco.
  • Tenía mucha documentación desde el principio: una guía paso a paso, una descripción clara de los objetivos, etc.

A continuación, me aseguré de que las personas que echaron un vistazo más profundo al proyecto se entusiasmarían aún más:

  • Escribo código limpio. Refactorizo ​​constantemente para que sea legible y fácil de seguir. (No digo que sea perfecto).
  • Abuso del rastreador de problemas y agrego cualquier función que se me ocurra. Superviso activamente el interés del usuario en ellos.
  • Utilizo muchas de las últimas tecnologías que entusiasman a todos.
  • Documente locamente todo, incluso clases privadas y métodos privados. Valoro la calidad de la documentación tanto como la calidad del código en sí.
  • Escribo muchos ejemplos y abro mi propio gran proyecto basado en el marco.
  • Confío en tantas buenas prácticas como puedo, para que el proyecto parezca un lugar perfecto para aprender. Por ejemplo: pruebas unitarias, revisión de código, DVCS, integración continua …

El tercer paso, y lo más importante en mi opinión, fue crear una comunidad acogedora y amigable:

  • Desde los primeros días, me aseguré de ser muy activo en el foro. Intento responder preguntas rápidamente. Cuando no encuentro una buena respuesta, abro un problema en el rastreador y entrecruzo la publicación y el problema.
  • Escribo anuncios amistosos en foros relacionados. Respeto y reconozco los proyectos bifurcados y los competidores.
  • Frecuentemente pongo mis parches para revisar el código y solicito revisiones públicas. (Rietveld es una excelente manera de nutrir una comunidad de desarrolladores).
  • Doy la bienvenida a los recién llegados, sin importar su nivel de habilidad, y dejo en claro que verán sus parches.
  • Le pido a cada colaborador que use la revisión de código y paso tiempo mirando cada parche, incluso aquellos que claramente no llegarán al tronco. Escribo reseñas en un tono amigable, cuando pienso que algo está mal trato de enseñar en lugar de corregir.
  • Acepto estar equivocado. Si los contribuyentes están de acuerdo en que debemos hacer algo de alguna manera, y no puedo convencerlos de mi visión, entonces adopto la suya.
  • Agradezco públicamente a las personas, me aseguro de que sus contribuciones sean reconocidas y atribuidas.
  • Otorgo privilegios de compromiso de forma muy liberal. Mi experiencia es que los contribuyentes generalmente tienen miedo de equivocarse y no harán nada peligroso. (No estoy solo pensando esto: http://www.jacobian.org/writing/…)
  • No me asusto si alguien lo arruina, y paso tiempo con él tratando de explicarle qué salió mal.

El último paso, que estoy pasando en este momento, es aprender a dar un paso atrás. Todo lo anterior es sobre mí: “Hice esto, hice eso …” Obviamente, esto no escala. Sin embargo, a medida que el proyecto crece, encuentro que los contribuyentes que se quedan son los que comparten los valores anteriores. Hoy, las preguntas reciben respuestas amigables incluso cuando estoy dormido. Es muy gratificante ver florecer el proyecto, pero también significa que debo aprender a dejarlo ir …

Yo uso un proceso de 3 pasos.
1. Mantenga sus características simples y fáciles de describir. Generalmente me quedo con 3 características o menos.
2. Nunca expanda esa lista de características hasta que se hayan completado todas.
3. Pague a los programadores algo razonable por su tiempo, de acuerdo con los hitos acordados con anticipación.
4. Si alguna característica resulta imposible de lograr dentro de los plazos, considérala completada y quítala de la lista de características, y comienza de nuevo en 1. Paga a todos los involucrados en la característica y mantén notas cuidadosas sobre por qué fue imposible usarla más adelante.

Si gana reputación por hacer este proceso de manera confiable, es fácil lograr que los programadores se interesen en trabajar en proyectos con usted. Si no puede pagarlos, la forma más fácil de interesarlos es según esta cita:

“Si quieres construir un barco, no juntes a los hombres para recoger madera, dividir el trabajo y dar órdenes. En cambio, enséñales a anhelar el vasto e interminable mar”.
Antoine de Saint-Exupéry

Pero tenga cuidado con esta perspectiva: lo difícil es no hacer que los programadores se interesen en trabajar en un proyecto con usted, lo difícil es mantener el proyecto en el buen camino, por debajo del presupuesto y a tiempo. Mi proceso ayuda mucho con eso. Es mucho más fácil mantener a las personas coordinadas y trabajando si usa dinero y establece una estructura para que puedan trabajar dentro de ellas, como lo hice anteriormente, y les paga de manera confiable.

Déles una tarea, un incentivo concreto y (la parte difícil) asegúrese de nunca expandir su lista de funciones, sin importar qué, sin completar primero los hitos iniciales. Tenga un plan sobre cómo llevar la cosa a un punto de salida, un final, una conclusión satisfactoria en la que todos puedan beber champán. No puedo enfatizar esto lo suficiente. Si tiene fama de completar proyectos de esta manera, es mucho más fácil lograr que los programadores se interesen en sus proyectos adicionales, donde puede usar todas sus ideas inteligentes. Manténgase enfocado en problemas simples hasta que se resuelvan o se demuestre que no se pueden resolver dentro de ciertas limitaciones, y los programadores se interesarán en ayudarlo a resolverlos, y en sus proyectos en general. Eso es cierto para cualquier empleado, no solo para los programadores, sino que es particularmente cierto para los programadores.

Muchas personas se obsesionan con lo de las personas que pagan. Yo también lo hice cuando comencé a emprender. Lo superé cuando comencé a notar que las personas a las que se les paga se puede confiar para que hagan un mejor trabajo, a tiempo, y no se les puede pagar si no hacen un trabajo lo suficientemente bueno o llegan tarde. Ahora prefiero pagarle a la gente siempre que sea posible para que haga cosas por mí. Simplemente lo toman más en serio.

Y aunque quisiera estar de acuerdo con el Sr. Pasquali, diría que pagarle a la gente es mucho más confiable y fácil que descubrir cómo ser honesto y humilde con respecto a sus necesidades o explícito con respecto a sus ambiciones, y la mayoría de los programadores son mucho más es probable que trabaje en un proyecto si tiene algunas características claramente definidas y se les pagará por ello, en caso de que solo tenga la actitud correcta pero no defina claramente las características y no pague. No siempre es cierto, pero la mayoría de las veces.

Un poco menos optimista que muchas respuestas aquí, pero ha funcionado para mí y para los programadores con los que he trabajado.

More Interesting

¿Cuál es el mejor software de productividad?

Soy desarrollador de C # y ASP.NET MVC. ¿Cuál es mejor para una perspectiva profesional, 'empresa de desarrollo basada en productos o empresa de servicios de software'? ¿Qué habilidades diferentes se requieren para ambos?

¿Cuáles son los principales desafíos de la ingeniería de software automatizada?

¿Cuáles son mis posibilidades de ser admitido en la Universidad de Saarland?

¿Qué proyecto o empresa utiliza el modelo de cascada?

¿Qué significa que una empresa de software no tenga un puesto de arquitecto de software?

¿Cuáles son las ventajas y desventajas de usar OS X vs Ubuntu para el desarrollo / programación web?

¿Cómo es el mercado laboral para un programador Java vs. C #?

¿Qué es lo mejor para comenzar su carrera en una empresa de software sin un desarrollo de software de grado de ingeniería, desarrollo web, pruebas o redes?

¿Qué puedo hacer para poder responder preguntas publicadas por otros en Stack Overflow? ¿En qué áreas debería centrarme en la programación?

¿Cómo puede un estudiante universitario de ingeniería informática prepararse para convertirse en un ingeniero de software integrado?

¿Cuántos años transcurren hasta que la IA y el aprendizaje automático comienzan a reducir los trabajos de desarrollo de software?

Para un currículum de ingeniería de software, ¿es mejor enumerar proyectos de clase o proyectos personales?

¿Cuáles son las buenas certificaciones para los probadores de software?

¿Por qué debería elegir las pruebas de software como mi carrera?