Open Source Is Dying - CourtneyR.dev's 2nd Brain

Open Source Is Dying ![rw-book-cover](https://img.youtube.com/vi/l8pQeVVaqpY/maxresdefault.jpg) 🔗 **Source:** [Open Source Is Dying](https://www.youtube.com/watch?v=l8pQeVVaqpY) > [!note]+ Document Notes > tags: #open-source #artificial-intelligence #developer-community #software-maintenance #github #funding > author: Theo - t3․gg > source: YouTube > reference: https://www.youtube.com/watch?v=l8pQeVVaqpY > date created: 2024-12-28 14:30 > > # 🏷️ Title: Open source is dying >  ## 🧰 Action Inbox - [H1] Implement PR spam protection using tools like Vouch — address overwhelming contributor volume #open-source - [H2] Support open source pledge at company level — commit $2000/dev/year funding #funding - [H3] Thank maintainers genuinely for their work — improve community relationships #community ## 🧭 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](https://github.com/t3-oss/t3-code) - [Open Source Pledge](https://opensourcepledge.com/) - [Vouch by HashiCorp](https://github.com/hashicorp/vouch) ## 📝 Summary - AI is creating unprecedented challenges for open source maintainers through PR spam, low-quality contributions, and entitled users - Projects are overwhelmed with AI-generated pull requests that maintainers cannot reasonably review - Funding models are breaking down as AI reduces demand for paid courses and premium tools - Maintainer burnout is increasing due to higher volume of low-quality interactions - Solutions include better tooling (Vouch), funding commitments (Open Source Pledge), and community appreciation ## 📖 Main Content The open source ecosystem faces an existential crisis as AI fundamentally changes how people interact with code repositories. Three major problems have emerged: **PR Spam Crisis**: Projects receive overwhelming volumes of AI-generated pull requests. T3 Code received 150 PRs in 5 days despite explicitly stating they weren't accepting contributions. Projects like TailDraw now automatically close external PRs due to unmanageable volume. **Quality Degradation**: AI enables non-developers to contribute code they don't understand, creating maintenance nightmares. The "10% fork-to-star ratio" shows unprecedented numbers of people wanting to modify projects without proper understanding. **Economic Disruption**: Traditional open source monetization through courses, workshops, and premium tools is failing as AI can replicate their value. Maintainers lose income while facing increased workload. The XZ backdoor incident demonstrates how burnout-driven social engineering attacks exploit maintainer exhaustion. GitHub's inadequate moderation tools compound the problem, forcing maintainers to build their own solutions. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/l8pQeVVaqpY?t=0) — [H1] Open source under AI threat - Key idea: AI is negatively impacting open source through spam and quality issues - Evidence: "We're finally at the point where AI is having a real impact on open source. And if I'm being frank, it's not very good." #### ⏱️ [02:15](https://youtu.be/l8pQeVVaqpY?t=135) — [H2] TailDraw closes external contributions - Key idea: Major projects abandoning community contributions due to AI spam - Evidence: "Tail Draw's announcement that they're automatically closing PRs from external contributors going forward" #### ⏱️ [05:23](https://youtu.be/l8pQeVVaqpY?t=323) — [H1] T3 Code overwhelmed with PRs - Key idea: New projects face unprecedented contribution volume - Evidence: "The T3 codebase, which has been public for about 5 days now, has 150 open PRs" #### ⏱️ [08:45](https://youtu.be/l8pQeVVaqpY?t=525) — [H2] System understanding degradation - Key idea: AI contributions reduce codebase comprehension for maintainers - Evidence: "When you build it with AI, you might understand how the parts come together, but your grasp over the whole system is inherently going to go down" #### ⏱️ [12:30](https://youtu.be/l8pQeVVaqpY?t=750) — [H3] Unprecedented fork-to-star ratio - Key idea: AI enables more people to attempt modifications - Evidence: "A greater than 10% forktoar ratio. For every 10 users that hit star, more than one clicked fork" #### ⏱️ [16:20](https://youtu.be/l8pQeVVaqpY?t=980) — [H2] User quality degradation - Key idea: AI enables non-developers to contribute without understanding - Evidence: "I remember Theo saying something along the lines of React is dead... This is a hallucination that can only occur due to a specific type of brain rot" #### ⏱️ [22:40](https://youtu.be/l8pQeVVaqpY?t=1360) — [H1] XZ backdoor social engineering - Key idea: Burnout makes maintainers vulnerable to malicious takeovers - Evidence: "Those accounts that were spamming the original maintainer were not just bad faith open-source contributors. These were fake accounts" #### ⏱️ [26:15](https://youtu.be/l8pQeVVaqpY?t=1575) — [H2] GitHub's inadequate moderation - Key idea: Platform provides insufficient tools for community management - Evidence: "GitHub does jack [ __ ] [ __ ] to solve this problem... They didn't even have a way to ban a contributor from your repo" #### ⏱️ [32:10](https://youtu.be/l8pQeVVaqpY?t=1930) — [H1] Vouch as spam solution - Key idea: Trust-based systems can filter quality contributions - Evidence: "We went from 150 to 43... this is like actually viable" #### ⏱️ [38:25](https://youtu.be/l8pQeVVaqpY?t=2305) — [H1] Economic impact on maintainers - Key idea: AI disrupts traditional open source monetization - Evidence: "The likelihood I pay for it is near zero because I'm already paying 200 a month for Quad, which I can tell it to go build the thing" #### ⏱️ [42:50](https://youtu.be/l8pQeVVaqpY?t=2570) — [H1] Open Source Pledge solution - Key idea: Companies should commit minimum funding per developer - Evidence: "$2,000 per year per devbit your company to open source maintainers" #### ⏱️ [48:15](https://youtu.be/l8pQeVVaqpY?t=2895) — [H2] Community appreciation importance - Key idea: Genuine gratitude helps prevent maintainer burnout - Evidence: "Those messages still feel awesome. Those messages make my goddamn day" ## 📚 References - [T3 Code Repository](https://github.com/t3-oss/t3-code) - [Open Source Pledge](https://opensourcepledge.com/) - [Vouch by HashiCorp](https://github.com/hashicorp/vouch) - [PR Stats Tool](https://github.com/reeseschultz/pr-stats) - [XZ Backdoor Analysis](https://en.wikipedia.org/wiki/XZ_Utils_backdoor) ## 🗣️ Paraphrase - AI-generated contributions are overwhelming open source maintainers with volume they cannot reasonably review while reducing code quality - Traditional funding models for open source are breaking as AI tools replace paid courses and premium offerings that maintainers relied on - Community dynamics are degrading as non-technical users enabled by AI create toxic interactions and unrealistic expectations ## 📰 Newsletter **Open Source Under Pressure: AI's Double-Edged Impact** The WordPress community should pay attention to broader open source challenges emerging from AI adoption. Projects are facing unprecedented volumes of AI-generated contributions that overwhelm maintainer capacity while potentially degrading code quality. Key concerns for WordPress contributors: - **Quality Control**: Implement review processes that ensure AI-assisted contributions maintain project standards - **Community Health**: Foster genuine understanding over quick AI-generated fixes - **Sustainable Funding**: Support open source dependencies through initiatives like the Open Source Pledge **Action Steps**: - Review your company's open source dependencies and consider funding commitments - When contributing, focus on understanding systems rather than just submitting AI-generated code - Thank maintainers genuinely for their work This affects WordPress's ecosystem since many plugins and themes depend on broader open source libraries facing these pressures. Resources: [WordPress Contributor Handbook](https://make.wordpress.org/core/handbook/), [Open Source Pledge](https://opensourcepledge.com/), [GitHub Community Guidelines](https://docs.github.com/en/site-policy/github-terms/github-community-guidelines) ## ✅ Action Items #### DevRel - Developer education: Create workshops on responsible AI-assisted contribution practices, quality review processes - Community management: Implement trust-based systems like Vouch for managing contribution quality at scale - Developer experience: Advocate for better platform moderation tools and spam detection systems #### OSPO - Funding strategy: Evaluate Open Source Pledge adoption, establish $2000/dev/year minimum for dependencies - Security management: Monitor for social engineering attacks targeting burnt-out maintainers - Community engagement: Support maintainer mental health through appreciation programs and workload management #### Community - Contributors: Focus on system understanding over AI output, provide meaningful context in contributions - Maintainers: Implement filtering systems, establish clear contribution guidelines, prioritize mental health - Ecosystem: Cross-project coordination on anti-spam measures and quality standards #### WordPress - Core: Evaluate contribution review processes for AI-generated code, maintain quality standards - Community: Develop guidelines for AI-assisted contributions, support maintainer appreciation initiatives - Plugins: Establish review criteria for AI-generated submissions, support dependency funding ## 🧪 Hypotheses - Trust-based filtering systems like Vouch can reduce PR review burden by 60-70% while maintaining contribution quality - Companies implementing Open Source Pledge see improved developer satisfaction and reduced dependency risks - Maintainer appreciation programs correlate with longer project sustainability and lower burnout rates - AI contribution quality improves when contributors are required to demonstrate system understanding ### 📊 Methodology - A/B testing of Vouch implementation across similar-sized repositories measuring review time and merge rates - Survey analysis of Open Source Pledge companies measuring developer sentiment and security incident rates - Longitudinal study of maintainer retention rates with and without community appreciation programs ### ❓ Questions - How can platforms better detect AI-generated contributions without stifling legitimate automation? - What funding models will replace traditional open source monetization disrupted by AI? - How do we balance accessibility for new contributors with quality control needs? ### 🔮 Future Research - Development of automated PR quality scoring systems that consider contributor history and code understanding - Economic modeling of sustainable open source funding in the AI era - Social dynamics research on maintaining healthy communities amid AI-enabled participation ### 💡 Implications - Practice: Implement contribution filtering and maintainer support systems immediately - Policy: Establish organizational commitments to open source funding and quality standards - Security: Monitor for social engineering attacks exploiting maintainer burnout - Education: Train developers on responsible AI-assisted contribution practices - Funding: Allocate budget for open source dependencies through structured pledge programs ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12 (technical content with accessible explanations) #### 👀 Visual learners - Present: GitHub interface screenshots, PR statistics, repository metrics - Improve: Workflow diagrams showing contribution filtering, funding flow visualizations #### 🔊 Aural learners - Present: Original video format with clear narration and examples - Improve: Audio summaries of key actionable insights for maintainers #### 🗣️ Verbal learners - Present: Clear definitions of PR spam, system understanding, social engineering - Improve: Analogies comparing open source maintenance to other community management #### 🧩 Kinesthetic learners - Present: Step-by-step Vouch setup, actionable GitHub configurations - Improve: Interactive workshops on contribution review processes, hands-on filtering tools #### 🧠 Logical learners - Present: Statistical evidence (10% fork ratio, 150 PRs in 5 days), cause-effect relationships - Improve: Decision trees for contribution evaluation, ROI calculations for funding commitments #### 🧑‍🤝‍🧑 Social learners - Present: Community examples, maintainer experiences, collaboration challenges - Improve: Discussion forums for sharing filtering strategies, peer support networks #### 🧘‍♀️ Solitary learners - Present: Individual reflection on contribution practices, self-assessment questions - Improve: Personal checklists for quality contributions, individual learning paths #### 🌿 Naturalistic learners - Present: Ecosystem thinking about open source sustainability, natural community cycles - Improve: Environmental analogies for community health, lifecycle models ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings structure, meaningful link text, video transcript provided - Improve: Add ARIA labels for interactive GitHub elements, describe visual charts #### Keyboard navigation - Present: Standard video controls, accessible transcript navigation - Improve: Skip links for transcript sections, keyboard shortcuts for timestamp navigation #### Contrast and readability - Present: High contrast text, readable font sizes in screenshots - Improve: Ensure GitHub UI screenshots meet contrast requirements, provide text alternatives #### Text resizing and reflow - Present: Responsive transcript layout, scalable text - Improve: Test transcript readability at 200% zoom, ensure no content clipping #### Media and captions - Present: Full transcript available for 52-minute video - Improve: Add closed captions with speaker identification, provide audio descriptions #### Forms and interactions - Present: Clear action items with context - Improve: Make interactive examples keyboard accessible, provide form validation ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global perspective on open source challenges, diverse project examples - Improve: Include non-Western open source communities, multilingual contribution examples #### Inclusive language - Present: Avoids technical elitism, explains jargon clearly - Improve: More inclusive examples of contributor backgrounds, avoid assumption of prior GitHub experience #### Neurodiversity support - Present: Clear section breaks, consistent formatting, multiple learning modalities - Improve: Content warnings for frustration/burnout discussions, provide summary bullets #### Representation - Present: Examples from various project types and maintainer experiences - Improve: Include perspectives from underrepresented maintainer communities, diverse contribution styles #### Psychological safety - Present: Acknowledges maintainer stress, promotes respectful community interaction - Improve: Explicit guidelines for supportive feedback, resources for burnout management ### ✅ Logical Validity #### Strong reasoning - Deductive strength: If AI increases low-quality contributions and maintainer burden increases, then burnout rises (confirmed by examples) - Inductive strength: Pattern recognition from multiple projects (T3 Code, TailDraw, Node.js) supports broader trend - Causal reasoning: Clear links between AI adoption → contribution volume → maintainer stress → project abandonment - Analogical strength: XZ backdoor case demonstrates vulnerability exploitation through burnout #### Fallacies - Hasty generalization: Extrapolating from personal T3 Code experience to all open source projects - limited sample size, newer projects may have different dynamics - Appeal to emotion: Heavy use of frustration and fear appeals - valid concerns but could bias rational decision-making #### Tone of voice - Overall tone: Urgent and passionate with technical authority, using personal anecdotes and strong language to emphasize severity while maintaining credibility through specific examples ### 🛡️ DARVO Analysis - Deny: No significant denial patterns; acknowledges complexity of issues - Attack: Criticizes GitHub and AI tools but focuses on systemic problems rather than personal attacks - Reverse victim/offender: No evidence of victim/offender reversal - Emotional cues and rhetoric: Uses urgency and passion effectively to motivate action rather --- ## Full Transcript [00:00] Open source is incredibly important to [00:01] me. I can say confidently I would not be [00:03] here today if it wasn't for open- source [00:05] software. It's a huge part of how I [00:07] started my career, got into YouTube, and [00:09] made all of this happen. Life without [00:11] open source is genuinely hard for me to [00:13] imagine, which is why I'm really scared [00:15] right now. We're finally at the point [00:16] where AI is having a real impact on open [00:18] source. And if I'm being frank, it's not [00:20] very good. And no, I'm not just talking [00:22] about the people on Reddit who are mad [00:24] because GitHub isn't for them and they [00:26] can't find the download button. As funny [00:27] as these posts are, I'm talking more [00:29] about stuff like this Tail Draw's [00:31] announcement that they're automatically [00:32] closing PRs from external contributors [00:34] going forward. Increased requirements [00:36] for reporting bugs in projects like [00:38] Node.js where you can't just flag it [00:39] anymore cuz they're getting so much AI [00:41] spam. Or even the Tailwind drama I [00:42] covered earlier this year that has been [00:44] massively impacting their ability to [00:45] fund the team and project. This isn't [00:47] good. If things keep going in this [00:49] direction, not only will it destroy open [00:51] source, it might destroy software as a [00:54] whole. Having these core pieces we can [00:56] all rely on together as an industry is [00:59] essential for our success building [01:00] software. And it does not matter how [01:02] good AI is. If it takes this from us, we [01:05] are doomed. And that means we ought to [01:07] fight a little bit. It's more important [01:08] now than ever that we as experienced [01:11] developers put our foot down and do [01:13] everything we can to prevent this spiral [01:15] from killing open source. There's a lot [01:17] of different problems in open source [01:18] right now, and one of the biggest is [01:20] funding. Thankfully, sponsors have [01:22] helped a lot, just like today's sponsor. [01:24] Y'all might have seen a new project I [01:25] recently launched, T3 Code. It's the [01:27] best way to code with AI. But we have a [01:29] couple problems. Specifically, this [01:31] number. The number of pull requests [01:33] we're getting is insane. And the amount [01:35] of CI we'd have to run and wait for [01:37] there would be even more insane. If we [01:39] turn it on by default for all users, we [01:41] have a huge potential security risk. But [01:43] if we leave it off by default and go [01:45] click the button when we want to run an [01:46] action, we're going to be stuck there [01:47] waiting forever before we even know if [01:49] the code works. Well, that was the case [01:51] before we started using today's sponsor, [01:53] Blacksmith. The best way to run your [01:55] GitHub actions. You make a oneline [01:57] change, and yes, it is literally a [01:58] oneline change, and now your actions are [02:00] twice as fast and cost half as much. [02:03] Yes, that does add up to a 75% savings [02:05] in most cases. Don't believe me? You can [02:07] go look at the PR yourself. This PR that [02:09] I didn't even file, I literally just [02:11] clicked the onboard button in the [02:13] Blacksmith dashboard and it filed this [02:15] PR for me. I thought it might be more [02:16] complex because this codebase is [02:18] building Electron across different [02:19] things and whatnot. Nope. Literally just [02:21] changed from Abuntu latest to Blacksmith [02:23] for CPU. That was it. Everything worked. [02:26] Not only did everything work, it worked [02:28] way faster. Our CI times for this app [02:30] got cut in over half from about 2 and [02:32] 1/2 minutes to under a minute [02:34] consistently. What's even better is [02:35] their dashboard, though. We had a couple [02:37] tests that were a little bit flaky. And [02:39] the dashboard has made it so easy to [02:41] figure out which tests are failing, [02:42] which ones are succeeding, and why. [02:44] Seriously though, how cool is this? [02:45] Having actual metrics of what things are [02:48] succeeding and failing and being able to [02:49] see like, oh, we had a huge spike in [02:52] failures at this time yesterday. So [02:54] useful to figure out what's going right [02:56] and wrong in your work. And I can click [02:58] here and see over time where the [03:00] failures and successes were happening. [03:02] And I could even go through and monitor, [03:03] look at specific events. It is suddenly [03:05] so much easier to figure out what's [03:07] going wrong when things are failing. [03:09] Stop wasting your time and money and [03:11] sign up today at soy.link/blacksmith. [03:13] There's a couple different angles I want [03:14] to take this one down. Specifically, [03:16] we're going to start with the PR spam [03:17] and slot problem. But then there's the [03:19] dumber, angrier users problem, install [03:22] versus prompt, and biggest probably is [03:24] the funding problems. First, we're going [03:26] to start with the PR spam problem. I've [03:28] been pretty aware of this for a while, [03:29] and I have a lot of sympathy for people [03:31] like TL Draw that put out this change [03:33] where they're just going to start [03:34] closing any external contributions [03:36] because they're just getting flooded [03:38] with them. And I knew how bad this was [03:40] and it helped other maintainers dealing [03:42] with it in the past. But this problem is [03:44] much closer to my heart now because [03:46] we're going through it ourselves. The T3 [03:48] codebase, which has been public for [03:50] about 5 days now, has 150 open PRs. Mind [03:55] you, we specified that we're not [03:57] accepting contributions and we still got [03:59] 100 PRs a day for the first two days. I [04:01] eventually added this cuz I was tired of [04:03] saying the same things over and over [04:04] again in all of the PRs. We're not [04:07] actively accepting PRs. You can still [04:08] open issue PR, but please do so knowing [04:09] there's a high chance we close it, defer [04:10] it forever, and never look at it. If [04:12] that sounds annoying, it's because it [04:13] is. Project's still very early. We're [04:14] trying to keep scope, quality, and [04:15] direction under control. Yeah, there's a [04:17] very real problem with software [04:19] development around what I don't really [04:21] know how to explain other than [04:22] understanding of the system. When you [04:24] build a project yourself, you understand [04:26] the whole system. When you build it with [04:28] AI, you might understand how the parts [04:30] come together, but your grasp over the [04:32] whole system is inherently going to go [04:34] down the more and more you defer to the [04:35] AI to do things. When you start [04:37] accepting PRs, similar stuff happens. [04:40] When you start accepting a lot of PRs [04:41] from external sources, it gets worse. [04:44] And then when those are built with AI, [04:45] it just the the slop expands [04:49] aggressively. If you understand 100% of [04:51] your codebase and then you merge a [04:52] change that you don't understand 5% of [04:54] and then that happens again and again [04:56] and again, you very quickly end up in a [04:59] position where you don't actually [05:00] understand very much of the codebase at [05:02] all. And it becomes way harder to [05:04] maintain control as that happens. [05:07] Previously, the only way you'd get in [05:08] this position is by accepting too many [05:10] PRs. Now, you can do it yourself by [05:12] coding with agents. And you can do it [05:14] exponentially worse by coding with [05:15] agents and merging PRs from other people [05:17] with agents. And that's assuming you can [05:19] get through them all because there's 150 [05:22] PRs. It's kind of intense. Like, this is [05:24] a lot to deal with. One of the things [05:26] we're trying out is vouch. We'll [05:27] definitely talk about that when we get [05:29] more to solutions, but I really wanted [05:31] to emphasize how bad this is right now. [05:34] There is no world in which we can give a [05:35] proper review to every single PR we are [05:38] getting at this rate with just Julius [05:39] and me doing all of these reviews. At [05:41] the same time though, we have 33 [05:43] contributors already on a project that's [05:45] been out for 5 days. So, that is really [05:48] cool. The fact that people can get into [05:49] a codebase like this so quickly is a [05:51] benefit. And I don't want to discount [05:53] how powerful that is because it is [05:55] really cool. But that required a lot of [05:57] work on our behalfs. Personally, I spent [05:59] most of Saturday and literally all of my [06:01] Sunday just sitting going through PRs, [06:04] testing things, shipping new releases, [06:06] just dealing with that. And I'm somebody [06:09] who likes doing those types of things. [06:11] And it was still draining for me. I [06:12] basically couldn't do anything Monday [06:14] cuz I was so tired from the whole [06:15] weekend of triaging, managing PRs, going [06:18] through issues. I had to bring two [06:19] people on just to help keep track of the [06:21] PRs and issues. It's insane. It's so [06:23] much more work than I would have [06:25] imagined. And I already was imagining it [06:26] to be a lot of work. Like just admire [06:29] this ratio here cuz this is something [06:31] that never would have happened before. A [06:33] greater than 10% forktoar ratio. For [06:36] every 10 users that hit star, more than [06:39] one clicked fork. That's insane. That is [06:41] an absurd number of people who want to [06:44] make changes to the project and [06:45] contribute and be involved. That is [06:47] unlike anything I've seen before in open [06:49] source. I was expecting React's ratio [06:51] here to be worse than ours. It's [06:53] actually crazier. So, might have to [06:56] rethink that take a bit. Yeah, it looks [06:58] like that 10% ratio is actually pretty [07:00] consistent. This is TypeScript at around [07:02] the same 10%. So, we'll leave that in [07:04] cuz I like when you guys see when I have [07:06] bad intuition sometimes. That was a bad [07:09] intuition on my part. I can't imagine [07:11] many projects get there as quickly as we [07:12] did with that brutal ratio. But still, [07:15] yeah, it is what it is. And if only PRs [07:17] were the biggest issue we had with this [07:19] type of open-source stuff nowadays. [07:21] Sadly, there's another bigger problem, [07:23] and it kind of touches on this classic [07:26] post on Reddit, the I don't give an f [07:28] about the effing code. I just want to [07:29] download the stupid effing application. [07:31] Why is there code? Just make an .exe and [07:33] give it to me. This post getting 10K up [07:35] votes and blowing up the way it did. [07:38] Signifies just how much things have [07:41] changed. I'm sure a lot of y'all can [07:43] sympathize with the things I'm about to [07:45] talk about here. Most of us are pretty [07:47] technical people. We just like [07:49] computers. That's why you're watching a [07:50] video about open- source and AI on [07:53] whatever day you're choosing to watch [07:54] this on. You might even be staying up [07:56] late at night just to watch this video. [07:58] We are not your average person. We're [08:00] probably not even your average [08:01] developer. This community is full of [08:03] people who, to be frank, are kind of [08:05] [ __ ] nerds. And that's awesome. I [08:07] love that about us. I love the fact that [08:08] we have this crew of nerds that come to [08:10] hang out that should be asleep right now [08:12] but are live watching me as I record and [08:15] just helping me make awesome content [08:17] about things we all are nerdy about and [08:19] care about. I bring this up because [08:21] there's a couple things that we just [08:22] experience in life differently because [08:24] of that. The one I'm imagining right [08:26] now, and I'm sure a lot of y'all are [08:28] this one's in chat if you can relate. I [08:30] used to get a lot of texts from family [08:32] members, random friends in high school [08:34] and just people in my life asking random [08:37] [ __ ] about computers. Anything from, [08:40] "Can you help me get my Instagram [08:41] account back?" to, "What MacBook should [08:43] I buy?" to, "Why is my camera foggy?" [08:46] Every vague tech question anyone in your [08:48] life had, you're the person who gets it [08:51] because you're the person that they know [08:52] that understands tech. And since you [08:54] have successfully written a line of code [08:56] before, or maybe you like got a job at [08:59] Google once or something, that's enough [09:01] that everybody in your life that's [09:02] nontechnical is going to start spamming [09:04] you with these types of things. Now, I'm [09:05] going to ask an interesting question. I [09:07] actually don't know what you guys will [09:08] answer here. Do you get more or less [09:10] tech questions since AI started to blow [09:12] up? I am very curious where this lands [09:15] for y'all. Now that the qu's been up for [09:16] a little bit, make sure you pick your [09:18] decision before I say what I'm about to [09:20] say. I personally find I'm getting way [09:23] less, which has been interesting. I get [09:25] significantly fewer of these types of [09:27] questions than I used to. But what's [09:30] even more interesting is the content of [09:33] these questions. It feels like the [09:35] questions I've been getting are [09:36] different now where I'm suddenly getting [09:39] like random Twitch streamers hitting me [09:41] up about their vibecoded chat app for [09:44] not chatting with AI but having their [09:46] chat shown in their stream or I'm [09:48] talking to people who I used to work [09:49] with at Twitch that were more on the [09:51] product side that are building their own [09:52] solutions to random video problems or [09:54] I'm talking to people who I know from [09:56] like high school that are building apps [09:58] for their friends restaurants and [ __ ] [10:00] and none of them knew how to code and [10:02] all of them are confused and the AI gets [10:05] them pretty far. But what ends up [10:07] happening is I get these weird questions [10:09] that are full of technical terms, a [10:12] handful of which are even being used [10:13] correctly, but the question is like [10:16] missing from it somehow. It's hard to [10:18] describe, but it's this uncanny thing [10:20] where even if the question is simple, [10:22] the amount of mental energy it takes for [10:24] me to parse the question out of it has [10:26] gone up a ton. It's weird. It leans It's [10:31] similar to [ __ ] bench. I get [10:32] questions that feel like [ __ ] bench. [10:34] I feel like that goes deeper than it [10:37] might seem initially. And I know I've [10:39] experienced this as an open- source [10:41] maintainer and developer myself. I have [10:44] had a lot of people who are really [10:46] confused that their T3 chat sub doesn't [10:49] work in T3 code. I've had people who are [10:51] really confused that their chat GPT sub [10:54] didn't give them API access back in the [10:56] day. I've had people confused about all [10:58] sorts of things that exist so far out of [11:01] where they normally would be that are in [11:04] a very very confused state right now [11:06] because they're suddenly way deeper than [11:08] they've ever been. And this is a huge [11:11] burden for maintainers and community [11:12] people in particular. The quality of [11:14] questions I see in things like the [11:15] create T3 app channels has gone down [11:18] meaningfully. The quality of the [11:20] questions I get about random things like [11:22] TypeScript and TRPC has gone down [11:24] hilariously. Beyond that, some of these [11:26] people just don't get it to the point of [11:28] hallucinating. I've been thinking about [11:30] this comment I just got sent on Reddit [11:32] far too much. I remember Theo saying [11:34] something along the lines of React is [11:36] dead and because of that, there is [11:37] Nex.js and there's absolutely no need [11:40] for React, of course, because it's [11:41] everything React does but better. I [11:44] cannot imagine a world where this [11:46] particular commenter had written a [11:49] single line of code before AI. This is a [11:52] hallucination that can only occur due to [11:55] a specific type of brain rot that is [11:57] unique to these non-devs learning to [12:00] code right now. And since they are [12:02] shipping more than they ever could have [12:03] imagined, they have a bit of a god [12:05] complex. These people are insanely [12:07] entitled, insanely toxic, and really [12:10] demoralizing as a maintainer. Along the [12:13] same lines, I want to highlight one [12:15] particular PR that annoyed me. We had a [12:17] stailed to-do MD file in the repo that [12:19] had random things I was working on at [12:21] some point in it. And someone filed a [12:23] nonsense PR that tried to fix all of [12:26] those things and ended up just breaking [12:28] other things. They didn't get any [12:30] response from us cuz we were being [12:31] flooded with PRs. So he randomly tags me [12:35] and two other people whose PRs merged [12:37] recently. I was so annoyed about this [12:40] because remember I was like underslept [12:42] deep in this Sunday session going [12:44] through PRs and then got a notification [12:46] from somebody spamming me with a PR [12:49] where half of the things it fixes are [12:50] already fixed. So how do you imagine [12:53] this person responded here with this [12:55] useful feedback that his way of [12:58] contributing was bad? Yeah, I was a [13:00] little harsh saying that tagging a bunch [13:01] of us doesn't make me more likely to [13:02] merge. It just makes me want to block [13:04] you from the repo. Terrible etiquette. [13:05] Bye. But this is a lesson you need to [13:07] learn as an open source maintainer. I [13:09] had to make a bunch of mistakes like [13:10] this myself in order to get to the point [13:13] where I know proper open source [13:15] etiquette. I was told by many people I [13:17] was way too harsh here. And then big fan [13:20] my friend did not mean that. It was [13:22] early morning in Brazil. I got a bit [13:23] enthusiastic. Let's discuss etiquette. [13:25] And the one you demonstrated was one of [13:26] the poorest. Really crippled the image I [13:28] had in relation to your channel and [13:30] content. I have been contributing to [13:32] projects since before you were born. [13:34] such an attitude, including some YouTube [13:35] codes of yours that I've never received [13:37] before. Feel free to block me. Mature. [13:39] This is somebody who never wrote code [13:40] before AI. Straight up. And I promise [13:43] you, you were not contributing to code [13:44] 31 years ago, [ __ ] And this is [13:47] the hot take. I need you guys to ignore [13:49] my message in between because the [13:51] reality is much simpler here. The type [13:54] of person who does this is the exact [13:56] same type of person who does this. These [13:58] are the same people. and then making [14:00] another account cuz I did block him [14:02] named Theo is a child so he could come [14:05] make fun of me again. This is nonsense. [14:07] And this is the type of [ __ ] open source [14:09] maintainers have always had to deal with [14:11] a little bit, but we're suddenly having [14:12] to deal with it a lot. And this isn't [14:15] about PR spam. This is about the [14:16] degradation of the energy of the people [14:18] who are doing open source maintenance [14:20] out of the kindness of their hearts. You [14:22] know, the classic XKCD, the dependency [14:24] one, this random package some person in [14:26] Nebraska has been thanklessly [14:27] maintaining since 2003. their job got [14:30] harder. And we all need to be terrified [14:32] of that fact. This person all the way in [14:35] the bottom here holding everything up [14:36] above them, they already have an [14:38] incredibly hard job. They're already on [14:40] the line of giving up. They suddenly [14:42] have more reason to give up. [14:44] Significantly more reason. That sucks. [14:47] That has the potential to cause real [14:49] long-term damage in this industry. This [14:51] is how things like the XZ back door [14:53] happen. If you're not familiar with the [14:54] story, I'll TLDDR quick. XC is a really [14:56] important compression library used by a [14:58] ton of open source software, especially [15:00] in the Linux ecosystem. The guy [15:02] maintaining XC has been slowly burning [15:04] out since he created it and then started [15:06] getting spammed with lots of really mean [15:09] emails saying, "How dare you not merge [15:11] this? How dare you keep maintaining this [15:13] when you're not doing anything?" But [15:14] there was this one maintainer, Got Tan, [15:16] who showed up and was actually really [15:18] helpful. And eventually, Gotan offered [15:20] to take over the project. Since then, we [15:22] believe that those accounts that were [15:24] spamming the original maintainer were [15:26] not just bad faith open- source [15:28] contributors. These were fake accounts [15:31] trying to social engineer this [15:33] maintainer into giving up the project. [15:35] Doing this to people has gotten easier, [15:38] not harder. This is the exact type of [15:40] attack we need to be really, really [15:41] scared of. It doing it got way easier [15:43] now that you can make it look like just [15:46] well-meaning people spamming AI PRs. I [15:49] could spend a night building a script [15:51] that would immediately flood and ruin [15:53] the lives of every major open- source [15:55] maintainer. It would be relatively easy [15:57] to do, especially if you have your own [15:58] project. If I just like made 15 sock [16:01] puppet accounts, merged all of their PRs [16:03] into T3 code, started spamming other [16:06] projects with PRs, and just set up some [16:08] agent orchestration layer to just spam [16:11] everything, and then start emailing the [16:12] maintainers saying, "Hey, how dare you [16:14] not merge this? You suck at your job." [16:16] Until eventually they quit. It would be [16:18] so easy for the right malicious person [16:20] with the right background to straight up [16:22] destroy half the software we rely on [16:24] today. It's terrifying. It's never been [16:26] easier to ruin open source for everyone [16:29] else. And the biggest problem by far is [16:31] the logo in the top left. GitHub is [16:33] doing jack [ __ ] [ __ ] to solve this [16:35] problem. We'll get to these two in a [16:37] second cuz I want to [ __ ] more about [16:38] GitHub for these two. GitHub will not [16:41] save us. Funny enough, I've talked about [16:43] this before and not even in regard to [16:45] AI. I did a video about GitHub's spam [16:48] problem because GitHub is a somewhat [16:50] trusted source of information that has [16:52] been used by so many different tools and [16:55] so many different things like search [16:56] engine indexing. GitHub does well on [16:59] Google. A bunch of spammers realized [17:02] this and started spamming real projects [17:04] like Shad Cnui with a bunch of porn [17:07] links. This is not a fake screenshot, by [17:09] the way. This is an actual screenshot of [17:11] the actual Shadian UIPR list. And it [17:14] took me doing a video and flaming GitHub [17:17] on Twitter publicly and pulling a bunch [17:20] of strings with my friends at GitHub for [17:22] them to even start introducing spam [17:24] detection and bulk deletion and banning [17:27] tools. Before this, they didn't even [17:29] have a way to ban a contributor from [17:31] your repo. It's insane. They are just so [17:35] behind on even the most basic things [17:37] that you would need to take care of the [17:39] communities that we are maintaining on [17:41] this platform. And I'm not speaking out [17:43] of my ass here. I know a lot of people [17:45] like to say, "Oh, Theo thinks he knows [17:46] so much cuz he built a web app once." [17:48] [ __ ] I built the best [17:49] moderation platform on the internet with [17:51] an incredible team. I shouldn't even say [17:52] I built it cuz they did. I just got to [17:54] help shepherd it to the point of success [17:56] and I'm so lucky to have been in that [17:57] team when I was. It changed my entire [18:00] career. It is the Mod View dashboard on [18:02] Twitch. This dashboard was built to be [18:04] entirely customizable so that you can [18:06] shape your moderation platform how you [18:09] want as a moderator or with your own [18:11] team of moderators. We have built so [18:13] many things even here you see in chat. [18:15] So dumb these little six-year-old spam [18:16] suit PRs. It looks like somebody deleted [18:18] that and it disappeared because we have [18:20] real moderation tools here where things [18:22] get caught by default when they're [18:24] detected to possibly be spam and one of [18:26] us maintainers has to choose whether or [18:28] not we want to let this in. I think this [18:30] is fine. I would not abandon it. But [18:31] like look at that. We have an automod Q [18:33] that shows when messages get filtered [18:35] and why they were filtered and what [18:37] action someone took on them. Like Twitch [18:39] is a streaming platform for gamers to [18:41] complain about game studios effectively. [18:44] But we built way better moderation tools [18:46] because we knew how important safety was [18:48] to make a good platform. Why the [ __ ] [18:50] was my team of four able to build better [18:52] moderation tools for Twitch in 7 months [18:54] than GitHub with thousands of engineers, [18:57] hundreds of which are dedicated to [18:58] safety and platform maintenance stuff, [19:00] have been able to build in 10 years. [19:02] It's insane. And to their credit, like [19:04] YouTube's tools suck for this really [19:06] hard, too. Like really, really bad. [19:08] YouTube does have a good shadow banning [19:10] type thing where you can hide a person. [19:12] They can still see their own comments so [19:13] they don't know they've been banned, [19:14] which I do like. There's no real way to [19:16] do that on Twitch because we show Twitch [19:18] chat when we're streaming. So, it's [19:20] harder to hide somebody like that. But [19:22] yeah, for the most part, YouTube's [19:23] moderation's garbage in comparison. And [19:25] god, GitHubs is non-existent. And now we [19:28] are stuck as a community trying to build [19:29] our own solutions. I was going to wait [19:32] till the end to cover solutions, but I [19:33] do want to try and discuss them for [19:36] these pieces here. I've been seeing a [19:38] handful of projects trying to figure [19:39] this out, and some of the solutions I've [19:41] seen are actually quite cool. One of the [19:43] first I saw was from Ree who used to [19:44] work at Verscell. He's now at Open Code. [19:46] He also built Answer overflow which is a [19:48] tool that turns your Discord Q&A [19:50] channels into search indexable websites. [19:53] He has a lot of open source stuff that [19:54] has a lot of PRs going into it and [19:57] wanted to make it easier to identify [19:58] whose PRs are worth looking at based on [20:01] their history doing contributions. So he [20:03] made PR stats which will show what [20:06] percent of your PRs end up getting [20:07] merged, what PRs you filed, where they [20:09] have been filed, what types of work you [20:11] have done. This is awesome. I really, [20:13] really like this. That all said, this [20:16] type of karma is hard to build and [20:17] maintain and it's weirdly easy to fake [20:19] through strategies like what I mentioned [20:21] before. It's not everything and it would [20:23] also block out new developers and [20:24] contributors in a way that I don't [20:26] necessarily love. It is a useful stat. [20:28] We should absolutely merge things like [20:30] this and bring them into our tools. But [20:32] there's more we can do. And I really [20:33] like a hands-on approach, which is why [20:36] I'm really hyped with what Mitchell is [20:37] creating. If you're not familiar with [20:38] him, he's the guy who made Ghosty as [20:40] well as Terraform. Mitchell knows his [20:42] [ __ ] He built Vouch because he was [20:44] tired of the nonsense PRs he was getting [20:46] in things like Ghosty. Funny enough, [20:48] Vouch has two PRs open and eight issues, [20:50] which is insane, especially considering [20:52] how useful and used this project is. So, [20:54] what is Vouch? Community trust [20:56] management system. People must be [20:57] vouched for before interacting with [20:58] certain parts of a project. people can [21:00] explicitly be denounced to block them [21:02] from interacting with the project going [21:03] forward. You set up vouch as a workflow. [21:05] It will automatically run in this case [21:07] whenever PRs are opened, reopened, [21:08] synced, ready for review, converted to [21:10] draft, all the different things that [21:11] change the status of a PR. And there is [21:13] this vouch TD file that has all of these [21:16] GitHub users that we have personally [21:18] vouched and decided that their PRs are [21:20] worth at least looking at. And now when [21:22] I go to the poll request tab, you see [21:24] certain PRs that are unvouched and [21:26] certain ones that are vouched as [21:27] trusted. And more importantly, when I'm [21:29] busy and can't look through everything, [21:31] which is most days, I can switch to [21:32] vouch trusted and filter out over [21:35] twothirds of the open PR. So, we went [21:37] from 150 to 43. And now this is like [21:39] actually viable. To be fair, half of [21:41] this has been banned at fixing all sorts [21:43] of random one-off bugs. God bless him. [21:45] This is an example of what I would [21:47] consider a golden PR. These are the ones [21:50] I love. Handle draft PR conversion in PR [21:53] vouch summary. Add missing converted to [21:55] draft pull request target trigger. [21:56] Ensure trust labels are refreshed. When [21:58] an open PR is moved back into draft [21:59] state and keep the working behavior [22:00] unchanged. It's a very simple PR. It [22:02] clearly describes what it does. So when [22:04] a draft PR is bumped out of draft, we [22:07] need to recheck the vouch state. This is [22:08] a simple oneline change where you added [22:10] this one additional field for when it's [22:12] converted to a draft. Awesome. Great [22:14] change. And I love these types of PRs. [22:16] Here's another really good one. This is [22:18] one where there was a missing key for [22:20] the local storage cleanup list. We [22:21] forgot to include render state v7 which [22:24] is just a thing we do to persist where [22:26] things are in the UI. We forgot to clean [22:28] up old data. You notice that and when [22:30] file a PR adding this one additional [22:32] line for the things that need to be [22:33] cleaned up. I love these these one to [22:35] five line PRs that clearly state what [22:37] they're doing and why they did them are [22:38] the best. Here was another one that was [22:40] really good. I actually initially didn't [22:42] know how important this was until I [22:43] looked at the issue and read a bit more. [22:45] But the PR was super clear. We were [22:47] using the app name as the directory [22:49] where files were saved cuz that's what [22:50] happens by default in Electron. But the [22:52] name had like parentheses and spaces and [22:54] things in it that aren't great for a lot [22:57] of platforms. And he changed it to just [22:59] be T3 code or T3 code dev in dev mode. [23:02] Put a great comment describing what [23:04] we're doing and why as well as code to [23:06] pull out the old data and move it over [23:08] so we can handle that. Just good PR, [23:10] reasonable changes that were actually [23:12] needed. Since it was super simple, [23:13] linked to the issue, described what was [23:14] going on. This is a very easy PR to [23:16] click merge on. Another great one from [23:18] Maria. Aligning package versions before [23:20] building artifacts. This makes sure that [23:22] all of the package versions for [23:23] everything are the same before we go and [23:26] build the actual release, which is a [23:28] thing we definitely should have been [23:29] doing before. Wait, why is Maria [23:30] unvouched? What went wrong there? The [23:32] only thing I've ever used the GitHub UI [23:34] for editing things for is creating [23:37] license MDs and like changing the [23:40] license for a project, but more [23:41] importantly, we're updating the vouched [23:44] MD. And now when she files PRs, they [23:45] will be marked as vouched. This is a [23:47] great system. This is going to make this [23:49] project significantly more maintainable [23:50] than it otherwise would be. And once [23:52] again, thank you to Mitchell for [23:54] continuing to put out incredibly useful [23:56] things like this. Mitchell Ashimoto is a [23:58] legend and deserves all of the flowers [24:00] he has received. I will hit the follow [24:02] cuz I probably should have forever ago. [24:03] Great project. I've also seen some [24:05] effort in projects like anti-slop, which [24:07] is set up to make it easy to scan a PR [24:09] and identify if it is likely to just be [24:11] AI slop and close it. This is really [24:13] cool, but my concern is that the cost [24:15] for something like this could quickly [24:17] escalate because you almost certainly [24:19] have to use AI to actually scan these [24:21] PRs. It has a lot of config, [24:25] enough config that I'm almost certain [24:26] that this project was vibe coded, but [24:28] yeah, you get the idea. There are a lot [24:30] of solutions being made to try and fix [24:32] these problems. Some of them are going [24:34] to make it harder for new maintainers to [24:35] break out, which sucks because we might [24:37] just have our current maintainers until [24:39] they die and then all of this slowly [24:40] evaporates. So I want to make sure [24:42] whatever solutions we end up going with [24:44] long term leave room for developers who [24:47] are new to open source to still be able [24:49] to like break in. And thankfully finding [24:52] good PRs and good contributors still is [24:54] relatively easy. It's they stand out in [24:57] that list of PRs. I have been surprised [24:58] how quickly I can identify which people [25:00] are good and which ones aren't. I [25:02] generally believe that good maintainers [25:04] are great at making themselves known [25:06] even if they're not doing it [25:07] intentionally. They just good [25:09] maintainers stand out much like bad ones [25:11] do. Bad ones do weird stuff like tagging [25:14] a bunch of people when they're not happy [25:15] with how quickly their PRs responded to. [25:17] Good maintainers make it really easy to [25:19] understand what changes they made and [25:20] why. This is a thing we all have to do [25:22] as maintainers of open source software [25:24] and it sucks. And it just got way [25:27] harder. It almost feels like [25:28] Hacktoberfest but forever and that [25:30] terrifies me. I put so much effort into [25:33] killing Hacktoberfest. I think this [25:35] video of mine, don't contribute to open [25:37] source, is one of the best videos I ever [25:39] filmed. Not sure who that blonde guy [25:41] with the mustache is though. Seriously [25:42] though, like that video, I have been [25:45] told by so many maintainers how thankful [25:46] they are for this video more than almost [25:48] anything I've done as a developer and [25:51] journalist, YouTuber, whatever you want [25:52] to call me. This video has been the one [25:54] the most people I care about have talked [25:57] to me about and thanked me for. This is [25:59] a thing I've cared about for a long time [26:01] and I am so thankful people are aware of [26:03] it now, but also terrified that the [26:06] awareness isn't counteracting the rate [26:08] at which the problem is growing. We need [26:10] to make more people aware of these [26:12] problems so they're more sympathetic to [26:13] it. We need to put more things in [26:15] between the problem and the maintainers [26:17] so they don't get burnt out. And we need [26:18] GitHub to just wake the [ __ ] up and do [26:20] more about this. GitHub needs to build [26:23] in more of these tools. They need to [26:24] make this part of the platform and not [26:26] continuing to pile on more burden onto [26:29] open source maintainers. That is the [26:31] biggest problem here and I want to make [26:32] sure that is clearly emphasized [26:34] throughout. The things that suck for [26:35] open source maintainers keep getting [26:36] worse. The fact they have to set up all [26:38] these tools and deal with all this slop [26:40] is making the hard parts harder. What [26:42] about the good parts? What about the [26:43] popularity of your package being [26:45] installed a whole bunch? What about the [26:46] job opportunities you can get from that? [26:48] What about the contracts you can get [26:50] with businesses helping them maintain [26:51] their interactions and their [26:52] integrations with your solution? What [26:54] about the sponsors you can get funding [26:56] your open source projects? To be very [26:58] clear, none of those things were ever [27:00] good enough. Open source maintainers did [27:03] not get paid enough. They did not get [27:04] enough recognition. They did not get [27:06] enough credit and they certainly did not [27:07] get enough sponsorship. Those problems [27:10] have gotten way worse. One of the things [27:13] I saw a lot of open source maintainers [27:14] do was sell courses. They would sell [27:16] workshops and courses to businesses that [27:18] wanted to use their solutions as a way [27:20] to make money. And I know a couple [27:22] people that made a meaningful amount of [27:23] money, like comparable to an edge salary [27:25] from doing stuff like that on the side [27:27] for 10 to 20 hours a week alongside the [27:29] maintenance of their projects. That's [27:31] not the case anymore. I also know people [27:32] like Tailwind. What Tailwind would do to [27:34] make money is they would sell things you [27:36] wanted to speed up your development [27:38] cycles. You'll see in the corner here, [27:40] there's this little plus button, which [27:41] is a subscription you can pay to [27:43] Tailwind to get a bunch of reusable [27:45] blocks, templates for pages, and their [27:47] complete UI kit. There was some name for [27:49] this before it was Tailwind Plus, and we [27:51] bought it forever ago back in like 2021, [27:54] and they still give us updates to this [27:56] day with a one-time lifetime purchase. [27:58] Tailwind's been awesome and super [28:00] generous with the hundred something [28:01] dollars we spent for that forever ago [28:03] for our business, but we've also built [28:05] so much on top of Tailwind and only paid [28:07] them $150 or so dollars over 5 years of [28:10] building everything we build on top of [28:11] it. And if I'm being real, if I didn't [28:13] have this now, the likelihood I pay for [28:15] it is near zero because I'm already [28:17] paying 200 a month for Quad, which I can [28:19] tell it to go build the thing instead. I [28:20] could literally take a screenshot of any [28:22] of the UI I see in here that I like, [28:23] hand it to an AI, and say, "Build it." [28:25] And not only will it build it, it'll [28:27] [ __ ] use Tailwind when it does it. [28:29] That's not great. Do I think they should [28:30] be forced to make the AI dumber to make [28:32] sure that these open source devs can [28:34] still be paid? No. I don't think they [28:35] were paid enough in the first place. And [28:37] now we're in this weird world where [28:39] companies might not even use the thing [28:41] because if they see it and like it, they [28:43] might just rebuild it themselves. Even [28:44] I'm guilty of this. There were projects [28:46] that I thought were pretty cool like [28:48] Conductor in Codeex Monitor. Conductor [28:50] wasn't open source, so I couldn't really [28:52] do anything to it when it didn't work [28:54] the way I needed. Codex Monitor was open [28:56] source, but it was clear the dev was [28:58] busy with other things and also the [29:00] project wasn't quite how I wanted to [29:02] build it. But it was an incredible [29:03] reference, one that I looked at and [29:05] thought about deeply when I built T3 [29:07] Code. T3 Code would not exist if it [29:09] wasn't for those other projects [29:10] inspiring us. On one hand, we were [29:12] inspired to do things like contribute, [29:14] but on the other, we were inspired to go [29:16] build our own thing so we could own it [29:17] and control it ourselves. And I've seen [29:19] a ton of this since. For every one [29:21] person I've seen fork T3 code to add [29:23] features and things they want, I've seen [29:25] another that was inspired to go build [29:27] their own alternative. That hurts the [29:29] top of funnel for these open source [29:30] maintainers. The likelihood somebody [29:32] even engages enough to care about the [29:34] maintainer has gone down. And if they [29:37] even do get that far, the likelihood [29:39] they spend money has also gone down. So [29:41] the upsides of open source which are the [29:43] proliferation of your software, the [29:45] proliferation of your ideas and the [29:47] potential to get funded for those things [29:49] that has gone down a ton. But the burden [29:51] of open source maintenance has gone up a [29:53] ton and that ratio shift terrifies me. [29:57] And this is where we need to do [29:58] something. The open-source pledge is a [30:01] great start, but it is just the start. [30:03] The open source pledge is a thing that [30:05] Zeie pushed for at Sentry that has now [30:07] become a good amount bigger a thing. The [30:09] open source pledge is a simple agreement [30:11] companies can make where they agree to [30:13] pay a minimum of $2,000 per year per [30:16] devbit your company to open source [30:18] maintainers. So if you have five [30:20] engineers, you are now agreeing to pay [30:22] 10 grand to open source projects every [30:25] single year. And you're expected to [30:26] self-report this every year about where [30:28] you paid, what you paid, and what you're [30:31] doing with all of this. They already [30:32] have an incredible group of companies [30:34] that are doing the pledge like Posit [30:36] Sentry Sanity channel sponsor Code [30:38] Rabbit, Hero Devs, Antithesis, Zero Dah, [30:40] channel sponsor Railway, previous [30:42] channel sponsor Bolt, Serai, Astral, [30:45] Prefect, Void Zero, Pyantic, AG Grid, a [30:48] personal favorite, Convex, who's at [30:50] $7,692 [30:52] per dev every year. That's an insane [30:55] number that a tiny company like Convex [30:57] that just did their series B and is so [30:59] small is contributing way more money to [31:01] open source than almost any big company [31:03] is. That shows how [ __ ] things are. [31:05] Oo, Frontend Master's also killing it [31:07] here with $10,000 per dev at the [31:08] company. So, if you work at a company [31:10] that has money, go bug your boss and [31:13] their boss to do this. And if you are [31:16] their boss, go do this. If you have the [31:18] money to spare, paying for the software [31:20] that we use every day to continue to [31:22] exist is essential. It is a very [31:25] important thing. And as we can see from [31:26] this wonderful load of the GitHub repo [31:29] for T3 Code, there is no world in which [31:31] GitHub is going to fix anything. They [31:33] can't even render CSS properly. I hit [31:36] this bug once a day now. It just [31:37] happens. As I was saying before hitting [31:39] that bad load, there's two more [31:41] important things that we all can do, and [31:43] I hope I see more developers doing this [31:45] stuff. The first one is helping with the [31:48] burden. There are so many little things [31:49] you can do other than opening PRs. And I [31:52] really want you to try and embody the [31:54] problem before you do anything in a repo [31:56] like this. The biggest problem we have [31:58] is the sheer volume of PRs and the [32:01] effort it takes to validate if any of [32:03] them are even worth looking at. There's [32:05] tons of little things that make this [32:06] suck. Like the fact that I can't see how [32:08] many lines were changed in this view. [32:11] That makes it way harder to know if a PR [32:13] is egregious or not. Because like if [32:15] there's a PR that title is a very simple [32:17] thing and it's like a thousand lines, I [32:19] just want to get rid of it. And don't [32:20] even get me started on the issues tab. [32:22] Issues tab is even more chaotic work to [32:25] manage. So how can we help maintainers [32:28] with these things? One of the best [32:30] things you can do is helping clarify [32:32] what matters by being in the weeds of [32:35] things. We have a couple maintainers [32:36] that have already been very helpful for [32:38] this. Huge shout out to Maria and Bin [32:39] Bandit. They've been essential as this [32:41] repo gets more and more popular. So, [32:42] here's a bug somebody reported where [32:44] they can't close the diff side panel. [32:46] Someone asked, "You got the latest [32:48] version?" Oh, I see this bug. We'll push [32:49] a PR soon. CC Julius so that he knows [32:51] that he's working on this so they don't [32:53] end up clobbering each other working on [32:54] the same thing at the same time. File [32:56] the PR, stated the root cause, stated [32:58] the fix. Corfix is the same as this [33:00] other PR that somebody else filed that [33:02] was the same thing. The difference is [33:04] that 930 introduces a new search params [33:06] helper that set all three keys to [33:07] undefined while this PR just inlines [33:09] this one particular thing. This is so [33:11] good. This is golden examples of doing [33:14] this, right? He took this issue, [33:16] identified other things that are [33:19] touching the same stuff. The only thing [33:21] he could have theoretically done better, [33:22] and I don't even know if this is the [33:23] case or not, is if there were other [33:24] related issues, if he had linked those [33:26] here, and I would bet that in his PR, if [33:28] there are other related issues, he's [33:30] mentioned them. Okay, just as 935, so [33:32] it's probably just that one. This is the [33:33] type of person where if I was trying to [33:35] hire right now, if I had any budget to [33:37] do such, they would be very high up on [33:39] my list of people I would want to hire [33:40] because this just makes my life easier. [33:42] If you see an issue that's really stale [33:44] that has already been fixed, comment [33:45] saying, "Hey, are you sure you're on the [33:47] latest version? I think this PR fixed [33:49] it. It doesn't happen for me anymore on [33:50] the latest." These types of things are [33:53] so goddamn helpful. And once you've done [33:55] that a bit on the issue side, you can [33:57] start doing the same on the PR side. And [33:59] here, Ben Bandit is giving UX feedback [34:02] to get this PR more polished while also [34:04] asking the team what we think about this [34:07] before going too far with it. That's [34:08] great. He's reviewed PRs of mine and [34:10] others. He has given useful feedback in [34:13] the comments. He's answered questions [34:14] when I have them. He's preempted [34:16] questions and answered them in the PR [34:17] description. So good. And you quickly as [34:20] a maintainer start to associate these [34:22] names with these good vibes, which means [34:24] I now know if I want to just get some [34:26] [ __ ] merged and I see Bin Bandit's name [34:29] pop up or NMG's name pop up or Egg Fried [34:32] Rice pop up or Maria or any of these [34:34] people, the mapping in my brain is [34:36] quickly been completed such that I know [34:38] I can trust these people because they [34:40] write things very well. So good. But [34:43] there is one last thing that I think is [34:46] really important. And if you take [34:48] anything from this video, I really hope [34:50] it's this. We need to be nice to open [34:52] source maintainers. These people are [34:53] doing one of the most thankless jobs in [34:56] the industry. We can make so much money [34:58] writing code for companies and they are [35:01] instead choosing to do that work that [35:02] could make them hundreds of thousands of [35:04] dollars a year for free. These people [35:06] are building the foundations that we [35:09] build our software on top of. They [35:11] deserve to be treated well for that. And [35:13] I'm not saying that by simply making an [35:15] open- source project, you are now a [35:16] deity that people need to bow to. I'm [35:18] saying that we as users of these pieces [35:20] of software should put a little work [35:22] into being thankful to the developers [35:24] who build the things we build on top of. [35:26] I don't want this to just turn into [35:27] story time, so I'll do my best to keep [35:28] this point brief. When I said at the [35:30] start of the video that I'm only here [35:31] because of open source, that was not an [35:33] exaggeration in the slightest. The only [35:35] reason anybody knows who I am is because [35:37] I DM'd Fred Shot, the creator of Astro, [35:40] and Ryan Carneato, the creator of Solid, [35:42] and I still had like 500 or so followers [35:44] on Twitter because I really liked their [35:46] writing, and I wanted to give some [35:48] feedback on the like pros and the [35:50] structure of their blog posts cuz I'm a [35:51] nerd about formatting of writing and [35:53] text. Believe it or not, the guy who [35:54] does YouTube videos for a living likes [35:56] the flow of words. Who would have [35:57] thought? Both of them were so cool about [36:00] this. When I hit them up saying, "Hey, [36:02] the work you've done is awesome. I [36:04] really liked this post. Would you be [36:06] down for some feedback on the way it was [36:08] worded so it's easier for more people to [36:10] digest? That worked way better than I [36:12] ever would have imagined. I have a 100% [36:14] hit rate for me hitting someone up [36:16] saying, "Hey, can I give some feedback [36:18] on the way you wrote this?" and them [36:19] saying, "Fuck yes, absolutely." I'm not [36:21] saying everybody should go give pros [36:22] feedback to every article on the [36:24] internet. I'm saying that I appreciated [36:26] their work so much so I was reading [36:27] their blog posts and I hit them up about [36:30] that this thing that I cared about and I [36:32] had a feeling they did too and offered [36:34] something that made the thing they cared [36:36] about better. The offer is not the part [36:38] that matters there though. I really want [36:39] to emphasize the prior part which is [36:41] thanking the people who do cool [ __ ] in [36:44] ways that are not interfering with their [36:46] dayto-day. It's silly but like a dear [36:49] way of putting this. I get a lot of [36:51] messages from my own fans thanking me [36:54] for helping them get their first good [36:56] job or help them get a promotion or help [36:58] them establish their project or [37:00] whatever. I didn't do any of that. I am [37:02] just a tool in the toolbox that those [37:04] people chose to use to build their own [37:06] success with. But those messages still [37:08] feel awesome. Those messages make my [37:11] goddamn day. Seeing somebody hit me up [37:14] about how they were a line cook for a [37:16] decade, learning code on the side, [37:18] didn't feel like they could really do [37:20] it, but watching my videos made them [37:22] feel more like this crazy tech world we [37:24] were in was a place they could fit, and [37:26] now they have awesome tech jobs. My [37:28] video isn't what did it. My channel [37:29] isn't what did it. They did it. But that [37:32] message still makes me emotional. It [37:34] still makes everything feel worth it. [37:35] Those are the messages I think about [37:37] when I come upstairs and consider just [37:39] canceling stream and going down to play [37:41] a video game or check my email or [37:43] something. Those people are the ones [37:44] that make me so excited to keep doing [37:46] this. Be one of those people, but not [37:49] for me, for them. Thank these [37:51] maintainers and do it in a way that is [37:53] genuine. If it isn't genuine, don't do [37:55] it. I'm not saying write some sappy [37:57] message or ask chat GPT to glaze some [37:59] random library you like. I'm encouraging [38:01] you to think about the tools you use. [38:03] Look at the packages they use. Look at [38:06] where they came from, who made them, [38:07] why' they make them, what does their [38:09] GitHub repo look like, what are they [38:10] contributing, what are they merging and [38:11] not merging. What do they care about? [38:13] There's a very good chance you care [38:15] about the same things if you even took [38:16] the time to notice they exist. The [38:18] reason people maintain open- source [38:20] software is because they care so much [38:22] that you could argue it's too much. And [38:24] when their job gets harder and harder [38:26] because of all of this AI [ __ ] it [38:28] gets more likely they give up. The [38:29] reason they're here is that excitement. [38:32] And if you can remind them of that, if [38:34] you can be the excited thing that made [38:36] them do this in the first place, you can [38:38] make it feel so much more worth it. You [38:40] should pay them, too. But this is even [38:43] more important than the financial [38:44] compensation. Cuz if they were just here [38:45] for money, they would get normal tech [38:47] jobs. But they're not. There's a lot of [38:49] things about me that make me a bad dev, [38:51] a bad influencer, bad influence in [38:53] general. But one of the things that I've [38:55] learned to love the most about me is the [38:58] way I reach out to the things that I [39:00] find cool. When I see something that's [39:02] interesting, I think less about the [39:04] thing and I think more about the people [39:05] and why they made the thing. And I'll [39:07] often reach out. Even when I was a [39:09] nobody, I would. And the craziest thing [39:11] is that the likelihood I get a response [39:13] has not gone up meaningfully since I got [39:16] popular. When I had a,000 followers and [39:18] when I had 300,000 followers, the [39:20] likelihood that I got a reply stayed [39:22] roughly the same. Okay? It's actually [39:24] gone down a lot a lot since they [39:25] absolutely [ __ ] the Twitter DMs with [39:27] the update with the encrypted stuff. But [39:29] before then, the rate stayed nearly flat [39:32] as I continued to get more relevant in [39:34] the space. A simple two sentence, "Hey, [39:37] I really appreciated this PR you [39:39] shipped. I've been a fan of what you've [39:41] been building for years. This library [39:42] makes my life much better. Thank you." [39:44] Those messages might seem small, but [39:46] they can actually change your life. And [39:48] I would not be here today if it wasn't [39:50] for the things like that that I did when [39:52] I left Twitch. Hell, even when I was at [39:54] Twitch, I did stuff like that. And it [39:56] can entirely change the trajectory of [39:58] where you're going in this crazy field. [40:00] But more importantly, it makes these [40:02] people less likely to give up. And I [40:04] don't want to live in a software dev [40:05] industry where the best maintainers who [40:07] built the foundations we build on top of [40:09] have all burnt out and given up. I want [40:11] to make sure we all work together to [40:13] prevent that. Be nice to the people who [40:14] build the software you use. Pay them if [40:16] you can and thank them either way. I [40:18] hope this helps you guys be better open [40:20] source users so that we can keep open [40:21] source working as well as it does now.  📄 **Full text:** ![[Full Document Contents/Articles/Open Source Is Dying|Open Source Is Dying, YouTube]] ## Highlights - Open source is incredibly important to me. I can say confidently I would not be here today if it wasn't for open- source software. It's a huge part of how I started my career, got into YouTube, and made all of this happen. Life without open source is genuinely hard for me to imagine, which is why I'm really scared right now. We're finally at the point where AI is having a real impact on open source. And if I'm being frank, it's not very good. And no, I'm not just talking about the people on Reddit who are mad because GitHub isn't for them and they can't find the download button. As funny as these posts are, I'm talking more about stuff like this Tail Draw's ([View Highlight](https://read.readwise.io/read/01kkvmrrqjbxhn3z9zx6ddwd8y)) - Tags: 👻 ai highlighted - announcement that they're automatically closing PRs from external contributors going forward. Increased requirements for reporting bugs in projects like Node.js where you can't just flag it anymore cuz they're getting so much AI spam. Or even the Tailwind drama I covered earlier this year that has been massively impacting their ability to fund the team and project. This isn't good. If things keep going in this direction, not only will it destroy open source, it might destroy software as a whole. Having these core pieces we can all rely on together as an industry is essential for our success building ([View Highlight](https://read.readwise.io/read/01kkvmrrqpngp7gwezehzj8k4j)) - Tags: 👻 ai highlighted - trying to social engineer this maintainer into giving up the project. Doing this to people has gotten easier, not harder. This is the exact type of attack we need to be really, really scared of. It doing it got way easier now that you can make it look like just well-meaning people spamming AI PRs. I could spend a night building a script that would immediately flood and ruin the lives of every major open- source maintainer. It would be relatively easy to do, especially if you have your own project. If I just like made 15 sock ([View Highlight](https://read.readwise.io/read/01kkvmrrvx0yzbyr7gas0tydwc)) - Tags: 👻 ai highlighted - puppet accounts, merged all of their PRs into T3 code, started spamming other projects with PRs, and just set up some agent orchestration layer to just spam everything, and then start emailing the maintainers saying, "Hey, how dare you not merge this? You suck at your job." Until eventually they quit. It would be so easy for the right malicious person with the right background to straight up destroy half the software we rely on today. It's terrifying. It's never been easier to ruin open source for everyone else. And the biggest problem by far is ([View Highlight](https://read.readwise.io/read/01kkvmrrxzrfdpbdaxcmmpwvg9)) - Tags: 👻 ai highlighted - and I am so thankful people are aware of it now, but also terrified that the awareness isn't counteracting the rate at which the problem is growing. We need to make more people aware of these problems so they're more sympathetic to it. We need to put more things in between the problem and the maintainers so they don't get burnt out. And we need GitHub to just wake the [ __ ] up and do more about this. GitHub needs to build in more of these tools. They need to make this part of the platform and not continuing to pile on more burden onto open source maintainers. That is the ([View Highlight](https://read.readwise.io/read/01kkvmrs5xscmdnprapcq8epq1)) - Tags: 👻 ai highlighted - Rice pop up or Maria or any of these people, the mapping in my brain is quickly been completed such that I know I can trust these people because they write things very well. So good. But there is one last thing that I think is really important. And if you take anything from this video, I really hope it's this. We need to be nice to open source maintainers. These people are doing one of the most thankless jobs in the industry. We can make so much money writing code for companies and they are ([View Highlight](https://read.readwise.io/read/01kkvmrsae8megctnmwvk32pry)) - Tags: 👻 ai highlighted - you to think about the tools you use. Look at the packages they use. Look at where they came from, who made them, why' they make them, what does their GitHub repo look like, what are they contributing, what are they merging and not merging. What do they care about? There's a very good chance you care about the same things if you even took the time to notice they exist. The reason people maintain open- source software is because they care so much that you could argue it's too much. And when their job gets harder and harder because of all of this AI [ __ ] it gets more likely they give up. The reason they're here is that excitement. ([View Highlight](https://read.readwise.io/read/01kkvmrsmrzmbayh8r4w90z167)) - Tags: 👻 ai highlighted - But more importantly, it makes these people less likely to give up. And I don't want to live in a software dev industry where the best maintainers who built the foundations we build on top of have all burnt out and given up. I want to make sure we all work together to prevent that. Be nice to the people who build the software you use. Pay them if you can and thank them either way. I hope this helps you guys be better open source users so that we can keep open source working as well as it does now. ([View Highlight](https://read.readwise.io/read/01kkvmrssymge99np03xcqk7e9)) - Tags: 👻 ai highlighted