The Changelog: Software Development, Open Source - Every commit is a gift (Interview)

Episode Date: June 10, 2021

Maintainer Week is finally here and we're excited to make this an annual thing! If Maintainer Week is new to you, check out episode #442 with Josh Simmons and Kara Sowles. Today we're talking Brett Cannon. Brett is Dev Manager of the Python Extension for VS Code, Python Steering Council Member, and core team member for Python. He recently shared a blog post The social contract of open source, so we invited Brett to join us for Maintainer Week to discuss this topic in detail. Thank a maintainer on us! We're printing a limited run t-shirt that's free for maintainers, and all you gotta do is thank them, today!

Welcome everyone, this is the Change Log. We feature the hackers, the leaders, and the innovators in the world of software. May 10th week is finally here, and we're excited to make this an annual thing. If May 10th week is new to you, check out episode 442 on the feed with Josh Simmons and Kara Soles. On today's show, we're talking with Brett Cannon. Brett is the dev manager of the Python extension for VS Code, Python steering council member, and core team member for Python. He recently shared a blog post, the social contract of open source.

So we invited Brett to join us for maintain a week and discuss this topic right here on the changelog. One more thing. We want you to thank a maintainer on us. We're printing a limited run t-shirt that's free for maintainers. And all you got to do is thank them. Check the show notes for details and a preview of the t-shirt. Big thanks to our partners, Linode, Fastly, and LaunchDarkly. We love Linode.

They keep it fast and simple. Check them out at linode.com slash changelog. Our bandwidth is provided by Fastly. Learn more at Fastly.com. And get your feature flags powered by LaunchDarkly. Get a demo at LaunchDarkly.com. This episode is brought to you by Influx Data, the makers of InfluxDB, a time series platform for building and operating time series applications. InfluxDB empowers developers to build IoT, analytics, and monitoring software. It's purpose-built to handle massive volumes and countless sources of timestamped data produced by sensors, applications, and infrastructure.

Learn about the wide range of use cases of InfluxDB at influxdata.com slash solutions, network monitoring, IoT monitoring, infrastructure and application monitoring. To get started, head to influxdata.com slash changelog and click Get InfluxDB. Again, that's influx week, which is awesome. And we love maintainers. And today we're talking about the relationship between a maintainer and a user and this idea of the social contract of open source. And today we're joined by Bretttt i mean dr brett cannon brett how are you i'm good thanks how are you too first i'm over calling you doctor yeah what's up with that so official phd in computer science bachelor's in philosophy a long time in school that's the deal with that there you go well once you do the time you have to do the crime i guess

or you have to get use of it. You got to get that doctor on there. Why not? Yeah. Well, and that's the funny thing, right? Like you come out of school after all these over a decade post-secondary and it's one of those like, yeah, you have a PhD. You can be called doctor and no one cares. Understandably.

But it's one of those weird things, right? Like it's not on your credit cards anymore. It's on my boarding passes for flights. I use it whenever the form for like your prefix, the, how to address you comes up. If it's there, I use it. But honestly, most of them don't even have it. So the only time I ever use it was when I give a presentation, I stick it in front of my name on that title slide and I don't even say it when I announce myself. So, you know, unless you're in a public place and somebody's having a seizure and now they want a doctor.

Not me. Is there a doctor in the building? I keep my mouth shut. Wrong doctor. Wrong type of doctor, at least. Not practicing medicine. Practicing computer science, of course. Was it worth it, the effort?

Did it pay off? No. Are you happy with the time you can't even get doctor on his credit card that's not paying off so the advice i always give to people when they ask me this in general as i say i found the master's degree worth it the phd you should only do it if there's something you very specifically want to research to that extent and you're passionate about because there's a lot of bureaucracy to a phd and you do research there's a lot of stuff you got to do that's just kind of

and unless you really want to go into teaching and become a professor or something it doesn't at least for me in my case because i i thought i wanted to do that because i come from a line of teachers i thought that was potentially what i wanted to do and then i realized i actually didn't want to deal with assignments and finals i just like teaching people that yeah you know what i'm good so i decided just to go to industry instead i didn't meet my wife during my phd so i got i did get something good out of it yeah priceless that was actually playing softball that was not actually in any class or anything it was during that time though it was during that was actually playing softball. That was not actually in any class or anything. It was during that time though. It was during that time.

She was attributed to the, yeah, okay. Yeah. So you became a doctor of love. That's right. I don't know if she'd agree to that. Dr. Brett Cannon love. Well, we have you here because in addition to all of this, you have long time experience with Python.

You're on the Python Steering Council, a core team member, and been doing it a very long time. How long have you been involved with the Python project? Remind us. Depending on your definition, I got my commit bit April 18th, 2003. But I joined the Python Dev mailing list

mid-June of 2002. So you can use either of those as the start points, but I typically just go with the commit bit because it's a bit more fun to be able to point to my very first commit in the repo and say, that was it, that's day one. So it's been over 18 years. Yeah, so you're pushing two decades. Longer than my web career.

You got me beat. Yeah, it's a long time. I didn't start actually doing email web until like 2005 so oh wow yeah you got your commitment before i'd evenly pushed html to the internet good way to make me feel old there adam i appreciate that it was geocities even i mean like feel real old brett oh oh geez yeah i remember my first 28.8k modem on earthlink back in the day and then being one of the first people i knew who got uh cable modem i think that was like a five meg connection which was major because it allowed me to download the i think it was first diablo demo that was 50 megs

and i leave my modem running it was on my modem i leave my modem running all day long while i was at school in high school to download that 50 meg demo for the first time. Wow. And it crapped out the first time. So I had to do it a second day. But yeah, I remember my first blog on Earthlink and uploading it to, you know, back when everyone had like earthlink.net slash tilde, like your email address and all that stuff. Good times. The good old days.

Yeah. There were days. They were actually bad days i remember when i was trying to load ign which was still i think it's still the same website which is like video game reviews and news and stuff and i was on uh what's the next one up from 28 like a 54k modem i don't know 54 yeah 54 56 yeah somewhere in the 56 is 28 times two there you go brings it well and there was a picture of a new zelda game or something and i remember like being all about this picture and it was

loading in one line at a time just like like pixel by pixel and i'm like here it comes you know like 30 i can see like link's head you know and it just took i mean minutes probably seven eight minutes to load in that picture but i I was super stoked. Remember all those articles back in the day talking about the various ways to progressively load your images, right? Back when every kilobyte matters. And now most websites are like measured in the megs just from JavaScript alone to load.

It's just a very different world. Very different world. Well, the cool thing is that you've been around for a long time. That's sort of like part of your journey too, like what you've been doing. I didn't realize you got a commitment to python that far back that's that's like what we just said more than my entire career yeah it was far enough back that so i took a gap year between my bachelor's and starting my master's program because jumping from a philosophy

degree to computer science i knew i was going to have to kind of build up almost like a programming resume to prove to master's programs that I know what I'm doing. Cause I took some CS courses. I did my undergrad at Berkeley and I was able to squeeze in some courses. There's a long story as to why I couldn't even pull off a minor due to unit caps and blah, blah, blah. Anyway, I took a gap year to try to kind of build up a portfolio so that when I applied to those programs, I could say no i do know what i i'm doing please let me in without that bachelor's degree and i was able to do this and get involved so i got the commit bit and then i showed up in my master's program and so people like oh yeah what do you do for fun blah blah so i could choose this open source project called python and half the time people

go what's that? And the other half would go like, is that that language where white space matters? And I mean, nowadays, I can't remember the last time I ran into someone who didn't know what Python was. So it's very much an interesting and wild progression of popularity and just my open source life with Python to see it go from

people not knowing what that is to top three programming languages in the world relying upon it uh helicopters landing on mars because of you know some of the underpinnings of that's right yeah we have martian helicopters we we get your cat photos on instagram uh i don't know the state but for a long time all your youtube videos were thanks to python. It's crazy. It's a big deal. So we want to fast forward to today and talk about a very interesting article. I think you have a keynote, you have a presentation, you've been talking about this social contract of open source.

So you've been doing this for a very long time. You've been a maintainer of the Python language and the community, really. A participant in that community and kind of a maintainer of the Python language and the community, really a participant in that community and kind of a maintainer of the community to a certain degree, helping guide these new ways of doing things with the steering council and the voting. And there's just been a lot involved there. And here you are, April 25th, 2021, talking about what you view as the social contract of open source. You've also talked about kindness on the show before so very much i don't know if that's the philosophical side but it's very much the human side of the open source scene that you have you have thoughts you have opinions

can you share with us kind of the the big picture what you think this contract is and we'll dive into the details yeah i should admit my wife andrea is in hr which probably adds to my caring about community and how people are treated and how that works. And then my mother was a fourth grade teacher. So that also kind of ties into be kind to each other because this great grand experiment with open source does not work if we don't treat each other well right both from a maintainer contributor and user perspective because there's cascading effects if someone comes into a project and starts to chastise you or be Rudy or miss you and just basically abuse you I mean it really does come down to psychological abuse and i know it's a strong term but it really can get pretty bad it leads to burnout right literally people just have to walk away for their own mental safety

to be able to keep doing open source so or just to not even do open source that's the problem they burn out and they walk away and they stop and then that has a cascading effect then that users don't get that software anymore because guess what? They're gone now. And same with contributors, right? If someone's being abused as a maintainer, that typically can eat into them becoming grumpier and not wanting to do open source or being grumpy when they do do it and feeling negative towards it and makes them rude in terms of dealing with the community and all that. And it can become a very nasty cycle of just negativity. And so for me, it's a little frustrating to an extent that this still has to be said, but I think kind of just inherent to the way the system works, that open source is just this huge, wide, broadly global thing that I think

if we weren't in, most of us just would never have this level of exposure to the rest of the world, that just learning how to interact with others from different cultures and different places with different expectations has certain requirements. And part of this being kind and setting proper expectations as well because there's interactions and then there's setting the expectation of it all, right? Because to me, open source is a gift and it's a perpetual gift. Like every commit is a gift to the world that me as a maintainer have chosen to give out because I just want it to, right? For whatever reason. But when you stop viewing that as a gift and start viewing it as something that you're owed or expecting, it shifts your mental model. And it leads to you feeling like you're people in a position to be mad at you, right? Like I didn't

get a release on when I expected. I didn't fix this bug. I broke something. I said I was going to try to do something. I didn't do it. People get really agitated. And I get it because some people are having a bad day. Their company depends on the software or whatever. But I'm also choosing to do this either in my free time or because work was lucky enough.

I'm lucky enough to work at a company that's put some time into Python. It's open source. Or work pays me to work on open source because the python extension 3ds code is open source as well but that doesn't mean people should feel like it's okay to come in and be mean and rude and trying to set this proper level of expectation of how to interact with each other and not basically get worked up is this message i'm trying to get out so that hopefully we can all kind of step back a bit realize that all these volunteers and all these maintainers are mostly doing this other kind of their heart and how to make sure that we can foster that kindness so that they can continue

continue to do this so that we all benefit right maintainers get to keep doing what they love and enjoy users continue to get wonderful free top quality software because they just want to and contributors get to help mold and shape and move that software in a way that they need it to go. And just to also support the maintainers and maybe eventually become maintainers themselves. But if we don't basically make this, I mean, to be kind of cliche, a circle of love here and appreciation, it won't last. And I really want to make sure this continues to last. And I don't want it to last because we managed to get enough fresh blood who are willing to put up with stuff to replace those of us who burn out. I'd rather have it be, oh, everyone sticks around for as long as they feel motivated enough for it,

not because people burn them out, but because they just love because it's just their time. Yeah, that's why I like this idea that open source is a gift, that these commits are a gift because that sets the expectation. I wonder if, you know, whomever might be an abuser out there, to some degree, maybe unintentionally, maybe it definitely moves into intentional because maybe the clarity of the expectation from that user perspective or could be an organizational user, it could be an individual user to a community to an individual maintainer to you know the core team to python itself or to any open source project i just wonder if it if this idea that open source is a gift sets the lens so to speak that what is to be expected is literally a gift rather than, you know, payment. Like, you know, I'm here as a user. I have needs of this project. You must show up because I have needs.

That doesn't set a good expectation. And I wonder if this idea that as a gift, it sets a more clear expectation of open source at large that I show up and get used to the software. And that's great as a gift. It's not that because of that or because of my need for it or because of my business's, you know, critical usage of this software

now makes you have to show up every single day. That you show up every day is a gift. Yeah, like the blog post that Jared alluded to, I use the analogy that it's like putting a bunch of USB flash drives on your front lawn with a sign that says free, right? Like every commit to some project is going to be on that flash drive. It's the Git repo, right?

And you can just come by and grab it and do whatever you want with it. And as long as I'm enjoying myself, I'll keep refreshing that pile of flash drives. But does that give you the right to come to my front door and leave a flaming bag of something because you're upset that how i did something right or leaving an angry letter or standing from the street screaming that brett cannon makes horrible software and you should never listen to him and he ruined my life because he took away this api or something now that isn't to say that people could end up with certain expectations right like tidelift's model of paying the maintainers so that they actually do have a financial, not only incentive, but almost expectation to do certain things.

That makes sense. And I do understand that. And I think that's great. But for a lot of people where they're not being paid to work on this stuff, that expectation I don't think carries over. I don't think it's a, that expectation always holds. Oh, good luck getting paid for it. I hope you do. I don't think those are equivalent. I think the transaction here is different. When you start to receive money for your open source work, which I totally am accepting

of and support, and I think it's great when it works out for people, that says a certain expectation. But when it's a volunteer, I think that completely shifts it, right? You don't go to the soup kitchen and yell at the person spoon that completely shifts it right you don't go to the soup kitchen and yell the person spooning out the soup because you don't like the soup right like that's not right yeah and this is not to equate open source to helping the homeless here but the point is is they're all volunteers and you need to recognize the fact that it is volunteerism right it's taking away time from family and friends and whatever. Like we are all here on this planet for a very finite amount of time. And I am choosing to spend part of that finite amount of time creating software that I'm going to give out to the rest of the world,

right? And that's my decision. But be aware of the fact that that has a cost, right? People forget that. Like I'm literally using up my time on this planet away from family and friends to do this for whatever reason but i think if people kept that in mind more there'd be a lot less agitation and anger and just frustration at people when things don't work out because you know otherwise you just don't use the software or i could just yank it off right there's nothing talking this there was a world before open source it's not like the world's going to collapse if my software that's happened before the yanking off and taking away and you know things like that i mean there is this backlash and you know this is maintain a week this week is a collaboration

between the community github tie lift we're obviously putting something out on thursday this is for upstream here in particular you know but this week-long thing is meant to be a place for maintainers to gather to share and to be celebrated and so i think you know, but this week long thing is meant to be a place for maintainers to gather, to share and to be celebrated. And so I think, you know, part of what your post did was define that lens between maintainer and user. And so that I think if you can have a clarity between relationships, you can have a clarity of expectation to, you know, what's your role in this relationship? What's a user's role in this relationship? And what do both get equally from it and what can be expected from either? Because then you can have a position to understand the necessary kindness, the necessary empathy to show up and to give freely as a volunteer or to take freely as a user of free and open source to use this gift to the world. Yeah.

So I think a good way to summarize that is there's a separation between the person and the code. And I think a lot of us forget that. In the blog posts, I talk about Immanuel Kant's categorical imperative and philosophy degree kicking in there. There you go. And part of what that says is don't treat people as a means to an end. Treat them as an end in and of themselves. Right.

And basically what that means is don't treat people as something to get from them. Treat them as human beings as they are and on their own. Right. Don't go to a maintainer and say, oh, you're the way I'm going to get this open source software. I'm treating you as just Brett Cannon, a human being. You happen to have this software over here and that's awesome. And I will talk with you and work with you and whatever to potentially get something changed. Maybe, maybe not. But there's a separation there of treating me as a human being, right? Versus as just the way to get something out of me. And I think that's also part of what's lost here,

right? Stop. Don't treat maintainers and people as something to get out of you. And I think that's also part of what's last year's right. Stop. Don't treat maintainers and people as something to get out of you. I'm still a person. Just treat me as a person and just realize I happen to produce something that is useful to you. And I think once again, it's all perspective. And I understand that not everyone necessarily thinks this way. Right. Once again, if it wasn't for this crazy world, the internet, I mean, even on the internet, right. How often do you interact with someone from another state, right? If you're in the US, right? Or another province like I'm in Canada. Like we happen to, but if we weren't in the tech industry and happen to have the outreach and speaking we do, chances are you won't talk to other people right and so kind of slowly growing ending up in this

situation where you're interacting with people in other countries with different expectations just different ways of communicating all this stuff it's new for a lot of people and i think a lot of people never stop and think about okay maybe the way i have learned to communicate within my family or my circle friends or my neighborhood or maybe my state if you go that far and if you happen to travel far for your university or something or not what have you your exposure level is going to very much dictate kind of probably how much you've potentially thought about this but it's something that i think a lot of people don't think about and understandably but it's one of those okay what are the proper expectations for everyone on the planet right it. It's not just

my expectations. And just how do you deal with that? Because a lot of people just go like, oh, well, this is how I communicate at home. This is how I communicate at work. And it's okay there. And people don't go like, oh, well, maybe that's not the way to communicate with other people. Right. And it leads to problems. And people also don't think that maybe I wasn't taught a nice way to communicate. And suddenly you have to go like, look, this is not really a good way to communicate. To me, this comes off as this. When I talk to people online, I always try to give them the benefit of the doubt and assuming like, okay, you come from some town somewhere where you just haven't been exposed to other places and only the people surrounding you have always treated you this way and you've learned that this is an acceptable way to communicate. So I sort of go, hey, just so you know, the way this came off to me is this. I

don't think you necessarily meant it that way. Assuming you didn't, this is what I think you're asking. And I try to use it as a way to teach people at least once. Pass that. If you're not listening, then fine, you're a jerk. And I have to wash my hand of you because I don't want to burn out. I'd rather get to year 19 of contributing to Python and not stop at 18. So it's a very interesting thing here of it's psychologically even just learning how to treat people as people. It's not even just treating people as a means to an end in terms of software. It's literally just learning how to communicate with human beings and how to treat people. As I said, I don't fault people when they don't get it right.

But it is something that I think a lot of us don't think about that there's a certain level of psychology here. This episode is brought to you by Retool. Retool is the low-code platform for developers to build internal tools super fast and super easy. They have a ton of integrations and templates to start with. With a click of a button in seconds, you can start with a new Postgres admin panel application, We'll see you next time. and try for free. Again, that's retool.com slash changelog. I'm glad you mentioned psychology. I'm curious if part of your philosophy degree, if you had to do anything of psychology because it's thinking humanity.

Because the one piece that's, I think, is important to mention is that often in a digital interaction, you're missing some data, right? To treat a human as a human, it requires a human element. And often that human element is removed. You know, we have it here in Zoom. I can see your face. I know who you are. We have a relationship, et cetera. It's easier for me to treat you like a human because my lizard brain doesn't forget, you know, like, Hey, Brett's still Brett. He's still a human, et cetera. Right. But in most of our interactions on the internet, you know, or in digital spaces tend to have the human element removed. And, and like you said, it's probably not the fault of them until maybe you say, Hey, I the way you said this, I heard this this way, et cetera.

But I think it's important to remember and to point out that there's a piece of data crucially missing for a real human interaction that is removed and is missing. And it's it's up to us to sort of like click and remember or set a habit, like remind myself this is a human interaction. There is human beings over there. They do matter. They have families, they have moms, they have dads, whatever, you know, they have people that they matter to, they have kids, they have whatever, like there's importance there. And you forget that, you know, that data piece is sort of crucial. We sort of forget about that. Yeah, no. So not,

I did not specifically have any psych courses as part of my philosophy degree. This is partially comes from my wife who has a minor in psych for my mother who just being a teacher just innately just kind of taught me to think about how people might be coming like to school for her like what her students are potentially going through at home and how that affects how they act at school and why they might act out and whatever. I was just lucky enough. I happen to live in a situation in terms of who surrounds me to just have contemplated this and have the build of piece that together as a, as a potential reason is why people are the way they are and how this kind of affects this grand experiment of open source and how this kind of just plays out. Well, your career shows the grand experiment, right? I mean, you know, since the time

Mike or even, you know, the the time, micro even, you know, the world's software now sort of relies upon open source as its foundation. It wasn't that way in the beginning of your career when you got the commit bit, as you mentioned. Like people, you would say, I work on Python, they'd say, what is that? Whitespace, whatever, you know?

And now they're like, oh, Python, so cool. Like since your 18 years of that commit bit, you've seen a massive change in the way that the world relies upon open source software. And there's that necessary component, user, maintainer, contributor, et cetera, foundation, core team, all these things to sort of make this possible. And that just wasn't the case. And so I think over time, we're sort of maturing. And it's talks like this and scenarios like this that bring out some of those points. Like we are just all humans and to help understand those roles and break it down.

Yeah. And I mean, to that point, right? Like there's structure you have to put in as projects grow and become more mature. Right. And there's two aspects to that too. There's, there's the maturation of open source in general, which I think also is what kind of leads to some of the scrumpiness, right? There seems to always be a tipping point in projects where you're small enough that the people participating in general

are just kind of friendly and enthusiastic, whatever. And then you hit that tipping point where suddenly people start relying on you and not just because they want to, just because they need to. And that's when you start to get more of the grumpiness and you kind of have to start dealing with that a bit more. And then the question is, is just, are you able to deal with that?

From a popularity and size perspective, there's an absolute versus relative number here, right? Like, let's say Python has 10 million users, right? It's probably more, I don't know, 10 million is a nice round number. Even if 0.1, 0.01% of those users are real jerks. And we all know that number is way higher percentage wise, probably, unfortunately, we're still talking thousands. Yeah. Right. Who all know how to get a hold of me. It's like the law of big numbers. Exactly. It's exactly the law of big numbers. And it's one of these unfortunate things where you don't get prepared for it unless you plan for it. And like for Python, for instance, we've tried to deal with it, right? Like Python originally was

Guido Van Rossum as benevolent dictator for life. We went for him for final calls. Everything else was basically just consensus. He did what you wanted and everything was done over the python-dev at python.org mailing list, right? And it was a mirror between Usenet and the mailing list, right? Back when people knew what Usenet was. Nowadays, we have multiple main lists from Python Ideas to Python Dev to Python Committers. We have a discourse instance. Guido's retired, and we now have the steering council that I'm on. We have the PEP process that wasn't... It's always been there since I've joined,

but it was not originally there in Python's history because Python's celebrating its 30th year of going open source and public this year, actually. February of 1991, funny enough, before Linux actually got released as open source. And so it's one of these things where... What did it run on? Historically, what happened was Guido wanted a scripting language for the Amoeba distributed operating system that was being developed at CWI, which is a research lab in the Netherlands that he worked at. And he didn't like the idea of Bash.

And he knew the people who worked on the ABC programming language, also at CWI, and had learned some things from them and talking with them. And so he decided, like, you know what, in December of 1989, I think I'm going to try to write a scripting language for this OS. And he created Python. December of 1989. I think I'm going to try to write a scripting language for this OS and you create Python and you open sourced it on a company. Mine dot something. I can't remember the exact username group on February of 91 and it's been going ever since.

Amoeba. Nice. Yeah. So yeah, so this leads to building structure and how to deal with it, but it's also one of those things that's, there's lots of growing pains. It's when do you hit that inflection point to add some extra layer to deal with things you never quite know it's like do it

too soon it feels too onerous do it too late and you you start to have growing pains and all that but it's i think from a general maturation of open source in general i think one of these things that we've not dealt with is the fact that originally open source with all these maintainers was a passion project for everyone right we didn't i don't think a lot of us when we started expected to be like mission critical let's help make sure a freaking helicopter on mars goes where it goes kind of dependency right like i never expected that in my life it's crazy and or like to be very specific like python was on perseverance street that handled the streaming of the video from the parachutes

all right so i never expected to have software on two planets like it still blows my mind to this day yeah but i didn't get into this expecting that and that also means i'd never and i think for a lot of people didn't get into this expecting people. And that also means I never, and I think for a lot of people, didn't get into this expecting people to have that level of dependence on me. And I think when people start to take that dependence is when the stress from people of not getting what they want really kicks in. It's one of these things of, oh, my God, my company depends on this. My job depends on what I do day to day. My job depends on this. I need to get this fixed.

Why aren't you fixing this? Right? That's where I think the stress kicks in. And I don't think anyone goes into this signing up with that expectation or knowing that that's going to come. And I think as an industry, we haven't taken the time quite yet to really try to structure and basically modify our view of what open source is in terms of dependency. right? Like we realize open source runs the world. If Linux went away, the planet would collapse, right? There's a lot of, if all of open source went away,

we're really screwed. But I don't think everyone stopped and think like, well, is open source going to be able to handle this? Are we setting ourselves up for success, both as users and as maintainers, to make sure that we treat each other to make sure that this continue to go right like as a maintainer i don't have problems with you depending on my software to that level but you also have to realize once again human being here

i can only handle so much stress don't come to me saying like the nuclear plant's going to melt down if you don't fix this bug kind of problem right i'm not set for that if you need that i mean i think a lot of people forget it's open source. If I don't fix it, you can fork it. You can vendor a copy and fix it yourself, right? Large companies do this all the time. And that's fine. That's why open source exists. People forget that big drawers of open source was not the free bit. It was the open parachute in case you had to fork it to get what you wanted. but when corporations started to really latch onto it and saw the free label like oh my god python which is probably worth millions

and millions and millions of years of development i mean it's probably into the billions at this point worth of software development for free free are you kidding me i can't write this kind of programming language from scratch i'd rather do that instead of using absolutely c or whatever i'm just going to randomly choose language not to pick on c but it's one of these things where i don't think anyone stopped and thought about well okay how do we make sure that we don't break this right and i don't think we've ever sat down as a community to go like okay where do we need to draw these? Where do we need to start talking as a community out loud and why I do these blog posts and everything else to say, yeah, all right, we need to make sure that we treat these people appropriately, realize that they're not here to give us free stuff. They're here to just give us stuff in general and we can use it however we

want, but we should not go in with any expectations instead of going, oh, cool. There's this free thing I'm going to keep using and I expect it to lead to a certain thing no it's just free things picked up off the street if it works for you awesome if it doesn't don't come bring it back to me just take it to the dump and just do it or if you need to modify the chair that you picked up off my front lawn good on you but that's your chair now don't come right knocking on my door thankfully i think we're starting to have these conversations we're slowing down i think more and more people are becoming aware of the foundation and the people who are building or have built or continue to maintain that foundation and and this discrepancy

and this problem of dependency and how important the foundation really is and how we need to support that foundation if we go back to the GIF as a framing, I think it's the perfect framing for open source. I almost called it a metaphor, but it's not. It's like literally a GIF, right? The metaphor is the stack of USB disks, or USB disks, what do you say? Compact disks?

USB drives. Yeah, I almost said DVD drives, but I realized the kids wouldn't know what the hell I was talking about, so I stuck with the flash drives. Floppy disks. You should have used floppy disks. It's a phenomenal metaphor, honestly, the USB drives. Yeah. I guess drives yeah i guess gift is literal so yeah gift is literal but let's analyze

a little bit because it's a fascinating gift right because it is a snapshot in time right like the gift you give like you said each commit each thing really you kind of release that release is the gift and that's a snapshot in time and And then it's received. Now you give it to the world, but it's received individually or corporately or, you know, you come to it yourself and receive that gift. And then it goes and lives on

in a world that changes. You know, like you gifted a snapshot, but that has to live on in a sea of change. And the person who receives the gift because of the value of the gift, I'm just emphasizing a little bit with the angry users to a certain degree, because we have to see where they're coming from as well. I think it's valuable as maintainers to understand the angry customer

or user because it helps us not take everything personally and it helps us deflect. Why are they acting this way? I'm not giving any excuses to be a jerk or anything like that. I'm just trying to understand. If I receive this amazing, valuable gift, I start to build my house on top of it, right? I may not even understand it. So like large corporations, experienced developers, we love open source because it's open and modifiable. And I can go in there and fix that bug. Lots of people who receive the gift actually don't have the skills to do that. And so we find ourselves dependent and unable to do anything about it. And then we start to build our life around that gift. And then things go wrong because maybe the gift didn't change,

but the world changed around it. Bitrots are a very real thing. It wasn't a bug, but now it's a bug because I updated this other thing or somebody decided they're not going to use time zones anymore because of some sort of vote that happened in this part of the world. Crazy stuff happens. And now I'm just like, I got nothing to do. What do I do? Well, I just turn back to the gift giver and I'm like, help!

And that doesn't always come out very well because A, we don't communicate well b like adam said we don't understand the humanity because all we're seeing is the text area or the github issue and then c because we got all other problems of our lives going on right like my boss is breathing down my neck or my website is down i'm losing money or worse you know i'm mining bitcoin for some random stranger on my website. It gets real bad. And so I think it's not excusable, but it's easy to see why the grumpiness happens.

Because you really do depend on this thing, which has no strings attached, but you sure wish they did. You sure wish they did. It's crazy. Yeah, I think understanding motivation is really important. Because to be very clear here, the vast majority of people are very kind, generous people. And I have absolute pleasure interacting with, right? Like I enjoy talking with people and helping with the problems and stuff. So I don't have issues.

It's once again, just the law of numbers here. Right. It takes 10 kindnesses to undo that one bad interaction. And depending on your reach, it might take a really a lot of effort to get those 10 kindnesses to wipe out that one bad. And you might never, right? If your project's too small, you get that one grumpy user and it'll just kill you instantly. So, but yes, understanding that motivation, it's a coping mechanism almost to an extent. But it's really understanding, all right, deep breath.

Why is this person upset? As you said, jared usually it's someone's bringing down their neck the bad day at work kids could have just been acting up who knows there's a whole litany you never know you never know so there does seem to be some entitlement that comes up a lot in these cases where you're like and this person seems entitled and maybe it's a lack of understanding of how the whole thing works they need to go read that blog post you know yeah but i work at big companies so you should give me what i want because i'm important like right sorry buddy no or you work at big company they pay you to take care of

why aren't you doing it kind of thing yeah yeah there's a lot of assumption happening yeah right and i think it's because it's lack of connection anytime there's a conflict the number one way to resolve conflict is more connection. You're not going to get it from less connection. It's more connection. And connection is understanding. Connection is me understanding what you're going through. You understand what I'm going through, why I'm the angry user, why you're the hurt maintainer.

I almost said butthurt. I'm going to rewind. I didn't say butthurt, but I almost said butthurt. Now you said it. The hurt maintainer. You know, you got your feelings hurt. I almost said butthurt. I'm going to rewind. I didn't say butthurt, but I almost said butthurt. Now you said it. The hurt maintainer. You know, you got your feelings hurt. You got 10 awesomes, but one negative.

And that negative is just way heavier than the awesomes. Oh, yeah. Totally. And that happens. But it's more connection, you know, that resolves conflict. Yeah. And I wish this stuff was taught in school. Right? Like, I wish people who learn this stuff.

Well, not even just opens both. Like I wish there was a class in high school to just teach people how to just be decent human beings, along with how to balance a checkbook. Right. Like there's you're onto something here. I think if there could be like a I'm going to participate as a user or a maintainer or anything in open source. Here's some prerequisites. You understand that there are maintainers out there. Understand their core teams. Understand their foundations and they have these roles and these responsibilities.

And this is a gift and that it doesn't change the fact that you use it in a dynamic world, the static gift and that things change. But here's the scenario. It's almost like I almost think that should exist. I agree with that. Like that should be somewhere. We should put that down somewhere. Yeah. Like speaking in general, like I would hope agree with that. Like that should be somewhere. We should put that down somewhere. Yeah. Like speaking in general,

like I would hope you would learn this in kindergarten kind of stuff, but at least at the university level, you would hope undergrad courses, just general software engineering where they talk about open source, just explain how the system works and what it represents and what it means would hopefully get kids while they're in undergrad before they go out into the working world, the right mindset of how to view and approach this and understand how to work with it because it's now become such an

integral part of our industry and our jobs as software developers that you can't ignore it it's going to be there so let's have that conversation at that point where you need to explain to kids is like here's how to be successful in using open source, not even contributing or making, just using, right? We teach kids how to write APIs and SDKs, right? And how to do this stuff. So why don't we teach them how to actually use it? And part of that's going to be using open source because guess what?

It's true. That's where they're getting all their SDKs and APIs. My only pushback would be you learn whenever you have, when you find use in, your brain is open to learning. Yes. So maybe not en masse that you're teaching this to, you know, let's just say the younger folks that are going to university, but maybe those who are sort of getting into the tech spaces. I'm tinkering with an Arduino or I'm, you know,

learning an SDK or an API. Maybe then it would make sense to say, you know, hey, at some point you're going to interact with, you know, GitHub.com and GitHub.com basically is all of open source. There's some non-open source on it that's freely available to see. Source available, so to speak. There's a license attached. You can see the code. You can interact with the community. But if you're on this website, for the majority of it, it's going to be open source and there's certain rules in this land. Here's some of the lay of the land, so to speak.

I mean, that should be a thing. I just had an awesome idea. Adam loves when I have awesome ideas live on the show. Are you ready for it? I'm ready. Is it more t-shirts? Open source school with Dr. Brett Cannon. Oh, man.

No pressure. It brings you back to your roots. Your mom's a kindergarten teacher. That's true, yeah. I mean, honestly, great idea on the spot to go with Jared's. I wish I could almost have a contributor license agreement that requires I certify that I have read Nadia Eggball's Working in Public, and I understand the concepts in there, and I agree with them almost.

Like one of these things of this. That would be great for book sales. It would be great for Nadia and her book sales she would be down with that i will fully admit not he's an acquaintance uh she's a great person and i actually bought copies she sent me a copy because i'm actually quoted in the book a couple times but i actually bought copies for my in-laws and my parents to read to help explain what the hell i do but also for them to understand why did i sometimes act grumpy on the phone sometimes when they called and said how are you doing like ah it's like yeah now you get it my in-laws have

been reading it my parents live in the states i live in vancouver and my in-laws are here so i get to talk to them when they read it's like oh i'm getting it now now i understand yeah it's almost like i want a way to have people when they come in it's like please set your expectations properly this isn't just code of conduct stuff, right? It's not just how to treat me. I want you to come in with the proper set of expectations of what to expect out of me in this software.

Yeah. As you both said, it's a gift. Here's the commit you're pulling from. That's your gift. Don't keep expecting more gifts necessarily. Right. It may or may not happen.

This is not a subscription service that I gave you. No strings attached. Yeah. You know, a gift with strings attached is a bribe really, or ext i guess in some cases yeah it is like if you get someone a gift and you're like by the way now you owe me one like that's not a gift no exactly yeah that is not a gift that's not a gift it's a favor exactly This episode is brought to you by CloudZero. They help teams monitor, control, and predict their cloud spend.

And I talked with Ben Johnson, co-founder and CTO at Upsticking Security. They get tremendous value from using cloud zero. Ben shared with me the challenges they face driving innovation and customer value while also trying to control and understand their Amazon web services spend. We want our engineers to move fast, to innovate, and to really focus on driving customer value. Yet at the same time, reality is we have to pay for cloud compute and storage. And the challenge around AWS is often that you have multiple accounts, you have lots of different services, you have some people who only have access to development environments,

not necessarily production. A lot of these different challenges across services, across accounts that make it hard to understand the positive or negative impact to the costs that the new feature, the scale, you know, maybe the change in architecture are having. And so giving our team more insight into the ramifications, again, positive or negative of their changes in order to maybe we need to really move fast. Let's have less worry about cost right now. Or maybe now we're in a more stable place. Let's drive down the cost so we can give those cost savings onto our customers or improve our margin. So a product like CloudZero can really help your team get a handle on costs, get alerted

to those spikes, feel good when you actually see the costs drop and do all that without a whole lot of investment of your own time. All right. If your organization shares similar struggles as Ben and Obsidian Security, check out CloudZero today. Learn more and get a demo at cloudzero.com slash changelog. Again, cloudzero.com slash changelog. But you're right though, Brett, that outside of the technical chambers, there's not much of an understanding to what open source is and the value it brings to the world or the importance that it plays on the progress and innovation of the world. Like we said, with your career, since your tenure as having CommitBit on Python,

the world's changed in terms of open source. The requirement of it and the enjoyment of it and the reliance upon it has totally shifted in that 18 years. That's a dramatic shift for all of the world in 18 years. That's massive. That's like more than a 180. Can you do more than a 180. Yeah. Can you do more than a 180?

That's like 360. 360. Going right back to the same direction. Well, you go back to where you were. So it's not. It's a massive shift essentially is what I'm trying to say. Or if you're Tony Hawk, it's a 720. That's right.

Sure. Yeah. And we just never had this conversation, right? It just happened gradually and honestly kind of quickly. I think it's one of these movements of people and thought that you just don't see coming and you don't sit down and have a thought about. It just kind of waves over you. It feels gradual, but the grand timescale of software and all that, it's pretty recent. And I think we've just never really all sat down and gone like, yeah, you know what?

This is how we think this should be thought of and treated and agreed on. Because it's not. Like when I tweeted out my blog post, some people came out and said like, yeah, you know what? This is how we think this should be thought of and treated and agreed on. And because it's not like when I tweeted out my blog posts and people came out and said, like, yeah, I don't agree with this. Not just from the way I phrase things, but literally like I don't agree as soon like one person said, I don't agree. Basically, as soon as you have a website and you start kind of pushing it out on social media or whatever and say, I have this thing they viewed it as I have now established a contract with the world as that is how it's going to go. Now, I personally disagree with that view because

it's like, that's still best effort, right? If I say my deprecation policy is this, I'm going to do my best to hold myself to it, but it might not work out and it might break. And as my wife would say, you don't know me from Adam. So that's kind of weird that you thought I'd hold myself to that necessarily. Right. Like not to not to make it sound like I'm a bad person or anyone else is going to automatically break their promises. But it's best effort, really. Right. Once again, free here.

Right. Please set your expectations accordingly. Well, that's what I think is the deal is the expectation setting and so i think as open sourcers like when we do open source you know we should set expectations explicitly in whatever ways that we can and honestly if you do say this is free and i'm going to maintain it for free for five years then i expect you to do that i don't think it's unfair for me at that point to say well you did say i'm going to maintain this you know i don't know who's doing that but for instance if you said something like if you were that bold in your statement of like i'm going to maintain this. You know, I don't know who's doing that. But for instance, if you said something like, if you were that bold in your statement of like,

I'm going to work on this for five years nonstop. Now, I may be foolish to believe you when you say that, but I don't think I'm insincere to say, okay, you said that. Now, where's your best effort? But if we set the expectation exactly like we ought to or what we believe it is at the time, and I think we could probably develop better tooling better ways of doing this i think a shared nomenclature on what

kind of you know right you're a listener of the show you know a lot of times we ask like what kind of open source project is this because they aren't all the same in fact very few of them are the same noddy did a pretty good job of providing some taxonomy around the kinds of projects. But if we can be explicit as open source people to say, here it is, here's my gift to the world, and here's the license, and here's the expectations, and et cetera, then I think we leave less ambiguity for people to make assumptions that are incorrect. Yeah, and I don't know how to communicate that out.

It's hard. That's the tricky bit, right? Because like, so like for me, like there's community open source and there's corporate open source, right? And I work on both like Python's community open source. There's no single corporation behind Python. Python is very much run by volunteers and community. And we're just, just starting to get people funded to work on stuff but it's like companies either hiring people directly and giving them the free time to work on like microsoft gives me at least 20 time every week to work on python however i see fit but that doesn't mean microsoft has control over python itself right and we now have sponsors giving us an employee we're actually going to be hiring our first devin residents so we now have we giving us an appointment. We're actually going to be hiring our first dev in residence. So we're going to have our first hired person to help work on Python.

Nice. Yeah, it's great. But once again, community run, the Python Software Foundation is the person doing that hiring. The people who gave us the money, Google specifically, isn't getting to direct what that person does. The steering council is actually going to do that. So there's very clear separation. Compare that to my work on the Python extension for VS Code, right? We're open source.

We still take pull requests. We're still driven by the community. But I am paid to help keep that running. My teammates and me and everyone else involved get paid to work on this. So the expectation is different, right? Like Microsoft has vested interest to keep this going. Same with VS Code or anything else coming from Microsoft or Google or any of these other large corporations

that are doing open source. So I think it's reasonable to say, you should still treat them nicely, by the way. This is not to get people off the hook and rude. But the expectations of this is going to be around for a while, I think makes sense, right? Like if your company produces a programming language, chances are they depend on it.

So chances are they're going to keep it going and they'll keep it healthy. So I think expecting that to be around and placing your bet on that. But that doesn chances are they're going to keep it going and they'll keep it healthy. So I think expecting that to be around and placing your bet on that. But that doesn't mean they're going to take it in a direction that you like, right? Oh yeah, right. Yeah, so there's lots of facets to these decisions.

They're going to take it in the direction that they think makes sense. Just like Python is going to be taken in the direction that the dev team thinks makes sense. And everyone's going to do it their own way. And I don't want to say that you can't rely on community open source versus corporate, but you can know the motivations behind it and what that means for you,

right? Like you might be able to convince people more in community just because discussions might be more in the open or they might just not have any pre planned anything. And just, you can just come in like, Oh, that's good.

I do it like versus corporate where you don't know about some planning that might be happening like every quarter semester right like we try to plan out the quarter in the semester we communicate it out as best we can but stuff comes up and we work with it and just it means we have different priorities potentially than what you may expect whatever and that just is part of life and they both have the pros and cons and whatever, but that's very different. But there, but even community-based, you have people who are getting GitHub sponsorships to keep stuff going or

Patreon potentially, or Tidelift or whatever, which once again, also potentially changes things, right? Because like Tidelift is very explicit about what that means. Right. GitHub sponsors is what the sponsor,

the person you're sponsoring says they will do because of this but it very much varies and i don't think we have any there's no standard at all i don't think there probably will be because this is very squishy like how do you say like i am corporate backed so i'm not going anywhere versus i am community based or whatever or i publish everything publicly and there's nothing behind closed doors that you will never know about versus we have certain things that will come up that we'll have to prioritize. Sorry, versus I'm getting paid to make these promises versus not. And there's no way to really communicate any of this well. And so you kind of have to do your research. And I know a lot of people go like, well, I can't do that. I don't know. Like if you're in the node

world, right? I can't go through my don't know like if you're in the node world right i can't go through my 365 dependencies to see what their promises are right especially your transitive dependencies that you didn't even you didn't even opt into those you opted into somebody who opt into them yeah it's hard it's tricky i am not saying there's a good answer to any of this to be able to understand this but this is also why almost regardless of all that taxonomy i just said if you just went with expectations this is a gift right one time and future promises you won't be future whatever you won't be disappointed right yeah you have the gift it works today if you might have to tweak it to keep it going as adam said maybe or maybe not you might not have the technical know-how but it still was way cheaper

for you to start with this than to develop the complete thing from scratch, probably. Yeah. And sometimes I wonder if we have to work out a balance here of how much open source does a company pull in versus you just have to hire someone to do it just because that critical, you don't always have to go that way. But I mean, if there is a way to make it work with the open source project and have someone on staff who contributes and becomes more of a maintainer, that's awesome. Right. That actually happened to me. Right. Like we thought we were going to have a need on the on the Python extension for something in Python packaging. Actually, the packaging project, which is a little miss poorly named because it's hard to say.

I work on the packaging project in the packaging community of Python. But yeah, exactly right. We thought we're going to have a need. So I went to the project and said, Hey, we have a need for this thing. And I worked with the team there. And I got it up. And now I'm, I'm a maintainer of the project. So I'm able to help out and get what we need from the project. But as one of those, we gave back because we saw it as a good thing. But I also happen to be paid to make sure we get the software we need, whether it's open source or not.

And I sometimes think companies forget that, right? It's like free, free, free, free, free. It's like, no, no, there's a technical debt to that. That's not technical debt in terms of you refactoring code. There's technical debt in terms of that project may go away someday. So how do we manage that type of technical debt? Right. And I just realized that's a reasonable analogy, and i wish i'd come up with that years ago the open source technical debt of maintaining that is still there right just like open source

from a cost might seem free to you there's still a cost to me in terms of my life literally in terms of time yeah yeah there's also to you a technical debt of what happens if that project never gets another commit ever again blog post coming soon you just you just created one right there there's always a cost i have to save it for the new podcast for dr brett teaches you open source that's right there you go well there's always a cost and it just shifts right there's always a cost to somebody yeah to the organization to an individual to someone else pays for your lunch there's never a free lunch is that what you're kicking off of? There isn't.

And there's always a cost and it's paid by somebody. But, you know, the premise of open source isn't necessarily just simply free as in money, but free in all ways. You know, free to contribute,

free to fork, you know, liberal licenses, you know, very permissive, et cetera. And, but there is a cost paid somewhere along the line by somebody

or a small group of people to do something or other and that just shifts around to some degree. Yeah, I mean, ideally, the best situation is you pull down this code and your technical debt was literally just integrating that code the one time and it's perfect for the rest of that code's days in your project. You never have to pull another version again. It's perfect and it's there and life's great. Life is grand. Oh, to live in that world.

After that, maybe it's, oh, Dependabot or something else comes along and says, yeah, we got to pull a new version, either security hole or newer stuff that runs faster or whatever and you just tweak a thing and you pull down a newer version and everything just works. Great. Maybe it's integration and new version

and break some things. So now you have to update your APIs. It varies, but it can go all the way up to projects gone, maintainers gone, codes gone, right? Could have been deleted, right? This is why major corporations who have the staffing

mirror the hell out of all the open source they pull down. And you have to state, I use this open source so that they can get that tarball of source code and have it on disk in case they need it for some reason. And code's gone. Maintainer's gone.

Something broke. And now we got to fix it. And that is potential technical debt that I think everyone who takes on open source has to be ready to deal with, regardless of who backs it. Because life happens. Stuff happens.

Companies go out of business. Who knows? There's no guarantees in life. And that goes with open source. Property shift. You know? It doesn't even have to be go out of business. It could be, I'm just done.

I'm just done. Right? And these aren't hypotheticals. Like, I've been an open source user long enough. I've been through every one of those scenarios as a user. Like, project changes direction that I don't like. Or project ceases to exist code is gone or bug just remains open forever and they license change i've been through them all and sometimes you know you got to take different action but you got to do something because once you receive the gift you own the code right yeah like it's

your problem now i received the gift from you it was a gift i'm looking at gift orphan the horse in the mouth and maybe i don't like the gift anymore but uh it's mine now and i have to deal with that and so these things do happen i mean the technical debt is real and you gotta pay it off at some point yep so very good point there let's change gears slightly here at the end it's related so you have your 18 years plus right you're hitting up on your your two decades involved in python yeah and we know that we've had the bdfl retire i'm just curious you you did face burnout at one point like you can go back and listen to our episode with you um we'll link those up in the show notes you've been on the show a

couple of times great conversations you seem like you're doing pretty well now today just seem like you are maybe you can disagree with that but curious if you have an end game like is there an open source end game or do you imagine that you'll just keep doing what you're doing now into perpetuity until you retire from public life or what do you think in that way so yes thanks i am doing better than i have in the past on occasion it It's one of these fluctuating things. Basically, I did not have anything negative happen to me in open source today, so I'm good. Okay, today was a good day. Today was a good day.

The hairball from the cat was yesterday, so that's all good. Totally with the cracks getting fixed Friday, so things are on a good trajectory. Yeah, endgame. The joke I've been making lately is the dev manager at Microsoft to to pay for my open source addiction so the end game is to get to retire from work so i can do more open source um okay and i open source retirement i like it yeah to be honest that that probably would be what i do just because i do this because i enjoy it right once again this is a passion thing for me right like I went to Microsoft because they gave me that 20% time that I wanted to get to do what I wanted plus I get to work on open source the other 80% of the time right like I got to make that I was very lucky

enough to be in a privileged enough position to make sure that I got to have that as my work life and I still managed to steal time during the week to work on other projects in my spare time and still get to work on what I want to work on and all that. And my wife tries to be as understanding as she can be as a non-developer right now, although she's starting to learn a little bit of coding. Why the heck does someone find this so much fun that they want to do it in their spare time on top of work time?

Right. I know plenty of developers still think I'm bonkers when i tell them that but yeah i'd like to think that i will get to the point where i don't burn out and honestly even if i did what i would probably do is i would just do code dumps right like one of the ways i've learned to cope with it there's a couple like i've developed a couple coping mechanisms that have really helped, right? Like I take at least one day every week off where I do not touch anything that requires me to interact

with people from the open source community. And that's a defense mechanism to make sure that I don't get that erstwhile user who's cranky. You need a buffer. I need a buffer. I need that guarantee

that I'm not going to read that email or that issue or anything like that that's somehow going to be a trigger of someone being mad because when it hits, my wife sees it on my face and goes, what's wrong? And so it's very visible that it ruins my day or at least ruins a couple hours of my day. So I have that one month a year outside of work hours.

I don't do any open source that would, once again, cause me to have to interact with other people. I'm allowed to code and I can push code, but I don't really deal with anything else otherwise. And I've actually started to be a bit more opinionated in my projects because by having an opinion, it makes it easier to say no, because that also helps set expectations for people that this is going to go the way I want it to go. And if it works for you, great, welcome. You're welcome to come along on the ride and get what you want out of it. But if it doesn't meet your needs, that's okay too. You're welcome to go fork it, go create whatever you want.

You don't have to use the software. It's a free gift, but just realize I'm going a very specific direction with this. And don't expect me to add stuff just because it might solve a problem for you. Because if it doesn't solve it for me, I'm not in the mood to support it and maintain it and keep it going. And that's helped a lot, too, because, yeah, as I said, saying no is a lot easier now. That's a little unfortunate. I'd like to be able to potentially be more helpful, but it simplifies my life enough that allows me to keep doing this. Well, you need that protection.

I think that your coping is a version of protection, right? How you cope with the threats of the world to your physical being, your mental health, etc. You know, how you think of the world today because of what you've dealt with, the cat ball, as you mentioned, the fur ball or something like that. That's a version of protection. So it seems like you put a lot of thought into how you cope. It seems like you put a lot of thought into how you, because Jared, I should about endgame. I'm curious how, can you get specific? Maybe what would a day in retirement in open source look like for you?

Like, would you be advising on the community? Would you be writing code? Would you like, give me an example of the things you love to do in open source? What's my perfect Sunday? Yeah. To put hot fuzz. Specifically for open source to keep it focused. I don't know.

It kind of runs the gamut, right? Like coding is great. I enjoy creating and all that stuff. I love teaching and helping people. Like I actually enjoy giving talks and doing these podcasts with the two of you and those other folk who I also speak to on podcast. Wait a second.

There are other podcasts. Yeah. Occasionally invite me over to have a chat. There are other, I'm sorry to say, I don't believe it. I'm not going to. podcasts. Yeah, occasionally invite me over to have a chat. There are other, I'm sorry to say. I don't believe it. I'm not going to, yeah. Anyway.

Say their names, please. They're all friendly folks. It's okay. Of course. Yeah. You know what? On that note, for real, we love other podcasts. Yeah.

Yeah, you all do. The place is better because there's more than just us. Yeah. Absolutely. We legit do. We want to see everyone thrive. Yeah. We're not a, hey, come listen to our shows only and they don't exist place so just to be super clear about that oh yeah i'm joking

but i want to be clear yeah no totally fair right like no one's ever community and i've never been on a podcast where anyone has suggested that yeah don't don't mention that other podcast you were interviewed on a week or month or whatever ago no one's never no one's ever done that you too or anyone else yeah to be this is i'm joking amongst friends just for everyone who don't know that I talked to you. Anyway, yeah, and just helping out and stuff. I would like to not have to deal with code of conduct issues over again. That's another thing I've done as a coping mechanism, which is a little weird, is I'm on the conduct working group for the Python's Hotter Foundation.

So I try to do what I can to help with our code of conduct for the PSF and Python in general, and kind of try to engender and create that welcoming, inclusive environment that I would want to have be there if I was starting out, and to help those who are not as lucky as I am based on my position of privilege as being a very tall white Canadian male. No one has. And so it's stressful, but it does let me help make sure that things are going the way they want. I feel should and need to be going so that these problems that I've happened to come across don't perpetuate going forward. I'm doing that as a coping mechanism to make sure the environment ends up the way it

needs to be. But retirement wise, I would love not to do that anymore. But yeah, it just kind of more or less what I do today with complete freedom. Yeah. Yeah. To say no or to say yes.

Yeah, exactly. Just say yes. A lot more than you say no, because you can now 20%. It's now it's 80% or 100% or whatever the number is you assign yourself. Exactly. Whatever strikes my fancy today. Yeah, that's good.

Brett, I'm glad that you have thought through those things to think about coping, to think about your end game. I think it's important. Something I like to think about often is what are you optimizing for? Because it shows what you want to do. It gives you the opportunity to have that opinion, to say no, like you said before. And a lot of people don't think about what they're optimizing for. They sort of just do. And it's just sort of like haphazard to some degree.

Not everybody. I'm just saying like if you think about what you're optimizing for, it gives you a chance to have that opinion so that you can say no. So that you can work on the things you want to work on, not what others want you to work on. And you can have a healthy balance or approach to the work you do. But Brett, you know, you're a friend of ours. We love having you on the show. This special thing for Upstream and for Maintainer Week is obviously open source software maintainers are near and dear to our heart.

We literally love open source maintainers and we show up because we have that love. And that's why we produce up because we have that love. And that's why we produce the shows we produce. That's why we do this in our business. We came for the tech and stay for the humans, as I like to say, because we literally love humans and we want to see everybody thrive. Brett, you're awesome. Dr. Brett Cannon, you're awesome. Thanks.

Appreciate you, doctor. All right. That's it for this episode of The Change Log. Thank you for tuning in. We have a bunch of podcasts for you at changelog.com you should check out subscribe to the master feed get them all at changelog.com slash master get everything we ship in a single feed and i want to personally invite you to join the community at changelog.com slash community it's free to join come hang with us in slack There are no imposters and everyone is welcome. Huge thanks again to our partners,

Linode, Fastly, and LaunchDarkly. Also thanks to Breakmaster Cylinder for making all of our awesome beats. That's it for this week. We'll see you next week. Thank you. Game on.