Listos para el commit

Cuando... empecé a hacer desarrollo de software, solo hacía pequeños proyectos nada más para divertirme, eh... pequeñas aplicaciones, herramientas de línea de comando y cosas así.

Yo no sabía que era tan fácil contribuir y que no era necesario haber resuelto P=MP, tu opinión de todos modos puede ser valiosa.

Las comunidades locales me dieron la confianza... suficiente para contribuir.

Acabas de escuchar a Nolan Lawson, Lindsey Tulloch y Kanika Muraka, héroes de la línea de comando que superaron las dudas y el miedo de incorporarse a las filas del código abierto.

Quiero contarte otra historia. La historia de Saron Yitbarek, anfitriona de la edición en inglés de este podcast.

Cuando empecé a programar, mi amigo Dan y yo hicimos mi primer "pull request", que también se convirtió en mi primera contribución de código abierto.

Había oído mucho sobre las contribuciones al código abierto, había oído que era una sensación maravillosa y al mismo tiempo aterradora. Y sabía muy bien que no todas las comunidades ni todos los mantenedores son amables.

El proyecto en sí era muy bueno para una primeriza Solamente estábamos agregando una biblioteca de JavaScript, para que las personas pudieran hacer un recorrido digital por el sitio web. Un proyecto bien definido. Independiente. Y además, la ventaja era que, si no funcionaba, estaba casi segura de que no iba a descomponer el sitio completo.

Pero estaba muy nerviosa por el "pull request". Dan y yo leímos los documentos de la biblioteca. Desarrollamos nuestro código. Y todavía me acuerdo de que cuando terminamos, nos volteamos a ver con cara de: “¿Eso es todo?” Hicimos el pull request, lo revisaron y fusionaron, y no sé, supongo que me sorprendió lo... no sé, lo mecánico del proceso.

No era nada misterioso ni mágico que solo pudieran hacer los desarrolladores. Me di cuenta de que yo también podía contribuir.

Eso que descubrió Saron es lo que queremos transmitirte en este episodio. La idea de que contribuir al código abierto no es magia. Y no tiene por qué asustarnos. Vamos a verlo juntos.

Estás escuchando Command Line Heroes en español, un podcast original de Red Hat.

Este episodio es la historia de dos héroes de la línea de comando que solo quieren mejorar algo en el gran mundo del código abierto. Uno de ellos es colaborador; el otro, mantenedor. Ninguno de ellos es real; son dos personajes ficticios que representan a todos los colaboradores y mantenedores que nos contaron su historia. Esperamos que te veas reflejado en sus anécdotas.

Primero te presentamos a nuestra amiga, la colaboradora. Está empezando sus contribuciones; todos pasamos por ahí alguna vez. No conoce bien el proceso básico de trabajo, pero ve cierta necesidad y cree que puede agregar una característica que podría ser útil. Tiene muchas ganas de hacer ese ajuste, ¿pero cómo?

Y luego, cuando ya te convenciste, ¿en qué debes pensar mientras te preparas para contribuir?

Es maravilloso entusiasmarse con ciertos proyectos, ¿pero cuál es el caso de uso que quieres resolver?

Vincent Batts es director de tecnología de Kinvolk y tiene experiencia en la arquitectura de los contenedores. Cuando llegan nuevos colaboradores, los alienta a que busquen la intención de sus contribuciones. A que encuentren el nicho donde tú y tu proyecto cobran sentido.

Creo que generalmente cuando queremos contribuir a un proyecto es porque tenemos una relación recíproca con él. Te ayudó con alguna necesidad que tenías, y conforme lo utilizabas, te diste cuenta de una necesidad del proyecto y encontraste una manera de resolverla, y así se establece la relación, incluso si es una comunidad de personas.

Por ejemplo:

Terminé armando una caja de Slackware Linux porque un amigo me lo recomendó. A mí me ayudaba a hacer lo que quería, y terminé ayudándolos a empaquetarla para la comunidad de Slackware Linux. Y terminé convirtiéndome en mantenedor y colaborador de ese proyecto, no porque quisiera ser colaborador de esa comunidad de Slackware Linux, sino porque era lo más adecuado para mi otro proyecto, el caso de uso que yo estaba tratando de resolver.

Creo que eso les sucede mucho a muchas personas. Quieren escribir una base de datos para su... caso de uso particular, y descubren que funciona bien en Golang, y se dan cuenta de que escribieron una base de datos con tan buen desempeño que pudieron contribuir con correcciones o mejoras a Golang, para ayudar a que su base de datos se ejecutara más rápido.

Así que puedes encontrar tu pequeño nicho y dejar que crezca de forma natural. Lo importante es empezar. No es necesario esperar a que obtengas un título ni a que te sientas con absoluta confianza.

Si necesitas experiencia directa escribiendo códigos o documentos, o incluso como administrador de sistemas para un servidor web de bases de datos de back-end, bueno, la mayoría de esas comunidades funcionan con voluntarios. Simplemente vas a algún proyecto como Debian, eh... Fedora, o el que sea, y esas comunidades tienen configuradas páginas con documentación. Y esas páginas deben estar en algún servidor web en algún lugar, para que entonces alguien gane experiencia, incluso si... es miembro de la comunidad a quien no se le paga para verificar si el servidor web está inactivo o si algo salió mal.

Vincent hace énfasis en la naturaleza igualitaria del código abierto. De dondequiera que vengas, realmente puedes comenzar a contribuir, si lo deseas. Puedes ir adquiriendo reputación, si eso quieres.

Una vez que se fusiona alguna de tus contribuciones, tu nombre queda vinculado. Eso significa que demostraste públicamente que realizaste alguna mejora en algún lugar, lo cual es increíblemente importante.

He trabajado con gente que reparaba televisores y con profesores, que no tenían un trabajo técnico cotidiano, y que estaban muy presentes. Y contribuían mucho en la comunidad. Pero por otro lado, he trabajado con desarrolladores que a veces han tenido 30 años de... experiencia en desarrollo, pero nunca habían... contribuido públicamente al código de ese modo.

¿Cómo está nuestra colaboradora por cierto? Bueno, encontró su nicho. Venció sus miedos y finalmente hizo su primer "pull request" Ahora puede relajarse y sufrir esperando a que el mantenedor responda.

Contribuir al código fuente es como subir al escenario para el espectáculo de talentos por primera vez; te pones nervioso, y sales y tus manos comienzan a sudar. Haces algo y se siente como un logro. Te cambia profundamente, nunca serás el mismo.

¿Te cambia profundamente? Quizás. De hecho, el mantenedor puede darte cuatro posibles respuestas; silencio, lo cual es divertido; un rechazo rotundo; una aceptación rotunda. O bien, el terreno medio: una solicitud de cambio.

Dos días después de su pull request, nuestra colaboradora imaginaria finalmente recibe una respuesta del mantenedor. ¡Y miren lo que tenemos, una solicitud de cambio! Como es nueva, siente que es un fracaso. Todavía no sabe que una solicitud de cambio puede ser un logro. De hecho, se enoja por el tono golpeado del mantenedor. Pareciera que no tiene tiempo para ella.

Es como si hubiera un muro entre ellos, y la nueva colaboradora no tiene idea de lo que sucede del otro lado.

Ahora te presento a un mantenedor. El proyecto que mantiene no es su trabajo de tiempo completo, es un proyecto de fin de semana, y se queda despierto hasta altas horas de la madrugada, muchas noches pone prioridades a los problemas, y le recuerda a la gente que actualice los documentos cuando hacen pull requests... ya sabes. Tiene mucho en sus manos. A veces incluso sufre un poco de agotamiento por el mantenimiento.

Nolan Lawson, mantenedor de la vida real, hizo una increíble publicación sobre el agotamiento que captó mucho interés.

La verdad, creo que parte de esa publicación del blog era un grito de ayuda. Eh... yo explicaba que había llegado al código abierto por coincidencia. Al principio era muy divertido, pero ya no. Y no sabía qué tenía que hacer para recuperarme.

Nolan tiene un trabajo de planta, pero como la mayoría de los mantenedores, trabajaba muchísimo en su proyecto de código abierto, porque de verdad le importa. Irónicamente, lo que le pesaba mucho era el hecho de que sabía que a los colaboradores también les importa.

Lo que realmente me agotó más que nada fue la gran cantidad de gente con buenas intenciones. Y que... quieres ayudarlos; de verdad, de verdad quieres ayudarlos. Lo único que hacen es hacer una pregunta, lo único que hacen es encontrar un error real en tu proyecto que los tiene atorados, o... lo único que hacen es... eh... de verdad tomarse la molestia de descargar el código, descubrir cómo se construye y corregir un error para contribuir. Solo quieren que revises el código que aportaron.

Los mantenedores como Nolan revisan constantemente las bibliotecas de pull requests, e intentan entender el efecto que tendrán los commits. Empujan a los colaboradores a que den su mayor esfuerzo en el trabajo, a que se ajusten a las limitaciones internas, a que contribuyan de maneras que sean más significativas para los objetivos principales del proyecto.

Entonces es probable que los mantenedores no sean los monstruos que deban poner nerviosos a los nuevos colaboradores. Se rompen el lomo intentando resolver todo. De hecho, muchos mantenedores incluso se toman el tiempo de etiquetar algunas cosas como reservadas para principiantes, para que los novatos tengan oportunidades para empezar.

Sin embargo, a fin de cuentas, el alcance de todos los pull requests y commits se vuelve abrumador. ¿Cómo evitar eso? ¿Cómo crear procesos que ayuden a los mantenedores?

Una de las soluciones es crear un proyecto de código abierto con una comunidad sólida como Fedora. El líder del proyecto de Fedora, Matthew Miller, nos explica lo que atrae a los mantenedores y colaboradores al proyecto.

Gran parte de Fedora no tiene que ver con el desarrollo, sino con todo lo que gira en torno al desarrollo. Y, de hecho, eso es lo que realmente sucede en... la informática o... las ciencias de la computación en general. Y tal vez para el código abierto no... no haya suficiente de eso, de ese tipo de personas que tengan una función de soporte en torno al código abierto.

¿Pero y cómo es ese soporte?

Uno de los cargos remunerados que tenemos, por ejemplo, es el administrador del programa de Fedora, que ayuda a que se cumpla el cronograma, y se asegura de que las personas hagan el trabajo administrativo. El contar con alguien que recibe una remuneración por ello en realidad ayuda a reducir la burocracia, porque puede dedicar el tiempo para que se vuelva algo humano, en lugar de que sea... puro papeleo engorroso.

Creo que ese tipo de participación corporativa brinda estabilidad a algunas de las funciones que no se pueden garantizar con voluntarios.

Es como los espacios de trabajo que usan los trabajadores independientes. Hay un área de recepción compartida, conexión Wi-Fi y café compartidos. El gerente lo administra y tú te dedicas a lo tuyo.

Matthew nos contó sobre otra de las ventajas de Fedora. Ese modelo de trabajo evita que sientas que todo se va a ir para abajo si te tomas un descanso.

Lo que hemos intentado es dar un cierre natural a las funciones directivas, porque... porque cuando participas en un proyecto, no se trata de que sientas que ya... estás ahí de por vida. Puedes volver a inscribirte, no es que después de un año te vayan a despedir. Pero si después de seis meses quieres dar la vuelta a la página, puedes hacerlo fácilmente, sin sentir que vas a defraudar a alguien. Hemos buscado la manera de asegurarnos de que la gente pueda salir del proyecto sin problemas.

Matthew cree que es indispensable encontrar formas de apoyar a esa comunidad de código abierto sin imponer nada.

Es como... una familia, como una familia, más que... un lugar de trabajo o algo así. Es que lo importante de contribuir es que... que no solo trabajas para ti mismo, ni por un sueldo o un producto final, sino porque... las personas con las que trabajas son amigos tuyos, y el... el objetivo de esa colaboración es algo más grande que el esfuerzo individual.

Ya sea gracias a Fedora o a otro proyecto, vale la pena luchar por un mundo donde puedan continuar las contribuciones de código abierto.

Pero volvamos al escritorio de la nueva colaboradora de la que estábamos hablando; acaba de terminar los cambios que le pidió el mantenedor. Todavía no se da cuenta, pero está a punto de que acepten su primer pull request.

Es fácil perder de vista esos primeros pasos cuando hablamos de problemas a largo plazo, como el agotamiento. Cada día hay nuevos colaboradores en todo el mundo que se unen a la fiesta. Por eso es que realmente necesitamos desarrollar procesos humanos y sostenibles que fomenten la magia del código abierto.

Al final, nuestra colaboradora y nuestro mantenedor trabajan juntos para que las cosas avancen. Pero hay una última parte de la historia: recuerda que toda esa comunicación y retroalimentación dependen de las plataformas de desarrollo como GitHub y GitLab, que son lugares donde todos podemos reunirnos.

Para saber cómo esas comunidades logran que ese trabajo sea posible, conversamos con Shannon Crabill. Shannon es desarrolladora de correos electrónicos durante el día, pero en las noches está aprendiendo desarrollo front-end. También es alguien que conoce de primera mano el valor de la comunidad.

El año pasado participó en una celebración del código abierto que dura todo un mes y que se llama Hacktoberfest, una iniciativa para lograr que contribuyan más personas. En ese momento, Shannon recién comenzaba en el código abierto.

Ahora que... recuerdo ese momento de octubre, sentía que no... que no encontraba mucho en qué trabajar y que probablemente había otros principiantes que tampoco encontraban en qué trabajar. Tal vez si hago algo que sea relativamente fácil, van a poder practicar, aprender y... acostumbrarse a Git y GitHub.

Creo que... eh... la parte más difícil es entender cómo funciona y practicar. ¿Cómo subo un repositorio? ¿Cómo comparto un proyecto? ¿Cómo hago pull requests y esas cosas? Logré que la gente contribuyera. Me... Me sorprendió, pero también me... eh... me dio mucho gusto.

¿Y no te pusiste nerviosa? Porque...yo creo que... si eres nueva. Y te expones, incluso solo con tener el repositorio y punto. Y de pronto hay gente que contribuye, y... tienes que hablar con ellos, revisar su código y tener opiniones... Eso puede dar miedo.

Creo que... al principio pensaba, como: “Ay, dios mío, esto es una maravilla”, pero también, “¿en qué carambas me metí?” Me di cuenta de que... había fusionado mi propio código en mi propio código, hice un merge de mis propias pull requests y las envié a... al sitio y todo eso. Pero no lo había hecho con las de los demás. Creo que no había hecho ningún pull request, o un merge antes, así que me tuve que dedicar a ver cómo se hacía. En general, la complejidad de las fusiones es algo con lo que todavía tengo dificultades.

Este... Pero sí, tenía este torbellino de sensaciones: “Qué maravilla. Esto no sé cómo se hace”. Todos eran muy amables, y yo solo intentaba mantenerme muy... amable y honesta, incluso para decir: “Oye, me siento agobiada. Veo los pull requests de todos. No los voy a poder resolver hoy en la noche, pero mañana sí”. Y la gente parecía responder bien a eso.

Sí. Cuando mantienes un proyecto, especialmente como desarrollador nuevo... ¿significa que tienes que ser la persona más inteligente en el repositorio? Porque eh... básicamente estás calificando, juzgando y revisando el código de otras personas. ¿Se te ha presentado algún caso en que no sabías tanto como la persona que hizo el pull request? ¿Cómo lo manejaste?

Qué buena pregunta. Sentía que si pensaba: “Uy, necesito ser la mejor desarrolladora, la más inteligente de la historia”, me iba a bloquear. Yo creo que... tuve suerte de no haber pensado eso cuando me metí en esto, porque más bien pensé: “Voy a intentar, voy a ver qué pasa”.

No necesitas tener 20 años de experiencia como desarrollador. Solo necesitas... tener idea, saber cómo usar el software y estar dispuesto a aprender si no sabes.

Definitivamente hubo una o dos pull requests que agregaron características excelentes a mi proyecto y, la verdad, si el código se descomponía, yo no sabía cómo arreglarlo. Podía ver el código y decir: “Sí, no sirve". Pero si había que construirlo desde cero, no habría sabido cómo.

Pero creo que eso es algo bueno. Si la contribución fuera solo mía, podría... podría haber hecho cosas buenas, pero no tan buenas como lo que aporta la experiencia de otras personas al proyecto.

Como mantenedora, ¿qué has aprendido en el camino para lograr que el proyecto sea más accesible, más sencillo, para que sea más fácil contribuir?

Claro. Lo que creo que fue muy útil, y que me hubiera gustado hacer desde el principio, es configurar plantillas siempre que fuera posible, y generar mucha, mucha documentación.

Definitivamente agregué mucho a mi archivo README a medida que avanzaba, y creo que... tener un archivo README para comenzar es un paso muy importante. Incluso si solo son enlaces de: “Oye, echa un vistazo a nuestras pautas para contribuir”. Creo que... hice una plantilla para los pull requests, eh... hice plantillas de emisión, "haz clic aquí para ver los problemas actuales", eh... para que la gente no envíe las mismas cosas varias veces.

Hacer que sea lo más fácil o intuitivo posible, creo que eso es un paso importante que puedes dar como mantenedor.

Absolutamente. Los archivos README son muy importantes; hay... puedes hacer muchas cosas con esos archivos. Porque, pues... a final de cuentas, es un documento en blanco que le dice a la gente que lo lea. ¿Qué haces en ese... documento? ¿Cómo lo estructuras para que realmente le... sirva a la gente que busca contribuir?

Creo que tenía muchos GIF en mi README.

Qué bien.

Sí... Tenía GIF, creo que también tenía enlaces.

Shannon había aprendido rápidamente qué importantes son las relaciones. Supo de inmediato que si la gente se concentraba e incluso la pasaba bien, el resultado sería excelente.

Hay gente que hace cosas maravillosas con proyectos de código abierto. Pero también creo que puede ser divertido decir en un proyecto: “Fíjate que hice unos murciélagos que se generan al azar en esta página cuando haces clic”.

Y me encanta que haya tantas... tantas cosas distintas que la gente puede hacer. Si te gusta mucho hacer cosas artísticas y divertidas, puedes hacer la función para generar murciélagos. Pero si quieres limpiar, también puedes hacerlo. Si dices: “yo me quiero concentrar en eh... la documentación, me voy a dedicar a... limpiar un poco esto, para ayudar a todos mis colaboradores”, pues también puedes hacerlo.

Sí. Yo intenté dejar en claro que cualquier contribución que quieras hacer está bien para mí. Si encuentras una falta de ortografía y quieres corregirla, perfecto. Si notas que un enlace está roto y quieres solucionarlo, excelente. Si solo quieres comentar este código para que sea más fácil de leer y comprender, perfecto, eso ayuda mucho.

Y qué maravilla que hayas tenido una experiencia tan positiva con la comunidad, porque hay muchas historias en que ese no fue el caso, ¿no? La gente en línea no era precisamente gentil, acogedora ni amable, sobre todo con los novatos.

¿Qué crees que ayudó a que tu comunidad fuera un lugar más agradable en comparación con otras comunidades?

Simplemente el hecho de que fuera algo... informal. Si quieres contribuir, perfecto, puedes hacerlo. Si no, también. Yo realmente creía que el código abierto era de dar miedo, eh... que tenías que tener mucha experiencia y conocer muchos lenguajes complicados, o el frontend, el backend y todo lo demás para poder contribuir.

Absolutamente. ¿Cómo ha cambiado tu idea del código abierto con tu participación en Hacktoberfest?

Ah, bueno, definitivamente mejoró la idea que yo tenía. Como dije, tuve una gran experiencia y espero que... toda la gente que participó en mi proyecto de alguna manera u otra también haya tenido una buena experiencia. Eh... sin duda me ha dado el... el impulso para querer probar cosas como esa más seguido, incluso si no llegan a nada. Porque ahora me parece más fácil.

Maravilloso.

Esto es importante: miles de personas de cientos de compañías, y algunas que no pertenecen a ninguna compañía, contribuyen al kernel de Linux. Eso significa que un ejército entero de héroes cotidianos se encarga del mantenimiento de Linux, que básicamente maneja Internet. Si tienes muchas ganas de empezar tus contribuciones al código abierto, tal vez sea bueno obtener más información sobre la comunidad de Fedora.

En el próximo episodio hablaremos del despiadado proceso de errores de Darwin y de la belleza de los errores en el desarrollo del código abierto; cómo nos atormentan, nos guían y nos hacen mejores.

Command Line Heroes en español es un podcast original de Red Hat. Escúchalo gratis en Spotify, Apple Podcasts, Google Podcasts o donde más te guste. Sigan programando.