Antes de GitHub

• Las dependencias de código abierto no eran solo una elección de paquetes, sino también una evaluación de la reputación y continuidad del proyecto, e incluso de cómo se mantenía.
• Aunque los sistemas de control de versiones distribuidos se volvieron algo común, el centro real de la colaboración volvió a concentrarse en GitHub, y eso sigue siendo una gran ironía del código abierto moderno.
• GitHub cambió el valor predeterminado de la colaboración pública con funciones como issue tracker, pull requests y páginas de lanzamientos, y también facilitó mucho el descubrimiento de proyectos y el flujo de contribuciones.
• Al mismo tiempo, GitHub también funciona como un archivo que conserva incluso repositorios abandonados y registros de discusión, ayudando a preservar la memoria de bienes comunes de software que pueden desaparecer fácilmente.
• En medio de señales recientes de que la centralidad de GitHub se está debilitando, para el código abierto se vuelve más importante contar con un archivo público que preserve la memoria y reduzca la dependencia, sin importar el modelo de negocio de una sola empresa.

---

El entorno del código abierto antes de GitHub

• Antes de GitHub, la cantidad de proyectos confiables para depender de ellos era limitada, y la reputación y continuidad de cada proyecto estaba directamente ligada a la elección de dependencias.
• Una dependencia no era solo el nombre de un paquete: también venían con ella la historia del proyecto, su sitio web, sus mantenedores, su proceso de lanzamientos y el contexto de su comunidad.
• Los proyectos grandes solían operar su propia infraestructura, y los pequeños a veces se publicaban en servidores universitarios o en SourceForge.
• Había fricción, como en el proceso de empaquetado de Debian, donde incluso se revisaban licencias y encabezados de copyright, y esa fricción también funcionaba como parte de la evaluación de confianza.

El funcionamiento de infraestructura propia y la paradoja del control de versiones distribuido

• En los primeros tiempos del código abierto, era común que los proyectos funcionaran 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.
• Como Subversion era un repositorio centralizado, operar un servidor venía de forma natural, y el hogar del proyecto era físicamente claro en forma de un nombre de host, un directorio, una instancia de Trac o un 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 reunirse en GitHub.
• Después de que triunfaron los sistemas de control de versiones distribuidos, el hecho de que todo el mundo terminara estandarizado en un único servicio central gigantesco sigue siendo una gran ironía del código abierto moderno.

Los cambios que trajo GitHub

• GitHub hizo más fácil crear y descubrir proyectos, y ayudó a que incluso quienes no tenían experiencia con listas de correo de desarrollo pudieran entender mejor el flujo de contribuciones.
• Al ofrecer issue tracker, pull request, páginas de lanzamientos, wiki, páginas de organization, API, webhook y más adelante CI, cambió el valor predeterminado de la colaboración pública.
• La colaboración en código abierto se volvió común como una forma de trabajo basada en 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 mostró una política que intentó mantener la accesibilidad de GitHub incluso en países bajo sanciones de EE. UU., la centralización no solo significó hosting, sino también una base pública accesible.

GitHub como archivo

• Una función menos destacada de GitHub fue su papel como archivo: incluso los proyectos abandonados seguían siendo encontrables y funcionaban como un índice de bienes comunes de software.
• Con forks, issues antiguos y registros de discusión que seguían presentes, la centralización ayudó a crear una memoria descubrible.
• En cambio, antes de las grandes plataformas era común que archivos y servicios de proyectos desaparecieran junto con el vencimiento de dominios personales, el cierre de VPS o la ausencia de desarrolladores.
• Como en proyectos tempranos de PyPI donde solo quedó el metadata y el paquete real desapareció, también ocurría que la dirección del repositorio apuntara a un servidor personal antiguo y terminara rota.
• Muchos proyectos del pasado acabaron dependiendo en gran medida de medios externos de preservación como Internet Archive.

npm y la explosión de dependencias

• El problema de las micro dependencias no se limitó a la proliferación de paquetes pequeños, sino que creció más porque GitHub y npm hicieron parecer casi inexistente el costo de crear, publicar, buscar, instalar y depender de ellos.
• Antes de GitHub, la confianza y la continuidad eran factores indispensables al elegir dependencias, y como no era fácil confiar en la disponibilidad de otros servicios, también era común incluir el código directamente en el repositorio mediante vendoring.
• Antes de las API, también era engorroso mantener scripts para traer código externo, y esa fricción hacía que uno lo pensara una vez más antes de agregar una dependencia.
• En un ecosistema al estilo npm, el grafo de paquetes puede crecer más rápido de lo que una persona puede razonar sobre él.
• Para responder al problema de estados de licencia poco claros, GitHub incluso intentó una revisión de sus términos de servicio.
• Se consolidó una cultura de revisar en GitHub, incluso al depender de paquetes pequeños, si existía el repositorio, si había mantenedores, issues, cambios recientes, uso por otros proyectos y si el código coincidía con la descripción del paquete.
• GitHub también se convirtió en uno de los pocos sistemas que incluso asumen el trusted publishing para registros como npm, y una pérdida de confianza en GitHub afecta no solo al hosting del código fuente, sino a toda la cultura de la cadena de suministro.

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

• Últimamente GitHub está perdiendo parte de la sensación de inevitabilidad que tenía antes por su inestabilidad, cambios repetidos de producto, ruido de Copilot AI y liderazgo poco claro.
• Al estar en el centro mismo del auge del agentic coding, también aumentó la presión interna, pero actualmente se lo describe como una situación donde se siente fuertemente la falta de liderazgo.
• Durante un tiempo, dejar GitHub era más bien un movimiento simbólico, pero ahora incluso proyectos influyentes están considerando o ejecutando públicamente su salida.
• El anuncio de Ghostty sobre dejar GitHub se considera una señal fuerte, aunque el destino todavía no esté claramente definido.
• Strudel moved to Codeberg
• Tenacity moved to Codeberg
• Puede que todavía no sea suficiente para provocar un cambio de tendencia general, pero está apareciendo una corriente en la que volvemos a ver con más frecuencia espacios de hosting fuera de GitHub.
• Dado que Git en sí fue diseñado originalmente asumiendo múltiples hogares, terminar con la situación en la que una sola empresa es el hogar predeterminado de todo podría ser saludable para el código abierto.

El costo del regreso a la distribución

• Si se vuelve a múltiples forges, múltiples servidores y múltiples comunidades pequeñas, pueden aumentar la descentralización y la autonomía, y reducirse la dependencia de cambios en el liderazgo de Microsoft.
• También existe la ventaja de que cada comunidad puede elegir su propio flujo de trabajo.
• El problema actual del issue tracker de Pi muestra cómo las decisiones de producto de GitHub pueden llevar a resultados que no encajan con la realidad actual del mantenimiento de código abierto.
• En GitHub se hace evidente un diseño más centrado en el engagement que en la salud mental de los mantenedores.
• En cambio, si se migra a un forge self-hosted, a un servidor propio de Mercurial o a un servidor cgit, el código en sí puede quedar distribuido, pero el contexto social puede dispersarse fácilmente.
• Issues, revisiones, discusiones de diseño, notas de lanzamiento, avisos de seguridad y tarballs antiguos desaparecen con mucha más facilidad de lo que parece.
• Las listas de correo que antes contenían ese contexto no lograron seguir el ritmo de las exigencias actuales, y además la experiencia de usuario no es buena.
• Puede haber un efecto de depuración en el hecho de que el software sea olvidado, pero si el riesgo de pérdida aumenta, también hay que replantearse cómo se aprovechan realmente los sistemas de control de versiones distribuidos.

Lo que hace falta es un archivo público

• Tanto si GitHub permanece como si los proyectos se van a otro lugar, el código abierto necesita un archivo público, aburrido pero estable.
• No hace falta un servicio para ganar en el mercado de la productividad de desarrolladores, sino una estructura que impida que software importante desaparezca.
• Debe operar sobre una base sostenible a largo plazo, como un endowment o financiamiento público.
• Los archivos de código fuente, artefactos de lanzamiento, metadata y contexto del proyecto deben preservarse en un lugar que no esté atado al modelo de negocio ni al estado de ánimo del liderazgo de una sola empresa.
• GitHub, al convertirse en el centro de la actividad de código abierto, terminó asumiendo por accidente también ese papel de archivo, 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 fueron suficientes para la preservación, y el vacío posterior al cierre de plataformas como Google Code y Bitbucket ya lo demostró.
• Los sistemas del futuro deben avanzar en una dirección que preserve la memoria y reduzca la dependencia, facilitando la migración de proyectos, el mirroring del contexto social y la preservación de lanzamientos, para que la deriva de una sola empresa no se convierta fácilmente en una crisis cultural para todos.
• Sigue existiendo la tensión entre no querer volver a tarballs con enlaces rotos y a instancias abandonadas de Trac, y tampoco aceptar la estructura centrada en GitHub de los últimos 20 años como un estado normal permanente.

[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