A Letter to Tech CEOs - CourtneyR.dev's 2nd Brain

A Letter to Tech CEOs ![rw-book-cover](https://img.youtube.com/vi/G1xqTjoihfo/maxresdefault.jpg) 🔗 **Source:** [A Letter to Tech CEOs](https://www.youtube.com/watch?v=G1xqTjoihfo) > [!note]+ Document Notes > tags: #open-source #business-strategy #ai-agents #software-development #developer-tools > author: Theo - t3.gg > source: YouTube > reference: https://www.youtube.com/watch?v=G1xqTjoihfo > date created: 2024-12-19 10:30 > > # 🏷️ Title: A letter to tech CEOs >  ## 🧰 Action Inbox - [H1] Consider open-sourcing core business features — enable customer customization over feature bloat #open-source - [H2] Implement "building block" architecture — let users code their own integrations instead of plugins #architecture - [H3] Explore patch.md concept for self-healing software forks — maintain customizations through updates #innovation ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [T3 Code GitHub](https://github.com/t3-oss/t3-code) - [Ghostty Terminal](https://ghostty.org) - [Mitchell Hashimoto's Building Block Economy](https://mitchellh.com/) ## 📝 Summary - Theo argues that tech companies should open-source their businesses to survive the AI era - Traditional SaaS moats (feature accumulation) are breaking down as AI agents prefer building blocks over monoliths - Customers increasingly want to customize software themselves rather than request features - Open-source enables community R&D, reduces maintenance burden, and creates stronger network effects - The future belongs to modular, forkable software with self-healing merge capabilities ## 📖 Main Content The video presents a comprehensive business case for open-sourcing software products, driven by fundamental shifts in how AI agents and users interact with software. Theo challenges the conventional wisdom that protecting source code creates competitive advantage, arguing instead that closed-source software faces existential threats in an AI-driven world. The core argument rests on the breakdown of traditional SaaS moats. Historically, companies like Salesforce succeeded by accumulating thousands of features, where each customer uses only ~5% but different customers need different 5%s. This created switching costs because competitors couldn't replicate every edge-case feature quickly enough. AI agents are changing this dynamic by preferring modular, open components they can assemble and customize. Rather than using monolithic applications, they select building blocks that can be combined programmatically. This shift makes traditional feature accumulation strategies less effective. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/G1xqTjoihfo?t=0) — [H1] The trust crisis in closed-source software - Key idea: Quality is declining as companies ship AI-generated features without caring about quality - Evidence: "Companies can just ship whatever they want and they're not caring as much about quality" #### ⏱️ [02:15](https://youtu.be/G1xqTjoihfo?t=135) — [H2] The security and competition risks of open source - Key idea: Open source increases vulnerability to AI-powered attacks and competitive cloning - Evidence: "Cal.com has been struggling a lot with security reports and attempted exploits because Cal is very much open source" #### ⏱️ [04:30](https://youtu.be/G1xqTjoihfo?t=270) — [H1] The Salesforce feature accumulation model - Key idea: Traditional SaaS wins by building thousands of features that create switching costs - Evidence: "1000 features total, each customer uses 50, but different customers need different 50s" #### ⏱️ [08:45](https://youtu.be/G1xqTjoihfo?t=525) — [H2] Why plugin systems fail to solve the problem - Key idea: Plugin architectures require massive engineering effort and still can't cover all use cases - Evidence: "No matter how flexible you make your plugin system, somebody will want something that doesn't work with it" #### ⏱️ [12:20](https://youtu.be/G1xqTjoihfo?t=740) — [H1] The Vercel model of letting customers write code - Key idea: Instead of plugins, let customers integrate via code on your platform - Evidence: "You write the code yourself... anything Vercel doesn't do, you can just do somewhere else" #### ⏱️ [16:30](https://youtu.be/G1xqTjoihfo?t=990) — [H1] T3 Code's remarkable fork statistics - Key idea: 10% of weekly users have forked T3 Code, showing unprecedented customization demand - Evidence: "1,500 attempts to change or customize T3 code... 10% of our users have forked" #### ⏱️ [20:15](https://youtu.be/G1xqTjoihfo?t=1215) — [H2] Emanuel's extensive T3 Code customizations - Key idea: Users are building entirely new features by forking rather than requesting them - Evidence: "He's building tmux into the product... multiple chats at once... his own queuing system" #### ⏱️ [24:00](https://youtu.be/G1xqTjoihfo?t=1440) — [H1] Mitchell Hashimoto's building block economy thesis - Key idea: Building blocks grow faster than applications because AI prefers assembling components - Evidence: "Lib Ghosty got multiple million daily users in 2 months vs Ghosty's 18 months to 1 million" #### ⏱️ [28:30](https://youtu.be/G1xqTjoihfo?t=1710) — [H2] AI agents prefer open and free software - Key idea: Models consistently choose open-source alternatives over commercial closed options - Evidence: "Independent research labs have found repeatedly that models pick open and free alternatives" #### ⏱️ [32:45](https://youtu.be/G1xqTjoihfo?t=1965) — [H1] The stickiness problem in open-source business models - Key idea: Traditional feature-based stickiness breaks down when users can fork and customize - Evidence: "People will just go build their own bespoke solution... I built my own alternative to Frame.io" #### ⏱️ [38:20](https://youtu.be/G1xqTjoihfo?t=2300) — [H1] The patch.md concept for self-healing forks - Key idea: Software should track user customizations and auto-resolve merge conflicts during updates - Evidence: "A patch.md file that describes all of the features you have added to the app" #### ⏱️ [42:10](https://youtu.be/G1xqTjoihfo?t=2530) — [H2] The future of in-app forking - Key idea: Users should be able to fork and customize software within the application itself - Evidence: "What does it look like for forking software to be part of the software?" #### ⏱️ [45:30](https://youtu.be/G1xqTjoihfo?t=2730) — [H1] Why businesses should embrace open source now - Key idea: Community R&D, reduced maintenance burden, and AI preference create competitive advantage - Evidence: "Customers will do research for you... agents like OSS tools more... incredible community" #### ⏱️ [48:00](https://youtu.be/G1xqTjoihfo?t=2880) — [H1] The personal stakes and call to action - Key idea: This isn't just theory—Theo is betting his portfolio on open-source business models - Evidence: "If I'm wrong on this, my kids don't get college money. If I'm right, my kids will own colleges" ## 📚 References - [T3 Code](https://github.com/t3-oss/t3-code) - [Ghostty](https://ghostty.org) - [RWX CI Platform](https://rwx.com) - [Mitchell Hashimoto's Blog](https://mitchellh.com/) - [Vercel](https://vercel.com) - [PostHog](https://posthog.com) ## 🗣️ Paraphrase - Traditional SaaS companies win by accumulating thousands of niche features that create switching costs, but AI agents prefer modular building blocks they can assemble programmatically - Open-source software faces real security and competitive risks, but these are outweighed by the advantages of community development, reduced maintenance burden, and AI agent preference - The future belongs to platforms that enable in-app customization and forking, with automatic merge conflict resolution to maintain user customizations through updates ## 📰 Newsletter The landscape of software development is shifting dramatically as AI agents reshape how we build and use applications. A compelling new thesis suggests that open-source business models may not just survive but dominate in this new era. The key insight: AI agents consistently prefer building blocks over monoliths. Instead of requesting features from vendors, users increasingly want to fork and customize software themselves. This creates unprecedented opportunities for businesses willing to embrace radical openness. Consider the evidence: T3 Code sees 10% of weekly users fork their application—an extraordinary rate of customization that suggests users prefer ownership over feature requests. Meanwhile, building blocks like Ghostty's core library grew faster than the main application, demonstrating the power of modular architecture. The practical implications for WordPress developers are significant. Rather than building every possible feature, successful projects may focus on creating excellent foundations that enable infinite customization. This approach reduces maintenance burden while enabling community-driven R&D. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create case studies showing AI agent preference for open-source tools - Education: Develop workshops on building "forkable" architectures and patch management systems - Developer experience: Design APIs that enable programmatic customization over configuration - Developer marketing: Position open-source as competitive advantage rather than risk - Community management: Establish processes for managing high fork volumes and community contributions #### OSPO - Policy & Governance: Develop frameworks for commercial open-source with customization rights - License Compliance: Create guidelines for fork management and derivative work tracking - Security Management: Implement security scanning for high-fork-volume projects - Software Inventory: Track and manage ecosystem of forks and customizations - Developer Support: Provide tooling and training for patch.md and merge conflict resolution - Community Engagement: Fund development of self-healing fork technologies - Strategic Alignment: Align KPIs with community growth and fork health metrics #### Community - Maintainers: Support development of patch management and auto-merge technologies - Contributors: Create onboarding for fork-first contribution workflows - Sponsors: Fund research into sustainable open-source business models - Ecosystem: Coordinate standards for interoperable building blocks #### WordPress - Core: Investigate modular architecture enabling easier customization and forking - Core Performance: Optimize for fork management and merge operations - Core AI: Develop AI tools for automated patch resolution and feature migration - Core Program Team: Coordinate development of fork-friendly development workflows - Mobile: Enable app customization through configuration rather than feature accumulation - Playground: Build environments for testing customizations and patches - Community: Support meetups focused on building block development patterns - Training: Create curricula for building fork-friendly software architectures - Marketing: Develop narratives around WordPress as ultimate building block platform - Support: Create documentation for managing customized installations - Design: Establish design systems that work across forks and customizations - Documentation: Document best practices for building block architecture - CLI: Develop commands for fork management and patch application - Hosting: Create hosting solutions optimized for customized WordPress instances - Themes: Develop theme architecture supporting easy customization - Plugins: Create plugin standards enabling better composability #### The WPCC - Programs: Fund fellowships for building block architecture research - Projects: Support development of WordPress fork management tools - Funding: Provide grants for open-source business model experimentation #### FAIR - Technical independence: Ensure building block architectures don't create vendor lock-in - Policies: Develop frameworks for fork rights and derivative work governance - Governance artifacts: Create templates for managing high-customization open-source projects ## 🧪 Hypotheses - Open-source businesses will outcompete closed-source equivalents as AI agents become primary software consumers - Fork rates above 5% of user base indicate strong product-market fit for customization-first architectures - Businesses enabling in-app forking will achieve higher retention than those relying on feature accumulation - Self-healing patch systems will become essential infrastructure for managing customized software at scale ### 📊 Methodology - Study design: Compare growth rates and retention between open vs closed-source developer tools - Data collection: Analyze fork patterns, customization frequency, and user retention across platforms - Market research: Survey AI agent behavior preferences across different software architectures ### ❓ Questions - How can businesses maintain revenue when customers can freely fork and self-host? - What technical infrastructure is needed to support widespread software customization? - How do security concerns balance against the benefits of radical transparency? ### 🔮 Future Research - Development of patch.md specification and implementation standards - Economic models for sustainable open-source businesses with high customization rates - Technical architectures for self-healing software and automated merge conflict resolution ### 💡 Implications - Practice: Shift from feature development to building block creation and maintenance - Policy: Need new frameworks for intellectual property in highly-forkable software - Security: Implement security-first development practices for high-visibility codebases - Education: Retrain developers in modular, composable architecture patterns - Funding: Redirect investment toward open-source businesses with strong community effects ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (complex business and technical concepts) #### 👀 Visual learners - Present: Business model diagrams, fork statistics, growth comparisons - Improve: Architecture diagrams showing building block assembly, visual fork trees #### 🔊 Aural learners - Present: 48-minute comprehensive video presentation with examples - Improve: Podcast-style discussion format, audio summaries of key concepts #### 🗣️ Verbal learners - Present: Clear analogies (Salesforce features, building blocks), defined technical terms - Improve: More business case studies, competitive analysis narratives #### 🧩 Kinesthetic learners - Present: Practical examples with T3 Code, Ghostty, concrete fork statistics - Improve: Step-by-step guides for implementing building block architectures #### 🧠 Logical learners - Present: Clear cause-effect relationships, numerical evidence, systematic arguments - Improve: Decision frameworks for open vs closed source, ROI calculations #### 🧑‍🤝‍🧑 Social learners - Present: Community examples, collaborative development stories - Improve: Discussion forums, peer review of business model assumptions #### 🧘‍♀️ Solitary learners - Present: Comprehensive single-source explanation, self-contained arguments - Improve: Reflection questions on personal/company open-source strategy #### 🌿 Naturalistic learners - Present: Ecosystem thinking, organic community growth patterns - Improve: Analogies to biological systems, environmental sustainability connections ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive video content - Improve: Transcript with proper heading markup, alt text for visual diagrams #### Keyboard navigation - Present: Standard YouTube video controls - Improve: Timestamped navigation, keyboard shortcuts for sections #### Contrast and readability - Present: High contrast video player, clear audio - Improve: Captions with high contrast, transcript formatting #### Text resizing and reflow - Present: Responsive video player - Improve: Scalable transcript text, mobile-optimized viewing #### Media and captions - Present: Full video transcript provided - Improve: Professional captions, downloadable transcript, chapter markers #### Forms and interactions - Present: Standard video interactions - Improve: Interactive transcript with clickable timestamps ### 🌍 DEIB Assessment #### Cultural breadth - Present: Examples from global tech companies (Salesforce, AWS, etc.) - Improve: International open-source project --- ## Full Transcript [00:00] I recently published a video about how [00:01] much I'm losing trust in closed source [00:03] software. It seems more and more like [00:05] the future that I want is open one where [00:07] I can make changes and use the version [00:09] of the thing that works for me instead [00:11] of being stuck with whatever the company [00:12] building it wants me to use instead. I [00:14] have a lot of gripes with a lot of [00:15] closed source software and they're [00:16] growing every day. And yes, AI is [00:18] definitely to blame. Now that companies [00:20] can just ship whatever they want and [00:22] they're not caring as much about [00:23] quality, the quality of the things I use [00:25] is going down. But that's me personally. [00:28] What about the business side? The [00:30] business case is getting sketchier and [00:31] sketchier as time goes by. If your code [00:33] is open source, it's way easier for [00:35] agents to find things that are insecure [00:37] and pone them. It's way easier for a [00:39] nobody to just tell the agent to fork it [00:41] and host it themselves so that you don't [00:42] ever get paid. And it's way easier for [00:44] other companies to clone your work, [00:46] point their agents at your product, and [00:47] then build it into their stuff. So, why [00:50] would you ever open source your [00:51] business? It's a great question and I'm [00:54] going to go really really strong on the [00:56] case for open-source as a company. While [00:59] I agree that open sourcing your apps [01:01] increases the risk profile of the things [01:03] you're building, I'm beginning to think [01:04] that if you don't do it, you might be [01:06] doomed. I've been advising most of the [01:08] companies I work with, especially the [01:10] ones I invest in, to go as allin on open [01:12] source as they possibly can. And I [01:14] cannot wait to tell you guys all why. Up [01:16] until this point, the rant I'm about to [01:18] do is info I kind of held privately and [01:20] I would give to the companies I was [01:22] working with and invested in in order to [01:23] give them an advantage. But the more [01:25] I've thought about it, the more I [01:27] realized that I should give this out for [01:29] free. As big as the advantage is for the [01:31] companies in my portfolio to know all of [01:33] this information, I would rather [01:34] everybody does in hopes that we get more [01:37] good open-source products in the future. [01:39] But if I'm giving my code and my [01:41] information out for free, someone's got [01:43] to pay me. So we're going to take a [01:44] quick break for today's sponsor. If [01:45] you've never pushed code that breaks CI, [01:47] you can skip this ad. Okay, now that all [01:49] the fake devs are out of the room, I [01:50] want to talk about today's sponsor, RWX. [01:52] This is a new way of doing CI that's [01:54] actually ready for agents. What do I [01:56] mean by that? We can start with the [01:57] skill that they provide because it's [01:59] really, really cool. It lets you set up [02:00] what they refer to as a run loop. A run [02:02] loop allows for your agent to run a CLI [02:05] command to run your full CI with all of [02:07] the fancy caching and everything they [02:08] enable so that your agent can get [02:09] feedback fast before it even commits. [02:11] Instead of committing a change, pushing [02:13] it, waiting for your CI to run, then [02:15] copy pasting the error back to your [02:16] agent, you can just let it run in a loop [02:18] until it fixes everything. Combine this [02:19] with a commit that adds a failing test [02:21] for the feature that you're trying to [02:22] build, and you can basically guarantee [02:24] your agents will actually fix the thing. [02:25] The more I think about it, the more [02:26] insane it is that you can't just run a [02:28] GitHub action locally with a simple run [02:30] command like they provide with their [02:32] CLI. Once you move to RWX, you'll never [02:34] want to go back because you can just run [02:36] the thing locally. Like, imagine if [02:37] GitHub CLI had a way to run your action. [02:39] I don't know how they don't, but I'm [02:40] very thankful RWX does. As if that [02:42] wasn't good enough, their dashboard and [02:44] their performance sell it even further [02:45] for me. You can get a little diagram [02:47] that shows which steps did or didn't run [02:49] because they were cached. And they can [02:50] break up your work into parallel [02:52] cachable trees that make it much easier [02:55] to not have to run work you don't have [02:57] to or have multiple things running in [02:58] parallel once a point is hit. The [03:00] timeline view makes it super easy to see [03:01] why things take too long. And then once [03:03] you're hitting those cache runs, the [03:05] result is insanely quick times. So, this [03:07] run took two minutes initially to get [03:09] everything set up and running. And now [03:11] when you do further checks, it only [03:12] takes 22 seconds. CI currently slows [03:15] down your team when it should be [03:16] speeding up your agents. Fix it now at [03:18] soyv.link/rwx. [03:20] So, why the hell should anybody open [03:22] source their business? We should first [03:24] start by listing the cases against this. [03:27] I mentioned these at the start, but to [03:28] quickly summarize, competitors cloning [03:31] is a very real risk. If you add a cool [03:33] feature to your product and the [03:34] competitor can just point their agent at [03:36] your repo and say, "Rebuild this," [03:38] you're screwed. Self-hosting is a real [03:40] risk, too. If your customers just never [03:42] end up customers because they run your [03:44] stuff on their own infrastructure. And [03:46] one of the biggest, especially now after [03:47] the Mythos stuff, is the security risk. [03:50] Agents are able to like decompile and [03:52] figure out holes in systems relatively [03:55] well, but they are much better at it for [03:56] open- source projects. For example, I [03:58] happen to know that Cal.com has been [04:00] struggling a lot with this because of [04:02] the sheer volume of security reports and [04:05] also attempted exploits they're getting [04:06] because Cal is very much open source. [04:08] So, knowing all that I know here and [04:10] knowing how big these problems are, and [04:12] I I don't want to discount this, these [04:14] are all real problems that you should be [04:16] thinking about if you're considering [04:17] open sourcing your stuff. Hell, this one [04:19] is why we haven't done T3 Chat yet. I [04:21] know it's the comment I'm getting [04:23] spammed with the most. I really want to [04:25] open source T3 Chat. The reason we [04:26] haven't is a combination of the security [04:28] risk and the edge effort that we have. [04:30] We're a two and a half person team and [04:32] I'm the half person and I'm barely even [04:34] half because I'm so goddamn busy. Julius [04:36] is all in making sure that T3 Code keeps [04:38] on iterating and Mark is entirely [04:40] swamped with support for T3 Chat. Open [04:42] sourcing T3 Chat would destroy us right [04:45] now. But since T3 code uses your sub on [04:48] your machine, we don't have to worry as [04:50] much about destroying all of our users [04:52] lives and all of our infrastructure if [04:54] there is some small thing that isn't as [04:56] secure as it could be here. Where with [04:57] T3 chat we could literally lose millions [04:59] of dollars in seconds. That is why we [05:01] haven't. And even then I'm kicking [05:03] myself wishing I could because of how [05:05] big the benefits are. So what are those [05:08] benefits? What are the things that I [05:10] keep telling companies when I am [05:12] thinking about open source? I want to [05:14] start with an interesting angle here of [05:16] who wins right now. This is my business [05:18] analysis for those who always wonder [05:20] like how do I pick my investments? How [05:22] do I see the market? All those types of [05:23] things. I try to not talk about that too [05:25] much here because this channel is more [05:26] about code and how we build software, [05:28] not about how I think about the business [05:30] landscape in the market. Every once in a [05:32] while, I have the opportunity to nerd [05:33] out about business stuff. And it seems [05:34] like you all like it. So hopefully [05:36] you'll like this part because I'm going [05:38] to go the full capitalist route to how [05:40] we get to open source. Now, hear me out. [05:42] Also worth noting is when I say right [05:44] now, I'm not necessarily referring to [05:46] this exact instance. I'm talking about [05:48] historically who have the winners been. [05:50] And I hope we can all agree with the [05:51] following companies being winners. AWS [05:54] obviously a winner. Salesforce is a [05:56] pretty clear, obvious, gigantic winner. [05:59] Retool is an interesting one that we'll [06:01] talk about a bit. If you're not [06:02] familiar, Retool is now rebranding [06:04] itself as an AI thing. But previously, [06:06] it was a tool that would integrate every [06:08] source of data you and your company had [06:10] in order to make it easy to build like [06:12] dashboards and widgets and solutions for [06:14] like your internal review team or your [06:17] customer support to have a custom [06:19] dashboard to go update something in some [06:21] random database that your company relies [06:22] on. It was kind of a a glue tool that [06:24] made it easy for non-devs and slightly [06:27] technical people to make a dashboard to [06:30] integrate with literally whatever data [06:31] source you had across the [ __ ] world. [06:33] I picked all of these companies for very [06:35] specific reasons, but I hope we all [06:37] agree here. All of these companies at [06:39] the very least as of like 2022 were [06:42] obvious, very very big winners. So why [06:45] am I picking these companies? Well, [06:47] let's take one like Salesforce for [06:49] example. Let's say you want to do the [06:51] suicidal thing and you want to compete [06:53] with Salesforce. We got to think about [06:55] all the features that Salesforce has. [06:57] These are all entirely fake numbers, but [06:59] I think it'll communicate my point well. [07:00] Let's say that Salesforce has a thousand [07:03] features. There's a thousand things [07:05] Salesforce can do or integrate with. Any [07:08] given customer only uses about 50 of [07:10] them. So, you're probably looking at [07:12] this and thinking that's insane, right? [07:13] Like if every customer is only using 50 [07:15] of those features and there's a thousand [07:17] of them, that ratio is really off. The [07:20] customer is only touching 5% of the [07:22] features. That sounds insane, right? [07:24] Like you have hundreds of thousands of [07:26] people at your company with Salesforce. [07:28] You got at least a few thousand [07:29] engineers working on building and [07:31] maintaining this pile, but any given [07:33] customer is only using 5% of it at most. [07:36] This just obviously makes no sense, [07:38] right? Like you got to trim down the [07:40] features. Well, here's where things get [07:42] interesting. And again, these are made [07:43] up numbers, but I'm promising you having [07:45] seen real numbers, the trends follow [07:47] roughly what I'm describing here. Of [07:49] those 50 features that a given customer [07:51] uses, half of them are used by the [07:53] majority of customers. So we'll say 80% [07:55] of customers use same 25 features. So [07:59] the vast majority of the customers are [08:01] using this core set. But the other 25 [08:04] features, the other 25 are used by less [08:06] than 1% of the customers. So in this 50 [08:10] half of them 2.5% of the total are used [08:12] by almost everybody and then the [08:15] remainder of the other 950 features are [08:19] split almost randomly across the rest of [08:21] the customer base. So what happens if [08:23] you want to build a competitor? Well, [08:25] obviously you start with the 25 features [08:28] everyone uses, but then you go to a [08:30] customer and say, "Hey, we saw you're [08:31] using Salesforce. We would love to move [08:33] you over to our platform. We're cheaper. [08:34] We're faster. We're more reliable. What [08:36] will it take to get you to move over?" [08:38] and they say, "Okay, looks like you have [08:39] all these features we want. Wait, what [08:42] about this random one bespoke thing that [08:44] one person on the team uses?" Oh, uh, [08:47] yeah, we don't have that yet. Oh, well, [08:48] I guess we're just going to stick with [08:49] Salesforce then. [ __ ] And then this [08:52] happens over and over again, and you [08:53] realize you can't get any customers [08:55] because even if you have 49 of the 50 [08:57] features they need, that one last [08:59] feature is used by so few people that [09:02] it's hard to justify adding it for just [09:04] one customer. This is the case for most [09:06] of these gigantic companies that have a [09:09] majority hold of the market they're in [09:11] and have thousands of employees and [09:13] engineers working on them. They have [09:14] been around for long enough that as [09:16] customers need specific things, they [09:18] build them. And if you have a million [09:20] customers, a feature that 1% of them use [09:23] is still used by 10,000 customers. If [09:26] you have a 100 customers, a feature [09:28] that's used by 1% of them is used by one [09:29] team. That doesn't work. This is why [09:32] historically we've had these big SAS [09:33] companies that win super hard because [09:35] once they get their initial customer [09:37] base, they keep adding weird features to [09:39] hold their customers in and then they [09:41] can never leave because nobody can build [09:43] all of the specific stuff that every [09:45] random customer needs fast enough to [09:47] compete. That's changing. I already saw [09:49] people in chat theorizing what the [09:51] solution [09:56] to do all the things that you need it to [09:58] do. Well, I have built plug-in [09:59] architectures before. They're [ __ ] [10:01] hell. No matter how flexible you make [10:04] your plug-in system, somebody will want [10:06] something that doesn't work with it. And [10:08] at least one of those 50 features is not [10:10] going to work in whatever plugin or [10:12] extension system that you think you can [10:14] build here. And my chat quickly caught [10:16] on here. Plugins are hell. Plugin [10:18] systems suck so much. Absolute hell. One [10:20] plugin could take down the entire app, [10:22] guaranteed. Yep. Absolutely. So while [10:25] plugins can work, they require way more [10:27] engineering effort to get the [10:29] architecture right. They will cause [10:31] endless support woes and costs and in [10:34] the end not even cover all of the [10:36] features that your customers want. But [10:38] there are companies that have found [10:39] success going in this direction. I would [10:40] argue Salesforce is one of them. Retool [10:42] is obviously like one of the biggest [10:44] here where they built their own plug-in [10:45] system as well as plugins for every [10:47] [ __ ] thing you'd ever want to [10:48] integrate. But then you're kind of stuck [10:50] to an extent. If you ever want to change [10:52] the plug-in system, you're going to [10:53] break something for some customer and [10:54] you're going to risk losing them. You [10:56] get locked really hard. So, how do we [10:58] deal with this? Well, historically, the [11:00] solution has been just hire all of the [11:02] engineers, add all of the features [11:03] everyone ever wants, and know that your [11:05] customers can't leave because nobody can [11:07] compete because nobody has all the [11:08] features you do. If you're able to [11:10] identify a subset of the market that [11:12] only needs a certain core set, and [11:14] enough of those features are poorly [11:15] implemented in your competition that you [11:17] can wedge your way in, that can work. [11:19] We've seen that with something like [11:20] Versella versus AWS. Verscella is [11:23] largely built on top of AWS and it is [11:26] missing a lot of the features. I would [11:27] argue the vast majority of the things [11:29] AWS can do. But the use case of a [11:31] developer who wants to deploy their web [11:33] application at scale, the scale being [11:36] really small or really big with a good [11:38] integration with GitHub where they're [11:39] putting their code, that is a common [11:41] enough use case that is technically [11:43] handled by all of the things AWS [11:45] includes, but the happy path to do that [11:47] is not very happy on AWS. It's a lot of [11:50] work to get it right, and it's easy to [11:51] fook on yourself and screw things up, [11:53] especially if you want to spin up [11:54] multiple projects randomly throughout [11:56] whenever. Verscell was started in order [11:58] to make it easier to deploy next apps [12:00] because the team noticed this fault that [12:02] web devs didn't really know how to deal [12:04] with all of the crust within AWS. And [12:06] even when they did, it was too slow and [12:07] annoying to set up. And with all of [12:09] that, Verscell was able to establish [12:10] their own corner of the market building [12:12] on top of AWS that is still doing very, [12:15] very well. But there's another part of [12:17] why Verscell went so well. And it's [12:19] certainly not that they made a plug-in [12:20] system. So what made Versel work so well [12:23] then? To put it simply, you write the [12:25] [ __ ] code yourself. While Versel [12:27] hosts the code for the backend for your [12:30] web app as well as the CDN for the [12:32] binaries you're distributing to your [12:34] users, they're letting you write the [12:36] code that is hosted on their servers. [12:37] So, anything Verscell doesn't do, you [12:39] can just do somewhere else. You want to [12:41] use Cloudflare as your firewall, go [12:43] nuts. You want to use Superbase as your [12:44] database, go nuts. You want to use [12:46] Convex for handling all of your database [12:48] and your back-end queries, go right [12:50] ahead. I have a lot of apps deployed on [12:52] Verscell where the back end isn't on [12:54] Verscell. I'm just using Verscell as a [12:55] CDN effectively and for hosting the [12:57] domain and then Convex does all of the [12:59] backend work. So even though Verscell is [13:01] missing 95 plus% of the things AWS can [13:05] do, it does the things it does well so [13:07] well that you can start with it and [13:09] whenever you're missing one of those [13:10] things, you can just plug it in via [13:12] code. And notice the difference here. I [13:14] am not saying plugins. I'm saying plug [13:17] it in with code. It is your job to build [13:20] the plug-in system, so to speak. [13:22] Verscelo is just providing the place [13:24] where the code runs. The market was [13:26] already starting to move in this [13:27] direction before AI systems that let you [13:30] get started and maintain and scale [13:32] easily that don't have all the craft [13:34] that they don't need. So, you can go [13:36] grab that from somewhere else. Even AWS [13:38] is arguably built this way where any [13:40] given service can only do so many [13:42] things. And if you want it to do other [13:44] things, you grab it from another service [13:45] on AWS. And all of Amazon's attempts to [13:48] streamline that and have like one [13:50] service that does most things like [13:51] Amplify have failed really hard. The [13:54] modular nature of these platforms are [13:56] hugely important for their success. So [13:59] obviously this makes sense for a hosting [14:00] platform like Verscell because Verscell [14:03] is hosting your code. You can plug your [14:05] code into whatever else you want and [14:06] you're good. But Versell is just one [14:09] type of business. It's infrastructure. [14:10] What about Salesforce and Retool? Those [14:12] are applications. There are applications [14:14] that have to integrate with a lot of [14:15] complex things. How would you compete [14:17] with them today? Here is where we get [14:19] into my spicy takes. This is the thing [14:21] that clicked for me as I was ubering to [14:23] demo day at Y Combinator as I was trying [14:24] to answer questions some of the founders [14:26] had about how I'm thinking about open [14:27] source. I was already thinking in this [14:29] direction, but the framing clicked in [14:31] that moment and I've wanted to write it [14:32] down since. I actually started an [14:33] article and decided to do a video [14:35] instead. Simplest way I can put it, you [14:37] got to let your customers make their [14:38] weird [ __ ] Instead of building all [14:41] these crazy features into your product, [14:43] you have to make it as easy as possible [14:45] for your customers to integrate their [14:47] things. With Versel, this is easy [14:49] enough. They're just hosting your code. [14:50] You can integrate whatever. But when you [14:52] don't have an info platform or you're [14:54] trying to work with a company that [14:55] already does, this gets way more [14:57] complex. It's much easier to adopt [14:59] forcell when you don't have any solution [15:01] yet. It's much harder when you do. So, [15:03] you got to start thinking in a more [15:05] modular way, a more building block [15:07] oriented way, and I would argue in a [15:09] more open way. If you're not already [15:11] familiar, we put out T3 code as an open- [15:13] source alternative to all the vibe [15:15] coding guies, but we don't have any way [15:17] to make money on it right now, just to [15:18] be very clear. T3 code makes you bring [15:20] your own sub from a platform like Codeex [15:23] or Claude. So, you have a cloud code sub [15:25] or a codeex sub or API if you want and [15:27] then you have to have the CLI setup [15:28] installed on your machine. And we have [15:30] effectively just made a better guey like [15:32] a graphical wrapper for the CLI because [15:34] as much as I love terminals, I [15:36] personally very much prefer having a [15:39] guey when you're doing back and forth [15:41] conversational type stuff. It's just [15:43] significantly nicer overall. Everybody I [15:45] know who's tried it, even terminal [15:47] people have come around and accepted [15:48] that this is the better way to do these [15:50] things. We're open source and on GitHub, [15:52] but the numbers I want to share here, I [15:53] think, will help this click. All time, [15:55] T3 Code has had about 45,000 or so [15:58] people sign up. It's about 42K. And when [16:00] I say sign up, I don't mean register or [16:02] anything. I mean that a unique [16:04] identifier was used when they installed [16:06] the app. And we've had 42,000 people [16:08] open it once. We have a rate about 16K a [16:12] week using the app right now, which are [16:14] really good numbers for a brand new dev [16:15] tool. But that's not what I want to talk [16:17] about. I want to talk about this number. [16:18] We have almost 9,000 stars, but we also [16:21] have 1 and a half thousand forks. [16:24] Onetenth of our weekly users are forked. [16:27] Do you know how crazy that is? 10% of [16:30] our users have forked and made some [16:33] customization. They might keep running [16:34] the fork themselves. They might drop it [16:36] and go back to the app themselves. They [16:38] might have tried to make some PR and [16:40] then it died. But that is 1,500 attempts [16:44] to change or customize T3 code in some [16:46] way. This has been [ __ ] me up. I've [16:48] just been staring at this and thinking [16:50] too much about it since it happened. The [16:53] sheer volume of people customizing T3 [16:56] code to their liking has just broken my [16:59] brain and how I think about these things [17:00] on a fundamental level. Every day I get [17:02] tagged in posts like this like Emanuel [17:04] who has been customizing the [ __ ] out of [17:06] T3 code. He's deep in his own fork now [17:08] that he's even called DP code and now [17:10] he's adding some of the features from [17:12] CMUX into it where he has multiple [17:13] terminals open. We don't have very much [17:16] terminal stuff in T3 code. It's just [17:17] like command J opens a small terminal in [17:19] the bottom. He's building Semucks into [17:22] the product now. He already built split [17:24] chat so you could have multiple [17:25] terminals and the chat all visible [17:27] horizontally at once. He let you do [17:29] multiple chats at once. He built his own [17:32] queuing system. He brought in commands [17:34] and plugins. And his framing here is [17:36] great. He's been playing with T3 code. [17:38] He loves it. It's a skeleton to play [17:40] with and build from. I want to express [17:42] that I love what Theo and Julius made. I [17:44] decided to add the Codex apps over [17:45] server with proper skills and UI. He was [17:47] talking about how fun it is to play in [17:48] the codebase. And he's also building [17:50] mobile codec stuff, too. That's really [17:51] good. Like, he could just go build his [17:54] own thing, but instead has forked what [17:56] we built and keeps going deeper and [17:58] deeper into it. He even added a handoff [17:59] feature, which I actually really want to [18:00] rip. There's a lot of really cool stuff [18:02] here that I want to get added to the [18:03] official T3 code project. Obviously, [18:06] since we want to make these things work [18:07] well and reliably for all use cases, [18:09] it's going to take us more effort to get [18:10] it just right in a general sense. But do [18:12] you know how [ __ ] cool it is to have [18:15] users download the source code, [18:17] customize it to their liking, and then [18:19] share all the cool things they did with [18:21] it? It's magical. And this never [18:24] happened to this level before. [18:25] Obviously, there's always been open [18:27] source. People have always been able to [18:28] customize, but the cost of that [18:29] customization has gone down immensely [18:32] because of the thing I haven't said a [18:34] whole lot thus far. Somehow, AI. [18:36] Suddenly, you don't even need to be a [18:38] dev to add a feature to a codebase as [18:40] long as you have the codebase. So, who [18:42] needs plugins anymore? The future I'm [18:45] imagining here is one where what [18:47] Emanuel's doing isn't so much a thing he [18:50] has to do as a developer where he clones [18:52] the whole project and has to make [18:54] changes and then pull things down from [18:56] main and keep it up to date himself. [18:58] What I'm imagining is a future where [19:01] every customer is running their own [19:02] fork. What would it look like if you had [19:05] a product like, I don't know, Post Hog, [19:07] which is open source by the way. Post [19:09] Hog can be self-hosted relatively [19:10] easily. I would never do it because I [19:12] don't want to deal with managing my own [19:14] cluster of ClickHouse. Just not [19:16] appealing to me at all. But if I could [19:17] build my own chart systems or features [19:19] in suddenly it gets a lot more [19:22] interesting for me. I cannot tell you [19:23] how many times I had a specific chart or [19:26] visualization I wanted in post hog that [19:28] ended up being a back and forth with [19:29] their support and edges for like 2 to 3 [19:31] weeks just for them to ultimately be [19:33] like eh I don't think that's important [19:34] enough. I hate that. And even though I [19:36] love Post Hog, I've had moments where I [19:38] considered leaving because they were [19:39] missing one type of chart that I wanted [19:41] really badly, which is insane. But I'm [19:44] not going to host my own Post Hog [19:45] because I don't want to deal with all of [19:47] that. But I would absolutely like to [19:49] customize my post hogg and make changes [19:51] to the binary that I and my team use [19:54] while still relying on their backend, [19:55] their servers, their everything. And I'm [19:57] not the only one who's thinking this [19:58] way. One of the other big winners that I [20:01] intentionally didn't mention is [20:03] HashiCorp. HashiCorp is the company that [20:05] maintains Terraform as well as many [20:07] other tools that companies rely on for [20:09] building software at scale. Mitchell was [20:12] the creator of Hashi Cororp as well as [20:13] Terraform specifically. And he's also [20:15] now very wellknown, arguably better [20:17] known for creating Ghosty, the terminal [20:18] that we all know and love. Ghosty is [20:20] very popular. I'm sure most of y'all [20:22] have at least heard of it if you're not [20:23] already using it if you don't have it [20:24] open on your computer right now. But [20:26] just today, he wrote an article that [20:28] kind of emphasized this point that I've [20:29] been trying to make for a month. The [20:31] building block economy. The most [20:32] effective way to build software and get [20:34] massive adoption is no longer [20:36] highquality mainline apps. Rather, it's [20:38] via building blocks that enable and [20:40] encourage others to build quantity over [20:42] quality. Over 18 months, Ghosty got a [20:44] million daily users. Lib Ghosty, which [20:47] is a library that powers Ghosty's entire [20:49] terminal binding layer. It's also its [20:51] own separate project that can be [20:52] installed and used to make your own [20:54] terminal or add your own terminal to [20:56] other products. And it got multiple [20:57] million daily users in just 2 months. [20:59] So, it took 2 months for the core of [21:01] Ghosty to grow past Ghosty itself after [21:05] 18 months. Do you understand how insane [21:07] this is in particular? The building [21:09] blocks are what the agents like and over [21:11] time the building blocks are going to be [21:13] what the businesses like too. If your [21:14] team no longer has to be blocked on the [21:16] feature that the product doesn't have [21:18] and instead the PM who needs it can go [21:21] spin that up as part of the app [21:23] themselves. That changes things a lot. I [21:25] kind of want to read this whole Mitchell [21:26] thing. [ __ ] it. Let's do it. [21:27] Experiencing this firsthand as well as [21:29] witnessing it in other ecosystems has [21:30] fundamentally shifted how I view the [21:32] practice of product and software [21:33] development today regardless of [21:35] commercial versus non-commercial goals. [21:37] So again, this is not just a thing you [21:38] can do if you're building an open source [21:40] side project. This is a thing he thinks [21:42] matters for businesses, too. Moving off [21:44] Twitter because it's not my favorite [21:45] place to read articles, and I want to [21:47] read Mitchell's stuff here. He also [21:48] calls out that this article was not [21:49] written with AI at all. I also do not [21:51] write with AI to the best of my ability. [21:53] I did like one slot post on my blog [21:55] forever ago. I'm probably going to [21:55] unlist. Generally, I just don't like AI [21:58] writing a whole lot. I do all my writing [22:00] and all my scripting for videos by hand. [22:02] I don't even script the videos. I kind [22:03] of just talk about the things. So very [22:05] pumped that he's not slopping up this [22:07] article. The next section he has here is [22:09] that imports are up. He used the term [22:10] building block to describe how they're [22:12] being used because they're being [22:13] assembled today in a very different way [22:15] than former decades. I don't use the [22:16] term library or framework because it [22:18] extends even up to applications. For [22:20] example, the ghosty gooey app has more [22:22] forks than ever before with customized [22:23] patches on top which is awesome. The [22:25] factory of today is agentic. I say that [22:27] as objective truth regardless of what [22:29] your feelings about it are. You can [22:31] argue that 99% of the stuff coming out [22:33] of these factories is total crap. But [22:35] you can't argue the sheer quantity of [22:37] stuff that is coming out. The numbers [22:38] are everywhere, spanning tech stacks and [22:40] industries, and they're undeniable. AI [22:42] is okay at building everything from [22:44] scratch, but it's really good at gluing [22:45] together highquality, well doumented, [22:47] and proven components. And AI prefers to [22:49] do this when it can, unless explicitly [22:51] prompted otherwise. This is the building [22:53] block nature of software today. We're [22:54] more than ever before grabbing [22:56] off-the-shelf components and gluing them [22:58] together. Funny enough, earlier today I [23:00] covered another interesting article [23:02] about what tech Cloud Code chooses when [23:04] you don't steer it to specific [23:05] technologies. And it very much prefers [23:07] for the most part these modular [23:09] customizable solutions. Like it's not [23:11] recommending that you roll your own [23:13] state management. It recommends Zustan [23:14] 65% of the time. They're not [23:16] recommending that you go figure out AWS [23:18] and do deployments yourself. They [23:20] recommend Versell 100% of the time if [23:22] you're working in JS. The models like [23:24] the tools that they can assemble the way [23:26] they want, that they can install via npm [23:28] and they can control and own. And the [23:30] most popular tool that was recommended [23:33] here was custom and DIY, but otherwise [23:35] it's recommending everything it can [23:36] install and use reliably. And it doesn't [23:38] even seem to care if there's a paid [23:40] backing for it like there is with [23:41] Versell or Resend or Sentry. It [23:44] recommends what it thinks is best and [23:46] that it can work with best, which is [23:48] often the thing it can npm install. Back [23:50] to the article. Humans of course have [23:52] always done this as well. For my entire [23:54] career, human software developers have [23:55] preferred to build on top of proven [23:57] primitives. But the natural barrier to [23:59] entry of understanding the component [24:00] pieces well enough to even slap them [24:02] together was high enough to limit the [24:03] ecosystem. This is a very big deal. I [24:06] cannot tell you how many times I got the [24:08] comment on my old videos. How do you [24:10] keep up with everything going on in [24:11] webdev? How do you deal with new [24:13] frameworks every week? How do you [24:15] possibly pick between 72 state [24:17] libraries? because it's not that hard to [24:19] pick if you know anything about the top [24:20] three. But people had massive decision [24:22] fatigue and despite the fact that there [24:24] were all of these awesome modular tools [24:26] that we could assemble. For example, the [24:28] T3 stack for those who remember good old [24:30] days. The reason that we built T3 stack [24:32] was to make it easier to assemble the [24:34] tools that we found played well [24:36] together. God, this site needs an update [24:37] so badly. The average dev was already [24:40] bad at finding all the solutions and [24:41] picking the right one. Asking a non-dev [24:43] to do it is even worse, but the AI much [24:46] better. And as Mitchell says here, the [24:48] barrier is effectively now gone. Exports [24:51] are up. Coming out of these factories is [24:52] of course software. So much software. [24:54] There are negatives, of course. I think [24:56] the negatives are obvious enough that [24:57] I'm not going to dedicate much time to [24:58] them. But I want to recognize that they [25:00] exist. Security, vulnerabilities, [25:01] instability, general lack of [25:02] understanding about how loadbearing [25:04] systems might work, but there's also a [25:05] huge amount of positives. The quality [25:07] bar is lower. A mainline app used by a [25:09] large cross-section of users has to [25:10] weigh every feature against every other [25:12] feature. How do they interact? Does it [25:13] make sense for the long-term vision? Can [25:15] I maintain this for millions of users? A [25:17] factory artifact targeting one to [25:19] hundreds of users doesn't need to care [25:20] about this. You can ship faster and [25:22] looser as a result. Also, the awareness [25:24] is greater. Mainline apps can't do [25:26] everything. They usually optimize for [25:27] use cases that most users need and use. [25:29] I don't fully agree here. I think that a [25:31] lot of these big apps are stuck [25:32] maintaining tons of bespoke [ __ ] for [25:34] important customers. And that's also a [25:36] change I think is happening. A factory [25:38] artifact can optimize for a tiny [25:39] cross-section of users, and these users [25:41] gain awareness of the building block as [25:43] a result. He's seeing this hugely in [25:44] Ghosty as very niche communities are [25:46] getting their own specific terminals and [25:48] things that solve their weird use cases. [25:50] The maintenance burden is significantly [25:52] lower. It's easier than ever to say no [25:54] thank you to feature requests because [25:55] you're offering a key part of the means [25:57] to production. He's been spammed so hard [25:59] that he's complained publicly about this [26:01] and even made a bot that will [26:02] automatically say no to people, but now [26:04] he feels less bad saying no because they [26:06] can go fork and do it their own way. And [26:08] the R&D is outsourced. It's so much [26:10] easier now as a maintainer to look at [26:12] what others are doing. see working proof [26:14] of concept and decide what you want to [26:16] bring back to mainline. There's way less [26:17] talk and way more walk. And while others [26:19] are doing the walk, you can cherrypick [26:20] the best ideas, which is totally fair [26:22] because you're giving away a building [26:23] block and they're giving away their [26:24] ideas. That's the trade-off here. It [26:26] makes a ton of sense. Mitchell says this [26:27] is changing how he views software and [26:29] product development. I couldn't agree [26:30] more personally. He's much more [26:32] purposeful about creating building [26:33] blocks and encouraging applications or [26:34] forks on top of them. He thinks that [26:36] this is resulting in happier community [26:38] and a larger community and ultimately [26:39] much better mainline software. [26:41] High-quality apps aren't disappearing [26:43] and high-quality apps are produced by [26:44] the developers of these building blocks [26:46] and those are also not disappearing. For [26:48] most software categories, he thinks [26:50] there will always be a majority group [26:51] that doesn't want personalized slop [26:53] software and wants a polished, [26:54] well-maintained and wellsupported [26:56] application. Instead, he thinks the [26:58] mainline apps are becoming more stable [26:59] and more purposeful in their feature [27:01] set. Thanks to the building block [27:02] economy, the stability comes from a much [27:04] larger and diverse user group. The [27:05] feature set comes from the massive [27:06] ecosystem of outsourced R&D. The [27:08] mainline apps are still measured, high [27:10] quality, and well-maintained, but it's [27:12] for specific groups. But then there's [27:14] the problem, and this is something I'm [27:15] actually very curious what his thoughts [27:16] are because he managed to commercialize [27:18] Tyraform. How does he think of [27:19] commercialization here? The obvious [27:21] question that follows is what this can [27:23] mean for commercialization. Closed [27:24] source commercial software appears to be [27:26] at a massive disadvantage because it is. [27:28] Agents will more readily pick open and [27:29] free software over closed and [27:30] commercial. At the time of writing this [27:32] article, that's an objective truth. [27:33] Independent research labs running [27:35] experiments on popular models have found [27:37] repeatedly that under diverse [27:38] circumstances, models pick open and free [27:40] alternatives over commercial. So far, he [27:43] doesn't have a concrete answer here [27:44] because unlike product and software dev, [27:46] he's not directly building [27:47] commercializable products right now. [27:48] Turns out he made his money. He's happy. [27:50] He has thoughts, but with all hard [27:52] things, the answer's nuanced. He doesn't [27:53] want to give the illusion of talking [27:55] authoritatively about this, so he's [27:57] going to avoid it. When he walks the [27:59] walk and learns more, he'll share. Okay. [28:00] Thanks for uh not helping here. [28:02] Appreciate you Mitchell for being [28:04] honest. Yeah, the shift has happened. We [28:07] have to accept that building blocks and [28:08] software factories rule everything [28:10] around us and accept and internalize the [28:11] consequences of it. We can choose to run [28:13] the other direction and create enclaves [28:14] where we fight against it or we can [28:16] choose to submit ourselves completely to [28:17] the chaos. People who know him know he's [28:19] far less extreme in his actions and [28:20] carries different opinions depending on [28:21] the context. His point is simply that [28:23] the shift has happened and I couldn't [28:24] agree more. Since Mitchell didn't go on [28:26] the commercial side, I will talk a bit [28:28] from my experience as well as the [28:30] experience I have with other companies [28:31] in the space and what has been working [28:32] for them. The biggest thing you have to [28:34] think about is stickiness. What makes [28:36] your solution the one that people like? [28:39] Historically, this has been that you [28:40] include specific features that users get [28:42] addicted to and can't leave. But more [28:45] and more that isn't going to be the case [28:47] because people will just go build their [28:49] own bespoke solution. I was upset enough [28:51] with Frame.io that I built my own [28:52] alternative. And the hardest part wasn't [28:54] building it. The hardest part was [28:55] getting everything set up so I could [28:57] ship it with a pricing tier and sell it [28:59] to people so others could use it too. If [29:01] I just wanted to run this internally, I [29:03] could have and I would have been done 2x [29:04] faster at least. And now Lawn is being [29:07] forked by many people to use for their [29:10] own businesses and I get no money when [29:11] they do that right now because they [29:13] wanted to use Lawn their specific way [29:15] for their content business. This is [29:17] people like Snazzy Labs and Jaca aka [29:19] Jake who used to be at LT. They're [29:21] forking this to use it internally for [29:23] their video review pipelines and they [29:24] were loving it. I think that's awesome. [29:26] But figuring out how to commercialize [29:27] that is the challenge. I gave them a set [29:30] of building blocks that let them solve [29:32] the problem that they have, but it was [29:34] missing pieces. They had to figure out [29:35] how to store the files. They had to [29:36] figure out how to set up O. They had to [29:38] figure out if they wanted to add [29:39] payments, how to do that. How to manage [29:40] the database, how to manage the state, [29:42] all these things. And none of them [29:43] coded. So they just had to do this with [29:44] agents. And they succeeded. But it took [29:47] a while. What would it look like to [29:48] build something like lawn where you can [29:51] pay us for the server and backend side [29:53] and getting all of the video info, [29:55] right? But the actual layer that you [29:56] engage with and use is owned fully by [29:59] you if you want and is trivial for you [30:01] to extend. What if when we set up lawn [30:04] for you as a customer, it goes to its [30:06] own custom domain or subdomain and then [30:08] the build that you're running is a fork [30:11] of the real original project and then [30:13] when you want to add things or change [30:14] things, you just tell it to. What does [30:17] it look like for forking software to be [30:19] part of the software? Personally, I [30:22] think it looks very very sticky. If you [30:24] try out my solution and you like it, but [30:26] it's missing something you want, you [30:28] could go fork if it's open source or if [30:30] it's open source and built into the [30:32] product to do such, you can fork it in [30:34] app. Or if you don't want to deal with [30:36] the infra side, but you like having the [30:38] codebase hosted your way, you could [30:39] fork, host it how you want, and then use [30:42] our backend to power it so you keep [30:44] paying us. There are definitely ways to [30:46] do this without the software being truly [30:48] open, but I don't know how well and [30:50] reliably they will work, and I think it [30:53] would be way too easy to get the source [30:55] out, and it's better to not deal with [30:57] that in the first place. I got one more [30:59] idea that I've been holding tight to my [31:01] chest that I was planning on not showing [31:03] to the world until I had a working [31:04] version. I think I'm going to give it [31:06] away now. I'm going to regret this. I [31:08] already regret that I've even said I [31:10] have something like this on my mind, but [31:11] at this point I'm too busy to do it [31:12] myself and I want to get the idea out [31:14] there, but sharing this early might cost [31:17] me a lot of money. So, we're going to do [31:18] a real quick break for an ad first. [31:20] Today's sponsor is G2I and they're [31:21] paying me to tell you about how good [31:22] they are at hiring. And they really are [31:24] good at it. That's why they're able to [31:25] help Bataround go from a 50% success [31:27] rate with new hires to 90% plus while [31:29] also speeding up the process. That's [31:31] what they want me to talk about, but I'm [31:32] just going to ignore that because they [31:34] do something that's even cooler. Hey, so [31:35] uh sorry guys, Discount Theo here. He [31:37] kind of forgot the most important part [31:39] of the ad, which is the fact that both [31:40] AI Engineer and React Miami are [31:42] happening next week. React Miami, you [31:44] all probably have heard of it. It's the [31:45] best dev conference of the year. But [31:47] this year, they are doing just 3 days [31:48] before AI engineer starting on April [31:51] 20th, which is going to be an incredible [31:52] conference. A ton of really, really cool [31:54] people in the AI space are going to be [31:55] there. It's actually the first [31:56] conference I've ever gi. If you just go [31:59] to their website and take a look at the [32:00] speakers list, it is a very stacked [32:01] roster and I am very, very excited for [32:03] that whole week. If you haven't gotten [32:04] tickets yet, you really, really should. [32:06] You can go to soyv.link/miami. [32:08] Use promo code theo50 off and just go to [32:11] both conferences. Just trust me, they [32:13] are worth going to. If you don't go, you [32:14] will regret it. Do it now. The tickets [32:16] are running out fast. Just go. Sorry for [32:18] the adbreak. Wanted to filter out the [32:20] people who aren't dedicated. This is [32:21] your reward for watching through to the [32:23] end of this video. We all already know [32:25] about the Claude MD, the agent MD. You [32:27] all might even know about the Soul MD. [32:29] I've been thinking about these a lot. In [32:31] particular, the Soul MD. The idea of a [32:34] piece of software that was designed to [32:36] have its behavior, characteristics, and [32:38] way of usage defined as a text file that [32:41] could be edited in plain English by a [32:43] normal person. My proposal, and I do [32:46] actually hope this becomes a standardish [32:48] thing, the patch MD. Hear me out. I [32:52] talked in my previous open source video [32:54] about how much Yasha's way of building [32:57] broke my brain. Seeing him treat every [33:00] package in our project as just [33:02] additional code that he could edit [33:03] however he wanted and then use patch [33:05] package to apply his changes so that we [33:08] could adjust the package to our needs [33:10] for our use case. There are issues with [33:12] this though. If the package gets an [33:14] update and the location of the code we [33:16] want changes or something shifts, you [33:18] got to rewrite the patch. So what does [33:20] it look like to fix that? Let's say we [33:24] added a feature in T3 code where we had [33:26] a button in the corner that was [33:27] customize and when you click it, it [33:29] would run a forked T3 code as a separate [33:31] like T3 code custom on your machine and [33:34] you could make changes to the source and [33:35] it would just be in a a pseudo dev mode [33:37] and you see the new UI as the changes [33:40] happen. Then Julius ships another [33:42] 100,000 lines of code and 500 commits [33:44] and all your shit's broken. You could [33:46] have an agent try to resolve the merge [33:49] conflict, sure, but what happens when [33:51] they fail? What if every time you made a [33:54] customization, it didn't just change it [33:56] in one place, it changed it in two. [33:58] Obviously, it will edit the code to do [34:00] the thing you want, but it will also [34:02] encode the intent of the change you made [34:04] in a patch MD file. The patchm simply [34:07] describes all of the features you have [34:09] added to the app. And then in the [34:11] future, an update isn't just downloading [34:13] the new binary and hoping for the best. [34:16] The future is you pull down the changes [34:18] from main. If it applies clean, awesome. [34:20] Go straight to it. If it doesn't, you [34:22] can hit a button that says run update [34:24] with agent and it will try to resolve [34:27] the merge conflicts. And if it fails or [34:29] has any issues, we'll tell you, hey, we [34:32] weren't able to resolve this cleanly. If [34:34] you want, we will run another instance [34:36] in the background and reapply these [34:39] features that you've added in the past. [34:41] Then you can check and make sure they [34:42] work how you want, and we'll migrate you [34:44] when that's done. What if the update [34:45] button was no longer an update button? [34:48] What if the update button was a process [34:50] that would clone the latest code, see [34:52] which changes cleanly apply and which [34:54] ones don't, and then lets the agent [34:56] guide you through getting the new [34:58] version where you want it to be with [35:01] your specific stuff added. And what if [35:03] in thet directory you had this file that [35:06] described everything you wanted T3 code [35:08] to be? What does a future look like [35:09] where all software is self-forking, [35:13] self-customizing, and self-healing when [35:15] merge conflicts happen? Since I thought [35:17] about this, I haven't been able to stop [35:19] and I am way too goddamn busy to build [35:21] it myself. This is on the road map for [35:23] things we want to add to T3 code and [35:25] there's a lot of little pieces we have [35:26] to get right for this to work. But I [35:28] wanted to coin the term patchm because I [35:31] firmly believe this is the path to allow [35:34] normal people to edit their software to [35:36] their liking and to allow for businesses [35:39] to keep iterating without breaking all [35:41] the weird forks that all of their users [35:43] are on. What does the future look like [35:44] if 90% of your users forked? How do we [35:48] resolve this? How do we make sure that [35:50] these users can have what they want but [35:53] not fall so far behind that they're in a [35:55] really insecure, poorly supported, [35:57] terribly integrated place. There's [35:59] obviously a lot of things that can go [36:01] wrong here. This is a very different way [36:02] of thinking about software than we have [36:04] historically, but so was the Unix [36:06] philosophy back in the day. I'm very [36:08] excited for a future where I can fork [36:09] the app I'm using within the app itself [36:11] and not have to build my own universe [36:13] from scratch in order to get what I [36:15] want. And at the absolute least, it [36:17] means I would feel much less bad closing [36:19] the 314 poll requests we have on T3 Code [36:21] right now. God [ __ ] damn it. [36:25] For most of you, this proposal probably [36:27] gives you more questions than answers, [36:29] and I have the same ones. This is a [36:31] thing I've been thinking a lot about, [36:32] and I spent no time actually doing, and [36:34] I got tired of waiting to share a [36:35] working version. So, I wanted to put [36:37] this out so that you guys can think [36:38] about it, too. Similar to how I've put [36:40] out ideas like an app that has an [36:42] infinite canvas in each direction for [36:44] the work that you're doing, so you can [36:46] create dimensions to the parallel nature [36:48] of building with agents. I won't be able [36:49] to be able to customize without having [36:51] to do everything else first. And I hope [36:54] that this idea sticks for some of y'all [36:56] and that I get to see some fun examples [36:58] in my replies in the future. We still [36:59] live in a world where the biggest [37:00] companies have shitloads of engineers [37:02] maintaining hundreds if not thousands of [37:04] features that are used by very small [37:06] portions of their customer base. This is [37:08] the direction things are going and I am [37:10] trying for the first time in a long time [37:12] to predict where we'll be in a year [37:14] instead of a few months. But honestly, [37:16] I'm starting to think this might only [37:17] take 3 to 4 months. And of course, [37:18] people are calling it out very much [37:20] thinking about PI here, too. the idea of [37:23] a minimal reliable agent that you [37:25] customize to your liking, not just by [37:28] adding skills or plugins, but by [37:30] modifying it for your needs. Software [37:32] malleability didn't matter when the [37:34] average user couldn't change it. Now [37:36] that the average person can prompt their [37:38] features into existence, the platforms [37:40] that allow that are going to be the [37:41] winners. And this is just one way to get [37:43] there. So to wrap up my argument here, [37:45] why open source your business? Customers [37:47] will do research for you. You don't have [37:49] to support 1% features. Asians like OSS [37:51] tools more and my personal favorite [37:53] thing, the community that forms around [37:55] it. It has been beyond heartwarming [37:57] seeing all of the awesome stuff [37:59] happening with T3 code. The hundreds of [38:01] forks that keep appearing in my replies [38:03] on Twitter, the insane [ __ ] people are [38:05] doing with the app. Even people like [38:06] Maria stuffing it in the terminal with [38:08] T1 code. That only happens when you're [38:10] building in an open way. And all of [38:13] these pieces feed into each other. The [38:15] more community you have, the more the [38:16] agents will like it. The more the agents [38:18] like it, the more customers you'll get. [38:20] The more customers research for you, the [38:22] more features you can integrate or not [38:23] integrate. All of these pieces feed into [38:26] each other. And you have an incredible [38:27] opportunity to take an existing product, [38:30] find the core pieces that make it [38:32] valuable, rebuild those core features in [38:34] a customizable, extendable, open way, [38:37] and then watch what the world does with [38:38] it. And I really [ __ ] hope I'm right [38:40] here because I've put a lot of my own [38:42] money and time on the line. This is not [38:44] my usual, well, this looks good type [38:46] recommendation. This is the one I'm [38:48] building my portfolio around. If I'm [38:50] wrong on this, my kids don't get college [38:52] money. But if I'm right about this, my [38:54] kids will own colleges. So, I really [38:56] [ __ ] hope I'm right. But in order for [38:58] this to be the future, in order for the [39:00] future to be more open instead of more [39:02] closed because of all the fear about [39:03] forking and AI hacking and all that [39:06] [ __ ] I need each and every one of you [39:08] to come in with me. We need to show the [39:10] world that open is the right way to do [39:12] this. And I know we can. You've already [39:14] shown me. If you can convince me through [39:16] what you've done to T3 code, we can [39:17] convince the world alongside us. Go [39:19] build the open version of the thing that [39:21] you hate at work. Make the pieces you [39:23] need to survive and then see who else [39:25] will use it based on those parts. The [39:27] future is open if we make it that way. [39:29] And I need y'all to help me do it. Thank [39:31] you as always for listening. I know this [39:32] was a long one, but it's a topic that's [39:34] very important for me, and I hope you [39:35] can see why now. Let me know how y'all [39:37] feel and keep building awesome [ __ ] and [39:39] ideally do it in the open. And until [39:41] next time, peace nerds.  📄 **Full text:** ![[Full Document Contents/Articles/A Letter to Tech CEOs.md|A Letter to Tech CEOs by YouTube]] ## Highlights - 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 ([View Highlight](https://read.readwise.io/read/01krgqkv3twz343k9escw6qywv)) - Tags: 👻 ai highlighted - 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 [ __ ] ([View Highlight](https://read.readwise.io/read/01krgqkv59az603s16h0wg29ne)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01krgqkv72mjc15yvfm473yz9b)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01krgqkvc1nq8xnpjav45nvdvh)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01krgqkvmwfth838k5bn4wh1y7)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01krgqkw1d1ph96mdbgngafs3z)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01krgqkwb481s59v1yyxm1jw5s)) - Tags: 👻 ai highlighted - 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, ([View Highlight](https://read.readwise.io/read/01krgqkwkz0j97frxdq4p6try7)) - Tags: 👻 ai highlighted