Como Contribuir al Open Source
Como Contribuir al Open Source
Por que contribuir
Contribuir al open source tiene beneficios concretos:
- Mejorar herramientas que usas: encontraste un bug? corrigelo tu mismo
- Desarrollar habilidades: codigo, diseno, escritura, organizacion — hay tarea para todos
- Construir reputacion: todo tu trabajo es publico y demostrable
- Encontrar mentores: trabajar con otros implica explicar y pedir ayuda
- Aprender habilidades blandas: liderazgo, gestion de conflictos, priorizacion
Contribuir no es solo codigo
El error mas comun es pensar que contribuir requiere programar. Las partes no-tecnicas suelen ser las mas descuidadas y las mas valiosas.
Organizacion:
- Organizar meetups o talleres
- Vincular issues duplicados
- Sugerir nuevas etiquetas para issues
Diseno:
- Reestructurar layouts para mejorar usabilidad
- Crear guias de estilo visual
- Disenar logos o arte para el proyecto
Escritura:
- Escribir o mejorar documentacion
- Crear tutoriales
- Traducir documentacion
- Curar ejemplos de uso
Codigo:
- Abordar issues abiertos
- Automatizar configuracion de proyectos
- Mejorar tooling y tests
Soporte:
- Responder preguntas en Stack Overflow, Reddit o Discord
- Revisar codigo de otros contribuyentes
- Ofrecer mentoria a nuevos colaboradores
Segun investigacion de Igor Steinmacher, el 28% de contribuciones ocasionales son documentacion.
Anatomia de un proyecto open source
Roles tipicos
| Rol | Descripcion |
|---|---|
| Autor | Persona u organizacion que creo el proyecto |
| Propietario | Quien tiene acceso administrativo (no siempre el autor) |
| Mantenedores | Responsables de la vision y aspectos organizacionales |
| Contribuyentes | Todos quienes han aportado algo |
| Comunidad | Usuarios que participan o expresan opiniones |
Documentacion esencial
- LICENSE: todo proyecto open source debe tener una. Sin ella, no es open source
- README: explica que hace el proyecto y como empezar
- CONTRIBUTING: tipos de contribuciones necesarias y procesos
- CODE_OF_CONDUCT: normas de comportamiento para participantes
Herramientas
- Issue tracker: discusion de problemas
- Pull requests: revision de cambios
- Foros/listas de correo: discusiones mas amplias
- Chat (Slack, Discord, IRC): conversacion casual
Encontrar un proyecto
Empieza con proyectos que ya usas. Cuando algo te moleste — un bug, documentacion confusa, un enlace roto — actua. El open source esta hecho por personas como tu.
Recursos para descubrir proyectos
- GitHub Explore
- First Timers Only
- CodeTriage
- Up For Grabs
- First Contributions
- OpenSauced
- Good First Issues
Checklist antes de contribuir
Verifica que el proyecto esta activo y receptivo:
- Tiene licencia (archivo LICENSE)
- Commits recientes en la rama principal
- Responden rapido a issues
- Hay discusion activa en issues y PRs
- Se cierran issues y se fusionan PRs
- Los mantenedores son amables en las respuestas
Si ves discusiones largas con muchas guerras de palabras, la energia va al argumento y no al desarrollo. Evita esos proyectos.
Comunicacion efectiva
Reglas basicas
Investiga primero: revisa README, issues abiertos y cerrados, documentacion. Demuestra que intentaste.
- Bien: “No se como implementar X. Revise la documentacion sin resultados”
- Mal: “Como hago X?”
Da contexto: ayuda a otros a entender rapidamente tu situacion.
- Bien: “X no sucede cuando hago Y”
- Mal: “X esta roto. Arreglalo!”
Se conciso: cada solicitud requiere revision de alguien. Menos texto = mas probabilidad de ayuda.
Comunica en publico: no contactes mantenedores por privado a menos que sea informacion sensible. Las conversaciones publicas benefician a todos.
Respeta decisiones: tus ideas pueden diferir de las prioridades del proyecto. Discute y busca compromiso, pero respeta la decision final. Siempre puedes hacer tu propio fork.
Abrir un issue
Abre un issue para:
- Reportar errores que no puedes resolver
- Discutir temas de comunidad, vision o politicas
- Proponer nuevas caracteristicas
Si quieres trabajar en un issue existente, comenta indicando que lo tomaras para evitar duplicacion. Si el issue es antiguo, pregunta primero si sigue vigente.
Abrir un pull request
Abre un PR para:
- Correcciones pequenas (typos, enlaces rotos, errores obvios)
- Trabajo previamente discutido en un issue
Los PRs no necesitan estar terminados. Puedes abrir un draft PR marcado como “WIP” para que otros vean tu progreso.
Pasos en GitHub
- Fork del repositorio y clona localmente
- Crea una rama para tus cambios
- Referencia issues relacionados (ej: “Closes #37”)
- Incluye screenshots si hay cambios visuales
- Ejecuta tests existentes y crea nuevos si aplica
- Sigue el estilo del proyecto (indentacion, comentarios, convenciones)
Que pasa despues
Sin respuesta
Si no recibes respuesta en una semana, responde educadamente pidiendo revision. Si persiste el silencio, no desanimes — busca otro proyecto. Esto senala que no debes invertir demasiado sin engagement comunitario previo.
Piden cambios
Es normal que pidan modificaciones. Responde activamente. Abrir un PR y desaparecer es de mal gusto. Si tus circunstancias cambian, informa al mantenedor para que asigne a alguien mas.
Rechazo
Tu contribucion puede no aceptarse. Si no entiendes por que, pide retroalimentacion. Respeta la decision. No te vuelvas hostil. Siempre puedes hacer fork.
Aceptacion
Felicidades — contribuiste al open source.
Resumen
- Contribuir no requiere programar: documentacion, diseno, organizacion y soporte son igual de valiosos
- Empieza con proyectos que ya usas
- Verifica que el proyecto sea activo y receptivo antes de invertir tiempo
- Investiga antes de preguntar, da contexto y se conciso
- Respeta las decisiones del proyecto, incluso si no coinciden con las tuyas