is AI ruining opensource? (Lost episode)

Alright, alright, here let me do a nice little intro. Uh anyways, I 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 NeoVib Adam. Creator of Tailwind, Taylor Otwell, creator of Laravel, and Mitchell, creator of many, many things. Most recently Ghosty, a super fantastic uh terminal in which was featured in an open AI. Uh video just recently if I'm not m if I'm not mistaken.

Yeah, yeah. That is that is pretty dang awesome. Alright. And so just kind of set the stage for those that don't know, there's this video that was released two years ago in which somebody used Express.js

as a means to give an example where they forked Express.js, manually edited the README, and then put in their name. And from there on out, approximately every six hours, For the last um two years, ExpressJS receives a PR that says update readme and then has somebody 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 project like Node.js. 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 can 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 uh contributing to open source for quite some time. And so I'd like to hear everybody's thoughts on what is the right way.

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 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

I there's so many ways to answer this, but I think in general, like the happiest, the 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

Um just observe. Just sit there and observe for a little while. Um 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 gonna 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 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 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 doc. Like 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 kinda just noise that doesn't matter that much. Don't refactor things. Uh never refactor things, almost ever. Even if you're a really serious contributor. Uh yeah. That's that's 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 Neo Vim user, you still need CI to be able to build your binaries, run your tests, or make your release. 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. Twice the speed and up to seventy five percent reduction in costs. Check them out at blacksmith.sh. Now back to the stage.

That's kind of interesting. Refactor D V. Lee Lee, he's a big big fan of it. Well I mean you miss a hundred percent 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 thirty seven edge cases that were there 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, l very low cost maintenance for like applying Vim patches.

to this thing. Like it should stay exactly the same'cause 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 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 you've been running an open source project for just a couple of years now, right? Yeah. A couple or twenty or something like that. I can't remember. 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 project, 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 it's just like at the bottom of some file because someone stuck it there. So like reading the room in 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 Really like tons of developer power or like a really great new feature or flexibility with very minimal like code changes to the framework itself. Um 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.

Um 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 driven from any real world like use case. It was just because they were watching other PRs come in and 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 off 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 Basecamp and all of that.

Um yeah. So that that's a couple of quick things that come to mind. I I would assume you get a lot more PRs for Laravel. Uh 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, splunking through and trying 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 readme updates then? Is that the call that we're hearing right now? Yes, more readme updates. No, I mean like I think like uh Taylor and Mitchell said, my favorite PRs to get are things that fix bugs because that's actually like saving me time, you know. Or uh if someone unlocks like some nice performance improvement, you know, things like that, that's always uh nice, especially if it doesn't require some crazy reimagining of how some entire subsystem works.

But new features I generally c generally feel like a chore, you know, to receive. Uh, especially from someone you don't know. I think uh 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. Um, but not not a good first. P R, 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 that like, oh I actually like understand how this stuff works and why things work this way and um whatever. So So what you're really trying to say, if I'm not mistaken, is you want to recreate the stack overflow feeling where you get a cer you get like a base level and you can only comment.

And then through enough comments and um votes you can then gain more and more power. So we just want to recreate that, but with GitHub. A GitHub social credit score. I see where this is going. Yeah, but it it would be a per repo social credit score. Mm-hmm. 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 and 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 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 and then you'll get like 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 any thing 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 found difficult 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 gonna 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 ha we have this policy like in in Ghostie 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 with no associate issue and our issues, only maintainers can open issues. Users can't open issues. Um users can only open discussions.

discuss 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, ten years, 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 and or like um I think what Taylor was getting out was like a lot of features it

The the actual like business logic isn't hard. What's hard is like the last mile taste of how that feature gets exposed 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 wanna do all that bike shedding in the discussion. Um and a lot of the bike shedding in the discussion is literally about

I don't care how you're gonna 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? Like it's just that stuff'cause then you could get the rest working and you could like iterate.

Um So with the way that you guys do things, Mitchell, if you you are the only ones who can open issues, do you monitor discussions like pretty diligently then to like notice when like a a bug is reported from the community that should be escalated to an issue.

Or do you just kinda 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 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 l they tag stuff, label stuff for us, um, they answer a lot of QA and close it and um yeah, it it it's a cool role. So that's sort of how we we look at that stuff.

for like the triage rule. 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? It's like I think it's open source in its purest sense. It's the 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'm just like shirk 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.

Um, and they they just want to do that because whether we like it or not, we you know, there's a 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. So they, you know, there's definitely a preserv a preserve

Oh my god. 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'll also learn a lot about

the perspective of an open source maintainer if you build your own thing and that's gonna help you be a better contributor to other projects um as well. And then the other side of it is again just like really be hyper focused on making contributions that are uh the maintainers are gonna be grateful for, which again is like bug fixes, uh

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 gonna how 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 features or things that people are gonna 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 f 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 gonna 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 gonna 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 Laravel's open source team is just like these intangible taste type things of like Yeah, the rebate is almost always like more

high stakes than the code. Yeah, can you write well? Like can you can you explain this well? You know, I mean that Is valuable too.

I'll come at it from another angle. I think that if you are the way I got involved with open source, because I was one of those people that really looked up to open source. Like um I I I I like really, really wanted to be like a Rails contributor. That was like my the big thing I wanted to do. And I I don't think I ever was. Um but Um I was like hunting for something to to fix in there. Um but I think that like the best way that to 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.

Um it may not be like the creator of the project, but um I've I've seen this happen in Ghost C a lot where We've had maintainers be be like it's a subsystem expert that could fix that in thirty 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 gonna help you through this, look at this file.

Um so 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. Um, like it's your work, but it was, you know, coached and apprenticed, whatever you want to call it, and that is pretty common, like pretty old school open source and it and it works really well still in the right project.

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 and nicer.

Um 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? Um and then like that was my, you know, eventually got merged uh like in the 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 and I mean in a lot of ways changed the trajectory of uh my career as well.

I had this really uh I had this really similar experience in high school where I okay, I couldn't get into Rails, but I found this like Rails 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 pat it wasn't GitHub didn't exist yet, so I made matches like pat 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 worked.

I clicked around it works. And I didn't know it was. More than a lot of contributors do. 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 who'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 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 as 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 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.

Alright 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 uh project. And Taylor, you said that you that you should just create when you're Now that you've kind of gone through the process of creating one yourself, have had a lot of success, you know, creating yours, seen 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. i 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 d 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 le at least f you know, for me. Um And uh, you know, I d 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

the places I've gotten to go or the people I've met online and 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 kinda 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 uh been a positive thing. Mitchell, you're like a chronic open sourcer. Uh you mu 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. 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. Uh

But no, I mean I like it. I like it. Th 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 closed source side, like founder CEO thing and I I think Adam and Taylor, you g I mean, you're all on that side too now, but You know, y it's the pasture's 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 kinda doing much more you mean you you 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'cause 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

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 has 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 it I think it knows. Go ahead. No. Oh, I was just gonna say I think another thing for me, you know, I think Mitchell and Adam and I and you know, teach 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 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. Um I don't use Neo Vim every day, sorry teach. Wait, what? But lots of people do. Taylor, you've been lying in our taxes.

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, in in small ways.

And like it's really cool that we get to do that and I find that satisfying and 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 in small ways.

Yeah, I know. I feel I felt the same way like when I was making telescope initially for NeoVim and people were using it and I was really surprised'cause 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 a 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 w uh 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 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.'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 gonna please everybody and my project's not for everyone. Some people are just gonna 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. I mean we all probably deal with angry people every day. I I think a big part of like

uh open source maturity from a maintainer side is learning how to how to not let that get to you. And there's various strategies, but yeah. And the you know the bigger you get the the the weirder also the anger gets, but it yeah, it's it's everywhere. 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 it used to. When

The 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, I 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 through they like hear a story and they say, Oh, that person got a job from a successful open source project. I'm gonna write open source and then I'm gonna 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. M uh Mitchell, you have probably the most unusual group of maintainers. Because uh as far as I can tell, the Adam and Taylor they're much more on the website. There's probably a 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.

Uh, still not at one point oh and you know, even the recent uh fifteen 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 uh cause 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 o 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 neck beard and has the ideal way everything should be done? Or like I 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

uh the highly opinionated my blessed setup must be supported kind of ways. Um You know, I've I've been on the website as well and and the the 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. Um there's generally a lot more uniformity in terms of setups. Um uh there's only like practically speaking, there's only

a ha like handful to a dozen sort of like browser configurations. That 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. 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 I'm committed to supporting it'cause I use it myself, but Um we recently like took a stand for example with um I I I tweeted some like some tongue in cheek version of it, but um we just took a stand on input issues because we were just getting so many people being like I use this custom keyboard with this custom firmware with like

and layers and when I and 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. 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 gonna get fixed. So I think stuff like that is is new to me and and I'm figuring it out. And then in terms of the actual maintainers themselves, um

Uh you know, good maintainers don't care too much about the language. So Zig, I I would say most of our maintainers um have been excited to use Zig, didn't use Zig before, just picked it up to learn it. Um 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.

I uh built a small tower defense in Zig and it was a very enjoyable time in Zero thirteen. And so I assume it's it's relatively the exact same language in zero fifteen. Uh but I am actually just curious, I know this is going way off topic.

You 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 it's been awesome. I mean we have to inter we we read and integrate with C and C plus plus code all the time as a comparison and Um just from their building and understanding and maintaining is 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 that these aren't amateurs. We're we're like we're trying you know, we read

um Chrome, uh Firefox and WebKit source code all the time because uh basically browsers solved font rendering and so every 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 plus plus you're gonna find.

And it's incredible how difficult it is to uh read that compared to the equivalent Zig. So I think that Zig's been hugely successful for us. Um each m 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. Um each one is is significant. Um 0.15 took Took me about three weeks. Um, 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. Um I trust them, but like I just have to understand it myself. So I went and redid it and I was able to hit roadbox and just copy from there and be like, oh they figured it out for me. Nice. And then learn something. And it still took me three weeks. Um

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 and I love it. All right. Well, do we have any final words on open source? Anyone have anything else you want to contribute to on contributing the right way to open source? It's October, baby.

Yeah. I was laughing we were talking about it before you came on Prime of like Will well this was what I was thinking too. Will LLMs in the future, when it's October, be more likely to create readme updates? Because of the source training data. Because they have the system prompt with the time, just like how it gets lazier in the summer, especially if it's clawed. Uh they will they also have this problem that forever and perpetuity.

October will be documentation update month for LLMs. 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. Actually, I do. 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 are receiving this, but there's a whole new frontier of like

contributing with LLMs in your toolkit. Um and that's like changing a lot of my viewpoints on uh on how to be a good contributor. Yeah. We should L L M driven PRS to R stuff yet, honestly. Wow. Really? You don't get like the PRs with like they all have the same basic um initial headers and the emotional every single sentence. Yeah, the the bullet points are all. If you're submitting a PR with AI and you don't want to get caught, at least tell it no emotion.

Like having each line be in a moment. I get'em every day. I get several a day actually. Really? Uh you know, like doc GitHub docs them a little bit and try figure out what they're about and w where they work and what they're doing, why they're w contributing here, whatever. And Uh 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 use I I s I literally spend like twenty five dollars a day in AMP tokens. I I love it, but um yeah, there there's some bad stuff out there. 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.

Oh cool. And I didn't know that. 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 f uh uh what's it called? Um very Like strong stanced. Yeah, I remember that. Yeah, yeah, yeah. Emphatic. That was the word I was looking for.

I remember that. And I am actually really sad because uh tab complete and inline complete hasn't been down in like a very long time and it's really nice when it's down'cause 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 copile it or like More of those could go down. That'd be sweet. All right. Taylor, I'm interested to hear more about like and and Mitchell, you too,'cause 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 a not like, oh, they carefully walked through an agent workflow over ten hours and did all of this 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, it 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. Um if someone throws a PR up, and this has happened like once a week probably, where they say, I used whatever, codecs, claud code to fix this bug. I don't know Zig. I don't know anything that it did. Uh, 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 slot and they're like really serious about confident about that they should be merged and be fixed. And so from the slope, that's what I would say. And so we require AI disclosure in our project, but that's part of the reason.

Do you do you actually get people that do AI disclosure? Like do they actually does everybody do it or have you like caught somebody and be like, Wait a second. That argument's all goofy and it's ordering. I know you use slop and then like dang it, you got me like

Yeah, I wanna hear what Taylor has to say, but I 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 uh also I think everybody except one person, uh, it just was an accident. They're like, Oh, I didn't read that. I yeah, here it is.

Um but there was one person that super tried to hide it and I eventually got you could find it on I I eventually got to the point where I'm like, I'm just gonna cl like this is not productive. If you can't be honest about your AI used I can't trust literally anything else you're doing, so I'm just gonna 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 wanna know their confidence in what they're submitting. Um, 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 cloud code and been like Find a refactoring opportunity in the O R M 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 uh fairly regular basis. 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. Taylor, say it how you really feel. No one's even listening. It's fine. There's nobody out here. Tell me Fuck those people. Yeah. You know There you go, Adam.

Yeah. I don't know. I action PRs really quickly. So I have I have to action like twenty 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. Yeah. No, there is something to that where w I mean on the inverse side for those that are making PRs, just simply making a PR. The home person came. I'm gonna draw. 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 gonna happen at any moment. So he is g he's gone. All right, uh I Uh 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 L L M 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 eff 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. If you do it one time.

Because that's your first impression. That is your first impression. 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. True. See the thing is is that I have Began who also submits a bunch of uh what's it called? AI generated stuff, but I love Began and so I let it slide even though I'm like Stop it Began. Stop it.

Just a thought. Yeah, 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 uh is it most of them are just like this random refactor thing or is it like for associated with an issue? Like I'm kinda interested in sort of this dish here. 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 real like performance improvement. It's just like code organization or like method extraction or just some random thing like 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? Yeah. Um 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 a difference. You're like I don't know if I like 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 I I mean I 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 bit of 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. Um three or four lines.

Yeah. Yeah. I just looked and this week I've gotten eight refactor PRs so far. Whoa. But that is so many. A any PR that has the word single responsibility principle in it is close. That's auto close. I'll be right back. That's autoclose. Yeah. We have agents for that now. Uh that just monitor

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 ten X or twenty X. cooler than like I got a random refactor PR merged into Laravel in twenty sixteen, you know like And and 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 the internet. Exactly. Yeah. 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'cause 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.

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 think they're good. Yeah. Yeah, that's right, Taylor. Package managers are evil. Yeah. Mitchell doesn't like packages very much.

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 I literally have a 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 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 your random open source repo does not have that same capability or budget to like solve those things. So, you know, like Taylor, I I know you feel it all the time, I'm sure

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. Yeah He he did build a Larvot package manager before pre-composer. Before Composer existed. Oh. And then you got to delete it.

Yeah, pretty much. Yeah, better. S PR. Mm-hmm. All right. Well, thank you everybody for being here. I think we gotta wrap this up. We gotta wrap this up. Yeah. That sounds good. We got seven year olds to kill in Fortnite. Yeah, yeah. Nice. By the way, we do have to do a DHA. Fortnite something at some point soon'cause it'd be so funny. Program or Fortnite tournament, that's what it's feeling like. Esports tournament. Oh, just like when

With programmers with kids only. There you go. Yeah. Now we're talking. Now we're talking. At least two as well. Yeah. All right, well thank you everybody for uh joining. Uh we had a Mitchell Hashimoto, creator of Ghostie and many other open source things. Taylor Otwell, creator of Laravel. Taylor, is there anywhere we can find you that you want to give a shout out for?

Laravel dot com baby. I don't know. X dot com slash Taylor Otwell. Nice. Let's go. And how about you, Adam? Adam is the creator of Tailwind uh and also a very handsome dude. And will probably and and has the has the ability to beat me up. He looks he's a very fit man. Uh Taylor, where can people find you? Besides for the gym. You mean Adam. Sorry, Adam. Yeah, the job. No, just uh probably on Twitter or X, whatever, X.com slash Adamwad, and that's where I hang out the most.

Awesome. And finally T J the man, the myth, the legend. I just wanna be Tej, I wanna code, I wanna dance, I don't wanna go home. Oh yeah. Where can people find you TJ? Uh T D V everywhere basically except GitHub, but I don't want you to find my GitHub anyways. Got him.