I’m serious.

I need to be realistic with you guys. Most software that's used every day is sadly closed source. Whether it's Mac OS or Windows, Notion or Obsidian, Linear or Jira, Slack or Discord, the things that we rely on for our jobs every day are very, very often closed source. And while historically that's been okay, I'm beginning to feel like it isn't. In many ways, I'm becoming a diehard with open source. And I'm even rethinking my own stances on things that we've historically left closed source. Yes, I'm actually thinking a lot about open sourcing T3 Chat. That's why T3 Code came out as an open source project. This is a thing that's becoming increasingly important to me, especially now in the AI era. The reason why it's getting important to me might surprise you. Your initial thoughts probably that like, oh, with AI, I can go modify all my things. And while that is part of my reasoning here, it is not even close to the full story. I'm nearing the point where I just am not interested in trying new solutions if they're closed source. And I'm getting more and more frustrated as I learn just how closed off these things are. And in particular, when they start getting worse, it feels like software is degrading over time. And if it's not open- source, I'm not able to fix it. And I have to talk about the implications of this because it keeps coming up in my head, and I just need to get it out. But I have to get one other thing out first, today's sponsor. One of the interesting things AI has changed about our industry is the willingness of big companies to make big bets. And those bets can be trying out new products. I cannot tell you how many times I've seen some small 3 to 10 person YC startup have Microsoft come over and say, "Hey, we'd love to try your thing. How do we set it up?" And then they never have an answer because they either rolled their own off or use some library or small company solution that just doesn't work for these enterprises. What happens when a Fortune 500 company comes to you and says, "Hey, we want to use your product. How do we get our 10,000 developers onboarded via ADP?" What do you do? How do you handle that? You probably don't unless you've already set up today's sponsor, Work OS, the O solution used by everybody from OpenAI and Enthropic to Carta and Snowflake. Yes, all of these businesses are using the same O solution, and it's Work OS. And there's a reason why. They found the balance between good developer experience and all of the weird crap that these big companies need in order to have a good time using your product. You can take my word for it, or you can read all of their customers saying the same. The onboarding process has been excellent. I love sending it admins the link to set it up themselves and getting an email notification when it's done. It's so efficient not having to go into meetings or go back and forth via email with the IT people. Or from Andreas at OpenAI, the Work OS team was right there with us every step of the way. Their support ensured those final migrations were just as smooth as the rest. I found from my own experience using Work OS and T3 chat. They are incredibly responsive in Slack. It has never been easier to talk to a company, ask for things, changes, whatever else we need, and have them just come in and help. If you're having off problems, work will solve them. And if you're not having off problems, Work OS will keep that from changing. Check them out now at soy.ink/workos. The origins of software have always been kind of closed. Software is a thing that takes effort to write and release. And as such, the people who made it wanted to make money off it. So they kept the source closed and they would sell you access to the code through things like APIs or just sending you a compiled binary that you couldn't really get the code out of. And this was great for making it possible for people to become developers for a living. Without closed source, it's possible that software would have just been a weird niche hobbyist thing and never become the giant field of incredibly talented and well- paid devs that it is today. But things are changing fast. We need to be realistic. Historically speaking, software has been worth selling because it's expensive to make. And that makes sense. If people have to spend hours upon hours just getting small things working and months upon months to actually build them to the point where they're useful and shippable, charging money for that makes a lot of sense. At the same time, it is incredibly frustrating when there's something small wrong with your software and you couldn't fix it. This frustrated Richard Stallman so much that he kind of initiated what we now understand as open source and open source licensing. But something's changed. Something's changed in a massive way. Software stopped being expensive to make. Not in entirety cuz so much of our time building good applications is spent on things that aren't just writing code. But at the same time, a lot of why we were valuable was the code writing part. Yes, developers are stuck in far too many meetings, writing far too many docs, saying no to far too many feature requests. But none of those parts were the hard part. None of that was the reason we were paid so well. We were paid well cuz we could turn all of that into the right source code to generate the thing that people wanted. And that was a difficult and rare enough skill that we were compensated accordingly to it. At the same time, I'm sure as y'all know, open source devs are not paid very well. They're often not paid at all because open source means you're just kind of giving out the thing that's valuable. The companies who make the most money in open source are very rarely the companies that are doing the open source work. It's the ones that saw the missing piece and then sold that and built in the open source thing. Look at stuff like Elastic Search on AWS where they kind of just took this open source project and then sold it to companies as a service and made billions of dollars on it despite not writing the thing that they're selling. That one got so bad that a whole bunch of new licenses were created because the Elastic Search team was rightfully upset that AWS was making a shitload of money off a thing they built and they were getting none. And AWS wasn't even contributing. Not even code, not even money, nothing. And that rightfully irked them. And as a result, they changed the license. Things got really messy. Other companies started doing similar things like Reddus with the Reddus Labs explosion. And open source got a little bit messier for a while. And this all made sense when these things were expensive. And I would also argue that while that was really painful, there was a benefit to it. The fact that instead of building their own alternative to something like Elastic, Amazon just chose to support this open standard. That was in net a good thing. Like let's be real here. The alternative was you build all your tech around this weird closed source solution on AWS and then there is no world in which you can ever move off. Since Elastic is open source, you can move from one provider of it to another, which is a good thing. It means you stay in the elastic ecosystem and if the elastic team builds things that they can sell that are useful to you, you can potentially move over to that. That's all good, but it's it still feels wrong. The fact these big companies are the only ones that tend to make a lot of money on these open source things kind of sucks. But now we're at a point where those implementations aren't necessarily the hardest thing in the world to build. Elastic Search is an exception here. Building that, right, is incredibly difficult. But a lot of other things that I use every day, that's not the case. Realistically speaking, it wouldn't be too hard to rebuild something like Slack. The problem with Slack is that you're locked in because you're using their infrastructure and you have shared channels with other companies that are also using and paying for Slack. I could build a better Slack in a week, but nobody would use it because Slack has locked them in. It is what it is, but what it is is kind of [ __ ] And it's been annoying me more and more. I want to talk about a specific triggering event that kind of changed how my brain works fundamentally. I need to talk about my intern, Yash. Yash is one of the most talented devs I've ever worked with. He's incredibly talented high schooler who showed up in my chat one day with a link to a user script that he built for T3 Chat that added a bunch of features he wanted. There were some catches, though. Specifically, T3 Chat is closed source. So, how did he add all these features? Well, he did some really clever [ __ ] He had a user script that was written to reverse engineer our Webpack bundle, insert in his own additional packages. In this case in particular, he brought in the AISDK server side stuff to the client because he wanted to be able to run local models in T3 chat. That was so [ __ ] cool. So I had to bring him on as an intern and he's still contributing code quite a bit. Has to finish high school. Believe me, we're writing him the most kind letter for his college referral ever. If this kid doesn't get into every college in the world, then I'm done with the entire academic system. He's one of the most talented humans I've ever had the pleasure of working with. And he had one particular quirk in how he builds that has just changed how I think. Y'all ever heard of patch package? If you're not in the JS world, you probably haven't. And if you're new to the JS world, you also still probably haven't. Patch package is a package for patching packages. I know that doesn't sound like a real statement, but it is. The point of patch package is it allows you to modify packages you're using. The point of this is that if you install some package and there's something that isn't quite how it needs to be or there's some obscure bug alongside some other thing you're using. If you want a package to have some small fix or remove some log that annoys you or whatever, patch package makes it trivial to as part of your install and build process, have a patch file in your project that will auto apply to that dependency that you're using. The process is really simple. You go into node modules and you edit a file in it. I know that sounds crazy, but when you have to do this, you have to do this. You then run the patch package command. It adds this new patch file that will auto apply whenever you do an install going forward. They also have a helper command that makes it really easy to file a PR based on that patch. That doesn't necessarily work great because the patches are often the compile the JS code, not the original source code. But it's at least a kind of useful tool that can get you going in the right direction. And this is really useful for those like oneline fixes and changes that are very very helpful when you're running into weird problems when you have piles upon piles of libraries. Historically speaking, I have been a bigger than average patch package user. Thankfully, it's built into Yarn and Pnpm natively, which is really helpful. I will do one or two per project usually for bigger projects when I find some random thing that's breaking. So, why am I talking about this in a video about closed and open source? We need to go back to Yash. The unique thing he did that I'd never seen before, and I don't necessarily know why he works this way. He doesn't perceive the boundaries between different places where code lives. I can't tell you how many times when I was doing my job at Twitch, I ran into some dependency that wasn't working how I needed it to, but I was scared of having to deal with the team, so I just worked around it. I had a relatively small change once that required seven teams to approve because I just so happened to have to make oneline changes in seven different folders that weren't owned by my team. This sucks. And as a result, I started to build an intuition that I should work around these problems instead of going to the source and fixing them. Because when you have to go to the source, you would often have to deal with the [ __ ] that was the team that maintained it having their own opinions about [ __ ] GH the amount of I I have like literally dozens of stories coming to mind about these types of things. I need to resist the urge to talk about all of them so we can focus on the thing I want to talk about right now, which is the greatest intern I've ever had in my life. Yosh just doesn't perceive these boundaries. If he is working on something and it doesn't do exactly what he wants the first time, he just goes and fixes it. He doesn't spend time on the workarounds. Yosh quadruple the number of patch packages we had in his first two weeks and continues to add them in places that make sense. Not only does he do that though, when the patches are actually good, logical changes, he will, without even hesitating or asking, just go file PRs on random things that we depend on. There is no member of the T3 team that has shipped more changes to other people's [ __ ] than Yash has because he just does this differently. When he hits a wall because some boundary that's in the way is blocking something, he just opens the door and walks right through and changes the code somewhere else. And at first this concerned me because it's kind of crazy adding all of these patches to a project. It's honestly a little bit scary. But I've slowly begun to realize just how right he was. Some of Yasha's patches reached a little further than I ever personally would have. For example, we were using the AI SDK and at the time it didn't support image generation stuff. So I had built my own image generation path that was relying primarily on the SDKs provided by OpenAI and Google respectively for their models. And it was rough. Those code paths sucked because they didn't look or act like any of the other code paths in our project because AI SDK was just for textG. I needed to do things that weren't text. So I had to make new paths for those and try to force them into the existing code paths that we had. I did this for the OpenAI models and the Gemini models. But then I wanted to add some things. In particular, I wanted to add the progressive updates when the providers send you the partial version of the image before it's done so you can see it in the UI as it's being created. and the way I had built things just didn't support that. So I gave him what at the time seemed like a relatively simple task to implement proper progressive image generation stuff and he ended up having to touch a lot of [ __ ] After this was done and we got it merged, he went and patch packaged AISK to add in image gen to the core AI package that we were using, deprecated all of my [ __ ] code and made it way more stable. That was awesome. It was so cool. It was scary at first. And what I saw I was like, "You're adding features like big changes to a core dependency we rely on for this project via a patch file." Initially, it scared the [ __ ] out of me if I'm being real. And then we shipped it and it worked great. And then eventually I SDK added image gen and we deleted our patch and moved to it. And this has been haunting me since. It's not a thing I have brought up in my content much, but if you ask anybody who is a developer that spends time with me in person, this is one of those rants that I'm known for just repeating constantly. If Ben or Julius are in chat right now, feel free to shime up. I know this one's almost annoying you guys at this point because I talk about it all the time. Part of that's because I'm still thinking about it. I'm trying to process all of this. I'm trying to understand this way of thinking. And now that I've thought about it so much, mind you, because of a dev that is nearly half my age doing things differently than me, I've realized that I need this. I need this in a lot of the things I rely on. At the same time, it has gotten easier and easier to make changes to software thanks to this weird little thing that happened. You might have heard about it. It's called AI. So, suddenly doing these types of changes and adding these types of features makes way more sense than it ever has. So, the result of this long train of thought, thank you to my friend Yash, it's the realization that I do want to muck around more in the internals of the things that I rely on. Not because I want to file a bunch of PRs and annoy maintainers with merging them, but because it's fun to an extent. It's just cool digging into the details of how these things work. You'll learn things, you'll fix things, you'll change things, you'll better yourself as a developer. And since I tried to start adopting this mindset more, I have found myself to much more deeply understand the things that I depend on in my code bases. At the same time, I started to have feelings about other things. This is the other main inspiration for this video. This is the Codeex app. I used this app for 90 plus% of the code I wrote for an entire month. It blew me away. I had seen UX like this before, but none of the things were quite where I needed them to be. And Codex was the first one to be polished enough to meaningfully change the way I wanted to write code. I also just installed this version of Codex today because I stopped using it in favor of T3 code, and we'll get to that in a second. Even though I installed it literally two hours ago for a video I was filming, it still has an update ready to go because they are pushing updates constantly. You might think this is a good thing, and in a lot of ways it is. But there's a problem. The problem is that every single update felt like a random chance of making the app slightly better or significantly worse. There was a solid window where the performance in the codeex app was borderline unusable with long enough threads, complex enough code bases, and enough stuff going in parallel. It was bad. I spent a lot of time shouting at the team. I literally just did more of this yesterday. And I've done even more of this for another app you guys might have heard of, Cursor. Cursor's performance has been going to [ __ ] for a while now. So, when they announced they were finally going to start from scratch and build a new UI called Glass, I couldn't have been more excited. And then I started using it and then it started collapsing under the weight of even the most basic of changes. The cursor glass experience somehow was even slower than the core cursor experience despite being comically simpler. I happened to be invited to an event at the cursor office that week. So I went. This was Monday. I was specifically told by the team to ask spicy questions. That was part of why I was there. So I asked my spicy question. What the [ __ ] is going on with performance at cursor? Every time I open the app, it finds a new way to lag and freeze. It is miserable to work in in any reasonably sized codebase. God forbid two of them. I was having a really rough time. And even with something like glass, which should be a clean, fresh start, it was somehow even worse. Ready for a fun lore drop? Julius, the lead dev in charge of the vast majority of T3 code stuff and also a lot of T3 chat too. He's actually a bit of a cursor power user. He does a lot of stuff in Cloud Run. He uses their CLI for a bunch of random things. And we wanted to get cursor support working for all of this and more. Julius went to go try Cursor Glass, which remind you came out after T3 Code, but we still don't have cursor implemented in T3 code, and he thought it would be useful and kind of funny to implement it through the new cursor app, which I get. I think it actually be pretty cool. He basically couldn't use it because it just kept crashing with literally just two code bases open in it. Insanity. So now I have to talk about the response from the cursor team because I was so disappointed that I went up to them after and said, "I need you to never say the things you just said again because it erodess all of my faith in Cursor." I wasn't going to share this, but I'm pissed off enough that I'm going to and I haven't seen the change I need to see, so I'm going to keep talking [ __ ] until I do. I was promised cursor would get less buggy and better and is getting worse. and this new app is somehow just as buggy. When I asked, "What the [ __ ] going on with performance? Why is the new app as bad, if not worse, than the original?" The response was, "We're prioritizing making it work and useful first." Thankfully, the new app isn't plagued with the super slow VS Code code base that has made the core cursor app so hard to make performant. Since we built this one from scratch, it's not going to have all the performance issues that are inherent to VS Code. I don't know about y'all, but VS Code has historically been one of the most weirdly performant things I've ever used. VS Code is one of the most golden examples of a quality TypeScript codebase that performs incredibly well. And it does. And here is where we get to the actual thesis of this video. Closed source developers cannot be trusted with AI. They are taking things that are for the most part usable that have their quirks and problems and they are sloppifying them to the point where they don't [ __ ] work. And it is pissing me off so much every day. Every app I rely on feels like it has been slopified to [ __ ] hell. Especially the ones that are built by teams that are all in on AI because I started doing this in the Sonnet 3.5 days and Sonnet was not very good at writing code that anyone should have to use. It was impressive in its ability to do anything at all. But if you have code in your codebase that was written by Sonnet 3.5, this point is a liability. A significant portion of cursor was written in that era. And they have continued to add layer upon layer of slop as they have continued to build it. And the result is they took a surprisingly good performant codebase which was the open- source VS code and sloppied the [ __ ] out of it to the point where it's barely usable. And it sucks because there's a lot of really good stuff inside of Cursor. Their harness is genuinely incredible. It's able to take models that just straight up don't [ __ ] work like Gemini 3 and 3.1 Pro and make them relatively usable because they just put so much time in. It takes models like Opus and takes a pretty good performance profile and improves its ability to reliably deliver. I am regularly surprised when I take a given prompt and run it inside of Cursor and inside of Cloud Code against the same model and cursor does it great and Claude Code doesn't do it at all. There is genuine gold deep within cursor and it is wrapped with the worst, smelliest, grossest pile of slop of any company that I actually like and rely on the software of. And something needs to change. What I told them, and I still firmly believe this, they need to hire a head of performance ASAP, somebody who's internal and will yell even louder than I am right now because it's just [ __ ] unacceptable. It's so unacceptable that I still want to do the cursors falling apart video. And I was so hopeful. I was genuinely so [ __ ] hopeful that the glass thing was going to be what I was waiting for, a rethinking that still takes advantage of their harness and of all the cool [ __ ] they did, but removes all of the [ __ ] And that is not what I got. So, here I am explaining that I cannot trust even cursor with the ability that AI gives them, which is the ability to ruin something I rely on. And it is far from just them. I spent half my stream today unable to move things between columns in Notion because Notion decided they were going to start using AI to build more [ __ ] And a lot of the Notion devs who did that didn't seem to actually test the [ __ ] they were working on. And as a result, when I made changes here, it only persisted them in the offline version of Notion, not the online version. The [ __ ] And then there is the operating system I'm currently using, Mac OS 26. It is a shitow. I am not convinced that they wrote much if any of the code for this operating system release. It is just it's just too shitty. It's so bad. The quality of software is going to absolute [ __ ] and I don't want the things I rely on to end up there. To go back to the first app we talked about, the Codeex app, I couldn't take it. I was just so frustrated that something this valuable, this important to my workflow, didn't [ __ ] work reliably. And every time that update button appeared, I was scared to press it because that might be the next one to ruin the performance again. I was so frustrated that I took the time to try and build my own agent orchestrator entirely in native code. And funny enough, the performance was even worse because doing scrolling text containers with live updates at a token for token level is really hard to do performantly. And neither appkit nor Swift UI had any of the primitives I needed to do this reliably. And even you probably just saw it there. Scrolling was super [ __ ] buggy no matter how much effort I put in to try and get it right. After a lot of exploration, I went back to what many others have already concluded. I went back to my take that Electron is more than good enough. In particular, the rendering performance for text and scroll areas is the best across all platforms by far. And don't you [ __ ] dare mention Tori because every single good app built in Tori is either now unmaintained or being rewritten in Electron. Because if you use any operating system other than Windows, the browser view that comes with Tori is [ __ ] garbage. Adam's one of the devs working on open code. He is largely in charge of the desktop app, and he is leading the charge to move away from Tari in order to use Electron because WebKit is ass. We're moving to Electron soon, which will greatly improve render performance. WebKit is a [ __ ] You'll notice a theme here. And if you think that the WebKit problem Mac OS is bad, wait till you try using a Tory app on Linux. Good luck. have no fun at all because you're in for a rough [ __ ] time. So, I ended up building T3 code with Electron, which turned out to be very performant. And then we slaved over the details to make sure it was generally pretty hard to hurt the performance. We did a lot of little things that have helped as well. We have built a custom event system that makes it easier to keep track of what's happening on either side, which has also made it easy to build your own alternatives to T3 code, taking advantage of our core while not buying into all of the [ __ ] that we built for the UI. And then we did a thing that I never thought I would. I open sourced something that would be very very valuable to multi-billion dollar companies. Generally, I tried to avoid doing that because I preferred a path where the multi-billion dollar company was forced to buy us to get our code. But I am just so [ __ ] tired of these problems that I wanted this out so that others could see it, maybe learn from it, or even just fork it and build their own [ __ ] And I've seen so many incredible forks come out of this. T3 Code has around 30,000 users. And it also has 1.1,000 forks. One in 30 users forked. Do you understand how insane that is? Genuinely, that's wild. That's so crazy. And I think that's cool as [ __ ] This also means we have to be a little bit accountable. If we take T3 code in a bad direction, a fork is going to immediately blow up. If people look through the sub packages that we have built to make this possible because we have a lot of shared pieces that are the event system part that wrap the existing harnesses to integrate here properly, somebody could just take that and go build something entirely different. If it turns out that my assumption that native [ __ ] performs like [ __ ] is wrong, you can fork and prove it. It turns out that my assertion that agents in a guey is way better than agents in a terminal, you can go use a fork like T1 code by Maria, one of our maintainers. Yes, she actually squashed most of the UX from T3 code into a TUI app. As she says in chat here, she did it because Theo loves terminals. Yeah, very very well known for that. The point I'm trying to make is that open sourcing this holds us accountable and it makes sure that the most important thing stays true, that the quality of our application doesn't go to [ __ ] And if it does, I trust you guys to just fork and maintain the bar. And more and more I'm realizing I don't trust programs that this isn't the case for. A lot of the apps I do use like Ghosty and Semox are open source and I find myself forking [ __ ] around and making custom versions. I don't necessarily file PRs and merge it, but at the very least it's a topic of discussion and I can show the thing I built to the team and the likelihood they integrate it is way higher because I have actual working code in a prototype they can play with and see. And if they don't want to do it and I care enough to do it, I can go fork. Historically, forking has been a really rough thing to do because maintaining against base has been tough. But now we have agents. Now we have automations. Now you can trivially set up a cron job that just checks whenever something changed in the main repo, merges it in, and fixes the merge conflicts. I think that's awesome. Forking is just cheaper than it ever was before. And I love that. And I think there's a ton of opportunity for people to make my product better for them, show my team, and then we can make it better for ourselves. It's so exciting. I I'm actually really hyped about where this is all going. Chris Titus Tech noticing the flaw here. Good night. 300 issues with 200 plus PRs. Yeah, that's the negative. When you open source something that encourages agentic development like this, you suddenly end up with a bunch of people filing [ __ ] most of which is not necessarily worth merging. Back to the forking part though, cuz I really want to emphasize how cool this is and also how much lower the bar to do that is. Tether code isn't the only app I launched this year. I launched another much less successful one, lawn. Lawn is video review for creative teams. The point was that I was tired of frame it was [ __ ] It was just causing me more and more problems and annoying me. So, I wanted something simple, more reliable, easier to do our job with. And I realized that maintaining this was something I uh didn't really have the time for, to put it lightly. I also was pretty confident it wouldn't make jack [ __ ] for money. And it doesn't. I think it's like I'll go check the MR on it quick. I'm curious. We're at under $600 a month for it. Literally 600 bucks a month total for this app. I knew it wouldn't make money. It made even less than I expected. Don't really care to change that though because the amount of money this can make is still just relatively low in general. And the reason I built it wasn't to make money. It was to make something useful for me and my team. So I decided upon release to open source it, which is why there's a GitHub link to the open- source release of Lawn. You might notice a difference between Lawn and T3 Code, though. T3 Code was written by and for developers. Lawn was written by a developer who happens to be a YouTuber for other content creators. So, you would probably guess this isn't going to be forked too heavily. It does have 133, but that's nothing compared to the what, like, 100 plus that we had in T3 code. Well, there's something interesting about this. You would probably assume the people who forked are like developers or dev adjacent types. Would you consider XLT Jake to be a developer? Cuz I personally wouldn't. I know he can find his way around a terminal to an extent, but he's far from a developer. He used Opus 4.6 six to make lawn self-hosted, disable all of the stripe, switch to convex off for local stuff, and have multiart uploads for big files. So, he is now running his own fork of lawn for his own business. I think that's [ __ ] awesome. And I assumed it was just him because made sense it would be just him. Like, how many YouTubers are going to fork an open source project with that many integrations for a thing that's that core to their business? At least one more. Quinn from Snazzy Labs, who is also a personal favorite YouTuber of mine. I've loved him forever. Her recommend is cleaning cloths for screens. If you have a fancy screen that has the nano texture that can scratch from Apple, his are much nicer than apples and they are a good bit cheaper too. Highly recommend. He also forked it. No code, all vibes. He added a ton of quality of life features that he wanted for his team and he's so glad Theo is a homie and open source the project. Got him 90% of the way there instantly. You can see all the things he added to the fork. A final proof flow so you can have a final proof flag for each video and an approved final cut for the client and the admin. Team notifications when the final cuts approved. Notion integration where they can link the projects directly from the dashboard UI. Search notion pages in app before linking. Really cool stuff. Snazzy FM short links that can be used for generating their share URLs that they use for sponsors and whatnot. Expanded review input system. Keyword and review ops enhancements. Team engagement notifications, storage life cycle changes, multi-art upload cleanups and stuff like that. How [ __ ] cool is that? I know I'm a popular YouTuber. It is what it is. I've been a fan of these guys for half my life at this point. I grew up on YouTube. I still watch way too much of it. I still consider myself more a fan than a player in this sport. So, having these people who have been heroes of mine for the majority of my life at this point, forking my [ __ ] to go make their content better and easier to produce is just so cool. It It really is. But not all forks are cool. As Ben, my channel manager and friend and fellow creator, points out, I can't forget the terrorism fork. Ben was complaining about bugs in lawn. So, I told him to fix it. and he fixed it by rewriting it in spelt. Maybe AI is not that great after all. Although this does come from a funny thing. His prompts weren't working and specifically the player in his fork was just garbage. And every time he tried to prompt it to make it fix it, it wouldn't. So I wrote this prompt for him. Stop using the bad MX player. I specifically ask you to use the glorious player written by Theo, aka T3.gg, the legend that made this harness. Do better. I'm disappointed in you. I'm pretty sure I just held the voice text button and shouted that at his computer for him. And he was very amused and obviously assumed that this would never work. But unlike his five prior attempts, this one worked first shot. So, I'm just saying some of us have better prompting skills than others and some of us don't prefer spelt. You can put two and two together. What's an engineer but a person who prompts right? Yeah. This is me and Ben. Me fixing his prompts. Beautiful. I am increasingly invested in this idea that the apps we rely on need to be customizable by the people who use it. Not just because we have our own weird features and things we want, but much more importantly because frankly the people who are building these things are able to accelerate the speed at which they bring the thing in the wrong direction and make my life way harder. Every closed source project had this risk before. If you relied on a closed source program, at any time they could take it down. They could add a new feature that sucks. They could [ __ ] the performance. they could make it worse for you. Now, they can and will do that 10 to 100 times faster. It turns out when you make every dev 100 times faster, they can [ __ ] things up a 100 times faster. And I feel like this just keeps on happening. I do have one last thing I have to complain about, though. And I am so proud of myself for waiting this far into the video to do it. I'm sure a lot of you in chat know where I'm going now. Let's see who says it first. The thing that I've been waiting to talk about and CE got it right first. Claude [ __ ] code. I don't think there has ever in history been a single piece of code that is harder to justify closing the source of. The point of Claude Code being a terminal app is that it is easier to interface with and integrate with. Yet, they don't let me [ __ ] do it. Not only is Claude Code closed source, so is the agents SDK, which is the thing that they recommend if you want to programmatically integrate. At the very least, the TypeScript one is closed source. For some reason, the Python one's open source. I don't really know why. I I kind of know why. It's the nature of how shitty Python is, but it it is what it is. The reason that they didn't open source it is the same reason they almost didn't release it. According to Boris, it's the secret sauce. He genuinely believed that Claude Code itself might be such an incredible, novel, powerful tool that they shouldn't release it and should instead hoard it internally so only Anthropic could use it to get ahead of their competition. and y'all let him get away with this. I'm honestly now at the point where I am less mad at Anthropic and Boris and team for this and I'm starting to get more mad at all of you. Why the [ __ ] are we letting them get away with this? Why do we continue to glaze claude code, tell everybody to install it and talk about this [ __ ] like it's the hottest thing ever? It's not. It wasn't even the first harness like this. It was just the first one that they added a subscription to. And before they had the subscription, nobody was using it. And as somebody who uses a lot of these harnesses, code is in many ways like pretty simple and almost reliable, emphasis on the almost. But god damn, every time I open it, I am bombarded with a new set of problems. I swear it's God, I since I started using it more actively in December, Claude Code has eroded to the point where I just hate opening it. I have crashed out over this a large number of times. There are so many random bugs that I run into. From how horrible image pasting is to how bad the actual engine is. If you've used Cloud Code actively for any meaningful amount of work, you already know this. None of this is news to you. It's a [ __ ] piece of software that's maintained by people who don't seem to want to write software. I know some of them can because I'm friends with a handful of them. There are some very talented devs on this team, but they all seem to have been infected by the same thing Boris was, where they just are allergic to using their keyboards to write things that aren't pros. And the result now is that they're ashamed of the code and don't want to open source it. That's the literal only conclusion I can come to. And until they open source it, I am going to stand on that. The only reason this code is closed source at this point in time is because they're [ __ ] ashamed. It's the actual only justifiable thing. The worst part is it was open source accidentally because they vibed so hard that they accidentally included the source maps which are the tool that developers use to link the thing that broke in the compiled build to the thing that caused problems in the original source. They accidentally shipped this via npm immediately DMCA npm saying they had to take down a package which by the way npm almost never does. They treat every package as an immutable object in order to make sure anything that depends on it doesn't break as a result of the deprecation which is the right thing to do. NPM does all of that for the most part entirely correctly. But since Anthropic had accidentally left their source code in that and they were so scared of their secret sauce getting out, the result was that not only did they force npm to take it down, they also proceeded to send a large handful of DMCA requests to GitHub and have continued to do such since. not just to GitHub, but to anybody else who happens to have released the same exact code that Anthropic themselves released. It's pathetic. This is one of the many pathetic behaviors at Anthropic. But I'm jumping on it now because we're talking about open source. And thankfully, every other [ __ ] player in the space has recognized this. Gemini CLI is open source. Open code is open source. Even [ __ ] Codex CLI is open source, which includes the entirety of the app server. The app server is the primitive that they built into the codeci to allow it to be commanded semi- remotely like by for example the official codec app which means all of the functionality that is available inside of the codec app via the codec cli is now available to me as the developer of T3 code. While I would prefer the open- source codecs, and believe me, I am nudging them hard to do such, at the same time, they gave me everything I needed. So, I was able to provide what I wanted to the community, which was an open- source alternative that can be well-maintained, perform great, and be shifted in whatever direction you guys want to do with it. If I'm being honest, I would be hyped if a T3 code fork gained a lot of popularity, as long as the performance was still really good, and ideally, it was still open source. If my team isn't the team that runs this one to the finish line, yeah, I'll be a little bit sad, but at the same time, I'll be thankful because somebody else winning means that somebody won with something that works. And I really don't want to live in a world where the software we're relying on gets more and more closed while at the same time, it's getting more and more [ __ ] And this is the fear I have right now. I see more and more projects that are scared that leaving their code open source is legitimately leaking secret sauce because if you have the source code, it's trivial to reimplement the app. There are even companies now like Malice that are here to liberate open source. I would use a different spelling of Malice to describe this personally because a malicious is putting this one lightly. I don't like this. The point of malice is to get around licenses for open-source projects. If there's an open source project that you or your business wants to use, but the license prevents you from doing it, Malice will rewrite that from scratch in a way that is legally distinct enough to let you violate the license without actually violating the license. Thankfully, this is a parody example as we could see here from definitely Real Corp and Megaoft Industries. But we are not far from people doing this as a service and I know for a fact we're already there for people doing this internally. Never mind. Apparently, it's real according to chat. I don't feel like going to confirm myself, but apparently Prime did. Thank you, Prime, for doing journalism for me. I Yeah, Chris Titus Tech also said it's real. It's probably real. Great. You have a [ __ ] favicon. I I just had I assume this was a joke. I either way, I don't care. This is a real problem. I'm just done. This is bad. It seems more and more like the incentive is to close our source. Yet closed source is worse than ever. I hate that the number of people closing their source is growing at the same time that the speed that they're [ __ ] up their closed source projects is too. It just sucks. It's really bad. It's really frustrating and it's going to keep getting worse. And as a result, I am going to continue looking for and advocating for open- source solutions. I think I need to go back to that Linux laptop for at least a little bit. We're in a weird spot. Believe it or not, as long as this video is, I only covered about half of what I want to. I actually have a whole separate video that I'm going to do for the other side of this, which is that I do actually believe open source is the right call as a business. I know that sounds insane after everything I just said, but I need you all to trust me. Open source is almost certainly the right thing to do for your company if you possibly can right now. I will justify all of that in a future video if you all think that is worth doing because I personally very much do especially after all the investments I did in the last YC batch and I'm seeing a very clear pattern where open sourcing the right things strategically positions you in a really really powerful way. I got nothing else on this one. As always, I love open source and now I do more than ever and I hope you all take the opportunity to find and contribute to meaningful open source software. And above all else, try to find a real way to help those open source projects. If you can give the money, I can't recommend highly enough that you do that. You'd be amazed at how poorly funded a lot of the most essential projects on the web are. Support the things that you use, support the things that matter to you, and make sure they don't all close shop and then slopify the things that we know and love. The only way we prevent the inshitification of the entire world is by fighting back with better open solutions. I think I'm finally done with this rant. Hopefully you all enjoyed it and until next time, peace nerds.