is AI ruining opensource? (Lost episode)

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.

• 0:00Speaker 00

  Alright, alright, here, let me do a nice little intro.

• 0:06Speaker 00

  Uh, anyways, I'm sorry. Alright, 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 Laravel, and Mitchell, creator of many, many things, most recently Ghosty, a super fantastic terminal in which was featured in OpenAI, a video just recently, if I'm not mistaken?

• 0:35Speaker 01

  Yeah, yeah.

• 0:36Speaker 00

  That is, that is pretty dang awesome, alright. 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 says "update read me", and then has somebody's name, or the name of the video, as the only contribution. And so, you know, this has 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

• 1:18Speaker 00

  project, like NoJS, or just pick your favorite project, there's probably quite a few of them. Uh, 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 of 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.

• 1:58Speaker 01

  Yeah, yeah, yeah. It's good to be back and, uh, and, uh, 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. Um, but yeah, I, I think

• 2:09Speaker 01

  I, there's so, 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, um, figure out what they're about, figure out like the things they care about, figure out the, the vibes of how they're, um, just observe, just sit there and observe for a little while. And then after that, make a small change. Um, you know, it's, it's really hard, you know, open source is 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, ah, they'll follow up if it's not perfect anyway.

• 2:47Speaker 01

  And they've shown that they've, they do pretty good stuff. But if you just like 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, uh, and try to focus on like fixing bugs or something. I actually, there was like, I don't know if 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, 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, um, don't do any of that. Like it's kind of just noise that doesn't matter that much. Um, so.

• 3:28Speaker 02

  Refactor things.

• 3:30Speaker 01

  Never refactor things, almost ever, even if you're a really serious contributor. Um, yeah, uh, that's, that's, I think that's my like the big picture, but there are just so many angles to it.

• 3:39Speaker 00

  Whether you're a vibe coder or a handcrafted free range Neo Vim user, you still need CI to be able to build your binaries, run your tests 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 Tej Refactor DV.

• 4:24Speaker 00

  Lee Lee is a big, big fan of it.

• 4:25Speaker 03

  Well, I mean, you miss 100% of the shots you don't take. So if you, you gotta shoot for a refactor if you need one. Uh, 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. Uh, and so like, if you think, oh, well, I know better. I'm gonna write this in a new way. That wasn't the way it was before. You're likely gonna 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. Um, or you just end up in a worse spot that doesn't handle the 37 edge cases that were there

• 5:05Speaker 03

  before. Um, or like some other existing thing like for Neo Vim, we had this sometimes where people are 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 Vim. 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, a big refactor, as like an early thing of

• 5:47Speaker 03

  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.

• 5:59Speaker 00

  Anybody else? Taylor? You, you've been running an open source project for just a couple of years now, right?

• 6:05Speaker 04

  Yeah.

• 6:05Speaker 00

  Couple of 20 or something like that? I can't remember.

• 6:08Speaker 04

  Yeah. Yeah. Gosh. I mean, a lot of stuff comes to mind. Like some of the, the first things that come to mind are, one thing we actually have in our, um, Laravel 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 where the code is structured, or the, where the method is even put, you know, in the codebase. Sometimes it's 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 pull requests are things that like, maybe add five lines of code, but unlock like...

• 6:49Speaker 04

  Really like tons of developer power or like a really great new feature 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 Laravel come from just like people watching other people make PRs and they see one feature come in and they're like, oh, I that caused me to have this idea of it, wouldn't it be neat if this had this feature and like it wasn't

• 7:32Speaker 04

  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 for 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 Basecamp and all of that. Yeah, so that's a couple of quick things that come to mind.

• 8:00Speaker 00

  I would assume you get a lot more PRs for Laravel. This is just me completely assuming in a vacuum here, 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, spelunking through and try to figure it out, whereas Adam Watham, I assume Tailwind's codebase versus the people with whom they serve are very, very far away camps.

• 8:23Speaker 02

  Yeah.

• 8:24Speaker 00

  Meaning that you don't.

• 8:25Speaker 02

  Yeah, we don't get a lot of contributions really because of that.

• 8:28Speaker 03

  You're looking for more readme updates then? Is that the call that we're hearing right now?

• 8:33Speaker 02

  Yes, more readme 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.

• 9:00Speaker 02

  But new features, I generally, generally feel like a chore 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, not a good first PR, I don't think. Kind of earn the maintainers' 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 that like,

• 9:40Speaker 02

  oh, I actually like understand how this stuff works and why things work this way and whatever. So.

• 9:47Speaker 00

  So what you're really trying to say, if I'm not mistaken, is you wanted to recreate the Stack Overflow feeling where you get a certain, you get like a base level and you can only comment. And then through enough comments and upvotes, you can then gain more and more power. So we just want to recreate that, but with GitHub.

• 10:03Speaker 03

  A GitHub social credit score. I see where this is going.

• 10:06Speaker 00

  Yeah, but it would be a per repo social credit score.

• 10:10Speaker 03

  The, the thing too, Adam, with what you're saying, I feel like if people are like in the community and they're gonna 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 tracker, discussions, kind of like, oh, I feel like we really need like XYZ, what do you think? And then you discuss for on the say, okay, cool, I'll submit a PR. Not like out of the blue, no, 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.

• 10:56Speaker 03

  And then get a lot of feedback like before any code gets submitted.

• 11:00Speaker 02

  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 a little 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.

• 11:23Speaker 04

  One thing I've felt difficult about these PRs is like, someone, someone asked me like,

• 11:30Speaker 04

  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?

• 11:54Speaker 01

  Yeah, we, uh, that's why we, we have this policy like in Ghosty and it's in our contributors doc where like a PR has to be, has to close an issue. 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 associate issue, you're still welcome to open a PR. But exactly what Adam said, it, there's a sentence in there that says something like, I might review it in a week, a month, 10 years.

• 12:38Speaker 01

  Never, 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, um, I think what Taylor was getting at was like a lot of features, it that the actual like business logic isn't hard. What's hard is like the last mile taste of how that feature could expose, gets exposed to users. And, and I don't, I don't trust a lot of people with taste. And so, um, 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 shedding in the discussion.

• 13:19Speaker 01

  Um, and a lot of the bike shedding in the discussion is literally about, I don't care how you're going to influence, 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? Like, it's just that stuff, because then you could get the rest working and you could like.

• 13:34Speaker 02

  It kind of reminds me of like, uh, isn't it like a famous like Amazon thing or something where like every like new projects? That was like, write the press release first, you know?

• 13:44Speaker 00

  Hmm.

• 13:45Speaker 02

  And, but yeah. So with the way that you guys do things, Mitchell, if you are the only ones who can know my 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.

• 14:06Speaker 01

  If it's bad enough, I'm gonna hear about it. But, um, uh, 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. Um, there's probably two dozen of those people, like significantly more. And they just have triage permissions on the GitHub repo, um, and, and Discord communities and stuff, and they're awesome. Um, and they, they, they tag stuff, label stuff for us. Um, they answer a lot of Q and A and close it. And, um, yeah, it's, it's a cool role. So that's sort of how we, we look at that stuff.

• 14:46Speaker 02

  How do you, uh? That might steal that.

• 14:48Speaker 03

  Yeah.

• 14:48Speaker 01

  I was thinking that.

• 14:50Speaker 03

  Sorry. Yeah. How do you convince or like bring people on for like the triage role? Cause 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?

• 15:05Speaker 01

  It's like, I think it's open source and it's pure sense. It's these people just appear, they start by not having that role, but they're answering questions and contributing really well to these discussions. And, um, usually it's other helpers and maintainers that recognize these people. Um, I'm the only person that could actually like assign people roles. So it eventually just gets bubbled up and, 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 yep.

• 15:40Speaker 00

  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, you know, there's especially in many videos and many discussions about this saying, hey, don't, you know, 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 means. So there's kind of like this competing conflict of don't do it, but also dream jobs over here with people doing it.

• 16:25Speaker 00

  So they, you know, there's definitely a preserve.

• 16:27Speaker 02

  Yeah, I think, 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 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

• 17:05Speaker 02

  that are 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 PRs for more substantial.

• 17:33Speaker 02

  Features or things that people are going to benefit from other than like fixes and performance improvements and stuff like that.

• 17:39Speaker 04

  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 readme setup, 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 of PRs that are like sort of in 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 Largely's open source team is just

• 18:22Speaker 04

  like these intangible taste type things of like.

• 18:25Speaker 02

  Yeah, the readme is almost always like more high stakes than the code. When I'm like reviewing open source.

• 18:32Speaker 04

  Yeah, can you write well? Can you, can you explain this? Well, you know, I mean, that is valuable too.

• 18:37Speaker 01

  Oh, I'll come at it 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, 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 like 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

• 19:21Speaker 01

  coach you through it. It may not be like the creator of the project, but I, I've seen this happen in GoSee 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 researched the problem educated. They're like, you know what, I'm going to help you through this. Look at this file, it's somewhere around there. If you have questions, let me know. And you know, 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. Like it's your work, but it was coached and apprenticed to however you want to call it. And that is pretty common, like pretty old school open source.

• 20:04Speaker 01

  And it, and it works really well still in the right projects.

• 20:07Speaker 03

  That's, 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 GitHub 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.

• 20:50Speaker 03

  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, I'll just be nice and like try and figure out what can happen. And then like that, that worked out really well.

• 21:34Speaker 03

  And I mean, a lot of ways changed the trajectory of my career as well. Yeah.

• 21:39Speaker 01

  I had this really, uh, 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 hadn't, 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, there wasn't, it didn't exist yet. So I made matches, like patch sets I was emailing around. And this guy, uh, came out and basically like, like a dad, really felt like a dad, like scolded me and 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 somewhere. I wrote a response being like, no, I tested it. I opened my browser and it works. I clicked around, it works. And, and I didn't know.

• 22:24Speaker 02

  That's more than a lot of contributors do.

• 22:26Speaker 01

  Yeah. And, 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 getting in the way of stuff that works? And I was so mad. It's like such a classic teenager egotistical angst thing. And, uh, he ended up teaching me so much. I, I, 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, um, 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,

• 23:10Speaker 01

  but like leaving a path of destruction along the way and not interacting with the community and blah, blah. And, uh, and yeah, there's a, there's a lot of like soft skills to mature on and learn about this process.

• 23:22Speaker 00

  All right. So a lot of you are, I mean, everyone here has been in charge of at least for some period of time of a large open source product, uh, 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 yours, seeing 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 mean because like my time running an open source project. 2015, 2016, uh, the amount of just like vitriol and annoyance and just made my life demonstrably worse.

• 24:02Speaker 00

  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.

• 24:22Speaker 04

  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 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. And, uh, you know, I, there's definitely ups and downs, as you said, and sometimes it feels like there's more downs than ups. Um, in the short term, but in the long term, like

• 25:05Speaker 04

  the places I've gotten to go or the people I've met online and built things together. To me, I'll, 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, and 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.

• 25:35Speaker 00

  Mitchell, you're like a chronic open sourcer. Uh, you must, you, you must enjoy this process. And obviously, by the way, 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.

• 25:56Speaker 01

  It's probably just a kick. I'm just like the monk that like is just like the whipping himself in the mirror. Like it's probably just that. It's not, it's not healthy, probably.

• 26:07Speaker 01

  But no, I mean, I like it. I like it. There's a bunch of negativity associated with it. But I think I was on the commercial closed 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, 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 yeah, at least like with open source, I feel like you could, you could walk away from a lot of things that you can't in the same way when you're on the corporate side. And also you are like kind of doing much more, I mean, you're giving away a lot. And then that's really cool. So, yeah.

• 26:47Speaker 02

  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 what Taylor said, I think it is a really good way to

• 27:25Speaker 02

  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, you know? Like 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? So I think that's just kind of like where you do it now with, with programming stuff.

• 28:01Speaker 04

  I think, I think another, yeah, go ahead.

• 28:04Speaker 02

  No.

• 28:05Speaker 04

  Oh, I was just gonna say, I think another thing for me, you know, I think Mitchell and Adam and I, and you know, Tej with Neo Vim. We've all been lucky that our open source projects are like very widely used and you know, 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 Ghostie every day. I use Tailwind every day. Um, I don't use NeoVim every day, sorry, Tej.

• 28:31Speaker 03

  Wait, what?

• 28:32Speaker 04

  Lots of people do.

• 28:33Speaker 03

  Taylor, you've been lying in our taxes.

• 28:37Speaker 04

  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, 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, and 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 Laravel, it's like this cool way I get to improve people's lives around the world in small ways.

• 29:12Speaker 03

  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, uh, good experiences, but then still not

• 29:53Speaker 03

  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. Ah, right? Cause like, when you let it get, when you let yourself get like wrapped up emotionally in the project, which is fine, you gotta like, still kind of like put up that wall of like, yeah, I'm not going to please everybody and my project's not for everyone. Some people are just going to think, I'm really annoying. Okay. That, that's okay. That's just like, that's just life. Um, 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 is like, it's good to allow some of those nice things to happen, but don't, don't take it too much to heart because there was an angry person at the keyboard on a Wednesday afternoon or something.

• 30:39Speaker 01

  I mean, we all probably deal with angry people every day. I think a big part of like,

• 30:44Speaker 01

  an open source maturity from a maintainer side is learning how to not let that get to you.

• 30:49Speaker 02

  Yeah.

• 30:49Speaker 01

  And there's various strategies, but yeah, and the bigger you get, the weirder also the anger gets. But yeah, it's everywhere.

• 30:59Speaker 02

  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 of years, it really doesn't bother me at all the way that I used to.

• 31:13Speaker 03

  The other thing I would just like, 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 gonna 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 an 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.

• 31:56Speaker 03

  I'm gonna write open source and then I'm gonna get 1 million TC this year, baby. Six months later, I'm 1 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.

• 32:19Speaker 00

  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 Laravel are intimately familiar with Tailwind. There's gonna be a lot of crossover there, but you're in a Zigland in a language that's relatively hot, relatively new, still not at 1.0. And you know, even the recent 15 update, which you said had a really good impact on your build times, also required some basic changes throughout the project as well. 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. So what is?

• 33:03Speaker 00

  Because I only kind of have an idea of how things work in the in the web world. What is it? What is, I guess, what is maintaining a project on that side? Is it? 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 neckbeard and has the ideal way everything should be done? Or like, I don't know how the feel is of it all.

• 33:25Speaker 01

  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. You know, 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 there's tons of like 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 like 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.

• 34:09Speaker 01

  There's a long tail of like other stuff and I feel like Mac is fine. Mac desktop development totally fine, pretty constrained set, but Linux is is a sprawling kind of nightmare. And I'm committed to supporting it because I use it myself. But we recently like took a stand, for example, with I tweeted some like some tongue in 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 N layers. And when I and this and I and I only speak Russian, but I live in Norway. And when I type this character, this shows up and and it just reached a point where like, I'm sure that's a real issue.

• 34:51Speaker 01

  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 experiencing 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 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, and that's been, it's been a new community for me, but they've been great.

• 35:37Speaker 00

  I built a small tower defense in Zig and it was a very enjoyable time in 0.13. And so I assume it's, it's relatively the exact same language in 0.15. 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 been on such a large project?

• 36:04Speaker 01

  Oh, it's, it's been awesome. I know we have to enter, we, we read and integrate with C and C++ code all the time as a comparison and just from their 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, 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, and it's, it's good code. Honestly, all of those are the highest quality C and C++ you're going to find. And it's incredible how difficult it is to

• 36:49Speaker 01

  read that compared to the equivalent Zig. So I think that Zig's been hugely successful for us. Each, each minor release, which was 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. And each one is, is significant. 0.15 took, took me about three weeks. And that was after a maintainer already spent another three weeks making it all work. But because of the 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 learn something.

• 37:29Speaker 01

  And it still took me three weeks. And so that's like, I think I've said this before, 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.

• 37:48Speaker 00

  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?

• 37:58Speaker 03

  It's October, baby.

• 38:02Speaker 03

  I was laughing. We were talking about it before you came on prime of like, well, this was what I was thinking too. Will L L M's in the future, when it's October, be more likely to create read me updates because of the source training data? Cause they have the system prompt at the time, just like how it gets lazier in the summer, especially if it's Claude. They will, they also have this problem that forever and perpetuity. October will be documentation update month for L L M's. They refuse to do any other work.

• 38:33Speaker 00

  The old October surprise, I believe is what they call that.

• 38:37Speaker 03

  It's a different context, actually, but yes.

• 38:39Speaker 00

  Oh, okay.

• 38:41Speaker 00

  Actually, I

• 38:42Speaker 01

  I mean, I think it's a whole topic, but I, I think it's a whole topic, but I mean, I think, I think there's a whole new frontier. And I would actually be really curious how Adam and Taylor are, are receiving this, but there's a whole new frontier of like, contributing with L L M's in your toolkit. And that's like changing a lot of my viewpoints on, on how to be a good contributor. Yeah.

• 39:06Speaker 00

  We should, we should talk about that.

• 39:09Speaker 02

  LLM driven PRs to our stuff yet, honestly.

• 39:14Speaker 03

  Wow.

• 39:15Speaker 04

  Really? You don't get like the PRs with like they all have the same basic um initial comment, the same format?

• 39:21Speaker 01

  The header is the emoji.

• 39:24Speaker 04

  Yeah, the bullet points are all the same.

• 39:25Speaker 03

  You guys, if you're submitting a PR with AI and you don't want to get caught, at least tell it no emojis. Like, not be having each line be an emoji.

• 39:33Speaker 04

  I get them every day. I get several a day, actually.

• 39:35Speaker 01

  Really? I want a day at least. You know what's funny, Taylor, is 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 to figure out what they're about, or 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 gonna be some, this is gonna be some slop, is you find like a ton of AI, like crap. And I'm not anti-AI, I gotta say that. I'm not anti-AI. I literally spend like $25 a day in AMP tokens. I love it, but um, yeah, there's some bad stuff out there.

• 40:12Speaker 00

  Yeah, if I'm not mistaken, you're the one that convinced me to re-give a inline autocomplete another shot. Been using Super Maven since then.

• 40:20Speaker 01

  Oh, cool. I didn't know that.

• 40:21Speaker 00

  Yeah, yeah, yeah, because you said that you can't, you just do not think that any developer should ever not at least have that. You said something along the line that was exceptionally, uh, what's it called? Um, very, like, strong-anced.

• 40:35Speaker 01

  Yeah, yeah, I remember that.

• 40:37Speaker 00

  Emphatic. That was the word I was looking for.

• 40:39Speaker 01

  I remember that. And I'm actually really sad because a 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 you like, that's when I close my laptop and don't, don't work for the day. Um, so, yeah, if like Copilot or like more of those could go down, that'd be sweet.

• 40:57Speaker 03

  Taylor, I'm interested to hear more about like, and, 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?

• 41:35Speaker 01

  For me, the best experiences I've had with 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 Claude 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 gonna 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.

• 42:17Speaker 01

  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.

• 42:24Speaker 00

  Do you actually get people that do AI 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 use Slop and I'm like, dang it, you got me like.

• 42:37Speaker 01

  Yeah, I want to hear what Taylor has to say, but I'll say on that point, 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. It just was an accident. They're like, oh, I didn't read that. Yeah, here it is. But there was one person that super tried to hide it and I eventually got, you could find it on, I eventually got to the point where I'm like, I'm just gonna 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 gonna close this.

• 43:05Speaker 04

  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 Laravel and just let it come up with some random refactoring. And they've then submitted that PR like that's, that's what it feels like is happening on a regular, fairly regular basis.

• 43:46Speaker 04

  Um, which is, you know, I don't know. It's not super helpful. Um, and probably not how I would go about contributing to open source.

• 43:55Speaker 00

  Taylor, say it how you really feel. No one's even listening. It's fine. There's nobody out here.

• 44:00Speaker 02

  Fuck those people.

• 44:01Speaker 00

  Yeah.

• 44:01Speaker 02

  You know.

• 44:02Speaker 00

  There we go, Adam.

• 44:03Speaker 04

  Yeah, I don't know. I action PRs really quickly. So I have, I have to action like 20 PRs a day or they're gonna get ahead of me. And so like, I just really quickly close those, you know, like it's not even a second thought, uh, cause I just don't have time to really, uh, mess with it.

• 44:20Speaker 00

  Yeah. No, there is something to that where, I mean, on the inverse side, for those that are making PRs, just simply making a PR.

• 44:26Speaker 01

  The home person came. I'm gonna drop.

• 44:29Speaker 04

  See you, Mitchell.

• 44:30Speaker 02

  Thanks, dude. See ya.

• 44:32Speaker 00

  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 gonna happen at any moment. So he is, 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, open source, and you wanna 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, printf it, whatever you do. Uh, it is like, you are wasting someone else's time. And I think there's something big to that because it's gonna take a big hit to your credibility. Like, if you do that enough times, it's gonna be, you're gonna like ruin your relationships with people.

• 45:11Speaker 03

  If you do it one time, because that's your first impression.

• 45:14Speaker 00

  That is your first impression.

• 45:15Speaker 03

  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 gonna pretend that I do, I will never trust you again.

• 45:24Speaker 00

  True. See, the thing is, is that I have Bacon who also submits a bunch of, uh, what's it called?

• 45:28Speaker 03

  We know him though.

• 45:29Speaker 00

  But I love Bacon and so I let it slide, even though I'm like, stop it, Bacon. Stop it. Just a thought.

• 45:35Speaker 03

  Yeah, so Taylor, you're saying you're seeing this a lot, though?

• 45:37Speaker 04

  Oh, yeah, every day, for sure.

• 45:40Speaker 03

  And the range is like for you, is it most of them are just like this random refactor thing, or is it like for associated with an issue like I'm kind of interested in sort of this.

• 45:53Speaker 04

  It's a lot of the lately, lately over the last few months, it's a lot of the random refactoring and it will 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?

• 46:24Speaker 00

  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, what'd you get me? Nothing. I just made it different. You're like, I don't know if I liked like, how is 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.

• 46:54Speaker 03

  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.

• 47:06Speaker 02

  I think it's just kind of like sort of like a thing that people who are maybe a bit less experienced or 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 posts that gave you some rules about how long your methods are supposed to be or whatever, you know?

• 47:33Speaker 02

  Yeah.

• 47:33Speaker 04

  Yeah, I just looked and this week I've gotten eight refactor PRs so far.

• 47:38Speaker 00

  Wow.

• 47:39Speaker 04

  But like.

• 47:40Speaker 02

  And any PR that has the word single responsibility principle in it is closed.

• 47:44Speaker 04

  That's auto close.

• 47:45Speaker 00

  I'll be right back.

• 47:46Speaker 04

  That's auto close.

• 47:47Speaker 02

  Yeah.

• 47:48Speaker 04

  I think like.

• 47:49Speaker 02

  That's why we have, we have agents for that now.

• 47:52Speaker 04

  Yeah.

• 47:52Speaker 02

  Just monitor.

• 47:53Speaker 04

  Sometimes I wonder if people like overvalue contributing a random PR to like something like Laravel or Tailwind versus just creating something of your own like Adam. So like to me, that's like 10x or 20x cooler than like, I got a random refactor PR merged into Laravel in 2016, you know, like.

• 48:14Speaker 02

  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.

• 48:22Speaker 04

  Exactly.

• 48:24Speaker 02

  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 a package or as a plugin or whatever. And people can go and do that.

• 48:48Speaker 04

  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.

• 48:53Speaker 03

  I'm calling Ginger Bill.

• 48:54Speaker 00

  Yeah, I know. Some people don't think they're good. Yeah. Yeah, that's right, Taylor. Package managers are evil.

• 48:59Speaker 03

  Yeah.

• 49:00Speaker 02

  Mitchell doesn't like packages very much either, but.

• 49:04Speaker 03

  Missed. Uh, we had the same thing for, 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 a like external repo that eventually get merged into NeoVim core. And like, I think that's a way better strategy too. If you're like, oh, there's this big thing that Laravel 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 Laravel has, right? And then you can come back later and see.

• 49:46Speaker 04

  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?

• 49:55Speaker 03

  Yeah.

• 49:56Speaker 02

  Yeah.

• 49:57Speaker 03

  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 year", right? And so, yeah, that's fine, you can just like, "Oh, they wanna 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,

• 50:42Speaker 03

  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 wanna spend all of my life writing a Laravel package manager or something, right? We have Composer!

• 51:05Speaker 02

  He did build a Laravel package manager-

• 51:08Speaker 04

  That is true.

• 51:09Speaker 02

  Before Composer existed.

• 51:11Speaker 03

  Oh, and then you got to delete it!

• 51:14Speaker 04

  Yeah, pretty much.

• 51:15Speaker 03

  Yes, even better, SPR.

• 51:18Speaker 00

  Mm-hmm. Alright, well, thank you everybody for being here, I think we gotta wrap this up, we gotta wrap this up.

• 51:24Speaker 03

  That sounds good.

• 51:25Speaker 02

  We got seven-year-olds to kill in Fortnite.

• 51:28Speaker 03

  Nice. Nice.

• 51:30Speaker 00

  By the way, we do have to do a DHH Fortnite something at some point soon, cuz it would be so funny.

• 51:39Speaker 03

  Programmer Fortnite Tournament, that's what it's feeling like. Esports.

• 51:43Speaker 02

  I don't know about tournament, we're casuals.

• 51:45Speaker 00

  That whole tournament word kinda hurts me.

• 51:46Speaker 03

  Oh, just like, with programmers only.

• 51:50Speaker 02

  With programmers with kids only.

• 51:53Speaker 03

  There you go, yeah. Now we're talking, now we're talking.

• 51:58Speaker 02

  At least two, as well.

• 52:02Speaker 00

  Alright, well, thank you, everybody, for joining. We had Mitchell Hashimoto, creator of Ghosty and many other open source things. Taylor Ottwell, creator of Laravel. Taylor, is there anywhere we can find you that you want to give a shout out for?

• 52:15Speaker 04

  Laravel.com, baby. I don't know. X.com/TaylorOttwell.

• 52:19Speaker 00

  Nice. Let's go. And how about you, Adam? Adam is the creator of Tailwind, and also a very handsome dude. And will probably, and has the, has the ability to beat me up. He looks, he's a very fit man. Taylor, where can people find you, besides for the gym?

• 52:36Speaker 03

  I mean, Adam.

• 52:37Speaker 00

  Sorry, Adam. Please don't beat me up for the mistake.

• 52:42Speaker 02

  Just probably on Twitter, X, whatever. X.com/AdamWad, and that's where I hang out the most.

• 52:48Speaker 00

  Awesome. And finally, TJ, the man, the myth, the legend. I just want to be Tej. I want to code. I want to dance. I don't want to go home.

• 52:56Speaker 03

  Oh, yeah.

• 52:56Speaker 00

  Where can people find you, TJ?

• 52:59Speaker 03

  TejDV, everywhere, basically, except GitHub. But I don't want you to find my GitHub anyways. So take that, chat.

• 53:06Speaker 00

  Got him.