Mi primera contribución de código abierto fue para una biblioteca que había usado previamente (y habría sufrido mucho sin ella) en un proyecto pago previo. Durante mi uso inicial había detectado un error en el código, así que creé un parche, me uní al proyecto y lo envié para su revisión.
Aproximadamente 8 meses después, cuando tenía algo de tiempo libre, decidí que devolvería (y trabajaría en mis habilidades de desarrollo) contribuyendo más al proyecto. Así que cloné el repositorio y comencé a familiarizarme con la base de código. Después de algunas semanas de enviar pequeñas correcciones de parches a la base de código y monitorear las solicitudes de funciones, recogí una solicitud de funciones para agregar un módulo bastante sustancial al proyecto.
Dado que generar muchas correcciones de parches individuales es bastante tedioso para cualquier desarrollo significativo, cloné el repositorio en una rama en git hub y comencé a eliminar el código. Unas semanas y varios miles de líneas de código más tarde, el líder del proyecto y yo trabajamos integrando y probando mis correcciones en la biblioteca de una manera que funcionó de manera consistente con el resto de la base de código.
Fue un proceso invaluable del que aprendí mucho:
- Cuando comencé no sabía cómo usar Git, al final pude crear ramas de seguimiento remotas y fusionarlas o volverlas a formar en la rama maestra sin sudar.
- Comencé en VS 2008 y terminé migrando a Linux y Monodevelop para trabajar en la escritura de código (porque VS es unicode retardado y las terminaciones de línea son un gran problema en git). Resulta que no hay mucho que no puedas hacer en * nix que puedas hacer en * dows.
- Nunca antes había hecho ninguna prueba de unidad, Nunit es muy fácil de usar y escribir pruebas de unidad es algo bastante elemental.
- Tuve que aprender a tragarme la lengua y escuchar, así como practicar la paciencia. No tiene sentido mantener una posición firme en su posición en un proyecto de código abierto porque todos los involucrados están bien informados (probablemente más que usted) y capaces de aceptar / rechazar sus ideas basadas en la sustancia y no en la entrega. Es extremadamente humillante y gratificante al mismo tiempo.
- Solo tener los ojos de otro desarrollador experto en una gran base de mi código señaló fallas en mi estilo que nunca había considerado antes (así como también señalé fallas en su código). Para mí, aprendí que es más fácil / mejor definir constantes que usar un montón de números mágicos con comentarios detallados.
Ese proyecto particular se basó en generar y decodificar paquetes de red en todos los niveles de protocolos de red. Tengo un interés personal en las redes de nivel inferior, por lo que fue genial tener conversaciones con otro desarrollador con intereses y conocimientos compartidos en el dominio.
Si solo quieres mojarte los pies: busca un proyecto que ya uses; clonar el repositorio; y empiece a ver si puede corregir algunos errores y / o agregar algunas pruebas unitarias. Parece intimidante mirar la base de código de otra persona con ojos nuevos, pero es una habilidad extremadamente valiosa para aprender. Envía algunos parches. Puede esperar que su código sea analizado de cerca al principio. No se preocupe, es una parte normal del proceso ganarse la confianza de los administradores del proyecto.
Después de establecer una base de mérito con los administradores del proyecto, comience a buscar más responsabilidades, como proponer nuevas características o solicitar que se le asigne la implementación de solicitudes de características.
Si no puede encontrar un proyecto ya existente en una de las principales redes de repositorio de código abierto (github, sourceforge, código de google) piense en una aplicación que realmente le gustaría usar que aún no existe y comience la suya.
Prepárese para ser humilde y espere que el trabajo sea rechazado a favor de nuevas revisiones. El mito de que cualquiera puede agregar código a un proyecto de código abierto es completamente falso. Siempre hay un guardián entre usted y el acceso push. Cuanto mejor sea su código, menos será analizado a largo plazo a medida que se gane la confianza de los administradores del proyecto. Si es tu proyecto, serás ese guardián.
Actualizar:
Simplemente lo pensé y me di cuenta de que no me molesté en mencionar a qué proyecto hace referencia gran parte de mi respuesta. Para aquellos que quieren saber, es SharpPcap . El desarrollador principal Chris Morgan es muy profesional y puntual. Él hace un gran trabajo gestionando el proyecto y me enseñó mucho sobre lo que se necesita para madurar un proyecto OSS.
Debido a limitaciones de tiempo personal, no he podido contribuir con código en más de un año, pero todavía trato de devolver al acecho en Stack Overflow y respondiendo preguntas sobre SharpPcap ocasionalmente.