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
2 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
Opiniones en Hacker News
Incluso en las comunidades más cerradas, muchas veces aceptan contribuciones si les mandas un correo educado
Hubo una vez en que un desarrollador de open source, agotado por el acoso, desactivó los pull requests y varias funciones del repositorio, y en ese período también se ganó la reputación de ser una persona muy difícil
Yo no sabía nada de ese contexto y simplemente pensé que el proyecto funcionaba así desde el principio, así que encontré su dirección de correo después de buscar un poco y le mandé un parche informal en un mensaje amable y sin presión, dejando claro que podía usarlo o ignorarlo
El desarrollador respondió agradeciendo, explicó la situación, incluso se disculpó por lo incómodo, dijo que no sabía cómo reaccionar salvo cerrándose de esa manera y, por supuesto, terminó incorporando el arreglo
Pensé que este artículo iba a tratar el problema tan extendido de que los proyectos de software libre obliguen a usar Discord para discusiones o reportes de bugs
Durante una o dos semanas pareció haber interés en mudarse a otras herramientas, pero ya se enfrió y al final parece que todos se rindieron y volvieron a Discord
Discord no es completamente terrible, pero es efímero y exige una enorme aplicación web inflada
Desde la perspectiva de alguien con canas en la barba, me gusta la actitud del autor
Llevo suficiente tiempo en esto como para recordar la época en que estabas sentado frente a veteranos de ARPANET y solo había unos, así que había que convertir como a la mitad en ceros a mano
En la vieja forma de desarrollar software, los proyectos normalmente eran escritos o mantenidos por una o dos personas, y todo internet conocía sus direcciones de correo y les mandaba los reportes de bugs directamente
Algunos proyectos se discutían en IRC o listas de correo, por lo general la gente se comportaba de manera profesional y, si no, la sacaban de la lista o terminaba en los archivos de bloqueo de iirc y pine
El punto clave es que, en cualquier momento, el grupo activo de desarrolladores era muy pequeño
Me refiero sobre todo a utilidades pequeñas como make, Sendmail, sed y awk, y hasta Perl parecía ser básicamente Larry Wall y tchrist antes de 1990
gcc era la loca excepción: miles de personas enviaban parches y además había que coordinarse bien con RMS para que entraran upstream
Las herramientas nuevas sí apoyan mejor la interacción continua de equipos más grandes, y también hay ventajas importantes en trabajar con equipos pequeños que no le prestan atención a cualquiera en internet a menos que llegue con un parche apostando un riñón
Solo que ese enfoque no ayuda a atraer gente al trabajo, así que puedes optar por la forma antigua, pero el equipo será más pequeño y puede costar más atraer usuarios
Aun así, eso no es problema del usuario; yo uso software para cubrir mi propio caso de uso y lo publico como open source por si también le sirve a alguien más
Para ser más concretos, el open source solo promete las cuatro libertades básicas(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
Fuera de eso, literalmente no promete nada, y eso incluye que no tiene por qué ser gratis
El software libre y open source puede cobrar dinero y de hecho debería hacerlo; aquí “free” no habla de dinero
Veo de forma bastante positiva los recientes ataques a la “cadena de suministro” open source que han ocurrido en varias comunidades, porque con optimismo espero que ayuden a que la gente entienda que el open source no es una cadena de suministro
Más detalles en https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Si no le estás pagando a un proveedor o no tienes un contrato con garantías de plazos, entonces no tienes una cadena de suministro
Casi todas las licencias FOSS incluyen una cláusula de “este software se proporciona sin garantía”, y una cadena de suministro implica garantías, así que FOSS no es una cadena de suministro
Ya me cansé de ver que aquí se hable de “open source” como si tuviera “valores morales”, mezclando conceptos robados del software libre como si fueran lo mismo
Open source no es más que grandes empresas de software aprovechándose de un montón de voluntarios
La gente de los códigos de conducta solo está para causar problemas
Basta ver cualquier debate del botón rojo/botón azul: ese nivel de insultos solo tiene sentido si el botón realmente existe o si a la gente le gusta actuar con maldad
Los partidarios de buena fe de los códigos de conducta hablan de libertad de asociación y libertad de expresión
La cuestión es si una plataforma puede bloquear a alguien simplemente porque no le cae bien, o si todo debería manejarse solo con la costumbre pragmática de las listas de correo de “seamos amables”
Claro, al final depende de quién tenga la autoridad para decidir, pero eso pasa en cualquier proyecto
No puedes exigir participar en el proyecto de otra persona imponiendo condiciones que contradicen los deseos del liderazgo del proyecto y al mismo tiempo reclamar libertad de asociación
Si tuviera que adivinar, cuando el autor dice que “no hace falta un Code of Conduct ostentoso”, tal vez quiere decir que en un proyecto pequeño, si solo quieres compartirlo con el mundo y dejar abierta la posibilidad de aceptar contribuciones externas más adelante, no necesitas preparar un código de conducta antes de siquiera enfrentar una situación real
No hace falta quebrarse la cabeza por un problema puramente hipotético
La razón de que exista un código de conducta es que la alternativa es el castigo arbitrario por infracciones arbitrarias, o una completa anarquía de spam
No entiendo cómo la misma gente que antes predicaba la netiqueta ahora se opone tanto a la claridad y a una comunidad sana
Pensándolo de nuevo, quizá sea la falacia Goomba, y tal vez quienes desprecian los códigos de conducta sean las mismas personas que en Usenet de los 90 se la pasaban sembrando flames y spam
Open source no es una simple elección de licencia
Es una reformulación del software libre para que resulte más atractivo a las empresas, y la idea central del open source es que para las empresas es más efectivo desarrollar software colaborando con el público que hacerlo de manera cerrada
Por eso el open source implica una comunidad abierta
Claro que puedes lanzar código al público con una licencia permisiva y no querer hacer desarrollo colaborativo; en ese caso, tu código sigue siendo open source
Abrir el código es algo bueno y no tienes obligación de hacer más, pero no estarías usándolo para el propósito con el que fue diseñado, e ignorarías una parte central
La gente no es irracional por asumir que, al ver código open source, hay desarrollo colaborativo
Ese es el objetivo del movimiento open source
Puede que en tu software esa suposición no aplique, y está bien, pero quien rompe la norma social no son ellos, sino tú
Yo pienso en Stallman, en el controlador de impresora y en que los usuarios sean dueños de su propio trabajo, así que esa afirmación tan tajante sobre el propósito del open source no me suena correcta
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Ahí no se dice nada sobre desarrollo colaborativo
La gente se pone emocional y muchas veces termina cuidando a usuarios nuevos que no quieren aprender lo básico, o a usuarios en general
Lo mejor es mantener una relación separada del foro de soporte, pero estricta, con respuestas a tiempo y sin involucrarse demasiado
coreboot y MrChromebox son buenos ejemplos; él responde solo cuando hace falta
Estoy de acuerdo, y agregaría que tampoco hace falta crear una página de marketing para convencer a la gente de usar tu software
En vez de eso, o además de eso, también puede ser bueno explicar todas las razones por las que no deberían usarlo
Cuantos más usuarios tengas, más problemas tendrás
Una aplicación FOSS no necesariamente tiene que distribuirse públicamente; eso es solo una expectativa social común
Tampoco significa que el código tenga que estar disponible para personas que no son clientes, y quién es cliente lo decide el desarrollador
FOSS fomenta vender software por dinero, e incluso puedes vender software de otra persona que originalmente era gratis (ver https://www.gnu.org/philosophy/selling.en.html)
El open source con licencia no libre sigue siendo open source, pero no FOSS, y no hay razón para que un desarrollador se avergüence de elegir una licencia open source no libre si quiere ganar más dinero con su software o imponer restricciones adicionales que le favorezcan
Eso también puede ser copyleft
En resumen: creamos LICENSE.md y dependemos muchísimo de eso, pero a nadie se le ocurrió hacer SOCIAL.md
Cuando alguien dice “open source”, mucha gente asume: “el autor lo hizo para la gente, para la sociedad y para todos a su alrededor; le importa el desarrollo del proyecto, agregar funciones nuevas, sobre todo las que yo necesito, y mejorar el software en beneficio de todos los usuarios. Si no, ¿para qué lo publicaría?”
Pero eso es solo la expectativa social más común sobre FOSS; está muy lejos de ser el único caso
La falta de una distinción entre open source técnico y open source social es una causa principal de desacuerdos, discusiones y, al final, burnout provocado por expectativas sociales desalineadas
Antes tenía que explicarle este problema y esa diferencia a multitudes furiosas, pero hace poco vi en el texto de Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ una comparación entre el código open source y un regalo
Mi explicación al final era: “si no te gusta el regalo o no te sirve, tíralo y olvídalo”
Solo hay unas pocas licencias aprobadas por la OSI que la FSF no considera software libre
Basta ver la larga lista de licencias de software libre incompatibles con la GPL en https://www.gnu.org/licenses/license-list.html
Además, “open source no FOSS” no tiene sentido, porque FOSS significa literalmente Free and Open Source Software
Ahora casi todo aparece enseguida en GitHub, junto con ejecutables que cualquiera puede usar, sin necesidad de pasar por sitios dudosos ni pipelines de build extraños
Sin “comunidad”, sin política, sin código de conducta, sin pull requests ni issues, sin wiki, sin equipo central: suena a paraíso
Últimamente siento que hay demasiada comunidad que termina siendo perjudicial para el proyecto mismo
Es más, no recuerdo ni una sola vez en que una comunidad haya ayudado de algún modo a un proyecto open source
Si tu objetivo es maximizar el control sacrificando calidad, está bien
Aunque en ese caso queda la duda de si de verdad tiene sentido que estés buscando FLOSS