The Changelog: Software Development, Open Source - Working in Public (Interview)

Episode Date: August 12, 2020

Nadia Eghbal is back and this time she's talking with us about her new book _Working in Public_. If you're an old school listener you might remember the podcast we produced with Nadia and Mikeal Rogers called Request for Commits. If you weren't listening then, or can't remember...don't worry...the back catalog of Request for Commits is still online and subscribe-able via all the podcast ways. That podcast is still getting listens to this very day! Obviously we go way back with Nadia...and having a chance to now talk with her through all the details of her new book _Working in Public_, this was a milestone for this show and Jerod and I. We talked through the reasons she wrote the book in the first place, Nadia's thoughts on the future of the internet and the connection of creators to the platforms they build their followings on, and we also talk about the health of projects and communities and the challenges we face internet-at-large as well as right here in our backyard in the open source community.

Worth pointing out, the book's called Working in Public. It's not about open source, but it's about open source, right? Yeah. It's open source as a lens to a somewhat bigger topic, right? Yeah, I was inspired by how in the late 90s and the early 2000s, ESR was writing about Cathedral and Bazaar. Everything that was happening around that time, a lot of people were looking at open source as an example of

what was to come more broadly on the internet. And so they were saying, okay, open source is this thing where there are all these strange developers that get together and write code, and they don't know each other, and somehow it all works. This is an example of peer-to-peer decentralized collaboration on the web. It's a promise of what the internet can enable. And people kind of took that mentality and applied it to a lot of things that were very formative to the early internet. And so similarly, now, I feel like we're in this second wave where, okay, like everyone's online, or at least a lot of people are online a lot more than before, we're experiencing some positive and some difficult effects of just like the internet at scale. And so again, it's like,

well, what are our mental models for how to organize communities and think about creators on platforms for this new world? And what I wanted to do with working in public was to say, like, there's actually still a lot we can learn from the second wave of open source as well, looking at sort of modern open source and how it's evolved from those early days. And they can tell us a lot just about like, what is happening on the internet more broadly. Bandwidth for ChangeLog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at rollbar.com and we're hosted on Linode cloud servers. Head to linode.com slash ChangeLog. What up friends? You might not be aware, but we've been partnering with Linode.com slash changelog. What up, friends?

You might not be aware, but we've been partnering with Linode since 2016. That's a long time ago. Way back when we first launched our open source platform that you now see at changelog.com, Linode was there to help us, and we are so grateful. Fast forward several years now, and Linode is still in our corner, behind the scenes helping us to ensure we're running on the very best cloud infrastructure out there. We trust Linode. They keep it fast and they keep it simple. Check them out at linode.com slash changelog. All right, welcome back, everyone.

This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, editor-in-chief here at ChangeLog. On today's show, we're talking with Nadia Ekbal about her new book, Working in Public. If you're an old-school listener, you might remember the podcast we produced with Nadia and Michael Rogers. It's called Request for Commits. If you weren't listening then or you can't remember, don't worry. The back catalog of Request for Commits is still online and subscribable via all the podcast ways. Check it out at changelog.com slash RFC. That podcast is still getting listens to this very day. But on to the details of this episode. Obviously, we go way back with Nadia and having a chance to now sit with her

and talk through all the details of her new book, Working in Public. This was a milestone for this show and Jared and I. We talked through all the reasons she wrote the book in the first place, Nadia's thoughts on the future of the internet and the connection of creators to the platforms they build their followings on. And we also talk about the health of projects and communities and the challenges we face, internet at large, as well as right here in our backyard

in the open source community. Oh, and one more thing, we're doing a book giveaway, but you got to listen to the whole show. We mentioned all the details at the very end. So working in public out now, Nadia's mood book. This has been a long time coming. It seems like the end of a chapter, at least from my perspective. Does it feel like the end of a chapter for you? Oh, absolutely. And actually, especially coming on here since you guys were the first podcast I

ever, ever did. Wow. So we're really coming full circle here. And big announcement, this is actually your last podcast ever as well. Ever. Mic drop. Out. That's the best way to do it, is do it with a podcast and a book. Yeah, they're bookends. Leave the stage. That's all I had to say.

So, big release, big book in print, working in public. A huge culmination of some of the work you've done over the last few years. Start by catching everybody up. Regular listeners know that you came on the changelog a long time ago with your big realization that there's this gap in the open source world, which was funding. This discrepancy between people who are maintaining this invaluable software that's really the infrastructure of the internet and a lack of support for those folks. This was something that we knew from the trenches

but many people had no idea about. You kind of uncovered that. You came on talking about fundraising and I think back then the idea was maybe we can get some VCs to support this type of thing. And you've learned a lot since then. Maybe start with just the history. You went to GitHub. Tell the logistical history real quick to get to where you are now to writing this book. And then we'll go into the learnings and what's in there.

Yeah. It started sort of with this open-ended exploration that didn't really have any goal to it. I was just going around talking to open source maintainers, trying to just dig into my own research project. I wasn't working anywhere at the time. And then wrote this blog post that just sort of like announced that I'd been having these interesting conversations with maintainers and that open source didn't really seem, it felt like there was just stuff missing from the narrative of how open source was actually working on the ground. And just saying like, I'm going to be writing and researching about this in public and you can follow along if you want.

And it got a really great response to that blog post. I think we did our first interview together shortly after that, but I still didn't really have like a plan. I think that was like pretty early on. And so I was just sort of like continuing to write and had a lot of open source maintainers reaching out and just folks that are peripherally involved in open source that were the big

thing we were sort of talking about then was everybody is relying on open source at this point. It's not just this side hobby thing. It's critical infrastructure for how the world works and runs today. But so many maintainers feel burned out, stressed out, like they're having to do this in their spare time and don't have any really direct way of working on open source, but something they really love other than, you know, the biggest projects like Linux, for example, where you can find a job working on those kinds

of things. But for all these smaller libraries and projects that kind of go unseen and unnoticed, who's really taking care of those? And so, yeah, I was just sort of like writing about it, didn't really have a plan, had a grant from the Ford Foundation to publish Roads and Bridges, which was kind of like this lengthier report at the time. And then around the same time was talking to GitHub about what is their relationship to open source developers and broader community. Obviously, everybody's using github but have they sort of been like taking the steps i guess to um really understand on a deeper level like what maintainers are doing on their platform and what they need from github i think right

around then the dear github letter came out if you guys remember that yeah yeah and so it was like i think several thousand maintainers who had written this open letter to GitHub published in a Dear GitHub repo. Of course, they're basically just saying like, we don't feel heard by GitHub. We have all these needs and we don't know who to send them to. And GitHub had spun up an open source team at the time. And so they were starting to think about this stuff. And then I was also starting to think about this stuff separately. And so we decided to join forces on that.

And I joined GitHub that summer or fall-ish. And yeah, being there was just a really useful experience in this whole thing. And that before when I was just sort of, yeah, I didn't have any background in open source. I was just sort of curious about what it was like. And so just interviewing and talking to people. And there's, I guess, like there's a lot you can do to just sort of summarize what people are hearing and try to amplify that a bit and that's what I was trying to do early on I didn't really trust my own intuition and I was very aware that I just didn't really have any credibility or

any personal experience really with open source and I was just sort of trying to be like like I don't know I don't know what this is all about but I'm just all I'm doing is pointing to these other people that are working on things that are like clearly really used and they're saying this stuff. So don't listen to me if you don't want to believe me, that's fine. But like, go look at these people. Being at GitHub gave me, I think even more of just that like hands-on experience and having to like really see how the sausage is made at GitHub and seeing the problems that people were running into. And also just being able to meet and talk to developers from a very, very wide range of ecosystems.

It wasn't just the people that I'd known and reached out to. I was just being exposed to so many different kinds of experiences. You kind of entered your experiment, right? You were no longer just an observer from the outside. You were actually in the community, in the thick of it, which was different. Yeah, it's helpful to have, I think, some skin in the game. And I even started experimenting with using GitHub more and finally figured out how that thing works, sort of.

And so, yeah, that was just a much more hands-on experience. And I think from there, then I was starting to test some of my own hypotheses and thoughts about, is this really all about a lack of participation in open source? What is this model that we talk about of like open source is just made up of like large armies of volunteers and it's just all about contributions and just starting to realize that for some projects, there really is just like one or two maintainers and there's not going to be any more substantial contributors. And so what do you do in a situation like that?

So my brain is just getting a little more nuanced at that stage. And then I left a couple of years ago and then started focusing full-time on basically writing this book and wrapping up some of my own research. Worth pointing out, the book's called Working in Public. It's not about open source,

but it's about open source, right? Yeah. It's open source as a lens to a somewhat bigger topic, right? Yeah. It's open source as a lens to a somewhat bigger topic, right? Yeah, I was inspired by how in the late 90s and the early 2000s, ESR was writing about Cathedral and Bazaar. Everything that was sort of just like happening around that time. A lot of people were looking at open source as an example of what was to come more broadly

on the internet. And so they were saying, okay, like open source is this thing where there are all these strange developers that get together and write code and they don't know each other and somehow it all works. This is an example of peer-to-peer decentralized collaboration on the web. It's a promise of what the internet can enable. And people kind of like took that mentality and applied it to a lot of things that were very formative to the early internet.

And so similarly now I feel like we're in this second wave where, okay, like everyone's online or at least a lot of things that were very formative to the early internet. And so similarly now, I feel like we're in this second wave where, okay, like everyone's online or at least a lot of people are online, a lot more than before. We're experiencing some positive and some difficult effects of just like the internet at scale. And so again, it's like, well, what are our mental models for how to organize communities and think about creators on platforms for this new world.

And what I wanted to do with working in public was to say there's actually still a lot we can learn from the second wave of open source as well, looking at modern open source and how it's evolved from those early days. And it can tell us a lot just about what is happening on the internet more broadly. And one of the things that you uncovered,

which we've uncovered as well over time, is that there's a perceived problem, which first of all, most people don't even know or think about it with open source software, which is really the funding sustainability support, right? And then there's actually more problems or even more important or seedier problems. You start out in the book describing that difference with the problem not really being not enough contributors, not enough money, which are kind of the things that you think and you hear. But there's problems like use versus contribution. There's a big one-to-many problem, or small few to large crowd,

which is really overwhelming. Like you said, this is the internet at scale. What brought you to that realization? Was it just the conversations you were having, or just the time in overwhelming. Like you said, this is the internet at scale. What brought you to that realization? Was it just the conversations you were having or just the time in the trenches where you realized, you know, really more contributors doesn't necessarily help this project because the number of contributors that could possibly be there is incredibly overwhelming to the few people who are there right now. For sure. I think not that many people that are working in open source get a ton of exposure to other ecosystems. So you tend to know kind of like the communities

in which you operate. But there are a lot of parallels and contrasts across different types of open source projects, different languages. And so I think like being in a little bit more of this zoomed out research type position allowed me to have this exposure to lots and lots of different types of projects. And from there, I started kind of zooming out and being like, okay, we have basically like one form of rhetoric to talk about how open source works, which is that it's this large communitarian thing that does seem to be true for certain projects. But then like, I can point to all these other examples that don't seem to fit that model. And so like, why is that? I think like a a lot of the early open source rhetoric has just sort of been holding people back.

And because there really are a lot of amazing examples of these more large scale, highly collaborative projects to point to. And we've even talked about those before. And a lot of what has happened in the Node ecosystem and their focus on liberal contribution policies, I think, is really emblematic of what that future can look like, where you do just enable lots of people to work on a project. So I'm not saying that it doesn't exist at all, but then those rules don't seem to apply or work on a maintainer who's got a small library and just kind of largely doing it by by themselves but the project is being used by millions of people for a while I just wanted to be like okay like clearly there's just something wrong with the project and like if only we can just like you know restructure it somehow and I

think it was sort of being more in the trenches and having to really grapple with those questions and and to be like well why is that not changing here and then again just trying to zoom out and be like okay like what are the patterns that I'm seeing here that explain that did you ever get into like empathy itis or i don't know how to describe it where you get all these emails you mentioned in the book getting all these emails from your inbox being flooded is a good quote you know when your inbox is flooded you're getting a lot of people saying you know i've got open source this or these problems that and they're coming to you not so much for a solution but more just a shoulder to cry on. Like, I've got these problems, please help me or just hear my issues.

Did you ever get into a situation where you're just like, I have no idea how to help you or what advice to give you. I've got these goals in mind for my job and research and plans, but did you ever get bogged down by the empathy and the weight of it all? Very. I'm going to steal that term, empathy-itis, because definitely inflammation of empathy was a thing that I was experiencing. Yeah, gosh. I mean, joining GitHub, for one thing, was already this existential crisis for me, because

I was like, well, I said I was going to solve everything, and what if I can if I'm just at GitHub? And then being at GitHub, I also just felt the stress of like well now I'm at GitHub and I should be able to like solve everything because of course I'm here on the inside and that was really stressful and hard and then even with writing the book like I mean god I like went through it's just sort of like you know is it even useful to be writing about these things like maybe I should be doing more things something that helped me over time which I wish I just had more this early on was I didn't know any other independent researchers or just like

researchers in general. And I guess like when I really like rewind back to the beginning, it's not like I ever, you know, said I was going to like single handedly solve everything. I was just interested in a problem and writing about it. And I think like, because I got so overwhelmed by all these amazing stories from people, I think I felt this burden to like, do something about it. And like, if I can't fix it, then it's my fault. And sometimes like, they're just like very emotional things that people tell you and share with you. And you just want to feel responsible for fixing it somehow. But in talking to other folks that have just spent a lot of time like working closely with communities that they're not necessarily a part of but are just trying to

describe and translate um outside of those communities I just learned a lot I think of like better practices about how to put a little bit more of like a wall for myself to just create a little bit more boundaries and like mentally separate myself from my work sometimes and be able to kind of like turn off and and not stress out too much about it. But it definitely took a little while to get there. One comparison that you draw, which Devin Zugal also drew with us here on the Change Log when we were talking about GitHub sponsors, which has left an impression on me and I think about it a lot more now, is the relationship between a GitHub open source developer and

a solo creator, a YouTuber, an Instagram influencer, right? A Twitter handle. And I want to dive into that a little bit more later, but right now I'm just thinking of it in light of the kind of the plight of the maintainer is that very few, okay, it happens, but very few people become like an Instagram influencer on accident, or they didn't mean to make an awesome YouTube channel and grow it and build an audience. But with open source, many of us find ourselves in this situation where we're like,

we didn't ask for this much responsibility. We were scratching our own itch. We hoped a few people would find this useful. A lot of times we're unaware. There's people, especially in the NTPM community, where it's like all of a sudden your thing just starts getting downloaded in the millions overnight.

And it's because some huge framework or some large company has now used you as a dependency. And you're suddenly thrust into this place of great responsibility and you're all by yourself right there. And it's really kind of crazy.

I mean, I think that's somewhat unique to open source, don't you think? Definitely. I actually hadn't really thought about that before, but you're right. I mean, I think like developers tend to be a little bit more just like wanting to be behind the scenes. And yeah, there are definitely Instagram celebrities and YouTube celebrities or whatever who didn't expect to blow up the way that they did. But there's still something there about like you recorded a video and you uploaded it or you took a photo of yourself and you upload it or whatever. And there is a lot of just like hard work

and hustle that goes into growing those brands. And with open source projects, like, yes, there is a lot of work around sharing things out and marketing yourself. That happens as well. But you're right. Like, I mean, sometimes it's just sort of like, I shared this snippet of code

that I don't know how people are finding this anymore. And I mean, in some cases, their developers are just like, didn't even know that how widely used they are until they have like big companies knocking on their door asking to fix things. And they're just like, oh my God, what is happening? And so, yeah, I think it's like this feeling of wanting to be a little more out of the spotlight. And like, I didn't ask for this is amplified in open source and then also the aspect of like the stakes are much higher where I mentioned this in the book as well but you know like if you're an Instagram creator and you just want to check out of your DMs like it's okay if you don't respond to every single DM whereas for an open source developer it's like if I miss a bug report that is critical then suddenly I have this even bigger

problem on my hands that I especially did not ask for and so it's both that they maybe don't want to be in the spotlight as much and the stakes are higher if they choose to not engage and so I think that those two things make it really scary yeah accidental fame and inherited responsibility sounds like a lot of weight for just someone who's not trying to be famous or take on responsibility like if you're just trying to like share your art with the world which is what code is in many ways yeah i think there's people on periscope or comedians that had if periscope is still around i think is it still around yeah yeah sure just not used very much like there's people who became famous comedians because of just like little skits so there's there is still the accidental creator in that realm that became famous and has gone on

to do things but like there's a lot of weight to just the need to to respond to a bug report for example you mentioned like that's an accidental responsibility that you probably didn't sign up for you're like that's just a bit. But it's like that video is not deployed into somebody else's life on an ongoing basis. If you walk away from your repo... When I drive my car, I'm not dependent upon that video performing well. Right, you just close your Periscope account

or you just stop posting new videos and you can then opt out of that fame and sure, whatever you put out there is out there. It'll reverb down through the ages to a certain degree. But it's not as if you ignoring that is going to cause a future problem in somebody else's software stack somewhere and maybe expose some info. I mean, there's so many things that can go wrong in software that it's kind of crazy, actually. Yeah, I mean, it really gets down to, I think think like for me it very clearly points to like maintenance costs being different from these creation costs and if you think about the example

of a viral video that maybe like unexpectedly went became popular yeah sure someone might have a random huge hit on tiktok or whatever but then they can choose to just not make any more if they wanted to it's like well i had that one really big hit, you know, but if a creator says, oh, I had a really big hit. Now I want to start making more videos and leverage that into like a whole brand. They can do that. Um, but you can think of that as, you know, they're starting to build their reputation as a creator. And then that reputation in itself is something that requires maintenance. Like they have to keep creating content in order for them to like continue to be popular. Um, and I think, yeah, similarly with open source developers, but even more amplified is if they do have that one random viral library,

which is the equivalent of a viral video, then they can't just be like, well, I just chose to do it once and not anymore. There is still an ongoing maintenance cost even with that first thing. Just the play on words about a viral library just makes me giggle a little bit. Because viruses used to be bad in computer software, but now you want to go viral. Of course, viruses are once again bad. It's bad again with the pandemic.

That's right. It keeps circling back around. It's an overloaded word, isn't it? All viruses banned from this competition. You do mention on the note of platforms and creators. I mentioned Periscope. I'm not unaware that TikTok exists, but there are platforms, YouTube, et cetera, that creators hinge upon. You mentioned the criticalness that the role

of a platform plays to creators and that's sort of like relationship back and forth. Can you dive more into, you know, what you've learned about the relationship between the platform, the creator, and the criticalness of that? Definitely. Some of this gets into starting to distinguish between different types of communities. And I talk about this in the context of open source projects, but I think it really just applies to online communities more broadly. And so one of the things that I do in the book is break down different communities based on their level of contributor growth versus their user growth. And so you can think of projects experiencing either very high or low user contributor growth. So we can think like,

I guess like two polar ends of this that might be helpful to think about are what I call clubs, which have high contributor growth, but low user growth. And so that's a project that might exist a little bit more like a hobbyist kind of meetup club kind of thing. The example I use in the book is AstroPi, which is a library for astrophysicists, which is widely used by that particular community, but is not really ever going to go mainstream. And so you have people that have this stake in maintaining it and being a part of it. And then on the other end, you have something they call stadiums, which are projects that have low contributor growth, but high user growth. And so that means

you only have like a couple people that are maintaining the project or really at the helm of it. And then you have a very broad base of users that have little context for what's actually happening in the project community. They're just kind of coming in to like use the project and leave and go do their own thing. And so the argument they make in the book is that clubs and anything that has like a high number of contributors are less tied to platforms than these stadiums are with like individual creators. And so if you're this, you know, hobbyist club, you can kind of imagine like Facebook is maybe like a more useful example here or more concrete. If you're a Facebook group that happens to be on Facebook, you can always migrate to a different platform and then kind of create another community or forum somewhere else. Yes, you might

be missing some of your features, but we've seen this happen with online communities over time, where they might have started on their own random internet forum, they move to Facebook, they move somewhere else. They're a lot less tied to the benefits that platforms provide. Whereas these individual creators who are managing these stadium like communities are much more tied to platforms because platforms are absorb a lot of the costs for them. So things like distribution costs and reach to their own communities, they kind of like are inextricably tied to all those benefits that a platform provides. Actually, there's an example that I put into the book

that since going to print has now changed again, where I talk about Ninja, who live streams Fortnite, which is a video game, and he rose to prominence on Twitch, which is like the default platform for streamers. And he, at some point, announced that he was moving to Mixer, which is a competing Microsoft platform. And he was paid an exorbitant

amount of money to move there. And so at the time that I wrote this in the book, I said, every once in a while, there are examples of creators who are so big that they're capable of moving to another platform. But it very rarely happens. And actually, since the book has gone to print, he announced that he's coming back to Twitch. Well, because Mixer is getting folded, right? Yeah, I think so. Yeah. Yeah, it's just, you know, like,

it's so, so hard to start a competing platform, even when you have all the resources that someone like Microsoft has. And even when you are literally, like, the biggest streamer on Twitch, you still can't leave because in the end, your whole audience is just on that platform. I mean, we see the same thing with open source projects that there are a few examples that I put in

the book. Like one that comes to mind is the project Babel that tried to move off of GitHub issues and use Fabricator for their issue tracking. And very soon afterwards came back to GitHub issues because they're like, you know what? Like no one knows how to use this other thing. They don't want to use the other thing. Like your audience is on GitHub, so you have to be on GitHub. And so it becomes this blessing and a curse where, yes, like, you know, if you're on GitHub,

having the issue tracker right there does just make your life a lot easier. On the other hand, like if you do want to exercise any sort of independence, it's a lot harder to just leave. Yeah. It's especially true for politics and things like that. And in these platforms, you can be on the right or wrong side of an issue, for example, and your content all of a sudden or you gets ejected or canceled and you're very much tied to even the platforms.

Demonetized. How the platform in general, the social constructs of the platform feels about X. You must be in line with it or you you know risk you know a lot of stuff essentially all the benefits of the platform in particular like you lose or could stand to lose those things and you have to play within the rule set right definitely yeah i mean it's platforms as governments now and like i think we should take that really seriously that there is this same social contract that's happening between platforms and creators and uh de-platforming is a really serious thing that can change it's like kicking someone out of a country

right and if that's where everybody you know hangs out that's where society happens not being there means you don't exist in some way right i mean or a version of it yeah it's something that was just trying to like highlight in the book too It's just like, I mean, these platforms are such a huge part of our lives. You could theoretically, if I wanted to share my photos of my vacation on my personal website, I can do that. But I'm probably going to put them on Instagram because that's where my friends are looking. And so they really force us to make these day-to-day choices

based on where everyone is. So we talked about the person who accidentally finds himself in a stadium, and the plight of that scenario. based on where everyone is. So we talked about the person who accidentally finds himself in a stadium, right? And the plight of that scenario. Realistically now, open source has matured and grown up. There's golden them hills. People see the value of a career built on that, right? They see the value of a career.

Just like you watch a YouTuber who's got millions of subscribers and you think that would be a nice life. You know, I could make a good living doing that. And they make videos for a living. I would love to write open source software for a living or just put my creations out there. So let's not ignore the fact that, and you mentioned it Nadia,

that there's lots of people that see this and they say I want to be in the center of a stadium in open source. Is the word of warning to them then that if you achieve the success you're somewhat beholden to GitHub for example or you're beholden to NPM unless you can

make sure that you're somehow diversified and in your platform use what are your thoughts on that well i think the argument i want to make is i guess maybe not even just pronouncing judgment on it one way or the other but to point out that whether we like it or not, we are tied to platforms. I mean, especially in open source. Work in open source, we're very familiar with the argument of GitHub itself is not open source. And so how can we really trust this and GitLab existing as an open source alternative to GitHub? And a lot of developers are just very concerned about whether they'll be able to exit and whether they'll be able to take their stuff. And like, yes, you can do a lot of that with Git, but things like issues are a lot harder to transport. And a lot of the features that only GitHub really provides, even if you can

fork your code or take the code itself somewhere. And I think one of the arguments that I want to make is just that I think platforms have won out for a reason because they do offer a lot of benefits. It's not just that we're locked in and against our will or something, but that there's a reason why creators have become so tied to platforms because they do so much of the work that other options can't really give us, especially with GitHub, as an example. Stability and security and reliability is a really underappreciated aspect of the infrastructure of a platform that is pretty hard to compete with for other platforms and other alternatives. So, yeah, I don't think it's necessarily that they should be concerned, but just more to be like, okay, maybe this is like a condition of what if we start from the premise that things are the way they should be and there's a reason why creators and platforms can work together really symbiotically? And then I think having that lens allows us to be a little bit more critical about where GitHub doesn't meet its responsibilities as a platform provider, especially compared to

other social platforms and their creators. And so that's sort of a thing that I dive into is, you know, like Twitter, for example, for all, maybe not the best product example, but one thing that it does do is it makes it really clear what someone's reputation is. You can see how many people they're following, how many people follow them, who of your mutuals is following each other. And so there are these sort of like legible status markers that make it more possible for you to make something out of your reputation. Whereas I think GitHub has sort of fallen more short of that, and we should talk about that more.

If GitHub is the platform that every developer is tied to, then what is GitHub doing to make it possible for you to work on open source full-time or to reap something from your reputation associated with your open source work or whatever? If on the person's profile and their reputation is a few clicks behind the repository URL issue, it's not like in your face, can you trust this person or person's organization? It's not front and center.

Yeah, and a lot of them use other platforms to build their reputation. So you can more easily get a sense of a prominent open source developer's reputation on Twitter, for example, but you go to their GitHub profile and it's almost, you know, often not even clear, like which projects are they known for? You can pin things to your profile and GitHub is definitely making more and more steps in this direction. And so it's not meant to be this like cynical criticism, but it is, I think, just important to highlight that there are these responsibilities that platforms should have towards our creators. When dealing with application performance, you ask questions like which endpoint is triggering memory increases?

Are slow requests to a particular endpoint cascading to the app? Why is this endpoint slow for only a handful of users? Has this performance pattern occurred before? What changed since the most recent deploy? Those are just a few questions easily answered by Scout APM. Scout is application monitoring that continually tracks down M plus one database queries, sources of memory bloat, performance abnormalities, and a ton more. Thousands of engineers trust Scout APM to help them uncover performance issues you can't see in the charts. Learn more and get started for free at ScoutAPM.com slash changelog. No credit cards required.

Again, ScoutAPM.com slash changelog. So while we're talking about GitHub and their role in everything, since you left, GitHub Sponsors has rolled out. I'd love to get your take on the implementation, the details. What do you think? Is it serving the community well so far? It's still early days for GitHub Sponsors, but it's out of beta and it's in many languages and countries now. Undoubtedly, it's being worked on while you were there, maybe. I'm not sure about that, But what's your take on GitHub sponsors

and how it's helping or not helping the community? Yeah, I'm a huge fan. It's definitely the brainchild of Devin Zuckel, so I'm not going to take credit for it. But yeah, I mean, definitely we were having a lot of those really active conversations while I was at GitHub. And one thing I will say is really cool about

my experience with sponsors so far has just been that especially as I've been starting to do more non-open source things a surprising number of people that are not developers and not involved in open source know about GitHub sponsors which I think is really cool so it's clearly making itself known more broadly beyond just developers so yeah, I think it's a really great experiment to have

for everybody to see and to learn from. There should be more examples of platforms that build funding or subscription mechanisms directly into the platform itself, since you can always raise money on Patreon separately, for example, which a lot of people do. But having sponsorship information appear right alongside your issues or your profile. So you could theoretically see if someone sponsors you, you should be able to see that in your issue thread and only really a platform can offer that end-to-end kind of solution altogether. I really like that it's very developer-centric and not just project-centric, which I think

was another thing that I've just sort of found in talking to open source developers, that historically we talk a lot about, like, open source as project-centric and not so much as developer-centric, because presumably there were just, like, fewer open source projects in the early days, and they were much, much bigger. And so you can picture, you know, like, Linus Torvalds is known for Linux or Git. There are these just like big projects, whereas someone like Cinder Soros today is just known for doing a lot of cool stuff on the internet. He has, you know, literally like thousands of projects. I don't even know, hundreds, thousands that he's written and published that are widely used. And so I think GitHub sponsors taking a step in the direction of saying this isn't just about sponsoring open

source projects themselves, but it's about sponsoring the individual people behind it really helps highlight that a lot of projects are do just have a couple of critical people at the helm and those people deserve our attention and support yeah it's interesting you know the we talk about the platforms and really you can see what a platform is all about by what it prioritizes, what it puts first. In the battle days, as I called them, SourceForge was where everybody went. That's a place that put downloads first. It also put a bunch of ads first.

I would go to SourceForge all the time in the early days of my career and download software. That's where you get free and open source software from. I didn't even realize at times that in that same UI somewhere was a forum and was issued. There was tools for the actual contributors and the insiders knew that because they were on the inside

and they were using it to collaborate. And GitHub really changed things because when you landed on a GitHub repo, especially in the early days, it's still that way now, only it's a lot more design work involved now than it was in the early days. The first thing you saw was the code. I mean, you land on a project and it's the readme now, but it was like, here's the files, here's the actual source code right here. It's very code first. And like you said, the interface for lots of people historically into open source has been

the projects. like i use this project to solve this problem but it's not really the people and only until recently maybe that's why twitter is a place where people go to build that reputation and we talk about the github profile it seems like the people of open source are starting to like come out from behind the scenes of their code and you get to know them and And I think why a lot of reasons that sustainability type solutions are project focused is because that's kind of what you think about as you are like a fringe user of a piece of software is the software first and then you start to maybe realize and meet and interact with the people later.

But the first thing you see often is the code or at least the compiled version of the code. Definitely. I think it really speaks to the influence that these platforms have as the infrastructure that is literally shaping not just our technical infrastructure, but also the types of conversations we have and the types of values that we hold. It is still really hard if you land on a project to get a sense of like, who are the maintainers here? Who are the biggest contributors? Like I'd always go through to looking at commit graphs and seeing who made the most number of commits to this project. But even that is not always perfect. And so it is very not people centric.

And like you said, I think that is why people do tend to build their reputations more off GitHub. And I think GitHub has had this tension of, I mean, even back in the very early days when they were billing themselves as social coding, it's like this tension between the social side and this utility. And so it is a utility. And there's a very good argument to be made

that it shouldn't be adding in all this stuff that is more reputation-based and is more like fluffy people stuff. Like maybe some people just want to get in, get their code and leave. But if this is the one platform that developers are tied to i think it's still within the realm of their responsibility to start considering like how do we actually integrate that kind of stuff in well the community is especially whenever microsoft purchased github

it became concerned about login and as you mentioned like certain features like sponsors or these like diehard features were, you can't do open source without some of the utility. You begin to have this perspective of lock-in, which is something we're trying to, I suppose, be concerned about. But there isn't, in particular to GitHub or open source or software, there isn't a great alternative in terms of what it provides. Not so much in its feature set, but its community. Network effect. Right, exactly. The network

effect only really exists to the degree it exists inside of GitHub. So every new thing like this is just more lock-in. Should we be concerned about that? Should we be like, yeah, that's great? What do you think, Nadia? It's really tough. I think about this framework of exit versus voice. And when you have citizens of a country, or in this case, users of a platform, when is the right time to exercise your voice within that country and be an active participating citizen? And when is the time to leave, aka exit?

I think we place a lot of emphasis in open source on exit, which makes sense because developers like to have autonomy over the things that they make. Yeah, autonomy. It's just extremely, I mean, the whole developer tool space is just sort of littered with people

that are excited to make their own slightly different version of something else that exists. And I think that's really cool. It's just this ongoing sort of creative space. And so I think we are very focused on the exit side of all. I should be able to like take my stuff and go with me. And again, like at its core, you still can do that with your code. I could not imagine a world where GitHub says like, you know, you can't really like, I mean,

you have to be able to take it with you. But I think we sort of like under talk about the voice side of things like even the rhetoric around forking I think has sort of gotten in the way of us having the more active citizen kind of informed conversations because I mean even there I feel like I see this divide between people that say oh you can always fork a project and that's like a big thing about source. And then a lot of folks in modern open source today who are saying, look, I know you can theoretically fork this project, but there's so many dependencies on it right now. Other dependencies that are pointing to this particular repo, all this social infrastructure that was built around it. It's not actually that easy to just fork.

Forking is a technical right. Socially, it's much harder to execute and so we should be concerned but to me the reaction is not we should be concerned and therefore we need to build alternatives and leave like and i think those people will always exist and i trust that developers are always building alternatives to everything so i'm not so concerned that that's not going to happen but i would like to see people be more active participants in the conversation around okay if we are in github then like what can we do to help github understand and make our needs really clear that like we do need these sorts of things right in regards to forking i'll

let people read the tea leaves here but it can take a very long time to, let's say, if a project wants to stop existing for whatever reason. And you can say, well, there's a user base there. The maintainer should continue. The BFL should continue. Whatever might happen. But it might literally take weeks to properly fork, rename, point, et cetera, to keep it moving if you wanted to literally fork it so there's still so much work in the process of forking the button isn't just pressing case of emergency done it's it's a lot of work involved in forking and sometimes maybe just finding amicable ways

forward or literally just letting it die and discontinue there's a lot of work is the point in forking it's not just like an easy button push it yes there's a lot of work is the point in forking. It's not just like an easy button, push it. Yes, there's a lot of nuance there. I think it's commensurate to the size of the thing that you're forking. The bigger it is, the harder it is to fork. The smaller it is, the less moving parts, less people involved, less redirects to put in place, etc. Which begs to point back to the responsibility we talked about

as well as the community ownership. And say a BDFL model where you have one person technically involved in most of the CEO-like roles that you've mentioned in the book, Nadia, where it's like the maintainers in many ways, a CEO of a company. And the responsibility there, and if they want to discontinue for whatever their reasons are do they have all the power does the community have the power well maybe but then they've got this painfulness of potentially a big community and as you said jared it's it's dependent upon the size of the community so it can be very just difficult to to change these things like that who's in control who has the power and it's not even like a github thing it's not like github has the power here we are focusing on the exit you know nad's not like GitHub has the power. Here we are focusing on the exit. Nadia's

like, we should focus on voice. And we're like, yeah, but exiting. Let's talk about exiting. No, I do agree though, Nadia. I think talk it out first. Talk it out first amongst the community is a much better route because in the end, sure, we're talking about code,

but we're talking about people. The code represents a utility to people. And so it's humans, it's relationships. And we undervalue the participation of human beings being kind. And there's so much unkind things happening that we need to be more focused on things that are kind and loving and respectful rather than the opposite of those in communities like this. Yeah. There's so many fascinating governance questions that arise in open source that have so much to say for other types of online communities. One of them just being, as you point out, who even is the community of an open source project? Because on the one hand, you have this language that says, well, everybody who wants to be a

contributor or shows interest in being a contributor is a contributor to the project like I mean there are some projects that will go to that extreme and just say if you think you want to be a contributor then you're part of this community and they do it because they want to be welcoming and I think it comes from this really good place of kindness and and wanting to you know grow the number of people that are pitching in. But I think it really just depends on the type of community you're talking about, where if you have enough of an active contributor community, that there's a sense of membership, there's a sense of culture for that community, then yes, bringing in someone new to that is that can totally work really well. If you're just one person who has like the most contacts for the community and you know nobody else everyone

else is kind of just coming as a casual participant and weighing in on your issues and like it's sort of just like faceless crowds that can be like streaming into your project and we've all seen examples of this happening where there's some sort of controversy and like one maintainer is just suddenly like super overwhelmed it creates this tension over source because it's like well we say that anyone should be able to participate and weigh in. Are your users part of your community? How much say should they have in the development of the project? And then on the other hand, you have in some extremes one person at the helm who's just sort of like, wait, but none of you all even understand how this project works, even if you are an enthusiastic user.

And so it just creates these really interesting and challenging situations. So you put this work into the classification of project types, toys, stadiums, federations, and clubs. And I like that because I don't think anyone's done that work before, or at least I haven't seen it. I'm definitely going to use this as a way of thinking about certain projects. But that's kind of the result, maybe, in certain cases, the result of the way it grows because it's based on user growth versus contributor growth what about explicitly stating

a project's style or classification is there any efforts or any you see anybody going out there and saying this is a club that's a bad example because that's one that you've derived or this is a club. That's a bad example because that's one that you've derived. Or this is a project where anybody, open governance, anybody can contribute. Or this is me putting my code out there. I'm the only one that's going to be committing code. You can look at my code. You can use my code. But I don't take open issues. I know people put those things in their readmes and stuff, but we might benefit from an actual

taxonomy of what kind of project does this want to be? Not what kind did it end up being, which it seems like is what you have here. But what does it want to be in the early days? Is there any work there? Yeah. I mean, like you said, there are folks that put that stuff in their readmes or try to reinforce it through issues. To my knowledge, there isn't a currently existing taxonomy.

And so hopefully those types of conversations will be encouraged if anyone reads my book. But yeah, I mean, we can see that sort of play on in these softer social norms already today. We mentioned Node and sort of this like liberal contribution policy, which is to me is emblematic of federations, which is what I call a high contributor and high user growth type community. So you have this, a lot of people that are participating in the actual development of the project, and then you also have this broad user base to draw upon. So like, of course it makes sense that you're just going to be trying to bring in more and more contributors.

And then you see maybe on the other extreme, a project like Clojure, which I think has done a really good job of being very explicit with their users and contributors and the broader closure community of Rich Hickey who authored it just sort of saying you know this is not a democracy I don't know if he's said the term democracy I think he's said something like you know not everything needs to be community-based or something like that but really trying to say you know like it's a couple of us that are focused on maintaining this thing. And these are the decisions that we make. And we're not trying to do this by vote.

And it is just so hard to create and develop and reinforce those norms. And I think to some extent it becomes a stylistic thing of, you know, if that's not for you, even if you love Clojure, maybe you're just not going to use it. Or maybe you use it and you're just completely not involved in the project development side of things and you just don't even think about it but people do sort of need to opt in and opt out of the types of communities they want to be a part of just like anything else so yeah i do think we see this broad spectrum of different projects taking different stances but how that stuff gets socialized and reinforced just takes a lot of time i want to plus one the need for this taxonomy though, because I think naming things is so important and participation in a community based on like,

if it's a stadium or a club will be an indicator. Like it, it may be clear to some degree, but just stamping it would be so much more helpful. What are some examples of a club? Like the one that I think of, which may or may not be, but I think of like the scuttlebutt community, like that area.

That's a good one. Where it's like really high. If you're using the software, you're probably a contributor, right? Like really high contributor growth, but it's still niche. It's not like everybody's using Scuttlebutt and doesn't know it like OpenSSL. Are there any other examples of clubs that you came across as you were building these out? Yeah. are there any other examples of clubs that you came across as you were building these out yeah and i mentioned um astropie is another sort of like go-to example in my mind of like i mean same

with scuttlebutt where it's just sort of like there's a very specific use that appeals deeply to a smaller group of contributors but like it's probably not going to ever go mainstream i think there are like a fair number of these examples in academia and like academic open source by the way it's just sort of like this funny like i don't know i feel like it is a highly developed ecosystem in itself but it has all these different rules and norms from like other open source just because i think there's sort of like this academic system on top of it and so it's just sort of like fascinating like i feel like someone should do like a long deep dive on academic open source projects but i think a lot of them do turn into clubs because they have this small passionate group of people that are dedicated and have some

specific use case or need for it. I don't know if you remember, oh gosh, Todd Gamblin from SPAC? Yeah, I do remember Todd. Yeah, I feel like that one is probably a club. The High Performance Computing Club. Yes. The coolest club of all. Huge computers.

Yeah, that's a good example. I think also, I'm starting to brainstorm now, I think a lot of robotics projects or anything that's focused around a piece of hardware where there's enthusiasts for the hardware and so springs around it as a club of people writing software for that hardware, Raspberry Pi, stuff like that. Yeah, that's a great example. So federations are pretty easy.

If it has a foundation, it's kind of like a Node foundation, a Linux foundation, although there's also, I don't know how Linux runs. I know Linus is involved in the kernel in non-democratic ways. Yeah, I think we just tend to see more complex governance in

federations because there's just a lot more coordination involved. I would even call stuff like Rust would be a federation. So what about Google's Go project where it's open source, but it's Google's Go? The team at Google advances the language. Is that a stadium then? That's a good question.

I think I would call it it kind of has elements of federation stadium and club in some ways because i mean go doesn't have a huge user base like it does sort of have that enthusiast vibe to it um even though of course it's widely used but it's not like you know python level or something yeah and then like it does have this sort of closed off community of people that are largely developing it. Right. It's tough with languages because they have the language, which is a software project.

But then they also have the community. If you go beyond Go, the language, and you look at Go, the ecosystem, and maybe those are individual projects inside there. There's a whole lot of things going on around that aren't Google driven. Right. Which goes, I mean, I'm sure even some Go developers are listening to this now are like, it's not all about Google, you know, like we do our own thing too. It's true even for Clojure, which I mentioned earlier. I mean, there's still folks that really don't necessarily subscribe as strongly to the feeling of

like we have this one BDFL and want to do more community initiatives. So like these things aren't perfectly cut and dry. Well, I think it's official, Nadia. You cannot retire from the open source space because you have to build this new taxonomy for us. You're the only one suited for the job. This is the last podcast. I'm never doing one again. When's the last time you thought about how your team spends its time on internal tooling?

I bet if you looked at the way your team spends its time, you're probably building and maintaining internal tooling that you probably just shouldn't have to. I mean, there is such a thing as retool. Well, companies like DoorDash, Brex, Plaid, and even Amazon, they use retool to build internal tools super fast. The idea is that almost all internal tools look the same. They're made up of tables, drop-downs, buttons, text input, search. And Retool gives you a point-click, drag-and-drop interface that makes it super simple to build uis like that in hours not days

stop wasting your time use retool check them out at retool.com change log so you came on this show 2016 first ever podcast went on to do request for commits ended up at github you learned a lot there was your plan to go to github part of the overall like plan to research or was it just simply you know was it part of the overall plan to research? Or was it just simply part of this bigger thing? I think the bigger question I'm asking is more like, what are you optimizing for? You got this book you've written. Maybe it's your magnum opus.

I don't know. You're talking about this is your last podcast. What are you trying to do? What have you been trying to do, Nadia? I think she's joking about that one. Yeah, for the record, this is not my last podcast. If you you're listening to this I will still come on your podcast hang it touche people seem to ask me that a lot like what is your deal and then I never have a good answer and then I'm like Jesus am I doing life you seem to give a plan you're operating as if you've got

a blueprint a plan you're working from and I'm kind of curious what that might be yeah I mean I I'm happy whatever is going on in my head, but I don't really know what's going on in there. I mean, like the first thing that all just comes to mind, it's like, I'm optimizing for learning. And that's sort of why over time, I mean, in 2016, when we were first talking, I don't think I really identified with this label, but like over time, I've really come to just think of myself as an independent researcher, regardless of when I'm doing like right now, I, the work I, my day job day to day at Subst think of myself as an independent researcher regardless of when I'm doing like right now I the work I my day job day-to-day at Substack is not as an independent researcher and a lot of people have actually asked me like at GitHub were you doing research

and I was like no I was working in developer marketing and product but I see all of that as like ideally like I like going through these cycles of okay I'm like learning about topic I find it really interesting I'm doing some sort of unbounded exploration around it at my own pace, and then I kind of light upon something that I find that I would just want to go deeper on and understand. The way I think about independent research is you both have to balance this theory side of it, where early on, as I was saying, I'm having these conversations with developers,

but I'm not doing anything myself yet. And then balancing that with the practice side of things, where then I went to GitHub and actually actually had to like, you know, put my money where my mouth was and was wrong about a bunch of things and had to like refine a lot of things. And so, yeah, like I guess like my plan is basically just go between those two things. Like I didn't even leave GitHub to write a book. I just left because I knew that my views on some things had changed based on my experiences there, but I hadn't had time to just like zoom out of that, the day-to-day of working at GitHub to understand the topic better.

And so I ended up moving to Protocol Labs, which is a company founded by my friend Juan, who just like gave me a place to do that independent research and have my own space. And then like that ended up turning into a book, but I didn't even really have a plan with that. But even the course of writing the book and seeing a lot of the parallels from open source to other online communities and just like the development of the web in general is also partly, well, in large part why I'm at Substack today, which is my new day job where I'm looking at different kinds of communities outside of open source. But yeah, I just expect that sort of cycle to go back and forth.

So yeah, I don't know. I hope that the book and I hope that the conversations that we're having just help encourage more people to think about this stuff. But I don't have a deep grand master plan beyond that. I said on a podcast recently, always be learning. ABL. Instead of always be closed and always be learning abl instead of always be closed and always be learning you know because i love it if you're somebody who's curious and then well

thought like you are where you can put those thoughts that you learn and you think through and you you know ruminate on different things you can actually put those back out into the world as like new learnings for others to follow we need people like that you know not everybody has that skill that's a skill you can learn and grow but some people just get it faster than others or for others to follow. We need people like that. Not everybody has that skill. It's a skill you can learn and grow, but some people just get it faster than others or understand it's even possible. I don't think you've done that. Yeah, it's fun for me.

Some people will get their jollies off something else, but for me it's definitely just learning and then sharing what I've learned. What are your biggest learnings over the last few years then? I'm not going to ask you to distill your entire book down into a few factoids, but when you learn you have big things

and you have little things. You pick up a pebble along the way, but every once in a while you see bedrock and you're like, this is true. I thought it might be true, but I've learned that it's true. So I can actually pass that on as a truth. Do you have any of those that stick in your head

where it's like, I didn't know this at first, but I know it now, and I don't know if it first, but I know it now. And I don't know if it's useful to you, but this is true. The big switch that flipped for me, I think, was realizing that there online communities in general for this book and just trying to like find some framework somewhere to understand like how do we talk about communities and how might we talk about them differently when there are these communities at scale and it just feels like whenever we use the term community we always talk about it being this like very highly participatory thing and I think that gets especially amplified in open source where it's like anyone can

contribute. And, but then even if you drill into like open source community dynamics outside of open source, they still talk about what happens when, for example, like newcomers overwhelm an existing community. There's like the eternal September problem. And like, it just amazed me, I guess, that that hasn't made its way back to open source. And so I think like, once I felt more confident being able to say, okay, like, it's a community, but there's still rules. And like, you still like, you know,

there's still an existing culture and set of norms that come with the members of this community. And I dive into like, a lot of the theory of that in the book. I don't know. I guess like, I guess part of me then was just sort of like, well, why is it so controversial to say that? I was actually like very nervous about as I started getting into writing the

book. So I was like, is it okay to say that not all things that are public should be participatory or like, you know, have these conditions attached to them. And then like seeing that kind of bear out slowly in I mean the development of group chats and sort of like these quieter more private places on the internet and just people kind of like taking their more um

controversial conversations to private threads where they feel like they can have just higher contacts with people that know them already. Like that started happening slowly as I was writing the book. And I mean, I feel like now it's totally like fine to talk about that happening. And it's not this horrible, controversial thing, but it's just so interesting to see how those two things are happening in parallel. The real challenge is whenever something happens in private like that and it becomes public. Right. Yeah. Which we're seeing now playing out seeing a couple examples i won't highlight in particular but where there's conversations

happening between people who have contacts so backstory and can potentially be willing to see different you know perspectives or facets to a problem and not judge that person or persons discussing very hard problems gets out into the open, into the media, into public. And it's like, well, all judgment rains down because there's no backstory or context. I'm not saying any particular, but it's just a challenge whenever you have these scenarios where you want to be private about conversations that may deal with social problems or whatever

and they're out in the open which there's just so many hard problems to talk about that don't have easy answers and easy language that comes with talking through them yeah i mean i feel like a lot of this has just been turning into devolving into identity politics and the the wars out there are wild yeah and i'm hoping like part of wanting to just write a book like this is to be like, okay, like I'm not going to take those kinds of sides.

I'm just trying to understand like what are the actual patterns of and structures of these communities that can help us help inform these conversations. And then like, here are some of the conclusions I arrived to. And I just, I would love to see more of that happening. And we are seeing more of that happening,

but like we need to understand what's going on here. And it's not just sort of like we're not going to shout so loudly that the other side is like, oh, you're right, and walk away. There's actually just sort of deeper social infrastructure things that need to be resolved here. Well, your book uses open source as a lens to view many things. What does open source have to say about that in terms of the way communities run, healthy, unhealthy, the way they interact, private conversations, how has it played out in open source scenarios? I think the maintainers who've found some semblance of peace in being able to continuously manage open source projects,

yes, sometimes it comes from getting funding, but one thing I wanted to highlight in there is it's not always about funding like even yeah even if you're making money and working on open source full-time you can still feel super burned out by just the scale and intensity of public interactions that you deal with and so i wanted to go one level deeper on that and just be like okay like what are the maintainers who are doing this well what are they doing and so i dive into some of those things and a lot of it is really just about like boundary setting. Reducing your inbound volume is another aspect of it of how do I just like cut down on the number of like comments or issues or pull requests that I might receive.

And so part of this just like maybe not as widely advertising participation. And then, yeah, some of it is just sort of willfully being like, look, I'm not responding to things or closing issues and being more proactive about that and not feeding the trolls and all that. So yeah, I think there's just a lot that they just have to do to be able to manage that day to day. And I think we can probably learn from that, too. Have you found yourself retreating into the quieter spaces of the internet? I definitely have like the smaller, tight-knit, non-public-by-default social networking tools

that allows me to stay connected, but in smaller groups where I don't feel pressured or I feel like I have to take part in a lot of the public debate or public conversation. Definitely. I still read Twitter regularly, but I don't tweet very much at all anymore. Sometimes I feel guilty about that, but I just, I don't know. I don't feel like I have

anything I want to say, but I am really active on a lot of my group chats and smaller groups with friends. Yeah. And I think like, I really have come to love writing a newsletter, which is, feels a little bit more private to me because it's like, I'm sending out an email and like, if you are getting it, you've subscribed to my newsletter. So you have some idea of who I am. And like, there is just a little more of a high context interaction. And then it does just feel a little bit more like it's okay. If you know, most people are just like reading the newsletter and then going about their day. Like I get responses, but it's not the same as like a tweet where you're like really actively optimizing for engagement.

I feel like having those long-form spaces, podcasts also being an example of that, is just like, we can have a conversation right now, and that's nice. So we've definitely seen the return of email is a thing. And you're right at the bleeding edge of that. So Substack is an email-based community, lots of newsletters. First of all, people are realizing that a direct connection to others is better than a platform connection because like we're talking about earlier when the platform disagrees with you you are you lose access to your audience or your

friends or whatever that you know that group of people is but with email the beauty of email is the federation and the the lack of middleman so to speak so there's that but also it is kind of a more personal medium for multiple reasons and it must be a place that you're interested in because you're you you went to work at substack yeah and a lot of that was really directly informed by the stuff i'd seen in open source. One of the things that I talk about in the book is this idea of like a one-way mirror behavior pattern or interaction where you can put things out in public, but you're, you know, being a little bit more limited about who's participating back. And that's a pattern that I've seen work well for open source developers where it's like, yes, all the code is public. Feel free to take it. Like how responsive I'm going to be to like people that

are trying to like actively develop it. Like Some developers say, I'm actually just not really looking for contributions. I'm very happy to discuss it with you. They are putting down those boundaries. And so I think one thing that is very appealing about newsletters right now is that you can also similarly have those boundaries and just say, look, here's my long form writing. You can't write at that length on Twitter, for example. So you can really just be yourself and think out loud. But it is itself a community.

It's a different type of community because it's centered around the writer and that person, which is more of that stadium type model that I was talking about. I mean, it's kind of like blogging, but there's no RSS feed. You're just delivering the blog into the email inbox. Yeah. Technically, you do get an RSS feed if you want one. But the email delivery is definitely, I think, the major difference. Right.

The subscription process, the UX, is give me your email, not here's a feed. Subscribe to it whenever you feel like it. Right. The exchange. It's very opt-in. You mentioned Maggie Appleton's vision of the web which is sort of pertinent to this conversation even in a recent newsletter you wrote and she describes the dark forest the cozy web digital gardens like why did that resonate with

you yeah i just love seeing this like new and much more nuanced vision of what the web is turning into um i can't even remember all the things that were on there, but you mentioned the dark forest thing, which came out of this blog post that Yancey Strickler wrote, who co-founded Kickstarter, where he's talking about, he is in turn drawing from three body problem, but this concept of a dark forest of like, the reason why you're not seeing a lot of really interesting conversations happening on the super super public sphere is because that environment is perceived to be hostile and so people are kind of like quietly doing this in like their own private space and so um the dark forest version of the web is one where you know there are still a lot of really juicy conversations

happening but like people might think twice about before putting them on twitter they might be just sharing it with their friends which i think is a thing that a lot of people are experiencing. Um, and so yeah, Maggie drew this beautiful drawing of just sort of like here, all the different like corners that are lurking in the web. And so you have these hyper public spaces, you have the Facebooks and the Twitters of, of the world, but then you also have the group messaging. Yeah. I love this idea of just sort of like having cozy corners where to me, like, I mean, some of my group chats do feel like coming home to something. Cause it's like, my friends are always there and you just kind of like say what's up. And it's just like, I think like we're, we're moving toward this world where it's not just this one thing. Like,

and it's actually incredible. Cause I think, I mean, I don't know. I felt like there was a time where we felt like, Oh, we've already developed all the social infrastructure that we're going to have. Like we have the major companies and most of them are owned by Facebook and that's it. But no, I feel like we're really actually in the beginning of this really amazing renaissance where people are finding new ways to interact on different kinds of levels. Yeah, kind of a backlash. Yeah. A correction. Yes.

Previous direction. Well, not all hangouts are controlled by, let's say, regional brands, for example. I'm just trying to think of an analogy of where you have a lot of Red Lobsters in every town or something like that, for example. You don't only eat there, right? You eat at Mom's Pub or Joe's Pub or Susie's Pub or whatever because that's – Lots of pubs, apparently. Yeah, I like pubs. Those are hangouts, right?

They're not owned by the multinational conglomerates, the power holders, so to speak. They're ran by individuals. As well as going to just a friend's house for dinner or something. Totally, a backyard barbecue, hangout, whatever. Sometimes you want to stand up in front of a huge crowd with a microphone and tell them something. There's your public platform and sometimes you need that but a lot of times all you want is a nice pub and some good friends and like everybody

else leave me alone yeah i mean people talk about substack being like a killer of some other you know major social media platform i actually think it's like complimentary and i think it's healthy that we have a lot of these different alternatives and different needs are different depending what you you want to do as you're saying like sometimes I actually do need to be on stage and shouting in a microphone but then I don't want to do that for everything that I do and so I don't see it as like a failure of those major social platforms I just see it as like we are just developing more nuanced taste of the ways we want to interact with each other. Variety. We need variety. Yeah.

Facebook isn't for everybody. And it's not that it's bad or good. It's just that it's not for everybody. Right. So working in public, this is an end of a chapter for you. Any idea what the next chapter looks like, Nadia? Oh, man. I already, it's, writing a book was so miserable.

I know I'm not supposed to say that as an author, but like it's really hard, harder than I expected. And after it was done, I was just like, oh, thank God, you know, I don't want to do that anymore. But immediately I was just like, oh, I kind of want to write another one. So it's definitely yeah, I think it's like having kids or something. Not that I have children. Maybe you guys can win.

But yeah, it's like it's difficult while you're're doing it but it's fun to think about what's next similar the marathon it's the best time to sign up for a marathon is right at the end of the one you just ran right same with the book it's like you do that because you're on that dopamine high like oh it was good right especially when you ship it you're like well rewarding you know that wasn't that hard I could do that again, I think. Yeah. I just miss having that in my life. Right.

So I definitely have some ideas for new research projects I want to take on. And it might be fun to pick one up, even complimentary to the work that I'm doing day to day. So we'll see. I'm not going to promise anything yet. But I'm pretty sure I won't be able to resist trying something new. Well, should we do a giveaway? We got some books to give away. Let's give them away.

Is she going to sign them? Nadia's going to sign them. Apparently. Sweet. And we have actual books to give away. Literally, we have the physical books with autographs by Nadia herself. But this giveaway is for Plus Plus members only. If you haven't heard yet, we've launched our membership.

It's called ChangeLog Plus Plus. And in addition to supporting us, going Plus Plus makes the ads disappear and get you closer to the metal. Learn more about our membership at changelog.com slash plus plus. By the way, Jared and I talked at length about this program on our recent backstage episode. So check the show notes for a link to that episode to learn more. Now, as far as giving me books, first step is to be a plus plus member. And second is, well, there's no step two. We'll select three lucky members at random on September 1st, which is awesome timing because that lines up perfectly with the end of our 40% discounted insider pricing.

We've been soft launching this and had a discount for people like you who love this show, listen all the time, and we wanted to give back by giving a deep discount. So on September 1st, we're bumping that price up 40% on the membership. So right now is the best time to support us and also save and also get a chance to get this awesome book. And this book looks so cool, too. I've seen the print edition. I do not have it in my hand, but I saw a picture. Nadia has one. I do. I saw it on Twitter, and it looks like it's really rad.

It's a very nice print job by Stripe Press. And, of course, if you don't win, go out and pick up working in public where can they get it nadia we know it's august 4th it's out there you can get it in print you can get it i assume as an ebook what's the best place to get the book uh amazon right now um although i'm told that we will have amazon alternatives soon okay for those of you that need them but yeah uh comes print. It is a very beautiful print book. So I recommend that. But it's also available in Kindle and I believe audiobook at some point too. We'll gather the link and put it in the show notes for easy clickings.

But of course, search Working in Public on Amazon. You'll also find it. Nadia, it was awesome talking to you again. It's been a minute. We really appreciate you. And we appreciate all the learnings that you've shared through this book and through our podcast over the years. And we wish you the best of luck on the next chapter. Thanks.

So good chatting with all of you. All right. That's it for this episode of The Change Log. Thanks so much for tuning in. And also huge thanks and congratulations to Nadia on this awesome book. It is cool looking. It is signed. We have a few copies to give away, but hey, that's only for Changelog++ members.

You can learn more about that at changelog.com slash plus plus. Of course, huge thanks to our partners who get it, Linode, Fastly, and Rollbar. Also, huge thanks to Breakmaster Cylinder, our partner in crime, our beats master in residence. Thank you so much, Breakmaster Cylinder, for making all of our awesome beats. And thank you to you for listening. We appreciate it. Thank you so much. And that's it for this week.

We'll see you next week. Thank you. Bye.