6 lecciones que aprendí al desarrollar proyectos de código abierto

La perspectiva de un científico de datos

¡El código abierto es un concepto increíble! Al agrupar las fuentes, las habilidades y el conocimiento de toda una comunidad, se pueden crear herramientas que no podríamos haber creado de forma aislada. Las herramientas que surgen de estas colaboraciones son realmente más que la suma de sus partes.

Como resultado, los científicos de datos utilizamos este software disponible gratuitamente que impulsa tantas tecnologías y al mismo tiempo tenemos la oportunidad de participar en su desarrollo.

En los últimos años, tuve la suerte de estar involucrado en el código abierto y tuve la oportunidad de desarrollar y dirigir varios paquetes.

Desarrollar código abierto es más que simplemente codificar

Durante este tiempo, hubo muchos obstáculos que superar y lecciones que aprender. Desde dependencias complicadas y opciones de diseño de API hasta comunicación con la base de usuarios.

¡Trabajar en código abierto, ya sea como autor, mantenedor o desarrollador, puede ser bastante desalentador! En este artículo, comparto algunas de mis experiencias en este campo, que espero ayuden a quienes quieran desarrollar código abierto.

Cuando crea software de código abierto, normalmente no crea el paquete exclusivamente para usted. Usuarios, de todo tipo de orígenes diferentes, harán uso de su software. La documentación adecuada contribuye en gran medida a ayudar a los usuarios a comenzar.

Sin embargo, ¡no subestime el impacto que la documentación puede tener en la usabilidad de su paquete! Puede usarlo para explicar algoritmos complejos, brindar tutoriales extensos, mostrar casos de uso e incluso permitir ejemplos interactivos.

Especialmente el software relacionado con la ciencia de datos puede resultar difícil de entender cuando implica algoritmos complejos. Abordar estas explicaciones como una historia me ha ayudado a menudo a hacerlas más intuitivas.

Créame, escribir buena documentación es una habilidad en sí misma.

Otro beneficio es que redactar documentación sólida reduce el tiempo dedicado a los problemas. Hay menos motivos para que los usuarios hagan preguntas si pueden encontrar las respuestas en su documentación.

Sin embargo, crear documentación es más que simplemente escribirla. Visualizar su algoritmo o software contribuye en gran medida a hacerlo intuitivo. Puedes aprender mucho de jay alammar cuando desee visualizar principios algorítmicos en su documentación. Sus visualizaciones incluso terminaron en el sitio oficial. Numpy ¡documentación!

Su base de usuarios, la comunidad, es un componente importante de su software. Dado que estamos desarrollando código abierto, es seguro decir que queremos que participen en el desarrollo.

Al interactuar con la comunidad, los incitas a compartir problemas y errores, ¡pero también presentas solicitudes y grandes ideas para un mayor desarrollo! Todos estos ayudan a crear algo para ellos.

La comunidad de código abierto es realmente más que la suma de sus partes.

Muchas funciones principales de BERTopic, como modelado de temas en línea, han sido implementados ya que fueron muy solicitados por sus usuarios. Como resultado, la comunidad es bastante activa y ha sido de gran ayuda para detectar problemas y desarrollar nuevas funciones.

Ya sea que su paquete se use millones de veces o solo unas pocas, crear uno es una excelente oportunidad para aprender más sobre código abierto, MLOps, pruebas unitarias, diseño de API, etc. He aprendido más sobre estas habilidades en el desarrollo de código abierto. que lo que tendría en mi trabajo diario.

También existe una gran oportunidad de aprendizaje al interactuar con la propia comunidad. Ellos son los que te dicen qué diseños les gustan o no. A veces, he visto aparecer el mismo problema varias veces en el transcurso de unos meses. ¡Esto indica que debería repensar el diseño ya que no era tan fácil de usar como había previsto!

Además de eso, desarrollar proyectos de código abierto me ha dado la oportunidad de colaborar con otros desarrolladores.

Trabajar en sus propios proyectos de código abierto fuera del trabajo tiene sus desventajas. Para mí, la más importante es que mantener el paquete, responder preguntas y participar en las discusiones puede suponer mucho trabajo.

Definitivamente ayuda si estás intrínsecamente motivado, pero aún así lleva bastante tiempo asegurarte de que todo se mantenga en orden.

Afortunadamente, puede recurrir a su comunidad para que le ayude a responder preguntas, mostrar casos de uso, etc.

En el transcurso de los últimos años, he aprendido a estar un poco más relajado cuando se trata de cambios importantes. Especialmente cuando se trata de dependencias, ¡a veces hay tantas cosas que puedes hacer!

Saber con qué frecuencia se utiliza su paquete es de gran ayuda para comprender su popularidad. Sin embargo, muchos todavía usan estrellas de Github para equiparar un paquete con calidad y popularidad.

Como científicos de datos, primero debemos comprender qué es lo que estamos midiendo exactamente. Las estrellas de GitHub no son más que un usuario que le da una estrella a un paquete. ¡Ni siquiera significa que hayan utilizado el software o que realmente esté funcionando!

Técnicamente, puedo pagar a mil personas para que destaquen mis repositorios. En cambio, me concentro en una variedad de estadísticas, como descargas y bifurcaciones, pero también en la cantidad de problemas que tengo a diario.

Por ejemplo, sería fantástico que sus paquetes aparecieran en Hacker News pero no indica si se usa consistentemente.

Como psicóloga, tiendo a centrarme mucho en el diseño de mis paquetes. Esto incluye cosas como documentación y tutoriales, pero incluso se traduce en cómo codifico.

Asegurarse de que el paquete sea fácil de usar e instalar hace que la adopción sea mucho más sencilla. Especialmente cuando te centras en filosofías de diseño como la modularidad y la transparencia, algunos paquetes resultan fantásticos de usar.

Adoptar la perspectiva de un psicólogo mientras se desarrollan nuevas funciones ha hecho que sea mucho más fácil saber en qué centrarse. ¿Qué buscan los usuarios? ¿Cómo puedo codificar de una manera que explique el algoritmo? ¿Por qué los usuarios utilizan realmente este paquete? ¿Cuáles son las principales desventajas de mi código?

Tomarse el tiempo para comprender al usuario promedio impulsa la adopción

Todo lo anterior conduce muchas veces a una regla básica pero importante;
Mantenlo súper simple

Personalmente, si encuentro un nuevo paquete difícil de instalar y usar, es menos probable que lo adopte en mi flujo de trabajo.

Si, como yo, te apasiona la IA, la ciencia de datos o la psicología, no dudes en agregarme. Etiqueta LinkedIn o sígueme Twitter. También puedes encontrar parte de mi contenido en mi Sitio web personal.

Todas las imágenes sin crédito de fuente fueron creadas por el autor.

Seis lecciones que aprendí al desarrollar proyectos de código abierto republicados desde el código fuente https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-6e4617f26c?source=rss—-247f7cf60c5620—9 vía https://towardsdatascience.com/feed

<!–

->