The Changelog: Software Development, Open Source - Deeply human stories (Interview)

Episode Date: December 8, 2021

Today we're bringing our appearance on DevDiscuss right here to The Changelog. Jerod and I guested their launch episode for Season 7 to talk about deeply human stories we've covered over the years on this podcast. For long-time listners this will be a trip down memory lane and for recent subscibers this will be a guided tour on some of our most impactful episodes. Special thanks to Ben Halpern and Christina Gorton for hosting us. Check out their show at dev.to/devdiscuss

All right, welcome back. This is The Change Log. We feature the hackers, the leaders, and the innovators of the software world. Today, as promised, we're bringing our appearance on Dev Discuss right here to you on The Change Log. Jared and I guested their launch episode for Season 7, talking about deeply human stories we've covered here on The Change Log. For long-time listeners, this will be a trip down memory lane. And for recent subscribers,

this will be a guided tour on some of our most impactful episodes. Special thanks to Ben and Christina for hosting us on their show. It was a blast. You can check their show out at dev.to slash debdiscuss. Of course, huge thanks to our partners,

Leno, Fastly, and LaunchDarkly. We love Leno. They keep it fast and simple. Check them out at leno.com slash changelog. Our bandwidth is provided by Fastly. Learn more at fastly.com. And get your feature flags, pop 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. And I'm here with Josh Vandere from Network2Code. Josh, tell me about how you're using InfluxDB and Telegraph. Thanks, Adam. Network2Code helps enterprises bring DevOps ideas into network organizations. We love using open-source tools like InfluxDB and Telegraph to help our clients collect, enrich, and analyze their data on their networks. Normally, we would have to build out this type of tooling, but InfluxDB and Telegraph meet all of our requirements.

Plus, InfluxDB and Telegraph are open source, so we're able to contribute changes and use their SDKs to write custom plugins whenever we have specific needs. All right, learn more about the wide range of use cases of InfluxDB at influxdata.com slash changelog. Network monitoring, IoT monitoring, infrastructure and application monitoring, InfluxDB at influxdata.com slash changelog. Network monitoring, IoT monitoring, infrastructure and application monitoring. InfluxDB does it all. To get started, head to influxdata.com slash changelog. Again, influxdata.com slash changelog. Welcome to Dev Discuss, the show where we cover the burning topics that impact all of our lives as developers. I'm Ben Halpern, a co-founder of Forum. And I'm Christina Gordon, developer advocate at Form. And today we're talking about deeply human stories in software

with the host of the ChangeLog podcast, Adam Stachowiak and Jared Santo. Thank you so much for being here. Great to be here. Thank you for having us. Thanks for having us. Big fans. All right. So the ChangeLog has been around for a while. You're on episode 463, as my notes say, and we're very excited to have both of you on. I've been on the changelog, and someone can look up that episode if they want. Episode 310, open sourcing the dev community.

So before we get into it, can we get a little bit of background from you two? So Adam, why don't we start with you? How did you get to do what you're doing today as a software developer and then as an entrepreneur, podcast host, and that sort of thing? The way I got here really was we've shared it several times over many shows and whatnot. So I'll try and give you a more recent version of a straight line. We did this with Adam Jacobs recently, talking about the business model of open source. And for me, things began really with like GeoCities and wanting to put something on the internet and then WordPress and, you know, the open source nature of it,

being able to see the source code and putting stuff on the web and a personal blog that turned into something that was like, you know, meaningful for me to learn, but then meaningful for my family. Like, you're actually really good at this and you should do more of this. And this is like, timeframes wise, I would say like 2005, 2004. So I hadn't really like considered at the time, the web wasn't as mature as it is now to say, okay, there's a real future here. Because like, I think now it's mature to the point where it's pretty clear there's a future here. Whereas then it was sort of like, what's going to happen here? It's still sort of like being proven. But it was so far back. I was like, you know, I should try this, I guess I should dig a little further in. And so I, you know, with like any good advice, I took my mom's advice. My mom said, you know, Adam, you're really good at this, you should really do something with it. And that's when I took it more seriously. I didn't go to school for software development. I didn't go to school for design or user experience or the things that I consider skill sets I have

as a front-ender or something like that. And I just sort of just played and tinkered, and there you go. Got into more design stuff. Eventually got into SaaS. Had a blog called The SaaS Wave for a while there. The repo's still there, but the domain actually expired accidentally. And so the domain isn't there anymore, unfortunately, but the Twitter handle's still there. The repo's still there, but the domain actually expired accidentally.

And so the domain isn't there anymore, unfortunately, but the Twitter handle's still there and the repo's still there. But the impact was still there around SAS as a processing engine around CSS and programmatic stuff around it was really interesting, really pushing like CSS3 at the time

and whatnot forward. And I think I pushed a little bit further there, got into open source. And it was around 2009, a buddy of mine and I was sitting there and I was like, you know, we should really do a podcast around this idea of open source. Because GitHub had just made itself exist basically the year beforehand. And it was like, well, open source clearly is moving fast. How do you keep up? And so that became our tagline,

open source moves fast, keep up. We established a blog called changelogshow.com and we quickly named it thechangelog.com, which was almost as bad as the first one. The changelog stuck around, but we eventually moved to changelog.com. We decided to make a podcast and blog really chronicling

what happens between versions of open source software. And so that's somewhat of a short answer to that story. I'm imagining a Sean Parker moment when you got the change from the changelog to changelog. We moved from the changelog.com to changelog.com. That did make it to the blog post announcing the announcement, but it was kind of like that. But we didn't really officially drop the the.

You know, the reason why is because there are many changelogs out there. There's a lot of changelogs that exist for good reason. So we don't want to own necessarily the brand of like what changelogs are, but we definitely own the brand of what the changelog is. And Jared, can you tell us a little bit about your background? Absolutely. So we did do a deep dive with Quincy Larson. If anybody wants a three-hour version of these, you can go listen to Free Code Camp. I think it's on our feed as well. So it's out there. But the brief version is I very much got into computers because of Napster and Winamp back in

the 90s. My first machine was a HP that my dad bought me when I was like 17, 18. So I wasn't super early into the game. I've always been a cautiously opportunistic person. And one of my friends in high school said, hey, Jared, you should go into computers because there's a scholarship you can get at the university here if you're into computers. And so I thought, oh, okay, I can be into computers. Like most people do, just kind of chasing some money, some free money, and followed that into the software industry. Turns out I really loved it, and I have a bit of a knack for these things.

I went through college doing scripting stuff. It was kind of like an InfoSec specialization, so I wasn't really a programmer, but a scripter. And then I got into the programming for the web very much similar to Adam. Mine was really like my WordPress blog. So I had a WordPress blog and I wanted to be rad. I wanted to put my latest scrabbles from Last.fm in the sidebar and the things

that we used to do back in the early aughts. Flickr and whatnot. Flickr? Flickr. Flickr. Flickr, yes. Just throw some liquor in the sidebar. Flickr for sure. That would be funr, yes. Yes, Flickr. You're like, yeah, just throw some liquor in the sidewalk. Flickr, not. Flickr, for sure. That would be fun.

Right at the advent of Web2, right? Yeah. And so I learned really how to program for the web through that. And then I saw DHH's Ruby on Rails and his build a blog post in 15 minutes. And I was like, hello. I found my way in. And so I really started doing that and did contracts offer for many years. So that brings us to the changelog. I was not there in 2009 when that and did contracts offer for many years. So that brings us

to the changelog. I was not there in 2009 when Adam and Wynn Netherland began it. I was just a listener. And I listened to the changelog because I was doing contract dev out here in the outskirts of Omaha, Nebraska, a little bit in the middle of nowhere. I very much felt like I was on an island. And so I would listen to podcasts to feel like I was connected to other developers. And the changelog was one of my favorite podcasts. There were some other ones back in the day. Like, did you know GitHub actually had a podcast that was just the founders of GitHub sitting around, may or may have not been drinking beers and just BSing. It was called Gitsplosion. And I loved it. And as soon as they got some investment money and got official, they had to kill that thing off. But

I was just loving podcasts because they kept me connected. I saw the changelog start to fade out and I ran an independent consultancy. So I had some free time, I guess disposable time that was up to my own discretion. And so I just offered to help out. This is around the end of 2012, beginning of 2013. And started blogging on changelog.com. Actually, it was the changelog.com probably at that point. It was, yeah.

Blogging interesting things and eventually started co-hosting the show. And our relationship grew and the podcasts grew and here we are. A lot of details in there that I missed. And it's fun. It's fun to hear even Jared share some of the history because this has definitely been a journey. We heard a tweet recently that said, and I don't like to say this to be boastful, but it's really interesting when you put a lot of hard work out there and it's recognized by the community. They said, at this point, the Change Log is an institution. And I was like, you know what? We're 12 years deep in this thing.

And we're definitely an institution. We've done so many shows. You can go back and listen. We just had a show recently that's going to come out soon on Oh My ZSH. Robbie Russell was on the show more than 10 years ago, came back on recently for an update on one of the most widely used ZShell frameworks. I don't know what you call it really, but, you know, like that's just interesting. One thing we say often is we came for the tech, but we stayed for the humans. Yeah, absolutely. And I'm glad there are some, you know, three-hour interviews with each of you or both of you. And there's plenty of backlog on the changelog. So our episode isn't going to be too, you know, meta or centric on what you two do.

And we're going to get into some of these episodes. But I want to kind of ask you about how Changelog has grown up alongside open source. Because I think like 12 years ago, a lot of what happens in open source was way less mainstream, way less understood. You've been at the forefront, and now it's like a lot of things which were a little bit more niche or just established. So like how has open source changed alongside this show with you two? I would just say, obviously it's matured. I think a lot of things have changed. I think the way we form around it, the way the community happens around it, even projects maturing, the way we think about open source has matured. There's a lot of things you think that are the right way now, but it's just matured over time. I think about even things

with Nadia and funding and the funding of open source and sustainability, this idea around that, even how we think about, okay, the only problem in open source is money. Well, that's not true because even when projects have money, they have other problems than just simply money. Some projects do have money problems and some just don't have money problems. So I think there's like different styles of open source. That's what's matured. There's obviously the idea of commercial open source now. There's this idea that you can become open source and then relicense and no longer be open source because you choose SSPL or what the OSI deems is or is not, you know, in quotes, open source licenses, which does make sense. We need arbiters out there like the OSI deems is or is not, you know, in quotes, open source licenses,

which does make sense. We need arbiters out there like the OSI doing great work to help draw that line and the distinction because, you know, there's just a lot of different ways you can leverage open source as a business, as an individual to grow your career, as a software developer to gain new knowledge, as a just a curious person to just get more into a different language. It's so many different facets. In terms of it being important, I think it's the most

important thing we have going on in the world today. Everything is run by open source software. Linux is a phenomenally, insanely used piece of software. Like it is everywhere, everywhere. Sure, Windows is out there and so is Mac OS and whatnot and different commercial operating systems. But Linux, anybody can grab it and do something different with it. You can change the kernel. You can make your own flavor and your own distribution. Like it's just so malleable as a tinkerer.

Everybody's invited. That's awesome. Yeah, I would definitely say that it has engulfed the world of software. You know that Marc Andreessen quote about software eating the world and open source has kind of

eaten the world of software. We used to say that the changelog was about open source software and people, but we actually even took that off because where is the distinction? I mean, everybody has an angle into open source

today whereas they didn't back then and so we even just say like we interview the hackers leaders and innovators of the software world because what's the difference really and for me i would say it's not just matured but it's gotten more corporate and somehow because of that mainstream and often kind of shilly and boring in some regards. And so I try to uncover the obscure and talk to the people doing the weird and wacky. For a long time, it was very much hobbyists, passionate people giving a giving a gift to the world. And there's, those people are still out there. And so like the motivations, not that they've changed, but there's so many more people doing it that there's more motivations now. And a lot of those motivations are just mainstream capitalist driven motivations,

which is fine. And we talk about those things as well. But for the things that I like to uncover and talk about and discuss, we had to work a little harder to find what's interesting now because there's so much noise you just mentioned kind of the noise and things like that. Can you kind of summarize what's been like the most challenging thing for you as you continue on or even in the past with podcasting? Everything. I mean, I would summarize it's, yeah, it's challenging to summarize because there's the business behind the thing itself. Yeah.

So I think being able to produce a high quality show that has those characteristics has, you know, when Jared mentioned his history, he came in at the time whenever we were going to legitimize in terms of our business, how we can actually turn it into a business. Because prior to that, it had really just been, and the reason it faded was because it was just a hobby, really. I had a full-time job. I was product manager at a nonprofit called Pure Charity. It's still there. It's awesome. was just a hobby, really. I had a full-time job. I was product manager at a nonprofit called Pure Charity. It's still there. It's awesome. Purecharity.com. I love everybody

there. They're amazing. And, you know, Jared came around at a time whenever we were going to change this into a business. So I would say like the challenges aren't just simply creating a podcast. It's one, you know, being in the trenches enough and caring enough to show up for the people that matter, to have them on the show, to shine our spotlight in areas where it's not being shined, for example, and to, you know, chase down different ideas like Jared's talking about, but also like building the business behind it. And I would even say like growing simply from just the Change Log podcast to JS Party, Go Time, and all these shows we have now, that's been the challenge of like being able to show up every single day and just deliver an excellence every single

time. Doing that consistently for 12 years or more, it takes a lot of work. So that's why I say everything. So one thing that we focus on is three things, actually. We call them the three Cs. And we didn't invent this, Adam. You hand this to me. You didn't invent this idea. I invented this. You invented this. This is my invention.

So the first one starts with a Q, which is hilarious. But the three C's are quality content. So there's your C is the content. And consistency and community. Those are kind of the three pillars that we focus on. And I think of those three things, I spoke a little bit to the content concerns and struggles, especially now versus back then. But a while it was like, what's interesting? You know, where is it? Can we find it now? It's like the same question, but now there's a lot more noise.

I don't think the content is the hardest part because there's so many interesting discussions, so many people doing cool things, overcoming challenges. There's always somebody worth talking to. For us, it has been the consistency, which we continue to struggle with to this day. I think most podcasters do because as you all know, podcasting is very much a grind and a show every week, whatever you decide your cadence is, maybe you go on seasons, maybe not. There's different ways you can attack consistency, but scheduling, cancellations, flood recordings recordings a conversation that went off the rails all these things that go into it they all attack your consistency you know vacation sickness

whatever it is and so i think for us for me on my side of it especially now that we do have a portfolio of shows that record every week some Some record live. Some have panels. Five people. We had nine people on a show. Some are more like the changelog where they're every Wednesday afternoon. It's kind of reliable. Just staying consistent and then keeping that quality each and every time. We're doing our best to do so.

That's hard work. This episode is brought to you by LaunchDarkly. Fundamentally change how you deliver software, innovate faster, deploy fearlessly, and take control of your software so you can ship value to customers faster and get feedback sooner. LaunchDarkly is built for developers but empowers the entire organization. Get started for free and get a demo at LaunchDarkly.com. Again, LaunchDarkly.com. All right, let's get into the meat of this episode. This episode came to be because we were talking about some news stories about some folks who are creating AI chatbots to replicate the dialogue they'd had with deceased relatives and things like that and talking about just like not just the fact that this is happening, but sort of the way, you know, it's such a deeply, you know, human and personal type of story. But who do we talk to about that, you know, aside from just the folks doing it themselves? And that conversation went to, you know, a bit of discussion of, you know, some of the

episodes I feel like I've heard on your show, you know, touched me or were like really authentic dives into some deeply human things. And an episode that came to mind was the episode you did with Peter Hinchens called The Protocol for Dying was the name of the episode. And it was also the name of a blog post that he had written. Peter Hinchin's a very notable open source software developer who at the time had terminal cancer and was thinking deeply about death and how it related to everything else, thinking of it in their own terms.

And Peter has since passed away. But I thought it was a very good episode. I learned a lot. If one of you two want to get into what recording that show is like, how that happened, and how you two felt about the whole thing. I'll start on this one.

I'll say this was Adam's idea. And I didn't know Peter Hitchens prior to Adam telling me about him. So he had already written that post, but Peter's a prolific open source person, the creator and lead maintainer of ZeroMQ. So he had already written that post, but Peter's a prolific open source person. The creator and lead maintainer of ZeroMQ. He has the C4, his licensing agreement or covenant, whatever it's called, the way that you can interact with a governance model and many other protocols.

But he hadn't crossed my radar. And when Adam brought that show idea to me, he had already written a protocol for dying. So this was something that we were well aware of. And I will say that going into that episode, I mean, Peter was basically living out the end of his days. He knew he was going to die and it was going to happen somewhat slowly. And he was like deliberately living his last days, spending his time as he saw best. And so first of all, it was a complete honor that he would come and talk to us. I had never met him, Adam, maybe you had met him previously. Secondly, I'll say that that episode absolutely terrified us

in terms of like, is this a really bad idea? Because things could go very south on a show like that. And I would just say that anytime that we felt that, I guess, trepidation, then usually the answer is, yeah, you got to do that show. Like if a show makes you nervous and a little bit scared, isn't that like the proving grounds for something amazing? And from my perspective, I was just honored to talk to the guy and learn about some of his precepts and the way he saw things. And at the tail end of the show, at one point, I remember, I just said, hey, why don't you just tell us some more stories? And we just, it was almost like we were around the campfire and just letting him tell us stories from his life.

And it was quite touching. Adam, what do you have to say about that? I totally agree with everything you just said. It was a challenge even pitching this idea for this show because i had paid attention to peter on twitter had been paying attention to what he had shared his his blog posts and whatnot and terrible news obviously he had uh obviously family i believe had a daughter as well and as someone who was also a father you know i just looked at this man's story and just thought like you know i just just total sadness you know for him but then i was a father, you know, I just looked at this man's story and just thought like, you know, I just, just total sadness, you know, for him.

But then I was, I was like, you know, I would love to know more about how he's living because his whole idea was how to pass on the software in a way that didn't interrupt everyone else's ability to use his creation. Like he respected the process of open source and of software so much that it really mattered to him to spend time with people like us on our show to share what was happening, this protocol basically for dying, how to do it well. You know, so I had this thought internally, like, I want to get this guy on the show. I would love to do this show. I had no idea what it might be. I'm like, there's no way I'm going to reach out to him. There's just no way. And then I saw him tweet like, hey, if you want to reach out to me and talk to me, like he invited people to reach out to him. And so then I was like, OK, great. I can do it without being like a total, total jerk.

So if he hadn't had an invitation, I probably wouldn't have emailed him or got in touch. I would have just wanted to do the show. We just didn't do it. But he put the invitation out. I reached out. He's like, sure, let's do it. And then we talked like basically as soon as possible because of his situation. And I remember near the end of the show, even that we were like, we think about everybody on the podcast, right?

Like a podcast is normally just a podcast. Like there's no seriousness to this point of anything. Like it's in comparison to life and death. Most of what we do on a podcast is pretty meaningless in comparison to life and death. Like no one leaves our podcast and passes away days later. Peter did. And so when we, when we were saying goodbye on the show, it was challenging.

Like even almost now I'm a little crackly because like, it was like, we were really saying goodbye to Peter because we had one, I just met him, never met him before, had deep conversation about his life and his legacy you know what mattered to him most and his daughter and his family and all his plans and saying goodbye at the end was like we're literally saying goodbye to this guy and i know jared almost cracked up in terms of tears yeah because we were on video at the time and like this is even a damn i don't know how often we did video, but we did for this one.

And, uh, and I was just like, wow, this is probably the most profound show we have done. Cause just the weight of it, you know, I don't think I've ever gone from not knowing somebody to like genuinely

appreciating and more line, loving the guy in the course of two hours. You know, it was just like that. He was just, he was that kind of person. Like you just loved to listen to the guy but it was to this day i mean it's definitely in my pantheon of our greatest hits for sure so i'm with you and i think that one it's it's powerful yeah if either of you want to could you kind of talk about some of the moments

of that podcast that struck you the most i know you've kind of talked about it in general and some of the things, but were there anything specific that you all talked about or said or just even just felt at that time that you'd like to bring up? I remember even him sharing how he had gotten this, he had a metastasis of bile duct cancer in both lungs. And I think he said the way he got it was like some sort of thing where it may have been from something he'd eaten. Well, it must have been about seven, eight years ago. I ate some bad sushi. That's what I think happened.

And there's this little parasite that lives in fresh farmed fish in Southeast Asia. And if you don't cook the fish or really freeze it very solidly, then this parasite gets into your duodenum and attaches itself to the bile duct and begins to produce carcinogens. And this is one of the major killers of men, specifically around 50 in many Southeast Asian countries. But these are very poor people. And this disease is basically just an ignored disease. And it was just like so bizarre how fragile I suppose human life is. It's like, I can go eat the wrong thing or there's some sort of like debate whether that was even the cause of it or whatever. And like life can unfold. So I just think like, for me, it was just reinforcing that hold dear the people near you.

We show up every single day and sure, tech moves fast and it's like, well, you got to raise venture and you got to do this and you got to push that and you got to show up every single day and you almost got to burn out just to show up, just to like succeed in quotes to somebody else. And I don't mean to paint venture capital by any means in any bad way,

but we just feel like this weight just like move as fast as possible. And that's not our model at all. We are slow down and check yourself. We're slow and steady wins the race. And that's because of stories like Peter and Jared and I both are fathers. We love our families deeply. I'm sure everybody loves their family deeply, but we just know how much it means to show up for them. And so we make choices for this business or for our show. Peter and his story just helped for me reinforce the reasons why we choose slow and steady.

The reasons why we're moving too fast. We say, slow down and check yourself because we can move fast and we can accomplish some sort of goal that might be financially driven or whatever driven. But if we don't show up for our families or for our kids or we miss these moments, our lives are so fragile. You know what I mean? There's just such fragility. And just to enjoy those moments and just to really show up for the people you care about. And so for me, Peter just reinforced those beliefs for us and for me. Yeah, so I touched on the campfire stories near the end and that was definitely the most enjoyable

part because when you just say like hey tell some stories and then he just started telling us stories I don't remember the stories I just remember like that was he was so open and so like yeah let's do this that really touched me one thing that I noticed is that he was really proud of his c4 which I always butcher the acronym, so I looked it up. That's the Collective Code Construction Contract. And this was his favorite protocol. So we asked him, like, you know,

he's written over 30 protocols. His blog post was a protocol for dying. He's going through, like, very nitty gritty of how he's going to go spend his final days. And he said that his most favorite or most proud protocol is this C4 because it's a way of working with people on software. And so it's very meta. I really like that protocol because it works really well.

I mean, we've tried it now for years and it just, it works almost magically well. And it's written kind of from an autistic viewpoint where you don't really care what people feel as such, but you do care that they do feel. And so there's this kind of very brutal approach to human nature in there where, you know, how do you solve bike shedding? Well, you look at the emotions involved, you look at why people argue, you look at the fallacies that people have in their minds, and then you, you reposition the things that they go away. And to do that takes a certain distance from,

you know, it takes a certain distance. If you're involved and you really care too much, then you can't do that. And I think, so I love, I mean, I love working with people and I've,

I've, I've, I think I'm, I think I'm hyper-social. I've made hundreds or thousands of friends in the last years as I've gone around the world with conferences and so on. And that's one of my great pleasures and happinesses in life is people, other people.

He was more proud of that than any other. And it's not very popular. They use it at Zero MQ. It's very permissive. It's radical in very many ways. And I think that's why it's not very widely used because most people can't be that open with their open source project. But I think he might accept all commits and then just like rewrite them afterwards. I don't know, it's got some interesting bits and I should go back and read it again. But the fact,

the details of that protocol aside, the fact that that was what he's most proud of is this thing he wrote about how we govern ourselves amongst these projects, I think really speaks to how deeply he thinks about these topics. Yeah, I mean, for me, I do remember this episode as being really impactful for how I thought about how open source software can or should be maintained in a lot of ways. Like, I didn't go around adopting any of this, literally, it's pretty radical, but it was a big influence for me. And also, you know, Peter passed away, he hasn't been around to see, you know, the evolution of things as they've happened, you know, in the past half decade. But I think pretty much everything like he has written about, you know, if you take it from its principles perspective, is pretty timeless. Not stuff everyone will agree with, but I think timeless in nature of like,

how to think about really the chaos, I think, of software development and that sort of stuff. And, you know, his blogs are still around to be read. You know, he's written a lot of personal stuff. You're not going to go there and find a million things that are personally you agree with or work for you. But I think your episode, I think, really distilled a lot of like the most impactful stuff he'd written. And, you know, I think he was thinking about it very lucidly when he came out and talked about it. And it was, I think it was pretty meaningful. And I definitely suggest people who are curious about thinking deeply about some of this stuff,

give that show a listen and anticipate it impacting them in some way. This episode is brought to you by our friends at Teleport. With Teleport Access Plane, you can quickly access any computing resource anywhere. Engineers and security teams can unify access to SSH servers, Kubernetes clusters, web applications, and databases across all environments. Teleport is open core, which you can use for free, and it's supported by their cloud-hosted version, which lets you forget about configuring, updating, or managing Teleport. The Teleport team does all that for you. Your team can focus on your projects and spend less time worrying about infrastructure access. Try Teleport today in the cloud, self-hosted, or open source. Head to goteleport.com to learn more and get started. Again, goteleport.com.

And by our friends at Square. Square is the platform that sellers trust. There is a massive opportunity for developers to support Square sellers by building apps for today's business needs. And I has apps like our point of sale app, like our restaurants app. But there are so many different sellers, tuxedo shops, florists who need specific solutions for their domain. And so we have a node SDK written in TypeScript that allows you to access all of the backend APIs and SDKs that we use to power the billions of transactions that we do annually. And so there's this massive market of sellers who need help from developers. They either need a bespoke solution built for themselves on their own node stack, where they are working with Square Dashboard, working with Square Hardware, or with the e-com, you know, what you see is what you get builder. And they need one more thing.

They need an additional build. And then finally, we have that marketplace where you can make a node app and then distribute it so it can get in front of millions of sellers and be an option for them to adopt. Very cool. All right, if you want to learn more, head to developer.squareup.com to dive into the docs, APIs, SDKs,

and to create your Square Developer account. Start developing on the platform sellers trust. Again, that's developer.squareup.com. you all had another really powerful episode with Laura Hogan author of resilient management titled leading leaders who lead engineers which obviously hits on some of the most human aspects of software which is managing people. Can you give us a little description of that episode and about Laura herself? Laura, man, she's awesome. I've been paying attention to her for a bit in terms of like her leadership style.

I pay attention to her newsletter. And Jared and I were just talking about this the other day because I was a little nervous having her on because I had been just such a fan of her for years. And we even say in the episode, like this was years in the making episode because I'd actually held off because of my imposter syndrome, emailing her and saying, hey, come on the show and share a lot of your ideas. And I guess finally I was like, you know what? Let's just do it. And so I emailed her, we got on the show and we talked through, you know, pretty much this excerpt that she had on a list apart, which was resilient management and excerpt.

And it was from her book. And we really broke down kind of this core construct of like a mentor, a coach, a sponsor and delivering feedback, this sort of these hats you definitely wear when you're a leader. And I love that people side of things because it's not just simply like,

how do we learn this API and deliver this application and then deploy it and keep it up? I mean, these are all obviously phenomenal skill sets to grow, but just like digging deep into like how you help somebody be a better player in the team

is phenomenal. Like her ideas around coaching and sponsoring and the differences there and mentoring was just awesome. So I just was excited, but at the same time, I was very nervous having on show. Cause I was like,

been a fan for a while. It happens. She really opened my eyes to really just thinking about sponsorship more and the aspects of ways you can invest in somebody else and help somebody else. One of her emphases, is it an emphasy when there's plural emphasizes one of the things she talks about a lot is how we focus on mentorship we like as an industry and i think even individually inside that industry we think about mentorship in ways of helping people and while it's legitimate it's not everything. And it's also kind of the most self-centered way to help somebody because it's really like,

I know a thing, let me teach you a thing. And so it's a little bit about the mentor, not saying there aren't good reasons to be a mentor, but often it's like, hey, I'm smart. Here's how I can help you because you're not as smart or experienced. So here's some advice, which is often needed, but it's not the only thing people need. And she really emphasizes people's need for sponsorship, which is really going out and giving them opportunities, going out of your way to vouch for somebody or to offer their name for that role or whatever it happens to be, get them in the door in a place. Like those things are incredibly powerful and incredibly helpful for people

that you're trying to invest in. And we often focus too much on the mentorship side, which is teaching somebody something and not enough on the sponsorship, but it's really opening the door or giving a leg up because those are things that people need as well. And I hadn't really thought about it that way. She shared a story too about that process. Like it wasn't just by any means, not that she would, but it wasn't pontificating. It was like, here's how you do sponsorship. It was like, here's an example of sponsorship in my life. And she was saying a time when she was at Etsy, because she was an engineering manager at Etsy and how her boss, you know, at the time she wasn't promoted yet, her boss was away for a sustained amount of time. And they were like, well, I'm gone, Laura. He was a VP. I was not. And I was not prepared

for what that was like. He didn't ask me first. It was sponsorship, as you said, Adam, by force, sponsorship by force. But again, it connected me to so many different people within the business. I didn't know what CapEx or OpEx was. I didn't understand how headcount worked. And it threw me in the deep end in a way that really, again, skyrocketed my growth. She gave good concrete examples of how to sponsor in ways that showed up in her life to help her be where she's at today. I was leading a web performance team. I was leading like a product infrastructure group. And my director was in the meeting vouching for me.

And all the other directors in the meeting were saying, yeah, but maybe she's not technical enough. Like front end. I don't know. I think we have to. She doesn't have enough back. And she's another experience. And my director was like, you know, she wrote a book about web performance. Right. Like, I think that we can say that she's technical enough to have the job of a director like you all, you know, and that sponsorship, too, that was behind closed doors. I didn't know about that till much later. But that's awesome. Like sponsorship can be invisible to you also. You all were just talking about a lot of kind of the takeaways there.

In this episode, you talk about needing compassion and empathy in order to lead. Can you talk about these traits and how they are necessary component for leadership, even in tech, especially in tech? Let me see if I can. I think Laura could do it better than I could. I think we're asking her the questions on that front. But to that note, we have a show called Brain Science. And it's because I'm super curious about, I guess, just humanity. And I happen to have a friend who is a doctor in clinical psychology. Her name is Mira Reese. And the show is now not in production, which just makes me super sad because I love that show.

But I learned so much through the Brain Science podcast about empathy and compassion and all these different things. And just from a psychological standpoint, how does it manifest? What's required? You know what I mean? It's just really an interesting process. But I think empathy is sort of meeting somebody where they're at. And I'm by no means giving a clinical terminology of empathy, but if you can meet someone where they're at and you can understand where they're at and still accept them and love on them. Like, I think that's a high

quality of a leader. You know, you have to care about somebody and empathy is seeing something like somebody in pain, a challenge or whatever, and not just like, oh, sorry for you, but sorry for you. And also I want to find ways to alleviate that pain. That is a hallmark for a phenomenal leader. Like I know you're in pain. It could be financial pain. It could be career ladder pain. It could be skill pain. It could be, you know, whatever it is, being ostracized from the community or from the team because you're not fitting very well, whatever it is, a leader steps up, a leader empathizes in those ways and doesn't just see the pain, but wants to resolve it. So I think that's like a critical skill. And it is a skill. It can be, it's something that you don't just get. You

grow an empathy skill because you practice it like anything else, day by day. Yeah. Anyone with kids knows that it's a skill that they learn over time. Right, precisely. Yeah, and we did 32 episodes on that show. And I think, you know, there's people who still tweet about it. It's been out of production for about a year. And it bums me out because I love that show so much. We just don't have the time for it right this very moment. But I'm hoping someday we might be able to bring it back in some way, shape, or form.

But there's just so many great nuggets in there. And I think about things like mindset and like a lot of the mindset I have with empathy and with different things I've gotten from like exercising that part of my brain by producing that show. And so I just if you're listening to this, check it out. Not to grow the show, but just to grow yourself. It's an awesome show. I love it.

The next episode I'd like to talk about is entitled Every Commit is a Gift. Can we hear about what that show is all about? So Every Commit is a Gift is an episode we did just recently. I think it was either this calendar year or last calendar year. I think it was just this spring. It was June, Jared. It was June. That's right.

Celebrating maintainer week with Brett Cannon. Well, we're in a bit of a time vortex at the moment. Yep, we are. I think it was just this spring. It was June, Jared. It was June. That's right. Celebrating Maintainer Week with Brett Cannon. We're in a bit of a time vortex at the moment. Yep, we are. I forgive you. I forgive you. This was for Maintainer Week, so we were involved in Maintainer Week, which was put on in collaboration with GitHub and Tidelift and trying to get maintainer events happening,

celebrating maintainers, talking to maintainers, helping maintainers, talking to maintainers, helping maintainers, getting them together. And of course, as we've been a long time in the open source world, and we're here for the people, the people of open source are the maintainers. I mean, there's lots of users, but the best users become maintainers. And the best maintainers are the most, I think, giving people out there. So many of these others, they give themselves to the point where they completely sometimes destroy themselves just giving. And so this episode with Brett Cannon, who is one of Python's steering committee core members, so he's been very involved in open source by way of the Python project for a very long time is really a conversation around a blog post he wrote

which is about how every single commit that an open source maintainer puts out into the world should be viewed is literally but should be viewed as in terms of the recipient as a gift and comes therefore with no strings attached and no expectations beyond. And it's really trying to set boundaries around how users of open source software and maintainers of open source software interact with each other because there's lots of problems in that particular area of what we do, mostly because of mismatched expectations, but also because of bad actors and also because of real world problems

that we bring to our keyboards and like take them out on other people and the lack of empathy. And so as part of maintainer week, we spoke with Brett, who's been on the show a few times about how he views open source as this metaphor of him

putting a present on his lawn. It's like free USB sticks and you walk up and you take it and now it's yours. It's like free USB sticks. And you walk up and you take it, and now it's yours. 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 do I don't think those are equivalent I think the transaction here is different

we did this with Kara Souls and Josh Simmons of Tidelift and GitHub and what not and we did this as part of maintain because we just absolutely love software maintainers I'm sure you all do as well you know every chance we get we want to find ways we can show up for them and because Brett had become a friend of ours, we knew, you know, the perspective he has.

Not just simply, oh, I read a blog post and it's pretty popular or whatever. But like we knew that Brett has a good lens for the ways to justify the relationship of a maintainer and open source in the community. And so doing that show as part of Maintainer Week is just like perfect, honestly. I mean, it's exactly the kind of show we want to deliver for that kind of event which maintain it was just about celebrating software maintainers for software maintainers so we did that with brett as someone who's not a maintainer necessarily because our whole team maintains our open source project but manages our repo i manage our repo. When there's a project where a maintainer is, especially when there's a project where it's a single maintainer,

or maybe they don't have a whole team behind them and stuff, I definitely get that concept of, this is a gift and I can keep putting stuff out there as a gift, but you coming at me and expecting things is maybe not the way this should be working. But also I see because we've had people before in our repo who, you know, are passionate, I say passionate about different things on our project. I also see that as a gift sometimes because if someone really, really deeply cares and they want to like comment on it or even add to it, especially add to it is helpful, but even just comment and like really kind of push you to like, think about where your project is going and what you're doing. I also see that as a gift too. And I know there's a lot of pushback a lot of times from people in open source,

but just kind of something to add there is someone who helps manage. Well, I would call you a maintainer because we had a podcast yesterday, that one with Robbie Russell. And the reason why I say that is because he expressed some challenges with finding help, co-maintainers of Oh My Z Shell. And I think it's because we, in the brain science show, we say we have to name things that tame things. And sometimes naming something helps you define obviously what it is because a name gives you a reference point. But I think, you know, we can massage the idea of what a maintainer is, not just be like, well, I ship code to this repository.

I think you're very much a maintainer. If it's open source and it's open source related, you're a maintainer for sure. And to not make people feel like they're imposters by showing up and thinking, well, am I really a maintainer? I kind of contribute. I think you're definitely a maintainer. A hundred percent. Thank you. You're welcome. In terms of our situation with regards to this topic, you know, there's certainly some additional social contracts that need to exist because we are a commercial open source project. And our responsibilities, I think, probably go a lot further than that pure unilateral volunteerism kind of component. Like, when we work with our community, ask for help in certain projects,

you know, from our perspective, we have to be really careful about doing so in a way where everything is mutually beneficial. And we really certainly try to maintain our open source projects such that, hey, if anybody wants to use this and download this, this is for everyone. And we foster this thing, but it's really for everyone. And, you know, that was the movement of taking dev and turning it into this forum thing. But yeah, just kind of wanted to say say that like you know our responsibility as a commercial open source project and like people should scrutinize us i think in a different way than they then they might you know your average volunteer maintainer and from my perspective

i would want that and i would also ask that of like git lab to be held to a certain type of standard that like the pure bottom-up open source alternative to that project might not. GitLab went public today. They're now officially a $14 billion company. It's kind of like you got to ask different things of them. Yeah. Well, that speaks to the maturity we talked about earlier though, right?

Like when you said, how has open source matured over the years? I think that speaks to the maturity of it because Brett's perspective from what I recall in the post, is his contribution to Python itself. Whereas your all contribution to forum is different than his contribution to the same open source commons that we all lean upon. So it's a facet, totally. But I think that speaks to the maturity because, you know, a GitLab or a forum and the commercial aspect of it, you know, you still have the software and it's still licensed permissively. You have a GPLv3 license.

I could take that software today and go commercially use it. There's probably some copyright conditions I have to adhere to. But for the most part, if I contribute to it, I can also take your software and do some commercial with it as well. So it kind of depends. I mean, licenses play a role in helping that line and being crossed too because what makes open source open source is, one, I would suppose, OSI's blessing of the license, but then two, it's permissiveness and it's restrictions. Right. AGPL is not one of the more permissive licenses, but we don't want to

necessarily bike shed licenses at the moment. I will say that that's why I started off with it's so important to set expectations. So I think you can layer on top of this gift concept and hold yourself to a higher standard. And if you put your higher standard out there, like in your documentation and your readme and your communications with your community, and like, here's where we are. We're going to be here. I remember we just had Richard Hipp back on the show from SQLite. Another one of our greatest hits, episode 201, check it out. He's one of my favorite guests. He says they want to maintain SQLite for until 2050. And like, that's something

that he holds himself to. And he puts that out there. Now, can they get that done or not? Not sure, but that's like a much higher standard than every commit is a gift. Now, it's still a gift to the world, but he's layering on top expectations

that he's willing to hold on to. I think that's what you're doing in your case. But the beauty of open source is if GitLab suddenly lets all of us down or a forum, God forbid, goes against their previous statements, fork it and start a revolution. That's the freedom in open source is like, you know, spell it backwards or more

F. I don't know. Start a more F project. Right. Like Dino and Node. That's right. Not less F. We need more F around here.

So, but that's like, that's the cool thing about open source is, you know, that was a gift as of that point. Now, maybe the next point it moves to something that you don't want anymore. That sucks. And maybe you are let down by those people, but there are options. Whereas with proprietary, you're basically SOL, right? Yeah, precisely. It's copyrighted.

It's intellectual in terms of IP. It may not be intellectual in terms of its actual code base, whatever. You know what I mean? Yeah, for sure. And that's the beauty of open source is like we can all show up and accept this free gift and we have choices based upon that. Whereas if it's proprietary, there is no gift and there is no option really. Which is why I'm an advocate for people very clearly communicating on their own projects that you, the projects that you create and run very clearly communicate the expectations of you and of the community.

One of the questions we ask many people, what kind of open source project is this? Is this open source? You can look at it, but we don't actually want any contributors. That's totally fine, by the way. That's your choice. But like, make that set clear.

Or is this like, come one, come all, you know, we're going to federate a thing and have a huge community. Then like make that set clear. Or is this like come one, come all, you know, we're going to federate a thing and have a huge community, then like set that expectation. And then there are more things people should expect than just what we're talking about with Brett on that episode. But I think it's a baseline. I definitely have a backlog of podcasts to listen to now. So I really appreciate talking to you all. You're welcome. So, you know, Adam, Jared, thank you so much for joining us today.

We've really enjoyed it. It was awesome. Thanks for having us. Thanks for having us. And it's been lots of fun. All right. That was so awesome. Thanks again to Ben and Christina

for having us on Dev Discuss. Check out the show at dev.to slash dev discuss. What do you think about this show? Any episodes or moments shared that stand out to you? What's one of your favorites in the back catalog? Let us know in the comments.

If you haven't yet, check out ChangeLog++. Support us directly and make the ads disappear on all our shows. Check it out at changelog.com slash plus plus. Thanks again to our partners,

Linode, Fastly, and LaunchDarkly. Also, thanks to Breakmaster Cylinder for making all of our partners Linode, Fastly, and LaunchDarkly. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. And of course, thank you to you for listening. If you enjoyed this show, do us a favor. Share it on Twitter, Reddit, Hacker News, anywhere that works for you. Word of mouth is by far

the best way to help us grow this show. And of course, the Galaxy brand move is to subscribe to our master feed. That will get you all of our podcasts in one single feed. Check it out at changelog.com slash master. All right, that's it. This show's done. Thanks for tuning in.

We will see you next time. Thank you. Game on.