El código abierto no implica una comunidad pública
(blog.feld.me)- El software de código abierto podía distribuirse incluso antes de (D)VCS mediante páginas HTML, archivos txt, tarballs por FTP y solo un contacto por correo electrónico, y seguía siendo código abierto aunque no existiera una comunidad pública
- Tener una lista de correo o un canal de IRC ya era tener suerte, pero pull request, issues, wiki, core team y Code of Conduct no eran requisitos indispensables del código abierto
- Sourceforge ofreció CVS/SVN y listas de correo casi gratis, lo que facilitó el desarrollo público, y después git ganó la competencia de los DVCS, haciendo que el mundo convergiera en GitHub
- Después de GitHub, mantener proyectos de código abierto pasó a parecerse a un trabajo no remunerado, cargando además con issues, pull requests fuera de alcance, quejas, exigencias y hasta la gestión de grupos de chat, lo que puede llevar al burnout y a perder el control
- Un proyecto no necesita desarrollarse públicamente de forma obligatoria; se puede desactivar el issue tracker y los pull requests, usar un servidor git bare y mantener código abierto con un grupo pequeño de confianza o incluso en solitario
La carga de mantenimiento después de GitHub
- GitHub hizo que mantener código abierto se sintiera para los maintainers como un trabajo no remunerado
- Después de lidiar en el trabajo con tickets, reuniones con stakeholders, roadmaps, política, distracciones, deadlines, métricas, KPI, requerimientos cambiantes, standups, one-on-ones, Agile y Waterfall, al llegar a casa todavía se acumulan las notificaciones del código abierto
- Se amontonan los issues, llegan pull requests que rediseñan el software en direcciones fuera del alcance del proyecto, y aumentan las quejas y las exigencias
- Cuando aparecen grupos de chat y una “comunidad”, el maintainer también termina asumiendo la responsabilidad de manejar personas impacientes y tratar con ellas uno a uno
- Como resultado, el código abierto se convierte en un segundo trabajo, y el maintainer puede sufrir burnout e incluso perder el control y la dirección de su propio proyecto
Volver a operar de forma simple
- Algunos proyectos son tan grandes y complejos que necesitan gestión de equipos, pero eso es la excepción, no el caso general
- Si te molesta que personas nuevas y bots de IA te quiten la atención, puedes volver a la forma de antes
- Puedes desactivar el issue tracker y los pull requests, o montar un servidor git bare para publicar el código
- También puedes trabajar con un grupo pequeño de personas que realmente conoces y en quienes confías, o llevar el proyecto completamente por tu cuenta
- No hace falta permitir que desconocidos invadan tu espacio, y tampoco son obligatorios un Code of Conduct performativo ni una política sobre LLM
- El hecho de que algo sea “código abierto” no significa que deba desarrollarse públicamente
- Puedes usar las herramientas que quieras, crear lo que te guste y hasta hacer un code drop a las 2 de la mañana en Navidad, sin tener que dejarte arrastrar a un sistema operativo que parece una mezcla de incubadora tecnológica y guardería
1 comentarios
Opiniones en Lobste.rs
Por ideas como esta se creó https://casuallymaintained.tech/ y me encanta
El ejemplo más famoso es SQLite, que rechaza contribuciones externas
Considerando que se usa incluso en aplicaciones de misión crítica como los aviones de Airbus, es una política razonable
SQLite es open source, así que puedes copiarlo cuanto quieras y usarlo sin restricciones, pero no es un proyecto de contribución abierta (
open-contribution)Para mantener SQLite en el dominio público y evitar que se mezcle con código privativo o con licencia, no aceptan parches de personas que no hayan presentado una declaración cediendo su contribución al dominio público
Es una perspectiva bastante fresca
Tal vez el autor tenga razón y le estemos exigiendo demasiado a quienes mantienen proyectos
Puede que lo que esté roto no sea el open source en sí, sino la inflación de expectativas sobre lo que debería ofrecer
La dimensión social de GitHub también puede influir. Mientras más estrellas y más usuarios generales tenga un proyecto, mayor es la presión por satisfacer a la gente nueva que llega a verlo
Se vuelve especialmente riesgoso cuando el interés y las demandas de la comunidad no coinciden con la visión inicial de quien lo creó
Artículo relacionado: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
Es un enfoque sólido, y ojalá más gente lo tomara como punto de partida
Construir una comunidad o asumir cierto tipo de responsabilidades debería ser algo excepcional e intencional
La parte donde dice que los códigos de conducta y las políticas sobre LLM son puro aparentar sí se siente un poco fuera de lugar, pero entiendo que es un tema sensible
Pero si se los pones a un repositorio de una sola persona que no tiene usuarios ni comunidad, y tampoco piensa crear una, entonces sí se vuelven algo meramente performativo
No necesito un código de conducta para mí mismo en un repositorio que uso yo solo
Ojalá esta discusión cobre fuerza y termine en un consenso que de verdad funcione
Hay muchas formas de crear software y de contribuir de manera saludable
Solo que algunas no son compatibles entre sí, o no encajan con los estándares altos del open source, o implican pagar el costo de la visibilidad y la popularidad, o usan mecanismos distintos como la licencia, el self-hosting o no aceptar contribuciones de código
Me gustaría que encontráramos juntos una buena manera de poner por delante la diversión y la justicia en el software comunitario
El estado que plantea el artículo es el estado natural de prácticamente cualquier proyecto personal open source recién creado por alguien que no es famoso
Todos tenemos bastantes proyectos que funcionan así
El problema está en que la gente no sabe qué quiere obtener de su proyecto, o cree que dirigir un proyecto popular sería genial sin calcular bien el costo que implica
Entonces empieza la búsqueda de atención, sea consciente o no
La frase “GitHub convirtió todo el open source en un trabajo no remunerado para quienes mantienen proyectos” solo es cierta si lo permites
Fuera de la promesa vaga de fama, en la mayoría de los casos GitHub no tiene mucho poder para empujarte a hacer cosas que en realidad no querías hacer
Totalmente cierto
Antes tuve un proyecto algo popular y me estresaba lidiar con reportes de bugs y pull requests sobre funciones que yo no quería
Me habría gustado poder leer un texto así en ese momento
Además, vale la pena ver también https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9
En proyectos pequeños, estoy muy de acuerdo con este texto
Incluso en proyectos más grandes, muchas veces los más exitosos no empezaron como comunidades abiertas desde el principio
Muchos de mis proyectos favoritos comenzaron a desarrollarse dentro de grandes organizaciones, y lo clave es que ese software realmente se usaba de forma activa internamente
Así que quienes lo mantenían ya recibían un sueldo
Ya sea un proyecto personal o un equipo interno, el software creado para resolver problemas cotidianos del propio desarrollador parece más exitoso y menos explotador que el software creado por prestigio o con fines de negocio