The Standup with ThePrimeagen - is AI ruining opensource? (Lost episode)

Episode Date: March 26, 2026

Thank You! https://blacksmith.sh our #sponsor (https://www.youtube.com/hashtag/sponsor) today! Speed up your GitHub Actions AND pay less! https://x.com/terminaldotshop - Want to order coffee over SSH? ssh terminal.shop This week on The Standup, we break down the real way to contribute to open source… and why most people get it wrong. With creators behind tools like Laravel, Tailwind, and Ghostty, we get into what actually matters: earning trust, fixing real problems, and why “drive-by” PRs (especially AI-generated ones) are doing more harm than good. We also talk about whether open source is still worth it, how it can shape your career, and the hidden realities of maintaining projects used by millions. If you’ve ever thought about contributing to open source… start here.

All right, all right. Here, let me do a nice little intro. Yeah, yeah, yeah, yeah, yeah. Anyway, sorry. All right, today we are talking about open source, the right way to do open source we have with us. TJ, core maintainer, or used to be core maintainer of NeoVim Adam, creator of Tailwind, Taylor Otwell, creator of Leravel and Mitchell, creator of many, many things, most recently, Ghosty, a super fantastic terminal in which was featured. in an Open AI

video just recently if I'm not if I'm not mistaken yeah yeah that is that is pretty dang awesome all right and so just kind of set the stage for those that don't know

there was this video that was released two years ago in which somebody used ExpressJS as a means to give an example where they forked ExpressJS manually edited the read me and then put in their name

and from there on out approximately every six hours for the last two years ExpressJS receives a PR that it says update, read me, and then has somebody name or the name of the video as the only contribution. And so, you know, this is obviously caused quite a bit of stir in the open source world. People are not very happy about that. I can totally understand why it's even bleeding over into other projects where people are doing the exact same thing, just a different project

like no JS or just pick your favorite project. There's probably quite a few of them. And then a lot of discussion from there, again, to set the stage is like, don't, I've seen videos like I think Theo did one, don't contribute to open source was his video and his big argument is first find the thing you're really interested in. And then once you're really interested in, get involved in the community. And then from there, maybe then you can start doing fixes and all that. And so I feel like we kind of assembled a crack team of people who've been contributing to open source for quite some time.

And so I'd like to hear everybody's thoughts on what is the right way to contribute to open source. So let's start with Mitchell. Mitchell, you haven't been on here in a while. Yeah, yeah, yeah, it's good to be back. And we'll see how long I'll be able to stay on. I'm waiting for someone to come over to my house right now, so we'll see. But yeah, I think there's so many ways to answer this,

but I think in general, like the happiest, the golden path of what the right way is to contribute to open source is definitely what you just said. It's like, join the community, figure out what they're about, figure out the things they care about, figure out the vibes of how they just observe. Just sit there and observe for a little while. And then after that, make a small change. You know, it's really hard. You know, open sources, a lot of trust. You know, if someone who's contributed dozens of patches that I know they're going to always,

like, follow up if something breaks, like, if they do something big and scary, I'm more willing to merge it because I'll be like, yeah, they'll follow up if it's not perfect anyway. And they've shown that they've, they do pretty good stuff. But if you just come out swinging and do something big, then it's really hard for me to like dedicate the time to review to that. So start small and try to focus on like fixing bugs or something. I actually there was like, I don't know this is still happening, but there was this trend for like a decade where people were like, write documentation. And I'm like, please don't write.

If you're a new user to a project, you're not expert enough to be teaching every other beginner, the project. So, like, don't write docs. Don't fix typos. Don't do any of that. Like, it's kind of just noise that doesn't matter that much. Don't refactor things? Refact it. Never refactor things, almost ever.

Even if you're a really serious contributor. Yeah, I think that's my, like, the big picture, but there's just so many angles to it. Whether you're a vibe coder or a handcrafted free-range NeoVim user, you still need CI to be able to build your binaries, run your test, or make your releases. That's where Blacksmith comes in. It takes your GitHub actions, and with a one-line change, makes them faster and more cost-effective. Not only that, but you can finally get visibility into your CI pipeline right when things go wrong. We're happy to have them as our sponsor for this episode, because just like us, this one is truly a no-brainer. Sign up and enjoy faster GitHub action workflows at a much lower price.

Blacksmith, twice the speed and up to 75% reduction in costs. Check them out at blacksmith.sh. Now back to the stand-up. That's kind of interesting. I'd actually like to hear what TJ has to think on refactoring because TJ's name is literally Teage Refactor DV. Lee, he's a big, big fan of it. Well, I mean, you miss 100% of the shots you don't take. So if you, you got to shoot for a refactor if you need one.

But, I mean, my, like, serious answer is if you're new to the project, you don't know why anything is the way it is. And so, like, if you think, oh, well, I know better, I'm going to write this in a new way that wasn't the way it was before. you're likely going to end in either the same spot. I don't know how many times I've started a refactor. I could definitely do it better this time. And then you get to the end and you say, that's the same function signature. Or you just end up in a worse spot that doesn't handle the 37 edge cases that were there before.

Or like some other existing thing like for NeoVim, we have this sometimes where people like, well, just rewrite this big feature in like a new way. It was like, but we're getting free maintenance, free, very low-cost maintenance, or like applying VIM patches to this thing. Like, it should stay exactly the same because we're getting updates from VIP. But there's nothing like, there's no way to know that unless you've been, like Mitchell said, hanging out in the community, seeing that VIM patches are a thing, doing and like understanding like, oh, there's like a whole world of other contributions

like existing in the separate repo that you don't know about. So in general, yeah, a big refactor. as like an early thing of like, I'll show how good I am at programming. They'll really like me after this is a surefire way to get people not happy with the contribution. Anybody else?

Taylor, you've been running an open source project for just a couple years now, right? Yeah, a few years. A couple or 20 or something like that. I can't remember. Yeah, gosh, I mean, a lot of stuff comes to mind. Like, some of the first things that come to mind

are one thing we actually have in our Larval internal, like code guide is read the room where like a lot of times we'll get a PR that just seems like disconnected from the rest of the projects even just in terms of the way the code is structured or the where the method is even put you know in the code base sometimes just like at the bottom of some file because someone stuck it there so like reading the room and like the context of what you're contributing to I think another thing is like I'm always looking for my my favorite kind of poor requests are things that like maybe add five lines of code, but unlock, like,

really, like, tons of developer power or, like, a really great new feature of flexibility with very minimal, like, code changes to the framework itself. In contrast to, like, huge PRs that modify dozens and dozens of files to unlock one niche, like, edge case for one particular user, that's, like, the worst kind of PR for me. Also, I prefer, like, all PRs ideally, come out of real world need.

A surprising amount of PRs to Larravel come from just like people watching other people make PRs and they see one feature come in and they're like, oh, that caused me to have this idea of, wouldn't it be neat if this had this feature? And like it wasn't driven from any real world like use case. It was just because they were watching other PRs come in. They're like made them think maybe this would be helpful too.

And it's just sort of made up in a vacuum. So don't do that. You know, I try to drive most PRs. of real world stuff and that's how like all the features even i myself add to laravel are usually driven out of real world stuff we're building here at laravel very similar to like rails and base camp and all of that um yeah so that's a couple quick things that come to mind i i would assume you get a lot more PRs for laravel uh this is just me completely assuming in a vacuum here uh just because the framework itself and also the code people write with the framework are very highly aligned

and so that they could probably start slunk, you know, spulunking through and try to figure it out, whereas Adam Watham, I assume Tailwind's code base versus the people with whom they serve are very, very far away camps. Yeah. Meaning that,

you know, basically, yeah, we don't get a lot of contributions, really because of that. You're looking for more read-me updates then? Is that the call that we're hearing right now? Yes,

more read-me updates. No, I mean, like, I think like Taylor Mitchell said, my favorite PRs to get are things that fix bugs, because that's actually like saving me time, you know? Or if someone unlocks like some nice performance improvement, you know, things like that,

that's always nice, especially if it doesn't require some crazy reimagining of how some entire subsystem works. But new features, I generally feel like a chore, you know, to receive, especially from someone you don't know. I think it's fine when it comes from someone who you talk to, like frequently who's been in the community for a long time and gets it. But not a good first PR, I don't think. Kind of earn the maintainer's trust with like bug fixes or even just like honestly like responding to other people's issues and explaining why it's like their fault instead of me responding to people and telling them why it's their fault is another good way to sort of like earn trust because it shows. to like oh i actually like understand how this stuff works and why things work this way and um

whatever so in general i think like if i'm not mistaken is you want to recreate the stack overflow feeling where you get a you get like a base level and you can only comment and then through enough comments and umboats you can then gain more and more power so we just want to recreate that but with github a geth social credit score i see where this is going yeah but it would be a per repo social credit score. The thing too, Adam, with what you're saying, I feel like if people are like in the community and they're going to do a new feature, they've already talked to you about it. Like, that's sort of, I feel like kind of implicit in this like discussion here is like it's not the first time you're hearing about it when the pull request gets submitted. They've probably like

been hanging out in Discord or element or whatever like on an issue track or discussions kind of like, oh, I feel like we really need like XYZ. What do you? you think and then you discuss wrong and say okay cool I'll submit a PR not like out of the blue nowhere I feel like that's one of the other things that really like people miss about this is like if you're hanging out in the community you get chances to talk about the feature that you're really missing and then get a lot of feedback like before any code gets submitted yeah and if you don't do it that way you'll end up opening a PR that'll basically get ignored for weeks then you'll get resentful and frustrated because you feel like this person's like being a dick when in actuality it's just

like they didn't have anything on their calendar saying like review the feature that this person invented you know like they had their time was pre-allocated to other things you know so one thing i've got to think about these PRs is like someone someone asked me like hey wouldn't this be a cool feature in Laravel and maybe it would but it's like entirely dependent on the PR itself and the amount of code it takes to build the feature, right? Like, yeah, that sounds great, but like, it's hard to actually know if I would click merge or not until I see the code and like how complex it is. I'm, I pretty much have to assume I'm going to be maintaining it forever, to be honest, because anything can happen. And, um, you know, like, what does it look like? Yeah, we, uh, that's why we,

we have this policy like in, and ghosty and it's in our contributors doc where like, a PR has to be, has to close an issue. Um, if you make a PR, um, if you make a PR, with no associated issue, and our issues, only maintainers can open issues. Users can't open issues. Users can only open discussions. Discussions are where maintainers could do feature design. We could bike shed, we could assess whether something's worth it. And then only a maintainer, or if a maintainer blesses you, which is actually pretty rare, but a maintainer can then convert that to an issue. And then it explicitly says, like, if there isn't no associated issue, you're still welcome to open a PR, but exactly what Adam said. There's a sentence in there. It says, like, I might review it,

in a week, a month, 10 years, I might close it without commenting. Like, there's no warranty whatsoever. I don't need to justify anything. That just might get closed, even though it's perfect. And it's to try to avoid this drive-by, fix a bug, which isn't a real bug, or, you know, it's just a feature or introduce a feature we didn't want. Or, like, I think what Taylor was getting at was, like, a lot of features, it, the actual, like, business logic isn't hard.

What's hard is, like, the last mile taste of how that feature. get exposed, gets exposed to users. And I don't trust a lot of people with taste. And so you end up like getting this PR that's mostly there. And then you're just like arguing about taste. And so I want to do all that bike chitting in the discussion. And a lot of the bike chitting in the discussion is literally about, I don't care how you're going to implement.

It's not about how. It's about what is the config syntax? What is the config name? What does the UI look like with little drawings? It's just that stuff because then you could get the rest working. And you could like iterate on that. you have like a, isn't it like an famous like Amazon thing or something where like every like new projects that was like write the press release first, you know? But yeah.

So with the way that you guys do things, Mitchell, if you are the only ones who can open issues, do you monitor discussions like pretty diligently then to like notice when like a bug is reported from the community that should be escalated to an issue? Or do you just kind of trust that if there's a real bug you, I will know about it, you know? it will get to me somehow. If it's bad enough, I'm going to hear about it. But yeah, for the most part, it's part of my daily morning routine where I sort discussions by date created. And for the most part, we only get like three to five per day. But there's also like we have maintainers.

And we also have like another group of people in the community that we call helpers. There's probably two dozen of those people like significantly more. And they just have triage permissions on the GitHub repo and Discord communities and stuff. And they're awesome. and they tag stuff, label stuff for us. They answer a lot of Q&A and close it. Yeah, it's a cool role. So that's sort of how we look at that stuff.

How do you... I'm thinking that. Yeah. How do you convince people? Sorry, yeah. How do you convince or bring people on for, like, the triage role? Because for some people, I feel like, it's like a specific person that'd be really interested in doing that. Like, are you guys doing anything to find them?

or like how does that work for you guys? It's like, I think it's open source and it's pure sense. These people just appear. They start by not having that role, but they're answering questions and contributing really well to these discussions. And usually it's other helpers and maintainers that recognize these people.

I'm the only person that I could actually like assign people roles. So eventually just gets bubbled up. And now there's enough trust where like if another helper says, hey, I think this person should be a helper. Like I don't even, I didn't just like, sure tagged it. Like I don't look at what they've said. Like I trust that you get the vibes.

And yeah. And yeah. Okay. So then follow up. There's a lot of people that would want to contribute to open source and kind of reciting back that video where the idea was don't contribute to open source. If there's somebody whose goal is to contribute to open source and find a community. And they just want to do that because whether we like it or not, we, you know,

there's especially in many videos and many discussions about this saying, hey, don't, you that shouldn't be your primary goal. There is a ton of, let's say, inverse advertising on Twitter where people are like, oh, I did open source and now I have this super cool job. And there's a bunch of people who want to have really cool jobs. They want to be able to work on these things they really love. And so they see open source as a mean. So there's kind of like this competing conflict of don't do it, but also dream jobs over here with people doing it.

So they, you know, there's definitely a preserve, oh my gosh. I think there's two different ways. to approach it. Like, I think the one thing that we haven't discussed at all that I think is the most obvious path there is just like make something yourself that's yours instead of getting permission from anybody to do anything, you know? I think that's like the easiest way to get started. You know, also learn a lot about the perspective of an open source maintainer if you built your own thing and that's going to help you be a better contributor to other projects as well. And then the other side of it is, again, just like really be hyper-focused on making contributions that the maintainers

are going to be grateful for, which, again, is like bug fixes, answering questions and discussions, like anything that just feels like, man, I'm glad this person is around. Like, they are helping me out. That's going to be how you get your foot in the door to start getting your ideas, I think, heard and listened to and create those opportunities to actually submit people. PRs for more substantial features or things that people are going to benefit from other than like fixes and performance improvements and stuff like that. Yeah, I was thinking the same thing, you know, especially when it comes to like hiring or

getting jobs is like if you can create your own open source project, that I think is ideal. And related to what Mitchell said, like if I see someone apply and they've created some open source projects, I'm going to go out there and look at everything, like how the read me set up, what the config options look like, all the taste type stuff that Mitchell mentioned, I'm going to look at like super close. And that's actually a lot more valuable if I can look at an entire project that you've created versus like a couple PRs that are like sort of an isolation where I might not get like a full read on how you really think about like presenting what you build, which to me is like the most important thing I'm interested in basically if I'm hiring someone on Lareval's open source team is just like

these intangible taste type things of like how you package things. Yeah, the rebate is almost always like more high stakes than the code. When I'm like reviewing open source Yeah, can you write well? Can you explain this well? You know, I mean, that is valuable too. I'll come out from another angle. I think that if you the way I got involved with open source,

because I was one of those people that really looked up to open source. Like I like really, really wanted to be like a Rails contributor. That was like my big thing I wanted to do. And I don't think I ever was. But I was like hunting for something to fix in there. But I

think the best way that to go about it is to become a user of something, find an issue that you really want fixed and then you be the change to fix that issue and then join that community. And like if someone comes into any open source community I've been a part of has a really specific issue they want to fix and they seem genuine about it. There's usually somebody else in that community that will coach you through it. It may not be like the creator of the project, but I've seen this happen and go see a lot. where we've had maintainers be like it's a subsystem expert that could fix that in 30 minutes but because this new person comes they're being kind they're obviously research the problem educated they're

like you know what i'm going to help you through this look at this file um so it's somewhere around there if you have questions let me know and you go off and work on it come back and and that's usually a pretty high bar and then by the time you make it a PR that other maintainer could come in and like vouch for you basically um like it's your work but it was you know coached and apprentice to have whatever you want to call it. And that is pretty common, like pretty old school open source, and it works really well still in the right projects. That's literally what happened to me for my, like, I was the person that got help

on my first open source contribution for NeoVim. I was like playing around with some stuff. You could put a separator to put stuff on the left side or the right side of the status line. I was like, well, I kind of want to put something in the middle. Like, what the heck? Search the issues. and I didn't even know anything about Git or GetUp at the time.

But I found one. And I was like, hey, I'd like to work on this. I don't know what to do, basically, like, you know, sort of in a much longer way and nicer. And someone, like, said, hey, you can go check out this file. You can go do this stuff. So I was like, okay, I opened up a PR. That same person came in and helped me in the PR. And then eventually we had, you know, some back and forth from a few other people.

But, like, trying to write tests, trying to explain what I was doing, trying to make sure that like, hey, I don't know how to do the code style things for this. Like, what do you guys do? And then, like, that was my, you know, eventually got merged, like, into NeoVim, and that was my first contribution that I had, which then, like, jump started me doing a bunch of other stuff. But it was literally like, I had a, I didn't even understand what open source was. You know, I was just literally a really dumb college kid who was, like, playing with my

NeoVim config and I wanted my status line to look different. I was like, I don't know. just be nice and try and figure out what can happen. And then like that that worked out really well. And I mean, a lot of ways changed the trajectory of my career as well. Yeah. I had this really, I had this really similar experience in high school where I couldn't get into Rails, but I found this like rail CMS. And I wanted to, they had, they needed, they were asking for help. So I was like, I will do this. And so I came in, guns blazing, made massive, uh, it wasn't, I'd didn't exist yet. So I made match. It was like patch sets. I was emailing around. And this guy

came out and basically like a dad, really felt like a dad, like scold to me. And it was like, whoa, slow down. Like slow down. You're doing too much. We need tests. I had never heard of unit tests. So I remember I wrote a response, probably on the internet anymore. I wrote a response being like, no, I tested it. I opened my browser and it works. I clicked around. It works. And I didn't know a unit test work. That's more than a lot of contributors do. Yeah And I remember him scolding me again And I remember going to school

Because I was still in high school And I was like seething Because I was like, who's this Old man He's getting in the way of stuff that works And I was so mad It's like such a classic teenager Egotistical angst thing

And he ended up teaching me so much I like somehow came around To like calming down And listening to him And breaking it down and he taught me so much and I think I see that a lot too there's so many really talented

now as me being the old man like there's so many talented young people that come into open source guns blazing implementing the most impressive shit but like leaving a path of destruction along the way and not interacting with the community and blah and yeah there's a lot of like soft skills

to mature on and learn about this process all right so a lot of you or I mean everyone here has been in charge of at least for some period of time of a large open source project. And Taylor, you said that you, that you should just create one yourself. Now that you've kind of gone through the process of creating one yourself, have had a lot of success, you know, creating your scene, the troubles and the upsides of it.

Is it even worth it to create these open source things? And I mean that in a genuine sense I'm not trying to meme because like my time running an open source project, 2015, 2016, the amount of, of just like vitriol and annoyance and just made my life demonstrably worse is the reason why I've largely never gone back to open open source I'll do source available but I just don't really want to ever deal with that again and so I've had like a very opposite I guess experience and so I'm just curious like is it really actually something people should all strive for is to create open source projects you know I mean I can only speak from like my experience over the long term there's

definitely been very dark days in open source, right? Where it like literally distracts from like my personal life or like my family life because of negative things people have said about the project, especially in its like nascent years when it was still like growing and it, um, things like that. And it like really got me down. But I think over the long term, you know, like over a period of years, like the people I've met and the things I've gotten to do because of open source, like far outweigh not doing it. At least, you know, for me. Um, And, you know, there's definitely ups and downs, as you said. And sometimes it feels like there's more downs than ups in the short term.

But in the long term, like the places I've gotten to go or the people I've met online and built things together. To me, I think I'll look back on those times with like a lot of fond memories and like gratitude is really some of the best years of my life. So it's been a very positive thing. But yeah, I mean, that being said, it can definitely be a slog and you kind of have to be mentally prepared to like grow some calluses you know like be willing to just like let some mean stuff fall off of you and people say it but overall i think it's it's been a positive thing

Mitchell you're like a chronic open sorcerer you must enjoy this process and obviously by considering everybody here has been doing it for like a decade and you you've just given tips where people are like oh my gosh i've never thought about it this way you've obviously solved some of these problems in your experience? It's probably just a kick. I'm just like the monk that like is just like whipping himself in the mirror. Like it's probably just that. It's not it's not healthy probably. But no, I mean, I like it. I like it. There's a bunch of, there's a bunch of negativity associated with it. But I think I've, you know, I was on the

the commercial close source side like founder CEO thing. And I think Adam and Taylor, I mean, you're all on that side too now. But, you know, it's the pasture is always greener on the other side like you get the same thing on that side sort of like different different ways but um yeah at least like with open source i feel like um you could you could walk away from a lot of things that you can't in the same way when you're on the the corporate side and also uh you are like kind of doing much more i mean you're giving away a lot and that's really cool so yeah yeah i i think depending on what your goals are it can definitely be a good thing to explore, like getting back to, okay, if you want to create better opportunities for finding cool jobs, I think creating open source projects is good for that, especially if you work somewhere where it's hard to sort of show the code that you write or show what you're capable of because everything's closed source and under NDA or whatever, you know, an open source project is something you totally control where you can just like show people exactly how you would do

things if it were up to you, which is really cool in that sense. And then echoing with Taylor said, I think it is a really good way to just sort of like meet new people who are excited and interested in the same things in the sort of sphere of programming. I don't really know any other ways to do it within that sort of hobby. If I compare it to other things I used to be interested in, like open source is almost like replaced what like niche message boards used to be for me for other things that I used to be into where you would meet people and talk about music or whatever, you know? Um, so I think that's just kind of like where you do it now with with programming stuff. Um, I think, I think, I think another, go ahead. No, I, I was just going to say, I think another thing

for me, you know, I think Mitchell and Adam and I and, you know, teach with NeoVim, we've all been lucky that our open source projects are like very widely used and, you know, And tons of people around the world are using them. And I like find it very satisfying and like a big privilege to like, we get to work on tools that people use every day, right? Like I use ghosty every day. I use tailwind every day. I don't use Neof-M every day.

Sorry, teach. Wait, what? Lots of people do. Taylor, you've been lying in our taxes? And it's like this big privilege, you know, to provide these tools that can make people's professional life a little bit more enjoyable. And I find that like a really satisfying, like, thing and something I take like really serious as a privilege like look not many people get to impact

this many people around the world you know in in small ways and like it's really cool that we get to do that and I find that satisfying and fun to work on and like that's why I like still enjoy improving the framework because if I improve Larval it's like this cool way I get to improve people's lives around the world in small ways yeah I feel I felt the same way like when I was making telescope initially for NeoVim and like people were using it and I was really surprised because that one was much more like me versus like I did contributions to NeoVim but that was like in a system that was already there like making telescope was like kind of me by myself and getting messages from people like oh I'm in Japan and I'm using this I'm like what the heck that's

crazy um that's a like very fun part of it and like one difficulty I think is like a caution for people is like allowing yourself to have those like good experiences but then still not like associating yourself so personally with the thing that when someone doesn't like it you're like oh they hate me i'm a bad person right because like when you let it get when you let yourself get like wrapped up emotionally in the project which is fine you got to like still kind of like put up that wall of like yeah i'm not going to please everybody in my project's not for everyone Some people are just going to think, I'm really annoying. Okay, that's okay.

That's just like, it's just life. So that would be one caution I would give to people, like, who are in the open source world or, like, starting their own stuff. It's good to allow some of those nice things that happen, but don't take it too much to heart because there was an angry person at the keyboard on a Wednesday afternoon or something. I mean, we all probably deal with angry people every day. I think a big part of, like, open,

source maturity from a maintainer side is learning how to how to not let that get to you and yeah and there's various strategies but yeah and the you know the bigger you get the the the the weirder also the anger gets but yeah it's it's everywhere all right so it takes a long time in my experience to be able to not let it get under your skin but I do feel like in the last couple years it really doesn't bother me at all the way that I used to so I think I would just like uh sorry you know Sorry, Prime. The other thing I'd say, too, is just like, when, like, open source is in some ways about, like, no expectations in some ways, right? Like, both, like, I'm going to make something.

I can't expect people to use it just because I worked hard on it. Like, if you do that, you're setting yourself up for a bad time. Or, like, when you contribute, that I get a comment back is a blessing from the maintainer's time. Like, they owe me nothing. so like when I send a issue or a contribution or whatever like I think a lot of people they like hear a story and they say oh that person got a job from a successful open source project I'm going to write open source and then I'm going to get one million TC this year baby six months later on one million TC and you're like first off that wasn't the story you heard

but secondly like putting those expectations like on the contributions or the contributors or the maintainers. That's like, I think, where a lot of people take a fast track to having a really bad time. All right. So, Mitchell, you have probably the most unusual group of maintainers. Because as far as I can tell, the Adam and Taylor, they're much more on the website. There's probably a little bit more of an intersection. As far as the technology goes, people who use Larravel are intimately familiar with.

Hailwind, there's going to be a lot of crossover there. But you're in a Zygland in a language that's relatively hot, relatively new. Uh, still not at 1.0 and, you know, even the recent, uh, 15 update, which you said had a really good impact on your build times also required some basic changes throughout the project as well. Uh, I'd used cursor and it actually was able to make something build by just being like, fix it, make it into the new version. And it was awesome. Uh, so what is it, because I only kind of have an idea of how things work in the, in the web world. What is it, what is, what is, I guess, what is maintaining a project on that side? Is it, is it? Is it, what is it? Is it, what is, I guess, what is maintaining a project on that side? Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is it. Is Is it similar? Is there just equally amount of people that just come in hot and angry? Is there more because then everybody's a neck beard and has the ideal way everything should be done? Or I don't know how the feel is of it all. Yeah, it all feels pretty similar.

I mean, I think you get a lot more for sure. I mean, I think in particular goes to being like a Linux desktop application. You get a lot more of the highly opinionated, my blessed setup must be supported kind of ways. I've been on the website as well, and my experience with the website is there's a lot more uniformity in a way. Obviously, there's tons of edge cases you have to deal with, but it's a lot easier to reproduce things. There's generally a lot more uniformity in terms of setups. There's only, like, practically speaking, there's only a handful to a dozen sort of like browser configurations. Correct me if I'm wrong, but this was my experience that I had to really, really care about. There's a long tail of like other stuff. stuff. And I feel like Mac is fine. Mac desktop development totally fine, pretty constrained set, but Linux is a sprawling kind of nightmare. And I'm committed to supporting it because I use it myself. But we recently took a stand, for example, I tweeted some like some tongue-and-cheek version of it, but we just took a stand on input issues because we're just getting so many people

being like, I use this custom keyboard with this custom firmware with like end layer. and when I, and I, and I only speak Russian, but I live in Norway. And when I type this character, this shows up. And it just reached a point where, like, I'm sure that's a real issue. But, like, I'm so burnt out on input bugs on Linux because everything is just so heterogeneous that you need to fix it yourself. Like, the number of people experience this issue is so small. It's you.

So you need to fix it or it's just not going to get fixed. So I think stuff like that is new to me and I'm figuring it out. And then in terms of the actual maintainers themselves, you know, good maintainers don't care too much about the language. So Zig, I would say most of our maintainers have been excited to use Zig, didn't use Zig before, just picked it up to learn it. That's fine. It's more of like you're finding that like systems knowledge type stuff. You know, this is a lower level piece in the stack. And it's been a new community for me, but they've been great.

I built a small tower defense in Zieg, and it was a very enjoyable time in 013. And so I assume it's relatively the exact same language in 015. But I am actually just curious, I know this is going way off topic. You've now built what would be considered a fairly large, now run for enough time to be able to really see kind of what life's like as you make a bunch of changes, as you have to fix a bunch of bugs. How has the process of using Zig Ben on such a large project? Oh, it's been awesome.

I mean, we have to enter, we, we read and integrate with C and C plus plus code all the time as a comparison. And just from there, building and understanding and maintaining, it's just a totally different level. And there's, you know, most of the maintainers in our group are also like professional C programmers. And so these aren't amateurs. We're like, we're trying, you know, we read Chrome Firefox and WebKit source code all the time because basically, browsers solved font rendering. And so any sort of font rendering issues, we learn from browsers. And so we're reading that all the time.

And it's good code. Honestly, all of those are the highest quality C&C plus you're going to find. And it's incredible how difficult it is to read that compared to the equivalent ZIG. So I think that Zieg's been hugely successful for us. Each minor release, which is a pretty major release for Zig, 0.12, we started pre-0.10. And so we've done 0.10, 11, 12, 13, 14, 15 now. Each one is significant. 0.15 took me about three weeks.

And that was after a maintainer already spent another three weeks making it all work. But because of the seriousness of the changes, I had to redo it all myself. I trust them, but like I just have to understand it myself. So I went and redid it. And I was able to hit roadblocks and just copy from theirs and be like, oh, they figured it out for me, nice. And then learned something. And it still took me three weeks. and so that's like I think I've said this for I still think Zig is too early for like you know a company to use it reliably for a product like that would be kind of a waste of time for a startup to be doing but I think it's heading in the right direction and I love it

all right well do we have any final words on open source anybody have anything else you want to contribute to on contributing the right way to open source it's October baby I was we were talking about it before you came on from of like well this was what i was thinking to will l l lm's in the future when it's october be more likely to create read me updates because of the source training data because they have the system prompt at the time just like how it gets lazier in the summer especially if it's quad uh they will they also have this problem that forever in perpetuity october will be documentation update month for l lms they refuse to do any other work the old October surprise, I believe, is what they call that. It's a different context, actually, but yes.

Oh, okay. I mean, I think it's a whole topic, but I think it's a whole topic, but I mean, I think there's a whole new frontier. I would actually be really curious how Adam and Taylor are receiving this, but there's a whole new frontier of like contributing with LLMs in your toolkit. and that's like changing a lot of my viewpoints on on how to be a good contributor. I don't think I've seen any LLM-driven PRs to our stuff yet, honestly. Wow.

Really? You don't get like the PRs with like they all have the same basic initial comment, the same format. Maybe they do something. The header is in every single sentence. Yeah, the bullet points are all the same. If you're submitting a PR with AI and you don't, want to get caught at least tell it no emojis like I get them every day I get several a day

actually really you want a day at least I you know it's funny Taylor's you said earlier that you new contributors you look at their GitHub repos and stuff I do the same thing I like kind of like you know like Doc GitHub docs them a little bit and try figure out what they're about where they work and what they're doing why they're contributing or whatever and the quickest way that I'm like oh this is going to be some this is going to be some slop is you find mine like a ton of AI, like crap. And I'm not anti-AI. I gotta say that.

I'm not anti-A-I. I literally spend like $25 a day in AMP tokens. I love it. But yeah, there's some bad stuff out there. Yeah, if I'm not mistaken, you're the one that convinced me to re-give a in-line auto-complete another shot and using Super Maven since the end. Oh, cool.

I didn't know that. Yeah, yeah, yeah, because you said that you just do not think that any developer should ever not at least have that. You said something along the line that was exceptionally, what's it called, very, like, strong stance. Yeah, yeah, I remember that. Emphatic. That was the word I was looking for. I remember that. And I'm actually really sad because tab complete and inline complete hasn't been down in like a very long time. And it's really nice when it's down because that's when I close my laptop and don't work for the day. So, yeah,

if like co-pilot or like more of those could go down, that'd be sweet. I'm interested to hear more about like and Mitchell you too because I know you both have been talking about it like someone submits a PR it you're pretty sure it's AI or like not not and not like oh they carefully walked through an agent workflow over 10 hours and did all of it but like uh you know fix this for me big bug number seven

and then just like well I did it what like what's the workflow for that What would be like the better way for someone to try and if they're using LLMs to do that? Like, what are your thoughts there? For me, the best experiences I've had with Slop in particular is if you're honest that you have no idea what's going on. If someone throws a PR up, and this has happened like once a week probably where they say, I used whatever, codex, Claudecote Code to fix this bug. I don't know Zig. I don't know anything that it did.

but I'm just sharing it with you. That's actually helpful because I don't need to do like a deep review. I could just look at it and like get a quick like, this is heading in the right direction, interesting. Or I could be like, okay, thanks. This looks pretty bad. I'm going to close it. Glad it works for you or whatever.

The problem is when people post slop and they're like really serious about confident about that they should be merged and be fixed. And so from the slop angle, that's what I would say. And so we require AI disclosure in our project, but that's part of the reason. Do you actually get people that do AI disclosure? disclosure? Like, do they actually, does everybody do it? Or have you, like, caught somebody? And they're like, wait a second. That argument's all goofy and it's ordering. I know you,

you slop. And then like, dang it. You got me. Like, yeah, I want to hear Rick Taylor has to say, but I'll say on that point, um, it's been really successful. I would say we catch probably like one or two people a week that don't disclose. But also, I think everybody except one person, uh, it just was an accident. They're like, oh, I didn't read that. Yeah, here it is. Um, but there was one person that super tried to hide it. And I eventually got, you can find it on. I, I eventually got to the point where I'm like, I'm just going to, like, this is not productive. If you can't be honest about your AI usage, I can't trust literally anything else you're doing. So I'm just going to close this.

Yeah, we get quite a bit of noise. And I mean, I can echo what Mitchell says about, like, it's helpful if they tell me they're using AI because I want to know their confidence in what they're submitting. A lot of times it feels like they're just like shooting in the dark. And honestly, what I'm seeing a lot lately is like refactoring PRs. where it looks like what has happened is the contributor has like fired up Claude Code and been like, find a refactoring opportunity in the ORM of Larval and just let it come up with some random refactoring

and they've then submitted that PR. Like that's what it feels like is happening on a fairly regular basis. Which is, you know, I don't know. It's not super helpful and probably not how I would go about contributing to open source. Taylor, say it how you really feel. No one's even listening. It's fine. There's nobody out here.

Fuck those people. Yeah. You know what? There we go, Adam. Yeah, I don't know. I action PRs really quickly. So I have to action like 20 PRs a day or they're going to get ahead of me. And so like I just really quickly close those.

You know, like it's not even a second thought. Because I just don't have time to really mess with it. Yeah. No, there is something to that where, I mean, on the inverse side for those that are making PR is just simply making making a PR because the home person came I'm going to drop. See you, Mitchell. Thanks, dude. See ya. All right, Mitchell has to drop. He had someone coming over

to his house to do some fixing and so he pre-warned us that it was going to happen at any moment. So he's gone. All right, uh, I there is something to be said on the inverse side, which is if you're attempting to contribute to open source and you want to fix something, you don't know how to get started

and you do just simply follow whatever the LLM says. You don't actually take the time to look at like why, are the things in place. You don't debug your way through print effort, whatever you do. It is like you are wasting someone else's time. I think there's something big to that because it's going to take a big hit to your credibility.

Like if you do that enough times, it's going to be, you're going to like ruin your relationships with people. If you do it one time. That's your first impression. That is your first impression. It's like a thousand times more impactful. If it's the first thing you submit to repo is,

I don't know what this does and I'm going to pretend that I do. I will never trust you again. True. See, the thing is, that I have Began who also submits a bunch of what's it called AI Generate stuff, but I love Began and so I let it slide even though I'm like, stop it,

Biggin, stop it. Just a thought. So, Taylor, you're saying you're seeing this a lot, though? Oh, yeah, every day, for sure. And the range is like, for you, is it most of them are just like this random refactor thing, or is it

like we're associated with an issue? Like, I'm kind of interested in sort of this distribution. It's a lot of the late here. lately over the last few months, it's a lot of the random refactoring. And the PR title will literally be refactor X, you know. And there will be no like bug that is being fixed or no like performance improvement. It's just like code organization or like method extraction or just some random thing like that. That it just doesn't really have any net benefit.

And like if the code's already working, why would I merge this when this has the potential to make it not work anymore? You know, like, yeah. Yeah. That is, that is kind of a bizarre thing to do because I guess I've been around software long enough to know that drive-by refactors almost exclusively just end in sadness. And so it just seems like a weird way to try to like meet somebody for the first time and also be like, I rewrote part of your code. Oh, would you get me? Nothing. I just made it different.

You're like, I don't know if I like, like, how does that trade-off? Like, how does that trade-off even exist where you're like, this is a good idea? This is a good place to start a relationship on. I mean, my guess is people want to be able to put I refactored Laravel code into a resume and try and leverage that to get a job. Like, that would be my assumption. I think it's just kind of like a bit of sort of like a thing that people who are maybe a bit less experienced, a bit more junior care about, you know, like when you're early in your career and just this idea of writing perfect code, it just sounds so fun. or you've read some blog post that gave you some rules about how long your methods are supposed to be or whatever, you know. Three to four lines.

Yeah. Yeah. I just looked at this week, I've gotten eight refactor PRs so far. Whoa. That is so many. Any PR that has the word single responsibility principle in it is closed. That's auto close. I'll be right back.

Yeah. That's auto close. Yeah. I think that's why we have agents for that now. Yeah. just monitor. Sometimes I wonder if people like overvalue contributing a random PR to like something like Larval or Tailwind versus just creating something of your own like Adams.

So like to me that's like 10x or 20x cooler than like I got a random refactor PR merged into Larval in 2016. You know like I don't know. And it's like half the reason why people like you and I invest so much effort into making sure the things we build are like extensible. from exactly because that avoids all sorts of PRs coming our way it lets people test out ideas using our sort of integration points which we honestly usually try to make as like extremely open and flexible as possible and it's a good it's good for us because we can say you know what

I'm not ready to like merge this go build it as like package or as a plug in or whatever and people can go and do that we have these cool tools called package managers that let you like bring in other code into your project, you know, which is super cool. I'm calling Ginger Bill. Yeah, I know. Some people don't think they're good. Yeah. Yeah, that's right, Taylor.

Package managers are evil. Yeah. Mitchell doesn't like packages very much either. Oh, man. Missed. We had the same thing for NeoVim, which was like, you know, obviously lots of extensibility things.

And there's been a lot of things that basically took a lot of time to mature and iterate on a separate, you know, feedback loop as, like, external repo that eventually get merged into NeoBimcore. And I think that's a way better strategy too. If you're like, oh, there's this big thing that Larval needs or something, right? Go and build like the external version of that. iterate, iterate, iterate, iterate, iterate, not on the release schedule and with the

same requirements as Larval has, right? And then you can come back later and see it. I literally have a GitHub saved response that says exactly that, basically. you should go build this as a package and see if it gets traction and then come back you know yeah yeah and that's been super successful especially like i think the thing people don't get which is like the other message for contributors that is important to hear is like most of these like open source repos do not have like a Microsoft level triage team where they have you know like five people on staff to read issues full time, right? Where it's like, oh, we're Microsoft's budget for VS code is like

multiple millions of dollars per a year, right? And so yeah, that's fine. You can just like, oh, they want to have a built-in package manager that does all of this stuff and whatever. Cool. They can put a few engineers on that and spend several million dollars. But like your random open source repo does not have that same capability or budget to like solve those things. So, you know, like Taylor, I know you feel it all the time, I'm sure of. I cannot maintain this forever, like you said before. I cannot be the one where this is my thing for the rest of my life. I don't want to spend all of my life writing a Laravel package manager or something.

Right. We have Composer. He did build a Larval package manager. That is true. Before Composer existed. Oh. And then you got to delete it. Yeah, pretty much.

Yeah. That feels good. Better. SPR. Mm-hmm. All right. Well, thank you, everybody, for being here. I think we got to wrap this up.

We got to wrap this up. Yeah. That sounds good. We've got seven-year-olds to kill him Fortnite. Nice. Yeah, yeah. Nice. By the way, we do have to do a DHH-F Fortnite something at some point soon because it would be so funny.

Programmer Fortnite tournament. That's what it's feeling like. E-sports. I don't know about tournament. We're casual. That whole tournament word kind of hurts me. Oh, just like with. With programmers only.

With programmers with kids only. There you go. Yeah. Now we're talking. How we're talking. At least two as well. Yeah. All right.

Well, thank you everybody for joining of we had Mitchell Hashimoto, creator of ghosty and many other open source things. Taylor Otwell, creator of Larval. Taylor, is there anywhere we can find you that you want to give a shout out of it for? Larval.com, baby. I don't know.

X.com. slash Taylor Outwell. Nice. Let's go. And how about you? Adam? Adam is the creator of tailwind and also a very handsome dude.

And we'll probably, and it has the ability to beat me up. He looks, he's very fit man. Taylor, where can people find you? Besides for the gym. I mean Adam.

Sorry, Adam. Yeah, the gym. Please don't beat me up for the mistake. No, just probably on Twitter, X, whatever,

X.com slash Adam Wadden. That's where I hang out the most. Awesome. And finally, TJ, the man, the myth, the legend, I just want to be Teage, I want to code, I want to dance, I don't want to go home. Oh, yeah. Where can people find you, TJ? Teage DV, everywhere, basically, except GitHub, but I don't want you to find my GitHub anyways. So take that, chat. Got them. Boot up the day.

Vibos and errors on my screen. Terminal coffee. Inhale