O GitHub está enfrentando problemas GIGANTESCOS!
MMaximilian Schwarzmüller
Computing/SoftwareBusiness NewsManagementInternet Technology
Transcript
00:00:00O GitHub está em uma situação muito terrível, muito ruim.
00:00:04Há muitos, muitos problemas, muitos deles relacionados à IA,
00:00:08mas talvez não pelas razões que você imagina,
00:00:10mas voltarei a isso.
00:00:11E, claro, isso importa.
00:00:13Isso importa porque o GitHub é a espinha dorsal
00:00:16do trabalho de desenvolvimento moderno.
00:00:17Não importa se você faz desenvolvimento de código aberto,
00:00:20se mantém alguns projetos de código aberto,
00:00:22se trabalha apenas em seus próprios projetos,
00:00:24seus projetos pessoais, seus projetos paralelos,
00:00:26se você administra uma pequena empresa,
00:00:29ou talvez se você estiver em uma empresa maior,
00:00:32ele é usado para todo tipo de coisa como um arquivo de código
00:00:35para fluxos de CI/CD, para colaboração,
00:00:38para trabalhar em projetos juntos, por meio de issues,
00:00:42para pull requests e muitas outras coisas e casos de uso.
00:00:47Então isso importa, mas como mencionado,
00:00:49há muitos, muitos problemas.
00:00:51E vamos começar com o que está errado
00:00:53antes de darmos uma olhada no porquê
00:00:54e no que isso significa para o futuro.
00:00:57E vamos começar com um grande problema.
00:00:59Houve uma vulnerabilidade de segurança grande, enorme,
00:01:02inacreditável, relatada ontem
00:01:07enquanto estou gravando isto.
00:01:09Uma execução remota de código no github.com.
00:01:12Digo, ler isso é simplesmente insano.
00:01:16Foi descoberto pela Viz, uma empresa de segurança,
00:01:19e não foi explorado.
00:01:21Então foi descoberto, foi relatado, foi corrigido.
00:01:25Nenhum dano foi causado.
00:01:28De acordo com o GitHub,
00:01:31eles também publicaram uma resposta a este relatório.
00:01:33Agora, não vou entrar nos detalhes
00:01:36de como essa vulnerabilidade funcionava.
00:01:39Vou deixar o link do artigo abaixo, no entanto.
00:01:42Mas, no fim, tudo funcionou através do git push.
00:01:44Portanto, sem phishing envolvido,
00:01:46sem invasão de conta de algum funcionário,
00:01:49sem ataque à cadeia de suprimentos.
00:01:51Vimos muito disso nas últimas semanas,
00:01:54mas não, nada disso estava envolvido.
00:01:56Em vez disso, foi apenas git push,
00:01:58e especificamente o recurso padrão de opção de push
00:02:03que você pode adicionar ao comando git push
00:02:05para anexar opções extras a esse comando de push.
00:02:10E por meio desse recurso de opções e da vulnerabilidade
00:02:13e da maneira como o GitHub lidava com pushes,
00:02:17os pesquisadores de segurança conseguiram anexar código
00:02:22que seria executado assim mesmo nos servidores do GitHub.
00:02:27Novamente, os detalhes exatos estão neste relatório,
00:02:31mas, no fim, eles abusaram do fato
00:02:34de que você poderia adicionar metadados extras a um cabeçalho xstat
00:02:39que seria preenchido com a ajuda dessa flag de opções de push.
00:02:44E esses metadados, essa informação que você podia passar
00:02:49com a solicitação de push através desse cabeçalho,
00:02:52não foram sanitizados pelo GitHub.
00:02:54Eles apenas autenticaram a solicitação de push no final,
00:02:58o comando de push.
00:02:59Eles verificaram se você tem permissão para dar push
00:03:01no repositório que está tentando,
00:03:03mas então eles pegaram esses dados de opções
00:03:07e montaram aquele cabeçalho xstat sem sanitizar os dados.
00:03:12E isso permitiu aos pesquisadores de segurança
00:03:15executar um comando que não estava restrito
00:03:18ao repositório para o qual eles deram push,
00:03:21mas que, em vez disso, rodou livremente nos servidores do GitHub
00:03:24e foi capaz de acessar outros repositórios também,
00:03:27incluindo repositórios privados.
00:03:29Agora, novamente, esta vulnerabilidade foi relatada e corrigida
00:03:33e não existe mais,
00:03:35mas é algo enorme, obviamente.
00:03:39Digo, é um problema gravíssimo ter uma vulnerabilidade
00:03:43que permite a execução remota de código no github.com.
00:03:45É realmente gigante.
00:03:47Então sim, esse é um grande problema,
00:03:48mas é claro que não é o único.
00:03:51Em 23 de abril, apenas alguns dias antes,
00:03:56houve um incidente enorme relacionado às merge queues do GitHub.
00:04:01As merge queues do GitHub, caso você não saiba,
00:04:04são um recurso destinado a repositórios
00:04:07onde há muita atividade, muito trabalho ativo,
00:04:11muitos pull requests chegando.
00:04:13E para garantir que você não precise mesclar
00:04:16cada pull request antes que um novo possa ser enviado,
00:04:19porque, claro, você quer ter um pull request
00:04:21em relação ao estado mais recente do repositório,
00:04:24da branch principal, por exemplo,
00:04:26a fim de garantir que você não tenha que mesclar
00:04:28cada pull request antes que um novo possa ser aberto.
00:04:30No fim das contas, esse recurso de merge queue existe,
00:04:34que tem o objetivo simples de criar, efetivamente,
00:04:38tipo uma mesclagem intermediária antecipada
00:04:42de criar um novo estado do repositório da branch
00:04:46que você estava tentando mesclar para cada pull request.
00:04:49E se um novo pull request for adicionado
00:04:51à cadeia de pull requests,
00:04:53ele também já é mesclado e combinado com os pull requests
00:04:57à frente dele na branch principal
00:04:58para que novos pull requests sejam abertos
00:05:01como se os pull requests anteriores já tivessem sido mesclados.
00:05:05E isso simplesmente permite que as equipes trabalhem mais rápido
00:05:08porque você pode abrir mais e mais pull requests
00:05:10sem precisar que os anteriores terminem primeiro.
00:05:13Em algum momento, claro, eles serão mesclados,
00:05:15mas isso permite que você continue trabalhando,
00:05:17o que, obviamente, é importante para grandes equipes.
00:05:19Agora, o que também é importante em relação a esse recurso
00:05:22é, claro, que ele funcione corretamente.
00:05:24E o que aconteceu no dia 23 de abril foi
00:05:28que houve um erro, um erro de lógica interna
00:05:32em como o GitHub resolvia esses diferentes pull requests
00:05:37de modo que, por fim, ele criava uma mesclagem
00:05:41que descartava algumas informações, o que levaria
00:05:45a um commit inválido e eliminaria partes
00:05:49do histórico do Git ali.
00:05:50Os dados não foram realmente perdidos,
00:05:53mas este recurso funcionou incorretamente
00:05:55e produziu aquele commit incorreto.
00:05:57Essa é a versão curta, a essência da coisa.
00:06:00E, claro, também é totalmente inaceitável
00:06:03se você for uma grande empresa ou qualquer empresa que dependa
00:06:06desse recurso e, de repente, seu projeto acaba
00:06:09em um estado quebrado sem que você tenha uma explicação clara
00:06:13para isso; isso é inaceitável, é claro.
00:06:16E seu primeiro pensamento, claro, provavelmente não é
00:06:19que existe algum bug interno nesse recurso de merge queue.
00:06:23É provável que você ache que fez algo errado.
00:06:26Então você gasta muito tempo procurando o erro
00:06:28até descobrir que, oh não, é o GitHub.
00:06:30E tudo isso, claro, vem em adição
00:06:33aos problemas contínuos de estabilidade que o GitHub tem.
00:06:38Agora, a página de status oficial parece ruim,
00:06:42mas talvez aceitável, mas não temos o padrão de "três noves"
00:06:46de disponibilidade aqui também, pelo menos para a maioria dos sistemas.
00:06:49Eles relatam a disponibilidade separadamente para diferentes sistemas.
00:06:53Mas as coisas parecem um pouco diferentes se olharmos
00:06:55para a página de status independente do GitHub,
00:06:57que rastreia a disponibilidade de uma maneira diferente
00:07:00e conta cada pequeno incidente como um problema,
00:07:04como um tempo de inatividade no final das contas.
00:07:05Aqui temos uma disponibilidade horrível para um sistema tão crucial
00:07:10como o GitHub, totalmente inaceitável, é claro.
00:07:14Portanto, tivemos problemas de estabilidade nos últimos meses
00:07:18e até mesmo no ano passado já.
00:07:20E também houve bugs menores aqui e ali,
00:07:23apenas não tão grandes quanto este ou tão importantes
00:07:26quanto esta vulnerabilidade de segurança.
00:07:28Mas sim, há muitos problemas
00:07:31e o GitHub definitivamente se tornou uma plataforma não confiável
00:07:36neste momento, infelizmente,
00:07:38o que é um desastre dado o seu papel e sua importância
00:07:43no desenvolvimento moderno, como eu disse inicialmente,
00:07:47não importa que tipo de trabalho de desenvolvimento você faça.
00:07:50Outro problema é que a comunicação por parte do GitHub
00:07:54tem sido, digamos, pouca.
00:07:59Não tem havido muita comunicação,
00:08:01mas houve um post no blog compartilhado em 28 de abril,
00:08:06antes dessa vulnerabilidade de segurança,
00:08:10onde eles meio que explicam o que está acontecendo,
00:08:14de onde os problemas estão vindo,
00:08:16que eles entendem que sua estratégia de comunicação
00:08:19não tem sido ideal e que as coisas vão melhorar.
00:08:23Essa é agora a próxima parte.
00:08:25De onde vêm os problemas?
00:08:28A declaração oficial aqui cita a IA como um motivo,
00:08:32mas não no sentido de engenheiros do GitHub
00:08:36na Microsoft usando IA e entregando software quebrado,
00:08:40atualizações quebradas para o GitHub.
00:08:43Isso pode estar acontecendo, mas não temos provas disso.
00:08:47Mas, em vez disso, a principal razão citada aqui é, claro,
00:08:51que, devido à IA, há tantos outros projetos
00:08:57sendo criados, muito mais código sendo gerado,
00:09:00e, por fim, todos esses projetos e todo esse código
00:09:03sendo enviados para o GitHub.
00:09:04E eles compartilham alguns, bem, sim, não muito úteis,
00:09:09mas eles compartilham alguns gráficos aqui.
00:09:12Eles não são super úteis porque não temos o eixo y.
00:09:14Não vemos os números absolutos,
00:09:17mas, claro, podemos ver as relações aqui.
00:09:20E podemos, é claro, ver que ao longo de 2025,
00:09:23houve um aumento acentuado nos pull requests mesclados,
00:09:28commits enviados e, claro, também novos repositórios abertos.
00:09:32São todos os nossos projetos paralelos que estamos criando
00:09:34e não terminando com a IA.
00:09:36E então, em 2026, obviamente para todas essas métricas,
00:09:41o gráfico simplesmente dispara para o alto, eu suponho.
00:09:46Então sim, essa é, obviamente, uma tendência bem clara.
00:09:49E esse tráfego, esse tipo de aumento no tráfego,
00:09:54naturalmente colocaria qualquer sistema sob estresse.
00:09:58É particularmente problemático para o GitHub
00:10:01porque eles estão no meio da migração
00:10:05de uma estrutura monolítica e de seus próprios sistemas
00:10:09ou centros de dados dedicados para a nuvem Azure
00:10:13e para um sistema mais fragmentado, um sistema de microsserviços,
00:10:17poderíamos dizer, em vez daquela estrutura monolítica.
00:10:21Esse já era um processo contínuo antes de entrarmos em 2026.
00:10:26Mas é claro que isso significa que agora esse processo de migração
00:10:31é atingido por esse pico de demanda,
00:10:34o que significa que, embora você esteja migrando,
00:10:36é preciso meio que estabilizar o sistema atual
00:10:39enquanto continua a migração,
00:10:40o que, então, espera-se que ajude com esse aumento
00:10:44de tráfego no futuro.
00:10:46Essa é a esperança, é claro, não há garantia.
00:10:50Mas, obviamente, é algo com que o GitHub tem que lidar.
00:10:52Agora, eles afirmam aqui que começaram a executar um plano
00:10:56para aumentar a capacidade do GitHub em 10x em outubro de 2025.
00:11:01Então pode-se dizer que por aqui eles viram:
00:11:04"Bem, isso tudo está subindo".
00:11:06Digo, eles já podiam ver isso de antes,
00:11:09mas foi aqui que decidiram que precisamos aumentar nossa capacidade em 10x.
00:11:13E então, em fevereiro de 2026, eles viram:
00:11:16"Ok, precisamos de 30x, não 10x", porque, bem,
00:11:20por causa daquele desenvolvimento aqui, certo?
00:11:22Isso, é claro, deve ser feito além daquela migração.
00:11:28E essa é uma tarefa enorme, obviamente.
00:11:33Agora, ele faz parte da Microsoft, então não é uma startup pequena,
00:11:37mas, ainda assim, é uma tarefa desanimadora.
00:11:39E este é um aspecto de todo esse problema do GitHub
00:11:44pelo qual tenho certa simpatia, porque acho que é fácil
00:11:47odiar o GitHub, zombar do GitHub.
00:11:51E você definitivamente pode fazer isso.
00:11:52E voltarei a mais problemas, que são realmente ruins.
00:11:56Mas esse tipo de aumento de tráfego seria um problemão
00:11:59para qualquer sistema, para qualquer empresa por aí.
00:12:03E é difícil acreditar que qualquer concorrente do GitHub
00:12:07se sairia melhor nesta situação.
00:12:09Ainda assim, é claro, isso não é desculpa.
00:12:10Faz parte da Microsoft.
00:12:12E, portanto, eles com certeza têm os recursos
00:12:16para passar por essa transição e ajustar seus sistemas
00:12:20a este novo mundo e a este novo volume de tráfego.
00:12:24Mas há outro problema importante aqui com o GitHub.
00:12:28E é que ele não tem mais um CEO.
00:12:32O CEO anterior, Thomas, Thomas Domke,
00:12:37aposentou-se, saiu ou anunciou que sairia
00:12:41em agosto de 2025.
00:12:43E a Microsoft não designou um novo CEO.
00:12:48Em vez disso, o GitHub tornou-se parte da Core AI,
00:12:51uma divisão interna da Microsoft que, como o nome sugere,
00:12:56trata inteiramente de IA e da criação de ferramentas e plataformas de IA.
00:13:01E o GitHub faz parte disso.
00:13:03Então, claramente, a missão do GitHub na perspectiva da Microsoft
00:13:07é tornar-se parte dessa cadeia de ferramentas de IA,
00:13:11dessa revolução da IA.
00:13:13E, obviamente, a Microsoft está empurrando o Co-Pilot
00:13:15em todos os seus produtos.
00:13:16E, de fato, no GitHub Universe 2023,
00:13:20eles já disseram que transformarão o GitHub
00:13:24na plataforma de desenvolvedores movida a IA
00:13:28com o GitHub em todos os lugares.
00:13:30Isso inclui coisas como novos recursos
00:13:32que ajudam a criar issues com o GitHub Co-Pilot,
00:13:36o que é um problemão para mantenedores de código aberto,
00:13:39mas também apenas a presença pura do GitHub Co-Pilot
00:13:43em todos os lugares no GitHub.
00:13:44Existe essa coisa de Agent HQ aqui no GitHub,
00:13:48[github.com/copilot](https://github.com/copilot),
00:13:49onde você pode interagir com o GitHub Co-Pilot
00:13:52e trabalhar no seu código diretamente de dentro do GitHub Co-Pilot
00:13:55sem nunca abrir uma IDE local ou ferramenta de agente de código
00:14:00e muitas, muitas outras partes.
00:14:02O GitHub Co-Pilot está em todo lugar no GitHub,
00:14:05assim como o Co-Pilot está em todo lugar
00:14:07em todos os produtos da Microsoft, eu suponho.
00:14:10E isso, é claro, é uma decisão estratégica clara
00:14:14que meio que vai contra a missão real do GitHub,
00:14:19pelo menos a missão que o GitHub tinha no passado.
00:14:23Porque, como mencionei no início,
00:14:25o GitHub é importante para diferentes tipos de desenvolvedores
00:14:29para todos os tipos de casos de uso.
00:14:31Mantenedores de código aberto o usam para ter seu código-fonte
00:14:36lá e colaborar com outros mantenedores
00:14:39e outros colaboradores da comunidade.
00:14:41As issues são vitais para detectar, bem, problemas
00:14:45e trabalhar neles.
00:14:46Os pull requests são importantes para que outras pessoas
00:14:50contribuam com a base de código.
00:14:52As discussões podem ser ótimas para debater novos recursos
00:14:55ou rumos de um repositório ou de uma biblioteca e assim por diante.
00:15:01Há muitos recursos relacionados aqui
00:15:03que ajudam os mantenedores de código aberto
00:15:04ou, pelo menos, ajudaram no passado.
00:15:07Outras pessoas usam o GitHub apenas como um recurso
00:15:11para hospedar links ou documentos
00:15:13como todos esses repositórios "awesome": awesome Go, awesome Rust
00:15:17e assim por diante, que você pode usar para achar recursos facilmente
00:15:20se quiser trabalhar com Go ou Rust.
00:15:22Eu também uso o GitHub para hospedar os recursos dos meus cursos
00:15:26como aqui para o meu curso de Codex, por exemplo,
00:15:29e para muitos outros cursos também.
00:15:31Então você pode até "abusar" do GitHub
00:15:33apenas como um tipo de armazenamento de documentos.
00:15:36E então, é claro, você também pode usar o GitHub para trabalho de CI/CD.
00:15:40Em uma empresa, você pode estar usando o GitHub
00:15:43para, obviamente, ter seu código-fonte lá,
00:15:46para ter os membros da sua equipe colaborando naquele código-fonte
00:15:50com pull requests e assim por diante.
00:15:52E então, é claro, o GitHub frequentemente
00:15:54também faz parte do pipeline de CI/CD,
00:15:57onde um novo push para a branch principal, por exemplo,
00:15:59dispara um pipeline de CI/CD.
00:16:02Isso poderia ser com a ajuda do GitHub Actions,
00:16:05embora esse produto tenha seus próprios problemas.
00:16:08Mas, é claro, também poderia ser para disparar um pipeline de CI/CD
00:16:12em qualquer outro provedor de CI/CD, não apenas no GitHub Actions.
00:16:16Então o GitHub, claro, tem um papel muito importante
00:16:20para o trabalho de desenvolvimento clássico e tradicional.
00:16:24Mas, obviamente, a Microsoft decidiu que não,
00:16:27ele deve se tornar uma plataforma de desenvolvedor baseada em IA,
00:16:31não apenas uma plataforma de desenvolvedor.
00:16:33E isso, com certeza, é um tipo de incompatibilidade aqui.
00:16:37Os desenvolvedores não querem necessariamente o Co-Pilot
00:16:41em todos os aspectos do GitHub.
00:16:43Eu suponho que os usuários de produtos da Microsoft em geral
00:16:46não queiram o GitHub em todos os seus produtos,
00:16:48mas isso é outra história.
00:16:49E o GitHub vem negligenciando os recursos principais
00:16:53que são importantes para os desenvolvedores.
00:16:56E digo, pegue o trabalho de desenvolvimento de código aberto.
00:17:00Os mantenedores de projetos de código aberto estão se afogando
00:17:03em issues e pull requests gerados por IA.
00:17:07Agora, o problema aqui, é claro, é a assimetria.
00:17:10É fácil usar IA para gerar código ou issues.
00:17:14É muito mais difícil revisar tudo isso.
00:17:19Ou seja, revisar aquele código gerado e aquelas issues geradas.
00:17:24E digo, isso é algo que todo desenvolvedor sabe,
00:17:26qualquer um que já tenha trabalhado com IA.
00:17:27Você pode facilmente acionar três agentes de IA ou mais
00:17:30e fazê-los trabalhar nos seus projetos,
00:17:32totalmente fora do GitHub.
00:17:33Você pode fazer isso na sua máquina com o Codex,
00:17:35Claude Code e assim por diante.
00:17:36Mas então, se você não for pelo caminho do "vibe coding",
00:17:39o que não deveria, na minha opinião,
00:17:41você tem que revisar aquele código em algum momento.
00:17:44E isso leva tempo.
00:17:45E não é muito divertido, pelo menos para mim.
00:17:48Agora, se você acionar três agentes,
00:17:51você tem que revisar a entrega de três agentes.
00:17:54Você pode reduzir a quantidade de agentes se for demais
00:17:57para você e sentir que não está sendo produtivo
00:17:59dessa forma.
00:18:00Agora, quando você é um mantenedor de código aberto no GitHub,
00:18:03você está se afogando em issues e pull requests gerados por IA
00:18:07e basicamente tem duas opções principais.
00:18:09Você pode ignorá-los, o que meio que anula o propósito deles,
00:18:13é claro, mas é uma estratégia válida, obviamente.
00:18:16Ou você tenta lidar com eles
00:18:18e acaba sofrendo burnout porque é simplesmente demais,
00:18:21porque ao contrário do seu trabalho de desenvolvimento pessoal,
00:18:25você não pode simplesmente reduzir a quantidade de issues
00:18:29e pull requests que chegam.
00:18:30Você pode usar menos agentes por conta própria
00:18:33se achar que não está sendo eficaz ou produtivo
00:18:36com todos os agentes que está tentando rodar.
00:18:38Você não pode fazer isso com os repositórios públicos.
00:18:41Você não controla quantas pessoas vão postar issues
00:18:45geradas por IA ou enviar pull requests para você.
00:18:49Portanto, esse é um problema enorme para mantenedores de código aberto
00:18:53e o motivo pelo qual toda a cena do código aberto
00:18:56e a filosofia por trás do open source
00:18:59estão enfrentando grandes problemas agora por causa da IA.
00:19:04E o GitHub não está ajudando com isso.
00:19:06Em vez disso, eles estão fazendo o oposto.
00:19:08Eles estão ativamente facilitando o compartilhamento
00:19:13de issues de baixo nível geradas por IA e assim por diante.
00:19:15O que mantenedores e desenvolvedores precisariam
00:19:18seriam ferramentas mais eficazes para lidar
00:19:22com todas essas issues e pull requests gerados por IA.
00:19:25Mas o GitHub não está trabalhando nisso.
00:19:27Não faz parte da estratégia deles, eu suponho.
00:19:29Agora, talvez isso mude.
00:19:30Aquele post oficial do GitHub que mencionei antes
00:19:35fala primariamente sobre os problemas de confiabilidade e uptime
00:19:39e que eles querem ser mais transparentes e tudo mais.
00:19:41Mas eles também mencionaram que têm um compromisso
00:19:44em apoiar os desenvolvedores.
00:19:46Veremos, não estou muito otimista
00:19:49porque, no fim das contas, faz parte da Microsoft
00:19:52e eles têm sua própria estratégia aqui.
00:19:55Mas o que isso significa para o GitHub então?
00:19:59É hora de migrar para fora?
00:20:02Tenho ouvido algumas vozes aqui e ali no X
00:20:05dizendo que agora é a hora de uma alternativa ao GitHub.
00:20:08Eu sei que alguns projetos já migraram.
00:20:12SIG talvez seja o mais proeminente.
00:20:15Eles migraram do GitHub para o Codeberg em novembro de 2025.
00:20:20Mas vamos ser realistas aqui.
00:20:22Por um lado, como mencionei antes,
00:20:24a quantidade de tráfego que está atingindo o GitHub
00:20:28sobrecarregaria qualquer concorrente também.
00:20:31Provavelmente até mais do que o GitHub
00:20:32porque eles não fazem parte da Microsoft.
00:20:35Portanto, definitivamente não veremos o GitHub ser substituído.
00:20:40E embora alguns projetos individuais,
00:20:42especialmente projetos de código aberto, possam sair do GitHub
00:20:45por razões que eu consigo entender perfeitamente,
00:20:48todas aquelas empresas, todos aqueles desenvolvedores individuais
00:20:52provavelmente não migrarão.
00:20:54O GitHub tem, apesar de todos os seus problemas,
00:20:57uma plataforma rica em recursos que são integrais
00:21:02nos fluxos de trabalho e no dia a dia de muitos desenvolvedores.
00:21:06Especialmente para empresas, é claro,
00:21:08não é fácil para elas simplesmente substituir o GitHub
00:21:11por algum outro provedor.
00:21:13Mesmo que todos os problemas de confiabilidade
00:21:15sejam obviamente problemas enormes para as empresas também,
00:21:18elas serão capazes e estarão dispostas a suportar muito mais dor
00:21:23antes de sequer considerarem se mudar.
00:21:25Tenho certeza disso.
00:21:26O GitHub é simplesmente uma plataforma importante demais.
00:21:30É a plataforma para colocar seu código gerenciado por Git
00:21:35na nuvem e trabalhar nele e colaborar nele.
00:21:39Então tenho certeza de que ele não vai a lugar nenhum,
00:21:43mesmo se a situação piorasse.
00:21:45É claro, eventualmente as pessoas sairiam
00:21:47se o GitHub não estivesse fazendo nada,
00:21:49mas claramente eles estão,
00:21:50pelo menos em relação aos problemas de uptime e confiabilidade.
00:21:55Quanto ao trabalho em código aberto e os problemas lá,
00:21:58e as issues de baixa qualidade geradas por IA, veremos.
00:22:01Mesmo aí, acredito que o GitHub é importante demais
00:22:07e tem vantagens demais para os mantenedores de código aberto
00:22:10simplesmente saírem, pelo menos não todos eles.
00:22:14Mas eu definitivamente entendo se projetos individuais
00:22:17se afastarem do GitHub, então isso pode acontecer.
00:22:20Mas, sim, para as empresas e para o GitHub em geral,
00:22:23ele vai continuar por aqui.
00:22:24Ainda assim, só resta esperar que esta situação aqui
00:22:28seja, talvez, talvez um alerta para a Microsoft.
00:22:33Talvez eles coloquem um CEO de volta no comando do GitHub.
00:22:38Talvez eles entendam sua importância.
00:22:41Talvez eles entendam que se trata de uma plataforma
00:22:45para desenvolvedores e desenvolvimento, não primariamente uma plataforma de IA.
00:22:49Mas, sim, resta esperar.
00:22:52Não sei se e quando isso acontecerá.
00:22:55Mas, enfim, essa é a situação atual do GitHub.
00:23:00Está ruim, está realmente ruim.
00:23:03E continuará ruim no futuro próximo,
00:23:06mas pelo menos a confiabilidade esperançosamente vai melhorar
00:23:11ainda este ano.
00:23:13Veremos, eu suponho.