The Changelog: Software Development, Open Source - ANTHOLOGY — Maintaining maintainers (Interview)

Episode Date: May 31, 2023

This week on The Changelog we're continuing our Maintainer Month series by taking to you back to the hallway track of The Linux Foundation's Open Source Summit North America 2023 in Vancouver, Canada. Today’s anthology episode features: Stormy Peters (VP of Communities at GitHub), Dr. Dawn Foster (Director of Open Source Community Strategy at VMware), and Angie Byron (Drupal Core Product Manager and Community Director at Aiven). Special thanks to our friends at GitHub for sponsoring us to attend this conference as part of Maintainer Month.

This week on The Change Law, we're continuing our maintainer month series by taking you back to the hallway track of the Linux Foundation's Open Source Summit North America 2023 in Vancouver, Canada. Today's anthology episode features Stormy Peters, VP of Communities at GitHub, Dr. Don Foster, Director of Open Source Community Strategy at VMware, and Angie Byron, Drupal Core Product Manager and Community Director at Avon. On this episode, we talk about the core issues of open source software maintainers, finding

balance, understanding project health, identifying new contributors, getting funding and support, knowing when to step back, healthy succession plans for leaders, and even a dash of choosing the right license. Learn more about Maintainer Month at maintainermonth.github.com. Special thanks to our friends at GitHub for sponsoring us to attend this conference as part of Maintainer Month. And also a big thanks to our friends and partners at Fastly and Fly. Our pods are fast to download globally because Fastly is fast globally.

Check them out at fastly.com and our friends at Fly help us put our app in our database, close to our users all over the world. And they'll do it for you too with no ops. Check them out at fly.io well i'm here with richard moot the api design lead for all of square and we're talking about the graphql api that is now in OpenAlpha looking for feedback. So Richard, what's the story with this API? So we've announced this at Unbox last year, and we've been just incrementally adding parts to our GraphQL API. It's been a big ask from developers within our community because

it makes using Square's platform so much easier for particular things. You're no longer having to, let's say, call three or four different APIs to pull together a bunch of different data. And so we've just been trying to learn more and more how developers are planning on using this and making sure that we get this right before we actually transition to the next phase in its release. So you have the orders API out there, the catalog API, the customers API, the merchants API, the customers API,

the merchants API, the payments API, the refunds API, and the inventory API out there. And you also have the GraphQL Explorer out there. Tell me, what are you expecting from developers? What feedback do you want? What are your expectations? I think our expectations is to find out all the different ways that you're using it and that we can make it better for you. I mean, right now, you know, we've gotten really good feedback. We have, I mean, as soon as I announced

the update to our docs that we recently did, the very first question that I got on Twitter from someone was like, when is this going out of alpha? And so we're really happy to see that. But we also are still wanting to hear from developers. Like, you know, you're implementing this, you're trying to build something. What is causing you angst?

Like, is it issues with, like, constraints around query depths or a number of queries? Is it fast enough for you? Are you trying to use it in a particular mobile app, Electron app or something? And like, you know, what what issues are you kind of coming across? And like, what, how can we make it better? And I would definitely say that, like, anything that you come across when you come in, you try it out, whether it's in the GraphQL Explorer, in your command line in your app, we want you to reach out to us on our Slack or forums, those would be great. You can also tweet at us, I will definitely be keeping an eye on that.

But I will probably still always say like, hey, like the forums are a great resource because we have a lot of questions that are already asked there. And we really just want to like funnel all that feedback to the team so that we can get this into there in want to check this API out yourself, go to developer.squareup.com. Again, developer.squareup.com. It is an open alpha. They're looking for feedback. Hit them up on Slack, head to the forums, whatever works for you. Once again, developer.squareup.com. GitHub Sponsors. What is the state of GitHub Sponsors? So GitHub Sponsors is now generally available for companies as well as individuals to donate money to maintainers. Or give money to maintainers, not donate. It's been a journey. You've had a couple people in charge of it. The last time we talked to Jessica Lord, she was, this was about a year and a half ago, was it?

Probably. She came back to GitHub. She was a boomerang. Yeah, she did. She loves GitHub so much. Yeah, she's awesome. Is she still in charge. She's not still in charge of GitHub sponsors, right? She's not doing sponsors now. Okay. Is

anyone in charge of it? Who is in charge of it? How does it work? We actually have an open job rec right now. Is that right? If you would like to be in charge of it, you can apply. Gosh, I could slay that. It's actually for a team that's going to be looking at how to change the open source ecosystem so that we fund maintainers in ways that aren't just a paycheck. Yeah.

It's a tough job. Who could do that job well? Like, what would they have done beforehand to do that job well? It's been kind of fun, like, trying to recruit. So, we really want someone who's passionate about open source software who has some kind of background in it. You know that, right? Yeah. We could pair up on that job, Jared.

I've also interviewed people who were in insurance before and suggested insurance models. I've interviewed people that were in venture capital money. We're just kind of experimenting with who can bring new ideas to the space. It has to begin with a desire. What is GitHub optimizing for when it comes to sponsors? What does GitHub want with sponsors in general? What are the possibilities? Our ultimate goal is to make open source software successful.

So that means providing ways for maintainers to have time and energy to invest in open source software. But part of that solution is helping companies understand what dependencies they have and making sure that software is secure and reliable. So companies know they have, some of them know they have dependencies on open source software. They really want to help make sure it's reliable. Like they need someone to help them if it goes down. And they understand money is part of that solution. So how do we help them provide that?

How do we help maintainers say, here I am, here's how I can help you. Right. That sounds like a challenge. So you said it's now available to companies. It was always available to companies, but until recently they had to pay via credit card, which how many people at a company can put a couple hundred thousand dollars on their credit card? Right. So we added things like invoices and normal corporate things. I see. So you grease the skids, as they say, for companies to be able to actually give at a higher clip than they could with some sort of corporate credit card. Yep. This has been an effort in the making because I know when we talked to Jessica,

that was the plan to get there and you're saying now it's available. Yep. Okay. How has that changed things? Like has the giving or supporting gotten easier? Has the amounts increased? What are the stats behind, you know, this new feature being there for sponsors? Yeah, I think it's worth looking at before we were generally available in just our beta program. We already had, like, $30 million flow through the program. So obviously there was, like, a high demand for it. Yeah. And we just GA'd a couple weeks ago.

So I don't have numbers, but I can tell you that there are new companies signing up for it. Okay. Okay. Can you speak to the excitement then? I mean, there's no traction net to compare these. Oh, there's traction. Oh, I mean, what I mean by that is it's so new, there's not a lot of details you can share yet because it's fresh. What's the response from those chomping at the bit to get access to this?

Is it a lot of companies desiring this? I think a lot of companies want to make sure the software they use is reliable, secure, and that they recognize that they use it. I think the people at companies want to make sure they're fair. I always say companies aren't people and they aren't motivated like people are. Right. There's no emotion. they aren't motivated like people are. Like if I'm like, like say, say I go out of town or there's no sense of like give and take the same way people have it. Like say I go out of town and I ask my neighbor to like come feed the cat every day. And when I get back into town, I'm like, Oh, she did me a huge favor. So like, I'm going to take her some apples from my apple trees.

And so I take apples over to her and she goes, wow, this was like a lot of apples just for feeding the cat. So I'm going to make an apple pie. And she like brings me back an apple pie. And there's like this give and take that we take for granted as humans. Who in a company, someone in a company has to do that because a company doesn't do that. Or profit generating machines. And so the people have to like step out of the norm in order to do that.

But people do want to. So we're trying to give them tools like here's your dependencies. Here's the dependencies of your dependencies. Okay, so all that stuff exists now inside of the sponsors dashboard or is it just inside of GitHub? Various tools have it. So we can help you with sponsors. We also have an OSPO dashboard for corporations

where they can see what they're using and what they're contributing to. That's cool. And so what's a typical give out of a corporation these days? Companies would also like to know that because we actually had one company that came and said, I want to make sure that I don't look like I'm giving too little. Right. And so they didn't want to give, and they were willing to give a couple hundred thousand dollars, but they were afraid it would look like too little. Yeah.

So I think we need to establish some norms. Right. So it's still kind of playing out. We don't know what a norm is. We don't know. The best indicator of that has been the FOSS Contributor Fund to some degree. And we just talked to Chad Whitaker that shows out there as part of this episode we did with Maintainer Month and whatnot. And essentially, he did some back-of-the-napkin math, and it was like 2K per engineer to the software that they depend on, essentially. So if they have 50 engineers, this is a round number, 2K, you do the math.

Yeah, you could look at it in a number of ways. You could look at how many engineers does your company have, how much money do you make off the software you build on it, how many different software projects do you use? You could offer up a whole bunch of formulas, and I think we probably just need to pick one and suggest something. We had this entire conversation story, and I really wish you would hear it. I'm going to paraphrase it.

We talked about this idea of a pricing page that a SaaS company might have for them. You got the free tier, you got the pro plan, you got the business plan, you got the enterprise. And essentially, we need an on-ramp to fair funding of open source, whether I'm an individual or a small team or a larger enterprise. The idea of fairness, I think they ask you all, get up sponsors, hey, what is fair, right? What should I give? What's too little? What's too much? There's no real, I guess, documentation out there of what fair is. If you're in this realm, maybe 2K per month is too much for you, but it's at least a good place to start. Maybe 2K per month, or sorry, whatever the number is, 2K per developer. Maybe it's more like 500, or what is a fair number that makes sense for you?

How do you quantify that? Give them some sort of algorithms, basically, to sort of figure out what fair really is for them. And it also depends on what the maintainer wants to be responsible for or commit to. I'm not quite sure the right word there. Like, what if I wrote it last summer, I had a month off, and I wrote this really cool library that solved a need for me and I put it

out there and like, I'm done with it. Right. Like I, I did it. I put it out there. If you tell me like it's being used in hospitals and someone's dying, I'm going to come back and help you. But like, I have another job, I have a family, like I'm not working on it anymore. That's a really different scenario than someone who's trying to make a living off of it, develop the library, wants to keep improving. It wants to hear feedback, wants to like help you however you're using it. You know,

I talked to someone last night at dinner and he's like, I have a job, but like they're using my software and like, I try to help them. I, you know, I, I look at their pull requests.

I send them emails. Like he's in a very active role in his project. Right. That's, those are different scenarios. Maintainer guilt. Not guilt. He wants to.

You're solving a problem for the world. He wants to do it. He would probably have more time to do it if he got compensated more. Right. But also he wants to do it right now, but three, four, five years from now his life changes. He doesn't want to do it anymore. Now he gets the maintainer guilt of like, well, all these people rely upon me. I'm life changes. He doesn't want to do it anymore. Now he gets the maintainer guilt of like, well, all these people rely upon me.

I'm burning now. I don't want to do this. I got a baby now or whatever it is. Right. That's been a theme. That's a theme for maintainer month. And it's also was a talk yesterday about how do you do succession planning? Yeah.

How do you do succession planning? I'm definitely not the expert. I could find you the speaker of that talk. We have talked about that. Asked a few people that question. It's like, it's like, it's like getting a room. There's just you the speaker of that talk. We have talked about that. We asked a few people that question. It's like getting a room. There's just so many rows to get there. I think it definitely is building out your community

and building trust along the way. You have to put other people in positions of trust so there's someone to fill your shoes when you leave. But it's really hard. Yeah, that's the easy way to do it. I mean, not the easy way, but that's the right way to do it, I guess,

versus one day being like, okay, I need a successor, right? Right. But I haven't been preparing for this day at all, but I need one right now. And so, what, I put out a post on my socials, and I was like, someone please take over this project for me? I think we could learn a lot from nonprofits in this space. I think they have the same problem. Okay. How so? So a lot of nonprofits don't have people on salary like a lot of the smaller ones. And so

if the person- Yeah. If the person running wants to like leave or go do something else, they have to have a succession plan as well. Okay. Well, we talked about having terms of service to some degree, like, A, if you want to be a maintainer, et cetera, or you are a maintainer, or you want to bring on a contributor, a term of service. So what you're saying is if you need to leave or you need to step away, the social construct should be plan for successor. Invite a successor, have some sort of plan, like, just don't leave your station abandoned.

And I agree with that. That would be great if you didn't abandon it, especially if other people are using it. But I agree with that as well. It's much easier to get people to step up to positions in your project if you're clear about what they are. Hey, if you submit five pull requests, and I pretty much accepted them unchanged, and you're always there when I send you an email or a DM.

Then I'm willing to consider you for this role. Right. And if you accept it, when you leave, which is cool, please help me find somebody who might be suitable. That would be a good question. And the please might be more you have to versus just simply please. Can you say that, though? Well, what I'm asking, I guess, is like, should we, there's no perfect way to do this, but maybe the version that gets deployed in most cases is like, if you accept a position on a project that has, I don't know, some usefulness, some threshold of usefulness, and you are a crucial person because you've accepted a role as a maintainer. Maybe you agree to mentor a certain number of people or something.

Yeah, exactly. Something that says I care about my team, my other maintainers, and this project enough to accept the role because I like it. But also, if I need to step away, some sort of responsibility to ensure non-breakage, you know? So one of our GitHub students, you know, the students that's in GitHub education shared with me a tip that he learned yesterday, which was instead of, you know, someone submits an issue, instead of just writing code and solving it

and doing your own pull request and closing it, they suggested writing out, like, the whole problem and how you saw the solution. They said it would take as long as just solving it, but writing it up and describing it and then putting it out there for someone else to be able to pick up is a good way to grow your project.

Don't repeat yourself. That's so forward thinking, though. It requires discipline and forethought. It's hard to do that at a time where you're just like, well, I could just fix it real quick. Especially if you like writing code and you like your project.

I like to write code. I do not like to write prose very much. I started this because I like coding. I'm just going to code this up real quick. But you do that over and over and over again, and eventually it's just a recipe for disaster, you know, as your life changes, as your desires change. But you can write prose for the problems that are kind of boring to you and then save the interesting ones for yourself. Yeah.

Just don't tell anybody that's what you're doing. Here's a bunch of boring issues, guys. You guys handle those. I'll take all the fun stuff. I'll take the fun stuff. It might not work to grow your project. Companies can now contribute to open source via GitHub sponsors in new ways, not just credit cards, POs, larger checks, et cetera. What's the state, I guess, the next major thing for sponsors? What

are you working on? What is the sponsors team or this new leadership? What's the next plan for GitHub sponsors? Yeah, so I think there's still features we can add in the products. Like we talked about being able to see all your dependencies and all those dependencies and contribute with one click. There's things like that we can add. the products. Like we talked about like being able to see all your dependencies and all those dependencies and, you know, contribute with like one click, you know, there's things like that we can add, but we also have a couple other programs that we're experimenting with and we're bringing them into, you know, one group. Um, so we have, we have a accelerator program that's going on right now. It's a 10 week program. We have 20 people in it in this round, $2,000 a week, and they meet a couple of times a week. They get like mentorship, they get to meet each other.

And these are people that want to take their project to the next level. And so we're figuring out what do they need, what can we offer them, and then hopefully what can we build into sponsors and the GitHub product to help all maintainers who want to take their project to the next level. We also have GitHub Fund

because it's really hard to get venture capital money when you are writing your company's code in open source. Venture capitalists like to think you have secret sauce. And so we have GitHub Fund that actually funds open source software projects that are companies, startup companies. Interesting. And that's GitHub proper that funds it or they're pulling together other people's money? How does that work? It's a partnership with Microsoft's M12 Venture Capital Fund.

Okay. How do those projects get selected? Is it an application? Is it who gets funded? How do they get funded? Most stars? The Accelerator program is... Yeah, most stars.

Yeah, most stars. The Accelerator program is an application. So someone who's interested in taking their project to the next level applies, and we selected them. On the GitHub fund, we actually try to source them and find them, and then we reach out. They could also reach out, but we actually do a lot of research to try to find them. Will you do the accelerator package or process as part of, like, batches? I'm thinking, like, YC, for example.

Like, you have YC batch X, and maybe this is a version for open source where the Accelerate, is it called Accelerate? Accelerator. Accelerator. This Accelerator program that, you know, maybe this first batch is like, hey, we've helped these maintainers level up their projects. Maybe the GitHub fund is right after that for them potentially to like throw some money in there or whatever it might be. Is there a thought around that process? I hope with all the things... To repeat it.

Yeah, we'll definitely repeat it. I hope with all the things that we do that we learn and iterate, and I'd love to see us build more and more into the product so that we can make it available to everybody. Right. So maybe when you reach 5,000 stars, I know we were joking about it before, but when you reach 5,000 stars, we know you really joking about it before, but when you reach 5,000 stars, we know you really need,

it would be really helpful if you knew about GitHub sponsors and had a list of tips and tricks that work really well with it. And so we somehow surfaced that. Right. Behind the scenes, we were hearing that a lot of the activity on GitHub is done by one person in the repos. And that's kind of part of funding open source. There's a lot of activity in github

around open source and maintainers and whatnot that's in like a very small percentage is that how as part of github sponsors do you have active reach out to this kind of folks like are you looking at the one percent that's got a lot of activity how do you kind of quantify or narrow down who to help and how to help them. So GitHub sponsors, individuals and companies are deciding who they want to sponsor. We can obviously offer suggestions but ultimately it's down to you deciding that you want to give Jared

$10 this month. So you're handing out shovels and picks. You're not giving maps. We're trying to provide maps. We're not providing rules and saying you must turn right here. Well, when you said at 5 000 stars you may be so that me that that made me think you might have some proactive outreach i would love i would love to start doing that right but um but i want to say when you ask what's next i hope we

learn from the accelerator this round and learn you know who, who came, what did they learn, what was most valuable for them, what kind of problems are they encountering, and we iterate. But in terms of sponsors, the product, it's pretty much what it is until we get this new person to come run product, right? We have a team working on sponsors,

but we're hiring a new lead for sponsors and accelerator together. Because I know when we spoke with Devin Zugal originally when she was finished with her work there, and probably when we talked with Jessica as well, there's other ideas of ways of providing funding

for open source through sponsors the product that's not money. Well, it's money, but maybe you have like, so bug bounties is one idea of like well we have issues right we have all these things through sponsors maybe we could also provide funding through bug bounties and i remember asking devon about that and she had her ideas on it and then i think jessica had her ideas but in terms of like changing the product dramatically or like adding

to it you're looking for a new leader. Is that fair? Or you're like, are you? We're still working on the product. Okay. And we're hiring a new leader. Okay. And I would hope with things like bug bounty

that what we're doing is making it possible for you to host a bug bounty if you want to. Not that you have to have a GitHub bug bounty to sign up for. Sure. No, I mean, the idea there is like, well, you could just build it right into issues. And so you open an issue and say, hey hey I would love for this issue to be addressed here's a thousand

dollars or maybe we could all bid on it we could all say I'll throw ten dollars into the pot yeah exactly cool the money so like those kind of ideas maybe good idea maybe not a good idea but ultimately like the sponsor's team has to decide what's going to be worked on and so I was just wondering if the product's moving forward in the meantime while you're looking for someone to lead that team. And it sounds like they're still working on stuff. They are. But this accelerator thing is super cool, by the way. I remember covering it in ChangeLog News and seeing a bunch of projects getting money, and they're all excited, and they get mentorship too, right? Yep.

So hopefully... They get mentorship too, right? Yep. So hopefully. They get mentorship and a cohort. Yeah, I mean, hopefully that whole deal really helps them and then we can learn from it, like you said, and do it again. Because when I started in open source, it was definitely like everyone's dream was to get a paid job working in open source software. Right. And everyone that got one is like, how did you do that?

How did you convince them? What are you working on? Yeah. And that's been great, and it's expanded, and many of us get paid to work in open source. But I think there's more models that we could add to it. Absolutely. Is there a maintainer dashboard or a place that a maintainer can go

or something where they can go see, here's what GitHub Sponsors has available to me. And I'm thinking beyond just a place to get educated on how GitHub Sponsors can help them sustain their project, whether it's through donations, through sponsors. I'm thinking about even there's a lot of, I guess, SaaS companies, service dev tooling, they give away their tool for free to open source contributors

or to maintainers. And is there a dashboard to go on and say, okay, I can go get Sentry for free because I'm an open source. Or there's XYZ program where they may be spending their dollars on this stuff and they could be getting it for free. Like some way to say, here's my access to the maintainer kingdom that GitHub Sponsors has orchestrated for me. A dashboard that says I can do sponsors, I can get money from here, I can get support there, I can get cohorts here, I can learn about Accelerator here. Is there a place for that?

You can go read about GitHub sponsors and maintainers and GitHub funds now. We don't offer maintainers free software, but if you are a student interested in open source software and you sign up for GitHub Education, there's a whole student pack of free software that you can get. There's a

repo that you can find something along the lines of free stuff like you can get. There's a repo that you can find something along the lines of free for open source. Awesome. It's an awesome list. It is an awesome list. And it's just community maintained. And it's a list of sentries and bit buckets.

I don't know about bit buckets. Other things. Things that have a free plan for open source maintainers. And that would be one place people could go. But just throwing that in there. Well, to me, it seems like you'll have the great opportunity to connect dots. The dots are on GitHub. That's in a repo.

Right? It's in disparate places. We're always... Centralized. We're always looking for new ideas. Bringing it together. A maintainer dashboard. That needs to be your next big thing.

Where can I go as a maintainer to find out what's available to me to sustain? Funding, people, free services, I don't know. So when you say maintainer dashboard, what I always think about is when I talk to maintainers, they tell me, they're not asking what they

get for free. What they're asking is like, how do I know who contributes to my project? And how do I know who this person is? And the last time they were active, and did they submit this code on behalf of GitHub or Microsoft? Or are they an individual?

Right. That would definitely be a good thing to put in that dashboard too. A lot of things. A lot of things. We of things well isn't um we could create a project yeah there's kind of two sides to an open source project though there's like the running of it and the creating the software and like managing the community potentially finding contributors or identifying three time contributors who may you know get an opportunity to become a full-time or core team member or whatever it might be.

And then the sort of the somewhat lesser known business side of it, where like it's not really the business side, but it's not development, right? It's more admin type stuff. Like that's what I think this dashboard should maybe have is where it's like, as an admin of this project, what's available to me to sustain this thing? Not only just that, but those things too. That, and i think we need to make sure developers and maintainers have tools to to do their job well and to get funding whether it's through accelerator or get a fund or sponsors in a way that doesn't require them to become marketing and social media experts um yeah i kind of feel this way about all

small businesses not just software like right if you have a really awesome hairdresser or massage therapist, should they have to become business experts as well? In our current model, they do. Same thing with writing code, right? For the open source software developer community, how do we help them be successful businesses, in a sense, without having to go be marketing people? Yeah, right. Precisely. To a certain extent, that's being built through the dependency graph, right? So you have the distribution.

Of course, there's different kinds of open source, but let's just talk about libraries, right? Where I write a library, maybe it's really fast JSON parsing, and everybody starts using it. Now I'm in their dependency graph. And now when these companies come to GitHub sponsors and they say, we got 300 grand for the year. Here's the invoice, right?

It goes into my, I'm sure I get a wallet or something. I got a stash of fake money there that represents the money that I put there. And now I can divvy that out and you're showing them like, okay, you're using this project. That project's using super fast JSON library by Jared. He's available on GitHub sponsors.

And so trickle down in that way, right? Like that's what you're trying to build. Do you guys, is that there today? Like, can you do that today? Yes. It's not as simple as just clicking a button, but you can do it. You can see it at least.

And that's the goal. Like you as a creator should get some kind of compensation for the thing you created that is now powering businesses around the world. Exactly. So all these businesses, maybe they don't rely directly on me, they rely on this framework that uses me and the framework gets 10 bucks and for every 10 bucks they get, I get a buck. Yep.

Or whatever it is. Or maybe you get 10 cents if they use 100 libraries, but once a thousand companies use it, that adds up at some point. Right. And so now you have distribution of your software, but you also have distribution of your sponsorship along that same graph. I think that's one way to do it without being like, hey, I'm on Twitter

talking about my fast JSON parsing library. We do have someone who shames people on Twitter. They talk about using his product. He goes and says, oh, that's great. Would you like to contribute on GitHub sponsors? And he's actually pretty successful at it. Okay, so there's a hack. Yeah, I like that. But if you don't want to be that

guy or gal, you can just write a bot so you don't have to deal with it every time. There you go. There's always a bot for that. Bot Jared, bot Adam. Maybe the one more facet is how do maintainers get paid? How easy is it for them to extract the dollars from the donation from GitHub sponsors?

It's a Stripe payment in the background. Okay. So they have to maintain a Stripe account. Yep. Deal with taxes, of course. Is that a struggle? Is it a struggle that you all care about, I suppose? I'm sure you do, but like...

We're always listening to people and asking them how they'd like to receive money so right now Stripe seems to work for a majority of the people but the majority of the people that we're listening to are the people that have signed up we're also looking at partnerships with other funding methods to see what else we can add

big problems to solve Stormy fun problems thank you Cool. Big problems to solve, Stormy. Fun. Fun problems. Yeah. Thank you. Yeah, thanks. Thank you. So in the sponsor of Minisoad here in the breaks, I'm here with Tom Hu, dev advocate at Sentry on the CodeCov team. So Tom, tell me about Sentry's acquisition of CodeCov. And in particular, how is this improving the Sentry platform?

When I think about the acquisition, when I think about how does Sentry use CodeCov or conversely, how does CodeCov use Sentry? I think of CodeCov and I think of the time of deploy. When you're a software developer, you have your lexical, you write your code, you test your code, you deploy, and then your code goes into production and then you sort of fix bugs. And I sort of think of that split in time as when you actually do that deploy. Now, where CodeCup is really useful is before deploy time. It's when you are developing your code.

It's when you're saying, hey, I want to make sure this is going to work. I want to make sure that I have as few bugs as possible. I want to make sure that I've thought of all the errors and all the edge cases and whatnot. And Sentry is the flip side of that. It says, hey, what happens when you hit production, right? When you have a bug and you need to understand what's happening in that bug,

you need to understand the context around it. You need to understand where it's happening, what the stack trace looks like, what other local variables exist at that time so that you can debug that. And hopefully you don't see that error case again. When I think of like, oh, what can Sentry do with CodeCover? What can CodeCover do with Sentry? It's sort of taking that entire spectrum of the developer lifecycle of, hey, what can we do to make sure that you ship the least buggy code that you can?

And when you do come to a bug that is unexpected, you can fix it as quickly as possible, right? Because, you know, as developers, we want to write good code. We want to make sure that people can use the code that we've written. We want to make sure that they're happy with the product, they're happy with the software, and it works the way that we expect it to. If we can build a product, you know, this Century plus CodeCov thing to make sure that you are de-risking your code changes and de-risking your software,

then, you know, we've hopefully done to the developer community as service. So Tom, you say bring your tests and you'll handle the rest. Break it down for me. How does a team get started with CodeCov? You know, what you bring to the table is like testing and you bring your coverage reports. And what CodeCov? You know, what you bring to the table is like testing and you bring

your coverage reports. And what CodeCov does is we say, hey, give us your coverage reports, give us access to your code base so that we can, you know, overlay code coverage on top of it and give us access to your CICD. And so with those things, what we do and what CodeCov is really powerful at is that it's not just, hey, like this is your code coverage number. It's, hey, here's a code coverage number. And your viewer also knows. And other parts of your organization know as well. So it's not just you dealing with code coverage and saying, I don't really know what to do with this.

Because we take your code coverage, we analyze it, and we throw it back to you into your developer workflow. And by developer workflow, I mean your pull request, your merge request. And we give it to you as a comment so that you can see, oh, great, this was my code coverage change. But not only do you see this sort of information, but your viewer also sees it. And they can tell, oh, great, you've tested your code or you haven't tested your code.

And we also give you a status check, which says, hey, like, you've met whatever your team's decision on what your code coverage should be, or you haven't met that goal, whatever it happens to be. And so CodeCov is particularly powerful in making sure that code coverage is not just a thing that you're doing on your own island as a developer, but that your entire team can get involved with and can make decisions. Very cool. Thank you, Tom.

So, hey, listeners, head to Sentry and check them out. Sentry.io and use our code changelog. So the cool thing is, is our listeners, you get the team plan for free for three months. Not one month, not two months, three months. Yes, the team plan for free for three months. Use the code changelog. Again, Sentry.io. That's S-E-N-T-R-Y

Dot I-O And use the code changelog Also check out our friends over at CodeCove That's CodeCove.io Like code coverage But just shortened to CodeCove CodeCove.io Enjoy So we're here with Dawn Foster from VMware.

How are you doing? I'm good, thanks. Thanks for having me. What do you enjoy about conferences like these? What's your favorite part? Oh my God, it's the people. So you get to run into people that you've known for years. You get to meet new people. Yeah. You get to reconnect with people. You get to have interesting conversations.

And, you know, when we were all virtual through, you know, the pandemic and lockdowns and things, it just wasn't the same. It wasn't the same. You don't get those serendipitous conversations. Kara's not going to drag me across the room to do this podcast on a virtual environment. I never want to drag. Did she drag you? No, she didn't drag me.

She very kindly asked me if I would like to do one right now. You're a willing party. Kara was telling me that your PhD had something to do with the Linux kernel. And I was like, tell me more. And that's all I got so far. So can you tell me more? Yeah, absolutely. So a few years ago, I decided for my midlife crisis, I was going to move to London on a student visa and get a PhD. And so I found a university I liked, the University of Greenwich in London, and they had a center for business network analysis.

And I pitched them an idea to do network analysis and study the people networks within the Linux kernel. They said yes. They let me do it. And so I spent three and a half years studying the Linux kernel. And so I gathered a bunch of data. Three and a half years? Yeah, yeah, because that's what a PhD takes.

Okay, wow. Or it can take more, but I did it in three and a half. But, yeah, so I looked at collaboration within the Linux kernel. I looked mostly at mailing lists because that's how the Linux kernel works. Like, they don't use GitHub. It's not pull requests. It's patch diffs mailed back and forth on the mailing list. So, yeah, so I looked at mailing list data.

I looked at some source code data as well, but I just did a whole bunch of analysis. What'd you learn? So it's interesting. I also did interviews with some of the kernel developers. And one of the things that they'll tell you is that time zones don't matter. It doesn't matter where you're located around the world. It just doesn't matter.

And it turns out that's true. That's what the data showed, was that I didn't collaborate. I wouldn't collaborate more with you because we were in the same time zone. It just, for whatever reason, it wasn't significant. And it was interesting also, one of the things I found interesting is that two people who work at the same organization were also more likely to interact with each other on the mailing lists, which I found I was surprised by that, but

I really like it. So I like that companies are interacting in public on the mailing list instead of just, you know, sending each other Slack messages, walking over to somebody's desk and talking about something. Yeah. So I found that kind of interesting. I wonder if there's something about public mailing lists. I guess maybe they allow this research to even take place

because a lot of other forms of communication potentially may have not been reachable by you as an outside analyst, right? Yeah, exactly. So that's one of the beauties of open source, right, is that you've got all of the data because it's all in the public. I mean, now, so I do some work within the Chaos Project

and outside of the Chaos Project as well, but I spend a lot of time in the public. I mean, now, so I do some work within the Chaos project and outside of the Chaos project as well, but I spent a lot of time in the GitHub API and just pulling out data on open source projects and looking at what's what and just trying to get a feel for different aspects of the project. Poking and prodding. That's so cool. Poking and prodding, yes. So Chaos, this is community health. Help me out with the rest. Community health analytics for open source software. So, Chaos with two S's. Two S's.

Chaos. Chaos. Yeah, so we basically, I'll give you an overview of what Chaos is. We are a project and we're focused on kind of two things. We're focused on metrics, so defining metrics, so that we can be, when we talk about a certain metric, that we can be consistent about what it is and have a definition that we can point people to.

And we say when we're talking about numbers of lines of code, that's what this means. If we're talking about the bus factor, which is how many people you have contributing to a project, that we measure that kind of the same way. So we do metrics definitions, and then we do software. So we have two pieces of software within the Chaos Projects. We have Augur and Grimoire Lab, and those are both...

They're basically software projects that go out, and they gather a bunch of data from various sources, so GitHub, obviously, Slack, other things that you can... Basically anything with an API that you can get access to the data from. And allow people to analyze that using software. Very cool. So do you have some sort of a score or how does it, how do you quantify health? That is an excellent question. Thank you.

No, we don't have a score. Okay. And I am anti-health scores. Okay. So what I like to look at when I'm looking at Project Health is I like to look at trends. So, you know, are you closing more of your pull requests? Is your pull request backlog getting bigger or smaller? Are you responding to pull requests and issues more quickly or is it taking you more time? So I like to look at trends over time and I like to look at metrics in the context of projects because individual projects have certain ways of working and certain things that impact the metrics and unless you're part of the project, you don't you know, for example, if I work on a project and it's, you know, we're cutting a huge release that, you know, has a bunch of breaking changes,

there's probably going to be some weird things in the metrics associated with that. So, you know, pull requests are going to get in the backlog while you get everything together for the release, for example. I was talking to a friend at Google, Sophia Vargas, and she does a lot of analysis on things like Kubernetes. And some of the metrics that she was looking at it made just no sense because the way Kubernetes works is you've got bots that do all the things, right? So, like, you have bots that respond to things automatically. The bots close the issues automatically after a certain amount. You know, they go stale.

They close them. So there's all this, like, bot activity that she was looking at data, and she's like, this makes no sense. And she went and talked to some people, and they were like, oh, yeah, because that's the bots. That's what they do. It's normal to them. But unless you understand that, you can't interpret,

like, it doesn't tell you anything about the health of the project unless you understand what's going on within the project. Yeah. So it's a hard job, then, I guess, to quantify. And so when you say you like to look at trends, you're basically measuring the health of the project relative to its past health. Why is that beneficial, I guess, just to see where they're headed? Or I guess who, I don't want to say who cares, but who's actually... Who cares?

Who's the person or the org or the entity that says, I care about the future health of this project? Is it foundations? Is it individuals? I would come to it as an individual and think, this is why I'd want to score. It's because my question is, do I want to get involved in this project? Do I want to use this thing?

How's the health of the community? You know, I look at the GitHub Pulse tab, the insights. Not super useful, but it's there, right? Because I'm trying to gauge, is this a dependency that I'm willing to take on, perhaps? So that would be, like, one angle into caring about the community health of a project, overall health. And so I would like to see, like, well, I mean, trends would be useful, but if it's starting from a really bad place and it's trending up, but it's, like, still maybe not the nicest place to hang out.

Yeah. Long-winded question. Like, who are the users of your information, I guess? Who's the end user? Yeah, so it depends. I think all of those people are end users of metrics. And so part of the reason that I look at trends is because, let's just talk about from a VMware perspective,

from a company perspective. I want our maintainers to look at the projects and use the project health metrics to decide where they need to improve. So if they're responding to pull requests really quickly, then that's great. But if they're never closing any of those pull requests, maybe that's where they need to focus.

So it gives them a place to focus. And the reason I like to focus on trends is because what I don't want is somebody getting all hung up because their number's going down, but maybe it's going down less quickly, or it's it's improving in some way. So they're already, they've already made some improvement. And I don't want people getting hung up on just like the number because the number's less than it was last month or whatever. I want them to think about whether they're already improving. Is there something else they can do to improve? And then I think, you know, when you're

new to a community and you're trying to decide whether you want to participate in a community, I think those are a whole different set of health metrics. That's a different set. Yeah. I mean, I think that's things like, is anybody actually using this thing? Right? I don't want to contribute to something nobody uses. Right. Are there lots of other people contributing?

Do all of those contributors work at the same company and I don't work for that company? Am I even going to be welcome in this project? So I think there's a lot of things that you look at depending on what your goals are as a contributor and depending on what kind of project you want to contribute to. How do you represent this data? Is it on a website and I can go to like a certain domain and a certain org name and a certain project name? Like, is it like GitHub URL structured to get to this data? How do you, how can I go and find my projects that I'm interested in as data? How can I find that information? Yeah, so you kind of have to, if you're talking about it from a chaos perspective, you kind

of have to use one of the tools and load your project's data into it. And then you can access it. I guess better question is how does it work? How do I use chaos? Yeah, yeah. So we have two tools. So we have Augur, which I use within VMware myself. So the way Augur works is on the back end, it's a Postgres database.

So basically what it does is it has a bunch of workers that pull data from GitHub, for example, and puts it in a very nicely structured Postgres database. And then there's also, they're doing some work on the front end, so they're kind of making some changes on the front end. It's a little bit less mature. But the reason I picked Augur was because there were four metrics that I wanted to measure that I wanted our maintainers to look at. And so because it's just a Postgres database in the back end,

I can just write a whole bunch of Python scripts that generate the four charts that I want. And then we display those internally. We have a little internal dashboard that we use for that. And then we also use the Patergia. Say what? So it's Grimoire Lab. And there's a company called Patergia that does a lot of the work on Grimoire Lab. Okay.

So that's the other piece of software. And it uses the Elk Stack. So basically Elasticsearch, although they're migrating to OpenSearch, and a fork of Kibana called Kibitter. So it's more of that style. So it's not a relational database. It's like an elastic database. You can run queries, but it's got really big dashboards that people can use.

So that, I think, is great for community managers who really want to dig in on their individual project and want to know every little bit about it because the dashboards have all this stuff already in them and then you can write custom queries around it. So like Augur is more powerful if you want to write like Postgres database queries and display stuff yourself. Although they are working on the front end

and it's looking really, really cool. So like don't, I don't want just the Augur front end because there's some awesome stuff happening. And then the other one has like a more robust dashboard. But it's confusing for a lot of people. Like they don't know how to write those queries because they're not relational database queries. They're different. So it just kind of depends on what you want.

How did you get to those four metrics? Why are those the ones that are important to your team? Yeah, so I picked them. Recount them for us and then why. Yeah, sure. Yeah, so the four metrics are response time for, I pick pull requests, response time for pull requests. And so our guideline internally is that if someone submits a pull request, we should have a human respond to it within two business days. So I exclude the bots, and then I look at how many business days it took us to respond.

And then I chart that over time. And then I look at change request closure ratio, which is basically in a given month, there are a total of 100 open pull requests during that month. Did you close 90 of them? Did you close 50 of them? And how big is the gap between the number of pull requests and the number of pull requests you closed? So this is kind of the pull request backlog and whether you're keeping up with pull requests. So response time is good because new contributors want a response to their contribution. Everybody wants a response to their contribution. The pull request backlog is good because it shows that people are either merging pull

requests or closing them without merge. It's like throughput. Yeah. Because you don't want a huge backlog of pull requests. I look at release frequency. So I want to make sure that when they release bug fixes and security fixes that they actually land in a release in a timely manner. So those are not just like big releases, but like individual point releases.

And then I also look at contributor risk, which is kind of a bus factor type metric. So I look at, does a project, and these are VMware owned projects that we run these metrics on. I look at, you know, are there three people who are contributing 50% of the contributions to the project? Or is it one person who's contributing like 98%, in which, that's not good. But if you have a large number of people who are contributing across a project, then if one person left the company or retired or decided they didn't want to do it anymore,

then the project can more easily continue. So I picked those because I thought it was a representative sample of things that a lot of people care about. And then what I want the projects to do and the maintainers to do is then drill down and have other metrics. So like I said, we have a team using the Grimoire lab tools for their metrics. And then we have other teams that are doing like, you know, custom stuff out of the GitHub API, for example, to measure other things that they want to care about. What metrics hit

your cutting room floor? What metrics was important, but didn't make the cut? That's a good question. I didn't really, I didn't really approach it that way. I just picked the four that I thought were important. You just only chose four. I chose four. Drill was the first time. No requirements. I'm focused.

Okay. Focused. It seems like the importance of those metrics is, trying to paraphrase, contributor. You want, if I give a pull request, I want, as a human who spent my time and effort to give you the project some value, whether it's X or Y, some sort of feedback. But the other one where I think you were talking about the pull request backlog, and you mentioned, Jared, throughput, I've got to imagine that tells you, should we increase our team size? Or should we decrease?

Because we're just closing them fast. Maybe we're just fast. Or, hey, we're slow this time or three months consecutively. Do we need to add a team member? Should we incubate a new core team member, et cetera? Is that kind of how you look at it? It helps you identify risk. It helps you communicate with the community really well.

But it also helps you grow or shrink the team as necessary based upon the feedback. And do you recruit more contributors from outside the company? So do you get more people involved in the project because you're not keeping up with the contributions? How well is this idea used by other projects? This seems to be a very good idea. And how many people are using Chaos and Augur to kind of dig in like you have

to showcase this health? So lots of companies, actually. So I think lots of the big companies that have open source program offices have at one time or another used some of the chaos tools. Yeah, I hate to name names because I can't remember which ones I can talk about, which ones I can't. But most of the big open source program offices at the big companies have used the chaos tools and are involved in the chaos project.

So if you look at the people who are coming to meetings and being involved in the chaos project right now, we see people from Bloomberg and Microsoft and Google and Red Hat and all of the big tech companies. More specifically, why did you not score? Why did you not establish maladaptive, healthy, a score of 50? Why the pushback against the scoring? Is it too concrete? Do you need to be a bit more ambiguous in terms of that true health? No, it's because every project's different. So how do you compare a Kubernetes and give that any a, like any algorithm that you could put together

that would score something like Kubernetes and then compare it to a project that has like two contributors and, you know, 10 pull requests a month. Like any metric that you could score would give you wildly different results because those are very different sizes of projects. And they have different automation. They have different like release schedules every project's different so i want the project themselves to think about what do these metrics mean to me for my project

and interpret it in light of the other stuff that's going on with their with their project like you know like a release window for example or you know kubecon comes up and you see you see a drop across the board on like cncf projects like the week leading up to KubeCon where everyone's writing their talks. And during KubeCon and then, you know, you see it go back up. Right. So there's lots of stuff that can impact that. If it's a mostly European-based project, you see a big dip in July. Yeah.

Because we're all on vacation. Does it answer the question, are we healthy or not? Is that, what is it, what's the question specifically that it answers? Community health. Yeah, like, is it, because like, you can score health and say we are healthy or we're healthy-ish, and it can be specific to your repo, and I can understand why, you know, if it's a European team, why July might be less so, and it's not like, even as an OSPO, I might be like, are my projects healthy or are they less healthy? And if it says less healthy, oh, because it's July.

And that makes sense. Yeah. I mean, I think the question I like to ask is where can I improve? So that is where I try to focus on the metrics is being able to look at where I can improve. But you can use it as kind of a gut check for whether it's healthy or not healthy. So I do do that within the VMware projects. There's an arbitrary threshold that I've set where it's like healthy and at risk. So I don't define something as unhealthy.

I define it as at risk. And then maybe we look at those a little more closely if they've moved from healthy to at risk. And then we have other projects that are at risk simply because they're very large and my threshold is arbitrary and doesn't suit them well because they're a really big project. And my thresholds work really well for the average size projects that we have. So yeah, it just depends on the project. Makes sense. One last question for you. You said at a certain point, it might be time to recruit an outside contributor. What does that look like? How do you do that?

Again, it depends on the project. But a good place to start is by looking at the people that are adopting it. And so if you have people who are using your project, that's a good place to start to talk to some of them to see if any of them are interested in contributing. Sometimes you have people who've contributed a little bit. They've made, you know, a pull request or two. They filed a few issues, maybe encouraging them to contribute a little bit more to the project. But it depends on what the project's like, who's adopting it, who's using it. And what do you say?

Do you say we have a core team member slot opening up because, you know, we recognize we have a lack and we have more space for another team member? And you suggest to these adopters, hey, we have a slot opening up. Submit a request to fill it. Or do you have anybody available? How do you ask specifically? Like, how do you engage specifically? Yeah, so we don't I don't really look at it as a spot opening up. If you have an open source project, you're always looking for contributors. So you're always looking for more people to get involved. And ideally, your governance documentation will give you some guidelines for how you recruit new contributors. So a lot of projects have governance so that the existing maintainers recruit the new maintainers.

So they get to decide who gets to come in and maintain the project. Projects have governance so that the existing maintainers recruit the new maintainers, right? So they get to decide who gets to come in and maintain the project. So it depends a lot on your governance model. It depends on your project. It depends on what kind of contributions you're looking for. Are those governance documents different per project? Or is it sort of VM or at large government documents or governance documents? That's how it works.

No. They're different depending on the project. And I also work with a bunch of, so I spend a lot of time in the CNCF contributor strategy technical advisory group. And one of the things that we work on for CNCF projects is governance templates. So we have three different governance templates that we use for CNCF projects. And we encourage them to use those, but they're individual projects. They can use whatever governance they want. Sometimes they'll pick something else. But yeah, it varies widely across projects, even within the same company or within the same foundation. If someone's out there saying, wow, Chaos sounds awesome.

I run an OSPO and I've never heard of it. What should they do? They should go to chaoswith2s.community, which is our website. And we have loads of regular project meetings. We have working groups you can get involved in. And so I would say poke around there, and there's information on how to participate. And we're very welcoming to new community members

and new contributors. What's your time to pull request closure ratio? What's that? Yeah, that's a good question. I have no idea. No idea. Well, thanks for joining us today. This is cool.

Thank you, Dawn. Thanks for having me. Hey, friends. I'm here with one of our partners and sponsors, Jason Bosco, co-founder and CEO of TypeSense. You may remember Jason from episode 505 of the Change Law. We talked about TypeSense being truly open source search. And that's kind of where we got interested in TypeSense because we've been hitting bottlenecks and issues with Algolia. And so I reached out to Jason and said, hey, Jason, we'd love to work with you and partner with you.

But Jason, tell the listeners here why you all built TypeSense. What do you believe? So we believe that fast search as you type experiences need to be widely available and adopted by as many sites and apps as possible. And what I mean by search as you type is you type in a letter and it returns results right away in, say, less than 50 milliseconds or 100 milliseconds. And we've tried building experiences like this in the past with other products. You know, there's solar, there's Elasticsearch, there's Alcolia, and all of them are good in different respects. But they either are very complex to deploy or they're hard to scale or they're very expensive to use even for moderate scale. So that's why we built TypeSense. We open sourced it. We made sure

that you can run TypeSense locally or if you don't want to worry about infrastructure, we also have TypeSense Cloud. So you have cloud and you have open source and you ship binaries in your open source that you actually use in your cloud with extra features, of course. But what was making you think that you should build cloud in the first place? Based on what users have told us over the last several years, many folks wanted us to host the search service. So we started building TypeSense Cloud. So whether you self-host or use TypeSense Cloud, it is the same binary that we run in

TypeSense Cloud that it is the same binary that we run in TypeSense Cloud that we also publish open source. So the feature set is identical, but in TypeSense Cloud, of course, we manage the service for you. So you'd have to worry about infrastructure. And then we give you a nice UI to manage your data. And then we give you role-based access control, the single sign-on, more collaboration aspects. But regardless of whether you self-host it or use TypeSense Cloud, we want to bring this technology to as broad an audience as possible without having to worry about cost. And that's one of the reasons we decided to partner with you, Adam, and talk about TypeSense here. Yeah, I love the idea of getting thissearch or Algolia that you could just host yourself if you want to. That's

so awesome. Of course, we're excited to partner with you. We're using TypeSense Cloud, which is awesome and very fortunate to have a chance to work with you on this project. Obviously, we have so much more in store for our search feature, so we're barely scratching the surface, but Hey, listeners, check out type sense at type sense.org or at cloud.type sense.org. I think Jason's awesome. And he has an awesome team. And of course we're using type sense. So we think you should check it out too. Again, type sense.org or cloud.type sense.org. Drupal is still a big deal, right? Is Drupal still a big deal? I would think so. I would say Drupal is still a big deal, yeah.

So I know somebody who is big into Drupal. Well, I don't know him, but I know him. His name is Jeff Geerling. You know Jeff Geerling? Yeah. He's a big Drupal guy, and he's moving his stuff off of Drupal. You Drupal, right? On, I believe, WordPress, if I last look.

Oh, he's moving off Drupal? Yeah, Like he was self-host and do a bunch of stuff. So I think he was a big Drupal person, but I just wonder like, is the tide shifting away from Drupal? Is it still a big deal? What's the, do you know? I think what I would say about that is Drupal has kind of shifted where, you know, what it's really targeting at this point is like ambitious digital experience is sort of what we say. It's an open source data platform for all that kind of stuff. And what that means is if what you're doing is running a personal blog,

Drupal's probably going to be a really frustrating platform to run that on, to be honest. But if you're building, for example, a university website where all of the different departments need to have the same functionality but look different from each other and have different access control, it's really great for stuff like that.

Right. Yeah. Access control. So do you plug into SSOs and stuff like that. Right. Yeah. Access control. So do you plug into like SSOs and stuff like that now? Is there plugins for that? Oh yeah, there's plugins for everything. For sure, right? Yeah, plugging into SSO if you want different functionality and features,

you have click buttons for that, that kind of stuff. Gotcha. Are you still in the Drupal community? Like what's your state? Yeah, so. It's been a while since we talked to you. It has been a while. I know, yeah.

2018, the last time Angie's been on the show. it's been five years essentially a lifetime ago so yeah in tech especially it's like that was like seven lifetimes ago what's happened are you still involved with your with your state yeah so um so I ended up uh departing Acquia in 2021 uh or so because I kind of had gotten to the point where it's like okay I kind of saw Drupal through it's like you know it's a toddler banging itself on the furniture kind of stages and up into, now it's an adult with a stable apartment and all this kind of stuff. Right. Paying their bills. Yeah. You know, the releases are coming out on time. We're not having security vulnerabilities,

like these kinds of things. So it kind of felt like I, okay, I beat this level of my career kind of thing. And then I started getting into data platforms. So I went into MongoDB and now I'm at Ivan, which is a startup around open source data stuff. So they run Kafka, Postgres, MySQL, Cassandra, a bunch of other things. Yeah, wow. Yeah, so I would say like I'm less involved in the day-to-day of Drupal.

Like I used to know literally everything that was going on. I was on top of every issue. I was on top of every new contributor, that kind of stuff. But what I do get pulled in for Drupal now is like the kind of big strategic decisions, you know, like Drupal 7 end of life or, you know, things like if the Dries node is going to create a different strategic direction, they'll call me in to talk about that or core maintainership stuff, that sort of stuff. So it's kind of nice because I get to still be knowledgeable and involved with the big decisions in Drupal, but I don't have to bike shed what color buttons are anymore,

which is kind of nice. Well, I have to say that I really, really enjoyed the episode we did with you way back when. Yeah, that was fun. Episode 321, if you're listening to this. That's a good number. Back in October of 2018. It's a great number.

321. I just love the energy you brought to that community. Jared and I are very much departed from Drupal. We're not involved really at all. And I feel like you gave us the best 30,000 foot, maybe 12,000 foot view of that world. And you just had so much passion. You really just did.

I mean, you represented Drupal very well. And I still do. I love Drupal, you know, and I love that community. The software is really interesting, especially for kind of like those big projects that have a lot of different moving parts. Or I used to say Drupal is great if your client has no idea what they want, because it can do all of the different things that you need it to

do. But again, it's not such a good platform if you know exactly what you need as a blog, or what you need as a shopping cart or something like that. There are other platforms that are good more. So we're here as part of maintainer month along with GitHub and celebrating this community and open source maintainers. So it's been a bit since we caught up. So what's your maintainer story now? Like if you were giving a fresh view of your maintainer story, what is it? I think my maintainer story has moved to the point where I'm trying to sort of empower more people. So if you think about building out a leadership bench of your maintainership so that you're not solely dependent on individual contributors

that have been with the project for a long time and have a lot of historical knowledge, but really clearing the way so that folks newer to the project or who have new interesting ideas can come in and can take a leadership role in the project. So I'd say that's more the point where I'm at is sort of shepherding in new leaders, providing some mentorship to some of the incoming product managers for Drupal, that kind of thing. What's involved in that? Like, is there documentation involved? Are you writing syllabuses? Gosh, you should, right? How are you educating and on-ramping this leadership? It seems like just proving ground for documentation to some degree

because you can document the process and usher them in. I mean, when we set up the governance structure originally, because originally, like, it was me and Jarees. We were the two maintainers for Drupal 7, you know, and that was not going to scale as we built out. So we started by creating a core governance where we had different types of committers that would focus in different areas,

product managers, framework managers, this kind of thing, release managers. And so that stuff, the distinction between those is documented. And that way, you don't have to be someone that can cut across all of those areas. You can sort of focus on one area or another. So what my involvement has been is a lot more ad hoc,

just kind of like having one-off conversations with people. But you're right. I should start documenting some of this stuff because, yeah, it's good information for people to know. You probably repeat yourself a lot. Well, I don't know. I enjoy repeating myself. Positively, I mean that.

In the most best case possible. Yeah. So I find that I repeat myself a lot too. And I've learned that I can have limited bandwidth and have to begin to jot down and put down things that I do, particularly for our organization. And I've been executing on that and like getting that positive feedback loop from that effort too. So maybe you repeat yourself a lot. So maybe it's time to document the process. Do some thought leadership. Yeah. Well, you know.

Yeah. But no, you're right. You're right. It is true. Because otherwise the stuff that you're imparting kind of stays within that one conversation when it could be out there for benefit of everybody. But talking is so much more fun than writing. It really is.

It is. Yeah. I like writing too, honestly. But yeah. I just never shut up. So it'll be like 4,000 words. It could have been in 20. You could transcribe yourself, which is what we do for our shows.

This is being transcribed right now. Not right now. Literally right now. This is on the record. There is a buffer between now and the transcribed. Okay, right on. And then you could give it to your favorite language model and say, turn this into documentation.

That's cool. All right, I'm going to think about it. There's an idea. Here's a question for you. So going back to 21, you said you felt like you beat that level. You're ready for your next adventure. How do you decide what's next? Like, how did you decide what's next? How did you pick this area of work and what drew you here? Well, so Drupal had this amazing community, but largely consisted of web developers. Web developers who could stand PHP specifically. So that's like a pretty small...

It's a niche inside a niche. It's a little bit of a niche inside of a niche. Yeah, exactly. So what appeals to me about data platforms is that any kind of developer can use them in any kind of language, right? So you can be, you know, I have C++ developers doing embedded systems.

You can have folks doing AI doing embedded systems you can have folks doing ai and ml you can have web developers sure right and all these kinds of things and what interests me from a community management perspective because that's kind of my my deal and director of community i love i love getting people together and just like making awesome things happen is cracking that code do you know what i mean around those different language frameworks how do you what's the what's the venn diagram of things that these people have in common is cracking that code. Do you know what I mean? Around those different language frameworks. What's the Venn diagram of things that these people have in common? Right, where is the common thread?

Yeah, exactly. And Ivan is really interesting because it's the common thread among many open source projects. A MySQL developer and a Postgres developer don't necessarily have a lot in common. They won't go to the same user groups necessarily. But if you pull it up a level to open source data infrastructure, now all of a sudden we do have a lot in common, like they won't go to the same user groups necessarily, but if you pull it up a level to open source data infrastructure, now all of a sudden we do have a lot in common. So it's been a really interesting thing to kind of get involved in all these different communities, see how they each do governance and how they do different approaches to kind of the common things that maintainers deal with.

How do you triage incoming stuff without overwhelming people? How do you make sure you're keeping the platform stable, but also adding innovation? And, you know, seeing that as a bird's eye view across many different open source projects is really fascinating. How did that opportunity present itself? Well, the MongoDB opportunity presented itself because I know a guy named Jono Bacon, who is big in the community leadership space. Yeah, he's great. We know Jono. Yeah, and I kind of just, you know, we've kept in touch, and I kind of subtly was like, hey, you know, I'm not actively looking, but if you know of anything, just pass it along my way. And, yeah, he passed it along, and I was like, wow, this is really cool.

And so I got to kind of meet the different leadership at MongoDB, and I was like, these people are awesome. Like, they really believe in this, and, like, the story is amazing, and there's a lot of good I can do here. And I feel like I did do a lot of good there. But it gets into a lot of, I don't know how much you get into legal, philosophy debates around licensing and stuff. But MongoDB is not open source. It is SSPL.

We covered this. Well, not Mongo directly, but all the peripherals around the BSL, the SSPL. Yeah, yeah, yeah. SSPL. Right. All the- Mostly with a view into Elastic. All the nuance, yeah.

Elastic. Which is interesting because the OSI hasn't quite cracked this yet, right? Because if you look objectively at open source projects that have adopted these open-ish licenses, except if you're going to run your own service, it becomes a stable funding model for them. Like, you know, MongoDB's revenue went boom, boom, boom, you know. And the open source, true open source communities do not have that. And Amazon or somebody can take their product, productize it on their own thing, charge a bazillion dollars, and they don't have any obligation to give back anything to the project.

So it's a huge challenge. So I appreciate that about it. It has restrictions, though, right? Like the SSPL and the BSL both have restrictions, which I think is the sticking point. Yes, and that's why they're not open source licenses. It's obvious why there is a sticking point. It's not like, oh, well, we just can't call them open source.

Yeah. Because eventually open source is not open source necessarily. Now there will be people out there who will argue that, as you may know. And those people may even operate those companies who run that software that is BSL or SSPL licensed. And that's cool. But it is restricted.

So by the nature of restriction, it is not open. Exactly. But it is an interesting thing in that absent of having a sustainable recurring revenue model that you can build off a service to run your thing, you kind of have to do one-off projects or you have to beg for money from big corporate. Your funding options are much more limited. For sure. So I respected MongoDB a lot that they went after a solution to that problem. Even if it's not in keeping with the full spirit of open source, it was like, it's creative.

I give you credit for that. I think the community accepts the SSPL and the BSL licensed solutions you're talking about, though, quite well. You know, one in particular is a sponsor of us. It depends on which part of the community you're talking about. Yeah, but I mean, I guess what I mean by that is that it's not like, oh, you chose that, so therefore you're bad. Because you decided to go a route that funded your business or made your business sustainable. I think the sustainable side, more so than the funding side side is the part that you have to have empathy on. Because particularly Century would not be a company and be as profitable as it is if it was not BSL licensed.

If it was originally, I believe, Apache VL2, I could be wrong. If it was not BSL licensed, it would not have the funding model it has, nor be giving back to open source. So there's all these positives to that. And they're also very, you know, open source centric and very giving in a lot of cases out there in the community. There's a lot of good that's done. Definitely, but you have to...

But they're not calling themselves open source necessarily. No, they're not. That's where it gets icky is like, if you're BSL, okay, shout it icky is like if you're BSL, okay, shout it proud. If you're open source, officially, shout it proud, but don't play the game that's in the middle

because now we're getting to where it's like, eh. And then there's people who really don't care and there's people who really do care and then in between we all find ourselves, which way do you lean? And so it's hard to say the community accepts that. Cause I think there's plenty of people in the community that who don't, but there are plenty of who are. And then there's those of us in between. I tend to be like slightly over there to be like, well, it's better than nothing. I'm kind of on the

sustainability side myself. It's like, well, this is what I think is a good thing. And we would not have this good thing if it weren't for this particular circumstance that they chose. Maybe they could have chose something different and it would be okay, but this is what they chose. I'd rather have that than nothing. And so, okay. I think eventually open source is kind of cool, but open source right now is cooler. But maybe that thing wouldn't exist if there wasn't something.

It's true though. People apply different value frameworks. Yeah. Like what do you value changes. And then there's other people who are like, no, it has to be OSI compatible. And then there's obviously the FOSS side of things that has to be copy left, et cetera. And it's interesting because that's why these arguments can get kind of fractious because no one's wrong, right? It's like everybody has a defensible position in this whole thing.

This goes back to Adam Jacobs' war for the soul of open source, right? For sure. It goes back to what do you value and why do you come here, right? And we all have to kind of answer that ourselves. I don't know. What are your thoughts on these things? My thoughts on these things are I think the OSI needs some solution to this someone else can productize your service and make a bazillion dollars and you see nothing of a problem. Because I do think it's a problem.

Yeah. It creates an issue, since we're talking about maintainer month, where the actual maintainers upon which these millions of dollars are built are just logging it out on nights and weekends, ignoring their families, while you're making a billion dollars. That's a problem. I get that it's tricky, though, right? Because the whole ethos behind open source projects, there is no restrictions. It's free. Do whatever you want, right?

Including make money off the backs of that one guy in Nebraska, right, who's maintaining the event. Yeah, so I don't know. I can see all angles on it. But I do think that it's a clever way to make your open source enough project, open source-ish product sustainable. Because the financial speaks for itself. Yeah. to include some of these or one of these or come up with some other license or model that is inside of its own definition

but allows for maintainers to thrive under this one circumstance that's really kind of crushing certain maintainers. Yeah, I just think it needs to be grappled with. Yeah. And I'm sure it has been, but I think it really needs to be grappled with because just being like,

nope, this is the definition, this one little box and that's it. It's like that isn't working in 2023. And what you're seeing like actually like abandonment of open source licenses for things like BSL or SSPL because there's no open source solution. So in the same way, we have different variations of Creative Commons, for example, that allow, you know, require attribution, are non-commercial, that kind of thing. It feels like we need some model like that for open source licenses with whatever asterisks and disclaimers are needed.

Right. Without having informal framework for that, this is going to continue happening. You almost need a spectrum to address the spectrum, right? Yeah. Right, like a spectrum of licenses that move from one side to the other that allow you to slot in where it matters for you. Sure. Do you pay attention much to the OSI's

I guess news, so to speak? The last time I checked, they were like the SSPL is not open source. And that was like the title of the blog post. That was back in 2020 I think when we did the, I don't know when we did the episode. 2021. It was on Elasticsearch and

that debate they had between them and AWS. I don't think their position has changed. And again, it's a defensible position. What I mean is how they addressed it by It was on Elasticsearch and that debate they had between them and AWS. Yeah. I don't think their position has changed. And again, it's a defensible position. What I mean is how they addressed it, by any means. How they had gone back to the SSPL conversation and said, okay, worst case, here's the positive size to the SSPL or BSL licensed organizations that are doing this. I mean, if they're not going to call it open source, which is totally at their discretion and the committee's discretion who gets voted in and runs the board and stuff like that,

which is peer-led, it's a peer vote. Correct. So it's not like some randos are just running the OSI ragged or whatever. They're voted in. But they're voted in by folks that are way more on the, this is the pure definition. Because that's why the OSI was created, right? To defend the definition.

Exactly. Right, exactly. So it's sort of a self-replicating machine because it's like the people who are voting are going to vote for people who still believe. I don't know, though. In their defense, I wouldn't call myself an avid keeper-upper on top of OSI breaking news. That was my question primarily. Neither are we, which is why we're asking. That's why I'm asking you. And then the question, I guess, then, if you were, was when have they last addressed BSL or SSPL?

Has there been any positive and or negative? Maybe we can go back and... Yeah, again, not to my knowledge, but I mean... And they're like, I'm looking it up right now, you idiots. Yeah, well, hey, if anyone from the OSI is listening, please tell us. Because, yeah, if there is something in the works or already happening around this funding sustainability issue, great. So where does Ivan fall in this world? Oh, yeah.

Is it purely open source? Yeah, so the reason I like Ivan is because all of the underlying data technologies are actual open source with a capital O and capital S. So they got streaming services built off Kafka. Or it's not even built off Kafka. It's like you get Kafka. is because all of the underlying data technologies are actual open source with a capital O and capital S, right? So they got streaming services built off Kafka, or it's not even built off Kafka, it's like you get Kafka. We manage it for you so that you don't have to panic. Because Kafka is apparently a nightmare to manage is what I'm reading out of things.

That's the key to having an awesome open source infrastructure project to build businesses around is it has to be really valuable and really hard to manage on your own. Yeah, yeah, yeah, exactly. I just had a conversation with Red Panda's founder, which is probably in your neck of the woods because they essentially are a better version of Kafka.

Yeah, okay, right on. In their terms. Yeah, yeah. No, I like Ivan because they don't, they don't want, they legit don't want vendor lock-in. Like if you, if Ivan makes you angry, you can take your Kafka and move it to Confluent or whoever you, I'm probably not supposed to say that word. But anyway, you know what I mean? It's fine. Because we're selling, what we're trying to sell is like, hey, we're the security layer on top of your thing. We're going to do the updates for you, like this kind of stuff. So that you can then be

like, great, I don't have to worry about that. I can just write the stuff my business cares about, because they don't care if I'm running a Kafka cluster. They don't care about that. They care about the results that they're going to get. Right. The other thing I like about them is, you know, a lot of companies will try to make money off of open source. Like that's, you know, why we're all here. Right. It's like this conference is, you know, very enterprise. How do we profit? Yes. How do we profit? But they have an open source programs office, for example, and they hire like Kafka core maintainers to make sure that the software that we're selling to our customers stays well maintained. So that's why, that's what kind of office, for example. And they hire Kafka core maintainers to make sure that the software that

we're selling to our customers stays well maintained. So that's what kind of drew me there is it aligns really well with my values. And I still love MongoDB, still love Drupal, but that idea of building something that can really be used to build anything and all powered off true open source stuff, that's awesome. So that's why I'm there. So what is it you do there then, particularly? Yeah, yeah. What is your role? Yeah, I'm director of community.

Okay. So that means that we're, you know, handling meetups. We're doing things like our community forums, our real-time communities, that kind of thing. Trying to bring together practitioners of open source data infrastructure broadly, whether we offer it on our platform or not, to kind of come together and talk about the problems that they're having and some of their pain points and some of their tips and tricks and stuff like that. Because it's a really fascinating thing to be part of. And, you know, a lot of people don't realize that there are open source alternatives for

like data warehousing or some of these other challenges. So, yeah. So that's why I'm in it. Do you interface with the Auspil by any chance? Yeah. Yeah. Okay. Yeah.

I mean, with the caveat, I've only been there like three weeks. So like, who knows? But yeah. Yeah. The the Ospo people are amazing and it reminds me a lot of the work that we did at Acquia around Drupal right it wasn't called an Ospo but it was very much like what's the best thing for this project right that's the thing we have to focus on whether or not it's good for the business as a whole because those are they're separate but hopefully there's a Venn diagram but they could be separate and competing concerns every Every OSPA has a level of maturity. What do you think yours is at?

Without calling it immature, what level are they fighting against? Honestly, I don't know if I'm qualified to say that, but I mean, they're in the to-do group. They're a member of the OpenSSF, so I feel like they're doing the right things. They're contributing in the right ways. Right, and they're also employing, you said, Kafka maintainers and stuff like that? Yeah. And yeah, there's Post and stuff like that? Yeah.

Yeah. And yeah, there's like Postgres, a couple of people. There's like, you know, from different, like, you know, again, they want to make sure that the technologies that we rely on for our customers stick around. Right. And I think that that's really awesome because not, they wouldn't have to do that, right? They could just sell the stuff and not give back, but they're choosing to do it. So yeah.

Cool. But on the maintainership thing, yeah, I do think that that is a general problem that people need to think about is like right now you're in this, you love it. You know, you can do this the rest of your life, but realistically your life's going to change over the course of your life, right? You maybe, you know, get, you know, different hobbies, maybe your interest in technology's changed. Maybe you have a kid, whatever. And so it's really important to think about that as you're maintaining your product and your project to make sure that you're thinking about who's going to take that on

when you have to step away so that you can step away when you need to. Yeah. One of the themes for me, I didn't put in my notes actually, one of the themes for maintainer month and maintainers, I believe, is like essentially finding a way to step back, finding a way to have succession planning and stuff like that. Do you, as part of your leadership, talk at all about that, like that kind of maturity of a maintainer and supporting folks that, to anti-burnout essentially? Yeah. Yeah. So we, we do things like have what are called, oh my God, what is the word? This is so bad. Ah, provisional, that's the word, provisional maintainers. So we find people that are kind of active and doing the right things in the right

subsystems. We'll kind of find those people, pull them in and say, hey, would you like to become a provisional maintainer? Provisional maintainer doesn't get commit access necessarily, but they are allowed to like make, okay, this RTBC, sorry, reviewed and tested by community patch. It's like, it's gone through the review process. This patch is good to go and they can escalate its committer to actually commit it. And after they've done that for a little bit of time, then we do give them commit access, but maybe just to their own subsystem and not the whole of core. And then later they kind of grow into that.

So we have like a progression model. What we're also exploring is the idea of term limits on a committer as well. Because terms and term limits, I should say. So terms meaning you're not signing up to something for life necessarily. Why don't you sign up for something for say three years? And we stagger it so that not all of the committers come on at the three-year mark and then now there's no one, right? But like stagger it so that, you know, there's still a group of people to help bring on the new folks. But then it's a lot easier to make a commitment or for your business to make a commitment

if you're employed by somebody to say, okay, we can pay you for say 20% of your time for three years, that's an investment we can make. Versus 20% of your time indefinitely is a lot harder to ask. And then we're talking also about term limits, which means once you've done, let's say two three

year rotations then you have to take a year off and you know if you want to come back great but otherwise like we're going to make you go out there build some stuff you know and get get familiar with what the field is doing that yeah see if this is still what makes you passionate and it's kind of a forced vacation yeah in a way in a way it is yeah because there's a lot of people who won't take vacation. They'll just burn themselves out. Exactly. They'll take the money instead of the vacation.

They just keep working through it. Some companies allow that, but this is kind of like, it's kind of like that. It's forced vacation. It is, and it's coming from a place of love. You know what I mean? It's coming from a place of you're probably not going to do this unless you're forced to, but forcing you to really gives you that, huh, okay, like I don't need that responsibility anymore.

And then if I want to go back willingly, I'm able to, but we're not stuck with people who maybe should have moved on a while ago and just feel like they can't because they're like everyone's depending on me, you know, that kind of thing. So they feel like that, but it's not, it's kind of true, but it's kind of not true. They're like that person should really take a break, but they will not. So yeah, I mean that was the thing, like I stepped away and I was super true, but it's kind of not true. They're like, that person should really take a break, but they will not. Yeah, I mean, that was the thing. I stepped away, and I was super active, but it's like Drupal's still fine.

You know what I mean? It's like Drupal's doing fine. Everybody's still getting their stuff done. And it proves that out, that even if someone is neck deep in everything, it's fine. Step away. If you need to step away, the project will figure it out. I had this epiphany a while back because I listened to and read Seth Godin's book, Lynchpin. Okay. And if you read, have you read that book or know of it? Well, Lynchpin essentially is like, you're crucial. The Lynchpin in a wagon wheel was what kept the wheel on the thing. So if you're the Lynchpin, you've got to be there to do the job so that the

wagon wheel stays on the wagon and the wagon keep moving. And I learned a long time ago, I'd rather be a cog because at some point somebody else is going to like be better or be more hungry than I am. And I'm not really the linchpin I thought I was. So might as well just be a very purposeful cog. I do my job well. I serve my team well. And I don't have to be a linchpin. I can be very important. I can have an important role and play a crucial role, but I'm not a linchpin. I'm more of a cog in a better machine, I suppose, to get the things done. Let me give you a slightly different analogy. Sure. Because yes, and think of yourself as like you're like the drummer in the band, right?

Right. The drummer in the band kind of sits back, just kind of does his thing or her thing, and makes sure that the beat's going on and this kind of thing. And then you let someone else be the lead singer and the guitarist, you know, like doing that kind of stuff. You know, because you still have a really important role to play. For sure. And I don't think calling yourself a cog is like doing service to that, you know, because

it's like... Well, every once in a while you have a drum solo. Yeah, yeah, yeah. Every once in a while. But not the whole time, right? Like, let other people shine. No, if it's the whole time, people start walking. Tiny cymbalra is just noise.

You can't have the whole thing be a drum solo. The reason I think I came up with cog was there was an analogy between linchpin and cog. Oh, all right. Because the cog is like

the thing that is just part of the bigger clock. But the clock wouldn't work if one or two of the cogs broke, right? It wouldn't take time the same way. Not to nitpick your analogy,

but while we're doing this. Sure, please. This is Jared's MO. Please. Tell me different ways of analogies. I'll tell you you're analogy, but while we're doing this. Sure, please. This is Jared's MO. Please. Two different ways of analogy. I cannot wait to hear this. If you pull a cog out of something, it's still gonna bust. So isn't each cog in its own way a linchpin?

I think the yes. To use Andy's. Yes and. So a linchpin is like it all breaks if I break. It all rests on my shoulders. There's far more superiority to some degree, so much more pressure. Whereas if you're just a cog, you can be replaced with another cog that's similar.

Oh, I see. Whereas a linchpin is like, there's only one of me, and if I break, everything breaks, and there's no replacing me. Okay. So you can't buy another linchpin. It's challenging. Well, linchpins are hard to come by. Okay.

I didn't know that part, so I think the analogy holds better. I didn't also know that part. I figured a linchpin, you just got another one somewhere else. Shove it in there. Maybe a stick if you need to. I don't know. You could just stick my break eventually. Just MacGyver something in there.

Some duct tape and some safety pins. We'll have to actually get Seth to talk us through this. Okay, because he uses that exact analogy. The whole book's called Linchpin. He tells you to be a cog, though? No, he says be a linchpin. Okay. Oh, that part I get.

But the cog, you pulled the cog in. I said the cog. This is me. I made this up. I'm like, I love that book. I love the idea of that book. But I don't want to be so focused on my importance that I have to be this linchpin with all this pressure on me. He tells you to be the linchpin?

Yes, he tells you to be the linchpin. Well, I guess there's job security in that, but it seems like I'd rather be a cog. It's a lot of pressure and a lot of responsibility. I'd rather be a drummer. Yeah. Keep the beat. Keep the beat. Yeah, keep the beat. It's like, linchpins are great

for a business, but they sure do get divorced a lot. You know what I mean? It's like the 10Xers. It's like the linchpins. Be the 1Xer. Be the one Xer. You know, that might run things poorly. You know, it's the, I'm very important. I can't be replaced. I'm super crucial. And yeah, there's unhealthy balances. I'm sure that ensue as a result of calling yourself a linchpin. Whereas if you're a very purposeful cog that that's, you cog, that's where I fight for. If I know my purpose and I can deliver that purpose and I'm for team, because a cog is not an individual.

A cog is not an individual. It's a part of a larger whole. Exactly. So if you understand the working system, you're part of the working system. But if you're a linchpin, it's like, well, it doesn't work unless I work. I see. You know what I mean? There's a difference in psychology there, in my opinion.

I like it. As long as you have some spare cogs. Because otherwise, you pull a cog out, the whole thing falls apart. For sure. Especially on a watch. All right, Angie. Well, thank you.

Thank you. Yeah, it was wonderful catching up with you guys again. It's always fun. Okay. You know, I really have to agree with Dr. Don Foster that catching up with people is really, really good. Jared and I really enjoy this hallway track series we do. When we go to conferences like this, it really takes a lot out of us, but it also puts a lot right back into us because we get to do shows like this, to have an anthology episode like this with many voices, many perspectives on how to open source, how to maintain open source,

how to support open source, how to love and support open source software maintainers. This is why we do what we do. Because like you, our lives depend on open source software and therefore open source software maintainers. So if you haven't yet, head to maintainermonth.github.com and find ways to participate and celebrate maintainer month. They've got news, a schedule, and a library of resources to tap into. Again, maintainermonth.github.com. And also thank you again to our friends at GitHub for helping us get to Open Source Summit 2023 this year. It was an absolute blast. We met so many

people and it was an awesome experience recording all these episodes. And once again, a big thank you to our friends at Fastly, Fly, and also TypeSense. But that is it. This show is done. We will see you on Friday.