The Changelog: Software Development, Open Source - Maintainer spotlight! Feross Aboukhadijeh (Interview)

Episode Date: August 29, 2019

In this episode we’re shining our maintainer spotlight on Feross Aboukhadijeh. Feross is the creator and maintainer of 100's of open source projects which have been downloaded 100's of million of times each month — projects like StandardJS, BitMidi, and WebTorrent to name a few. This episode with Feross continues our maintainer spotlight series where we dig deep into the life of an open source software maintainer. We’re producing this series in partnership with Tidelift. Huge thanks to Tidelift for making this series possible.

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. Welcome back, everyone. This is the Changelog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog.

Today, we're shining our maintainer spotlight on Firas Aboukadej. Firas is the creator and the maintainer of hundreds of open source projects out there, which have been downloaded hundreds of millions of times each month. Projects like StandardJS, BitMedia, and WebTorrent, just to name a few. This episode with Firas continues our Maintainer Spotlight series, where we dig deep into the life of an open source software maintainer. We're producing this series in partnership with Tidelift. Huge thanks to Tidelift for making this series possible. For the uninitiated on Tidelift, they're the first managed open source subscription that pays the maintainers of the exact open source

projects you're using while giving you the commercial support you've been looking for. You can learn more at tidelift.com. And now onto the show. So Firas, we first met you on the changelog back in 2016. Three years ago now, we talked about WebTorrent. You were creator and maintainer of that project. You're still a maintainer, I assume. Today, we're here to talk to you about all things maintainery. I should say, since then, you've joined us on JS Party, regular panelist on that show as well. You maintain 100 plus open source projects,

which are downloaded 100 plus million times per month, according to your GitHub bio. So you have lots of maintainery things to talk about. First of all, thanks for joining us. Yeah, of course. It's awesome to be here. So one of the things which we may or may not focus on, but which you shared recently on JS Party for those interested on episode 83, I think it's called an honest conversation about burnout. You shared your story about maintainer burnout in open source. So for those interested to go deep into that, definitely listen to that

episode. But for us, if you want to give just a quick brief on that, it might be useful to get things started. Yeah. So in that episode, I think we talked about different kinds of burnout. And I brought the perspective of the open source maintainer to the table there. Because of course, there's other kinds of burnout as well, you know, job burnout or something, you know, stuff like that. I think with being a maintainer, the source of burnout is at some point your project that you're in charge of just gets too big for any one person to handle. And initially, the excitement about fixing issues because people are actually using your project turns into something different. Suddenly, it's not like, oh my god, I got an issue. Somebody's using my code.

This is so exciting. And it becomes, oh no, I woke up again and there's another 15 issues. How come people don't like my code? How come I can't write code that has no bugs? When is this ever going to end? Am I just going to be fixing bugs in this code until the day that I die? And it just sometimes can feel a little bit like, you know, hopeless. Absolutely. No doubt. A large part of your story and one shared. I mean, it resonates because it happens so often. It's one of the reasons why even just by circumstance or happenstance, this show so often is focused on things like burnout and sustainability because it's systemic or it's endemic across so many of us.

I was looking at your projects on GitHub and you have 132 repos that you personally own. Of those, 123 of them are source repos. So that's most of them. And then of course, WebTorrent has its own org, so it's not technically yours, but it's also one of your big projects. So it got me thinking, are you mostly a maintainer of your own projects

or have you contributed to others? Have you ever been on the side of contributor to open source? Yeah, that's a good question. I definitely think I've done more of the creating projects from scratch to solve my own problems and then becoming a maintainer of those. There is one time when I did a bit of contribution to something else, which was Browserify, which is a package for taking your JavaScript code and bundling it up so that it can work in a web browser.

Yeah. But besides that, yeah, I think that's actually an interesting point. I've sort of come at it from like, I'm going to make this stuff because it's useful for me, and I'm going to put it out there. And then people just ended up, you know, using it. And then I became kind of responsible for keeping it in good shape. What about starting out? How did you even get into open source? Sometimes the path for maintainers is somewhat even accidental. Did you intend to be, in quotes, an open source software maintainer? No, I don't think I did. I mean, I think I admired open source and I saw it as this thing that really great programmers could do. And I didn't

really understand that anybody could publish open source at first. So I started my first sort of use of like, where I remember actually installing like open source was when I was doing Ruby on Rails in college. And I remember, whenever I had a problem, I would just Google it, and it would install this package, and it solves your problem. And I remember, I remember, I knew that somebody wrote that. And I remember thinking like, they must be really, really good. And it's almost like some kind of secret society that you have to, you know, be inducted into or something. And I didn't really understand the process for that. And it wasn't really a thing I thought I could do. But then I think where that started to change was, I don't remember how I stumbled upon this, but I found a YouTube video where this guy named Paul Irish, who does a lot of JavaScript stuff, and I

think he works on the Chrome team now, he posted a video about himself just going through the source code of jQuery, and like line by line, and just talking about different aspects of it. And I think he called it 10 things I learned from jQuery, from looking at the jQuery source. And then he did like another video where he said 10 more from jQuery from looking at the jQuery source and then he did like another video where he said 10 more things I learned from looking at the jQuery source so I watched those and I think it made it clear to me that like oh this is actually a thing that I could understand and that it's totally possible for somebody you know if they had the time and they and they you know knew enough things that that they could do this and so I thought you know maybe one day I'll be able to do that and that's when I got like the first seed of the idea

that maybe if I get really good, I'll be able to do this someday. Around what year was this, just timeline-wise? This was, I was in college. I think it was like my second to last year or my last year of college. So that would be like 2011 or 2012. So that's still in the, you know, rise or sort of re-emergence of open source with GitHub because I think, you know, you sort of re-emergence of open source with github because i think you know you speak to this exclusivity kind of factor and i think some of that is just sort of like

just capability like we used to live in a system where it was just harder to collaborate on code and now it's gotten easier and easier to actually even publish ideas too you know thinking of source code as an idea for example so. So GitHub has really changed that a lot for, I would say, the future of software. Because while you may have come in the game, you know, 2010, 2011 for us, you know, GitHub came on the scene around 2008. And that was sort of like the beginning of, you know, open source moving fast. Absolutely. Yeah, I think that was really a big change. I mean, I wasn't really around before, you know, I source moving fast. Absolutely. Yeah, I think I think that was really a big change. I mean, I wasn't really around before. And I wasn't contributing to open source before GitHub, but I definitely feel like GitHub has changed things. I mean, the ease with which you can

publish stuff and the fact that you know, anyone can open an issue on your code is, I guess that's pretty paradigm shifting. Because I mean, if you think about it, it's like so much easier now to get involved. You don't have to just send code to like an email list or something and get people to review it that way. You can just send it directly to the person. And it's a standardized process for every project. Instead of this bespoke thing where you have to go to the website and read about what is this project's process. Everybody has a different way. Yeah. Yeah. And I think that's actually part of the reason why a lot more maintainers are getting burned out because this is one of those things

where it's like a blessing and a curse. It's obviously good that more people can get involved and we lower the barrier to entry, but it also means that you're going to get, as a maintainer, you're going to get way more issues from people who have in a lot of the time put in like less effort into their issues and just say like, it broke fix, please, you know, like with like no information. You're like, okay, can't really help you or like, you know, you just get way more. Yeah, just people who could have never, you know, would have never thought of contributing before who like find a GitHub page and open the code and crack it open But I'm curious, which ones are those or which ones are the, which ones require the most hands-on maintenance to this day? Are those the ones where you're actively maintaining or are they passive? Tell us about

the burden. Which of your projects bear the most burden? That's a good question because it wasn't obvious at first to me what projects would end up taking the most time and which wouldn't. Obviously with more than 100 projects, if each one was taking a bunch of time, it obviously

wouldn't really work. So most of those aren't that much work. Most of those are just a package that just does one thing. It's very clear what it does. It has an API that isn't going to change. Although maybe now that Node is switching from callback first pattern to promises, maybe a lot of them need to change. And I'm starting to do a little bit of work on that. But yeah, in general, the idea is that those types of packages, they don't change very often. Either they work or they don't. And then, you know, usually, usually they just change if

there's like some kind of an API that's deprecated that you use, you know, or if like the entire ecosystem changes, it's like a paradigm of like how you, you know, how you interact with stuff. But the packages that really take up your time are ones where it's less clear what they should be doing. And it's much more of a opinion thing or a taste thing or where the API surface area is quite large. And so there's a lot of discussion about, should we add this feature? Does this feature belong in the library or does it not?

That kind of discussion wouldn't happen on a package that just does one thing. You would just say, sorry, if somebody had proposed adding something to it that just didn't make sense. It's very simple. You say, no, this know, if somebody had, you know, proposed adding something to it that just didn't make sense. It's very simple. You know, you say, no, this doesn't belong here. Make that a different package, you know, problem solved. With those larger projects, it's sort of debatable. And so you end up spending a lot of time trying to decide whether to add something or not. You usually have a huge list of features that you haven't really gotten to yet

that you want to get to. There's a lot of focus on making the thing easy to consume for people. So, you know, you try it, you try a lot of focus on making the thing easy to consume for people. So, you know, you try a lot of experiments with how the API should work and you change that over time. And then also like WebTorrent, you know, is built on a foundation of pretty experimental technology that's changing. So that sort of ends up causing a lot of sort of shifting under,

you know, if you build your project on a shifting foundation, it's going to take a lot of work to, you know, keep things working as the browsers evolve the standards. well seems like most of your stuff i mean maybe standard isn't because we should mention standard as a coding style linter etc which once you have certain opinions that are enforced i'm not sure exactly how standard works but i assume that's relatively stable once it's set in stone but a lot of your other stuff are built on the web, the web projects, aside from some of your websites and stuff like Bitmedia, which I guess those might be

moving targets as well. I guess my point here is, it seems like lots of your stuff is on a shifting foundation, right? Not very much of the web is standing still, and so BitRot's very much a thing. I think a lot of it is pure functions, and it doesn't need a lot of active work. But yeah, anytime you're interacting with a web API,

that stuff shifts all the time. Can you speak to, since we're talking about these two projects in particular, WebTorrent and Standard, I'm noticing on both of them you have this notion of sponsors and one of them being Brave, which is the browser i tend to use day to day what's it like what what has open source enabled you for you you know these kind of connections you've i'm sure you've spoken with folks at brave there's some sort of relationship there can you share the backstory there yeah so i think the story there is that brendan ike the creator of javascript he's the ceo of brave at some point reached out to me because he liked the web torrent stuff I was doing.

And so we got dinner and just talked. Wait, so you had dinner with Ben and Ike? Yeah. There you go, boys and girls. See, that's what can happen to you. Dinner with the inventor of the language. Yeah, so we talked about like how... So the cool thing about Brave is that because it's a new browser,

they can sort of do things that other browsers would be a little bit afraid to do. Meaning like they can they can take bigger technical risks. If you have a browser that's huge and has billions of users, then you're going to be very conservative about what you ship to them. You want to make sure it's really solid and you're really worried about what can go wrong. But with Brave, they were building this browser from scratch. And so they were looking for features that could differentiate Brave from other browsers, and were willing to add new protocols and new ideas to the browser. And that's where our collaboration came from. So the idea there is that just like how a browser can open up a PDF file and show you the PDF directly there in the browser without requiring you to have another program

installed on your computer for that, we wanted to make Brave do the same thing with torrent files. So if you go to a site and there's a torrent file there, or there's a magnet link, which is just another form of a torrent file, and you click on that, instead of it sort of saying, popping you out to some program that you have on your computer, or just telling you it doesn't work because you don't have a torrent program, it will just work right there in the browser. It'll just say, okay, this is a torrent. Do you want to begin torrenting this? And you can say start and then there it goes. Wow. Built right in. Built right in. Yeah. That was the idea. And so, yeah, back in 2016, I think me and a friend went to Brave for like a couple of weeks and we built in WebTorrent into Brave.

It only took a few weeks of work because most of the work was already there in the WebTorrent library. Yeah. And they paid us for that. It was like a contracting gig. Actually, one of the few times I've actually gotten paid for my work on WebTorrent. Wow. Yeah. I think that's, I think really that and then the sponsorship, a couple of sponsors that just put in money for their, to get their logo on the website. Right. Yeah. But I'm actually back at Brave right now. So it's been a couple of years and they have me back there now for a couple of weeks this summer.

Right now, literally right now or like timeframe right now? Like right now, yeah. Like I started working there again last week and I'm going to probably be there another week after this. So it's like two or three weeks total. So they pull you in for like new features,

new ideas, brainstorming how Brave is actually using WebTorrent, feedback loop, etc. Yeah, it's both. So there's a bunch of new projects they want to look into adding like different kinds of syncing models for doing browser sync using peer-to-peer instead

of centralized services. And so brainstorming some of that stuff, you know, and other new things. And then also just updating the web torrent implementation to make it a little bit more solid and add some features that users have been requesting. Yeah, so that's one of the cool things.

If you're the maintainer of a project and you have a lot of experience, then that is like one model for how to kind of sustain the open sources is to have people who use your code, you know, call you in for, for expert advice, basically, you know,

you know, even though they could figure it out themselves, they sometimes they prefer to just have the person who works on it to just come in there. Why not? If you could, right? Yeah.

It's one of the funnest things I've done. It's definitely really cool. They're, they're really good people like working with them. So this is kind of like a hero story. What about a war story? Something that other maintainers can sort of like latch on to. Something that's like you're in the trenches, you got some buddy knuckles, you're fighting the fight.

You know, what's that for you? What's a war story for you? Hmm. A maintainer war story. I haven't really thought of that before. Surprise. Surprise. Yeah.

I got one story. Maybe it'll be interesting. Back when I was getting started, actually, I don't know how far back to go here because I could go back to the very beginning. It might be too much information. Your birth? back in 2013. It was the first conference I ever spoke at. And I was giving a talk on WebRTC, which I had been learning a lot about at the time. So I did a company called PeerCDN. This is what I did right after college, before I had really gotten into open source. I guess I will go a little bit into the backstory of that since it's come up now. Is that okay? We're pulling it out of you. All right. Keep going. Yeah. so basically I had this kind of mischievous idea

that I wanted to figure out what could I do with people's browsers that they wouldn't expect me to be able to do. So like, how can I push these APIs to their limits? Which by the way is funny because I still think that way. If you know about my annoying website, you know, theannoyingsite.com.

It's very simple. I was going to say mischievous ideas is kind of your whole brand. Yeah. I guess, yeah. That also gives us a chance to plug GS Party once again because you actually spoke about that

annoying website on an episode of GS Party I would say at least a year ago, I bet. But continue, continue. So I was thinking of different things I could do and one of the things

I was really curious about was could I do computation using WebGL or workers to do useful work on people's browsers? You sort of use it as a distributed computer. Yeah, so I looked into that and the browser wasn't really quite fast enough. So I then discovered WebRTC, which lets you do peer-to-peer connections between browsers. And the idea that I had was why don't we connect a bunch of sites

together and build something kind of like a torrent network where the resources for a site can come from from the other people on the site and we can reduce the cost of running a site and so i ran with that idea for a little bit and tried to make a company out of it but i learned a learned a ton about how not to do a company i guess yeah like one of the big problems we you know we had was just being too focused on building stuff writing code and not really talking to customers and seeing if there are people who would want to ever buy this stuff. So a little bit of time went by there, and we didn't really have any customers,

but we spent about a year just building a bunch of really cool technology, learning all about WebRTC and making some cool demos. And in the end, we got acquired by Yahoo, which was a good outcome for us because we didn't have any customers. And we worked on this thing for about a year. So it was a really outcome for us because we didn't have any customers. And we worked on this thing for about a year. So it was a really exciting outcome where we got to go and just basically join the video team at Yahoo and made a little bit of cash, obviously. And that's actually what enabled me to spend a lot of time on open source later and not worry about having a job.

And I could just sort of fully devote myself to, you know, for years, just working on stuff and, you know, giving it away and not having to be, you know, worried about making ends meet. But anyway, so getting back on track. So at the end of, so right about when that happened, I gave this talk at Realtime Conf and I was talking about WebRTC and how cool it is

and what you could build with it. And at the very end of that talk, I mentioned the idea for WebTorrent because I knew that Yahoo was going to buy, you know, was going to have all the technology we had worked on. And my concern was that, you know, that some of the ideas, you know, of connecting everybody's browsers together and making a really amazing peer-to-peer network that can, you know, decentralize control of things, you know, that was a really cool idea. And I didn't want it to die with, you know, with this acquisition. So I was like, what if we

rebuilt Pure CDN basically, right? We rebuilt it from scratch, but made the goal instead of saving money on bandwidth, we made the goal decentralization. And we made it match the BitTorrent protocol as much as possible, because we know that already works. And that has a lot of and there's all this content on there and there's just there's a big community of people so we could just make this basically bring the BitTorrent protocol and put it put it into the browser right so it was just an idea that I thought would be cool to work on and I wanted to start working on it so I threw in this slide at the very very end of the talk you know like the last one minute of it or 30 seconds. And I said, I have this idea to make BitTorrent on the web. Here's what it would do. If you think this is a cool

idea, come talk to me. And I threw it out there as just this like thing that would be, you know, I wanted people to come and just, I wanted to find collaborators basically. But one of the people in the audience misunderstood what I said. And I did have a GitHub repo up with a readme in it that just said what the project would do one day. And he tweeted it and he had quite a few followers who like clicked through this link and said, you know, dude, there's no code here. What is this project? And so then he messaged me and was like, dude, I thought you had code. Why did I tweet this out to all my followers? There's nothing here. And I was like, dude, you could have looked at the readme, man. It was clear that it was just

an idea. So this guy basically launched WebTorrent for me before there was actually any code. I think it was a good thing that he did that because I don't know if I would have built it otherwise. It was just this idea.

It wasn't clear whether people would want to use otherwise. It was just this idea. It was kind of, it wasn't clear whether people would want to use it or anything like that. But because of their reaction, all the people who started opening issues and saying, this is a cool idea. I really think you should do this. I got really motivated. And I really wanted to actually build it at that point. That's really a great story. The thing I find funniest about it is you inadvertently fixed the problem. So the problem, your classic blunder was, you know, you build all this stuff without customers for pure CDN. And then by way of the slide, basically, you got all these customers without any software. I mean, quote unquote, customers, right? Like, you prove the demand for web torrent, without a single line of code, I go, read me. Kind of by happenstance by somebody tweeting now, but that's awesome.

That's the way you do it right there. Yeah, launch first without anything. You know, vaporware, that's the way to go, right? You should do a new talk, launch without code, get customers. I mean, this is actually typical startup advice that people always give, but I never experienced it firsthand. I think there's just far too many people who... I don't want to generalize here, but I guess I will have to generalize a little bit.

As technologists, we get really excited about code. We want to spend all of our time writing code. And so we can sometimes just get way too caught up in actually just only doing code and not really thinking if anyone's ever going to use it or if it has any value to other people. And I don't want to say that all code has to have, you know, a utility to other people, because sometimes you just want to do an art project or you just want to make something because it feels good to work on it. And, you know, that's great. But if you think that people will use your thing eventually, it's important to show it to people early and often

and to get people to see it and to give you feedback and to confirm that they're, that they're actually excited, that there's people who are actually excited and to hone how you explain it to people. So just to make sure you can actually explain, explain what you're doing. Cause so many projects can't even do like a lot of, you know, I just came back from the, from the decentralized web summit,

which is this conference where all these different peer to peer projects were, were presenting. And so many people there couldn't explain what they were building in a few sentences. You could even give them a few paragraphs and they still couldn't explain why it was useful to anybody. Yeah. This really speaks to the why and the how, right? The importance of the why to gain followers is not always as critical as the how. The code is somewhat the how,

but the why is what I think is what you put out there with that last slide of here's why I want to do it, here's how I think I can do it. And the why was very crucial to success of WebTorrent, as you said. And to get people who are interested to come and find you, by putting it out there, there are all these collaborators who sort of came out and, you know,

actually introduced themselves to me and said, you know, hey, this is great, I want to help. You know, you can't really do that if you're just coding away by yourself. If I could try to generalize your generalization to go one more step. If you take code as art off the table and say, we're talking about utilitarian code,

there's really two kinds of projects. There's one where you're scratching your own itch, and if it's that style, then the right methodology is, well, create the backscratcher. I got an itch, I'm going to create the code first, and then if other people find it useful, now I have a successful open source project.

And then there's the other kind, which is, I need to find people with an itch that I would like to scratch. Or I have an idea of a really cool new backscratcher, do I build it and then hope people have the itch on their back? I'm really killing the metaphor. But do I build first, or do I get the idea out there first? In that case, it's foolish to actually build the thing first. I mean, you can try to do both at the same time.

That's the best. If you can be scratching your own itch and you know everybody else is dying for a solution, I mean, that's actually a perfect situation. That would be nice. In a perfect world. So as a meta note, I love how Firas' war story is like, I won the war. It was easy. You know, like everything went great at the end.

It's kind of great. It's successful. Maybe I It's a successful war story. Maybe I don't understand what war story means. War story is usually whenever things don't go right. Battles, you know. You're sweating, you're blood. Usually it's an opportunity to complain about some users who are opening issues

that you hate. I guess I have a story of Standard.js when that first launched. There was a bunch of haters. That's probably a more appropriate war story. Well, Standard.js, because it is about style and whatnot, I assume it's open to the most bike shedding of any project out there, right?

Because it's like, this style is good or bad for every little aspect of the code you write. Is that what happened? Yeah, so, I mean, initially the goal of standard wasn't to tell everybody to write their code like the way I write my code. The goal was to save time on web torrents, on pull requests, where people were sending in these pull requests that I wanted to accept, but I couldn't because they just completely didn't follow the style guide of the project. So the goal was, okay, I want to just, I mean, what I should have done is probably just added

ESLint, or I think at the time, it was JS Hint that was popular. I should have just added that to the project and just moved on with my life. But the problem I faced was, if you use JS Hint, then you had to add this config file to like to each of the projects to sort of say what the style rules were. And this was like a hundred line file with all these options. And I didn't want to make a bunch of copies of it and put it into every different package. And so I was like, oh, there's a solution to this. Let's make another package.

Every problem in computer science can be solved with another level of indirection, right? With one more package, exactly. Exactly. So I just made another package and I put the little config file for the linter in there. Yeah. And then I just made every different WebTorrent project require that project. And then the question was, what do I call this package?

And so I was going to call it WebTorrent style or Feroce style or something like that. But then I was like wait a minute I should search for dictionary words and see if there's like a word relating to like you know code enforcement or something and I so I almost named it like I think enforcer or something or something like that but anyway then I then I found the word standard that was available and I thought ah I should call it standard because that will annoy people. That's right. I actually thought that it would annoy people. From the creator of the most annoying website comes a linter that's going to annoy people. Well, I mean, the thing is, it is a code standard, right?

So the name standard by itself shouldn't have offended that many people. But then I was like, okay, since I'm naming it standard, let's just go all out. Let's just call this JavaScript standard style instead of like for us as a style or something. And then just that title of the readme just set everybody off. They were like, how dare you? How dare you call yourself the standard? Are you a standards body? Is this part of ECMAScript? Are you part of TC39? And I was like, I'm not saying any of those things. I'm just saying that this is a style guide and you're free to use it if you want. If you want? If you want. Yeah.

That's right. Yeah. I mean, the thing that helped me at that time was like, I did get quite a lot of backlash, but then there were these friends of mine who thought that standard was a great idea. And they sort of dealt with all the people on github they responded to all the issues and sort of just you know said you know you guys are being haters if you don't want to use it you don't have to use it take it or leave it you know uh and and they sort of dealt with that for me and that made me feel really good it made me feel like i wasn't like that i should i shouldn't you know apologize and like delete it you know what i mean you chose a

provocative name you got a provocative response. And that's cool. That's how it works. Yeah. And the funny thing is that the main advantage of standard, I thought, was going to be that you didn't have to include the same big configuration file in every one of your projects. But it turned out that actually the real benefit that people liked about it was that they could just adopt it without having to make all the decisions themselves. And I didn't even know that that was going to be what people used it for. Sure. Yeah. They were adopting it because they liked that they could tell their team who was fighting about style rules and changing the ESLint configuration constantly and wasting a lot of time. They could just say, hey, everybody, there's this thing called standard that we can just use and we

can just end all these bike-sheddy discussions. That was actually the huge win. It was actually because it was called standard, it could just end a bunch of fights in different people's companies. Which, you know, who would have known that was actually the real benefit, you know? And we've seen languages with

official implementations adding formatter tools to the toolkit for that exact reason. Like Go, Fumpt, as they like to pronounce it. The adding formatter tools to the toolkit for that exact reason. Like GoFormatter. Elixir recently added a formatter as part of its mixed tools so that these conversations just don't have to happen.

This is the format. You follow it or you can have your own style if you want. We're not going to force you to do that, but if you want to just follow the style, run the tool, it's going to reformat your code and we don't have to have these bike-shed conversations. It's interesting in the JavaScript land that there's no

one implementation to rule them all. Maybe to a certain degree there is practically, but there's not a single company or entity that runs it. It's all based on boards and what have you, implementers. But here comes a one-off

JavaScript library from a guy named Firas. He just calls it the standard. Who does he think he is? Come on now. Yeah, who did you think you were, Firas? Yeah, I mean, it was called Firas. What did Brennan Eick have to say when you talked about it? He adopted it at Brave. Well, there you go. Dang.

It's the standard now. Now it is the standard. Exactly. The inventor of the language endorsed it. And then also, believe it or not, Tim Berners-Lee, the inventor of the web, also uses standard. Okay.

There we go. That's all the street cred you need. I saw a sticker on his computer at the D-Web Summit in 2016. I was actually the one who gave him the sticker. Disclosure. I put it on his laptop. No, no, no. I gave it to him because I knew he used it. I saw it on his GitHub. And then I was like, yo, you should take this sticker. And then he put it on his laptop. No, I mean, yeah, I would not have guessed that that was really going to be the benefit of standard, that it would end all

those style debates for people. I mean, the flip side of that is that I basically took on all the style debates for other people. I mean, so now instead of every company fighting out whether or not they should put the curly brace on the same line or on the next line or whatever, all these random discussions that... Same line. Yeah. Yeah. Obviously, same line.

But instead of every company having to have this fight separately, the idea is like, we'll just take it to the standard repo and have the fight there, and then decision gets made and then we can all stop fighting about it in all the different companies. But that just means that my life became a lot more about talking about style when the whole point was that

I was trying to avoid writing style feedback and pull requests on web toursrents. So it sort of backfired on me. And I'm one of your all-time backfires. Yeah, I mean, it helped a lot of other people. So I'll take that, you know, backfire. All right. I hope you've been enjoying this conversation with Faraz for our Maintainer Spotlight series.

Special thanks to Tidelift. We're producing this podcast series in partnership with Tidelift because we both deeply care about supporting the maintainers of open source software. Our goal with this series is to dig deep into the life of an open source software maintainer, to learn what challenges they face, the highs and lows of being a maintainer, how they financially support their projects, how they maintain balance between life, day job, and open source, and also how they're supporting and encouraging contributions and community. For the uninitiated on Tidelift, they're the first managed open source subscription model that pays the maintainers of the exact open source projects you depend on, Thank you. Speaking of standards, at least on GitHub and actually on the standard repo, you've got the newest standard for sustaining and supporting projects,

which is the sponsor button, the funding.yaml file. What has that done for Standard itself? Can you speak to GitHub sponsors or just the sustainability of your projects? You mentioned before being a Brave and that being one of the first times you ever paid for your open source. So can you speak to the getting paid aspect and what it means to you? Yeah, totally.

I mean, so like I mentioned before, I worked on open source funded mainly by my savings that I got from working at Yahoo. So I did that for like a year and saved some money up and that was sort of what enabled me to put so much time into open source

and to not have to worry about other things and to not have to sort of squeeze it in after a day job. So that was really great. But I mean, that obviously can't last forever. Savings run out, reality hits you eventually. Basically, I think it was like the beginning of 2018 where I was like, okay, this isn't going to work indefinitely.

I need to think about how to get paid for open source or else I'm not going to be able to keep doing it. I mean, there's obviously other collaborators who help out with stuff, but there's no one really working full time on WebTorrent and on any of the code I've created. And so my concern was that this stuff would just get unmaintained if I left it and it wouldn't be in as good of shape as I would want it to be. And so I started having these feelings of guilt of like, I can't just abandon this stuff. I can't just not work on it anymore. I was like, okay, the solution is I have to just get paid. If I could find some way to get paid so that I could

work on this at least 10 hours a week or 20 hours a week, something like that. I could really do this thing that I enjoy, keep all this code in really good shape. That would be ideal, right? So I started exploring different funding models in the beginning of 2018. I made this package called Thanks, which you could run it in your Node project. You'd run npx, you know, space, thanks. And I would just execute this thanks program. And what it did is it would go through your package, your package.json file, and it would find all the packages

you're depending upon and their dependencies, and then it would look up and see, are any of the authors of these packages currently seeking donations on a platform like Patreon or Open Collective? And if so, it would just, you know, print out a list of people you could donate to. And then I started a Patreon as well to solicit donations from my users.

And I thought this would be a great solution for funding it because people would just be happy to give you money for the work that they rely on. Turned out it didn't really work out quite as nicely as that because people, I don't know, people don't, I think people are just too used to getting stuff for free and it's this optional step that they can do afterwards and it's just, it got, you know, a few people ran it, it raised awareness of, you know,

of what packages people are depending upon and stuff like that. It didn't really help me at all. The main person I think who benefited was Sindra Sorhus, the Node no JS contributor, because he shows up at the top of pretty much everyone's list of, of thanks. Yeah. So, because he, he just has so many of these tiny packages that everybody uses. So it would just, it would say, you know, pretty much every time somebody ran it, it would say, you should donate to Cinder Sorhus. Uh, and, uh, I, I looked at his Patreon, um, like statistics and you can see a little blip where his, his, um, I, I looked at his Patreon, um, like statistics and you can see a little blip

where his, his, um, monthly money went up by like $200 a month, right. When I released, thanks. Come on, Sendra, send some of that back Ross's way. Yeah. But, um, but yeah, so, so then I, I started promoting my Patreon, like on Twitter and trying to get other people to, to make Patreons around that time. And, um, I was like moderately successful, I say but not enough to to um allow me to work on open source full-time or even even part-time and living in the bay area where i live it's just too expensive so yeah i was kind of bummed by that i like the potentially

accidental standard additional standard here i guess because you've got frost.org slash thanks, which I think is pretty cool as a software maintainer and open source software maintainer to have this sort of, you know, whomever you are thinking, you know, you get your platinum sponsors there, your gold sponsors there, people who are helping you maintain this lifestyle of being a, an open source software maintainer. So you're, you're not only putting your thanks out to the world, but you're also inviting those to come in to support you via Patreon, GitHub sponsors, even Bitcoin. I think this is an interesting thing that I'm curious if more software maintainers who desire to be sustained by their community could do to enable this?

Yeah. I mean, I think that, I think that it is a thing that you can do, but it's, I've thought about this a bunch. So I guess I can, I can list off a few things that people should keep in mind if they,

if they want to go this route, things that make it hard. So, so the first is that, um, companies can't donate money to people in general. It's, it's, it's,

it's, it's a lot harder for like a company to do a donation than it is for them to just buy a product. So if I was selling something for like I was selling a license to a text editor like Sublime Text for $100, then pretty much any

developer at that company could just buy that editor and then expense the $100 to their company and their company would have no problem paying for that editor because it's making their developers more productive, right? So, but if that same developer goes to their boss and says, you know, hey, we use code by this guy named Frost and a bunch of these other people and, you know, they're asking for donations. Can we donate to them? Their manager is going to be like, well, we can't, how do we do that? We need an invoice saying that we're paying for something. We're not a charity, we're a company. So we have to be buying, we can buy things for ourselves, but we can't just give money away.

And even if they really do, if that manager happens to be one of the few managers who really would appreciate the value of open source and wants to donate, and they go to their CFO or whatever, their finance officer and say they want to do this, that person's going to be like, who's this person? We can't just give money to a random person. How are we going to explain that to our shareholders or on our taxes or whatever? So one big problem is just what are you actually asking for from these companies? If you're not giving them something that they can just pay for, then they're not going to be able to support you. That's like one huge lesson I learned.

So like an example, like what can you actually ask for? Well, you can say, okay, this is not a donation. This is a sponsorship. You're buying advertising basically on the project's website. You're going to get your logo there and you're going to put a link to your site. And we're going to say, you know, you support open source. You're not paying for the support. You're paying for the your logo there and you're going to put a link to your site. And we're going to say, you know, you support open source. You're not paying for the support.

You're paying for the advertising of your support. Yeah. And that's something that they kind of understand because they actually already have a budget for advertising. Yeah. That was a lesson that took me way too long to learn. It might also increase your pool of money to access as well because sometimes advertising and marketing budgets can be bigger or brand association budgets can be bigger than just simply the donations pile, for example, which seems to be pretty small or non-existent.

Yeah. Or very hard to execute on. The other thing that was sort of sad about the, I mean, the donations thing was like a bunch of the people who were donating to me were other open source maintainers. So it was like not really accomplishing the goal. I was like, and then I would donate back to them. So like if you have somebody, so we had this like a bunch of this like really weird ring where we were all donating like $10 or $20 to each other in a big circle. And so it looked like we were getting $400 a month, but it was actually just... I was giving a bunch of money to everybody and then they were giving it to everybody else.

And it was all just coming back to us. And then there's obviously other nice individuals who also were doing some donations. But I just think that you know the main people who have to sort of fix this problem are going to be companies and we have to find a way to make it so that they want to want to pay for something that where they're actually getting value from it um and and that that will be a much easier conversation to have with companies than like what we've been trying which is where we say here's all of our code for free. You can do whatever you want with it. Oh, and by the way,

could you please consider giving something back? That conversation doesn't work if the goal is to get paid to work on open source. It just doesn't work. I want to ask you about what's working, what's not working. Before that, I'd like to do a quick disclaimer. So on your standard standard,

you have in the funny animal, GitHub for us, Patreon for us, Tidelift NPM standard. So you are a Tidelift supporter. This series is maintainer spotlight. We are doing in partnership with Tidelift. They are sponsors of this episode. That being said, we are not required to talk about Tidelift.

We can say whatever we like. We did not invite for us on the show because he is on Tidelift. We're here to talk to for us because he's an awesome maintainer. And we have complete editorial control. I want to make that super clear for our listeners that this is not like a Tidelift pay-to-play kind of a show. It's just in sponsorship with them, in partnership with them. And we can say what we like.

Feroz, you can say whatever you like. So having said all that, you have these different things you're trying, you're an experimenter, you're a tinkerer. I'm curious if GitHub sponsors is a game changer for you. If you think it will be, maybe not yet. Curious how Tidelift's going. You mentioned how Patreon's kind of going. Where does your sustainability stand and what do you think the future looks like?

Yeah, so I think that obviously getting money, you know, getting money from companies, I think has to be the strategy that we adopt going forward. And so one route is contacting companies directly. And that's what I've sort of tried. It sort of works if you are persistent, and you're willing to, you know, email a lot of people and explain to them the benefits of getting their logo on your on your open source projects page. You can sort of end up getting, I don't know, a few thousand dollars a month if you really work hard at it. Obviously, the downside to that is now you're spending a bunch of time emailing people and having meetings about sponsorship issues instead of coding. And I think a lot of maintainers just

don't want to do that. So I think that's where the promise of something like Tidelift comes in. The idea there is instead of maintainers having to interface with all these companies and try to explain to them why they should be caring about their dependencies and the shape that those dependencies are in, Tidelift can just go out and do that. And they have a sales team of people who are just basically going out and talking to companies and trying to convince them to pay for open source. And then they turn around and they give like half of the money that they collect from those companies straight to the maintainers. I think

they've promised that they're going to always give at least half of their profits indefinitely. That's a cool model because now suddenly I don't have to worry about emailing people and doing all this sort of salesy stuff, which I mean, I don't mind doing it because I like to push myself to learn new skills and to, you know, to go outside of my comfort zone. But I know a lot of maintainers like don't want to be spending their time like basically being a salesperson. So this is actually a promising model, I think. The way Tidelift does it is they look at sort of what their customers, their subscribers are using. And so they look at sort of what their customers, their subscribers are using. And so they look at what packages are their customers relying on. And then they say,

they have some kind of an algorithm that sort of just tries to calculate how much of the money that they've collected should go to the different dependencies. And then you just, as a maintainer, you just sort of sign up and collect that every month. And there's really very little you have to do in return at the moment for you just sort of collect it. So I'm right now making like about $500 a month from that, from Tidelift. So it's great, but you know, like all these things are all just, like the thing that's not ideal about all these different approaches is just that, you know, if I were to go just get a job at Google or something, I mean, I can make way more money, right? This isn't about money.

I mean, this is not really about trying to get rich, but it's just about, you know, if we want open source to be... How weird is it that open source creates all this value for people, right? And the people who actually get to capture all this value are like the startups that are built on top of the open source and not the people who actually make the open source. Just like think about how, I mean... if you assume the value is monetary value right because you just said it's not about money and in that case you're saying the value and so the

the value in the case of a startup is generally revenue you know in the case of say an instagram with billions for example built on open source so in that case if your value prop is simply revenue then then yeah that's true. I agree. I mean, yeah, I don't want to sound ungrateful about all the things open source has given me. I really do think that it's been amazing. I mean, I have so many friends everywhere around the world and it's been really great for just me as a person, such a better programmer. There's definitely an imbalance. Sorry to cut you off, but I just want to speak to your point about the people building profitable or sometimes failing companies on top of open source.

There's definitely an imbalance that we see, and I think we all see it, especially from the inside. Especially with all of our friends are burning out or struggling and making these things that huge corporations benefit from and not seeing any kickback. And so I see the imbalance. There's also a side of it like, well, you know, we're open sourcing our code. We're giving it away. It's a gift to the world.

I totally buy that. I want to give a gift to the world. That's why I got involved. I love the idea of giving away my code and just letting anybody do what they want with it. That's why it's like, I wouldn't call it a gray area. It's just like there's conflicting,

I have conflicting feelings about it because I built a career around this stuff. I've gotten tremendous value out of it. If I was to weigh in the balances, like how much I put in versus how much I've gotten out of open source, I've gotten

out a lot more, just individually. And I think most of us can say that. You're speaking for yourself, right? I am speaking for myself, Jared. And I'm not a big business who's reaping in the profits. By the way, I would also agree with, sorry to cut you off, but I just want to say

I totally agree with that too. Even though I put in all this time, I think I still have gotten more from open source than I've given. That's what's tricky about it. We all agree that these companies who are, I think they're also getting, I mean, okay,

I've gotten out more than I put in, but I'll just go on a limb and say Instagram Inc. or whatever that entity is, got out way more than it put in. Especially if we're speaking in terms of monetary value. Yeah, orders of magnitude. And so that's where we stand. And I think it is the community's job

to rally around this issue. I think what we're doing and find solutions. And that's why it's interesting to hear what's working for you. Because as a single maintainer who does have some celebrity and audience, if it's not working for us, then if anybody who has the kind of, the the kind of, you know, the person who's

running that transitive dependency that nobody even knows about and has a small following, it's really not working for that guy or that gal. Totally agree. Yeah. Totally. Yeah. That's the thing. That's the thing I always think about is like, I'm fortunate to have like some people who,

you know, follow me and I can talk to them about, you know, this issue. And, you know, if you, if you issue. And so if you look at the people who are making the most from open source and who are able to sustain themselves the best right now, it's not me for sure. But you can look at people like Evan Yu, who I think last I checked was making 16K per month on Patreon. I don't know if that's all for him

or if that goes to other contributors as well. But there's a couple of other examples of maybe... Cinderasaurus, I think, is also doing all right. And he also lives in Thailand, which is one of the ways he keeps his costs low. But there's really not that many examples. You'd think that the very most well-known maintainers would be doing quite well. And then you could hope that people who are less good at marketing themselves or just don't want to spam people on Twitter as much as I do, those people would also be able to make a living doing this.

But it's just not that. It's not the case. So it's absolutely right that like, yeah, some of the things that would make it easier for me to do this than other people, you know, you can actually point to all these advantages I have, and even and it's not even working for me. So that just tells you that, you know, it's not going to be a thing that most people can do full time, unless they're just lucky enough to get a job that just, you know, pays them to do to do open source, because I have these number of followers. And I have, I fortunately work on projects which are user-facing. So standard JS and WebTorrent are things that users actually intentionally install. There's all these other maintainers who do amazing work that powers all this stuff,

and they aren't making projects that people usually directly install. But oftentimes, they're doing as much work or more work than the sort of the user-facing stuff. So, I mean, those people are just, you know, they have a lot harder of a time raising funds because no one even knows that they're depending on this stuff. And the really, really paradoxical and unfair thing is that the better job that they do as a maintainer, the less that people are going to know that they exist, right? Because the better they do their job, the more invisible their software is. Like their software will cause no exceptions, it will cause no errors. So then no one will even bother to know that that's in their dependency

tree. Versus if they actually did a bad job and they were, you know, all kinds of issues being caused by their package, then people would go there and, you know, they'd go to their GitHub page and they would file issues and they would complain. And they would at least get to see this readme where the person could say, hey, by the way, I'm raising money for open source. It's really hard for those types of projects to get sustained. I have a draft blog post about these people and I'm comparing them to the offensive line in a football team. I don't know if either of you are football fans, but the offensive line is the most thankless job in football. All you do is you protect the quarterback or the running back, whoever it happens to be.

And when you're doing your job great, nobody notices that you're even there. And then the only time the camera comes on you is when you miss your block and the quarterback gets time the camera comes on you is when you miss your you miss your block and the quarterback gets sacked and then everyone looks at you like you dope what are you doing and so there's just a thankless thing that only gets focused on when something goes wrong and that's what these maintainers are they're just like that it's it's a shame you know it's up to you know that's why the quarterback's always thanking the offensive

line when the when he's getting interviewed after the after the game's over because they're the ones that that made it possible but they don't get any of the glory they just get all the shame it's really unfortunate but it's just there's multiple positions in the game and they play offensive line you know yeah yeah and i mean sometimes these people didn't even ask to be to be maintainers yeah they didn't even try out. They're just like all of a sudden, hey, you're on the line, get out there. They just made a project and put it out there and then suddenly they find that all these companies are basing their businesses on their code. And then they suddenly feel like, oh my god, I have to show up and take care of this because people's builds will break.

What if I miss my block and the internet goes down? Before we round off this portion of the conversation, can you speak to the success of GitHub sponsors? For you at least? Yeah, I just signed up for it. So far I haven't really told anybody that I'm on there. So I can't really speak to it. I know some people are having quite good success with it. Is it just Standard using the GitHub sponsors button?

Or is it others? Just that one project? I think it's just, I just put it on standard for now. Because they've got the sponsor button up in there. So they're telling people for you, even if you're not. Yeah. So one thing I like about GitHub sponsors is that it puts it right there on the page. So it's built and it's built directly into GitHub.

So in theory, it should be a lot easier for people to contribute. If they are already, especially if they already have their credit card added to GitHub versus going over to Patreon. But yeah, and the other good thing too is that GitHub is matching the sponsorships for the first year. So that's pretty good. Sweet.

Yeah, but we'll see. I mean, I still think I want to, I'm really curious about other models where there's more of an exchange of value instead of like this donation model um but i mean in general we need to try more things just as a community so i'm just glad that there's experimentation and that there are people talking about this right i just yeah i just think we need to try more stuff and see where it goes so because jerry put out that awesome

disclaimer about our relationship with tidelift in this show i can share my free opinion without any concerns and that's why i think i personally like the tidelift model because of that value exchange uh charity doesn't scale very well it's nice it does have its benefits but when we talk about sustainability on the long term, when you exchange value with a company, in this case, if we're looking at the idea of companies being able to use open source and potentially in the Instagram models or others, extract a massive amount of monetary value from it, how can we direct more of that value back to those who create and maintain

and support the open source we rely upon? If that's the idea, then you've got someone like Tidelift or others who may come up that say, hey, company, if you use for us as project standard, and it's in your dependency tree, if we can give you assurances, would you pay us so we can pay them? That's why i like that model because there's this value exchange between the two that when vi exchanges hands money often flows and so that's a good model for me charity is great it works in the case of open source software i think it has its limits i think this is a more viable long-term option to look to lean upon yeah i'll i'll want to quote Dominic Tarr here.

He's the guy who maintained EventStream. That was the package that was in the news a little while ago. I think we talked about it on JS Party. The one where somebody came along and said, hey, you haven't been maintaining this. I'll take care of it for you. And then Dominic gave the package over to this person who was a complete stranger.

And that person ended up putting a backdoor into the package to steal Bitcoin. And one of the things that happened after that, in the aftermath of that, was he wrote this little post where he talked about what it's like to be a maintainer. And he said, if it's not fun anymore, you get literally nothing from maintaining a popular package. And then he gave this really funny anecdote about how he used to be a dishwasher in a restaurant and he did his job a little bit too well. So they promoted him to cook and they only gave him 50 cents an hour more for that. But it was like massively more responsibility. And he didn't feel like it was worth it. So I think he asked to be put back as a dishwasher. But he said that writing a popular

module is like that, but times a million. And the pay increase that you get is zero. So it's like you just get infinite responsibility, no pay increase. And so if you're not using the package anymore, then he feels like what's the point so that's something that i think maybe tidelift or something along these lines can change because instead of popular packages being something that is a sort of like a drain on a drain on you you know especially if you know if it's not fun anymore if you're not using it anymore like what if instead it was a like an asset you know something like you know it's like if oh well you know what if I take care of this package,

Tyler's going to pay me however much per month or some other kind of model. Just imagine how different open source would be if that was the case. I think it'd be so different. Now suddenly somebody who normally wouldn't be able to participate in open source because they need to get a job

or they don't have the free time, they could adopt a package, especially one that nobody wants to take care of, you know, that someone's trying to literally give away to the first person who asks. They could adopt a package like that and even get paid to work on it. That would be so cool. I really think that open source would just be in much better shape. People would be, you know, people would say, you know, I want to take, I want to maintain more packages because I'm going to make more money. So like, I want to, you know, that would just be such a different world

than what we live in today. One thing, one lesson I've learned, you didn't say this word for word, but one thing I've learned this year or something that's been on my forefront of like what am I optimizing for is how can I turn my liabilities into assets? And I think that's kind of what you're talking about there

is like how can you turn what is often a liability or what might be a liability to somebody into an asset and that's what models like Tidelift do is enable that. One tool I'd like to mention which is cool and speaks to this and to the experimentation comes from Open Collective. They have a website

backyourstack.com so we were talking about the problem with transitive dependencies and not knowing who your offensive linemen are. This is a place where you can just put your GitHub organization in and it'll analyze all your code and dig through it. I think it supports JS, PHP, Go, Ruby, and.NET at the time. Right now, but it's open source. You can add other ecosystems.

And it will just analyze your software and show you all the different things that you're depending on. Probably similar to the way Thanks works, but it's a nice easy website that you can send to somebody who's not a command line junkie and show them, like, these are software projects in need and we could support them via,

I think it's obviously for them it's via Open Collective, but whatever ways. So that's something worth checking out if the listeners haven't heard of backyourstack.com. Cool. For us, let's close with maybe some hope, I suppose, for maintainers out there. You seem to have either thick skin, the tenacity, or all the above to keep doing what you're doing. So what have you done to sort of make being a maintainer a little easier day to day? What are some tips and tricks you can kind of share on our way out of this conversation? I guess I should say that I think I could do a

better job of all those things. You know, what I mean is, you know, I did get burned out a little bit in 2018. So I think think knowing when to take a step back and rest is really important. And also, there's this weird feeling of guilt you sometimes get as a maintainer about like, I owe all these people stuff because they're relying on my code. And that's really not healthy.

I think I've heard a lot of other maintainers talk about this, this weird sort of sense of obligation that you have toward the users of your projects. Yeah, I don't think it's helpful. I think that's sort of been the most, the thing that's been the least helpful to me as a maintainer. So I don't know, finding ways to not feel that sense of guilt and just remembering that, you know, that open source is a gift to the world. It's a, you know, it's like me saying, here's some code I wrote, and I'm going to put it out there. And, you know, you're free to use it to solve your problems and to help you. And, you know, but I'm not necessarily promising that I'm going to hold your hand forever with this code,

and I'm going to fix every problem that might arise for the, you know, for the indefinite future. And, you know, that's not part of the promise. And just remembering the, you know, for the indefinite future. And, you know, that's not, that's not part of the promise. And just remembering that, you know, and just, just contributing when I, when I can, when I feel like I can, you know, and just remembering that it's a marathon, not a sprint. Well, we appreciate your willingness to experiment, your willingness to share your ideas. You said earlier that I want to give my code away as a gift to the world.

And we certainly appreciate that as well. And we appreciate, you know, all the ways possible to enable open source software maintainers to live the lifestyle of a maintainer, which is whether it's a network of value or if it's financial value, whatever the value it is that you're seeking. I, you know, we here at Change Lab want to enable stories like this to be shared and the opportunity to do the things we love. Because you said that, you quoted Dominic, if it's not fun anymore, what's the point, right? So. Yeah. And I don't want to leave people with the impression that being a maintainer is not, you know, not a good idea. I think that's

really, that's not, that's not the message, even though we have been focusing a little bit on the sort of maybe the darker side that isn't told as often. Um, I, I really do feel like being a maintainer has been one of the best things in my life. Um, and I mean, I have friends all over the world now from, from going to conferences and such'm such a better programmer. It's been incredible. I also think that the financial model thing is probably going to figure it out soon. It might not even be a bad time to start if you're thinking about spending more time doing open source.

Maybe we'll figure this out soon. This won't be a thing where you have to choose between doing what you love and putting food on the table. Well, Frost, thank you so much for your time today. It was awesome. Yeah, of course. Totally happy to be here.

Thanks for having me. All right. Thank you for tuning into this episode of The Change Law. Guess what? We have comments on every single podcast episode. Head to changeog.com, find this episode, and you can discuss it

with the community. Huge thanks to Tidelift for their support of our Maintainer Spotlight series. And of course, thanks to Fastly, Rollbar, and Leno for making everything

we do possible. Our music is produced by the one and only Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our Master Feed at changelog.com

slash master, or go into your podcast app and search for changelog master. You'll find it. Subscribe, get all of our shows as well as some extras. Only hit the master feed. It's one feed to rule them all. Again, changelog.com slash master. Thanks for tuning in. We'll see you next week. Bye.