I think every company should open source their code.

I recently published a video about how much I'm losing trust in closed source software. It seems more and more like the future that I want is open one where I can make changes and use the version of the thing that works for me instead of being stuck with whatever the company building it wants me to use instead. I have a lot of gripes with a lot of closed source software and they're growing every day. And yes, AI is definitely to blame. Now that companies can just ship whatever they want and they're not caring as much about quality, the quality of the things I use is going down. But that's me personally. What about the business side? The business case is getting sketchier and sketchier as time goes by. If your code is open source, it's way easier for agents to find things that are insecure and pone them. It's way easier for a nobody to just tell the agent to fork it and host it themselves so that you don't ever get paid. And it's way easier for other companies to clone your work, point their agents at your product, and then build it into their stuff. So, why would you ever open source your business? It's a great question and I'm going to go really really strong on the case for open-source as a company. While I agree that open sourcing your apps increases the risk profile of the things you're building, I'm beginning to think that if you don't do it, you might be doomed. I've been advising most of the companies I work with, especially the ones I invest in, to go as allin on open source as they possibly can. And I cannot wait to tell you guys all why. Up until this point, the rant I'm about to do is info I kind of held privately and I would give to the companies I was working with and invested in in order to give them an advantage. But the more I've thought about it, the more I realized that I should give this out for free. As big as the advantage is for the companies in my portfolio to know all of this information, I would rather everybody does in hopes that we get more good open-source products in the future. But if I'm giving my code and my information out for free, someone's got to pay me. So we're going to take a quick break for today's sponsor. If you've never pushed code that breaks CI, you can skip this ad. Okay, now that all the fake devs are out of the room, I want to talk about today's sponsor, RWX. This is a new way of doing CI that's actually ready for agents. What do I mean by that? We can start with the skill that they provide because it's really, really cool. It lets you set up what they refer to as a run loop. A run loop allows for your agent to run a CLI command to run your full CI with all of the fancy caching and everything they enable so that your agent can get feedback fast before it even commits. Instead of committing a change, pushing it, waiting for your CI to run, then copy pasting the error back to your agent, you can just let it run in a loop until it fixes everything. Combine this with a commit that adds a failing test for the feature that you're trying to build, and you can basically guarantee your agents will actually fix the thing. The more I think about it, the more insane it is that you can't just run a GitHub action locally with a simple run command like they provide with their CLI. Once you move to RWX, you'll never want to go back because you can just run the thing locally. Like, imagine if GitHub CLI had a way to run your action. I don't know how they don't, but I'm very thankful RWX does. As if that wasn't good enough, their dashboard and their performance sell it even further for me. You can get a little diagram that shows which steps did or didn't run because they were cached. And they can break up your work into parallel cachable trees that make it much easier to not have to run work you don't have to or have multiple things running in parallel once a point is hit. The timeline view makes it super easy to see why things take too long. And then once you're hitting those cache runs, the result is insanely quick times. So, this run took two minutes initially to get everything set up and running. And now when you do further checks, it only takes 22 seconds. CI currently slows down your team when it should be speeding up your agents. Fix it now at soyv.link/rwx. So, why the hell should anybody open source their business? We should first start by listing the cases against this. I mentioned these at the start, but to quickly summarize, competitors cloning is a very real risk. If you add a cool feature to your product and the competitor can just point their agent at your repo and say, "Rebuild this," you're screwed. Self-hosting is a real risk, too. If your customers just never end up customers because they run your stuff on their own infrastructure. And one of the biggest, especially now after the Mythos stuff, is the security risk. Agents are able to like decompile and figure out holes in systems relatively well, but they are much better at it for open- source projects. For example, I happen to know that Cal.com has been struggling a lot with this because of the sheer volume of security reports and also attempted exploits they're getting because Cal is very much open source. So, knowing all that I know here and knowing how big these problems are, and I I don't want to discount this, these are all real problems that you should be thinking about if you're considering open sourcing your stuff. Hell, this one is why we haven't done T3 Chat yet. I know it's the comment I'm getting spammed with the most. I really want to open source T3 Chat. The reason we haven't is a combination of the security risk and the edge effort that we have. We're a two and a half person team and I'm the half person and I'm barely even half because I'm so goddamn busy. Julius is all in making sure that T3 Code keeps on iterating and Mark is entirely swamped with support for T3 Chat. Open sourcing T3 Chat would destroy us right now. But since T3 code uses your sub on your machine, we don't have to worry as much about destroying all of our users lives and all of our infrastructure if there is some small thing that isn't as secure as it could be here. Where with T3 chat we could literally lose millions of dollars in seconds. That is why we haven't. And even then I'm kicking myself wishing I could because of how big the benefits are. So what are those benefits? What are the things that I keep telling companies when I am thinking about open source? I want to start with an interesting angle here of who wins right now. This is my business analysis for those who always wonder like how do I pick my investments? How do I see the market? All those types of things. I try to not talk about that too much here because this channel is more about code and how we build software, not about how I think about the business landscape in the market. Every once in a while, I have the opportunity to nerd out about business stuff. And it seems like you all like it. So hopefully you'll like this part because I'm going to go the full capitalist route to how we get to open source. Now, hear me out. Also worth noting is when I say right now, I'm not necessarily referring to this exact instance. I'm talking about historically who have the winners been. And I hope we can all agree with the following companies being winners. AWS obviously a winner. Salesforce is a pretty clear, obvious, gigantic winner. Retool is an interesting one that we'll talk about a bit. If you're not familiar, Retool is now rebranding itself as an AI thing. But previously, it was a tool that would integrate every source of data you and your company had in order to make it easy to build like dashboards and widgets and solutions for like your internal review team or your customer support to have a custom dashboard to go update something in some random database that your company relies on. It was kind of a a glue tool that made it easy for non-devs and slightly technical people to make a dashboard to integrate with literally whatever data source you had across the [ __ ] world. I picked all of these companies for very specific reasons, but I hope we all agree here. All of these companies at the very least as of like 2022 were obvious, very very big winners. So why am I picking these companies? Well, let's take one like Salesforce for example. Let's say you want to do the suicidal thing and you want to compete with Salesforce. We got to think about all the features that Salesforce has. These are all entirely fake numbers, but I think it'll communicate my point well. Let's say that Salesforce has a thousand features. There's a thousand things Salesforce can do or integrate with. Any given customer only uses about 50 of them. So, you're probably looking at this and thinking that's insane, right? Like if every customer is only using 50 of those features and there's a thousand of them, that ratio is really off. The customer is only touching 5% of the features. That sounds insane, right? Like you have hundreds of thousands of people at your company with Salesforce. You got at least a few thousand engineers working on building and maintaining this pile, but any given customer is only using 5% of it at most. This just obviously makes no sense, right? Like you got to trim down the features. Well, here's where things get interesting. And again, these are made up numbers, but I'm promising you having seen real numbers, the trends follow roughly what I'm describing here. Of those 50 features that a given customer uses, half of them are used by the majority of customers. So we'll say 80% of customers use same 25 features. So the vast majority of the customers are using this core set. But the other 25 features, the other 25 are used by less than 1% of the customers. So in this 50 half of them 2.5% of the total are used by almost everybody and then the remainder of the other 950 features are split almost randomly across the rest of the customer base. So what happens if you want to build a competitor? Well, obviously you start with the 25 features everyone uses, but then you go to a customer and say, "Hey, we saw you're using Salesforce. We would love to move you over to our platform. We're cheaper. We're faster. We're more reliable. What will it take to get you to move over?" and they say, "Okay, looks like you have all these features we want. Wait, what about this random one bespoke thing that one person on the team uses?" Oh, uh, yeah, we don't have that yet. Oh, well, I guess we're just going to stick with Salesforce then. [ __ ] And then this happens over and over again, and you realize you can't get any customers because even if you have 49 of the 50 features they need, that one last feature is used by so few people that it's hard to justify adding it for just one customer. This is the case for most of these gigantic companies that have a majority hold of the market they're in and have thousands of employees and engineers working on them. They have been around for long enough that as customers need specific things, they build them. And if you have a million customers, a feature that 1% of them use is still used by 10,000 customers. If you have a 100 customers, a feature that's used by 1% of them is used by one team. That doesn't work. This is why historically we've had these big SAS companies that win super hard because once they get their initial customer base, they keep adding weird features to hold their customers in and then they can never leave because nobody can build all of the specific stuff that every random customer needs fast enough to compete. That's changing. I already saw people in chat theorizing what the solution to do all the things that you need it to do. Well, I have built plug-in architectures before. They're [ __ ] hell. No matter how flexible you make your plug-in system, somebody will want something that doesn't work with it. And at least one of those 50 features is not going to work in whatever plugin or extension system that you think you can build here. And my chat quickly caught on here. Plugins are hell. Plugin systems suck so much. Absolute hell. One plugin could take down the entire app, guaranteed. Yep. Absolutely. So while plugins can work, they require way more engineering effort to get the architecture right. They will cause endless support woes and costs and in the end not even cover all of the features that your customers want. But there are companies that have found success going in this direction. I would argue Salesforce is one of them. Retool is obviously like one of the biggest here where they built their own plug-in system as well as plugins for every [ __ ] thing you'd ever want to integrate. But then you're kind of stuck to an extent. If you ever want to change the plug-in system, you're going to break something for some customer and you're going to risk losing them. You get locked really hard. So, how do we deal with this? Well, historically, the solution has been just hire all of the engineers, add all of the features everyone ever wants, and know that your customers can't leave because nobody can compete because nobody has all the features you do. If you're able to identify a subset of the market that only needs a certain core set, and enough of those features are poorly implemented in your competition that you can wedge your way in, that can work. We've seen that with something like Versella versus AWS. Verscella is largely built on top of AWS and it is missing a lot of the features. I would argue the vast majority of the things AWS can do. But the use case of a developer who wants to deploy their web application at scale, the scale being really small or really big with a good integration with GitHub where they're putting their code, that is a common enough use case that is technically handled by all of the things AWS includes, but the happy path to do that is not very happy on AWS. It's a lot of work to get it right, and it's easy to fook on yourself and screw things up, especially if you want to spin up multiple projects randomly throughout whenever. Verscell was started in order to make it easier to deploy next apps because the team noticed this fault that web devs didn't really know how to deal with all of the crust within AWS. And even when they did, it was too slow and annoying to set up. And with all of that, Verscell was able to establish their own corner of the market building on top of AWS that is still doing very, very well. But there's another part of why Verscell went so well. And it's certainly not that they made a plug-in system. So what made Versel work so well then? To put it simply, you write the [ __ ] code yourself. While Versel hosts the code for the backend for your web app as well as the CDN for the binaries you're distributing to your users, they're letting you write the code that is hosted on their servers. So, anything Verscell doesn't do, you can just do somewhere else. You want to use Cloudflare as your firewall, go nuts. You want to use Superbase as your database, go nuts. You want to use Convex for handling all of your database and your back-end queries, go right ahead. I have a lot of apps deployed on Verscell where the back end isn't on Verscell. I'm just using Verscell as a CDN effectively and for hosting the domain and then Convex does all of the backend work. So even though Verscell is missing 95 plus% of the things AWS can do, it does the things it does well so well that you can start with it and whenever you're missing one of those things, you can just plug it in via code. And notice the difference here. I am not saying plugins. I'm saying plug it in with code. It is your job to build the plug-in system, so to speak. Verscelo is just providing the place where the code runs. The market was already starting to move in this direction before AI systems that let you get started and maintain and scale easily that don't have all the craft that they don't need. So, you can go grab that from somewhere else. Even AWS is arguably built this way where any given service can only do so many things. And if you want it to do other things, you grab it from another service on AWS. And all of Amazon's attempts to streamline that and have like one service that does most things like Amplify have failed really hard. The modular nature of these platforms are hugely important for their success. So obviously this makes sense for a hosting platform like Verscell because Verscell is hosting your code. You can plug your code into whatever else you want and you're good. But Versell is just one type of business. It's infrastructure. What about Salesforce and Retool? Those are applications. There are applications that have to integrate with a lot of complex things. How would you compete with them today? Here is where we get into my spicy takes. This is the thing that clicked for me as I was ubering to demo day at Y Combinator as I was trying to answer questions some of the founders had about how I'm thinking about open source. I was already thinking in this direction, but the framing clicked in that moment and I've wanted to write it down since. I actually started an article and decided to do a video instead. Simplest way I can put it, you got to let your customers make their weird [ __ ] Instead of building all these crazy features into your product, you have to make it as easy as possible for your customers to integrate their things. With Versel, this is easy enough. They're just hosting your code. You can integrate whatever. But when you don't have an info platform or you're trying to work with a company that already does, this gets way more complex. It's much easier to adopt forcell when you don't have any solution yet. It's much harder when you do. So, you got to start thinking in a more modular way, a more building block oriented way, and I would argue in a more open way. If you're not already familiar, we put out T3 code as an open- source alternative to all the vibe coding guies, but we don't have any way to make money on it right now, just to be very clear. T3 code makes you bring your own sub from a platform like Codeex or Claude. So, you have a cloud code sub or a codeex sub or API if you want and then you have to have the CLI setup installed on your machine. And we have effectively just made a better guey like a graphical wrapper for the CLI because as much as I love terminals, I personally very much prefer having a guey when you're doing back and forth conversational type stuff. It's just significantly nicer overall. Everybody I know who's tried it, even terminal people have come around and accepted that this is the better way to do these things. We're open source and on GitHub, but the numbers I want to share here, I think, will help this click. All time, T3 Code has had about 45,000 or so people sign up. It's about 42K. And when I say sign up, I don't mean register or anything. I mean that a unique identifier was used when they installed the app. And we've had 42,000 people open it once. We have a rate about 16K a week using the app right now, which are really good numbers for a brand new dev tool. But that's not what I want to talk about. I want to talk about this number. We have almost 9,000 stars, but we also have 1 and a half thousand forks. Onetenth of our weekly users are forked. Do you know how crazy that is? 10% of our users have forked and made some customization. They might keep running the fork themselves. They might drop it and go back to the app themselves. They might have tried to make some PR and then it died. But that is 1,500 attempts to change or customize T3 code in some way. This has been [ __ ] me up. I've just been staring at this and thinking too much about it since it happened. The sheer volume of people customizing T3 code to their liking has just broken my brain and how I think about these things on a fundamental level. Every day I get tagged in posts like this like Emanuel who has been customizing the [ __ ] out of T3 code. He's deep in his own fork now that he's even called DP code and now he's adding some of the features from CMUX into it where he has multiple terminals open. We don't have very much terminal stuff in T3 code. It's just like command J opens a small terminal in the bottom. He's building Semucks into the product now. He already built split chat so you could have multiple terminals and the chat all visible horizontally at once. He let you do multiple chats at once. He built his own queuing system. He brought in commands and plugins. And his framing here is great. He's been playing with T3 code. He loves it. It's a skeleton to play with and build from. I want to express that I love what Theo and Julius made. I decided to add the Codex apps over server with proper skills and UI. He was talking about how fun it is to play in the codebase. And he's also building mobile codec stuff, too. That's really good. Like, he could just go build his own thing, but instead has forked what we built and keeps going deeper and deeper into it. He even added a handoff feature, which I actually really want to rip. There's a lot of really cool stuff here that I want to get added to the official T3 code project. Obviously, since we want to make these things work well and reliably for all use cases, it's going to take us more effort to get it just right in a general sense. But do you know how [ __ ] cool it is to have users download the source code, customize it to their liking, and then share all the cool things they did with it? It's magical. And this never happened to this level before. Obviously, there's always been open source. People have always been able to customize, but the cost of that customization has gone down immensely because of the thing I haven't said a whole lot thus far. Somehow, AI. Suddenly, you don't even need to be a dev to add a feature to a codebase as long as you have the codebase. So, who needs plugins anymore? The future I'm imagining here is one where what Emanuel's doing isn't so much a thing he has to do as a developer where he clones the whole project and has to make changes and then pull things down from main and keep it up to date himself. What I'm imagining is a future where every customer is running their own fork. What would it look like if you had a product like, I don't know, Post Hog, which is open source by the way. Post Hog can be self-hosted relatively easily. I would never do it because I don't want to deal with managing my own cluster of ClickHouse. Just not appealing to me at all. But if I could build my own chart systems or features in suddenly it gets a lot more interesting for me. I cannot tell you how many times I had a specific chart or visualization I wanted in post hog that ended up being a back and forth with their support and edges for like 2 to 3 weeks just for them to ultimately be like eh I don't think that's important enough. I hate that. And even though I love Post Hog, I've had moments where I considered leaving because they were missing one type of chart that I wanted really badly, which is insane. But I'm not going to host my own Post Hog because I don't want to deal with all of that. But I would absolutely like to customize my post hogg and make changes to the binary that I and my team use while still relying on their backend, their servers, their everything. And I'm not the only one who's thinking this way. One of the other big winners that I intentionally didn't mention is HashiCorp. HashiCorp is the company that maintains Terraform as well as many other tools that companies rely on for building software at scale. Mitchell was the creator of Hashi Cororp as well as Terraform specifically. And he's also now very wellknown, arguably better known for creating Ghosty, the terminal that we all know and love. Ghosty is very popular. I'm sure most of y'all have at least heard of it if you're not already using it if you don't have it open on your computer right now. But just today, he wrote an article that kind of emphasized this point that I've been trying to make for a month. The building block economy. The most effective way to build software and get massive adoption is no longer highquality mainline apps. Rather, it's via building blocks that enable and encourage others to build quantity over quality. Over 18 months, Ghosty got a million daily users. Lib Ghosty, which is a library that powers Ghosty's entire terminal binding layer. It's also its own separate project that can be installed and used to make your own terminal or add your own terminal to other products. And it got multiple million daily users in just 2 months. So, it took 2 months for the core of Ghosty to grow past Ghosty itself after 18 months. Do you understand how insane this is in particular? The building blocks are what the agents like and over time the building blocks are going to be what the businesses like too. If your team no longer has to be blocked on the feature that the product doesn't have and instead the PM who needs it can go spin that up as part of the app themselves. That changes things a lot. I kind of want to read this whole Mitchell thing. [ __ ] it. Let's do it. Experiencing this firsthand as well as witnessing it in other ecosystems has fundamentally shifted how I view the practice of product and software development today regardless of commercial versus non-commercial goals. So again, this is not just a thing you can do if you're building an open source side project. This is a thing he thinks matters for businesses, too. Moving off Twitter because it's not my favorite place to read articles, and I want to read Mitchell's stuff here. He also calls out that this article was not written with AI at all. I also do not write with AI to the best of my ability. I did like one slot post on my blog forever ago. I'm probably going to unlist. Generally, I just don't like AI writing a whole lot. I do all my writing and all my scripting for videos by hand. I don't even script the videos. I kind of just talk about the things. So very pumped that he's not slopping up this article. The next section he has here is that imports are up. He used the term building block to describe how they're being used because they're being assembled today in a very different way than former decades. I don't use the term library or framework because it extends even up to applications. For example, the ghosty gooey app has more forks than ever before with customized patches on top which is awesome. The factory of today is agentic. I say that as objective truth regardless of what your feelings about it are. You can argue that 99% of the stuff coming out of these factories is total crap. But you can't argue the sheer quantity of stuff that is coming out. The numbers are everywhere, spanning tech stacks and industries, and they're undeniable. AI is okay at building everything from scratch, but it's really good at gluing together highquality, well doumented, and proven components. And AI prefers to do this when it can, unless explicitly prompted otherwise. This is the building block nature of software today. We're more than ever before grabbing off-the-shelf components and gluing them together. Funny enough, earlier today I covered another interesting article about what tech Cloud Code chooses when you don't steer it to specific technologies. And it very much prefers for the most part these modular customizable solutions. Like it's not recommending that you roll your own state management. It recommends Zustan 65% of the time. They're not recommending that you go figure out AWS and do deployments yourself. They recommend Versell 100% of the time if you're working in JS. The models like the tools that they can assemble the way they want, that they can install via npm and they can control and own. And the most popular tool that was recommended here was custom and DIY, but otherwise it's recommending everything it can install and use reliably. And it doesn't even seem to care if there's a paid backing for it like there is with Versell or Resend or Sentry. It recommends what it thinks is best and that it can work with best, which is often the thing it can npm install. Back to the article. Humans of course have always done this as well. For my entire career, human software developers have preferred to build on top of proven primitives. But the natural barrier to entry of understanding the component pieces well enough to even slap them together was high enough to limit the ecosystem. This is a very big deal. I cannot tell you how many times I got the comment on my old videos. How do you keep up with everything going on in webdev? How do you deal with new frameworks every week? How do you possibly pick between 72 state libraries? because it's not that hard to pick if you know anything about the top three. But people had massive decision fatigue and despite the fact that there were all of these awesome modular tools that we could assemble. For example, the T3 stack for those who remember good old days. The reason that we built T3 stack was to make it easier to assemble the tools that we found played well together. God, this site needs an update so badly. The average dev was already bad at finding all the solutions and picking the right one. Asking a non-dev to do it is even worse, but the AI much better. And as Mitchell says here, the barrier is effectively now gone. Exports are up. Coming out of these factories is of course software. So much software. There are negatives, of course. I think the negatives are obvious enough that I'm not going to dedicate much time to them. But I want to recognize that they exist. Security, vulnerabilities, instability, general lack of understanding about how loadbearing systems might work, but there's also a huge amount of positives. The quality bar is lower. A mainline app used by a large cross-section of users has to weigh every feature against every other feature. How do they interact? Does it make sense for the long-term vision? Can I maintain this for millions of users? A factory artifact targeting one to hundreds of users doesn't need to care about this. You can ship faster and looser as a result. Also, the awareness is greater. Mainline apps can't do everything. They usually optimize for use cases that most users need and use. I don't fully agree here. I think that a lot of these big apps are stuck maintaining tons of bespoke [ __ ] for important customers. And that's also a change I think is happening. A factory artifact can optimize for a tiny cross-section of users, and these users gain awareness of the building block as a result. He's seeing this hugely in Ghosty as very niche communities are getting their own specific terminals and things that solve their weird use cases. The maintenance burden is significantly lower. It's easier than ever to say no thank you to feature requests because you're offering a key part of the means to production. He's been spammed so hard that he's complained publicly about this and even made a bot that will automatically say no to people, but now he feels less bad saying no because they can go fork and do it their own way. And the R&D is outsourced. It's so much easier now as a maintainer to look at what others are doing. see working proof of concept and decide what you want to bring back to mainline. There's way less talk and way more walk. And while others are doing the walk, you can cherrypick the best ideas, which is totally fair because you're giving away a building block and they're giving away their ideas. That's the trade-off here. It makes a ton of sense. Mitchell says this is changing how he views software and product development. I couldn't agree more personally. He's much more purposeful about creating building blocks and encouraging applications or forks on top of them. He thinks that this is resulting in happier community and a larger community and ultimately much better mainline software. High-quality apps aren't disappearing and high-quality apps are produced by the developers of these building blocks and those are also not disappearing. For most software categories, he thinks there will always be a majority group that doesn't want personalized slop software and wants a polished, well-maintained and wellsupported application. Instead, he thinks the mainline apps are becoming more stable and more purposeful in their feature set. Thanks to the building block economy, the stability comes from a much larger and diverse user group. The feature set comes from the massive ecosystem of outsourced R&D. The mainline apps are still measured, high quality, and well-maintained, but it's for specific groups. But then there's the problem, and this is something I'm actually very curious what his thoughts are because he managed to commercialize Tyraform. How does he think of commercialization here? The obvious question that follows is what this can mean for commercialization. Closed source commercial software appears to be at a massive disadvantage because it is. Agents will more readily pick open and free software over closed and commercial. At the time of writing this article, that's an objective truth. Independent research labs running experiments on popular models have found repeatedly that under diverse circumstances, models pick open and free alternatives over commercial. So far, he doesn't have a concrete answer here because unlike product and software dev, he's not directly building commercializable products right now. Turns out he made his money. He's happy. He has thoughts, but with all hard things, the answer's nuanced. He doesn't want to give the illusion of talking authoritatively about this, so he's going to avoid it. When he walks the walk and learns more, he'll share. Okay. Thanks for uh not helping here. Appreciate you Mitchell for being honest. Yeah, the shift has happened. We have to accept that building blocks and software factories rule everything around us and accept and internalize the consequences of it. We can choose to run the other direction and create enclaves where we fight against it or we can choose to submit ourselves completely to the chaos. People who know him know he's far less extreme in his actions and carries different opinions depending on the context. His point is simply that the shift has happened and I couldn't agree more. Since Mitchell didn't go on the commercial side, I will talk a bit from my experience as well as the experience I have with other companies in the space and what has been working for them. The biggest thing you have to think about is stickiness. What makes your solution the one that people like? Historically, this has been that you include specific features that users get addicted to and can't leave. But more and more that isn't going to be the case because people will just go build their own bespoke solution. I was upset enough with Frame.io that I built my own alternative. And the hardest part wasn't building it. The hardest part was getting everything set up so I could ship it with a pricing tier and sell it to people so others could use it too. If I just wanted to run this internally, I could have and I would have been done 2x faster at least. And now Lawn is being forked by many people to use for their own businesses and I get no money when they do that right now because they wanted to use Lawn their specific way for their content business. This is people like Snazzy Labs and Jaca aka Jake who used to be at LT. They're forking this to use it internally for their video review pipelines and they were loving it. I think that's awesome. But figuring out how to commercialize that is the challenge. I gave them a set of building blocks that let them solve the problem that they have, but it was missing pieces. They had to figure out how to store the files. They had to figure out how to set up O. They had to figure out if they wanted to add payments, how to do that. How to manage the database, how to manage the state, all these things. And none of them coded. So they just had to do this with agents. And they succeeded. But it took a while. What would it look like to build something like lawn where you can pay us for the server and backend side and getting all of the video info, right? But the actual layer that you engage with and use is owned fully by you if you want and is trivial for you to extend. What if when we set up lawn for you as a customer, it goes to its own custom domain or subdomain and then the build that you're running is a fork of the real original project and then when you want to add things or change things, you just tell it to. What does it look like for forking software to be part of the software? Personally, I think it looks very very sticky. If you try out my solution and you like it, but it's missing something you want, you could go fork if it's open source or if it's open source and built into the product to do such, you can fork it in app. Or if you don't want to deal with the infra side, but you like having the codebase hosted your way, you could fork, host it how you want, and then use our backend to power it so you keep paying us. There are definitely ways to do this without the software being truly open, but I don't know how well and reliably they will work, and I think it would be way too easy to get the source out, and it's better to not deal with that in the first place. I got one more idea that I've been holding tight to my chest that I was planning on not showing to the world until I had a working version. I think I'm going to give it away now. I'm going to regret this. I already regret that I've even said I have something like this on my mind, but at this point I'm too busy to do it myself and I want to get the idea out there, but sharing this early might cost me a lot of money. So, we're going to do a real quick break for an ad first. Today's sponsor is G2I and they're paying me to tell you about how good they are at hiring. And they really are good at it. That's why they're able to help Bataround go from a 50% success rate with new hires to 90% plus while also speeding up the process. That's what they want me to talk about, but I'm just going to ignore that because they do something that's even cooler. Hey, so uh sorry guys, Discount Theo here. He kind of forgot the most important part of the ad, which is the fact that both AI Engineer and React Miami are happening next week. React Miami, you all probably have heard of it. It's the best dev conference of the year. But this year, they are doing just 3 days before AI engineer starting on April 20th, which is going to be an incredible conference. A ton of really, really cool people in the AI space are going to be there. It's actually the first conference I've ever gi. If you just go to their website and take a look at the speakers list, it is a very stacked roster and I am very, very excited for that whole week. If you haven't gotten tickets yet, you really, really should. You can go to soyv.link/miami. Use promo code theo50 off and just go to both conferences. Just trust me, they are worth going to. If you don't go, you will regret it. Do it now. The tickets are running out fast. Just go. Sorry for the adbreak. Wanted to filter out the people who aren't dedicated. This is your reward for watching through to the end of this video. We all already know about the Claude MD, the agent MD. You all might even know about the Soul MD. I've been thinking about these a lot. In particular, the Soul MD. The idea of a piece of software that was designed to have its behavior, characteristics, and way of usage defined as a text file that could be edited in plain English by a normal person. My proposal, and I do actually hope this becomes a standardish thing, the patch MD. Hear me out. I talked in my previous open source video about how much Yasha's way of building broke my brain. Seeing him treat every package in our project as just additional code that he could edit however he wanted and then use patch package to apply his changes so that we could adjust the package to our needs for our use case. There are issues with this though. If the package gets an update and the location of the code we want changes or something shifts, you got to rewrite the patch. So what does it look like to fix that? Let's say we added a feature in T3 code where we had a button in the corner that was customize and when you click it, it would run a forked T3 code as a separate like T3 code custom on your machine and you could make changes to the source and it would just be in a a pseudo dev mode and you see the new UI as the changes happen. Then Julius ships another 100,000 lines of code and 500 commits and all your shit's broken. You could have an agent try to resolve the merge conflict, sure, but what happens when they fail? What if every time you made a customization, it didn't just change it in one place, it changed it in two. Obviously, it will edit the code to do the thing you want, but it will also encode the intent of the change you made in a patch MD file. The patchm simply describes all of the features you have added to the app. And then in the future, an update isn't just downloading the new binary and hoping for the best. The future is you pull down the changes from main. If it applies clean, awesome. Go straight to it. If it doesn't, you can hit a button that says run update with agent and it will try to resolve the merge conflicts. And if it fails or has any issues, we'll tell you, hey, we weren't able to resolve this cleanly. If you want, we will run another instance in the background and reapply these features that you've added in the past. Then you can check and make sure they work how you want, and we'll migrate you when that's done. What if the update button was no longer an update button? What if the update button was a process that would clone the latest code, see which changes cleanly apply and which ones don't, and then lets the agent guide you through getting the new version where you want it to be with your specific stuff added. And what if in thet directory you had this file that described everything you wanted T3 code to be? What does a future look like where all software is self-forking, self-customizing, and self-healing when merge conflicts happen? Since I thought about this, I haven't been able to stop and I am way too goddamn busy to build it myself. This is on the road map for things we want to add to T3 code and there's a lot of little pieces we have to get right for this to work. But I wanted to coin the term patchm because I firmly believe this is the path to allow normal people to edit their software to their liking and to allow for businesses to keep iterating without breaking all the weird forks that all of their users are on. What does the future look like if 90% of your users forked? How do we resolve this? How do we make sure that these users can have what they want but not fall so far behind that they're in a really insecure, poorly supported, terribly integrated place. There's obviously a lot of things that can go wrong here. This is a very different way of thinking about software than we have historically, but so was the Unix philosophy back in the day. I'm very excited for a future where I can fork the app I'm using within the app itself and not have to build my own universe from scratch in order to get what I want. And at the absolute least, it means I would feel much less bad closing the 314 poll requests we have on T3 Code right now. God [ __ ] damn it. For most of you, this proposal probably gives you more questions than answers, and I have the same ones. This is a thing I've been thinking a lot about, and I spent no time actually doing, and I got tired of waiting to share a working version. So, I wanted to put this out so that you guys can think about it, too. Similar to how I've put out ideas like an app that has an infinite canvas in each direction for the work that you're doing, so you can create dimensions to the parallel nature of building with agents. I won't be able to be able to customize without having to do everything else first. And I hope that this idea sticks for some of y'all and that I get to see some fun examples in my replies in the future. We still live in a world where the biggest companies have shitloads of engineers maintaining hundreds if not thousands of features that are used by very small portions of their customer base. This is the direction things are going and I am trying for the first time in a long time to predict where we'll be in a year instead of a few months. But honestly, I'm starting to think this might only take 3 to 4 months. And of course, people are calling it out very much thinking about PI here, too. the idea of a minimal reliable agent that you customize to your liking, not just by adding skills or plugins, but by modifying it for your needs. Software malleability didn't matter when the average user couldn't change it. Now that the average person can prompt their features into existence, the platforms that allow that are going to be the winners. And this is just one way to get there. So to wrap up my argument here, why open source your business? Customers will do research for you. You don't have to support 1% features. Asians like OSS tools more and my personal favorite thing, the community that forms around it. It has been beyond heartwarming seeing all of the awesome stuff happening with T3 code. The hundreds of forks that keep appearing in my replies on Twitter, the insane [ __ ] people are doing with the app. Even people like Maria stuffing it in the terminal with T1 code. That only happens when you're building in an open way. And all of these pieces feed into each other. The more community you have, the more the agents will like it. The more the agents like it, the more customers you'll get. The more customers research for you, the more features you can integrate or not integrate. All of these pieces feed into each other. And you have an incredible opportunity to take an existing product, find the core pieces that make it valuable, rebuild those core features in a customizable, extendable, open way, and then watch what the world does with it. And I really [ __ ] hope I'm right here because I've put a lot of my own money and time on the line. This is not my usual, well, this looks good type recommendation. This is the one I'm building my portfolio around. If I'm wrong on this, my kids don't get college money. But if I'm right about this, my kids will own colleges. So, I really [ __ ] hope I'm right. But in order for this to be the future, in order for the future to be more open instead of more closed because of all the fear about forking and AI hacking and all that [ __ ] I need each and every one of you to come in with me. We need to show the world that open is the right way to do this. And I know we can. You've already shown me. If you can convince me through what you've done to T3 code, we can convince the world alongside us. Go build the open version of the thing that you hate at work. Make the pieces you need to survive and then see who else will use it based on those parts. The future is open if we make it that way. And I need y'all to help me do it. Thank you as always for listening. I know this was a long one, but it's a topic that's very important for me, and I hope you can see why now. Let me know how y'all feel and keep building awesome [ __ ] and ideally do it in the open. And until next time, peace nerds.