Cómo contribuir a un proyecto de código abierto

El mundo del software, tal y como lo conocemos hoy en día, no sería el mismo si no existiese el código abierto. De alguna forma, cuando visitas con tu navegador un sitio web, estás usando código abierto. Ya sea en tu sistema operativo, el navegador o la propia página web.¡Hasta yo para preparar este curso que estás siguiendo he usado en algún punto algo de código abierto!

Que cientos de miles de personas del mundo del desarrollo puedan acceder a millones y millones de líneas de código, leerlas, compartirlas y mejorarlas, hace que la evolución del software esté a otra velocidad.

El propio Git, como hemos dicho anteriormente, es de código abierto. Un proyecto que, de otra forma, hubiera acabado siendo muy diferente a lo que conocemos hoy en día.

¿Por qué debería contribuir al código abierto?

Podría intentar convencerte quetienes una deuda con el código abiertoya que, de alguna forma, te has beneficiado de él en algún momento de tu vida. Pero voy a evitar jugar esa carta…

En lugar de eso, quiero convencerte de que contribuir de alguna forma al código abierto va a ayudarte a mejorar tu carrera profesionalpor diferentes motivos.

Te hace subir de nivel

Contribuir al código abierto es una forma de mejorar como profesionalen tu sector. No sólo vas a necesitar conocer diferentes tecnologías para hacerlo, sino que además tu código va a ser revisado por otros contribuidores.

Estohará que recibas opiniones sobre tu códigoy otras personas podrán ver qué es lo que está mal y qué puedes hacer para mejorarlo.

Además podrás ver soluciones alternativas y la gente compartirá su experiencia contigo además de forzarte a seguir unas buenas prácticas con tu solución.

Ganas reconocimiento

Hoy en día, muchas personas están buscando una forma de trabajar en el desarrollo de software.¿Cómo puedes demostrar que eres capaz de hacerlo?

Si ya cuentas con años de experiencia, es sencillo. Simplemente explicas en qué lugares has trabajado, atesoras unas cuantas referencias y, quizás, tengas suficiente.

Tus contribuciones aparecerán en GitHub. No hay que obsesionarse con contribuir todos los días pero sí que ofrece algo de gamificación ver que vas rellenando cuadraditos verdes.

Pero si no es el caso, una forma de ganar experiencia con desarrollos que tienen impacto en muchas personas es contribuir al código abierto. Si lo haces en proyectos que son reconocidos, las empresas y posibles futuros clientes lo tendrán en cuenta como algo a valorar positivamente.

Impacto en la comunidad

Los proyectos de código abierto dan servicio a millones de personas y ayudan a cientos de miles de proyectos cada día. La propiaNASAescribió un artículo en julio de 2021 donde explicabalos proyectos de código abierto que habían ayudado al helicóptero Ingenuity a aterrizar en Marte²⁰.

²⁰https://www.jpl.nasa.gov/news/meet-the-open-source-software-powering-nasas-ingenuity-mars-helicopter

GitHub otorgó una insignia a las personas que habían contribuido a proyectos de código abierto que fueron usados por la NASA en la misión Ingenuity

Al final, tampoco hace falta que tu proyecto llegue lejos del sistema solar. Por ejemplo, una biblioteca de UI que usen diferentes aplicaciones web, una herramienta para comprobar el código, una utilidad de testing… y tu trabajo será usado por miles de personas. ¿Cómo suena eso?

¿Cómo empiezo a contribuir a un proyecto de código abierto?

En primer lugar, busca un proyecto de código abierto que te interese. Si no lo encuentras, puedes crear uno… aunque el impacto que puedes tener es muy pequeño al principio y vas a echar en falta elfeedbackdel resto de personas.

Si no lo tienes claro, te recomiendo que visites la página deGood First Issue²¹. Esta página te permite buscar proyectos de código abierto que requieren ayuda y que han etiquetado algunas tareas como fáciles para gente que quiera contribuir por primera vez en el código abierto.

Puedes filtrar por diferentes lenguajes comoJavaScript,GooPython.

Good First Issue te ofrece errores sencillos de arreglar en centenares de repositorios reconocidos

Una vez tengas claro el proyecto al que vas a contribuir, es el momento de crear un forkdel mismo.

^²¹ https://goodfirstissue.dev/

¿Qué es un fork?

Unforkesunacopiadeunproyectoquehatomadocomobaseuncódigofuente que ya existía. La copia, entonces, puede recibir modificaciones que no han sido aprobadas en el código original y puede ser mantenido por personas distintas, de forma que su desarrollo puede tomar una dirección distinta.

La palabra no tiene nada que ver con tenedor pero, por si te sirve para recordarlo, puedes pensar en cada terminación del tenedor que va a un lado diferente…

Si te preguntas por qué se usa la palabraforktienes que saber que, en inglés, la traducción no sólo significatenedor. En realidad, la palabra se usa para referirse también a bifurcaciones, dividir en ramas e ir por partes separadas. Y se conoce ese uso de la palabra desde el siglo XIV. De esta forma, en el mundo del desarrollo, se empezó a usar para referirse a la operación de crear procesos que eran copias de si mismo, algo muy típico en Unix. Más adelante empezó a usarse también para referirse a divergir código en sistemas como Git.

Cuando hablamos de Git, unforkes, literalmente, copiar un repositorio y evolucionar el código en ese repositorio sin afectar o tener en cuenta el original.

Muchas veces se puede confundir un fork con un clone pero no son lo mismo. El fork crea un repositorio en la nube dónde tú tienes todos los permisos. El clone hace una copia local de un repositorio donde tú puedes tener, o no, los permisos

La diferencia entreclonarun proyecto y hacer unforkes que al hacer clone simplemente estamos creando una copia local del proyecto original, manteniendo el repositorio remoto intacto. Con unforkestamos creando una copia remota del proyecto, con nuevos permisos y, por lo tanto, una nueva dirección.

¿Por qué haríamos algo así? Pues bien, puede ser por diferentes motivos:

El proyecto original de código abierto ha sido abandonado y no tenemos privilegiosparaenviarnuevocódigo. De esta forma, cuando creamos un fork, podemos generar una copia del código original y publicar nuevas versiones usando un nuevo nombre. - El proyecto original no está de acuerdo con cambios que queremos aplicar. Así, al crear un fork, podemos hacer los cambios que consideremos sin importar ni impactar al original. Un ejemplo de esto fue elforkque se realizó de Node.js en su día para crear io.js (hoy en día deprecado). - No tenemos permisos para enviar código al proyecto original. Al crear un fork, podemos crear una Pull Request que nos permita enviar cambios al proyecto original. Esto sería evolucionando la copia y, después, enviando una petición de cambios al original con el nuevo código.

Justamente, por esta última razón, es que vamos a necesitar crear un fork para poder contribuir al proyecto.

Creando nuestro primer fork

¡Una cosa! En este curso nos enfocamos en GitHub, que es el servicio de alojamiento de repositorios más grande del mundo. Sin embargo esta operación puede ser ligeramente diferente en otros servicios como BitBucket y GitLab. Sería imposible cubrirlos todos pero lo aprendido aquí será muy similar a cómo se haría en otros servicios.

Para crear un fork debemos acceder a la página del repositorio original. En este caso, vamos a acceder alrepositorio dónde se encuentra la documentación y el blog de Google Chrome.²².

^²² https://github.com/GoogleChrome/developer.chrome.com

Al entrar al repositorio, veremos que tenemos un botón que nos invita a hacer un Fork del repositorio

Como verás, en la parte superior derecha, existe una botonera dónde podemos suscribirnos a los cambios del repositorio (Watch), crear un fork del mismo (Fork) o guardar el repositorio en favoritos (Star). Al lado de cada uno, el número indica el número de personas que han realizado esa misma acción.

Hacer clic enForkse iniciará un proceso de unos pocos segundos. Una vez finalizado, se abrirá una nueva página donde podremos ver el repositorio que hemos creado.

Aunque el repositorio se parece mucho al original, existen algunas diferencias importantes que nos indican que el fork ha sido un éxito y que nos encontramos ante un repositorio diferente

Si revisas la imagen, verás que hemos indicado diferentes puntos importantes. Vamos a explicarlos.

Ahora el repositorio te pertenece. Por eso ha cambiado la organización anterior (GoogleChrome) por tu nombre de usuario (tu-usuario). Esto no es sólo un cambio visual. Significa que con estos de permisos de administración puedes hacer lo que quieras con este repositorio. 2. Un mensaje pequeñito nos indica que este repositorio es un fork de otro. En este caso deGoogleChrome/developer.chrome.com. De esta forma existe una relación entre los repositorios y cualquier persona puede acceder al original con el enlace. 3. Un mensaje nos indica que la rama en la que nos encontramos está sincronizada con la misma rama del repositorio original. En este caso la rama main. También nos podría decir si hemos hecho commits en nuestro repositorio que no están en la rama del repositorio original o, al revés, que el repositorio original tiene commits que nuestroforkno tiene para esa rama.

¿Quieres hacer un fork desde la terminal? Más adelante, en la sección GitHub CLI, hablamos sobre el uso del comando gh de GitHub. Este comando te puede simplificar mucho la vida si no quieres tener que visitar la página de GitHub para realizar ciertas acciones. En este caso para hacer un fork de un repositorio podrías simplemente ejecutar gh repo fork https://github.com//.git —clone.

¿Cómo hago una Pull Request al proyecto original?

Como hemos dicho antes, al hacer unforkpodemos tener diferentes objetivos. El más común es poder contribuir al repositorio originaly esto lo haríamos a través de unaPull Request.

UnaPull Request, o de forma abreviadaPR, es una petición de cambios que se envíaalrepositoriooriginal. Estos cambios que queremos llevar a cabo los tenemos que agrupar en commits, en una rama, en nuestro fork. Con esos cambios podremos crear nuestra petición.

Como bien dice el nombre, es una petición. Las peticiones se pueden aceptar o denegar. Si la petición es aceptada, el cambio se aplica al repositorio original. Si no, el cambio se descarta. A veces es posible que En la secciónBuenasprácticas vas a encontrar una serie de consejos que te ayudarán a crear una Pull Request para tener más posibilidades de que sea aceptada y tus cambios fusionados.

# primero nos clonamos el fork

$ git clone git@github.com:tu-usuario/developer.chrome.com.git

# ahora podemos acceder a la copia local
$ cddeveloper.chrome.com

# para empezar a trabajar, creamos una rama nueva
$ git switch -c add-spanish-translations
Switched to a new branch 'add-spanish-translations'

# hacemos los cambios que queramos en el editor

$ code.

# los añadimos a la fase de preparación
$ git add.
# hacemos un commit
$ git commit -m "Add spanish translations for Chrome 101"
[add-spanish-translations d2b217d8] Add spanish translations for Chrome
101
1 file changed, 1 insertion(+), 1 deletion(-)

# hacemos push de la rama al repositorio remoto
$ git push origin add-spanish-translations

Enumerating objects: 15 , done. Counting objects: 100 % ( 15 /15), done. Delta compression using up to 10 threads Compressing objects: 100 %( 8 /8), done. Writing objects: 100 % ( 8 /8), 692 bytes | 692 .00 KiB/s, done. Total 8 (delta 6 ), reused 0 (delta 0 ), pack-reused 0 remote: Resolving deltas: 100 % ( 6 /6), completed with 6 local objects. remote: remote: Create a pull request for ‘add-spanish-translations’ on GitHub ** by visiting: remote: https://github.com/tu-usuario/developer.chrome.com/pull/new/a ** dd-spanish-translations remote: To github.com:tu-usuario/developer.chrome.com.git * [new branch] add-spanish-translations -> add-spanish-translat ** ions

Al hacerpusha nuestro repositorio remoto, nos indica que podemos crear unaPull Requestvisitando laURL que nos ha indicado en la terminal²³.

Al visitarla nos vamos encontraremos una pantalla como esta:

^²³ https://github.com/tu-usuario/developer.chrome.com/pull/new/add-spanish-translations

Al crear una petición de cambios de un fork, GitHub ya nos ofrece hacerlo

Vamos a repasar los puntos clave de la imagen:

Arriba nos indicasobre qué repositorio estamos operando. Si te fijas bien, aparece GoogleChrome/developer.chrome.com. Esto significa que estaríamos haciendo una petición de cambios al repositorio original y no al fork. El fork es tu-usuario/developer.chrome.com. 2. Esta esla acción que queremos realizar. Crear unaPull Requestcomparando entre dos ramas de dos repositorios diferentes. 3. Aquí podemos elegirel repositorio remoto al que le queremos hacer la petición de cambios y a qué rama. Por defecto nos ha seleccionado el repositorio original pero podríamos hacer la petición a cualquier fork (incluso el nuestro mismo) y a cualquier rama disponible. 4. Estos son los cambios que queremos hacer. Aquí estamos indicando que los cambios que hemos hecho en nuestro fork en la rama add-spanish-translations son los que queremos llevar al repositorio original.

El título de la petición de cambios. Aparecerá en la lista de Pull Requests del repositorio original. 6. La descripción. En este caso ya aparecía algo escrito. ¿Por qué? Porque el repositorio original tiene configurada una plantilla por defecto. Esto puede variar dependiendo de cada repositorio y es útil para asegurarte que todas las peticiones siguen una estructura.

Una vez que hayas completado la información tendrás que pulsar el botón verde Create Pull Request, se sitúa debajo del cuadro de texto para la descripción.

Marcar tu Pull Request como Borrador (Draft)

Es interesante que conozcas también la posibilidad de crear borradores de PRs. De esta forma podrás crear una petición de cambios que está todavía con trabajo en progreso. Que se trata de un borrador (draft).

Es útil porque de esta forma das visibilidad a los cambios que quieres realizar, puedes empezar a recibir comentarios pero dejas bien claro que todavía no está terminada (y, por lo tanto, no es posible fusionarla incluso aunque personas con permisos del repositorio original quieran).

Pulsa la flecha al lado del botón al crear la Pull Request y te aparecerá una opción para marcar la petición como borrador (draft)

Hasta que no se marque la Pull Request como lista no será posible fusionarla.

Otra forma de hacer la Pull Request

¿Has perdido la URL y ahora no sabes cómo hacer la Pull Request? No te preocupes, GitHub tiene una manera para que siempre puedas crearla fácilmente.

Para ello sólo tienes queir a tuforken GitHub²⁴. Allí seleccionas la rama en la que has hecho los cambios con los que quieres crear laPR.

^²⁴ https://github.com/tu-usuario/developer.chrome.com

En el listado de ramas, selecciona la que quieres enviar como Pull Request al repositorio original.

Una vez la seleccionas, la vista del repositorio cambiará para reflejar los archivos que tienen en la rama.

Al entrar en una rama en nuestro repositorio remoto, tendremos información sobre su sincronización respecto al repositorio original y un botón para iniciar la Pull Request

Aquí podrás ver cómo la rama de nuestro fork tiene el historial decommits sincronizado respecto al repositorio original. En este caso nos dice que hemos hecho 10 commits que están por delante del HEADdel repositorio original pero que hay 43 commits que han hecho en la ramamaindel repositorio original y nosotros no los tenemos.

Esos 10 commits son justamente los que vamos a querer llevar en nuestra Pull Request. Es totalmente normal que existan estas divergencias.

Respecto a los 43 que no tenemos nosotros… ¿qué hacemos? Dependedelcontenido de estos commits si es algo que nos afecta o no. Si, por ejemplo, son commit que han modificado los mismos archivos que nosotros, vamos a tener que hacer un mergepara poder converger. Si no tocan los mismos ficheros, podremos continuar sin problemas.

Este es el botón al que tenemos que darle para que nos aparezca de nuevo la ventana para crear nuestra Pull Request. Al hacerlo, nos aparecerá el siguiente diálogo:

Nos vuelve a recordar que tenemos commits que están por delante y nos invita a crear nuestra petición de cambios

Si nuestra rama no tuviese commits que fuesen por delante del HEAD del repositorio original, no tendríamos que hacer nada. No podríamos hacer una Pull Request porque no tenemos ningún cambio que llevar.

¿Cómo puedo sincronizar mi fork con el repositorio original?

Como hemos visto antes, nuestro fork se había quedado por detrás del repositorio original.¿Cómo hacemos para que nuestro fork no se quede obsoleto al poco tiempo?¿Hay que borrarlo y volverlo a crear? No, no es necesario. Lo que tenemos que hacer es actualizarlo y ya está.

Usando la terminal

Ya sabes que me gusta enseñarte a usar y entender los comandos de Git en la terminal. Ysincronizar un fork no iba a ser una excepción.

Además, ahora verás por qué es interesante poder tener más de un repositorio remoto enlazado a un mismo repositorio local.

Cuando ejecutamos el comando git remoteen la terminal, nos aparece una lista de repositorios remotos que tenemos enlazados a nuestro repositorio local.

Normalmente nos aparece sólo el repositorio remotooriginque es el que estamos usando. En nuestro caso nos eltu-usuario/developer.chrome.comque es el que estamos usando.

$ git remote --verbose

origin git@github.com:tu-usuario/developer.chrome.com.git(fetch)
origin git@github.com:tu-usuario/developer.chrome.com.git(push)

Como vemos, nuestro repositorio local está enlazado a nuestro fork a través del alias originpero lo que queremos es justamente traer los cambios del repositorio original… Así que vamos a tener que añadirlo entre los repositorios remotos.

Normalmente cuando se añade el repositorio remoto original a un fork se le llama upstream. Es una convención que se usa en muchos repositorios de desarrollo pero puedes llamarle como prefieras.

# añadimos el repositorio remoto original

git remote add upstream git@github.com:GoogleChrome/developer.chrome.co
m.git

Ahora podemos ver que el repositorio remotoupstreamestá enlazado a nuestro fork.

$ git remote --verbose

origin git@github.com:tu-usuario/developer.chrome.com.git(fetch)
origin git@github.com:tu-usuario/developer.chrome.com.git(push)
upstream git@github.com:GoogleChrome/developer.chrome.com.git(fetch)
upstream git@github.com:GoogleChrome/developer.chrome.com.git(push)

origin -> nuestro fork
upstream -> el repositorio original

¡Listo! Ya estamos preparados para sincronizar nuestro fork con el repositorio original. Para eso, sólo necesitamos usar git pull. Le indicamos que queremos descargar e integrar los cambios de la ramamaindel repositorio original al repositorio local de nuestro fork.

$ git pull upstream main

From github.com:GoogleChrome/developer.chrome.com
* branch main -> FETCH_HEAD
b7ff3d9e..29452bbf main -> upstream/main

Removing site/en/docs/devtools/css/print-preview/index.md Removing site/en/100/100.11tydata.js Removing site/_data/banner.yml Merge made by the ‘recursive’strategy.

.cloudbuild/deploy.yaml | 16 +-
.eleventy.js | 29 +-
.github/chrome-devrel-bot.json | 49 ++-
redirects.yaml | 7 +
site/_data/authorsData.json | 29 +-
site/_data/banner.yml | 6 -
site/_data/docs/devtools/toc.yml | 7 +-

Ahora estos cambios están en nuestro repositorio local. Para llevarlos a nuestro fork, podemos usar git push.

$ git push origin main

Enumerating objects: 10 , done. Counting objects: 100 % ( 10 /10), done. Delta compression using up to 10 threads Compressing objects: 100 %( 4 /4), done. Writing objects: 100 % ( 4 /4), 470 bytes | 470 .00 KiB/s, done. Total 4 (delta 3 ), reused 0 (delta 0 ), pack-reused 0 remote: Resolving deltas: 100 % ( 3 /3), completed with 3 local objects. To github.com:tu-usuario/developer.chrome.com.git d2b217d8..f6f10183 main -> main

Ten en cuenta que esto tendrás que hacerlo también en otras ramas en las que estuvieses trabajando. Si no lo haces, las ramas que hayas creado ya en tu fork se quedarán también por detrás del historial de commits de la ramamaindel repositorio original.

Usando la UI de GitHub

“Demasiado texto”quizás has pensado al ver la sección anterior. En realidad, una vez que lo entiendes, es bastante mecánico pero es posible que te parezca más fácil, y objetivamente lo es, darle a un botón directamente en la UI de GitHub. Por ello, puedes ir a la página de tu fork, seleccionar la rama que quieres sincronizar y simplemente darle al botónFetch upstream. Se abrirá un diálogo que te permitirá descargar y fusionar los cambios de la rama principal del repositorio original.

Tan fácil como darle a un botón para actualizar la rama de tu fork

Verás que si tu rama está totalmente sincronizada, al abrir el diálogo te lo dirá y el botón estará desactivado.

¿Entonces por qué te he explicado todo el rollo anterior? Bien. Lo primero es porque esto es el camino feliz. Un camino en el que no te encuentras conflictos y todo funciona perfectamente. Pero si tienes conflictos al hacer la fusión, vas a tener que lidiar con ellos y eso es mejor hacerlo usando los comandos de la terminal y un editor.

Por otro lado, de esta forma entiendes qué mecanismos hay detrás de ese botón mágico de GitHub.

¿Con qué puedo contribuir a un proyecto?

Ahora que ya sabes cómo hacer y sincronizar forks y crear peticiones de cambios… Es posible que estés pensando:“Oh, qué bonito es todo esto, pero mi nivel no es lo suficientemente bueno para poder hacerlo.”

No te culpo. Yo lo he pensado docenas de veces. A todos nos pasa. Da vértigo participar en proyectos de código abierto, especialmente aquellos proyectos que son muy importantes para la comunidad o de personas que admiras.

Algunas ideas para que te animes a contribuir a proyectos de código abierto, sin necesidad de ser experto en programación o teniendo que crear soluciones de muchas líneas de código, podrían ser:

Solucionar errores ortográficosque existan en el README, documentación o comentarios. Son peticiones de cambio pequeñas, sin prioridad alta, que no comportan mucho esfuerzo ni entender muy bien todo el código. - Muchas veces, especialmente proyectos grandes, buscantraductores para la documentación. Esa es una muy buena oportunidad ya que, al mismo tiempo que contribuimos, vamos entendiendo mejor el proyecto. - Añadir testses una forma excelente de contribuir. Consigues muchas cosas: haces que el código sea más mantenible, de mejor calidad y es una contribución que es muy difícil de rechazar. Además, es una forma perfecta para entender el código. - Al final puedes incluso contribuir a un proyecto de código abierto sin hacerPull Request. Puedes ir a la sección deIssuesy ayudar a cribar los problemas que la gente va presentando al repositorio. Muchas veces son peticiones de ayuda o necesitan una buena demostración para que las personas que mantienen el proyecto puedan entender mejor el problema.

Todos hemos empezado por algún sitio. Anímate.