Cómo aprender de código abierto

Veo este problema con bastante frecuencia. Me gusta una cierta propuesta de valor de un proyecto de código abierto. Pruebo los tutoriales básicos. Excelente. ¡Funciona! Pero si paso a problemas más complejos, paso horas investigando, depurando, frustraciones, etc.

¿Cuáles son sus estrategias para mantener la motivación en código abierto? ¿Cuál es la recompensa del código abierto después del éxito de los tutoriales básicos? ¿Qué "éxito" de código abierto experimentaste?

Supongo que está buscando pequeñas bibliotecas de código abierto como las que se encuentran en github. En mi caso, a menudo uso uno para resolver un problema específico. Si no lo resuelve limpiamente, entonces profundizo, aprendo cómo funciona el código y hago los cambios necesarios. Si mi cambio es por algo útil o una corrección de errores, intento contactar al propietario de código abierto o bifurcar mi propia sucursal.

Otras veces solo estoy adaptando algo cercano a mis propias necesidades, en esos casos solo mantengo mis cambios y sigo adelante. Agrego relojes o reviso regularmente para ver qué se ha actualizado.

Sin embargo, como en las notas, esta es la vida del desarrollo de software. Es un entorno siempre cambiante.

¿Pregunta cómo mantiene la motivación para usar un proyecto API de código abierto dado?

El truco es descubrir qué proyectos de código abierto son los buenos. La calificación principal en Open Source es el hecho de que tiene acceso al código fuente, lo cual es extremadamente útil cuando necesita saber cómo funcionan las cosas (lo que generalmente sucede cuando necesita cambiar el comportamiento en alguna situación), pero esto no implica algo más que eso. Esto incluye la calidad del proyecto que no tiene relación alguna con la apertura de la fuente.

La calidad consiste en varias cosas más o menos sutiles cuando se habla de un proyecto de código:

• ¿Qué tan bien está diseñado el API? ¿El código que necesita escribir para llamar realmente a la API se lee fácilmente?
• ¿Qué tan bien escrito está el código real en la API? ¿Es fácil entender lo que sucede? ¿Las estructuras de datos están bien elegidas y no tienen características de tiempo de ejecución costosas? ¿Se eligen bien los nombres de las variables? ¿El código se ajusta a un estándar de codificación?
• ¿Está documentada la API? Este es tanto el diseño como el javadoc del código real, y ¿es útil? Esto es más importante de lo que piensas, ya que muestra la madurez del código.
• ¿El proyecto tiene una página web? ¿Está actualizado y sin enlaces rotos? ¿Proporciona acceso fácil al código fuente, descargas y documentación?
• ¿El proyecto tiene una comunidad y listas de correo? ¿Los archivos están disponibles y accesibles? ¿Es útil la comunidad?

Todas estas cosas son útiles para tener en cuenta al elegir si desea utilizar un proyecto de código abierto determinado o no. Cualquier derivación de los mejores debería hacer que una señal de advertencia parpadee en su cabeza, ya que es una indicación de que este no es el mejor proyecto.

Luego, cuando encontraste el proyecto, te gusta lo que ves, ahí está la prueba final:

• ¿Qué tan difícil es comenzar a trabajar desde cero con un programa simple que invoca la API de una manera útil?

Esto debería ser

1. explicado en una ubicación fácil de detectar en el sitio web del proyecto y / o en la documentación en el paquete de descarga.
2. fácil de entender: la documentación debe ser precisa, el programa simple de escribir o adaptar a partir de un ejemplo dado y simple, bien explicado y fácilmente comprensible.
3. rápido para hacerlo bien: si necesita realizar alguna depuración en este punto para que el programa se ejecute como se explicó, algo está muy mal.

Si es evidente que este es un caso de uso anticipado y priorizado, entonces esto debería ser trivialmente simple. Si es evidente que al proyecto no le importa esta cosa en particular, entonces consideraría no usarlo. Si está cuesta arriba aquí, será cuesta arriba muchas, muchas veces más tarde, y será mejor simplemente no usarlo.