What's next?
Chapters7
Introduces the motivation to leave GitHub due to downtime and unstable merges, and suggests evaluating alternatives.
Explorer Theo’s take on GitHub alternatives like Forgejo/Codeberg, and why the future may hinge on Gen 3 tooling and open-source foundations.
Summary
Theo (t3.gg) walks us through the aftermath of GitHub downtime and recalls why many developers—including Mitchell from Ghosty—are considering alternatives. He weighs open-source options like Forgejo/Codeberg against enterprise-focused choices such as GitLab and Bitbucket, and argues that none feel like a perfect GitHub replacement yet. The video digs into what we actually want from a hosting platform: reliable Git hosting, cohesive CI/CD, a thriving community, and open self-hosting options. Theo credits Forgejo and Codeberg for impressive release pages, good UX in some areas, and strong transparency around outages, while skewering GitLab and Bitbucket on navigability, speed, and integration quirks. He borrows a generational lens—Gen 1 SVN, Gen 2 GitHub-era platforms, and a speculative Gen 3 built around agents and advanced code storage—to frame where things might go. The discussion also touches on Code Storage and Pierre’s ambitious throughput demos, plus Graphite, Entire, and other players reshaping how agents and code collaborate. A recurring note remains: the loss of a shared GitHub-home hurts open-source social graphs and contributor histories, even as we gain more diverse homes for code. Theo ends with a constructive call to try Forgejo/Codeberg, explore new tools, and support the communities building the next generation of code hosting.
Key Takeaways
- Forgejo and Codeberg stand out as compelling self-hosted/open alternatives, with Forgejo powering Codeberg’s platform and offering actionable release views and fast diffs.
- Codeberg demonstrates a lightweight, Go-based backend (Forgejo) that runs faster than Ruby-based rivals and ships useful features like a solid release history and embedded diffs.
- GitLab’s UX reliability issues and long load behaviors were highlighted as barriers to a drop-in GitHub replacement, despite strong enterprise appeal.
- Bitbucket’s Jira-centric workflow promises are downplayed here in favor of direct GitHub parity and smoother navigation, with concerns about overall UX.
Who Is This For?
This is essential viewing for developers and open-source maintainers weighing GitHub alternatives after outages, and for teams considering self-hosted paths (Forgejo/Codeberg) or Gen 3 tooling like Code Storage.
Notable Quotes
"These are the two options I would recommend for Gen 2 because Gen 3 is not even close to ready yet."
—Theo categorizes Forgejo/Codeberg as Gen 2-style open options and frames Gen 3 as still-emerging.
"Forgejo is the actual source code that is running this git backend for your remotes, and Codeberg is the hosted version."
—Clarifies the relationship between Forgejo and Codeberg.
"There’s a big problem with leaving GitHub behind. The community, the home, the history—that’s over now."
—Addresses the social/credibility cost of migration.
"Code storage is one of the primitives that could let us build the next generation of Git hosting."
—Highlights Pierre and Code Storage as a foundational idea for Gen 3.
"If you’re looking for something you can self-host, Forgejo and Codeberg are the legitimate options."
—Summarizes the practical takeaway for self-hosting.
Questions This Video Answers
- What are Forgejo and Codeberg, and how do they compare to GitHub for open-source projects?
- Is there a viable Gen 3 alternative to GitHub that isn’t just a re-skinned GitLab or Bitbucket?
- Why is GitHub downtime prompting a mass migration to Forgejo, Codeberg, and Code Storage?
- Can Code Storage and Pierre’s code backends realistically replace GitHub for high-throughput environments?
- What are the social implications of moving away from a single home for open-source projects?
ForgejoCodebergForgejo ActionsCode storagePierreGitHub downtimeGitLab UXBitbucketGraphiteEntire
Full Transcript
So, you've decided it's time to move on from GitHub. A lot of people have. Myself, Mitchell, the creator of Ghosty, and many other people are realizing that GitHub might not be the safest place for us to be leaving our code now that they're randomly reverting merges and having downtime that is measured in days instead of minutes. We're in a tough spot. So, what are our options? There's tons of alternatives, right? Like GitLab, Bitbucket, Dropbox, Git, Forge, Joe, Codehub, or sorry, Codeberg. So many options, right? I grabbed as many as I could find, and there are a lot, but I have feelings about most of them.
And the bad news is, as great as many of them are, I'm not sure if any of them are quite ready to be a proper GitHub alternative. And even if some of them are ready, the effect this will have on the open source community is tough. I'm going do my best to break down all of the options you should consider, figure out what you should actually move to, if you should move at all, and where things are going to be long term. But if I'm not going to be making money off GitHub sponsors anymore, we're going to have to take a break for a normal sponsor.
Agent coding gets you pretty far, but there are some things that it just can't do. In fact, there are certain things it makes harder. If you have an agent that's able to browse the web, how do you know that agent is the right person? If you're using an agent to use MCP, how do you know that it has the permissions that it's supposed to have? And if you have a user coming to your site, how do you know it's actually them? You can probably try and vibe code this all out, but you're better off using today's sponsor, Work OS.
These guys get off and they get it at all levels. If you're a small startup or a big company or even just a side project, work OS has you covered for free for your first million users. You're probably already familiar with their login components because they're used by everyone from OpenAI to Enthropic to Cursor to T3 Chat. Basically everything is using work OS now. And there's a reason. They understand what we need as developers trying to build off that is business ready. If a Fortune 500 company hit you up right now and said, "Hey, do you have ADP working?
We would love to start a contract with you guys in the next 2 weeks. Do you have that stuff working? Do you know how to handle the sample compliance and all the other weird crap you're going to need to do to get that business onboarded? I certainly don't. I've had to try in the past and it was not fun. With work OS, you just send them a link to the admin portal. That's it. It's so simple. Engine sales shouldn't be blocked on off. Start selling better and shipping more at soyv.link/workos. There's a couple angles we can go here.
I could go through each option individually and explain what's good, bad, and ugly about it, but I want to do a couple other things. First, I want to establish what are we actually looking for. I'm going to start by listing things GitHub already does and arguably does well. First and foremost, place to host Git. I want a serverbacked Git remote that will hold my code that lets me and others work on it at the same time. Part of that is implying a PR workflow, some way for other people to contribute their changes and a system for merging those changes.
Along with that, one of the cool aspects is a community. Be it whether this is profiles, histories, a feed that shows cool stuff, people are doing, stars, all of that type of thing. I think this is one of the coolest parts about GitHub. So, I would like to see this in alternatives. One other piece that I think is pretty important is CI and CD. You know, this probably is GitHub actions. A lot of these alternatives have their own solutions. Some don't. It is important. Here's where I'm going to draw a line for things that aren't part of GitHub, but would be really nice to see.
Things like stable platform. Be really nice if we don't have to worry about it going down all the time. Things like open source, so if you need to host it yourself, you can. Then we'll do a very vague AI native piece here. We'll get to this in a little bit. Don't worry. So with these things established as what we are roughly speaking looking for. Let's start looking at the options that we have. We will start with GitLab. GitLab is the option that most people are referencing, thinking about and citing. GitLab has always seemed to be one of the best options.
I want to think of a good analogy for this. GitLab kind of feels like a bicycle. Makes a lot of sense. A lot of people consider it an option, but everybody just kind of chooses to walk, Uber, or buy a car. We all know we could bike more, but we don't. And the few people who do will tell you in detail all of the things that make biking suck terribly. There is no better way to be convinced to not bike to work than to talk to somebody who bikes to work. I didn't realize how bad things were because I, like most people, thought a bicycle was probably a good idea, but just didn't bother.
Now I'm seeing people who actually use GitLab and they have a lot to say. Josh here has disagreed with me many times in the past. He's we've come around to each other over time and he had a lot to say about GitLab. GitLab was designed by developers with no eye for design, but think they do. The UX is atrocious as if they never use their own product. I'd let GitHub lose another 5 to 10% uptime before I consider switching to Bitbucket before I would consider switching to GitLab. And don't worry, we'll have plenty to say about Bitbucket, too.
But first, we have a beautifully egregious example of terrible loading behaviors. This one was great. He had this page here that has these repos. He clicks one of the repos. It brings him there. Well, it's an org. He goes back and now they're not loading cuz that was hidden under a second loading layer. That is so bad. That is so bad that like navigating back and forth causes content to disappear. We already have the problem where whenever I'm on GitHub, I assume I have to refresh to see what's going on because otherwise I might just lose all of the content.
I fear that constantly when I'm navigating GitHub. GitLab appears to be even worse about that where you can navigate back and forth and have things disappear because they don't refire the API request that they're doing. And that's just the start of it. Jason Cox here broke down significantly more problems that you will see on GitLab. Key frame this as UX monstrosities that make it unusable as a drop in replacement for GitHub. So let's look at the GitLab project itself for these examples. You land on this page. You're honest with yourself. Your reaction should be, "What the [ __ ] am I looking at?
Where's the read me that tells me what I'm looking at?" The answer is that you've scrolled down the page 75%. Yeah, there's the readme. They did make a change where they put more info up the top here specifically because they got flamed on Twitter for this, but it it's Twitter driven design changes. This is a really good point as well. Somehow all of these numbers have the same weight. Does this make sense to you or did you come here looking for releases like everyone else does? Yeah. The reason I look at this section on the side is so I can go to releases quickly.
That is not easy to see because there's all of these different things that are the same weight. How often are you clicking tags or environments and looking through them? This is awful. Now, let's click on history because I want to find some commit that was made last year. Where do I find this? You get infinite scroll. Nope. Search my message. Don't recall the commit message. Author. I can't remember who authored it. Browse files. How do I filter by date? Yeah, here we are in commits. We can very, very slowly infinite scroll. Waiting. Waiting. Okay, there's another chunk.
So, we want to find a commit last year. Good luck. Your best option is to just clone it because you're not going to find it. Back to releases. Let's take a look at the release page. This is what he sees and he has a ton of questions. When was this released? What does 88% complete mean? And was this actually released? Or is it just a random like, oh, it's 89% released? What What does this even mean? If I'm here to download something, what is there other releases? How hard to scroll? Oh, GitLab 1810 is 94% complete.
What does that mean? 189 96% complete even though it's a historical release. No info, no date. Oh, the date is here all the way at the bottom after you scroll through the whole change log. The data that's useful is at the bottom, not the top. At the top, you get these things that are useless to most people. That's really bad. And if you click the commit hash at the bottom, let's click it. That one was the update to the version file. That makes sense. What about the most recent releases? That was also the version file update.
That makes sense. What's he complaining about here? Oh, it's the same one. Cool. That's the commit that updated the version. But I want more of what happened here. How do I get that? Can I see what else went into this release? Can I click something to see all the commits that are between this and the previous one? Can I get more info anywhere here? This is a really bad view and releases are a very important view. Getting these this bad is scary. Now I want to see what changed immediately after because something is breaking right after the release tag and I can't.
There is no next commit button. Why? There's a parent commit. You just can't go the other direction. Yeah. Yeah, I can go to the parent, but I can't go down. Even though this is on main or a release branch. And what's this? Branches with an arrow here. Oh god, that scroll broke a ton of [ __ ] There's the arrow and then branches containing commit. Is this going to navigate me or is this going to open there? Okay, that was hilarious. It did the slide to open and then hung and then pulled after. Like, I'm not trying to be nitpicky here, but I'm going to nitpick cuz this is not something I would actually enjoy using at all.
This is impossible to navigate. Like what? And you might think like, yeah, it's mostly open source though. Can't you fix these things? How big do you think the GitLab code bases? Do you throwing out some fun numbers? 200K, 250K, 1.6 million. Well, considering that the clone isn't even starting to show me the data for the clone after I accepted the signature here. Got a bad feeling about this one. I'm trying. How long is it going to take to clone GitLab from GitLab? It's an open- source repo. It shouldn't matter that I don't have the SSH key.
It's not The SSH key should authenticate who can download that code. Yeah, see it is going. It just took that long. It took 5 minutes almost to start enumerating what it's going to clone. We have 7,59,000 Git objects. This is going to be bad. It is about 5 megabits per second faster to clone from GitLab than it is from GitHub. Let's clock it. It is 12,78,69 lines of code. What the [ __ ] a P 0 file? Okay, that seems to be about 4 mil of it. The rest is 3.8 8 million lines of Ruby, 1.16 million lines of JavaScript, not TypeScript, JavaScript, another mill of Markdown, another mill of JSON, 600K of Vue components, 490K of YAML, almost 90k of just raw SQL, a tiny bit of Go, a shitload of GraphQL.
You you get the idea. You're not vibe coding your way out of the issues here. And apparently, it's Vue 2. It's not even Vue 3. This is an old ass project is the point I'm trying to make. GitLab as a more open alternative to GitHub makes sense in the same way that Azure as an alternative to AWS makes sense. It is similar but just worse in every single way except for uptime. But there is no other benefit to GitLab. I have heard their CI is a little bit more pleasant, that their equivalent of actions is a little nicer to work with allegedly.
I haven't confirmed that myself, but GitLab is just a worse version of GitHub the same way Azure is just a worse version of AWS. If you're okay with that, cool. Maybe you can go use GitLab. But the like harsh reality is that it's just not that great. Like I've tried it many times before in the past cuz I love the idea of a GitHub alternative that I could host myself and use how I want. And in reality, it just hasn't worked out that way. This is a project with 528,000 commits. That is almost half a million commits.
This is an old ass project. And a point I'm going to make, and this is going to come out a lot, generations of product. For an example we can all relate to, I would argue that Sublime Text was the first of a new generation of text editor where it introduced the idea of a minimal text editor that you would extend to have your needs rather than an IDE that came with all the features included. Sublime Text was really good, really cool, awesome. Atom came out, which was a downgrade in many ways, but the accessibility was better and it was open source.
And then Microsoft saw the writing on the wall and made VS Code taking all of those lessons. I would argue VS Code is one of the best versions of that generation of product. And then we had cursor which was trying to improve that generation of product using AI. But there's a pretty clear path in my opinion from Sublime to Atom to VS Code to Cursor. And I would argue all of these are the same generation. And the previous generation would be things like Visual Studio, things like Eclipse, Jet Brains, all those types of tools are the previous generation of developer experiences, developer environments.
Sublime kickstarted the nextG. Sublime was the worst version of the next generation. Cursor was in many ways the best version of that same generation. But now we have had another generational shift. We're moving towards different methods and user experiences for coding entirely. We're moving into things like cursors glass view or T3 code or the codeex app stuff like that where T3 code means I'm using VS Code a lot less and it feels fundamentally different but it is a new generation of product and I would argue things like T3 code are like Sublime where they are entirely different from how we did things before and they are in many ways the worst it will ever be.
The real sublime for this would have been composer. Composer was the first like, oh [ __ ] this is a better way to think about your parallel agents and we got the awful anti-gravity thing, the anti-gravity agent manager. Then I would argue the next big one that matter was codeex app. And now I'm hoping fingers crossed that T3 code can become the big winner similar to VS Code and cursor. You get the idea though. There's generations with these products. And if you compare Sublime with VS Code, yeah, Sublime was a little bit faster and cool, but VS Code is obviously better once you see how powerful it and its extension ecosystem are.
You can't compare so cleanly between Sublime and T3 Code because they're from different generations. T3 Code is a lot worse than Sublime in many ways, especially if you're just trying to read code. But T3 Code is an entirely different way of thinking. It's a Gen 3 in this example. Before GitHub, we had solutions for source control. We had platforms for managing SVN. We had Fabricator. We had all these other things. GitHub was the first one that was good enough to like start a new generation of products. And when this generation started, a lot of people tried to build their alternatives.
One of those, one of the successful ones I would argue, was GitLab. There is also Bitbucket. These are all, in my opinion, the gen two of version control and centralized source control. We had the old solutions before. We now have these. These are all part of the gen two so to speak of source control. So what is gen 3? We'll get there later. Maybe we'll see. But for now, I want to emphasize the point that GitLab and Bitbucket aren't generational improvements. They're not trying to be very different. The same way that VS Code wasn't trying to be very different from Atom.
It was just trying to be better. And a lot of why VS Code won is because Adam was so [ __ ] VS Code made a lot of sense. and Sublime being closed source and not really embracing the extension ecosystem meant it wasn't as powerful for the use cases we wanted to use these things for. So again, VS Code didn't win by adding all these crazy new features and things. They won by being the best option in that generation. The harsh reality that we're likely going to come to is that GitHub, as shitty and unreliable as it is, is in most ways the best option of this generation where you have things like AWS, GCP, and Azure.
And now we have things like railway versel and convex. That is a generational shift in how we think about interfaces, how we think about these infrastructures, all of these things. Okay. Now that we've established the idea of generational solutions, GitHub was probably the best of this generation, but we should explore the others. I would argue GitLab's value wasn't that it was better than GitHub, is that it was an open alternative to GitHub that would often price itself cheaper for enterprise deals and the enterprises would have more control over what they were using it for and hosting it with.
So GitLab was attractive to a lot of enterprises enough so they could make serious money. Like last year, GitLab did almost a billion dollars in revenue, which is 26% growth over 2024. They're making money, and they're making that money by licensing to enterprises. But as we've now established, product is not great to use. So let's move on to Bitbucket. I like the phrasing here when you Google search Bitbucket. Git solutions for teams using Jira. Hopefully I don't need to go much further here, but we'll look at Bitbucket versus GitHub according to Atlassian. First thing, code and CI up to 10x savings.
They are not trying to push this as a better solution. They're trying to push this as a cheaper solution with best-in-class Jira integrations. First, look at how much cheaper it is per user than GitHub Enterprise Cloud. Wow. And then they show how numbers multiply when you increase the other number you're multiplying it by. Crazy. When number goes up, number goes up. This chart should tell you everything you need to see about why this is not the solution for you. If you're pricing your source control and the engineers that have access to it and you're this excited to save $15 a month on engineers, you're probably not paying your engineers very well and I'm generally not that interested in you and what you're doing.
If you're going that out of your way to save $15 per month perge, I don't want to work at your company. Oh, even better. The 10X savings is based on the GitHub plan priced at $21 a user plus the $50 per user security add-on plus the premium support add-on. So they intentionally added all the custom features on GitHub in order to make the price look as egregious as possible. Let's keep going. Dev Sec Ops tools are included. Secret scanning, dependency scanning, and infrastructure as code scanning tools for no additional cost. GitHub charges for security tools as an add-on.
Premium supports included too. Premium support in 99.9% SLAs's. Okay, this part actually probably is useful. The fact that it's actually up. Cool. There's the first actual useful thing. Flexible build minute plans. Get started with 3500 build minutes per month and buy additional minutes based on your usage. Note that that's not per user. Every account gets the 3500 build minutes once you create your organization and then you have to spend more. There's a reason there's a lot of other cool things happening in CI. I don't know who's sponsoring this video yet, but there's a good chance it's one of our bigger sponsors in the space like Depot or Blacksmith.
And they're both awesome alternatives to running CI on GitHub or Bitbucket. They're cheaper and faster. Highly recommend. So, why would you choose Bitbucket Cloud over GitHub? First, because it simplifies your tool chain. Put your code and CI/CD on one platform with Jira and capabilities spanning the entire software development life cycle. Reduce context switching. Developers can view and manage issues with a built-in Jira UI. I'm going to do a quick test. What do you think comes up more on this page, Git or Jira? Jira's on the page five times. Okay, Git is there more. It's there 13 times.
How about code? Okay, code's there 12. Cool. So, Jira is mentioned at least five times on the page. Pretty hilarious. Not as many as expected, but it feels like it's everywhere. More Jira mentions. You can keep operation teams in sync with a native integration into Jira service management. JSM. All commits flow into JSM and automatically kick off upon approval. Native IDP experience. You might notice a pattern here. The value you get out of Bitbucket is if you're already a big customer of Atlassian, it integrates with your other Atlassian stuff. That's it. That's the value you get.
They have 15 million devs on Bitbucket and they only could get three quotes. And it's an analytics company. Nexttiva and Flow are the only companies with anything to say. Thankfully, Bitbucket is very willing to disqualify themselves. They're back to our options list because we've largely ruled out GitLab. If you care about user experience, it is just worse GitHub with slightly better uptime. And we have Bitbucket, which is Bitbucket. So, how about we look over here where we get some of the open options. You're curious what the separation was here. First section was the more enterprisey business options.
GitLab does have open source stuff, so it's a weird in between there, but they are very much an enterprise that makes a lot of money. Everything here is for the most part known for being open- source or nonprofit. So, I'll start with Git T. Gee is honestly the one that feels like it comes up the most, mostly as an open alternative to GitHub. But you might be noticing something. Nothing here says open. Git T is a private, fast, reliable DevOps platform. Self-hosted DevOps platform that gives teams and developers high efficiency, easy to run operations from planning to production.
Quotes from people. Best open- source and self-hosting platform for version control is gi platform. Notice none of these people even have pro pictures. I actually know Satchin. His account doesn't exist anymore. Great. How many of these exist anymore? Also, the names are all the same format. Not suspicious at all. Yeah, a zero following account. Great source. They do have free self-hosting under the MIT licensed version, which is a different version, and then an enterprise plan for $9.5 a month instead of the usual 19 if you do a one-year commitment. Notice they keep calling it private, fast, and reliable, not open.
That's because they kind of rug pulled. A lot of people are very mad at Git and not just because like they have weird hover treatments all over their site and because they're jank as [ __ ] and kind of false advertising here with these quotes that can't actually be traced back to the original people who posted them because those aren't real accounts. All of that aside, the problem with Git is that they were very open before. The people running it decided they wanted to go more private and charge for it. The community felt rugpulled and they forked.
So, what happened to the Git T community is that they forked and the fork is Forge Joe. Forge Joe is a self-hostable lightweight software Forge. It's easy to install and low maintenance. It just does the job. They formed the Codeberg EV, which is democratic nonprofit or that maintains Forge Joe. You can create an account on Codeberg and other instances or download it to self-host on your own. I want to be really kind to these guys because it is so important this exists and I genuinely think it's awesome. If you want to just find a good enough alternative to GitHub to like not have to worry about and use it and get back to work, go use Forge Joe.
They're awesome. I love that this exists. I love the way they formed it. I love that it's a truly free software organization formed by a democratic nonprofit. This is the right way to build open, reliable software. Massive respect to Forge Joe and Codeberg. Wanted to get that out of the way first because I want to also try using it and I have feelings already. I actually went and made an account because I do really want to try it. And after signing up, this is the view I opened it to. My face isn't covering anything valuable here.
This is just where it opens. Generally speaking, free software, foundation style software, things that are are free as in free press software, not going to be the best designed stuff. And then when I refresh, you'll see some questionable loading states here with the search, even though I haven't done a search. And it's still spinning. It spins for like five plus seconds. Well, let's explore some repos. Oh, I'm hitting a capture check. And now we have the actual Forgejo repo. Reminder, that's what this is built on. Codeberg is the product that you can use to use Forgejo in the cloud without having to set it up yourself.
Forge Joe itself actually looks pretty well maintained and solid. Hasn't been going anywhere near as long as GitLab has. Way fewer commits, 25K instead of the 500,000 we saw before. But also, you can see the size of the community difference where the source code that Codeberg is hosted with, Forge Joe, has 4,000 stars. It now has 4.3K and one extra because I hit it on my new account. Let's take a look at the codebase. I'm actually curious. Way smaller and more elegant. The whole thing is like 12 megs. Oh, they're on the latest version of Node.
That's also a very good sign. All All very green flags so far. Like I I'm not upset. Let's analyze it, though, because I can't help myself. You guys know how I am. Way smaller, actually. Damn. 400k lines of go, bunch of INI files, small amount of JavaScript, small amount of TypeScript, some Vue. That is very reasonable for what it is. And since it's a Go project, it's going to run much faster than a lot of these alternatives that are Ruby based. Yes, both GitLab and GitHub are built on top of [ __ ] Ruby, which is a huge part of why they're hard to scale.
I also There's a lot of little things in the UI here I love. like it's not pretty, but releases is right up here as a top level thing. That's great. And if I click it, oh, this is exactly the info I need. We have when it happened, how many commits were involved in this release, and I can click this, and it is a bit slow to load this because this is a big project on the free hosting on Codeberg. And now we have all the commits for this release. It's ugly as sin, but it's doing exactly what I need it to do.
There's apparently themes. Oh, yeah. Codeberg dark. You have to click change theme after. Didn't appear to change anything. Okay. So, it's the Forge Joe dark. Okay. Yeah, I like these colors a lot more. Actually, this is a little egregious in terms of the customization, but it's cool. They offer these types of things where you can pick types of comments that just won't be visible to you. That I like. That is useful. But I'm just like the release tab is great. Like as good, if not better than GitHubs. An actual search here. There's an RSS feed button, so you can subscribe to the RSS feed for releases.
This is a developers platform for sure. This is built by and for devs, but like with a little bit of taste. I thought I was going to hate this more. I'll be real. You probably have to scroll too far. You have to scroll way too far to get to the read me. All of them make this mistake sadly. They everybody puts the code first, which doesn't really make sense and never has. But renderers read me is fine. I just can't get over how good like this is. Like I can get to the things I need to get to really quickly from here.
How are the issues? This is like onetoone GitHub clone stuff, but they load relatively quick. I expected to hate this more, guys. I really did. Can you embed images or do they just get attached like this? That might be killer if that is the case. If you can't like put an image in the body of an issue, they do embed. Okay, they embed. That was just the way that was set up. I guess that was the code review tab. This is where a lot of things start to break down. It would be nice to get an idea of how big a change is from this view.
Not a lot of things do that and it's expensive to calculate it and like preserve that this high up, but it would be nice to see how many lines of code were changed in a given PR. It does show it here still as expected. Oh, there's a little bit of jank in transitions, but like GitHub's code review is as if not more jank. This is clearly like ripped off from the new GitHub code reviewer, but it's solid. Oh, wait. This is the big one. Does split view require a page reload? Cuz the GitHub one has for a long time.
It does. It has a full page reload when you switch from split view to the normal view. Not everything can be perfect, but like this is absolutely passable. I I would pick this over GitLab easily. Apparently, I'm pronouncing it wrong. I'm not going to fix that. I'm sorry. They have a comparison with Git over in their FAQ. ORJ was created in October of 2022 after a for-profit company took over the Git project. Exists under the umbrella of the nonprofit organization Cobberg EV. It's developed in the interest of the general public. In the years that followed, the difference in governance led to choices that made Forgejo significantly and durably different from Git T.
You'll find below the most important reasons to choose Forgejo. Exclusively free software like proper free Libra software and they also test and release it using Forgejo actions. Pretty cool. Git T's actually developed on GitHub and release the GitHub actions. I did not know that. That's hilarious. Forge Joe's localization is done via weblate which is an open thing. Git tease is crowded which I believe is not open. Four Joe's quicker to fix security things. Apparently, Git T has been lazy about security stuff. I can't verify that trivially myself, but I trust these guys. I have no reason to not.
There's a lot more effort into stability with Forge Joe and end to end testing across it, which is really cool. You know what? I'm putting my money where my mouth is. We're donating. They're not even at 300 a week. Gross. One moment. Okay, just just more transparency stuff. This was unchecked initially. are forced to check automatic or manual renewal. It doesn't just automatically select one. You have to pick one. They are being really chill. I just threw them 1,200 bucks and they'll be getting 400 a month from me going forward. It's the least I can do.
This is a project that deserves support. I am actually very impressed with what they have built here. And when I saw how little money they are getting right now, it's insane. So yeah, least I can do. You got to put your money where your mouth is and it is important to support projects like this. I thought I was going to come in and be like, "Oh, this is ugly. This is slow. This is useless." No, I could see myself using this. Like, legitimately, this is actually gonna change my plans for this video. I like it so much more than expected.
I'm actually going to move some things over after stream and try this out more myself. I'm impressed. Apparently, Forge Joe actions can largely use the same YAML files as GitHub actions do. So, it's like a onetoone move. That said, I don't do GitHub actions on GitHub. If I do them on other platforms, like I mentioned before, Blacksmith and Depot, if I can link those up, which I almost certainly can, I'll be very happy. And if I can't, I'll convince the two companies to make that work. Good [ __ ] This is really good. I'm I'm hyped. Yeah.
Shout out to Forge Joe and Codeberg for all the work they are putting in here. For those who haven't been paying attention, Forgejo is the actual source code that is running this git backend for your remotes. and Codeberg is an existing hosted version of it that is also the corporation which is a nonprofit organization that owns and maintains Forgejo. This is a very good symbiotic good to see relationship and the most important thing their actions have had some downtime for the freeto use hosted version but their actual site and the source control in Git has way better uptime than GitHub does right now.
And what is the partial degradation? Do they have info on what's going on with that? Ah, the outage on actions was them preparing for copy fail, the Linux CVE that went live a few days ago. But the transparency on this Mastadon account where they post status updates is insane. I would kill for this level of transparency from GitHub. I don't even fault them for that. If this is just because of [ __ ] copy fail, that makes a lot of sense. But remember, you can just host it yourself. If you have any issues with their hosting or you have things that are like legitimately valuable and important that you want to have high enough uptime on, you can just self-host.
Oh, apparently you can bring your own machine on Codeberg, too. You can just host your instance of it on your VPS and still be on codeberg.org. Oh, it's just for actions. Oh, I thought it was for like the whole instance for actions. That makes sense. Yeah. So, you can add your own runners and register them yourself. That's pretty cool. I dig that. I like where they're going with this. This is a legitimate option. And if you're looking for something you can self-host, I would not [ __ ] touch the pile of ruby slop that GitLab is. They're doing everything right here.
I I am hyped on this. Yeah, this this meaningfully changes the direction I was going to take the video and I'll still cover the other piece I think are important. Source Hut. I I don't even care anymore. Yeah. Yeah. I just looking at this. No, this is not for us. Hosted real time chat services. I don't care anymore. Cool. So, Forge Joe and Codeberg are the things that we like and recommend. Now, that was easy. Let's look at the other stuff I have here, though, because it's all here for reasons. We got Code Commit, which is largely dead.
We got Pierre, who we'll come back to. We have Google Code, who is largely dead. Google Code was originally not using Git because Google firmly believed for a while that Git was the wrong solution. They changed their minds. SourceForge [ __ ] show. Fabricator actually dead. But now we have to go to this section at the bottom here. Graphite entire and Pierre and Pierre in the literal immediate sense is dead. If you're not familiar, Pierre was a GitHub alternative trying to rethink from first principles. And as they say on their current homepage, development on this project is currently paused.
What seems like a really good time to have a GitHub alternative? Why' they pause it? The reason is the two other things they're building, the primitives to make a better GitHub. One of which I'm really hyped on is code.sto. And not just because they have like the most beautiful site I've ever seen. They are really crazy about their design [ __ ] The point of code storage, their new service, code.sto, is that it lets you programmatically integrate git and push shitloads of code really, really fastly. It's an ultra low latency git cloud for reading and writing files from anywhere, bringing classic Git workflows like branches, commits, and merge strategies, as well as novel concepts like ephemeral branches, in-memory writes, cold storage, grap, and more directly into your product.
This is a new way of thinking about GitHosting built heavily around this idea of agents pushing way more code. In GitHub's coverage of why they're having so much downtime, they love citing these graphs, the massive increase in the number of pull requests, commits, and new repos that GitHub is seeing because agents are making more people do more projects and they can't handle the throughput. That's because they're built on top of a pile of Ruby slop that horizontally scales almost decently but barely and they are hitting the limitations of the system that was built for multiple orders of magnitude less traffic than they're getting.
Pierre started from scratch with code storage with the goal of making it handle super high throughput agentic style work. I would argue that Pierre is building the foundation for this third generation of source control. So if we were to do the Gen one, two, three thing, Gen one was SVN. Gen two has the great enterprise option that is slowly dying of GitHub, but also the phenomenal open-source solution with Forge Joe and Codeberg. So those are the two options I would recommend for Gen 2 because Gen 3 is not even close to ready yet. Nobody has built a proper Gen 3 product, but Pierre is the first company building the pieces for it and code storage is one of those pieces.
Pierre stored 9 million repos in the last 30 days. Peak of 15,000 repos per minute for three hours straight with no downtime. They built it for this throughput and they are hitting this throughput. I happen to know cuz I'm friends with the team their current numbers are even crazier than the numbers they posted in March and they're handling it fine because they built it for this. Meanwhile, GitHub is collapsing under 20 million new repos. They did half that and have no issues. So again, my friends at GitHub, I'm sorry, your [ __ ] [ __ ] sucks. People are asking, "How much do we trust the stat?" I'm friends with them.
We trust the [ __ ] stat. To be clear, this is just the Git infrastructure. This isn't pull requests or history management or issue tracking or release cycles or any of that. This is just the git backing behind all of it. But everything here that GitHub's complaining about other than PRs merged is from the git backing. The git backing is apparently a problem according to GitHub. Otherwise, I wouldn't put put this here. But here's the secret. The git backing is probably not GitHub's problem. It's all the slop they built around it. But if we have a really solid reliable git backing to start from, we can build not just alternatives to GitHub, but alternative ways of building entirely.
And like there you go. TypeScript con store equals new git storage. Cons repo await store.create repo. Do you know how much time and effort it takes for me to commit a repo on GitHub? I crashed out about this in a video and people were mad at me for it. So yeah, let's just I'll show you some fun examples. Let's do it. Okay, let's say I want to push something on GitHub. Get status. I don't want to add the P cache. We'll just do get add db.py. Let's put this on GitHub. GHPR create can't. Okay. GH repo create.
Oh, first option. Create a new repo on github.com from scratch. Create a new repo on github.com from template or push existing repo to GitHub. the obvious thing we want. Okay, I'm here. Enter. Path to repo. Probably the thing I'm in right now. Repository name. Some random name. Wait, I want to go back. I'm going to press option and delete, which I do all the time for deleting things up to the last non like asy character or last non letter or number character. Option delete. Oh, it crashed the CLI. I have to run the whole thing again.
Let's do it. Down arrow twice. Enter. Enter. Some other name. Enter. Wait. Loading time because it has to load between half the steps. Choose what repo owner? T3. GGG. Cool. Description. Some random description. Cool. Oh, wait. I typed option delete. Oh, nope. I have to do the whole thing again. Can you tell that I do this multiple times a week? The CLI is [ __ ] terrible. It's so bad. And even if you happen to hit all the ideal cases. Oh, I didn't even do anything that time. I just pressed enter and I got an unexpected sequence.
Couldn't I have just backspace instead of option backspace? If I remember to, if I remember that the way I type normally, which is like this, and then I do option delete to delete the last word. I'm sorry. I don't want to use my keyboard differently because GitHub is too incompetent to let me push [ __ ] code. I'm sorry I'm crashing out, but you guys make the stupidest [ __ ] suggestions when your products don't work. I was just giving an example that I personally went through two days ago. That's all. Let's try again. Push. Enter. Enter. Enter. Some description.
Enter. Public or private? Enter. Another loading time. Created the repo. Add a remote. I told you I want to use the existing repo. Obviously, I want a [ __ ] remote. Yeah. What should it be called? I don't know. the thing it's always called origin. Would I like to push the commits? No, I just wanted to make the repo and add the origin to it so I wouldn't push the commits. Thanks GitHub for asking. And now after 1 2 3 4 5 6 7 8 nine separate questions it asked me with four separate stoppers for loading, I now have a repo on GitHub.
Tell me how I'm wrong, chat, because you love to tell me. I deal with this at least once a week when I'm putting up random repos for [ __ ] It's inexcusable how bad it is. Apparently, the bug I was hitting is six years old and just hasn't been fixed. It doesn't handle escape sequences. They just never fixed it. Great. Do you know how you do this on code storage? Oh, wait. Store.create repo. Now you have a repo. One line of code. When I'm trying to describe generational product differences, this is what I'm talking about. a CLI with nine steps and four loading blockers versus a line of code.
Do you understand the difference? Pierre does not replace GitHub. They built the next generation of tools for whichever builders are motivated enough to build the next generation of GitHub. Forge Joe has pushed to create. I can just push to a fake origin and as long as it's under my like SSH key, it will just write the repo. I should have donated more. Oh. Oh, that means your agents can just push freely. That's magical. Why does everyone else get this right? This video is going very differently from how I expected. I'm not going to lie, guys.
And one more thing from Code Storage. They have two other products. They have Code Storage, which is their infrastructure that, to be fair, is not open for anyone to use right now. You do have to like get on a wait list and get approved. I had to annoy them on Twitter to get approved personally. But they have two other things you can use right now. You've probably actually seen them in a handful of products. The first is diffs.com, their open- source and freeto use diff rendering library. I say you might have seen this because if you use T3 code, you've probably seen this.
T3 Codes diff viewer is diffs.com because diffs.com is awesome. Phenomenal renderer for diffs. We're actually working on porting it to React Native right now for the T3 code react native app in the future. But they also put out a new thing, trees.software, software, a file tree rendering library to make it way easier to render complex file trees. They're building all the missing primitives we need. This is why I'm hyped on PR. They tried building the GitHub alternative. Nobody wanted to use it. I know cuz I tried and it wasn't very good. It was just another GitHub alternative.
But now they're building best-in-class primitives. So, whoever wants to build whatever shape of GitHub alternative in the future, they now have all the pieces they need to do it. They are a VC back company. They raised a bunch of money. They are burning it to build this stuff in hopes that in the future code storage might make enough money or maybe they build something else that makes money. They're just trying to form the like garden where the best things can grow. And I have a lot of respect to them for that. I do see a future where they win and they win big.
We got to talk about the other two potential big winners here. Graphite and entire. You've probably heard me talk about graphite before. There's a lot to love about them. The next generation of code review. Graphite's focus was making better workflows for code review stuff and they did a great job. Their diff viewer, their hotkey layer for actually navigating poll requests properly, their comment system, their feeds, all those things made graphite feel 10 times better than GitHub for reviewing code. But it was built almost entirely on top of GitHub. It was built by people who worked at Facebook before that missed stack diffs and these better workflows for making changes to code and getting them approved and merged.
and they built graphite to try and bring those things that worked well at Facebook over to the rest of the developer world which happened to be on GitHub and that means they were fighting GitHub constantly. the hardest and most complex technical challenge they have faced and I've talked to many of the founders I'm friends with them is that building on top of the GitHub API was help one of the boldest changes they made mid last year or so if I recall is that they added a checkbox where you could start mirroring your repos on graphite's infrastructure because GitHub's info was too slow and it made the site feel awful to use.
So by cloning your code they could do their own diffs their own everything effectively and it made everything feel significantly better and faster. So, Graphite started pulling more and more off of the GitHub APIs and into their own world, and then they got acquired by Cursor. My suspicion, and I'll be clear, I have no meaningful inside info here. I have actually went out of my way to not ask. I don't want to get too excited. My suspicion is that Cursor alongside Graphite could build a different thing that does replace GitHub, but not by being better GitHub, about being an entirely different way to think about your source code, think about your issues, think about your changes, and everything else.
So, graphite is well positioned here to be a different thing from GitHub, but we'll see where it goes. Graphite made a way better experience for me when I use GitHub and still do. And I hope that doesn't go away cuz I still rely on them heavily for that. But their focus is integrating with Cursor and building the next generation of development as a whole. And that does include GitHub. So, I see a way for them to to go that direction. We have no idea where they're going to end up. And that leaves us with one last big bet.
Entire. Entire is an interesting company. They just announced their $60 million seed round. If you're curious how they were able to raise so much money in a seed, one of the biggest seed rounds of all time, it's cuz the founder Thomas was the last CEO of GitHub. And when he left, they chose to not have a new CEO. So, GitHub no longer has a CEO, but Entire does. An entire CEO is the guy who was running GitHub up until late last year when he left. Another important thing to note to account for bias is that I am the second investor in the list of investors.
So I am an investor. So account for that as we talk about it. Their first release is the entire CLI for tracking agent context. They want to think more about how agents write code and how git isn't necessarily the right way to preserve what happens. They say here that git preserves what changed, but nothing about why. With agents generating hundreds or thousands of lines per session, this context loss compounds fast. Without shared context, agents can't collaborate effectively. They retrace steps, duplicate reasoning, yada yada yada. They want to make more durable history that goes alongside your code so that agents know why more directly.
Entire aren't the only company trying to rethink the relationship of git and agentic code flows. Zed is as well. Zed is an agentic editor that has been building really cool standards including ACP, the agent client protocol, which we use for integrating other agents in T3 code. They're also working on Delta DB, which uses crdts to incrementally record and synchronize changes as they happen. It's designed to interoperate with Git, but its operation-based design supports real-time interactions that aren't supported by Git snapshots. The point of this is to give more context to agents on what happens and why.
So, there is meaningful exploration going into this, both complnting Git and breaking out of Git. So, it's possible the Gen 3 GitHub alternative leaves Git entirely because Gen 1 to Gen 2 was SVN to Git. Is Gen two to Gen 3 still get? I don't [ __ ] know. I'm hoping so because I invested in one of the companies doing this, but we'll see. I have no idea. I legitimately don't. But there is one thing I know for certain about this, and this is the most heartbreaking part. There's a big problem with leaving GitHub behind. The community.
This part is legitimately sad. When I'm on GitHub and I'm looking at a pull request, I can click on the person's profile and see what else they work on. I can see what projects they've built, what things they've contributed to, who they are, maybe they added their Twitter profile, and I can click that, too. It's silly, but everything is on GitHub. So, if you're doing any work vaguely in the open, it's there. And if I'm looking for a repo for a project that I'm using on npm, if I have some random package I downloaded, the source is on GitHub, the author's on GitHub, the conversation is on GitHub, the issues are on GitHub, it's all on GitHub, and that has been really nice.
in the same way that everyone uses email and that's really nice. There was a hellish landscape of messaging apps back in the day and everyone just kept going back to email and occasionally IRC because those were the standards where everything kind of was and to this day people still like using phone numbers because of all the chat apps. We need a good home and I am sad that the unfurling of GitHub means it no longer is going to be home. We are already at the point where major projects are leaving and that means it is already over.
The great fracturing has begun. Some projects will go to some weird federated [ __ ] built on top of whatever the hell's going on at Blue Sky. Some people will go to Forgejo. Some will go to GitLab. Some will go to self-hosted instances. They're all going to go different places. And this consistent history where you could click one person's username and see everything they've done for the last 20 years. That's over now. And that's the sad reality. GitHub losing means that the one core thing we had, the one place where you could see who someone was and what they've done in the history of that project and its relationship to other projects.
That's all over now. I hate ending on a negative note like that, but I want to make sure we're realistic about the experience cost we're all going to eat because of the changes. I can no longer just ask somebody to send me their GitHub profile to know if they're legitimate or not because their best project and their best contributions might be somewhere else. And that went from being the exception for like three or four projects to at this point being the rule. And I don't like that rule. And I've already seen projects die because they chose GitLab or Bitbucket before.
I don't think it will kill the projects that choose to move, but it's going to hurt the relationships that those maintainers get across other things. And if you think this can be solved by importing data or building yet another layer or aggregator on top, I hate to be the bearer of bad news. You can't tool your way through this. You can't build a better tool that changes the fact that we all used to live in the same home and we're all going to be going other places. Do you know how many people have tried to build custom tools so they can stay friends with their high school friends when they all graduate and go other places?
Do you know how many of those actually work? Never. It doesn't happen. This is a graduation moment. This is the start of the end. And it is different. I'm sure you still have friends from high school, but it's not the same as it was when you were there. And that is what happened here. We are graduating. We're all going to go our own ways. We're all going to make our own new communities. We're all going to have our own friends. We all went to school together for 20 [ __ ] years. And it's kind of sad that that's over.
And I just wanted to take a moment to reflect on that. So yeah, I do still hold hope that GitHub can get their [ __ ] together and fix things, but I don't expect it to happen. And that's why I'm going to be investing my cash in supporting projects like Forge Joe and Codeberg while at the same time exploring other options and building the tools that are needed, the foundations, the blocks that will let us build our own more stable homes for our code and for our communities in the future. Because the ones we're using right now, the the one we're using right now, it isn't cutting it anymore.
Again, hate to end on this note, but I want to be realistic. We are losing something no matter where we go. And that sense of community is a thing I'm going to miss for the rest of my development career. It already feels like it started and I don't think we're ever going to get that back. But at the very least, we'll have better, more stable, and reliable places to host our code in the future. I'll be real, this hit feels more tangible than the move to AI based coding. I'm going to miss GitHub more than I miss typing out lines of code.
I know that for a fact, and I know I'm not the only one who feels that way. So, knowing all that, go try out Forge Joe and Codeberg. Go explore these other options. Build some cool things on Pierre. get hyped for what's happening with Entire and all our friends over at Graphite and all these other things. But know we are losing something when this change happens and I will miss my time spent on GitHub. Until next time, keep contributing.
More from Theo - t3․gg
Get daily recaps from
Theo - t3․gg
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.



