El cómo y el por qué del Código Abierto
¿Estás pensando cómo comenzar un proyecto de c&oacut;digo abierto? ¡Felicitaciones! El mundo aprecia tu contribución. Hablemos sobre lo que es un proyecto de código abierto y porqué la gente lo lleva adelante
¿Qué significa “Código Abierto”?
Cuando un proyecto es de código abierto, significa que cualquier persona puede ver, modificar, usar o distribuir tu proyecto para cualquier fin. Estos permisos están reforzados a través de una licencia de código abierto.
“Código Abierto” es poderoso debido a que reduce las dificultades de adopción, permitiendo que las ideas se esparzan rápidamente.
Para entender cómo funciona, imagina a un amigo que organiza una comida, te invita, y llevas una torta.
- Todos prueban la torta (usarlo)
- ¡La torta es un éxito! Te piden la receta, la cuál tú das. (estudiarlo/verlo)
- Un amigo, Pedro, es cocinero, y te sugiere colocar menos azúcar (modificarlo)
- Otro amigo, Juan, te pide permiso para usarlo en una cena que tendrá la próxima semana (distribuirlo)
Realicemos una comparación: un proceso de código cerrado sería ir a un restaurante y pedir una porción de torta. Para ello tendrías que pagar por la misma, y el restaurante muy probablemente no te dará su receta. Si decidieras copiar su torta y venderla bajo otro nombre, el restaurante podría recurrir a acciones legales en contra.
¿Por qué las personas utilizan el “Código Abierto”?
Hay muchas razones por las cuales una persona u organización querrían involucrarse en un proyecto de código abierto. Algunos ejemplos son:
-
Colaboración: Los proyectos de código abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. Exercism, por ejemplo, una plataforma para ejercicios de programación con más de 350 colaboradores.
-
Adopción y remezcla: Los proyectos de código abierto pueden ser usados por cualquiera para casi cualquier própósito. Las personas pueden usarlos hasta para construir otras cosas. WordPress, por ejemplo, comenzaron como un “fork” de un proyecto existente llamado b2.
-
Transparencia: Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de Bulgaria o United States, para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como Let’s Encrypt.
Código abierto no es solamente software. Uno puede “abrir” cualquier cosa, desde conjuntos de datos, hasta libros. Mira esto GitHub Explore para tener otros ejemplos.
¿“Código Abierto” significa gratis?
Una de las cosas que causa confusión es el que el código abierto no cuesta dinero, es decir, es gratuito. Sin embargo, es un subproducto del valor general del “Código abierto”.
Esto es debido a que una licencia open source requiere que cualquiera pueda usar, modificar, y compartir sus proyectos para casi cualquier propósito, y los proyectos en sí mismos suelen ser gratuitos. Si el uso del proyecto cuesta dinero, cualquiera puede legalmente hacer una copia del mismo y usar la versión gratuita en su lugar.
El resultado es que la mayor parte de los proyectos de este tipo son gratuitos, pero “gratuito” no forma parte de la definición del “Código Abierto”. Hay formas de cobrar por estos proyectos en forma indirecta a través de licencias duales o funcionalidad limitada, y al mismo tiempo cumplir con la definición oficial del “Código Abierto”.
¿Debería lanzar mi propio proyecto de Código Abierto?
La respuesta corta es “Sí”, debido a que, sin importar lo que suceda, lanzar tu propio proyecto es una buena forma de aprender acerca de cómo funciona el código abierto.
Si nunca has utilizado este concepto en el pasado, probablemente estés preocupado de lo que otras personas digan, o que no digan nada. Si esto es así, debes saber que no estás solo.
El código abierto funciona como cualquier otra actividad creativa, ya sea escribir o pintar. Puede dar miedo de compartir algo con el mundo, pero la única forma de mejorar es practicar (aún si no tienes una audiencia).
Si no estás convencido todavía, toma un momento para pensar acerca de cuáles serán tus objetivos.
Definiendo tus objetivos
Los objetivos pueden ayudarte a detectar puntos en los que continuar trabajando, a qué decirle que no, y a dónde recurrir por ayuda. Comienza preguntándote, ¿Por qué estoy haciendo “código abierto” a mi proyecto?
No hay nunca una respuesta correcta a esta pregunta. Puedes tener múltiples objetivos para un solo proyecto, o diferentes proyectos con diferentes objetivos.
Si tu único objetivo es mostrar al mundo tu trabajo, quizás no necesites ni quieras contribución, y quizás digas eso en el README. Por otra parte, si quieres ayuda, invertirás tiempo en clarificar la documentación y en hacer sentir a los recién llegados bienvenidos.
A medida que tu proyecto crezca, tu comunidad podrá llegar a necesitar más que solamente el código. Es decir, necesitará que respondas a issues, que revises el código, entre otras tareas importantes en un proyecto de esta clase.
El tiempo que dediques a tareas ajenas a codificar dependerá del tamaño y alcance de tus proyectos, deberías estar preparado, como encargado de mantenimiento, a afrontarlas por tu cuenta o encontrar a alguien que pueda ayudarte.
Si eres parte de una compañia que quiere “abrir” el código de un proyecto, debes asegurarte que el mismo tiene recursos internos que necesitan mejorar. Necesitarás identificar al responsable de mantener el proyecto una vez lanzado, y definir cómo vas a compartir esas tareas con tu comunidad.
Si necesitas un presupuesto dedicado o personal para la promoción, operación y mantenimiento del proyecto, empieza esas conversaciones de forma temprana.
Contribuyendo en otros proyectos.
Si tu meta es aprender cómo contribuir con otros o entender cómo funciona el “código abierto”, considera contribuir en proyectos existentes. Comienza con proyectos que ya has estado usando y que te gustan. Contribuir a un proyecto puede ser tan simple como arreglar “typos” o actualizar documentación.
Si no sabés como comenzar a contribuir, mira esta Guía sobre cómo contribuir.
Lanzando tu propio proyecto de Código Abierto
No hay momento perfecto para abrir el código de tu trabajo. Puedes abrir el de una idea, el de un trabajo en progreso, o después de varios años de ser un proyecto cerrado.
Generalmente, puedes abrir el código de tu proyecto cuando te sientas cómodo de que otras personas vean y te aconsejen sobre tu trabajo.
No importa en qué etapa decidas hacerlo, cada proyecto debe incluir la siguiente documentación.
Como encargado de mantenimiento, estos componentes ayudarán a comunicar tus deseos, manejar tus contribuciones y proteger los derechos legales de cada uno (incluyéndote). Incrementan significativamente tus posibilidades de tener una experiencia positiva.
Si tu proyecto está en GitHub, colocar estos archivos en tu directorio raíz con las recomendaciones de nombrado de los mismos, te ayudará a que GitHub los reconozca automáticamente y muestre a tus lectores.
Eligiendo una licencia
Una licencia de Código Abierto garantiza que otros puedan usar, copiar, modificar y contribuir en tu proyecto sin problemas. Además ayuda a protegerte de situaciones legales complejas. Debes elegir una licencia cuando inicias tu proyecto!
El trabajo legal no es divertido. La buena noticia es que puedes copiar y pegar una licencia existente en tu repositorio. Solo llevará un minuto proteger tu trabajo.
MIT, Apache 2.0, y GPLv3 son las licencias más populares, pero hay otras opciones para elegir.
Cuando creas un nuevo proyecto en GitHub, te dan la opción de seleccionar una licencia. Incluir una licencia de Código Abierto hará tu proyecto efectivamente de Código Abierto.
Si tienes otras preguntas acerca del aspecto legal al manejar proyectos de este tipo, te tenemos cubierto.
Escribiendo un README
Los README hacen más que explicar cómo usar tu proyecto, también explican por qué importa el mismo, y qué pueden hacer los usuarios con él.
Trata de que tu README responda a las siguientes preguntas:
- ¿Qué hace el proyecto?
- ¿Por qué es útil?
- ¿Cómo se debe comenzar?
- ¿Dónde puedo buscar más información? (si es que la necesito)
Puedes usarlo para responder otras preguntas: cómo manejo las contribuciones, cuáles son las metas del proyecto, e información acerca de licencias y atribuciones. Si no quieres aceptar contribuciones, o tu proyecto no está listo para producción, lo escribes.
Algunas veces las personas evitan escribir el README debido a que sienten que su proyecto está incompleto, o qué no quiere contribuciones. Ambas son muy buenas razones para escribir uno…
Para más inspiración, trata de usar @18F’s “Making READMEs Readable” o @PurpleBooth’s README template para escribir un README.
Cuando incluyes un archivo de este tipo en tu directorio raíz, GitHub automáticamente lo mostrará en la página principal del repositorio.
Escribiendo las pautas para contribuir
Un archivo CONTRIBUTING le da información a la audiencia acerca de cómo participar en el proyecto, por ejemplo:
- Cómo archivar un reporte de bug (trata de usar issue and pull request templates)
- Cómo sugerir una nueva funcionalidad/característica.
- Cómo establecer tu entorno y correr pruebas.
Además de detalles técnicos, este archivo es una oportunidad para comunicar tus expectativas, como:
- Los tipos de contribución que esperas
- Tu visión del proyecto (La hoja de ruta)
- Cómo deberían comunicarse (o cómo no) los contribuyentes contigo.
Usando un tono cálido y amigable, y ofreciendo sugerencias específicas para contribuciones puede ayudar a los iniciados a sentirse bienvenidos y ansiosos de participar.
Por ejemplo, Active Admin comienza su guía de contribuciones con:
Primero, muchas gracias por considerar contribuir a Active Admin. Son personas como ustedes las que la hacen una gran herramienta.
En las primeras etapas del proyecto, tu archivo CONTRIBUTING puede ser simple. Siempre debes explicar cómo reportar bugs o issues, y cualquier requerimiento técnico (como tests) para hacer una contribución.
Con el tiempo, quizás debas agregar otras “preguntas frecuentes” a tu archivo. Escribir esta información significa que menos personas te preguntarán nuevamente la misma pregunta.
Para más información sobre este tema, puedes acceder a @nayafia’s contributing guide template o @mozilla’s “How to Build a CONTRIBUTING.md”.
Vincula tu CONTRIBUTING desde tu README, así más personas pueden verlo.Si tu colocas el archivo en tu repositorio, GitHub automáticamente lo vinculará cuando un contribuyente cree un issue o abra un pull request.
Estableciendo un código de conducta.
Finalmente, un código de conducta ayuda a establecer reglas base de comportamiento para los participantes de tus proyectos. Esto es muy deseable si estás lanzando un nuevo proyecto de código abierto para una compañía o comunidad. Un código de conducta facilita un comportamiento en comunidad sano y constructivo, reduciendo tu estrés como encargado de mantenimiento.
Para más información, entra a Guía del Código de Conducta.
Además de comunicar cómo esperas que se comporten los participantes, un código de conducta tiende a describir a quién se aplican las expectativas, cuando apliquen, y qué hacer si una violación a las mismas ocurre.
Como muchas licencias de código abierto, existen estándares emergentes para códigos de conducta para que no debas escribir uno propio. El Contributor Covenant es un código de conducta usado por más de 40000 proyectos de código abierto, incluyendo Kubernetes, Rails, and Swift. Debes estar preparado para redefinir el tuyo cuando sea necesario.
Copia el texto directamente en el archivo CODE_OF_CONDUCT dentro de tu repositorio, en el directorio raíz, y vincúlalo desde tu README.
Dando un nombre y una marca a tu proyecto
La marca es más que elegir un nombre atractivo y un buen logo. Es acerca de cómo hablar de tu proyecto y llegar a la gente.
Eligiendo el nombre correcto
Debes elegir un nombre sencillo de recordar y que en lo posible de una idea de lo que el proyecto hace. Ejemplos son:
Si estás construyendo sobre un proyecto ya existente, usar su nombre como prefijo suele clarificar lo que el mismo hace (ejemplo: node-fetch trae window.fetch a Node.js).
Considera claridad por sobre todo. Los chismes son divertidos,pero recuerda que algunas bromas pueden no ser traducidas otros idiomas o llevadas a otras culturas, con gente que posee diferentes experiencias a las tuyas. Algunos de tus potenciales usuarios pueden ser empleados de la compañía: no debes hacerlos sentir incómodos cuando tienen que explicar tu proyecto en el trabajo!
Evitando conflictos con los nombres
Busca proyectos con el mismo nombre, o similar, especialmente si compartes el mismo ecosistema o idioma. Si tu nombre coincide con algún otro proyecto popular, puede confundir a las personas.
Si quieres una página web, manejo de Twitter, u otros ítems que representen tu proyecto, asegúrate de que puedas asignar el nombre que quieras. En lo posible, reserva tu nombre ahora para estar tranquilo, aunque aún no lo vayas a usar.
Tu nombre no debe infringir ninguna marca (trademark), de ser así la compañía puede pedirte que des de baja a tu proyecto, o puede tomar acciones legales en tu contra. No vale el riesgo.
Puedes verificar WIPO para verificar conflictos de este tipo. Si estás en una compañía, ésta es una de las cosas con las cual tu equipo legal puede ayudar.
Finalmente, haz una búsqueda rápida en Google: ¿Las personas podrán encontrar rápidamente el nombre? ¿En los resultados de búsqueda aparece algo que no quieres que ellos vean?
Cómo escribir y codificar afecta tu marca
Durante el ciclo de vida de tu proyecto, escribirás una serie grande de documentos: README, tutoriales, issues, etc..
Ya sea documentación oficial como casual (un email), tu estilo de redacción debe ser parte de la marca de tu proyecto. Considera cómo será visto por tu audiencia y si es o no adecuado.
Usando un lenguaje inclusivo, puede ir lejos haciendo que tus proyectos reciban de forma más cálida a los nuevos participantes. Mantén un lenguaje simple.
Luego de cómo expresarte, tu estilo a la hora de codificar puede ser importante también. Angular y jQuery son ejemplos de proyectos con un riguroso trato en este sentido.
No es necesario escribir una “guía de estilo” para tus proyectos cuando recién estás comenzando, y quizás hasta descubras que disfrutas al incorporar distintos estilos de codificación en tu proyecto. Pero deberías anticiparte y definir cómo tu redacción y estilo de codificación puede atraer o no a distintos tipos de personas. Define esto al comienzo.
Tu checklist a armar previamente al lanzamiento del proyecto
Estás listo para iniciar tu propio proyecto de Código Abierto. Aquí dejamos un checklist que puede ayudar. ¡Una vez marcadas todas las casillas estás listo para continuar! Clickea “publish”.
Documentación
Code
Personas
Si eres un individuo:
Si eres una compañía u organización:
¡Lo has hecho!
Felicitaciones por abrir el código de tu primer proyecto! Sin importar el devenir, trabajar en público es un regalo a la comunidad. Con cada commit, comentario y pull request, estás creando oportunidades no solo para ti, si no para que otras personas puedan aprender y crecer.
