El mundo del código abierto antes de GitHub

• Antes de que GitHub se consolidara como la infraestructura social del código abierto, los desarrolladores gestionaban proyectos sobre infraestructura operada por ellos mismos, como Trac propio, repositorios Subversion y listas de correo, y agregar dependencias implicaba bastante fricción y cautela
• GitHub facilitó de forma radical la creación, el descubrimiento y la contribución a proyectos, estandarizó el issue tracker, los pull requests, el CI y más, y además terminó cumpliendo también el papel de archivo del código abierto
• Al combinarse con ecosistemas de paquetes como npm, se produjo una explosión de microdependencias, y GitHub se volvió un eje central del sistema de confianza; sin embargo, hoy esa confianza se está erosionando por inestabilidad, confusión en la dirección del producto y ruido de IA
• También hay movimientos como la salida de Ghostty y la migración a Codeberg de Strudel y Tenacity; la descentralización aumenta la autonomía, pero también conlleva el riesgo de perder contexto social como issues, revisiones y avisos de seguridad
• En medio de señales recientes de que la centralidad de GitHub se está debilitando, se vuelve más importante contar con un archivo público que preserve la memoria y reduzca la dependencia. La siguiente era del código abierto debe mantener la memoria, pero reducir las dependencias

---

El entorno del código abierto antes de GitHub

• Antes de GitHub, la cantidad de proyectos confiables era limitada, y la reputación y continuidad de cada proyecto estaban directamente ligadas a la elección de dependencias
• Una dependencia no era solo el nombre de un paquete, sino que venía acompañada de la historia del proyecto, su sitio web, sus mantenedores, su proceso de releases y su contexto comunitario
• Los proyectos grandes solían operar su propia infraestructura, y los pequeños a veces se alojaban en servidores universitarios o en SourceForge
• Había fricción, como en el proceso de empaquetado de Debian, donde se revisaban incluso licencias y encabezados de copyright, y esa fricción también funcionaba como parte de la evaluación de confianza

La paradoja de operar infraestructura propia y el control de versiones distribuido

• En los primeros proyectos de código abierto era común que todo corriera sobre servidores donde se operaban directamente Trac, Subversion, tarballs y documentación
• También existían estructuras como Pocoo, donde varios proyectos compartían el costo del servidor y la carga de operar Subversion, Trac y listas de correo
• Subversion era un repositorio centralizado, así que operar un servidor venía de forma natural, y el hogar de un proyecto era físicamente claro en su hostname, directorio, instancia de Trac y archivo de listas de correo
• Mercurial y Git eran sistemas distribuidos en los que cualquiera podía tener el repositorio completo, las ramas y el historial, pero en la práctica el centro volvió a concentrarse en GitHub
• Después de que los sistemas distribuidos de control de versiones ganaran, quedó como una gran ironía del código abierto moderno que el mundo entero terminara estandarizado en torno a un único servicio central enorme

Los cambios que trajo GitHub

• GitHub facilitó la creación y el descubrimiento de proyectos, y permitió que incluso personas sin experiencia con listas de correo de desarrollo entendieran mejor el flujo de contribución
• Al ofrecer issue tracker, pull requests, páginas de releases, wiki, páginas de organización, API, webhooks y más tarde CI, cambió el valor por defecto de la colaboración pública
• La colaboración en código abierto se generalizó como una práctica que avanza sobre historial visible y discusiones visibles
• Durante un tiempo, GitHub funcionó como una opción predeterminada muy razonable para publicar proyectos de código abierto
• Como muestran sus políticas para mantener la accesibilidad de GitHub incluso en países sujetos a sanciones de Estados Unidos, la centralización no solo servía para alojar código, sino también como una base pública accesible

GitHub como archivo

• Una función menos destacada de GitHub fue su papel de archivo: incluso proyectos abandonados seguían siendo localizables y funcionaban como un índice de los bienes comunes del software
• Los forks, los issues antiguos y los registros de discusión seguían ahí, y la centralización ayudaba a crear una memoria descubrible
• En cambio, antes de las grandes plataformas era común que archivos y servicios de proyectos desaparecieran cuando vencía un dominio personal, se apagaba un VPS o dejaba de estar presente el desarrollador
• Había casos como proyectos antiguos donde en PyPI quedaba solo la metadata, pero el paquete real había desaparecido, o donde la dirección del repositorio apuntaba a un servidor personal viejo ya caído
• Muchos proyectos del pasado terminaron dependiendo en gran medida de medios externos de preservación como Internet Archive

npm y la explosión de dependencias

• El problema de las microdependencias no se limitó a que hubiera más paquetes pequeños, sino que se amplificó porque GitHub y npm hicieron que crear, distribuir, buscar, instalar y depender de paquetes pareciera casi no tener costo
• Antes de GitHub, la confianza y la continuidad eran elementos esenciales al elegir dependencias, y como era difícil confiar en la disponibilidad de otros servicios, también era común hacer vendoring, es decir, incluir el código directamente en el repositorio
• Antes de las API, también era molesto mantener scripts que trajeran código externo, y esa fricción obligaba a pensarlo una vez más antes de agregar una dependencia
• En un ecosistema tipo npm, el grafo de paquetes puede crecer más rápido de lo que una persona puede razonar
• Para responder a problemas donde el estado de las licencias se volvía ambiguo, GitHub incluso intentó revisar sus términos de servicio
• Se consolidó una cultura de verificar en GitHub, incluso para paquetes pequeños, si existía el repositorio y el mantenedor, qué issues tenía, si había cambios recientes, si otros proyectos lo usaban y si el código coincidía con la descripción del paquete
• GitHub se volvió además uno de los pocos sistemas encargados incluso del trusted publishing para registros como npm, y una pérdida de confianza en GitHub afecta no solo el hosting del código fuente, sino toda la cultura de la cadena de suministro

El debilitamiento de GitHub y señales de migración

• Últimamente GitHub está perdiendo parte de la sensación de inevitabilidad que tenía por su inestabilidad, cambios repetidos de producto, ruido de Copilot AI y liderazgo poco claro
• Aunque estar en medio de la ola del agentic coding también ha aumentado la presión interna, se describe la situación actual como una donde se siente con fuerza la ausencia de liderazgo
• Durante un tiempo, dejar GitHub era más un gesto simbólico, pero ahora incluso proyectos influyentes están evaluando o ejecutando públicamente su migración
• El anuncio de la salida de Ghostty de GitHub se considera una señal fuerte, aunque el destino final todavía no esté del todo claro
• Strudel moved to Codeberg
• Tenacity moved to Codeberg
• Puede que todavía no sea suficiente para marcar un cambio de tendencia definitivo, pero sí está apareciendo un patrón en el que volvemos a ver con más frecuencia espacios de hosting fuera de GitHub
• Dado que Git fue diseñado originalmente asumiendo múltiples hogares, puede ser saludable para el código abierto terminar con una situación en la que una sola empresa sea el hogar predeterminado de todo

El costo de volver a lo distribuido

• Si se regresa a múltiples forges, múltiples servidores y múltiples comunidades pequeñas, la descentralización y la autonomía pueden aumentar y la dependencia de cambios de liderazgo en Microsoft puede reducirse
• También existe la ventaja de que cada comunidad pueda elegir flujos de trabajo distintos
• El problema actual del issue tracker de Pi muestra cómo las decisiones de producto de GitHub pueden producir resultados que no encajan con la realidad actual del mantenimiento de código abierto
• Queda en evidencia que GitHub tiene aspectos diseñados más en torno al engagement que a la salud mental de los mantenedores
• Pero, por otro lado, si se migra a un forge self-hosted, a un servidor propio de Mercurial o a un servidor cgit, el código puede distribuirse, pero el contexto social puede dispersarse fácilmente
• Los issues, las revisiones, las discusiones de diseño, las notas de release, los avisos de seguridad y los tarballs antiguos desaparecen con mucha más facilidad de lo que parece
• Las listas de correo, que antes contenían ese contexto, ya no alcanzan para las necesidades actuales y además ofrecen una experiencia de usuario deficiente
• Puede haber un efecto depurador en el hecho de que el software sea olvidable, pero si el riesgo de pérdida aumenta, también hay que replantear cómo usamos realmente los sistemas distribuidos de control de versiones

Lo que hace falta es un archivo público

• Ya sea que GitHub permanezca o que los proyectos se muden a otro lugar, el código abierto necesita un archivo público, aburrido pero estable
• No se necesita un servicio diseñado para ganar en el mercado de productividad para desarrolladores, sino una estructura que evite que software importante desaparezca
• Debe operar sobre una base sostenible a largo plazo, como un endowment o fondos públicos
• El archivo del código fuente, los artefactos de release, la metadata y el contexto del proyecto deben preservarse en un lugar que no dependa del modelo de negocio ni del humor del liderazgo de una sola empresa
• GitHub terminó asumiendo por accidente ese papel de archivo al convertirse en el centro de la actividad de código abierto, pero si su centralidad se debilita no se puede asumir que esa función vaya a mantenerse automáticamente
• Los servidores personales y la buena voluntad no bastaron para preservar, y el vacío que dejaron cierres de plataformas como Google Code y Bitbucket ya lo demostró
• Los sistemas del futuro deben ir en una dirección que preserve la memoria y reduzca la dependencia, donde mover proyectos, reflejar el contexto social y conservar releases sea fácil, y donde el extravío de una sola empresa no se convierta en una crisis cultural para todos
• Persiste así una tensión: no queremos volver a los links rotos de tarballs ni a instancias abandonadas de Trac, pero tampoco podemos aceptar la estructura centrada en GitHub de los últimos 20 años como un estado normal permanente

[runableapp]

Es cierto que GitHub ha desempeñado muchos papeles hasta ahora, pero según recuerdo, antes de eso los proyectos de código abierto los hacían solo quienes ya estaban metidos en ese mundo, y no era común que individuos publicaran los suyos. Incluso dentro de las empresas, a veces se compartían solo entre equipos del mismo grupo. Y que te aceptaran como alguien que contribuía a un gran proyecto de código abierto era un gran honor; a los pequeños proyectos personales, en cambio, ni siquiera les prestaban atención.

Recuerdo que todo empezó con un cambio en el ambiente de la comunidad de desarrollo, cuando publicar software abierto comenzó a usarse como una forma de demostrar y obtener reconocimiento por las propias habilidades, y al final también coincidió con que, entre varios DVCS, git terminó usándose más ampliamente. Creo que fue el inicio de una serie de golpes de suerte; los competidores también ofrecían servicios parecidos, así que no diría que GitHub destacara únicamente por hacerlo mejor.

[ndrgrd]

En realidad, el problema son las discusiones de issues y PR; el propio git se puede mover a otro servicio en cualquier momento. También había proyectos que metían esas tres cosas en git, así que si usas algo así, podrías migrarte cuando quieras.

[GN⁺]

Comentarios en Hacker News

• Creo que uno de los mayores cambios que trajo GitHub fue su estructura centrada en personas y no en proyectos
  El hecho de poder crear algo rápido asociando un repositorio directamente a mi nombre se sentía mucho más liberador que el proceso pesado de SourceForge, donde había que decidir y reservar un nombre de proyecto para luego tener CVS o SVN, sitio web, lista de correo e issue tracker
  Eso redujo muchísimo la carga mental de pensar “esto es solo algo temporal”
  Tampoco es que GitHub diera de golpe issue tracker, PR, página de releases, wiki, páginas de organización, API, webhooks y CI
  Antes ni siquiera tenía funciones de organización, así que a veces uno creaba una cuenta de usuario nueva para simular una organización, y más de una vez fui posponiendo adoptar un bug tracker aparte pensando “GitHub seguro lo saca en unos meses”, para al final terminar gestionándolo con archivos de texto dentro del repositorio
• Todavía me da algo de pena que en la mayoría de los proyectos Git le haya ganado a Fossil
  En codebases gigantes como el kernel de Linux quizá sí haya una ventaja de rendimiento con Git, pero en la gran mayoría de los proyectos casi nunca se llega al límite de rendimiento del VCS
  En Fossil es realmente útil que herramientas internas como wiki, foro y tickets queden versionadas junto con el código en un solo archivo
  En trabajo freelance, Fossil hace muy fácil volver a entender el contexto del proyecto, los detalles y los acuerdos con el cliente
  No hace falta ensuciar el codebase ni andar buscando entre correos y herramientas de notas para reconstruir el contexto
  Tampoco me gusta la idea de que, como Git está demasiado arraigado culturalmente, ya no se pueda cambiar
  Pasarse a Fossil es fácil, e incluso viniendo de Git el flujo de trabajo resulta más simple
  • También se podían haber hecho herramientas parecidas sobre el protocolo y los repositorios de Git; de hecho sí existían cosas como la revisión de código distribuida
    Pero la mayoría no quería eso, así que nunca ganó tracción
    También hay bastantes casos en los que guardar los issues junto al proyecto resulta problemático
    Si un cliente te manda muchas capturas o videos para reproducir bugs, el repositorio crece rapidísimo, y si eso queda atado al código, todo el mundo tiene que bajar un repo enorme solo para ver tickets localmente, lo cual es bastante molesto
    Al final es fácil caer en “mejor no usemos esto, es demasiado complejo y solo infla el repositorio”
    La mayoría de las funciones de Fossil parecen implementables también sobre un backend de Git, y wikis o issues podrían ir en una capa separada de ramas paralelas
  • Parece que también influyó el timing
    Si mal no recuerdo, incluso cuando Git ya era estable y usable en el día a día, Fossil todavía tenía casos donde al actualizar versión había que recrear por completo el repositorio
    Git tenía peor UX, y puede que todavía la tenga, pero igual funcionaba y daba más sensación de estar listo para producción
    Además, lo usaba uno de los mayores proyectos de código abierto del mundo, así que en términos de percepción esa diferencia fue decisiva
  • Justo ahora me parece un buen momento para que alguien compre fossilhub.com y arme una nueva comunidad
  • Me da curiosidad por qué Git es más rápido en repositorios grandes
    Aunque recuerdo que por un tiempo esa ventaja no se notaba tanto cuando había blobs grandes
• Creo que fue más bien malo que GitHub asumiera el papel de archivo
  Si el 99% del tiempo existe un servicio centralizado útil, la capacidad de preservación de toda la comunidad se atrofia
  Si mantener algo vivo implicara que alguien realmente tuviera que seedearlo, la gente conservaría mejor copias de lo que de verdad considera importante
  El problema es que se volvió demasiado fácil asumir “luego lo vuelvo a hacer checkout”
  No debería existir un solo lugar desde el que se pueda bajar algo
  Si un proyecto en GitHub recibe un DMCA, hasta los forks desaparecen junto con él
  Cuando Nintendo bajó en 2024 un emulador popular de Switch, la preservación y el trabajo posterior solo fueron posibles buscando quién tenía hecho checkout de la revisión más reciente y reanudando desde ahí
  Y eso solo fue posible porque era un proyecto muy popular: https://news.ycombinator.com/item?id=40254602
  Además, la animación del encabezado y pie con vibra de Splatoon en este sitio está buenísima
  No molesta, aporta ambiente y se quita de inmediato cuando haces scroll, así que me dan ganas de robármela tal cual
  • Eso también termina creando una sensación de que si no está en GitHub, no existe
    Parece que hay demasiados desarrolladores que ni siquiera saben que el código puede alojarse en otros lados
  • Archivar en sí es fácil, pero el copyright y las leyes de propiedad intelectual lo complican todo
    Si hubiera menos obstáculos para hacer accesible la información, también habría menos concentración de poder
  • No estoy de acuerdo con eso
    Una de las razones por las que GitHub se ganó la confianza durante años es que hasta ahora no ha monetizado directamente ese rol de archivo
    Claro, viendo las funciones nuevas relacionadas con Copilot, quién sabe qué pase en adelante
    Si la alternativa es fragmentarlo en varios sitios, entonces solo tendríamos distintas reglas de DMCA en cada uno
    Eso me hace preguntarme cuál sería exactamente una alternativa mejor
• Leer algo así me hace mirar hacia atrás el recorrido de los proyectos en los que participé
  La mayor parte de mi trabajo en código abierto la hice sobre infraestructura self-hosted, y el ejemplo más representativo es Xfce
  Cuando participé por primera vez en 2004, recuerdo que había un servidor SVN y quizá una interfaz web con el nuevo soporte de SVN en CVSweb
  Creo que después de entrar al equipo central fui yo quien configuró Bugzilla, aunque también pudo haber sido otra persona
  Cuando Git empezó a volverse el estándar, lideré la migración de un gran repositorio SVN a varios repositorios Git y además le agregué la interfaz web cgit
  Hasta entonces seguíamos usando Bugzilla
  Luego entré a una startup pequeña alrededor de 2009~2010 y dejé el proyecto porque ya no tenía tiempo para OSS; cuando volví en 2022, en el intermedio ya habían levantado una instancia de GitLab con runners de CI y también habían migrado Bugzilla a issues de GitLab
  Sigue habiendo muy poca gente activa y la administración de infraestructura recae casi por completo en una sola persona, pero incluso con un equipo pequeño se puede operar bien
  Tener la infraestructura patrocinada es una gran suerte, y con puro patrocinio recurrente probablemente también podrían pagarla directamente si hiciera falta
  Sobre todo, me encanta no depender de GitHub/Microsoft
  Si hace 20 años alguien me hubiera dicho que Microsoft iba a ser dueña de la mayor forge de código OSS del mundo, me habría dado náuseas, y todavía hoy me sigue incomodando bastante
• A veces se pasa por alto, pero el inicio de sesión compartido también fue importantísimo
  Rust ejecuta pruebas a todo el ecosistema de proyectos Rust con una herramienta llamada crater, y cuando tocó abrir manualmente cientos de issues para encontrar proyectos que dependían de implementaciones internas de Cargo, ayudó muchísimo tener un flujo con poca fricción
  Si ya tienes las credenciales del sitio y además permite plantillas vacías, abrir 200 issues se vuelve mucho más fácil
  En cambio, cuando me topo con una instancia self-hosted, normalmente abandono ahí mismo
• Yo ya publicaba en Planet Source Code desde antes de que existiera SourceForge
• A mí me encantaba Trac
  Configurar Trac como primer paso al arrancar un nuevo proyecto de código abierto tenía una fricción difícil de creer, pero aun así me gustaba
  Django sigue funcionando sobre Trac después de más de 20 años: https://code.djangoproject.com/timeline
  No fui yo quien configuró eso, pero puede que sí haya ayudado a levantar un Trac privado anterior
  • Trac era realmente bueno
    Eso sí, mi primer issue tracker fue Bugzilla, y configurarlo fue bastante doloroso, además de que no se integraba muy bien con otras herramientas
    Aun así, ver Zarro Boogs tenía un encanto muy especial
  • Trac fue, en muchos sentidos, lo que me empujó a hacer apps para despliegue en Python en lugar de PHP
    Su sistema de plugins era excelente
  • A mí me gustaba Bitbucket
    Cumplía bien su función, en mi caso nunca se rompía, y además Mercurial me gustaba más
    Me cambié porque las empresas usan GitHub, pero incluso ahora GitHub para mí es poco más que un endpoint torpe de Git, y builds/deploys los manejo con Docker y scripts de shell, así que el costo de cambiarme es muy bajo
    En el trabajo, si no me toca decidir, pienso que simplemente se usa la herramienta paga que toque, igual que en la época de SVN
  • Curiosamente, en esa época odiaba muchísimo Trac, pero ahora me dejó buenos recuerdos
    Sentía que quería hacer demasiadas cosas sin destacar realmente en ninguna
    Hoy ese papel probablemente lo ocupa GitLab, y seguro después también lo recordaré con cariño
• Me dio curiosidad buscar servicios de archivado de código y encontré varios
  Está el propio programa de GitHub: https://archiveprogram.github.com/
  Y también Software Heritage, una organización sin fines de lucro apoyada por la UNESCO: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
  Eso sí, esta parte parece enfocarse más en preservar el código y el historial de commits, y no tanto metadatos periféricos como issues, PR, discusiones o wikis
• Creo que fui de los que usaron Flask casi desde el principio
  Aprendí Python para aprovechar AppEngine, que era un hosting moderno gratis y fácil, y gracias a eso estaba en una posición perfecta cuando apareció Flask
  Llevo mucho tiempo admirando a Armin, y reconocí el dominio en cuanto lo vi, incluso antes de hacer clic en el enlace
  También coincido con lo que dice de que en esa época GitHub no era la opción predeterminada
  Además me impresiona que este texto sea una respuesta al post de Mitchell de hace apenas unas horas, y sorprende que haya escrito tan rápido algo tan largo, tan bien estructurado y de tanta calidad
• Me hizo recordar code.google.com
  Todavía me cuesta creer que Google dejara pasar una oportunidad tan grande
  • Qué nostalgia, de verdad
    Yo estaba en ese equipo antes de que cerraran ese servicio