Is AI Ruining Opensource?  🔗 **Source:** [Is AI Ruining Opensource?](https://share.snipd.com/episode/2eee7f46-0862-428b-a174-9091574e7981) ## Highlights - **Earn Trust Before Big Contributions** - Start by observing the project's community and culture before submitting code. - Make small, trusted contributions (bug fixes) to build credibility; avoid big refactors or unsolicited large changes early on. Transcript: Mitchell Hashimoto 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. But yeah, I think there's so many ways to answer this, but I think in general, the happiest, the golden path of what the right way is to contribute to open source is definitely what you Just said. It's like join the community, figure out what they're about, figure out the things they care about, figure out the vibes of how they're... Just observe. Just sit there and observe for a little while. And then after that, make a small change. It's really hard. Open source is a lot of trust. If someone who's contributed dozens of patches that I know they're going to always follow up if something breaks, if they do something big and scary, I'm more willing to merge it because I'll be like yeah they'll follow up if it's not perfect anyway and they've shown that they've they do pretty good stuff but if you just 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 know if this Is still happening, but there was this trend for a decade where people were like, write documentation. And I'm like, please don't write documentation. If you're a new user to a project, you're not expert enough to be teaching every other beginner the project. So don't write docs, don't fix typos, don't do any of that. It's kind of just noise that doesn't matter that much. Adam Wathan Don't refactor things. Mitchell Hashimoto Never refactor things, almost ever, even if you're a really serious contributor. Yeah, I think that's my, like, the big picture. But there's just so many angles to it. ([Time 0:01:58](https://share.snipd.com/snip/47e89953-a400-4aab-9181-9222c14fb65c)) - **Match Project Taste And Prefer Small High-Impact PRs** - Read the room and align with a project's coding style and placement conventions before contributing. - Prefer small, high-impact changes (few lines that unlock developer power) over huge niche PRs. Transcript: ThePrimeagen You've been running an open source project for just a couple years now, right? Yeah, a few years. A couple or 20 or something like that? I can't remember. A few years, yeah. TJ (TJDV / The NeoVim contributor) Yeah, gosh. I mean, a lot of stuff comes to mind. Some of the first things that come to mind are one thing we actually have in our Laravel internal code guide is read the room where a lot of times we'll get a PR that just seems disconnected From the rest of the projects, even just in terms of the way the code is structured or the, where the method is even put, you know, in the code base, sometimes 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 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. 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. 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 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 Rails and Basecamp and all of that. ([Time 0:06:01](https://share.snipd.com/snip/c9be7087-791e-418b-856b-ca3c067936cb)) - **Open Discussions Before Large PRs** - Require design discussion before major work: open an issue or discussion first. - Mitchell Hashimoto enforces PRs that close issues and warns PRs without issues may be closed without comment. Transcript: Mitchell Hashimoto That's why we have this policy in Ghosty, and it's in our contributors doc, where a PR 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 is No associated issue you're still welcome to open a pr but exactly what adam said there's a sentence in there it says something like i might review it in a week a month 10 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 it's just a feature or introduce a feature we didn't want. ([Time 0:11:55](https://share.snipd.com/snip/e2b13039-0037-43f2-a149-0ff7e1168c98)) - **Earn Triage Roles By Helping First** - Use community roles for triage: answer discussions and earn a helper role before gaining permissions. - Mitchell monitors discussions daily and trusted community members become helpers who triage issues. Transcript: Mitchell Hashimoto It's bad enough i'm gonna hear about it but um yeah 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. There's probably two dozen of those people, significantly more, and they just have triage permissions on the GitHub repo and Discord communities and stuff, and they're awesome. And they tag stuff, label stuff for us. They answer a lot of Q&A and close it. It's a cool role. Taylor Otwell So that's sort of how we we look at that stuff how do you uh yeah i was thinking that sorry yeah how do you convince or like bring people on for like the triage role because for some people I feel like it's like a specific person that'd be really interested in doing that like are you guys doing anything to find them or like how does that work for you guys it's ([Time 0:14:06](https://share.snipd.com/snip/b78eadb7-1a33-48f6-9eb6-7880efb92786)) - **Create Your Own Project To Showcase Talent** - If your goal is visibility or hiring, build your own open source project instead of drive-by PRs. - Creating a project shows taste, README quality, and end-to-end thinking that employers inspect closely. Transcript: Adam Wathan That's yours instead of getting permission from anybody to do anything. You know, I think that's the easiest way to get started. You'll also learn a lot about the perspective of an open source maintainer if you built your own thing, and that's going to help you be a better contributor to other projects as well. And then the other side of it is, again, just like really be hyper focused on making contributions that 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 Features or things that people are going to benefit from other than like fixes and performance improvements and stuff like that. ([Time 0:16:39](https://share.snipd.com/snip/0907d8c7-dc80-4fc0-94bd-6644e466323a)) - **First Contribution Was Built By Coaching And Apprenticeship** - TJ described his first NeoVim contribution: he asked for help, got coached, and made a merged PR. - That apprenticeship-style help led TJ from beginner to recurring contributor and later maintainer work. Transcript: Mitchell Hashimoto The way I got involved with open source, cause I was one of those people that really looked up to open source. Like, I like really, really wanted to be like a Rails contributor. That was like my big thing I wanted to do. And I don't think I ever was, but I was like hunting for something to fix in there. But I think 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 if someone comes into any open source community I've been a part of, has a really specific issue they want to fix, and they seem genuine about it, there's usually somebody else in That community that will coach you through it. It may not be like the creator of the project, but I've seen this happen 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 research the problem educated. They're like, you know what, I'm going to help you through this. Look at this file. So it's somewhere around there. If you have questions, let me know. And you go off and work on it, come back. 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 vouch for you, basically. It's your work, but it was coached and apprenticed, whatever you want to call it. And that is pretty common, pretty old school open source. And it, and it works really well still in the right projects. Taylor Otwell 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. And 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. 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. ([Time 0:18:40](https://share.snipd.com/snip/eeab3196-a6a9-4718-9481-553c1fed8047)) - **Long-Term Value Outweighs Short-Term Open Source Pain** - Open source has long-term rewards despite short-term toxicity and distractions. - Taylor Otwell says meeting people and work opportunities over years outweighed the temporary negative experiences. Transcript: ThePrimeagen Is it even worth it to create these open source things? And I mean that in a genuine sense. I'm not trying to meme because like my time running an open source project 2015, 2016, the amount of just like vitriol and annoyance and just made my life demonstrably worse is the reason Why I've largely never gone back to 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 a very opposite, I guess, experience. And so I'm just curious, is it really actually something people should all strive for is to create open source projects? TJ (TJDV / The NeoVim contributor) 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 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, you know, there's definitely ups and downs, as you said. And sometimes it feels like there's more downs than ups in the short term. But in the long term, like the places I've gotten to go or the people I've met online and built things together, to me, I think I'll look back on those times with like a lot of fond memories And like gratitude is really some of the best years of my life. ([Time 0:23:45](https://share.snipd.com/snip/ed9332f1-e3c9-4cb9-ad53-002bec1969da)) - **Be Prepared For Negativity And Retain Exit Options** - Expect negativity and build resilience; you can walk away more easily than in corporate roles. - Mitchell Hashimoto values the freedom to stop or change direction that open source grants compared to closed-source business obligations. Transcript: Mitchell Hashimoto Probably just a kick. I'm just like the monk that is just like whipping himself in the mirror. It's probably just that. It's not healthy, probably. 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 the pasture is always greener on the other side like you get the same thing on that side sort of like different different ways but um yeah at least like with open source I feel like um You could you could walk away from a lot of things that you can't in the same way when you're on the the corporate side and also uh you are like kind of doing much ([Time 0:25:56](https://share.snipd.com/snip/269af8f3-5832-4e25-89a0-31642575cf8b)) - **Keep Emotional Distance From Project Feedback** - Don't tie your identity to project praise or criticism; maintain emotional distance. - TJ warned that personalizing negative feedback leads to burnout and poor decisions when maintainers internalize every complaint. Transcript: TJ (TJDV / The NeoVim contributor) No, I, I was just going to say, I think another thing for me, you know, I think Mitchell and Adam and I, and, you know, teach with 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. I don't use NeoVim every day. Sorry, teach. Wait, what? Lots of people do. Taylor, you've been lying in our taxes. And it's like this big privilege, you know, to provide these tools that can make people's professional life a little bit more enjoyable. And I find that like a really satisfying like thing. And something I take like really serious as a privilege, like, look, not many people get to impact this many people around the world, you know, in 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 yeah Taylor Otwell I feel i felt the same way like when i was making telescope initially for neo vim 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. ([Time 0:28:04](https://share.snipd.com/snip/97b3b735-bc8e-45e8-a4a0-c5264bb0b20d)) - **Disclose AI Use And Own Your Understanding** - If you use LLMs to generate a PR, disclose it and be honest about your understanding. - Mitchell says undisclosed AI slop is common; admitted-AI PRs let maintainers gauge contributor confidence. Transcript: Mitchell Hashimoto Think it's a whole topic, but I mean, I think a whole new frontier. I would actually be really curious how Adam and Taylor are receiving this, but there's a whole new frontier of contributing with LLMs in your toolkit. That's changing a lot of my viewpoints on, uh, on how to be a good contributor. Yeah. Adam Wathan I don't think I've seen any LLM driven PR star stuff yet. Honestly. Wow. Really? TJ (TJDV / The NeoVim contributor) You don't get like the PRs with like, they all have the same basic, um, initial comment, the same format. Taylor Otwell That's what I had. Every single sentence. TJ (TJDV / The NeoVim contributor) Yeah. Taylor Otwell The, the bullet are all the same. If you're submitting a PR with AI and you don't want to get caught, at least tell it no emojis. Like, bro, not giving each line be an emoji. I get them every day. TJ (TJDV / The NeoVim contributor) I get several a day, actually. Mitchell Hashimoto Really? They want a day at least. You know what's funny, Taylor? You said earlier that new contributors, you look at their GitHub repos and stuff. I do the same thing. I kind of like GitHub docs them a little bit and try to figure out what they're about and where they work and what they're doing, why they're contributing or whatever. And the quickest way that I'm like, oh, this is going to be some slop is you find a ton of AI crap. And I'm not anti-AI. I've got to say that. I'm not anti-AI. I literally spend like $25 a day amp tokens i love it but um yeah there's some bad stuff out there yeah if i'm not mistaken you're the one that convinced me to re-give a inline autocomplete ThePrimeagen Another shot been using super maven since then oh cool and i didn't know that 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, what's it called, very strong-stanced. Yeah, I remember that. Emphatic, that was the word I was looking for. Mitchell Hashimoto I remember that, and I'm actually really sad because tab complete and inline complete hasn't been down in like a very long time and it's really nice when it's down because that's when You like that's when i close my laptop and don't don't work for the day um so yeah if like co-pilot or like more of those could go down that'd be sweet all right i'm interested to hear more Taylor Otwell 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 for me it the best experiences i've had with with slop in particular Mitchell Hashimoto 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, cloud 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, this is heading in the right direction, interesting. Or I could be like, okay, thanks, this looks pretty bad. I'm going to close it. Glad it works for you, or whatever. ([Time 0:38:44](https://share.snipd.com/snip/0dc92f64-f113-45c8-9c3c-5d854e83ee5f)) - **Don't Submit Drive-By AI Refactors** - Avoid AI-driven random refactors; they create noise and risk regressions. - Taylor Otwell reports many daily PRs that refactor Laravel without fixing bugs or improving performance, and he often closes them quickly. Transcript: TJ (TJDV / The NeoVim contributor) 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 what it feels like is happening on a fairly regular basis, 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 Otwell Taylor, say it, how you really feel. No one's even listening. It's fine. There's nobody out here. ThePrimeagen Tell those people. Yeah. You know, Adam. TJ (TJDV / The NeoVim contributor) Yeah don't know i action prs really quickly so i have i have to action like 20 prs a day or they're going to get ahead of me and so like i just really quickly close those you know like it's not ThePrimeagen Even a second thought uh because i just don't have time to really uh mess with it yeah no there is something to that where i mean on the inverse side for those that are making prs just simply Making it all the home person came i'm gonna drop see you mitchell thanks dude see all right mitchell has to drop he had someone coming over to his house to do some fixing and so he pre-warned Us that it was going to happen at any moment so he 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 want to fix something you don't know how to get started and you do just simply follow whatever the llm says you don't actually take the time to look at like why are the things In place you don't debug your way through print effort whatever you do uh it is like you are wasting someone else's time i think there's something big to that because it's going to take A big hit to your credibility. Like if you do that enough times, it's going to be, you're going to like ruin your relationships with people. Taylor Otwell 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 going to pretend that I do. I will never trust you again. True. See, the thing is, is that have Began who also submits a bunch of what's it called? AI generating stuff but I love Began and so I let it slide even though I'm like stop it Began. ThePrimeagen Stop it. Just a thought. Taylor Otwell Taylor you're saying you're seeing this a lot though? TJ (TJDV / The NeoVim contributor) Oh yeah every day for sure. Taylor Otwell And the range is like for you is it most of them are just like this random refactor thing or is it like we're associated with an issue like i'm kind of interested in sort of this it's ([Time 0:43:05](https://share.snipd.com/snip/60797107-0da5-4799-8e2e-7c62b44f6f24)) - **Use Plugins To Test Features Before Core Acceptance** - Encourage extensibility and plugins to let contributors experiment externally. - Adam and Taylor prefer people to build packages or plugins first and return with traction rather than asking core to absorb big niche features. Transcript: TJ (TJDV / The NeoVim contributor) We have these cool tools called Package Managers that let you bring in other code into your project, which is super cool. ThePrimeagen I'm calling Ginger Bill. Yeah, I know. Some people don't think they're good. Yeah. Yeah, that's right, Taylor. Package Managers are evil. TJ (TJDV / The NeoVim contributor) Yeah. Adam Wathan Mitchell doesn't like packages very much either. Oh, man. Missed it. Taylor Otwell The same thing for NeoVim which was 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 feedback Loop as an external repo that eventually get merged into neo vim 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. TJ (TJDV / The NeoVim contributor) 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? Taylor Otwell 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 want to have a built in package manager that does all of this stuff and whatever. Cool. They can put a few engineers on that and spend several million dollars. ([Time 0:48:48](https://share.snipd.com/snip/c3ceee53-2758-41fa-a7e8-47b4a1c7513a))