> whoami --open-sourceLlevo varios años escribiendo código, y solo ahora me he dado cuenta de un error que arrastro desde el principio: cero contribuciones a proyectos open source. Me daría de cabezazos contra la pared si sirviera de algo.
En ningún equipo, con ningún jefe, líder técnico o compañero, salió el tema. Repositorios sí, desde el primer día. Commits, todos. Pull requests, los menos, y cuando llegaban solían pasar sin revisión real, o servir de excusa para que alguien luciera criterio a costa de otro. Ni ejemplo a seguir ni incentivo real. Recuerdo un PR esperando revisión varios días, reclamarlo, y que mi responsable me dijera que me lo autoaprobara yo misma. Esa es de las red flags que avisan de que ahí no vas a mejorar como desarrolladora de software.
Así que este post no es una lección desde la experiencia. Es la guía que me estoy armando para empezar a contribuir a open source, documentada aquí por si te sirve para el tuyo también.
Vamos por partes.
Qué es Open Source (y qué no es)
Según la [Open Source Initiative], organización que mantiene la Definición de Open Source desde 1998, un software es «de código abierto» cuando cumple algo más que «puedes ver el código». Tiene que ser libremente redistribuible, dar acceso al código fuente, permitir modificarlo, y no restringir para qué lo usas, incluido uso comercial. Publicar código en GitHub sin licencia no es open source. Es código visible con derechos de autor intactos.
La diferencia importa porque es la licencia la que te da permiso legal para tocar ese código. Sin ella, estás mirando un escaparate, no una tienda abierta.
> contribuir no es solo escribir código. Es reportar un bug bien documentado, mejorar una documentación confusa, traducir, diseñar, revisar pull requests ajenos. El código es la parte más visible, no la única.
Glosario rápido
Para no perderse en el resto del post:
– fork: tu copia del repo, para trastear sin miedo a romper el original.
– upstream: el repo original, el que manda.
– issue: un problema o petición documentada, la antesala de casi todo.
– pull request (PR): «aquí tienes un cambio, dime si lo quieres».
– draft PR: un PR marcado como borrador, para pedir opinión antes de darlo por terminado.
– squash: aplastar varios commits en uno solo antes de fusionar, para no ensuciar el historial.
– merge conflict: el momento en que Git no sabe cuál de dos cambios quieres y te lo pregunta, mal momento para tener prisa.
– CLA (Contributor License Agreement): documento legal que algunos proyectos piden firmar antes de aceptar tu código.
– maintainer: quien sostiene el proyecto, revisa PRs y decide qué entra y qué no.
Licencias: lo que decide si puedes tocar ese código
Antes de tocar nada conviene saber bajo qué licencia vive el proyecto. Las tres que te vas a encontrar todo el rato:
MIT es la más usada y la más permisiva. Puedes usar, copiar, modificar, publicar y hasta vender software basado en código MIT. El único requisito es mantener el aviso de copyright original.
Apache 2.0 se mueve en la misma filosofía que MIT pero añade algo que MIT no tiene: una cesión explícita de patentes. Si alguien contribuye código cubierto por una patente propia, Apache 2.0 concede permiso explícito para usar esa patente. Más peso legal, mismo espíritu permisivo.
GPL es copyleft: si distribuyes o modificas software GPL, tienes que liberar el código fuente de tu versión bajo esa misma licencia. Es la que usa el kernel de Linux, y es la razón por la que no puedes coger código GPL, meterlo en un producto cerrado y venderlo sin más.
Ninguna de las tres te impide contribuir. Lo que cambia es qué puedes hacer después con el resultado, y eso conviene saberlo antes de escribir la primera línea.
Por qué importa (con números, no con fe)
El reporte [Octoverse 2025 de GitHub] registró 1.120 millones de contribuciones en repositorios públicos durante el año, un 13% más que el anterior, con 518,7 millones de pull requests fusionados. Cada segundo se une un desarrollador nuevo a la plataforma.
Esto no es un pasatiempo de nicho, es la infraestructura invisible sobre la que corre buena parte del software que usas a diario, del framework de tu stack al linter que corre en tu CI.
A nivel de comunidad, contribuir mantiene vivos proyectos de los que dependemos todos. La mayoría del software libre lo sostiene un grupo pequeño de mantenedores, muchos sin remunerar. Cada issue cerrado, cada typo corregido, es una carga menos sobre esas pocas personas.
A nivel personal, contribuir es de las pocas formas de tener código real, revisado por desarrolladores que no conoces, en un repositorio con historial público. Sirve como portafolio verificable: cualquiera puede ver el diff, leer la discusión del PR y juzgar la calidad del trabajo sin que tú tengas que venderlo. Y aprendes a leer código ajeno bajo convenciones que no elegiste, que es una habilidad distinta a escribir el tuyo desde cero.
Contribuir a Open Source sin escribir código
Ya lo apunté arriba, pero merece su propio espacio: el código es la parte más visible, no la que más falta hace en muchos proyectos.
Documentación: tutoriales nuevos, guías desactualizadas que nadie corrige, ejemplos de uso que faltan.
Traducción: llevar documentación o interfaz a otro idioma, ampliar quién puede usar el proyecto sin depender del inglés.
Triage de issues: leer, etiquetar, pedir la información que falta, cerrar duplicados. Trabajo invisible que le ahorra horas al mantenedor.
Tests: escribir casos de prueba para funcionalidad que no los tiene, sin tocar la lógica de negocio.
Según [estimaciones sobre patrones de contribución casual], alrededor de un 30% de las contribuciones son documentación, corrección de typos o traducciones. No es una contribución de segunda categoría, es una puerta de entrada tan válida como cualquier PR de código.
Cómo elegir el proyecto correcto
Elegir bien el proyecto pesa tanto como elegir bien el issue. Algunos criterios objetivos antes de comprometerte:
Actividad reciente: commits e issues cerrados en las últimas semanas, no hace un año.
Tiempo de respuesta: un proyecto sano suele revisar PRs pequeños en menos de 48 horas y fusionarlos en menos de 5 días. Si el último PR abierto lleva tres meses sin respuesta, es una señal.
Reparto de la comunidad: si el 100% de los commits los firma una sola persona, es un proyecto personal disfrazado de open source. Mejor buscar uno donde una parte real de los PRs vengan de gente fuera del equipo core.
Tono en los issues: si las respuestas a otros contribuidores son secas u hostiles, no va a ser distinto contigo.
Comparar tres o cuatro candidatos con estos filtros antes de comprometer tiempo evita el desgaste de invertir horas en un proyecto que no va a fusionar nada.
Herramientas antes de empezar a contribuir a Open Source
Antes del primer fork, hay una lista corta de cosas que conviene tener resueltas.
Git instalado y configurado con tu nombre y email, los que van a quedar asociados a cada commit para siempre.
Una SSH key añadida a tu cuenta de GitHub, para no escribir usuario y contraseña en cada push. Se genera y se sube siguiendo la [guía oficial de GitHub Docs sobre autenticación SSH].
Firma de commits, opcional pero recomendable. [GitHub verifica firmas GPG, SSH o S/MIME] para marcar un commit como «verified» y confirmar que viene de ti. Configurar la firma con SSH es más simple que con GPG, aunque GPG tiene a su favor que la clave se puede hacer expirar o revocar cuando ya no se usa.
GitHub CLI (gh), no imprescindible pero ahorra pasos: forkear, clonar y abrir un PR desde terminal sin pasar por el navegador.
Nada de esto es obligatorio para el primer PR, pero configurarlo una vez evita fricciones en el siguiente.
Tutorial: mi primer pull request, paso a paso
Este es el flujo que voy a seguir, tal como lo documenta [GitHub Docs]. Lo dejo aquí paso a paso para no improvisar cuando llegue el momento.
1. Elige el repositorio y lee las normas antes de tocar nada
Busca el archivo CONTRIBUTING.md en la raíz del repo. Casi todos los proyectos serios tienen uno con las reglas del juego: cómo formatear commits, qué tests correr, si necesitas firmar un CLA.
Revisa también si hay un CODE_OF_CONDUCT.md, la mayoría de proyectos grandes adoptan el [Contributor Covenant], el código de conducta más extendido en open source, adoptado por 9 de los 10 proyectos más grandes del mundo. Saltarse esto es la forma más rápida de que cierren tu PR sin leerlo.
2. Fork
No tienes permiso de escritura sobre el repo original, así que creas tu propia copia. Botón «Fork» arriba a la derecha.
> gh repo fork usuario/proyecto --clone3. Clona tu fork en local
> git clone https://github.com/tu-usuario/proyecto.git
> cd proyecto4. Sincroniza tu fork antes de currar
Un fork se queda desactualizado en cuanto el repo original avanza. Antes de crear rama, conecta el repo original como remoto y trae los últimos cambios, para no partir de una base vieja ni arrastrar conflictos evitables.
> git remote add upstream https://github.com/usuario-original/proyecto.git
> git fetch upstream
> git merge upstream/main5. Crea una rama con nombre descriptivo
Nunca trabajes directo sobre main.
> git checkout -b fix/typo-en-readme6. Haz el cambio, commitea, sube
> git add .
> git commit -m "fix: corrige typo en sección de instalación"
> git push origin fix/typo-en-readme7. Abre el pull request
Desde GitHub, título claro, descripción de qué cambia y por qué. Si responde a un issue existente, referencia con `Closes: #15`. Eso vincula el PR al issue y lo cierra automáticamente al fusionarse.
8. Espera revisión
Un mantenedor revisa, puede pedir cambios, puede tardar días o semanas. Es normal. No es rechazo personal, es que alguien sin obligación contigo está dedicando su tiempo libre a mirar tu código.
Errores típicos de primerizo
PR gigante en vez de pequeño: los cambios enormes son más difíciles de revisar y con más probabilidad de acabar cerrados con un «divide esto en PRs más pequeños».
No leer el CONTRIBUTING.md ni la plantilla de PR: la plantilla existe para que el mantenedor tenga lo que necesita sin tener que perseguirte a preguntas.
Discutir el enfoque dentro del PR en vez de en el issue: la conversación de diseño va antes, en el issue. El PR es para revisar código, no para debatir si la idea tiene sentido.
Ignorar el CI en rojo: un pipeline que falla y nadie mira es la forma más rápida de que el PR se quede sin revisar indefinidamente.
No sincronizar la rama con main antes de pedir review: un PR desactualizado genera conflictos que el mantenedor no tiene por qué resolver por ti.
Hacktoberfest: la excusa anual para empezar a contribuir a Open Source
Si necesitas una fecha límite para dejar de posponerlo, existe una hecha a medida. [Hacktoberfest] es la iniciativa anual de DigitalOcean que corre cada octubre. Te registras entre el 15 de septiembre y el 31 de octubre, y el objetivo son pull requests fusionados en proyectos de GitHub o GitLab etiquetados con el topic hacktoberfest. En la edición 2025 el listón estaba en 6 PRs aceptados para completar el reto, con insignias digitales por el camino y camiseta física para quienes llegan primero. Las reglas exactas de cada año se publican en hacktoberfest.com, conviene revisarlas antes de lanzarse porque cambian de una edición a otra.
No hace falta esperar a octubre para contribuir, pero tener una fecha y un contador público ayuda cuando el freno es la procrastinación, no la falta de ganas.
Truco para empezar sin morir en el intento
Busca proyectos que quieren gente nueva, no cualquier proyecto. Existen webs que agregan justo eso:
– [Good First Issue] filtra issues etiquetadas como aptas para primerizos en proyectos populares.
– [Up For Grabs] lista proyectos cuyos mantenedores curan tareas específicamente para nuevos contribuidores.
– La etiqueta [`good-first-issue` en GitHub Topics] hace lo mismo directamente en la búsqueda de GitHub.
Practica el flujo completo sin miedo a romper nada. [first-contributions] es un repositorio hecho exactamente para eso: seguir fork, clone, edit, PR sobre un proyecto donde equivocarse no tiene consecuencias.
Empieza pequeño, literalmente. Typos, enlaces rotos, documentación desactualizada, mensajes de error poco claros. No es menos válido que arreglar un bug complejo, es la puerta de entrada que además menos tiempo de revisión le exige al mantenedor.
Lee antes de escribir. El historial de issues y PRs cerrados te dice cómo habla ese proyecto, qué rechazan, qué esperan. Es la mejor documentación no escrita que vas a encontrar.
Lee el código de conducta antes que el código fuente. Te dice qué tono espera esa comunidad y cómo se gestionan los conflictos, información que en mi experiencia interna nunca existió por escrito y aquí sí.
No lo tomes como examen. Un «cambios solicitados» en tu primer PR es la review funcionando, no un juicio sobre si sabes programar. Y si nadie contesta en semanas, no es personal, la mayoría de mantenedores hacen esto en su tiempo libre.
Sé específico en el issue antes de ponerte a picar código. Comenta que quieres trabajar en él y espera confirmación si el proyecto lo pide. Evita el choque de dos personas resolviendo lo mismo en paralelo.
Qué pasa si tu PR es rechazado
Un PR cerrado no significa que el código fuera malo. Puede ser que no encaje con la dirección del proyecto, que ya exista un cambio similar en curso, o simplemente que falte contexto en la descripción.
La diferencia con las revisiones internas que describí al principio está en la respuesta esperada: aquí el comentario es sobre el código, no sobre ti, y la conversación es pública, así que hay poco margen para la crítica gratuita sin que se note.
Si piden cambios, se responde punto por punto: el que tenga sentido se aplica, el que no se rebate con argumentos, sin dramatismo.
Si no hay respuesta en semanas, se espera. No se insiste antes de una o dos semanas, y entonces sí, un comentario breve y educado preguntando si el PR sigue en pie.
Si lo cierran sin más, se puede preguntar si un enfoque distinto sería bienvenido. Un simple «gracias por el feedback» y seguir adelante también es una respuesta válida.
Ninguna de estas reacciones depende de aguantar lo que aguanté en revisiones internas mal hechas. Aquí el mecanismo de control es público, y eso ya cambia las reglas del juego.
Por dónde voy a empezar a contribuir a Open Source
Esta es mi shortlist, no una lista genérica de internet:
– [first-contributions] — para hacer el primer PR sin miedo a romper nada, antes de tocar un proyecto real.
– [good-first-issue (DeepSource)] — issues fáciles en proyectos populares, para cuando ya quiera algo con más peso.
– [awesome-for-beginners] — filtrado por lenguaje, así que puedo buscar directo en Java o lo que esté usando esa semana.
– [up-for-grabs.net] — para cuando quiera salir del modo tutorial y buscar un proyecto que de verdad necesite manos.
> primer commit open source: pendiente.