Finding Future Maintainers by Brian Douglas ![rw-book-cover](https://img.youtube.com/vi/4Zba7999KzI/maxresdefault.jpg) ## Metadata - Author: [[YouTube]] - Full Title: Finding Future Maintainers by Brian Douglas - Category: #articles - Document Tags: [[video-notes]] [[youtube]] - Summary: Finding Future Maintainers by Brian Douglas - URL: https://www.youtube.com/watch?v=4Zba7999KzI All right, good morning. I am between you and coffee or maybe lunch. I'm not sure. We got a we got an actual talk right after this. Uh Brian Douglas and specifically talking about finding future maintainers in the age of AI. Interesting, huh? Uh raise your hand and say I if you could contribute to open source. All right, we're in the we're in the right room today. Excellent. Cool. So, I would actually I've actually given the story on the stage before a couple years ago about my first open source contribution. Um I actually have a finance degree, graduated in 2008 during the housing crisis in Tampa, Florida. So, there were no jobs. So, instead, I ended up selling IT equipment uh for NFL stadiums. So, Cisco, Extreme Networks, Wi-Fi was like a big thing uh in the early 2010s. So, uh, it was a fun way to learn how to talk to people. Uh, I actually consider myself an introvert. I know a lot of people are like, "Oh, you're so outgoing and and talking, but find me later. I'll probably go into like my shell and just like stare at the wall." Um, but yeah, this was my experience. So, I learned how to code while getting my MBA uh back in 2013. And surprisingly, people were hiring for jobs at that point. It was like just pastnet world. Uh, it was Rails was my intro to making contributions to open source and building stuff. And this is literally the email of my first exchange with a maintainer and making a contribution. Uh I went from Ruby to Noode.js. Uh I didn't understand Noode.js. I didn't I knew JavaScript from copy and pasting and Stack Overflow. Uh but I didn't understand the server side. So I had to use something on GitHub to solve a problem and I knew how to email. I had no idea about GitHub issues. So I emailed the maintainer and said, "Hey, I can't get this working. Could you help me out?" Uh, and to my surprise, within a couple hours at like 1:00 a.m. on a Saturday, uh, he responded and this is the exchange. And he ended up unblocking me. And then at the end, he's like, "Hey, I'm so glad you got unblocked. By the way, I'm at a K-pop concert. Uh, and I've been like traveling like, uh, Southeast Asia just like following this K-pop band. I didn't know what K-pop was back in 2015. Um, turns out K-pop's like huge. I've got a seven-year-old who's, uh, she knows all the dances, the K-pop Demon Hunter, and all the songs. So, uh, I'm a fan. Um but yeah, that was my first contribution. I I went into a whole world of like eventually got a job at GitHub, led developer advocacy there. Uh but the job actually I got that because I built this tool called opensour. Uh and it was a way for me to manage my open source contributions. It was like CRM for open source or pull request. And um funny enough like Kyle Del who's like leading um leading GitHub now COO uh he reached out and said I should work there and I did. Uh and then later I I left because I wanted to build open source as a thing for like a broader scope of the community. Um and I did and in about two years we ended up uh getting absorbed into Linux Foundation. So they have a they're actually one of our biggest users. Uh CNCF specifically. Uh so we merged with them late last year and opensource is now merged within the LFX insight. So if you are part of the LFX or LF uh you'll see some some nuance there. Um, but I still had the problem where I I wanted to still do open source and I actually don't contribute to a lot of LF projects. So, uh, I mentioned Brian Douglas, but I'm Buggy on most places on the internet. So, Buggy Yo on X, that usually confuses people because Buggy is he's actually a father of six gamer in St. Louis. So, he will get appment mentioned if you app mentioned him on X. Uh we're friends at this point because he gets so many app mentions about me uh for his his ex Twitter. Uh this is a stat that uh GitHub actually put out. So 46% of all the code uh specifically in the public open source is generated. Now this is across all languages. Uh so this number can be a little wonky and we can debate about it like back and forth like obviously this is one stat from one company. Um, but what's not a stat is folks are now getting open source contributions consistently uh within their open source projects. So this is Mitchell Hashimoto formerly uh well he co-created uh Hashi Corp, former board member uh he actually stepped down earlier this year uh and now he's working on his own open source project called Ghosty and he put out a call that says you can do AI contributions but you have to say you did it. Uh so you have to disclose that you made this contribution with AI because the way you the way you review AI code is very different than the way you review human code. There's a lot of assumptions that are made and we'll get to us but also I had a conversation with Mitchell earlier this year um around this time when he was doing this and it was a great conversation. Uh one of my new podcasts is called open source ready. Uh so please check it out if you're interested in open source and hearing from maintainers in the space. Cool. So, who's maintaining generated code? Now, I worked at GitHub and one of the things I was really impressed by GitHub is they do diff. So, they do PRs early uh because you're all remote and you kind of have to like uh actually I'm not even sure if this is still a thing, but when I was there, uh you open up the PR because you're all remote and you don't want to be over overlapping on people who are also working alongside of. So, like put the diff in a in a draft, but when it goes ready for review, the assumption is that you reviewed it first, right? So, we're now in a world where the assumption is that some AI, shout out to Codapid who sponsored the dinner last night. So, PR reviews are happening by AI first. So, you're shipping code and like you might be swinging from the hip uh and vibe coding. Uh hopefully not vibe coding at work, but you know, we're all human working with AIS. So, now we have the question of like who's maintaining this? Uh I work for this company now called continue.dev. Continue. We are perpetuating the problem which we are an open source coding agent fully open source Apache 2. Our goal is really to help you connect to open source models and leverage that in VS code or CLI and etc. But we also have this other mantra about amplify.dev which we're only meant to amplify developers not to replace them. And when you take that mindset of how you're interacting with AI and you look to extend what your capabilities are. I've been I spent all summer writing doing data engineering in Python not because it was my job but because I always wanted to do it and the way I approach this is using AI where I drop in the chat GBT and be like hey give me an arch architecture design of like here are the tools I want to use this is what I want to solve like let's make it performant let's make it scale to me as the one user and if I ever get 10 more users figure out how to scale that and I just open up a bunch of GitHub issues all summer and I did this and I amplified myself you know I'm not a data scientist I'm not data engineer but I was able to like accomplish this and it was a lot of fun because I won a lot of stuff that I usually have to ask for help for continue itself and a lot of this the I'll show continues repo so we're open source so I can show the data it's a lot easier to do that way um but this is the GitHub repo continue dev continue check it out but there's one thing that I got really excited about when I was doing open source which is the idea of contributor distribution so kind of seeing the shape of work across the last 30 days uh to see where the activity is happening. So that's this chart right here. So this is actually a live URL. Um I've since created this new little chart that I vive coded. Um and I I use that that term loosely more as like a a meme. I vibe coded, but also I really planned it out and I had to write up issues and I did design and archetype and stuff like that. So but I vibe coded it. Uh so this this is what that chart looks like the last 30 days of all contributions that continue. Uh, I'm actually hovering over myself on the right, which is I had a MCP cookbook in the docs. Um, what's nice about this, I can see roughly who are the folks who are repeatedly coming back for more. Who are the folks that actually work at the company? It's actually not clear, but we have a green dot over faces that are maintainers. Uh, and I'm using just a lot of stuff I was just curious if I could do. Could I identify a maintainer using just GPTO um 40? And the answer is yes. I can identify different details uh within how folks interact with the repo and identify them as a maintainer without being the or owner. Um the trick is if you've merged a PR in the last 30 days, you're probably a maintainer or you own you have ownership over the repo. Uh and then you can kind of do a bunch of other heruristics around that. And it's funny because AI is this automated machine learning. Uh I used to do heristics. I work at a company called Netlefi. Had to do like deploy cues for front-end websites and it was all heristics. And now you're like this dropping in a GPT and it's AI. Um, but here we are. So I built this thing because at continue we've got about 16 PRs a day. We get about a few issues a week. Uh, we get a ton of contributions from actually large companies because we do help build other folks AI tools because we're open source. But it's hard to know like what's happening, what the conversation is, uh, or who I should be paying attention to next. And I I do Devril, I do DevX, and I'm all about community and engaging with folks. So I built this tool. Uh I call it workspaces but what I really do is I take discussions that are open or issues that are open and I want to find similar issues that are already open. We had an issue we had issues like 1,200 issues which is I don't know it's is is that a lot to you guys is 1,200 issues a lot to me because I get a lot of anxiety of like oh man I want to like reach out these people but also I feel like issues are more of like a river of information. You don't always have to respond to them. Uh but it'd be nice to know where the trends are happening. So I created that and then what I just output is this a markdown table that just give me the list of all discussions that have been answered or are there they're similar and it's something that you could really approach just yourself at your team uh internal I know GitHub just shipped an embedding model that's not open but uh it's putting us in that same direction of like hey there's an issue open what other issues are similar to this can we pick the one issue to talk to and then close the other ones uh and I know we use Steelbot Steelbot's a it's a great tool. I know the guy who built it. Uh but he regretted it almost immediately because you don't want to close issues every 30 days or 90 days because you're losing so much information. And the reason I say that is because issues they're really this just the beginning of the story. Uh one thing I did when we didn't um when being an advocate at GitHub was we needed to figure out who the top 100 open source projects was. It was like a a small little skunk works project. We went to the data and the thing that a lot of folks look to and they gravitate to is like stars. But stars is not a really good metric of like actual engagement of a project. It's just more of like a vanity thing of like you bookmarked it for later. Uh but what we found is issue authors is actually a really good metric to look at because when you have issue authors growing up in the right there's interest that it's growing. Um so I say that because I I ran a podcast called the secret sauce for a while. One of my guests was uh Brendan Burns. Brenda Burns, co-creator of Kubernetes, and he actually talked about how early Kubernetes at Google and how they sort of like gifted this thing to the community, but how they built a community was when you started seeing the issues from like Red Hat and from IBM and them asking very specific questions about what they were building, you can kind of see something growing and some interest growing. Uh, and we focus, we overindex on pull requests. So, like we're in the month of Hackto Fest and you get six pull requests this year to get um, actually I don't think they do a t-shirt anymore. It's like a sticker pack or something or just like a high five. But what I'm getting at is we overindex on PRs, but we don't actually pay attention to issues. And issues could really be the the sort of the makings of a real community growing. So these are all charts and graphs that I built and I I again I I this is Python data science project. This is it like this is the front end to all the stuff I did like crunching a bunch of data on GitHub and um so I won't I won't go into in detail of all these charts. Uh you can go to the Euro the OSS FYI URL earlier and see this um but I wanted to point out one person. So I just want this chart where I can just like walk in on Monday and say okay what's happening within the continue repo and I have this thing called repeat uh reporters uh and then also have like repeat responders as well. So like reporters are folks opening issues. Responders are folks that are replying first. And I try to take out all bots. Um because there's a a really good trend of seeing, oh wow, Chess Smithy. Who is this guy? Like what is he doing in my repo? What is the thing you like you're trying to accomplish with a continue repo? When I found out he works for an agency that uses continue that's deployed at scale. Uh he also contributes to Copilot uh and specifically has Amazon Bedrock as a solution. So they're just trying to make Amazon Bedrock work at all the tools so the engineers could be happy. And that's a story I had to go source and go ask that question. But a lot of times you'll get these issues open like why is this guy opening like three issues a month? Like that's so annoying and they're so specific on things we don't care about. Well, he cares about for a reason and all we have to do is like take his time to like have a conversation. So continue I mentioned is a CLI as extension. Uh so this is a CLI and this is something that this one's for free uh because you could use for continue quad code copilot cursor whatever but what I like to do is actually go to the data inside the agent and just ask questions about it. Uh so this I'm asking hey use the GitHub CLI to summarize all issues authored by Chess Smithy. It's pretty simple right? Just give me a list of issues. Uh, so I get that list, but then give go ahead and summarize his expertise. If I need to like reach out to Chess Smithy for some help or contributions, like what is he good at? What does he know? And like this is something I would probably not do manually and just like read a bunch of issues and say, "Hey, what are you doing?" Like, "Okay, cool. Check this box. You know this thing, you know that thing, issue 1, 2, 3, 4, or whatever." Uh, but this is what I get. And this is GitHub CLI is one of the like probably up until AI like probably the most underutilized tools like I did the team u Mishlov and and Nate uh who actually kicked it off at GitHub when I was there and it was just like three person team for the longest time and now with the advent of AI you know what AI is really good at reading man pages. Uh so when you have like CLIs like you don't need to well cool use MCPS use goose what I'm saying is like CLI are pretty good with AI out the box. So like when we're like vibe coding things like vibe code with the CLI. Don't don't let it hallucinate and do like random things. Uh so like this is his expertise. So like I'm able to like and this is how I found out he was contributing the co-pilot stuff. I didn't even know that until I prepared these slides. I thought he was just I thought he was our man on the inside uh for continue but turns out he's everywhere. Um so we talked about issues but we also want to talk about pore requests where pull requests are the stories we leave for future maintainers. So I I'm It's one of my pet peeves like if you don't leave a PR description, you don't leave some breadcrumbs of what I'm looking at. I always get a little annoyed. I'm like, "Ah, you want me to read all these files and like guess on what your your attitude was at the point you were writing this code or what you wanted to do? I got to read your code comments. Like can you just give me like three lines?" Uh so obviously like we do have PR descriptions that get generated by AI. Um, so I appreciate if folks actually enable that stuff, but this is a point where I can tell that story. Like there's there's few people at GitHub that when they open issues and they open PRs, everyone stops and they read it because they're either staff or distinguish and folks will just stop and read the code that they're they're planning for the or the architecture design because like there's some problems you can learn from. And so I say this because every face on this chart that I was showing it before is a seed planted. A seed planted for future maintainers, for future junior engineers, future senior engineers to go discover what happened. How did we get here? The best thing we could do as senior engineers is walk in the code and be like, man, this guy was dumb. Like why did you do this? And at least you can answer that question by having descriptions and PRs and issues that lead into the breadcrumbs of how we got to this point. So, I say this now because code review is more important than ever in the age of AI. Like we're taking we took this for granted like we ship stuff. We assumed this engineer knew what he's doing or do what they were doing and uh so we're just going to like look for lenting changes and then we got lentters and like we got all CI/CD would just populate stuff and like we got prettier and stuff like that. So now like we're viewing for context and and I don't know what we're we're viewing for anymore like honestly because we have we have these agents that are not doing the work for us but I want to say that this is the opportunity for us to like sit around the fire and tell these stories. uh one of the engineers I worked at open source uh he was talking to me about uh one of the contributions he made to one of the CNCF projects and it was like one of those situations where he kind of understood the full vision of the CNCF and Kubernetes and it came because he was like I found the problem at the time he was working at VMware and wanted to solve it because they had to solve it for the the job opened the issue got mentorship because he asked enough questions jumped on a couple calls and got a PR uh into one of the uh CLI tools Uh, and he was just telling the story like it was like I don't know like watching a a a movie or a documentary and like tell me about all the turns and the left hands and all the buyin he had to do internally to like get time to work on this thing. And those were the stories that we always leave the behind once we hit merge. So I'll say this I my first day at GitHub uh we onboarded and they taught us how to use GitHub and like for 90 minutes and I'm like dude I've I've been doing GitHub for my entire career. Uh so what I did is I went to GitHubgitub and I went to the PRs and I scrolled all the way back in the pageionation. So like all the founders who just ship code all the early engineers all the issues that are open all the ones that I knew before I joined that were pretty incendiary. Uh reason why GitHub's not open source because there's a lot of interesting conversations and issues I just read them all because they're just sitting there like any GitHub employee can just scroll all the way back and look at all that context. And that's how I learned yeah GitHub had challenges. they were a Rails shop that turned into like a microser thing that turned into like a React embedded system and there's like reasons of why they took those turns or even like with accessibility there's a reason why they got there and when you understand the reason why you got there you have a better decisions and I think when you engage with agents and you do the vibe coding you don't know what you don't know but if you like read the book if you read the issue if you read the PR you know what to prompt next uh so when you choose to use AI or not sit around the fire and learn about that uh I saw this yesterday. David Kramer tweeted out that now we have these coding review agents that will give us exactly what we need. It will give us suggestions. We can copy and paste a prompt. I love doing this, but I also love asking follow-up prompts and asking follow-up conversation to understand like, hey, can I write documentation at this point? PR is open. Maybe docs are time. Like if I don't spend a lot of time writing the code, maybe I can spend more time prompting the docs so the next person can figure out how did we get here? Um I have a session this afternoon. Uh I didn't really go too deep in uh AI but I have a session going about continuous AI best practices. Uh so this is basically yes using agents but building workflows for things that we can automate. Uh so at the point that issues are open or documentation or whatever you have. Uh that's what we going to and I'll be doing quite a bit of live coding on this because uh we shipped a new feature today and uh I'll live code it. Um other thing I'll mention is building review agents. Uh I know code rap is a sponsor. Uh you could also build your own. So if you have data that you don't want to hand over to another model, uh you can run the stuff inhouse. You can run it on your own S3 bucket as well. So encourage you to do that. Uh maintainers and I'll leave you this maintainers are the storytellers we meet along the way. Um I say that because I talked to Evanu on the same podcast I mentioned earlier. Evanu, he's known for Vue and Vit and uh I think he has a startup now called Vzero, Void Zero. Uh he was telling me a story about in the pandemic he was building this build tool called V and he kind of just like threw a bunch of stuff on the wall during the pandemic uh and he knew he had to cut over the 2.0 and he spent all this time in issues and in discussions and in discord just saying okay this is not working but I think I know what I want and he described like I asked him like how do you find such a good team around you to contribute alongside of you and he he said he kind of just knows like the folks who get the maintainer's mind and like understand the next thing that he they can anticipate the next thing he's going to say based on all the stuff he just throws out there so like you might just be word vomit a bunch of ideas but there's this one guy Anthony Fu and Anthony Fu this guy celebrated for being a GitHub star. Uh the way he was describing this person I knew exactly who he was talking about. It was Anthony and Anony's written vetest. He's written all these other parts within the the V ecosystem at 19 years old. Uh and 19 years old I think he was in China at the time. I know he's in Europe now. Um but what I'm getting at is like he just was super excited about the idea. He would just pick up everything that was merged, every issue that was like closed and just go read a bunch of stuff. And I think we're leaving a ton of information on the table. A lot of the knowledge transfer that we could be continued to pass on to the next generation or to the next developer that onboards. Uh don't let AI just take it over full uh face value. Like go read a bunch of stuff. Uh read a book, read an issue, read a PR and I think we'll be better for finding our future maintainers. I'm B Douggee and uh as I mentioned uh I'll be giving a talk this afternoon and I do appreciate All Things Open for having me back uh speaking today and uh hopefully in future conferences. Cheers., Finding Future Maintainers by Brian Douglas, YouTube, 01k98371mx3ts3agn4k14ketz4.