The painful death of Github

Theo - t3․gg| 00:35:10|Apr 30, 2026
Chapters9
Explains how outages disrupted daily work and made it hard to review pull requests, highlighting the personal and professional stakes.

Theo argues GitHub’s reliability and leadership have collapsed, forcing a reckoning with alternatives like GitLab, Git Ty, and Bitbucket.

Summary

Theo (Theo - t3.gg) delivers a searing critique of GitHub’s current state, arguing that outages, unreliable webhooks, and embarrassing communications erode trust built up over nearly two decades. He recalls how GitHub helped launch careers and foster communities, then details outages where pull requests and webhooks failed for hours. The video dives into a “split brain” incident where things merged and then reverted, creating undebuggable scenarios for deployments. Theo calls out leadership gaps at the top—no CEO, fragmented product and engineering teams, and a governance structure he views as dysfunctional after the Microsoft era. He weaves in a security scare (remote code execution) and the Tanstack name-squatting malware incident, highlighting real risk for open-source maintainers. Ghosty’s Mitchell’s public departure from GitHub serves as a personal blow to Theo, who emphasizes the human cost of platform failures for maintainers. He previews a move to alternatives, contemplates the long-term health of the ecosystem, and ends by inviting discussion on where to go next, while acknowledging sponsorships and the hard truth about bills needing to be paid. Throughout, Theo balances personal history with concrete, data-backed incidents to argue that GitHub’s demise isn’t just outages—it’s a trust crisis with potentially lasting industry impact.

Key Takeaways

  • GitHub outages have progressed from inconvenient to mission-critical failures, with incidents affecting hundreds of pull requests and webhooks for hours.
  • A rival narrative emerged: a ‘split brain’ deployment where merged changes were undone, creating untraceable states in production.
  • Ghosty founder Mitchell is leaving GitHub after 18 years, a move Theo frames as a symbol of declining platform trust for open-source maintainers.
  • Security incidents—remote code execution and name-squatting malware on Tanstack—illustrate real, immediate risk when maintainers cannot get timely help from GitHub or npm.
  • Leadership vacuum at GitHub (no CEO, reporting to a Microsoft executive) is cited as central to the governance and accountability problems.
  • Theo notes a perception shift: GitHub’s stewardship under Microsoft is no longer aligned with the needs of developers and open-source contributors.
  • Alternative tools and platforms (GitLab, Bitbucket, etc.) are positioned as necessary considerations for teams that can no longer rely on GitHub.

Who Is This For?

Essential viewing for open-source maintainers, software developers, and team leads who rely on GitHub daily and are evaluating whether to switch to alternatives or demand reform.

Notable Quotes

"GitHub has meant so much more to me than that. It helped kickstart my career."
Theo reflects on GitHub’s personal and professional impact.
"This is the erosion of trust of one of the most important services holding together the software world in the open source community."
Theo frames the outages as a trust crisis, not just outages.
"There is no CEO of GitHub. GitHub has no leader."
Critique of governance and leadership structure after the CEO departure.
"Mitchell, the creator of Ghosty, is leaving GitHub."
Illustrates real-world impact on long-time maintainers.
"If they were to charge 2x, I would still pay for it. If they were to charge 10x, I would still consider it."
Theo’s contrast between sponsorships and platform reliability.

Questions This Video Answers

  • Why is GitHub experiencing repeated outages and what are the implications for CI/CD workflows?
  • What alternatives to GitHub should open-source teams consider after funding and leadership concerns?
  • How does GitHub’s leadership structure affect software governance and maintainer trust?
  • What security incidents have affected GitHub users recently, and how have they been addressed?
  • How can open-source maintainers protect their projects when critical dependencies show signs of platform risk?
GitHub reliabilityGitHub outagesGitHub leadershipOpen source governanceTanstack malwareGhosty leaving GitHubMicrosoft acquisition of GitHubGitLabBitbucketCI/CD runners
Full Transcript
GitHub is one of the most important tools I've ever used in my life. I can't imagine how different my life would be if I didn't start using it to publish my work 15 years ago. So many of the relationships I have built, so many of the friendships that are core to my existence, so many of the jobs I've had, work I've done, projects I've contributed to, and more happened on and started in GitHub. It is hard to imagine where anything would be in software without GitHub and the incredible stewardship they have shown trying to help the open source community grow and thrive into what it's become today. which is why this hurts me so much. I cannot properly put into words how frustrating it has been watching GitHub die. This isn't just another small outage happening here or there. I could not use GitHub at all yesterday for any of the work that I do on it. I was just trying to look at pull requests, which we have hundreds of open on T3 Code right now and I couldn't because the API that responds with that stuff just wasn't working properly and didn't for the entire workday. I tried at noon and I tried at 6 p.m. and it didn't work at either. And this is just one of the many egregious outages that has occurred on GitHub over the last few weeks. During a separate outage related to pull requests, GitHub successfully reverted random things that had merged prior. That's not just a small like outage where you can't load the page. That is a split brain problem where if you had a web hook that auto deploys when something merges and then it gets unmerged in GitHub, you now have a very, very painful debugging session ahead of you. This is insane. this is the one thing they should never do and it has happened now and that would be enough for me to reconsider everything. But when Kyle, the COO, who I've previously had very high regards and respect for, writes this absolute [ __ ] slop reply where 50% of the words are trying to downplay the severity of the incident. I can't be polite anymore. This isn't just another small blip in GitHub's history. This is the erosion of trust of one of the most important services holding together the software world in the open source community. And this is why we see people like Mitchell, the creator of Ghosty, deciding to leave. There is a lot to dive into here. From the severity of the incidents to the piss poor response that I've seen from the GitHub higher-ups that are responsible to the core leadership failures that led here and most importantly, what the [ __ ] do we do now? Where do we go? GitLab, Git Ty, Bitbucket, I don't know. We have a lot to dive into here. I'm going to resist the urge to do a cringy sponsor transition here because this is a serious thing, but we have bills to pay. Just forgive us. This brand is really cool. I'm sure I trust them a lot more than GitHub right now. And then we'll be right back. You've already heard about today's sponsor. It's Blacksmith. They're the fastest way to run your GitHub actions. And we use them a lot and I'm very happy with them. But I need to be real with you guys. I haven't been able to use them for everything, and that's been really frustrating. I want to use Blacksmith for all of the stuff we do. And that's why I was so sad that our biggest open- source project, T3 Code, couldn't work on Blacksmith. Keyword couldn't because as of yesterday, our build times went from 6 minutes and 11 seconds for the ARM build on Mac to 3 minutes and 23 seconds. And for the x64 builds for the handful of Intel users we still support, they went from 9 minutes to the same 3 minutes and 34 seconds. As you probably guessed, the reason is that they shipped Mac runners. You can finally do any Mac specific tasks you need in CI on Blacksmith instead of overpaying for way slower boxes from GitHub. I'm going to be so real with you guys. If they were to charge 2x, I would still pay for it. If they were to charge 10x, I would still consider it. But they actually charge 60% less than an equivalent GitHub runner. That is hilarious. I've yet to see a bill from these guys because we fall within their free tier. And since our builds are so fast, it's unlikely we'll even hit the minutes limit. If you've ever found yourself waiting for a build to finish, you are wasting your time and you're probably wasting money, too. Fix that now at soy.link/blacksmith. One of the best places to start is here. GitHub's average uptime by month. To be fair, this is a chart that is zero indexed on 99.5%. So in this, the worst cases they were going down to 99.5 where previously they were at 100. While this chart does show meaningful degradation in reliability, it is also worth noting that they probably made changes to how they're tracking their uptime and reliability around this time. So, I don't think this is worth overreading. The uptime that is trackable by their official internal stuff is very different from our experience using the platform and seeing how reliable it is. Mere here made his own alternative GitHub status page, the missing GitHub status page. that does a much better job of tracking how the uptime actually feels when basically anything is down. He tracks it as downtime instead of downtime per service. It's every moment was something down in this window. And if the answer is yes, it counts as down. And when you do it that way, we're down to 86.75% uptime. It's bad and it's getting worse. There isn't even a meme 9 in here. There's no nines. Like we're we're at nearing 85%. And that's just part of the hell that we're in here. like we're we're just getting started because the various types of regressions are egregious. So, we're going to start with the reliability problem because this is the thing pushing many over the edge. GitHub has lots of other problems. There's lots of user experience things they could make better. There's lots of performance things that are horrible. Like just navigating GitHub for a big project is hellish and is unpleasant at best. I wish we could focus on those. I believe me, I have a lot of GitHub UX crashs in me. I crashed out so hard at the GitHub CLI that I had to unlist the video because you guys were mad at me for being so harsh towards it because I think it's absolutely atrocious UX. As much as I want to crash out at all of those things, the reliability is the part that matters here. The other stuff wasn't bad enough that people would actually leave GitHub despite many trying. The issue here is that we can't trust it anymore. And there's different types of reliability issues. There is does this work how it did yesterday? There is does this work right now and there is did the work I do yesterday persist. These are three of the like main categories that I would file under reliability. If you click a button and it does a thing one day and the thing the button does changes the next day, it is not reliable and you'll be scared to click any button going forward if the behavior changes. If you go to use it and it just doesn't work at all in the moment, you now know that this thing is fragile and can't be fully trusted. And if you did work one day and it vanished the next day, everything you do now feels fragile. In the first category here of the way things work changing, GitHub has not been too bad about this. There are problems with like regression of performance where your poll request tab slowly has broken over time and their attempts to rebuild the diff view has made it worse, not better. For the most part, it is finally getting a little better. While I have had my issues with random regressions in the GitHub UX, they are not the focus here. This is not enough for people to really move away from things. Part two is where things start to get iffy. This is the much more traditional you can't trust the thing because it's not up. I still vividly remember the first time I experienced this on GitHub. I was on a trip to LA. If I recall, I was at VidCon in 2022. I'm pretty sure that's where I was. We had an outage on Ping, our video service. We had some important customers trying to use it for an install for a Vtubing thing in person and we needed to make a change to the iPad app that we had done bespoke for this client and the API endpoint that served them. And I got everything working. I tested it. I was at a friend's house who had faster internet because the hotel I was at just did not have good enough internet. So I went to my friend's place. I made the changes. I tested it all on my iPad. Everything was working locally. I merged and I'm using Versell. So it was supposed to auto deploy on merge, but GitHub had an outage. GitHub web hooks was down. GitHub web hooks is the most common way to integrate GitHub with other services for things like continuous integration and deployment. If you want to autodeploy on merge to main, a GitHub web hook is one of the best ways to do that because it will notify an external service, hey, we have code changes. You should deploy them and then it will deploy them. So I merged the changes that had the code we needed and it just didn't deploy. I went and complained to Verscell a whole bunch. Like, what the [ __ ] guys? We made these changes. I can't deploy this code. Like, what's going on? And they let me know that GitHub had an outage for web hooks where only some of them would send, some of them would cue and eventually send, and some of them would just never go out at all. So, they couldn't even give me an estimate as to when my code changes would deploy. So, I had to temporarily rip out the GitHub integration and do a manual deployment using the Verscell CLI with the code on my machine because there was no other way for me to get our deployed servers up to date because something as simple as GitHub doing a [ __ ] simple post request, a curl to another service broke entirely and it was down for two [ __ ] hours. And that was the moment my trust in GitHub started to erode. And that hurt because as I said at the start of this video, GitHub is really important to me. I do genuinely believe I would not be here talking to you guys if it wasn't for GitHub. It helped kickstart my career. It kickstarted my love of coding. It got me way more into seeing how other people built, what they were building, why they were building it, finding where else they are online and following them, keeping up with them, and all these things that I learned to value and love, like the the people who make the software. GitHub was the first platform that was as focused on the people as the software and the process too where it wasn't just for looking at the code. I spent very little time reading code in the code bases on GitHub. I spent a lot more time in the poll request tab. Spent a lot more time on the different people's profiles. I spent more time reading the comments and looking at issues and all of those things. And I had kind of just seen it as a thing that would always be there. One of my hotter GitHub takes is that the Microsoft acquisition was a net positive and that Microsoft was a really good steward of GitHub for a long time. One of the first things that happened when GitHub got bought by Microsoft is they removed the requirement that you were a GitHub Pro paying user to have private repositories. Previously, all your repos had to be public unless you were paying, then you could make them private. So, I've been a proud GitHub Pro user since I was in high school cuz I wanted to have private repos. I still maintain the subscription because once Microsoft bought them, I made enough money to do it and I loved GitHub enough to keep that. Like I have been on GitHub as long as I can [ __ ] remember and I kept the sub because I just wanted to keep supporting GitHub. I like it that much. I use it heavily. I trust it. It I trusted it. And this was the moment that started to change. And I I remember the like internal crisis I went through there cuz it at that moment GitHub felt like it felt like Git, not in the sense that GitHub and Git are the same thing, they're very much not, but in the sense that like the Git install on my machine will always be there no matter what. I kind of felt the same about GitHub. It might have its quirks. It might have its problems. It might be far from perfect, but it was there and it worked and I could trust it. 2022 was when that started to fail for me. And it has gotten much worse since. And that breaks my heart because I still have so many friends there. I still rely on it heavily. It's so important. Like if I do move on from GitHub, that is like a chapter in my life story of like the the moving on part. And I'm far from the only one who feels this way. I mentioned earlier that Mitchell, the creator of Vagrant, Terraform, and Ghosty, is moving on from GitHub as well. We'll go over this article in a bit, but I want to show you a comment he left on HN. Flashbang warning before we get there. I know this is ridiculously dramatic, but it's the truth. I actually cried writing this blog post. Tears hit my keyboard. I'm embarrassed to say, nobody should cry over a software as a service of all things, but GitHub has meant so much more to me than that. All laid out in the post. I have an unhealthy relationship with it. It's given me so much and I'm so thankful for it, but it's not what it used to be. I don't know. We've been discussing it on and off for months. Really started seriously discussing it over a couple weeks ago and made the final decision a few days ago. Putting metaphorical pen to paper and hitting publish made it so very real. I'm sure folks will make fun of me for this. It's a stupid thing, but I truly love GitHub and I hope they find their way. I'm with him on that. [ __ ] sucks. This this is not a thing I want to do. And I have been talking to plenty of my friends at GitHub and apologizing to them for the things I have to do here because the state of GitHub has regressed to a point that is unfathomable. Specifically, now that we have left, does it work right now where it has downtime sometimes and now we're in did the work I did yesterday persist. the fact that this is now a real risk that if you had a pull request where you added a database migration and some new feature to your product and the web hook went out deployed the change and then GitHub didn't persist it, the diff that you have, the commit that you have in prod and the hash for that commit that you have in prod doesn't [ __ ] exist anywhere anymore. That is unfathomable. That is truly unbelievable. That is no longer annoying. It's down. We're now in this uncharted territory where I can't trust the merge button anymore. That is a really scary button to break trust for. As I mentioned earlier, Tom experienced this merge issue where something that came in through the merge queue got deployed and then unmerged. And these types of bugs are impossible to debug after. Like why is prod different than what we have here? Let's remerge the PR and now you're running the same migration twice and things are breaking. It's so horrifying to get into states like that and having to debug split brains where one thing sees a different history than the other. This is the problem that Git was meant to solve and GitHub was going to be the place where we managed all of that and it can no longer be trusted. But again, and I am so sorry to my friends at GitHub. The crash begins now. Kyle is the chief operating officer at GitHub. As I said before, we've had good interactions. I wouldn't call him a friend. I would definitely call him an acquaintance. I would imagine that before this moment, if we ran into each other at an event, we'd probably go grab drinks after. I am sorry for what I'm about to do, Kyle. This is an offensive response. This is a pitiful, pathetic response to what happened here. The severity of the issue is so great that any attempt to downplay it is a slap in the [ __ ] face. Let's just read this verbatim. Wanted to provide more clarity about this. This being the issue where merges are being undone. Yesterday we had a regression in merge Q behavior. Regression in merge Q behavior. It's a light way of putting it where in some cases, squash or rebase commits were generated from the wrong base state. We are many words in here and thus far all we have done is downplay. Making earlier changes appear reverted in branch history. Appear reverted. Are you [ __ ] joking? 2,84 poll requests out of over 4 million merged on April 23rd. Roughly 0.07%. Do you see how many [ __ ] things he just did there? The downtime wasn't the whole day. The downtime was a few hours, but he extended the window to the whole day so he can make the percentage sound as not severe as possible. This is one of the most disingenuous sentences I've ever read from a comm's person from a product I loved. What the [ __ ] How many words were used here to downplay the most severe issue GitHub has arguably ever had? We fixed the issue. We contacted every impacted customer and we're expanding our automated test coverage for merge Q operations. The team will be updating the status page with RCA details as well. Do you understand the severity of almost 3,000 merges being [ __ ] reverted? Clearly you don't because you framed this as a peer reverted and a regression in merge Q behavior. Merge Q behavior in of itself is such a [ __ ] stupid way to put this to anybody saying oh this must be legal or comms forcing them to do things. No abs that's not how legal and comms teams work. I've worked with a lot of them in my career. It's not that. Stop assuming these things while you don't work in the industry. The comm's team would have told him to not post and the legal team would have said just post what we already have on the site. This was clearly written by Kyle and it is clear to me that Kyle genuinely believes this wasn't a big deal. That's why he started it with wanted to provide more clarity, not so sorry that this happened. Notice how there is no apology here. There's a whole lot of words downplaying, not a whole lot of words apologizing. Pathetic. Absolutely [ __ ] pathetic. If I was CEO of GitHub, I'm sorry, Kyle. I would legitimately fire you over this post. This is pathetic. It's insane. Thankfully, that won't happen because not only am I not CEO of GitHub, there is no CEO of GitHub. GitHub has no leader. There is no boss of GitHub. The boss of GitHub is a random VP of AI stuff at Microsoft that is an infraerson that has never written code in their life. and the CTO and COO of GitHub. Report to some random person who's also in charge of Azure, also in charge of C-pilot, also in charge of a bunch of other [ __ ] that isn't GitHub. There is no owner for this [ __ ] to fall on. And as a [ __ ] CEO myself, everything falls on me. When things break in T3 chat, in T3 code, and any of the services we rely on for those things and anything that we build, it goes down to me. It doesn't matter who shipped the bad code or what process led to the thing not going how it's supposed to. In the end, it is my responsibility to fix it, address the problems with the users, own it, and prevent it going forward. You need a [ __ ] CEO and they don't have one. He raised a 60 million seed round to rethink what GitHub looks like. And I am an investor in it. I am hopeful. I think he has a chance of doing things well here. It is still far too early for it to make sense for almost anyone yet. It's currently just a Git workflow, but the future of this could be a new better GitHub type thing. But the CEO of GitHub isn't there anymore, and they chose when he left to not replace him. One more quick flashbang warning. This is the executive vice president at Microsoft who runs the Core AI team at Microsoft. GitHub now directly reports to him without a CEO. GitHub is now much less independent and much more part of Microsoft. His previous roles were CEO of Lace Work, which got acquired, and then he ended up leaving and going to Microsoft in October of 2024. He's also a member of the board at Atlassian. I could say a lot about how that makes me feel, but uh we'll avoid my temptation to do that, as tempting as it is. It's pretty clear this person does not necessarily have the right experience to run GitHub. And also, to be frank, his job is a lot of other things. Even if he didn't have history at Atlassian, he would still be a questionable pick for this role simply because it's not a role anymore. It's just people being forced to report to him directly. I'm not going to entertain the conspiracy theories that maybe he is doing this because he wants Bitbucket to do well, so the thing he's a bored of does better. I wouldn't blame you for making those conspiracies though. So, GitHub has no real leader. To Kyle's credit and to the CTO, who I forgot the name of credit, they are trying their best to step in here, but there are problems. First off, there's nobody that like owns the failures. There's no CEO to come in and be like, I clearly led things wrong. We need to rethink everything if this stuff is happening. If the COO or CTO do that, there's a good chance they just get fired. So without a CEO who isn't fireable, the person who can own the thing and not get punished for it, like without that there is no path forward. And now everyone's just running in circles. And when you combine this with another novel problem that exists at GitHub, everything starts to make even more sense. GitHub has two core teams. They have product and they have engineering. There's a wall between them. There is no overlap between product and edge. They are different teams with different reporting chains and different processes. When I was at Twitch, my immediate edge team where we were building stuff had a product manager on the team reporting to the same person that I was reporting to. We worked together. We were in half our meetings together. He was effectively just part of the team. When the developers went out for like a dinner together, we brought our product manager with us cuz he was part of our [ __ ] team. And that was at Twitch. It doesn't matter if he knows what framework we're using or what patterns we're enforcing or what our new lint rules are. He just needs to make sure the product's good. And generally, a good product manager is somebody who understands the product well. So, at a place like Twitch, a good product manager will be somebody who uses Twitch and watches Twitch and understands Twitch. A good engineer is somebody who can interact with that product manager in such a way to implement the things that they think will make the product better. So, why the [ __ ] at a company that's users are developers is the wall between product and edge bigger than any company I've worked at before? A place where there should not just be less wall. They should be the same thing. Product andge should be the same because the product is ange product. So that separation is [ __ ] nonsense. And the only way this can work, the only way this type of hard separation can work is if there is a shared point they report to. If your tree looks like this, where you have the top and you have two branches where you have on this side you have product and on the other side you have engineering. If this is how your company is structured, I have concerns. But I also like kind of understand because if you have the right leader in place to synchronize these things and move stuff properly, you can make that work. But again, that only works when you have the person at the top here, usually referred to as the CEO. What happens when you remove that? This is what happens. The term for this horrible, broken ass split is a dead company. That's the problem. They already had [ __ ] up company architecture. They already screwed their entire report hierarchy in ways that are indescribably bad. But the only way it could work is with a really strong leader at the top. Like if it was a weak leader, that would be a problem. Always be a problem in a normal scenario. But in scenario where there is literally nobody [ __ ] there, it's over. It's done. And I would love more than anything to be wrong about this. We'll go into that in a sec. There's a few more things I want to cover. First, I want to talk about a fun security incident that just happened as well. This happened today right before I got ready to film. I want to talk about the Mitchell Post. I want to talk about why all the current alternatives suck. So, this is what we're going to do moving forward. I'll start here. Cloud researcher at Whiz managed to pone GitHub today with a remote code execution bug that let him get access to millions of repositories belonging to other users and organizations on GitHub. So now we have yet another type of trust being eroded. And this is the problem. Like GitHub went from something so core that the thought of not trusting it was funny to being one of the least trustworthy places to leave your code because your changes can get reverted. The platform might just be down at any time and now rce is just randomly dropping. When you do a git push- o you can pass arbitrary strings when you make your git push. GitHub will embed those strings in an internal header and doesn't sanitize them. So you could break out of the headers they use internally for receiving your git push and then use that to execute remote code. To their credit, GitHub did deploy a fix the same day. But these are really embarrassing things to happen on a platform as important as GitHub. Absurd. So this hurts trust a lot, too. I'm thankful they fix it so fast. That helps a bit. But everything else hurts so much it cancels out almost. Now we need to talk about the Mitchell post. I've been hearing this one's emotional. It's time to talk about Ghosty leaving GitHub. This one, I'll be honest, kind of pushed me over the edge a bit, too. Mitchell is GitHub user 1,299. He joined in February of 2008. That is so much more legit than me. It's hilarious. I was 12. Writing this makes me irrationally sad, but Ghosty will be leaving GitHub. I'm GitHub user 1299, joining February 2008. Since then, I've opened GitHub every single day. Every day, multiple times per day, or over 18 years, over half my life. A handful of exceptions in there. I'd love to see the data, but I can't imagine more than a week per year. I feel that so hard. I am at about 15 years or so, I think. So, yeah, GitHub is a thing I am very almost like intimately familiar with. The amount of time I've spent on there is insane. GitHub is the place that has made me the most happy. I always made time for it. When I went through tough breakups, I lost myself an open source on GitHub. During college at 4 a.m. when everyone's passed out, let me get one quick commit in during my honeymoon while my wife is still asleep. Yep, GitHub. It's where I've historically been happiest and where I've wanted to be. Even the annoying stuff. Some people doom scroll social media. I've been doomcrolling GitHub issues since before that was a word. On vacations, I'd have bookmarks of different projects on GitHub that I wanted to study. Not just the source code, but the open source processes, how the other maintainers react to difficult situations, etc. Believe it or not, I like this. I believe it because I did the same. A big part of my success personally came from reading through how pull requests got responded to, reviewed, and merged, looking at how issues were triaged, and all these other things like seeing the people who do the work, which is really what made GitHub magical. It wasn't just the source, it was the people editing the source and making the software great. And I got to see that before I knew what any of that meant. It was magical. And if you're not into that, it's fine. But for those of us who are, this is heartbreaking. Some might call this sick, but my hobby and work and passion all align. And for most of my life, they got to also live in one place on the internet, GitHub. Did you know that he started Vagrant, which was his first successful open source project in large part because he hoped it would get him a job at GitHub. I don't think this was public info before, that the reason he made Vagrant is that he wanted to work at GitHub. It's no secret. He said this repeatedly. Oh, actually he did say this before. In his first talk about Vagrant when he was only 20, he joked, "Maybe GitHub will hire me if it's good." GitHub was my dream job. I didn't ever get to work there. Not their fault, but it was the perfect place that I wanted to be. The engineers were incredible, product was incredible, and it was something I lived and breathed every day. I still do and consistently have for these 18 years. Enough time for an entire human to become an adult, all spent on GitHub. Lately, I've been very publicly critical of GitHub. I've been mean about it. I've been angry about it. I've hurt people's feelings. I've been lashing out because GitHub is failing me every single day and it's personal. It is irrationally personal. I love GitHub more than a person should love a thing and I'm mad about it. I'm sorry about the hurt feelings to the people who are working on it. I felt this way for a long time. For the past month, I've kept a journal where I put an X next to every day where a GitHub outage has negatively impacted my ability to work. Almost every single day has an X. On the day I am writing this post, I have been unable to do any PR reviews for over two hours because there's a GitHub actions outage. This is no longer a place for serious work if it just blocks you out for hours per day every day. It's not a fun place for me to be anymore. I wanted to be there, but it doesn't want me to be there. I wanted to get work done and doesn't want me to get work done. I want to ship software and it doesn't want me to ship software. I want it to be better, but I also want to code and I can't code with GitHub anymore. I'm sorry. After 18 years, I've got to go. I'd love to come back one day, but this will have to be predicated on real results and improvements, not more words and promises. I'll share more details about where the Ghosty project will be moving to in the coming months. We have a plan, but I'm also very much still in discussion with multiple providers, both commercial and open source. It'll take us time to remove all our dependencies on GitHub, and we have a plan in place to do it as incrementally as possible. We plan on keeping a readonly mirror available on GitHub at the current URL. My personal projects and other work will remain on GitHub for now. Ghosty is where I, our maintainers, and our open source community are most impacted. So, that is the focus of this change. We'll see where it goes after that. This [ __ ] sucks. Like, I don't know what else to say here. I know a lot of y'all see me as an influencer, but like, I remember the moment that that shifted. Up until around 100,000 subs, I was the open- source guy who happened to have a YouTube channel. And since then, I'm the YouTuber that pretends he does software dev. I get why people think that. Whatever. I'm not going to be mad at you for it. But GitHub is my original YouTube. GitHub is the platform I obsessed over every detail of the platform that I built everything I am on. I wouldn't be here if it wasn't for that. I got my first jobs because I had somewhat impressive projects on GitHub. They weren't even that impressive, but they were there and it was proof. And watching it die, going to GitHub and feeling that like fear and frustration, wondering what's going to break this time. And I was genuinely in disbelief when I went to the poll request tab yesterday to look at some PRs that I had heard Julius mention to just not have it load at all. And I went back two hours later and it still wasn't loading. It's insane. It's genuinely absurd. And I will be real. If you think we're overreacting, I am thankful I've never had to work with you because you don't actually care about software. Like every maintainer I know of real software is beat up [ __ ] hard about this one. And I understand my friends at GitHub's initial reaction being upset with us for going so hard, but it's my responsibility to the reason I have this channel is so I could fight for open source maintainers. That was like the goal from the start. I wanted to bring back the convos I missed from lunch and dinner and advocate for the awesome things happening in the open source developer world. And every one of those maintainers that made me the dev I am today is suffering because of GitHub's inane [ __ ] Even just [ __ ] today, Tanner Lindsley hit me up. If you're not familiar with Tanner, he's the creator of Tanstack, which is an ecosystem of tools that make web development significantly better. Tanner was failed hard by GitHub today because they've been failing him for a long time because GitHub owns npm. npm is how we install packages in the JavaScript world. Tanstack is his org. So, he has tanstack slash, but somebody else squatted on the Tanstack package. He has been reporting this to NPM for months now. Hell, I think it's been years. He tried going the trademark route. He tried going the internal contacts route. He tried going every other route he could. And npm did not budge. They did not do anything about it. They just ghosted him. You know what happened today? Seemingly legitimate packaged handstack seems to have been compromised with a post install script that steals yourv files and xfiltrates them to a remote host. That is not a seemingly legit package. That is a name squat. And because GitHub didn't take the report seriously, there is real malware being shipped under the Tanstack name. This has been verified by socket because remember it's not a legit package. It's not associated with them at all. They don't own that. They don't own the name. They don't own anything. They should. And since GitHub and npm chose to not help an open source maintainer working in perfectly good faith, people are now getting pawned. Their irresponsibility isn't just inconvenient or nice optics things. Like obviously Tanner wanted the Tanstack package. Of course he does. I wanted the T3 package. Like spent money and got it. Despite all of that, the legitimate safety risk of this package not being owned by a real maintainer was entirely ignored. And now malware is being shipped under Tanner's [ __ ] name because GitHub is so incompetent. Not only does GitHub not care about open source maintainers anymore, they're actively hurting them. And open source maintainers already have to work so hard and so thanklessly. GitHub sold to Microsoft for billions of dollars on the backs of these open source maintainers and has just slowly let them suffer since. It's pathetic. It's inexcusable. The maintainer who is name squatting demanded $10,000 from Tanner. Clearly a malicious actor and npm's done nothing. GitHub's done nothing. Microsoft's done [ __ ] nothing. There is no excuse for this. We are past the point. And to go back to where we started here, we're talking about the different types of reliability. I'm going to add one more layer. There's four tiers here of reliability problems. The first is, does it work the way it did before? GitHub's been failing that for a while. People didn't care. Next is, does it work right now? GitHub has slowly been falling apart and now it's barely usable, but that wasn't enough for people to care. Did the work I do yesterday persist? Cannot believe they have now passed this line. that you cannot know for sure when you merge a PR that it stays merged. And now we're at the last level here. Can others steal my work and harm my users? They are failing here, too. In all of the ways a platform can lose trust, GitHub has lost it. In every way that we can rely on a platform, we can't rely on GitHub anymore. And as much as I want to talk about where we can go next, this video is already long enough. So, let me know in the comments what your favorite GitHub alternative is, and I'll be sure to consider it in a very fun, likely similarly long follow-up video about all the alternatives to GitHub that we should explore. And I'm sorry to all my friends at GitHub for this video. I um I I've been debating doing this for over a year now. I was debating this when we were just here, when we were at level two of these four levels. I was on the line about doing this, and I chose not to because I trusted y'all, and I still trust y'all. I want to be wrong about this. I want to see real change happen. I want to see a leader appointed. I want to see the product and edge teams at GitHub merge. I want to see a real road map with real promises to solve these real problems. And I want to know you guys are going to fix it. And then I want to see it fixed. But it would be irresponsible of me to not make this video. I would be failing the reasons I started the channel. I'd be failing my friends in the open source world. I'd be failing my own moral code if I didn't. This is beyond unacceptable. Things need to change. And as much as Microsoft was a decent steward of GitHub for the first few years, it's clear they no longer are. Something severe needs to change, and I don't see it happening right now. And in this moment, I can no longer trust or even recommend GitHub. I don't know. I I have no idea what to even end this on. I'm genuinely beat up by this one. I hate that we're at this point. I really do. And I am so sorry to my friends there. Please fix this. You don't have one more chance. You are in debt of chances. But if I go back to GitHub in the future and it is working better, I'll feel better a bit. But this is no longer like make it right or promise us you'll make it right. This is we're past the point now. From my friends having their names used to hack people and steal their environment variables and credentials to things being reverted randomly to not knowing if I can even see the work my team is doing. It's over there. There's nothing to repair. When there is zero trust, you can't repair trust. There's no foundation to build on anymore because you [ __ ] the whole thing up. It's over. You killed your platform and there's nothing that I think can be done. I would love for you to prove me wrong, but until then, I'm going to go very, very hard evaluating alternatives. Until next time, hopefully your code merges.

Get daily recaps from
Theo - t3․gg

AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.