Código abierto: ¡No es tan aterrador!

Lo siguiente se publicó antes del lanzamiento de las Becas Toptal para mujeres desarrolladoras.

Como desarrollador, es emocionante y desafiante mantenerse al día con las últimas tendencias en tecnología. Todos los días, nuevos lenguajes, marcos y dispositivos captan nuestra atención y estimulan las conversaciones en reuniones, foros y chats. Sin embargo, nuestra comunidad de desarrolladores está formada por personas, no por herramientas, y es fascinante explorar sus aspectos sociopolíticos (a falta de una palabra mejor, "social" tiende a asociarse con las redes sociales en estos días).

En Toptal, recientemente tuvimos algunas conversaciones interesantes sobre cuánto contribuyen las mujeres al código abierto y qué les impide contribuir más, por lo que hemos investigado el asunto. Habiendo sido parte de esa conversación con Breanden Beneschott y Bozhidar Batsov, me pregunté: Bozhidar es uno de los principales contribuyentes de código abierto en GitHub. ¿Dónde estoy? Si revisa mi cuenta pública de GitHub a partir de hoy, se trata principalmente de pequeños proyectos de prueba que usé en clase para mis alumnos. Están a medias y definitivamente no son representativos de mis habilidades o experiencia. (Tendrá que creer en mi palabra al respecto). Si alguien considerara contratarme en función de lo que puede encontrar en esa cuenta, supongo que tendría dificultades para ganarme la vida. Aun así, he sido desarrollador profesional durante más de 20 años y en mi trabajo diario he estado usando más software de código abierto de lo que me gustaría recordar. Con el tiempo, pirateé el kernel de Linux para adaptarlo a alguna necesidad específica, modifiqué cada enrutador y NAS que compré, esperé pacientemente durante meses en la lista de espera de Raspberry Pi para tenerlo en mis manos y obtener mi domótica casera como Me gusta. Aún así, ninguno de estos ajustes y pruebas llegó a mi GitHub para convertirse en código abierto. Además, además de corregir un error en una de las primeras versiones de Tomcat, nunca contribuí a un proyecto de código abierto. Curioso, ¿no?

Podrías pensar que es solo falta de tiempo o interés, pero sé que no lo es. En cuanto a mis proyectos personales, puede que haya pensado que nadie podría estar realmente interesado en lo que he hecho, pero sobre todo es que la sola idea de publicar mi trabajo allí, para que todos lo vean y para la posteridad, me asusta mucho. Y aunque siempre puedes derribar un proyecto personal de GitHub, el día que intentas contribuir a un proyecto de código abierto ampliamente disponible, no hay vuelta atrás. ¿Qué pasa si mi código no es lo suficientemente bueno? ¿Qué pasa si no entendí bien el problema? ¿Qué pasa si mi solicitud de extracción es rechazada? ¿Qué pasa si la gente me trolea?

Una ronda rápida de llamadas con amigos desarrolladores, en su mayoría mujeres, pronto me convenció de que no soy el único con este problema, pero para un ingeniero no hay problemas, solo soluciones, ¿verdad?

Este es un problema importante a resolver, porque contribuir a un proyecto de código abierto puede marcar una gran diferencia:

• Durante su carrera : Muchos clientes mirarán su red social antes de decidirse a contratarlo; tu cuenta de GitHub y tu currículum de LinkedIn encabezan la lista, junto con tus perfiles de Facebook y Twitter. Debes usarlos sabiamente.
• Para tus habilidades técnicas : Examinar un código base escrito por otros desarrolladores, y a menudo muy buenos, te enseña mucho. La capacidad de extraer el significado de un código base mal escrito lo desafiará y le enseñará mucho.
• Para sus habilidades blandas : el software de código abierto es un proceso colaborativo, y casi todos los proyectos interesantes que existen están construidos por equipos. Aprender a trabajar con otros desarrolladores a través de las herramientas que todos usan, a integrarse en el equipo, a comunicarse de manera eficiente, es lo que lo convertirá en un gran desarrollador, no solo en uno hábil.
• Para la comunidad : cada bit que contribuye a un proyecto de código abierto cuenta. Cuanto más contribuya, mejor, pero incluso corregir un pequeño error tipográfico en una traducción hará que el producto final sea mejor.
• Para tu red : puedes enviar cientos de currículos a empresas, pero nada funciona como tener colegas con conexiones personales. Involucrarse activamente en un proyecto de código abierto le asegurará conocer gente y ganarse su respeto, y su reputación crecerá, lo cual es invaluable para cualquier profesional.

Este es mi pequeño viaje personal en la lucha contra este miedo. Publicar este artículo es parte del viaje en sí. Lo escribo con la esperanza de que cualquiera que esté bloqueado para escribir una publicación de blog, o que tenga miedo de hacer incluso una pequeña contribución, vea que al final no fue tan aterrador. Además, está destinado a ayudar a cualquier persona a la que le encantaría contribuir con el código abierto, pero que realmente no sabe por dónde empezar, así que comenzaré con lo básico.

¿Qué es un software de código abierto y dónde lo encuentro?

El software de código abierto, o OSS para abreviar, es cualquier software lanzado con su código fuente e incluye una licencia que le permite modificarlo y redistribuirlo. Se puede entregar en cualquier lugar: en un sitio web, a través de una lista de correo o con una lechuza. El escenario más común, y el que nos interesa, es cuando el código base se mantiene en un repositorio colaborativo. Aquí nos estamos enfocando en GitHub, pero hay otras opciones, como SourceForge y Bitbucket. GitHub es muy amigable, tiene una gran base de usuarios, se puede usar para cualquier tipo de código y con cualquier entorno de desarrollo que use. Es importante destacar que también se usa ampliamente para proyectos que no son de código abierto. Lo más probable es que su próximo proyecto de cliente se aloje allí, por lo que saber cómo trabajar con él es una habilidad útil en sí misma.

¿Qué pasa si no sé codificar?

Si estás leyendo esto, es probable que quieras aprender a codificar. Puede encontrar cursos increíbles en varios sitios web gratuitos y de pago. Debes elegir un idioma para aprender; si no tiene una preferencia, vaya con JavaScript. Ya tiene todo lo que necesita para comenzar en su navegador web y es una de las habilidades más utilizadas y comercializables. Mi favorito personal es Python, que se usa tanto en desarrollo web como en aplicaciones científicas. Yo también tengo un curso favorito para principiantes, "Introducción a la informática" en Udacity. Me gusta porque es un curso práctico, donde trabajas en un proyecto mientras aprendes. También puede encontrar varios otros cursos en Coursera, Khan Academy y PluralSight.

¿Qué pasa si no conozco Git?

Como se mencionó anteriormente, conocer Git es importante, así que tome una clase de Git. Hágalo incluso si ha estado trabajando con Git por un tiempo; no sabes cuánto no sabes sobre Git hasta que realmente lo estudias. Hágalo si no puede explicar con confianza qué hace el comando rebase . Hazlo incluso si una rebase incorrecta no te asusta. Tomé la ruta completa de Git en Code School, pero nuevamente, puede explorar otros sitios para obtener más opciones.

¿Cómo elijo un proyecto en GitHub?

Es probable que utilices algún OSS en tu desarrollo diario. Elegir un marco familiar es un buen punto de partida; ya está familiarizado con las características y cómo funciona el marco. Cuando te sumerjas en el código fuente, aprenderás más y entenderás su lógica aún más claramente. Si hay una tecnología o herramienta que le gusta especialmente, busque proyectos que la mencionen o el proyecto de la herramienta en sí. Como último recurso, puede consultar los proyectos en GitHub Showcases y comenzar eligiendo una categoría que le interese.

Por ejemplo, una búsqueda rápida de “Raspberry” en la búsqueda de GitHub muestra más de 17 mil repositorios. Es fácil perderse, así que busque un proyecto con una buena comunidad y un buen seguimiento de problemas. Al elegir un proyecto, verifique el número de:

• Contribuidores : Diríjase a cualquier cosa por encima de diez contribuyentes. Esto debería asegurar que el proyecto tenga suficiente interés y no sea simplemente un pequeño esfuerzo de equipo. Si es nuevo en OSS, o no tiene mucha experiencia, limite su búsqueda a proyectos con un máximo de cincuenta colaboradores; comunidades más grandes implican bases de código más grandes y proyectos más complicados.
• Confirmaciones : elige proyectos que tengan al menos mil confirmaciones y donde la actividad más reciente no tenga más de una semana. Un proyecto que ha estado inactivo durante un mes o más es antiguo y obsoleto en términos de OSS, y probablemente no obtendrá ninguna respuesta rápidamente. La actividad diaria es el signo de un proyecto saludable.
• Problemas : los problemas son problemas abiertos, errores que se han informado o características solicitadas para implementar. Te darán un punto de partida y son una buena métrica del interés en el proyecto.

Además, averigüe cuál es el idioma principal del proyecto; Puedes ver las estadísticas del idioma en la barra superior de la página principal del proyecto. Tómese un tiempo para leer el tono de la discusión, vea cuán amistosos y educados son los comentarios. Algunos proyectos son famosos por sus comunidades agresivas, por lo que pueden no ser el punto de partida adecuado.

Elegí ScyllaDB, un proyecto de almacenamiento de datos en columnas, ya que me fascinan los datos, cualquier cosa relacionada con el rendimiento. Nunca he trabajado con él, pero espero poder sumergirme en su base de código. Puede que sea más sencillo trabajar con herramientas que conozco, pero lo estoy tomando como un desafío y una ocasión para aprender algo nuevo. Por lo demás, cumple a la perfección; tiene 18 colaboradores, 6.5k confirmaciones (la más reciente fue hace 23 horas al momento de escribir), 178 problemas abiertos y parece activo.

¿Qué hago ahora?

Primero, clone el repositorio e instale el software en su máquina para tener una idea de sus partes móviles. Luego, comience a leer los números. Una vez que se sienta listo, vea si puede reproducir el problema en su máquina y luego comience a analizar qué hace que el software se comporte mal.

Otro enfoque sería encontrar algo que usted mismo pueda mejorar o modificar. Tal vez notó un error tipográfico o una fuente desalineada, por ejemplo. Elegí corregir un pequeño error, específicamente un nombre de variable incorrecto utilizado en la documentación de un script.

Parece diminuto, pero la documentación incorrecta es mucho peor que no tener documentación. Los usuarios instalarán ScyllaDB y seguirán los pasos de instalación, confiarán ciegamente en lo que está escrito en ese script y terminarán frustrados. Esto fue perfecto para mis habilidades, y solucionarlo requerirá que siga todo el proceso y me familiarice un poco con el código base. La corrección de errores es aburrida, pero es un gran comienzo para encontrar su camino en un proyecto.

Creando un tenedor

Esto puede ser trivial, pero por el momento, para el proyecto ScyllaDB, soy la Sra. Nadie; sería arriesgado permitirme hacer cambios en su código sin supervisión. Lo que debo hacer es crear una "bifurcación" en mi propia cuenta de GitHub. Aquí está mi bifurcación ScyllaDB. Es mi propio patio de recreo donde tengo acceso a todo el código y puedo modificar los archivos como desee. Si quisiera crear mi propia versión de ScyllaDB y modificarla para que hiciera algo completamente diferente a su propósito original, podría hacerlo aquí. Crear una bifurcación es simple; vaya a la página principal del proyecto y haga clic en el botón "bifurcación". No da miedo en absoluto.

Es hora de arreglar el error

Ahora es el momento de probar el código en su computadora y hacer las modificaciones necesarias. En primer lugar, asegúrese de haber instalado el cliente Git en su máquina. Luego, agregue su clave pública SSH a GitHub y asegúrese de que su ssh-agent la cargue. Obtener el código localmente es simple; solo usa el comando git clone que apunta a tu bifurcación, en lugar de la rama principal:

 git clone [email protected]:acbellini/scylla.git

A estas alturas, debería haber probado el proyecto en la rama principal, por lo que va a compilar su código localmente y probarlo de la misma manera. Tenga en cuenta que tendrá que bifurcar cualquier otro proyecto de GitHub en el que se base su proyecto, ya que las referencias son relativas. En mi caso, tuve que bifurcar a seastar, scylla-ami y scylla-swagger-ui.

El error que necesito corregir es relativamente simple; la documentación en conf/scylla.yaml menciona tres directorios configurables: uno para archivos de datos, uno para registros de confirmación y otro, aparentemente sin usar, para cachés, todos predeterminados en algún subdirectorio de $CASSANDRA_HOME :

Al profundizar en el código, se muestra que los valores predeterminados son diferentes y, como se mencionó en el número 372 desde el que comencé, no se debe usar $CASSANDRA_HOME . Valido mi hipótesis probando el código con un par de configuraciones diferentes, eliminando la configuración del archivo de configuración y verificando qué directorios se usan. Una vez que estoy lo suficientemente seguro de que todo es correcto, puedo agregar, confirmar y enviar el archivo modificado:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Tenga en cuenta que introduje el número de problema precedido por un hash en el mensaje de confirmación. Esto le indicará a GitHub que vincule automáticamente mi código al problema en sí.

Otra cosa importante a tener en cuenta es que, cuando examiné el código, me di cuenta de que el tercer directorio, el de los cachés, en realidad no se usa. Es tentador ir un paso más allá y eliminar esta configuración en sí, o agregar un comentario que no se usa, pero que estaría fuera del alcance del problema n.º 372, y sería incorrecto cometer cualquier cosa que no esté estrictamente relacionada con esto. asunto. Debe mantener sus cambios enfocados y limitados a la tarea en cuestión.

En este punto el código está arreglado y está en GitHub, en mi fork privado. Aquí es donde entra la parte aterradora: pedirle a la gente de ScyllaDB que acepte mi código. Esto se llama una solicitud de extracción.

El paso final: la solicitud de extracción

Me gusta crear solicitudes de extracción directamente desde la interfaz web en GitHub. Lo encuentro más intuitivo y a prueba de errores que intentar hacerlo desde la línea de comandos. Todo lo que tengo que hacer para crear mi solicitud de extracción es hacer clic en el pequeño botón verde junto al nombre de mi sucursal:

Tenga en cuenta que GitHub calculó automáticamente el comentario. Mi rama ahora tiene una nueva confirmación, pero desde que creé mi bifurcación hay 14 confirmaciones más en el repositorio principal, así que haré clic en el ícono verde a la izquierda.

Afortunadamente, mi compromiso único no entra en conflicto con los otros 14, por lo que GitHub me informa que estoy listo para continuar. No necesito añadir ningún otro comentario o mensaje. El mensaje de confirmación, aunque es muy breve, lo dice todo: qué hace mi cambio de código y con qué está relacionado. Mientras hago clic en el último botón para confirmar mi solicitud, me pregunto qué fue lo que encontré tan aterrador hace solo unos días. No hay ningún monstruo rugiendo hacia mí en este momento, y las llamas del infierno no parecen estar ardiendo. Honestamente, no fue para nada aterrador. En el improbable caso de que me equivoque, mi arreglo no será aceptado y eso será todo.

Si ahora verifica los detalles del problema, puede ver que GitHub agregó automáticamente una nota de que hay una solicitud de extracción que hace referencia a este problema. Esta es la magia de ese #372 en el mensaje de confirmación. Esto ayudará a evitar que otras personas pierdan el tiempo arreglando algo que ya se ha arreglado.

notas finales

Ahora estoy esperando que se acepte mi solicitud de extracción, recibiré una notificación cuando eso suceda. Tenga en cuenta que esto puede demorar algunos días, incluso semanas; alguien tiene que revisar mi código, probar que funciona como se describe, solucionar el problema y, en última instancia, asegurarse de que no afecte negativamente la funcionalidad del resto del código (léase: crea nuevos errores). Todo esto toma el tiempo de alguien, así que ten paciencia. Al final, cuando se acepte mi solicitud de extracción, ScyllaDB tendrá un colaborador más, un problema menos y tendré mi primera contribución de OSS. Ahora es el momento de que tú también lo pruebes. Después de todo, no da miedo en absoluto.