¿Es malo unirse a proyectos de código abierto como aficionados?

Llevo unos seis meses pensando que debería unirme a un proyecto de iPhone o iPad de código abierto para perfeccionar mis habilidades en Objective-C, pero cada vez que lo hago veo miles de líneas de código en grandes proyectos que terminar convenciéndome a mí mismo que nunca entendería. Siempre pienso que mis compromisos terminarían siendo una molestia para los administradores de proyectos y los colaboradores más importantes, por lo que siempre retrocedo en el último segundo.

Mi pregunta es, en esencia, ¿ es una molestia cuando un programador con experiencia intermedia se une a un proyecto de código abierto?

No, no es.

Si la base de código de los proyectos que ve es demasiado desalentadora, considere:

• Elegir un proyecto (incluso) más pequeño para trabajar.
• Elija una tarea más pequeña dentro del proyecto:
  • Escribe un ejemplo / tutorial / demo para algo
  • Actualice y repare la documentación (todos los proyectos, sistema operativo o no, necesitan mejores documentos)
  • Solucione muchos errores de baja prioridad pero fáciles de solucionar (gran exposición al código, los desarrolladores suelen ser felices, de bajo riesgo)
• Hay formas de contribuir sin comprometer el acceso a la fuente principal, como:
  • Enviar parches, que se pueden comentar.
  • Bifurcación y envío de solicitudes de extracción (ver arriba)
  • Tenerte y trabajar por tu cuenta, solo para ver a dónde te lleva. Si estás contento, pide a los desarrolladores que echen un vistazo a lo que hayas hecho para ver si tiene sentido.

Para superar su "miedo" de no aceptar sus compromisos, busque puntos seguros al principio. Esto permitirá que tanto usted como el equipo de desarrollo ganen confianza en su relación y aprendan la forma de pensar del otro. A medida que mejore (tanto en habilidad, experiencia, calidad de código y comprensión del equipo de su proyecto de SO como de su dinámica), podrá abordar una tarea más grande mientras introduce menos problemas.

También ayuda a pedir puntos de partida adecuados y ver qué puede encontrar el equipo adecuado para usted.

Como ejemplo, he contribuido un poco a Buildbot a lo largo de los años. Comencé a solucionar algunos pequeños problemas, luego superé la calidad de los pasos de la fuente Mercurial al corregir algunos errores evidentes. Finalmente, reescribí la mayoría de las páginas web y cambié el código HTML pegado a una solución de generación de HTML basada en plantillas. El último fue unos pocos cientos de compromisos durante unos meses de arduo trabajo.

También he realizado algunos trabajos de Mercurial, pero esos tipos son más exigentes y la tecnología es más complicada, por lo que aún no he conseguido ninguna solución en el núcleo. Hice algunos informes de errores y escribí algunas extensiones pequeñas, pero no he conseguido nada más grande en este momento.

Espero eso ayude.

Salte. Monitoree las listas de desarrollo por un tiempo y preséntese cuando se sienta cómodo. Muchos proyectos tienen algunos trabajos más fáciles en la corrección de errores o documentación que los clientes habituales estarán encantados de señalarle. La mayoría de los proyectos son bastante amigables con las nuevas manos, y lo llevarán a cero lo suficientemente rápido para que pueda convertirse en un activo real para el Proyecto.

Después de un tiempo, estará familiarizado con la estructura y las partes más importantes de la base del código. Aprender a comprender un código como este es una parte muy importante de la programación, y el código abierto es una excelente manera de aprenderlo.

Ve a por ello. Hay toneladas de principiantes haciendo lo mismo. El líder del proyecto puede ayudarlo a encontrar cosas para trabajar que no están fuera de su alcance. Gradualmente te conviertes en el resto.

Ah, y solo porque no entiendas el código no significa que sea bueno . He visto un código realmente horrible por ahí. Parte de esto es difícil de entender porque está mal escrito y está hecho para ser mucho más complejo de lo que debería ser.