O mundo do open source antes do GitHub
(lucumr.pocoo.org)- Antes de o GitHub se firmar como a infraestrutura social do open source, os desenvolvedores gerenciavam projetos em infraestruturas operadas por eles mesmos, como Trac próprio, repositórios Subversion e listas de discussão, e até adicionar dependências envolvia bastante atrito e cautela
- O GitHub tornou a criação, descoberta e contribuição para projetos drasticamente mais fáceis, padronizou issue tracker, pull request, CI e mais, e acabou cumprindo até o papel de arquivo do open source
- Ao se combinar com ecossistemas de pacotes como o npm, ocorreu uma explosão de microdependências, e o GitHub se tornou um eixo central do sistema de confiança; porém, hoje essa confiança está se desgastando por causa de instabilidade, confusão na direção dos produtos, ruído de IA e outros fatores
- Com o Ghostty também saindo e movimentos como Strudel e Tenacity migrando para o Codeberg, começam a aparecer sinais dessa mudança; a descentralização aumenta a autonomia, mas também traz o risco de perda de contexto social, como issues, reviews e avisos de segurança
- Em meio a sinais recentes de enfraquecimento da centralidade do GitHub, torna-se mais importante um arquivo público que preserve a memória e reduza a dependência. A próxima era do open source deve manter a memória, mas reduzir as dependências
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 continuidade de cada projeto estavam diretamente ligadas à escolha de dependências
- Uma dependência não era apenas o nome de um pacote; ela vinha junto com a história do projeto, site, mantenedores, processo de release e 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 funcionava como parte do julgamento de confiança
O paradoxo de operar infraestrutura própria e do controle de versão distribuído
- Nos primeiros projetos open source, era comum tudo rodar em servidores operados diretamente pelo próprio projeto, com Trac, Subversion, tarball e documentação
- Havia também estruturas como a do Pocoo, em que vários projetos dividiam juntos o custo do servidor e a carga de operar Subversion, Trac e listas de discussão
- O Subversion era um repositório centralizado, então operar um servidor vinha naturalmente junto, e a casa do projeto era fisicamente clara: o hostname, diretório, instância do Trac e arquivo das listas de discussão
- Mercurial e Git eram sistemas distribuídos, nos quais qualquer pessoa podia ter o repositório completo, branches e histórico, mas na prática o centro voltou a se concentrar no GitHub
- Depois que os sistemas distribuídos de controle de versão venceram, o fato de o mundo inteiro ter se padronizado em torno de um único serviço central gigantesco continua sendo uma grande ironia do open source moderno
A mudança criada pelo GitHub
- O GitHub facilitou a criação e descoberta de projetos e tornou o fluxo de contribuição mais compreensível até para quem não tinha experiência com listas de discussão de desenvolvimento
- Ao oferecer issue tracker, pull request, páginas de release, wiki, páginas de organization, API, webhook e depois CI, ele mudou o padrão básico da 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
- Por um bom tempo, o GitHub funcionou como uma opção padrão muito razoável para publicar projetos open source
- Como mostra a política de manter o GitHub acessível até em países sob sanções dos EUA, a centralização cumpria um papel que ia além de simples hospedagem, servindo também como base pública acessível
GitHub como arquivo
- Uma função menos notada do GitHub era seu papel de arquivo: até projetos abandonados continuavam pesquisáveis, funcionando como um índice do patrimônio comum do software
- Forks, issues antigas e registros de discussão permaneciam disponíveis, e a centralização ajudava a criar uma memória descobrível
- Em contrapartida, antes das grandes plataformas, era comum projetos desaparecerem junto com o vencimento de domínios pessoais, o fim de VPSs ou a ausência dos desenvolvedores
- Como no caso de projetos antigos no PyPI em que só restou o metadata e o pacote real desapareceu, também acontecia de 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 terminou no simples aumento do número de pacotes pequenos; ele se agravou 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 indispensáveis 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 das APIs, manter scripts para importar código externo também era incômodo, e esse atrito fazia as pessoas pensarem 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 capacidade humana de raciocinar sobre ele
- Para responder ao problema de estados de licença pouco claros, o GitHub também tentou uma revisão dos termos de serviço
- Mesmo ao depender de pacotes pequenos, consolidou-se a prática de verificar no GitHub se o repositório existe, se há mantenedor, issues, mudanças recentes, uso por outros projetos e se o código bate com a descrição do pacote
- O GitHub se tornou um dos poucos sistemas que também assume o trusted publishing para registros como o npm, e a perda de confiança no GitHub afeta não só a hospedagem do código-fonte, mas toda a cultura da cadeia de suprimentos
O enfraquecimento do GitHub e sinais de migração
- Recentemente, o GitHub vem perdendo parte da sensação de inevitabilidade que tinha antes por causa de instabilidade, mudanças repetidas de produto, ruído de IA do Copilot e liderança pouco clara
- Por estar no centro da onda de agentic coding, a pressão interna também aumentou, mas a situação atual é descrita como marcada por uma forte sensação de ausência de liderança
- Durante muito tempo, sair do GitHub era algo mais simbólico, mas agora até projetos influentes estão considerando publicamente ou executando essa mudança
- O anúncio de saída do Ghostty do GitHub é tratado como um sinal forte, mesmo que o destino final ainda não esteja totalmente claro
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- Talvez ainda não seja um movimento suficiente para inverter a maré, mas já aparece uma tendência de voltar a ver com mais frequência espaços de hospedagem fora do GitHub
- Como o próprio Git foi originalmente projetado com a ideia de várias casas, encerrar a situação em que uma única empresa é a casa padrão de tudo pode ser saudável para o open source
O custo do retorno à distribuição
- Ao voltar para vários forges, vários servidores e várias comunidades pequenas, a descentralização e a autonomia podem aumentar, e a dependência de mudanças na liderança da Microsoft pode diminuir
- Há também a vantagem de cada comunidade poder escolher seu próprio workflow
- Os problemas atuais do issue tracker do Pi mostram como escolhas de produto do GitHub podem levar a resultados desalinhados da realidade da manutenção de open source hoje
- O GitHub revela aspectos de um design mais orientado a engagement do que à saúde mental dos mantenedores
- Por outro lado, ao migrar para forge self-hosted, servidor Mercurial próprio ou servidor cgit, o código em si pode se distribuir, mas o contexto social pode se dispersar com facilidade
- Issues, reviews, discussões de design, notas de release, comunicados de segurança e tarballs antigos desaparecem muito mais facilmente do que parece
- As listas de discussão, que antes carregavam esse contexto, não acompanharam as exigências atuais e também não oferecem uma boa experiência de uso
- Pode haver um efeito depurador no fato de o software ser esquecido com o tempo, mas se o risco de perda crescer demais, será preciso repensar como realmente usamos sistemas distribuídos de controle de versão
O que é necessário: um arquivo público
- Quer o GitHub continue, quer os projetos migrem para outros lugares, o open source precisa de um arquivo público, estável e sem glamour
- É preciso uma estrutura que impeça o desaparecimento de softwares importantes, e não um serviço focado em vencer no mercado de produtividade para desenvolvedores
- Essa estrutura precisa operar sobre uma base sustentável no longo prazo, como um endowment ou financiamento público
- Arquivos de código-fonte, artefatos de release, metadata e contexto do projeto devem ser preservados em um lugar que não esteja preso ao modelo de negócio ou ao humor da liderança de uma única empresa
- O GitHub se tornou o centro da atividade open source e, por acaso, assumiu também esse papel de arquivo, mas quando sua centralidade enfraquece não dá para supor que essa função continuará automaticamente
- Servidores pessoais e boa vontade por si só nunca foram suficientes para preservar tudo, e o fim de plataformas como Google Code e Bitbucket já mostrou esse vazio depois do encerramento
- 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, para que a deriva de uma única empresa não se transforme tão facilmente em crise cultural para todos
- Permanece a 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 como estado normal permanente a estrutura centrada no GitHub dos últimos 20 anos
3 comentários
É verdade que o GitHub desempenhou muitos papéis importantes até aqui, mas, pelo que me lembro, antes dele os projetos de código aberto eram feitos mais por quem já estava nesse meio, e não era tão comum indivíduos publicarem os seus. Em alguns casos, até dentro das empresas o compartilhamento ficava restrito entre equipes do mesmo time. E contribuir para o open source era visto como uma grande honra por ser aceito como colaborador de um projeto grande; pequenos projetos pessoais nem chegavam a chamar a atenção de muita gente.
Lembro que tudo começou com a mudança no clima da comunidade de desenvolvimento, com as pessoas passando a publicar software abertamente e a usá-lo como forma de ter sua habilidade reconhecida, e também com uma série de coincidências favoráveis, como o git acabar sendo mais adotado entre alguns DVCS. Os concorrentes também ofereciam serviços parecidos, então não acho que tenha sido algo em que o GitHub fosse especialmente melhor.
Na verdade, o problema são as discussões de issue e PR; o próprio git pode ser migrado para outro serviço a qualquer momento. Vi que existia até um projeto que colocava esses três no git, então, usando algo assim, daria para migrar quando quisesse.
Comentários do Hacker News
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
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
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
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
Mas lembro que, por um tempo, essa vantagem não aparecia tanto assim ao lidar com blobs grandes
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
Parece haver desenvolvedores demais que nem sabem que código pode ser hospedado em outros lugares
Se houvesse menos barreiras para tornar a informação acessível, também haveria menos concentração de poder
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
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
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 muitoSe 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
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
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 BoogsO sistema de plugins era realmente excelente
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
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
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
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
Ainda acho inacreditável que o Google tenha deixado escapar uma oportunidade tão grande assim
Eu estava nesse time antes de o serviço ser encerrado