Antes do GitHub

• Dependências de código aberto não eram apenas uma escolha de pacote; também envolviam avaliar a reputação e a continuidade do projeto, além da forma de manutenção
• Embora os sistemas de controle de versão distribuído tenham se tornado comuns, na prática o centro da colaboração voltou a se concentrar no GitHub, e isso continua sendo uma grande ironia do open source moderno
• Com recursos como issue tracker, pull requests e páginas de release, o GitHub mudou o padrão de colaboração pública e também tornou muito mais fácil descobrir projetos e contribuir para eles
• Ao mesmo tempo, o GitHub também funciona como um arquivo, preservando até repositórios abandonados e registros de discussão, ajudando a reter a memória de bens comuns de software que tendem a desaparecer facilmente
• Em meio a sinais recentes de enfraquecimento da centralidade do GitHub, torna-se ainda mais importante para o open source ter um arquivo público que preserve a memória e reduza a dependência, independentemente do modelo de negócio de uma empresa

---

O ambiente de open source antes do GitHub

• Antes do GitHub, o número de projetos confiáveis para depender era limitado, e a reputação e a continuidade de cada projeto estavam diretamente ligadas à escolha de dependências
• Uma dependência não era apenas o nome de um pacote; vinha acompanhada da história do projeto, do site, dos mantenedores, do processo de release e do contexto da comunidade
• Projetos grandes frequentemente operavam sua própria infraestrutura, enquanto projetos menores às vezes ficavam em servidores universitários ou no SourceForge
• Havia atritos, como no processo de empacotamento do Debian, em que até licenças e cabeçalhos de copyright eram revisados, e esse atrito também fazia parte da avaliação de confiança

O paradoxo da infraestrutura própria e do controle de versão distribuído

• Nos primeiros tempos, era comum que projetos open source rodassem em servidores operados diretamente, com Trac, Subversion, tarball e documentação
• Havia também estruturas como a do Pocoo, em que vários projetos dividiam os custos de servidor e o peso de operar Subversion, Trac e listas de e-mail
• Como o Subversion era um repositório centralizado, operar um servidor vinha naturalmente junto, e a casa do projeto era fisicamente clara, na forma de hostname, diretório, instância do Trac e arquivo de lista de e-mails
• Mercurial e Git eram sistemas distribuídos nos quais qualquer pessoa podia ter o repositório completo, branches e histórico, mas o centro real acabou se reunindo novamente no GitHub
• Depois da vitória dos sistemas de controle de versão distribuído, o fato de o mundo inteiro ter se padronizado em um único grande serviço central continua sendo uma grande ironia do open source moderno

As mudanças trazidas pelo GitHub

• O GitHub tornou mais fácil criar e descobrir projetos, e facilitou para quem não tinha experiência com listas de e-mail de desenvolvimento entender o fluxo de contribuição
• Ao oferecer issue tracker, pull requests, páginas de release, wiki, páginas de organization, API, webhook e depois até CI, ele redefiniu o padrão de colaboração pública
• A colaboração em open source se popularizou como um processo conduzido sobre histórico visível e discussões visíveis
• Durante um bom tempo, o GitHub funcionou como uma opção padrão muito razoável para hospedar projetos open source
• Como mostrou a política de manter a acessibilidade ao GitHub até mesmo em países sob sanções dos EUA, a centralização acabou exercendo o papel de infraestrutura pública acessível, e não apenas de hospedagem

O GitHub como arquivo

• Uma função menos destacada do GitHub foi seu papel de arquivo: até projetos abandonados continuavam pesquisáveis, funcionando como um índice de bens comuns de software
• Forks, issues antigas e registros de discussão continuavam disponíveis, e a centralização criava uma memória descobrível
• Em contraste, antes das grandes plataformas, era comum que arquivos e serviços de projetos desaparecessem com o vencimento de domínios pessoais, o encerramento de VPS ou o sumiço de desenvolvedores
• Em projetos antigos como este no PyPI, em que restaram só os metadados e o pacote real desapareceu, era comum o endereço do repositório apontar para um servidor pessoal antigo já fora do ar
• Muitos projetos do passado acabaram dependendo fortemente de meios externos de preservação, como o Internet Archive

npm e a explosão de dependências

• O problema das microdependências não se limitou ao aumento de pacotes pequenos; ele se ampliou porque GitHub e npm fizeram parecer que criar, publicar, buscar, instalar e depender de algo quase não tinha custo
• Antes do GitHub, confiança e continuidade eram fatores obrigatórios na escolha de dependências, e como era difícil confiar na disponibilidade de outros serviços, também era comum fazer vendoring, incorporando o código diretamente ao repositório
• Antes da era das APIs, também era trabalhoso manter scripts para buscar código externo, e esse atrito fazia pensar uma vez mais antes de adicionar uma dependência
• Em ecossistemas no estilo do npm, o grafo de pacotes pode crescer mais rápido do que a velocidade com que uma pessoa consegue raciocinar sobre ele
• Para responder ao problema da incerteza sobre o estado de licenças, o GitHub chegou a tentar uma revisão dos termos de serviço
• Consolidou-se a cultura de, mesmo ao depender de pacotes pequenos, verificar no GitHub o repositório, a existência do mantenedor, as issues, mudanças recentes, o uso por outros projetos e se o código corresponde à descrição do pacote
• O GitHub também se tornou um dos poucos sistemas responsáveis até por trusted publishing para registros como o npm, e a perda de confiança nele afeta não apenas a hospedagem de código, mas toda a cultura da cadeia de suprimentos

O enfraquecimento do GitHub e sinais de migração

• Recentemente, o GitHub vem perdendo parte da aura de inevitabilidade por causa de instabilidade, mudanças repetidas de produto, ruído da IA do Copilot e liderança pouco clara
• Por estar no centro do movimento de agentic coding, a pressão interna também aumentou, mas a situação atual é descrita sobretudo como uma de forte ausência de liderança
• Durante um tempo, sair do GitHub era quase um gesto simbólico, mas agora até projetos influentes estão considerando publicamente a mudança ou já a estão executando
• O anúncio de saída do Ghostty do GitHub é tratado como um sinal forte, mesmo sem um destino totalmente definido
• Strudel moved to Codeberg
• Tenacity moved to Codeberg
• Talvez ainda não seja suficiente para provocar uma virada dominante, mas já se percebe uma tendência de ver com mais frequência espaços de hospedagem fora do GitHub
• Como o próprio Git foi originalmente projetado supondo várias casas, encerrar a situação em que uma única empresa é a casa padrão de tudo pode ser algo saudável para o open source

O custo do retorno à distribuição

• Se houver um retorno a vários forges, vários servidores e várias comunidades menores, a descentralização e a autonomia podem aumentar, e a dependência de mudanças de liderança da Microsoft pode diminuir
• Também há a vantagem de cada comunidade poder escolher seu próprio workflow
• O atual problema do issue tracker do Pi mostra como certas escolhas de produto do GitHub levam a resultados desalinhados com a realidade atual da manutenção em open source
• O GitHub revela aspectos desenhados mais em torno de engajamento do que da saúde mental de mantenedores
• Por outro lado, ao migrar para um forge self-hosted, um servidor Mercurial próprio ou um servidor cgit, o código em si pode se distribuir, mas o contexto social pode se dispersar facilmente
• Issues, revisões, discussões de design, notas de release, avisos de segurança e tarballs antigos desaparecem com muito mais facilidade do que parece
• As listas de e-mail, que antes carregavam esse contexto, não acompanharam as exigências de hoje e também não oferecem boa experiência de uso
• O fato de o software ser esquecido pode até ter um efeito de depuração, mas se o risco de perda aumenta demais, então também é preciso repensar como os sistemas de controle de versão distribuído devem ser usados na prática

O que é necessário é um arquivo público

• Independentemente de o GitHub permanecer ou de os projetos irem para outro lugar, o open source precisa de um arquivo público, estável e sem glamour
• Não de um serviço feito para vencer no mercado de produtividade para desenvolvedores, mas de uma estrutura que impeça o desaparecimento de softwares importantes
• Ele deve operar sobre uma base sustentável no longo prazo, como um endowment ou financiamento público
• Arquivos-fonte, artefatos de release, metadados e o contexto do projeto devem ser preservados em um lugar não vinculado ao modelo de negócio ou ao humor da liderança de uma empresa
• O GitHub se tornou o centro da atividade open source e, por acaso, acabou assumindo também esse papel de arquivo, mas se sua centralidade enfraquece, não dá para presumir que essa função continuará automaticamente
• Servidores pessoais e boa vontade, sozinhos, nunca foram suficientes para preservar tudo, e o vazio deixado após o fim de plataformas como Google Code e Bitbucket já mostrou isso
• Os sistemas do futuro devem seguir na direção de preservar a memória e reduzir a dependência, tornando mais fácil migrar projetos, espelhar contexto social e preservar releases, além de dificultar que a deriva de uma única empresa se transforme em crise cultural para todos
• Continua existindo essa tensão entre não querer voltar a links quebrados de tarball e instâncias abandonadas de Trac, e ao mesmo tempo não poder aceitar a estrutura centrada no GitHub dos últimos 20 anos como um estado normal permanente

[GN⁺]

Comentários do Hacker News

• Acho que uma das maiores mudanças trazidas pelo GitHub foi que ele era centrado nas pessoas, e não centrado nos projetos
  O fato de poder simplesmente anexar um repositório ao meu nome e criar algo rapidamente era muito mais libertador do que o processo pesado do SourceForge, em que você precisava escolher e reservar um nome de projeto e ainda configurar repositórios CVS ou SVN, site, lista de discussão e rastreador de issues
  Isso reduziu bastante a carga mental de pensar "isso é só uma coisinha temporária"
  Também não é como se o GitHub já tivesse entregado de uma vez rastreador de issues, PRs, páginas de release, wiki, páginas de organização, API, webhooks e CI
  Antigamente nem havia recurso de organização, então às vezes criávamos uma conta de usuário nova para imitar uma organização, e também já adiei a adoção de um bug tracker separado pensando "o GitHub deve lançar isso em alguns meses", e no fim acabei gerenciando tudo em arquivos de texto dentro do repositório
• Até hoje acho uma pena que, na maioria dos projetos, o Git tenha vencido o Fossil
  Em codebases gigantescas como a do kernel Linux, o Git talvez tenha vantagens de desempenho, mas a grande maioria dos projetos praticamente nunca chega no limite de performance de um VCS
  No Fossil, é realmente útil que ferramentas internas como wiki, fórum e tickets fiquem versionadas junto com o código em um único arquivo
  Em trabalhos freelance, o Fossil facilita muito reconstruir o contexto do projeto, os detalhes e os acordos feitos com o cliente
  Não é preciso bagunçar a codebase nem ficar vasculhando e-mails e ferramentas de notas para recuperar o contexto
  Também não gosto da ideia de que, só porque o Git está culturalmente enraizado demais, não dá mais para mudar
  A migração para o Fossil é fácil, e mesmo vindo do Git o workflow acaba sendo até mais simples
  • Também dava para construir ferramentas parecidas em cima do protocolo e do repositório do Git, e de fato já existiram coisas como code review distribuído
    Só que a maioria não queria isso, então essas ideias não ganharam força
    Também há muitos casos em que armazenar issues junto com o projeto é inconveniente
    Se o cliente manda muitas capturas de tela ou vídeos para reproduzir bugs, o repositório cresce rápido, e quando tudo fica amarrado ao código, todo mundo precisa baixar um repositório gigantesco localmente só para ver os tickets, o que é bem incômodo
    No fim, isso tende a virar "melhor não usar isso, é complexo demais e só infla o repositório"
    Parece que a maior parte dos recursos do Fossil poderia ser implementada sobre um backend Git, e wiki ou issues poderiam ficar em uma camada separada de branches paralelas
  • Acho que também houve um efeito de timing
    Pelo que lembro, mesmo quando o Git já estava estável e bom para uso cotidiano, o Fossil às vezes ainda exigia recriar o repositório inteiro em atualizações de versão
    O UX do Git era pior, e talvez ainda seja, mas de qualquer forma ele funcionava e passava uma sensação bem mais forte de estar pronto para produção
    Além disso, um dos maiores projetos open source do mundo usava Git, e essa diferença de percepção foi decisiva
  • Agora seria uma ótima hora para alguém comprar o fossilhub.com e criar uma nova comunidade
  • Fico curioso para entender por que o Git é mais rápido em repositórios grandes
    Mas lembro que, por um tempo, essa vantagem não aparecia tanto assim ao lidar com blobs grandes
• Acho que o papel do GitHub como arquivo foi, na verdade, algo ruim
  Quando existe um serviço centralizado útil 99% do tempo, a capacidade de preservação da comunidade como um todo se atrofia
  Se a estrutura exigisse que alguém realmente semeasse algo para mantê-lo vivo, as pessoas provavelmente segurariam melhor cópias daquilo que consideram importante de verdade
  O problema é que ficou fácil demais presumir "depois eu faço checkout de novo"
  Não deveria existir um único lugar de onde algo pode ser removido
  Quando um projeto no GitHub leva um DMCA, até os forks desaparecem junto
  Quando a Nintendo derrubou um emulador popular de Switch em 2024, a preservação e a continuação do trabalho só foram possíveis encontrando alguém que tivesse feito checkout da revisão mais recente e colocando isso para rodar de novo
  E isso só foi possível porque era um projeto extremamente popular: https://news.ycombinator.com/item?id=40254602
  Aliás, a animação de cabeçalho/rodapé com vibe de Splatoon neste site é muito boa
  Ela não incomoda, dá personalidade ao ambiente e sai imediatamente do caminho quando você rola a página, então dá até vontade de copiar isso descaradamente
  • Isso também acabou criando uma sensação de que, se não está no GitHub, então não existe
    Parece haver desenvolvedores demais que nem sabem que código pode ser hospedado em outros lugares
  • Arquivar em si é fácil, mas copyright e as leis de propriedade intelectual atrapalham
    Se houvesse menos barreiras para tornar a informação acessível, também haveria menos concentração de poder
  • Não concordo com isso
    Um dos motivos de o GitHub ter conquistado confiança ao longo dos anos é que, até agora, ele ainda não monetizou diretamente esse papel de arquivo
    Claro, olhando os novos recursos relacionados ao Copilot, não sei como isso será daqui para frente
    Se a alternativa for fragmentar tudo em vários sites, isso só significa ter regras de DMCA diferentes em cada um
    Então acabo me perguntando qual seria exatamente a alternativa melhor
• Ler textos assim me faz olhar para a trajetória dos projetos de que participei
  A maior parte do meu trabalho em open source aconteceu sobre infraestrutura self-hosted, e o principal exemplo é o Xfce
  Quando participei pela primeira vez, em 2004, lembro que havia um servidor SVN e talvez uma interface web com suporte novo a SVN no CVSweb
  Acho que foi depois que entrei para o time central que configurei o Bugzilla, embora isso também possa ter sido outra pessoa
  Quando o Git começou a virar o padrão, liderei a migração de um grande repositório SVN para vários repositórios Git e também coloquei uma interface web com cgit
  Até então ainda usávamos Bugzilla
  Por volta de 2009–2010, entrei em uma startup pequena e tive menos tempo para OSS, então saí do projeto e só voltei em 2022; nesse meio-tempo, tinham montado uma instância do GitLab com runners de CI e também migrado o Bugzilla para issues do GitLab
  Ainda hoje o número de pessoas ativas é pequeno e a administração da infraestrutura continua quase toda nas mãos de uma única pessoa, mas dá para tocar tudo tranquilamente com uma equipe pequena
  É uma grande sorte que a infraestrutura seja fornecida por patrocínio, e só com doações recorrentes já parece viável pagar os custos diretamente se preciso
  Acima de tudo, é muito bom não depender de GitHub/Microsoft
  Se alguém tivesse me dito 20 anos atrás que a Microsoft acabaria sendo dona da maior forge de código OSS do mundo, eu quase teria vomitado, e isso ainda hoje continua me incomodando muito
• Isso costuma passar batido, mas o login compartilhado também foi importantíssimo
  O Rust roda testes em todo o ecossistema de projetos Rust com uma ferramenta chamada crater, e, quando era preciso abrir manualmente centenas de issues para encontrar projetos que dependiam da implementação interna do Cargo, um fluxo com menos atrito ajudava muito
  Se você já tem as credenciais do site e ele ainda permite um template vazio, abrir 200 issues fica bem mais fácil
  Em contraste, quando encontro uma instância self-hosted, normalmente é ali que eu desisto
• Eu já publicava no Planet Source Code desde antes de existir o SourceForge
• Eu gostava muito do Trac
  Configurar o Trac como primeira etapa ao iniciar um novo projeto open source tinha um atrito quase inacreditável, mas mesmo assim eu gostava
  O Django continua rodando em Trac há mais de 20 anos: https://code.djangoproject.com/timeline
  Não fui eu quem configurou isso, mas talvez eu tenha ajudado a subir um Trac privado anterior a esse
  • O Trac era realmente muito bom
    Mas meu primeiro issue tracker foi o Bugzilla, e a configuração era bem sofrida, além de ele não se integrar tão bem com outras ferramentas
    Mesmo assim, havia algo de especial em ver Zarro Boogs
  • O Trac foi, em muitos sentidos, o que me levou a criar apps para deploy em Python em vez de PHP
    O sistema de plugins era realmente excelente
  • Eu gostava do Bitbucket
    Ele cumpria bem o seu papel, nunca chegou a quebrar nada para mim, e eu gostava mais do lado do Mercurial
    Acabei migrando porque as empresas usam GitHub, mas até hoje trato o GitHub só como um endpoint meio sem graça de Git, e faço build/deploy com Docker e scripts de shell, então o custo de mudar é muito baixo
    No trabalho, quando não tenho poder de decisão, acho que basta usar a ferramenta paga como acontecia na época do SVN e pronto
  • Curiosamente, na época eu detestava o Trac e, ainda assim, hoje só me restam boas lembranças dele
    Eu sentia que ele tentava fazer coisas demais e não era excepcional em nenhuma
    Hoje esse papel provavelmente ficou com o GitLab, e talvez no futuro eu também me lembre dele com carinho
• Fui pesquisar serviços de arquivamento de código por curiosidade e vi alguns exemplos
  Existe até um programa do próprio GitHub: https://archiveprogram.github.com/
  E também existe o Software Heritage, uma organização sem fins lucrativos apoiada pela UNESCO: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
  Mas isso parece focar mais em preservar o código e o histórico de commits, e não lida tão bem com metadados periféricos como issues, PRs, discussões e wikis
• Acho que fui uma das pessoas que usou Flask quase no começo
  Aprendi Python para aproveitar o AppEngine, que era uma hospedagem moderna, simples e gratuita, e por causa disso eu estava exatamente no lugar certo quando o Flask apareceu
  Admiro o Armin há muito tempo, e reconheci o domínio antes mesmo de clicar no link
  Também concordo com ele quando diz que, naquela época, o padrão não era automaticamente usar GitHub
  Também me impressiona que este texto seja uma resposta ao post do Mitchell de algumas horas atrás, e surpreende que ele tenha escrito tão rápido algo longo, bem estruturado e de alta qualidade
• Isso me faz lembrar do code.google.com
  Ainda acho inacreditável que o Google tenha deixado escapar uma oportunidade tão grande assim
  • Dá uma nostalgia enorme
    Eu estava nesse time antes de o serviço ser encerrado