Sustaining Open Source Software

Welcome back, everyone. This is the ChangeLog. I'm your host, Adam Stachowiak. This is episode 159.

And on today's show, we're talking to Mike Parham, the maker of Sidekick, Sidekick Pro, and Spectre, and Inspector Pro. And this is episode 159. And on today's show, we're talking to Mike Parham, the maker of Sidekick, Sidekick Pro, Inspector, and Inspector Pro. And this is more of a conversation show than we might normally have.

Jared, myself, Mike, all talking about sustaining open source. We teed off the subject a little bit here and there, but for the most part, we were focused on what it takes to sustain open source, avoid burnout, and hopefully you'll love this show. We have three awesome sponsors, CodeShip, Toptal, and DreamHost. Our first sponsor is CodeShip, they're a hosted continuous delivery service focused on speed, security, and customizability.

You can set up continuous integration in a matter of seconds and automatically deploy your code when your tests have passed. CodeShip supports your GitHub and your Bitbucket projects, and you can get started today with CodeShip's free plan. Should you decide to go with a premium plan, you can save 20% off any plan you choose for three months by using our code, the change log podcast. Again, that code is the change log podcast.

That gets you access to a 20% off discount on any plan you choose for three months. Head to codechip.com slash the change log to get started. Tell them we sent you. And now onto the show.

All right, everybody, we're back. We've got a great show lined up today. We've got Mike Parham here today. Jared Santo, of course.

Jared, what's up, man? I'm here. I'm excited. I'm ready to do this.

You don't sound excited. You got to sound excited. I'm here. I'm excited.

I'm ready to do this. Mike, you excited? I am pumped, guys. This is the best part of my day right now.

Right. Awesome. Awesome. And it's Friday.

You know, it's TGI. It's the best day ever. The best day ever. So the conversation today, this is, so for the listener's sake, this is a lot more of a roundtable than I think some of our other shows might be.

A pretty near and dear topic to any of our hearts here. Sustaining open source, not just sustaining open source, but just sustainable lifestyles, sustaining anything, the changelog, open source projects, a business. And some recent events brought this to Mike's attention. Mike tweeted out that he wanted to talk and we said, hey, let's talk.

And here we are. So what do you think, Mike? That's a very accurate summary. So sustainable open source, what is it that prompted you to tweet what you tweeted?

So I tweeted what I tweeted because Steve Klapnik recently sort of rage quit Twitter. And this made me profoundly sad. I mean, I've met Steve before, a really nice guy, really smart guy. And he's one of the good guys in open source that is not only incredibly productive, but he is, I think, a good role model for other people who are looking to get into open source.

And so for him to sort of quit open source in frustration really worried me. And I think it, I'm assuming that he, yeah, I can't really speak to why he quit per se, but I know that open source has a serious problem with sustainability in people working on open source projects for months or years and then giving up on them because they simply don't want to put any more time into it because it's so frustrating. And so I wanted to have that discussion about things that you can do to minimize that frustration and things that you can do to ensure that not only are you treated with the most respect, but your users are treated with respect and everybody tries to be as respectful to each other as possible. Well, I also say, let's maybe as a group, try to reflect back on those we can remember or moments we can remember where burnout happened.

Besides Steve, this is the most recent one, but you got things like, I'm not sure if Y ever left Ruby because of burnout or not. I think it's sort of up in the air if, if you, it's an opinion, maybe not so much a fact, unless anybody has proof and he said so behind the scenes. Lee Hambley with Capistrano. We had a conversation on that.

Just recently, just yesterday, we released a show or recently released a show with, I had a conversation with the CEO of Joyent, Scott Hammond, and we talked about Ryan Dahl having issues with burnout and then stepping away from Node back in the day. And that sort of helped begin some long-term fracturing, not so much, you know, he himself, but just his departure and, you know, removing himself as the BFL. And then, you know, what examples can you guys come up with? The one that I can think of offhand was James Tucker, who is also known as Roggi.

He used to maintain Rack and he sort of, he joined Google, I think a year or two ago and he's sort of minimized his open source work over the last two years because he's been so frustrated and, and feels like he's just putting in a lot of work for maintenance and, you know, and drudgery without any sort of reward or recognition. So I don't know that he's like tweeted out enraged things, but I know he has in the past. I don't necessarily have someone else to add to this one. One fine point I wanted to make about Steve's recent departure.

As many listeners know, Steve's kind of been involved in the changelog over the years. And so he is in our Slack room and he did want to make a point. He asked us to say this, if we're gonna talk about it, is that he says, he had a follow-up tweet where he says, I feel the need to say that this has been a few years coming. If you're just reading my timeline, you probably don't get it.

And then he said to us, this is me needing to chill out after years of stuff is not any particular thing. So yeah, just wanted to throw that in there. When you go to, when you get the pedal to the metal and your car goes 120 and you're going 120, I love analogies. Yeah.

You don't, you don't burn out overnight, right? You burn out day after day, after day for months and years. Your, your sort of frustration level grows every single day. There's the burnout doesn't happen overnight.

So maybe we can talk about some things that attribute to it. So there's a couple of factors. You got one self-inflicting things that you can do, right? The ways you live your life, the choices you make.

And then there's the other side, which is the way the world perceives what you work on, whether it's in recognition or adoration or put downs or requiring too much from you and treating like a God and expecting more from you than you can actually, you know, put out sustainably for long periods of time. So maybe let's start with the, the ones you do self-inflicting. What, what are some examples I think of that you can think of that are self self-inflicting towards moving you towards burnout? Well, the easiest, the easiest thing to do is just overwhelm yourself with work is to just keep saying yes to, to new features.

Yes to the growth of your own projects that you may be working on. If you want to build, start building your own language and interpreter that might be a fun weekend project. But if people start using it, if you want to start using it at your work, maybe for some, you know, custom business purpose. Now, all of a sudden you've got users, you've got something to maintain.

People start adding, asking for more features. Now that we can project has gone from something that you can throw away to something that other people start to depend on. And that brings up a question of how long, how are you going to support this thing? And sometimes that those responsibilities can, can even surprise and overwhelm somebody who never expected their little project to go so far.

And all of a sudden now you have all these users at first, it's fun. Somebody is paying attention to something you built. Of course, that joy of having something you made being used in the real world. We've all probably felt that and it feels pretty good.

And you start to have a certain sense of responsibility that you probably weren't prepared for. And how you react in that moment, like you said, it is over time, but how you react to those types of pressures, I think can lead you one way or the other. Right. People start seeing you as an expert in that space, whatever that space might be.

And you don't want to lose that respect. And so by telling people, no, you might be worried that you're going to start losing that respect. And so a lot of people tend to just start saying yes to everything. They don't want to turn down PRs.

They, they want to answer every support question as fast as possible. Um, yeah, it's a, it's a tough, it's a tough one. Once you have that ball rolling, it's going to roll on its own. That inertia is going to keep going on its own.

And it's hard to, to stop that. As a, as a, I guess an experiment in preparation for this call, I went on hacker news and search for burnout. Just the word burnout. Not a ton of results, but enough to, you know, alarm anybody.

331 results. I don't know if somebody's go back a couple of years and then I went to the next place. Somebody might rant about burnout It could be thinking like I was trying to like say I was trying to like say I was cool, but I wasn't. I meant that I was trustworthy, that anything you want to find out about me is on Google.

So I said, I'm highly Googleable. You go on Google, you can find out pretty much the kind of person I am by the links that link back to what the internet says I am. You know, so you can realize that I'm not this jerk. Right.

Anyways, sidetrack. Now I'll just say one more point around the celebrity thing and then we can put this to bed and talk about sustainability. I think Mike has some good ideas around it. But internet celebrity is different, right?

And I think it's better in terms of overall celebrity. Of course, you're not on the network news or actually usually on the network news, you're in trouble. You're not on Entertainment Tonight and whatnot. But those celebrities, they can't escape it.

Like you can't, like when you reach a certain level of people knowing you and you're not knowing them, there's no privacy for you anymore. You can't actually get away from it. And internet famous, you can always just, you're always normal in the real world. Like, you know, unless you're at RailsConf, right?

Like when you go to your local Apple Store or Target, people aren't saying, Hey, it's Mike Barrow, you psychopath. Psychic, get him. So it's nice in the sense of, you know, RailsConf perhaps it'll be even more enjoyable for you because you meet people who enjoy your work. That can become overwhelming.

And then what we do in response to that, because we can, is we just leave the internet because that's where the pressure is, right? And it's a nice, it's actually grace for us that we can, we can just leave the internet and we're okay. But that being said, you leave all of us behind who adore the work that you do on the internet. And so it ends up being a loss for the community, but necessary for the person who is leaving.

Very true. But to move to something Mike did, did you think about your thing, Mike? Uh, no, no. You couldn't get your point?

You want to do the sponsor real quick, Jared, and come back? Sure. What's the next topic? What do you want to bring up?

Well, uh, something Mike said earlier on the pre-call, which I think we should talk about is goals. Right. And I think that's a major linchpin for um gauging success and failure and you know, whether or not you can sustain something. Good deal.

Alright, let's, let's take a break. We'll come back and talk about what Jared just said and uh we'll be right back. You've heard me talk about TopTile several times on this podcast, but today is different. I've got a special treat for you.

I went out and spoke with a listener who, a year ago, had never heard of TopTile. He listened to the show, just like you're doing right here, right now today and heard us talk about TopTile and what they're all about. And he decided to get in touch. And now he's living the dream as a freelance software developer with TopTile.

His name is Daniel Elazon and I sat down and I talked with him. I said, Hey, what is it that you love most about TopTile? Take a listen. Well, for me, the thing about TopTile, which I thought would be very hard for me personally as I transitioned to a more consulting role, uh, was the way I would have access to new clients and what quality of those clients would be.

So I found that I've had access to awesome clients through TopTile and it hasn't been that hard to find because they have a lot of choice. And even more than that, uh, there's enough choice. And I, I can actually be a little selective about what kinds of things I want to be working on. So I use that as a way to sort of hone my skills and, you know, go towards the technology that I think are worth investing in for the future.

So whether it's, you know, including you front-end frameworks or doing a little DevOps work on the side, I usually am able to find clients who are, have the needs of the things I want to get better at. So that's been, that's been truly useful. All right. That was Daniel Elazon, a listener of the ChangeLog and also a freelance software developer with TopTile.

If you want to follow in Daniel's footsteps, go to toptile.com slash developers. That's T-O-P-T-A-L.com slash developers to learn more about what TopTile's all about and tell them the ChangeLog sent you. All right, we're back. We're talking about how can you sustain open source projects?

We're here with Mike. Mike has a few ideas. And one of those is around goals. Can you speak to that, Mike?

Sure. I think a lot of burnout comes from the fact that you as a developer or as an engineer, just don't see the light at the end of the tunnel for your project. You don't necessarily see where you're going and when you're going to achieve that goal. And so setting some realistic goals for your project, like what you want to happen based on all the input and all the work that you're doing on the project can really help because you're not, you don't see it as an endless time suck anymore.

You see it as the work that you need to do to get to some point at the end of the, you see the light at the end of the tunnel. So a lot of people, when they create an open source project, they just say, I want to create this thing and then I want people to use it. But the problem with that is that that becomes an endless time sink where people may be using this thing for the next, for five years from now. Are you going to be around five years from now to support it?

And if you acknowledge that, yes, I'm going to be around five years from now, that's fine. That actually helps your mental attitude so that you understand that I'm going to do what I need to do to reach that goal of supporting it five years from now. But if you don't have those goals in mind, you can, you can easily be overwhelmed psychologically and just all that you have to do and it just keeps piling up and you're not really seeing any, any positive outcome for all the input that you're putting into the project. So the thing I think is what you get by doing that is something Matt Vasquez taught me when I was started working at PureJd with Matt, um, Jared, do you know Matt?

Any of you guys know Matt by any chance? I don't think so. Um, super smart guy. Um, I think he's, it's called scrimmage is the app he's making.

Get scrimmage, I believe is the URL. If it's not scrimmage, it might lead you to his actual project. But he worked with me at PureJd, lead dev, uh, turned CTO. I think at some point, I'm not sure if it was actually CTO or not.

But nonetheless, he was the person in charge of the development team. But I learned so much from Matt about setting expectations. I used to get angry at people for not, for not delivering what I thought they should deliver. And he would say, well, did you set some goals for them?

Right? So what you just said, like setting goals for yourself or for other people, it, it sets expectations. If I do this, I can expect, you know, to come close to this result or not. But that's what I'm expecting to do.

And because you set the expectation clearly enough, it's easy to have a waypoint or, you know, like a positive or negative emotional response to where you're actually trying to go. And for me, that was everything. It was like setting expectations for me and for others has been huge. So anytime I feel angry at somebody, I'm like, internally, before I get mad at them and, and say lash back, which I never lash back at anybody, but let's, you know, my own version of lashing back.

I asked myself, did you set expectations well enough for them? If not, you're wrong. Right. So how, how explicitly do you set expectations then?

I mean, you like make a list or you? Well, I mean, you know, use your own judgment, but like, for example, I'll use this example, and not because it's a real issue whatsoever, but only because it's the most relevant issue or the most relevant point I can make. Today, we release the show every Friday. We release the show, right?

Now, if, if, if it had gotten to, you know, end of Thursday night and into Friday morning, and Aaron hadn't finished the file or finished the edit, then, right, then, then I would say to myself, well, It's in Aaron's court. He's the last person to touch the next step for this project to go out. And I would say to myself, if it isn't completed or done, did I tell him what needed to be done? Is it clear what his next step should be?

And if that were the case, then I have reason to say, well, he's got an issue. But if the ball's in my court and I didn't set expectations clearly enough, then it's my fault. Right. So that's what I mean by that.

So like, if, if it's clear that what the next step should be and they have onus of it, then, then that to me is clear enough expectations. But Aaron, you're awesome, dude. You're just a good example to share. And I'm just saying that.

That's all. It's a good example. We shipped, we shipped the first thing this morning. Yeah, it was And they're super frustrated.

But you're right, there is a sense of entitlement to insulting somebody like that. But again, it's faceless communication. We're not talking to each other face-to-face. So it's so easy to get a flame war started.

Oh, yeah. I mean, text is, I'll just now I say, it's okay, I'll say it. It's impossible to understand whether or not you're trying to be nice or try to be mean or even malicious because you can't see body language, you can't see, you can't hear tone in the voice. All the things we use as waypoints to determine whether or not Mike's trying to be a jerk to me are gone when it's in text.

The only thing that sort of adds a back lately is an emoji. But the other day I got a thumbs up after something and I was like, is that like shutting it up, Mike? Or is it like, is it like really a thumbs up, man? Like, and I had to like back away from it.

And it was a little thing. I should have. Like a sarcastic smiley face or a legitimate smiley face. Or is that a sarcastic smiley face?

And I share my negative concern with my wife. And she's like, Adam, chill out. It's not that big of a deal. Yeah, that's the way to burn out, man.

You got to think, you got to think the best of people, right? If it's unclear which one it is, just assume the best of people. Yes. And one thing we don't think about is, sorry, one thing we don't think about oftentimes when we're on the receiving end of a flame, right, is what's going on in that other person's life.

Like what brought them to that point? To where they say something that's incredibly offensive to me or attacking me. And, you know, we don't know about that pressure they have at work or their spouse who's in the hospital, right, or that bill that's, you know, three months late. Whatever it is that's like bringing them to a point of lashing out.

You know, we, we assume that they're just a jerk, right? Right. And maybe legitimately so in certain cases, but we tend to give ourselves the benefit of the doubt and nobody else. And on both sides of that in the internet, it's just bad news.

That is absolutely right. I always think of it like, I don't know when it changed for me, but I can remember clearly that something in me changed that whenever I would go to, let's say a convenience store to get gas, and it's before the days where you can pay at the pump, all right, so this is back in the day, you know, and I go into the convenience store and I go to pay and I need to get some gum and I get a Snickers. I love Snickers. Who doesn't love Snickers?

Sorry. Well, it sounds nice. That's right. Right.

This is not an advertisement. This is not an advertisement for Snickers, but I love Snickers. That's a free ad. Snickers, if you'd like to sponsor the show, we will definitely consider.

Folks, please pause the podcast right now and go buy Snickers. That's right. That's right. Get yourself a Snickers.

And when you buy the Snickers, be nice, be nice to the person behind the counter. You know, you never have any idea. Like, I always like to say hello to the person. They wear their name tag for a reason.

If their name is Ben and it says Ben on their name tag, hey, Ben, how are you? Be polite to people. And I always think of it like the point I'm trying to make here is that, you know, I don't know that person. They don't know me, but I get, you know, 30 seconds of their life and they're working and they got to deal with the public.

Say polite things like, hello, how are you? Good to see you. You know, whatever it is, because you never know that person may be dealing with what Jerry was just saying, like maybe a bad bill or, you know, their boss is going to fire them. This is their last shift.

Who knows? And you may not be the reason they do it, but you may help enforce the negative attitude to go home and kill their way for their, you know, or do something crazy that just shouldn't be done because you could have controlled yourself better or been a more polite social human being and just said hello and use their real name. Not just like sticky gum, Snickers. Here's my card.

Bye. You know, be a little generous with, with your love and give some love to people. And you just got to try extra hard on the internet because like you said, we don't have those other forms of communication that you have in real life, right? So with the eyes and the body language.

And so we have to be extra, we have to take special care with how we craft our sentences. And like Mike said, you know, take that, that one you put together. Sometimes I'll just stop and reread a few times and say, how could this possibly be misconstrued? Right.

Like, could this, which is either a joke or just constructive criticism or feedback, which is something that is valuable. How could this be taken wrongly? And I try to try your best to improve your communications. There's a lot of really heated debates though on the internet too.

And those get going real fast. Like I don't want to bring up any particular topic, but some that have been there lately in the news has been inclusivity, gender bias, feminism, where men aren't treating women well, a lot of these issues. And they escalate so quickly because there's some inherent pain and inherent hurt from previous engagements around the scenario, around the topic. And somebody might indirectly take all the pressure and all the pain that someone's built up, not saying it's wrong or right.

I'm not saying that they're not deserving of that feeling, but sometimes we also get, you know, just like I just lay it all on Mike. Hey, Mike, you're taking it all, you know, because you're here today. Right. And that's not right either.

That's interesting you talk about the flame wars that come in. People are so passionate about certain topics and it's because they identify one way or the other. They identify themselves with I'm this or I'm that. Right.

It's a tribal response. It is. And in software, we identify with our code. And I know there's even been conversations back and forth about whether or not you are your code and these types of things.

One kind of shining anti-example to burnout is a recent guest, Daniel Stenberg. Yes, that's true. The show we did on 17 years of curl, which everybody enjoyed. I actually went back and re-listened to that show and he's just a very interesting person.

He said some things like, I enjoy working on curl now more than I did when I started. And, you know, he's been doing it at least two hours a day roughly for 17 years. So I started thinking like, why? How did Daniel make it so far?

And one of the things he said is he said, this is my life's hobby. Like curl is me. And he identifies like curl is like his life's hobby. And so he has a level of dedication and identity wrapped up in that project that I think, you know, you can say maybe is or is not healthy at certain times, but has allowed him to sustain through all the pressure and all the times where he doesn't want to be coding and what have you.

And I think that's just an interesting data point. What do you guys think about that? I like the fact that he calls it his hobby and not his life's work. That is a sort of an implicit sort of end goal that he's setting there, which is that I'm not going to support myself through this.

It is a hobby. I'm going to treat it as such, which, you know, sort of implies a level of support and a level of activity that can fit into an hour or two a day and not eight hours a day. One of the things he did too, just indirectly, or not explicitly, is focused. He doesn't have curl plus 10 other things.

He's known for curl. And I guess subsequently loop curl, but it's sort of the same camp, you know. So he's got a level of focus too where he hasn't spread himself too thin. And maybe that's some self-identification of like where his strengths and weaknesses are.

Maybe he's not okay with multitasking and working on 10 things at once. Maybe he's okay with full-time employment that's enjoyable and his lifetime hobby. And so something I learned from doing Founders Thought for years, but like if anybody asks me, hey, Adam, you interviewed all these founders of these companies that, you know, do great things. What's like some things you took away?

The number one thing I took away was focus. Every one of them focused on their goals. They set some goals and they focused. They didn't do 10 things at once.

They didn't do 15 things at once. They set some goals and expectations and ran towards those expectations. And as they got closer and closer to them, self-analyzed, am I closer or further away? What's bringing me closer or further away?

And took the necessary steps to correct their course towards their goals and focused. And I think Daniel probably has done that based on 17 years of curl. It's crazy. Yeah.

Mike, interesting to hear maybe your thoughts on that in light of Inspector and the fact that, you know, you had Sidekick. And it's not just your life's hobby, right? This is actually how you make a living. You had Sidekick.

You added Inspector, I think it was maybe six or eight months ago. Has that changed your focus? Have you been Just sort of randomly build an open source version of it. Just pay Mike to build it and support it.

I mean, right? It really is that simple. It really is that simple. I like the way Mike.

That's good. But remember, with open source, people are terrible at estimating how long this is going to take them to build. And so I was talking with a guy just today, just this morning on Stack Overflow, who said, How do I know when my set of jobs are all done? And I said, well, that's Sidekick Pro's batches option.

And he was like, well, can I just implement some counters and Redis and just sort of build it myself? And I'm thinking, and I told him up front, I was like, you can absolutely do that. It will work 90% of the time. And the other 10% of the time, the other 5% of the time, you'll have no way of figuring out what's going wrong.

It will just, it'll be a time suck. And you know, if you're a business, you're trying to solve a business problem. Why are you building Sidekick Pro's batches feature again? Right, right.

That's the expectations back to that same thing we did. Like, Hey, you can do that. But if you just support me and support me through buying the Pro version, you can have a happy life, not the time suck. And there's the expectations.

So that's back to the sustainability of, that's how you make your money. So I'm sure you've got family, right, Mike? You've got wife, kids. Yep, wife and kid.

Right. So you've got things to take care of and you're doing work and you're being altruistic and putting things out in the open source world, but you're also putting a Pro version out there that says, Hey, here's a, I've thought of the feature. It's really complex. You don't want to deal with it.

And if you support me, you can get that here and support with it. I think that's historically a hard sell for developers because we build solutions, you know, at the level of my own. I know that stuff. But remember with open source, people are terrible at estimating how long this is going to take them to build.

And so I was talking with a guy just today, just this morning on Stack Overflow, who said, How do I know when my set of jobs are all done? And I said, well, that's Sidekick Pro's batches option. And he was like, well, can I just implement some counters and Redis and just sort of build it myself? And I'm thinking, and I told him up front, I was like, you can absolutely do that.

It will work 90% of the time. And the other 10% of the time, the other 5% of the time, you'll have no way of figuring out what's going wrong. It will just, it'll be a time suck. And, you know, if you're a business, you're trying to solve a business problem.

Why are you building Sidekick Pro's batches feature again? Right, right. That's again, expectations back to that same thing we did. Like, hey, you can do that.

But if you just support me and support me through buying the Pro version, you can have a happy life, not the time suck. And there's the expectations. So that's back to the sustainability of, that's how you make your money. So I'm sure you got family, right?

Mike, you got wife, kids. Yep, wife and kid. Right. So you got things to take care of and you're doing work and you're being altruistic and putting things out in the open source world, but you're also putting a Pro version out there that says, Hey, here's a, I've thought of the feature.

It's really complex. You don't want to deal with it. And if you support me, you can get that here and support with it. I think that's historically a hard sell for developers because we build solutions, you know, at the level of my own.

And it's like, well, yeah, I mean, that's just, it's in there, right? Like I think that I have to stop myself often. I love how as developers, I think we're becoming more business savvy just as an industry over time. And, and yet I still have to stop myself and say, why am I hand rolling this solution?

You know, which may take me 10 hours at this cost to my customer, what have you. When I know that the solution I saw it, it was 20 bucks a month, right? Or whatever it is. And yeah, I'm like, well, that's too much.

I'll just spend a thousand dollars building it. That's going to work 99% of the time. All I want is a folder of files on all my machines. How hard could that possibly be?

And yet you've got people paying Dropbox billions of dollars to provide that same functionality. You know, nerds will buy a network attached storage system. They'll set up an NFS mount. They'll do all this complex complexity.

They'll set up an IP back to their house so they can go away. Provide a folder with the files. But the reality is that 99% of businesses don't want to deal with that. So they will pay for the pro version.

So if somebody wants to build the batch or reliability or whatever the different pro features are, if someone wants to build that and release it themselves, they can totally do that. I don't care. You are free to write whatever code you want. The question though is, are you going to be around three years from now to support that code?

Are you going to support it as Sidekick changes over time? That's true. So, you know, businesses aren't just paying for a feature. They're also paying so that they can, they know that someone is going to be there to answer questions, to deal with migration.

Business is damn people though because businesses pay for things, but people pay for things with their choices, right? So when they choose to use Sidekick, they're choosing to, you know, follow you in a trusted way. You're not going to go anywhere and they can even trust you more because you do have a business model that is sustainable to the point where you can long-term support the open source version. I mean in terms of not so much, Hey, you've got a problem.

Here's how you fix it. But, you know, you're making sure that if things break or if there's something that goes wrong with it, you're there to fix the open source version of it and re-release it because you've got a sustainable model. Right. So to bring the conversation back to the topic at hand, which is burnout.

Yes. I knew that when I started Sidekick, that this was a big enough project and my aim was to make it successful enough to where if I didn't have some way of paying myself to support myself in doing the project, that I was going to burn out. There's no way I could support Sidekick as well as I do today without having it be sort of a job that is paying me money. And so that's how I dealt with burnout is I turned it into a job and now I'm happy to devote eight hours a day to supporting Sidekick because I know that it's my full-time job and it's supporting my life.

So that goes back to those setting expectations of, Hey, my goal here is to not just develop another open source project. It's also to develop a business and possibly a life around this work. So that's, I guess, where I deviated from what Daniel did with curl. He made it his life's hobby.

I want to make Sidekick my life's work. Hmm. I wonder if he could make curl some sort of pain model. I imagine, right?

Jared, because he said he's got Facebook and all these big companies using it. They've got to have features that, that they need to pay for. Think about that, Daniel, get back to us. I know he has had a lot of opportunities to work on it, which I'm very excited.

Like to add right now he's adding some stuff to HTTPS, some additional HTTP two support, like on a contract type of deal. So he has had opportunities where it has made some money, but because he's in his mind, it was still that hobby. It's not all of a sudden now he expects it to make money because if he did, you know, he made that be down at that $1 an hour rate or, you know, and he can make a lot more than that working full-time for Mozilla. For those of you who are interested in the full story on inspector and Sidekick checkout changelog.com slash 130, where Mike and us go deep into those topics.

Let's take a break and hear from a sponsor and we'll be back in a bit. Dreamhost now has managed VPS hosting built for speed and scalability, including solid state drives. And that's awesome. These VPSs are built for open source developers and now include one-click installs of Node.js, custom Ruby, and RVM support.

Speed, speed, and more speed is what it's all about. Their VPS servers use SSD hard drives and are 20% faster than traditional SATA drives. All virtual private servers from Dreamhost include SSD storage, Ubuntu 12.04 LTS, web-based control panel, scalable RAM, which is super awesome. You can go from one gig of RAM and easily scale up to eight gigs if you need it.

Node.js one-click install, Ruby version manager, unlimited bandwidth, unlimited hosted domains, unlimited 24-7 support. Go check them out and learn more at dreamhost.com slash the changelog. All right, we're back. That was a fun break.

The funniest. Yeah, that was the best break ever. That was the best break ever. That really was a good break.

And now we're here to talk about moderation. So we've talked about lots Sleep man, work 8, play 8, sleep 8. So moderation is not just your own habits or how much work you do, but it's also how you relate to others, because open source is sort of an infinite time suck. And if people are just constantly peppering you with requests and questions, you will find yourself spending all of your time dealing with that.

And so that's where part of moderation is being able to say no to people. It's being able to say, I don't have the time to implement that feature, or no, this PR is not something that I want to maintain because I have to consider the support costs of this change, and I don't want to support it for the next five years for the length of the project. And so there's a large number of reasons why you might say no to people. And you need to consider that as part of moderation.

You need to moderate your own time as part of a project. So we'll say this URL here on the air because Jared is so awesome, and he Googles well. Jared, you're good at that, right? Thank you.

That's what I do for a living. Some would say. Some would say. So it's gofundme.com slash Ian Hikes, I-A-N-H-I-K-E-S, Ian Hikes.

Right now his goal is $6,000. The amount raised is $725. We need to push that up. We need to push that up and make this dream come true.

I can't wait to have him on the show now. I'm excited. But jeez, man, what a goal to have. Moderation.

I like that conversation. Ian is not moderating his goals. No, he is leaning far into them. Hiking the trail behind my house, that's a moderate goal.

Hiking Kilimanjaro, that is not a moderate goal. No, that's extreme. Sometimes, though, and that's the thing too, right? Part of moderation comes wise choices.

Wisdom, I think, is probably the thing that sits beneath everything we've talked about today because you can have moderation. That doesn't mean always playing it safe. There's times to take risks. I'm sure you can attribute that, Mike, and you as well, Jared.

And there's times you go above and go to the extremes like climbing Mount Kilimanjaro. There's times you do that. And there's times when you moderate your life a little bit more and you do things that allow you to have more flexibility and more focus in certain areas. Goal setting, I think, is super, super important in all these things.

But the wisdom to know when to go to the extremes or hang out in goal land and keep doing what you're doing there. So any closing thoughts, Mike, Jared? Say no to drugs, kids. Of course, of course.

Say no to pull requests. Say no to pull requests, indeed. The world's most dangerous drug. Yes.

No, I mean, you know, I think moderation and learning to say no and being realistic with what you want to do and what you want to achieve is that part of that wisdom. It's part of the experience you get over being an open source developer for a number of years. You start to learn this stuff. I got something that I think you guys might like is sometimes we're our own worst enemies, right?

And you've got your buddies to your right and you've got your buddies to your left. I learned this in the army, right? You've got those people around you that you can trust. And if you're someone someone trusts, so in this example, let's say the three of us here, right?

I'm someone you guys trust. And if I think Jared is doing something that is abusing his moderation, abusing his goals, if I know his goals and I'm there as a support person in his life because I'm close enough to him, and I see him step out of line, help. I would say help people that either you look up to or you know and you're close enough and you can say this to them. Help them moderate their life.

Help them not go too crazy. Help them realize, you know, hey, you said you were going to focus on these goals and I see you doing this, this, and this. Not saying you're doing it wrong, but you might want to just double check back to your goal list. Are you actually going towards where you're trying to go?

Because sometimes I'm my worst enemy. And my wife, man, if I didn't have my wife out sometimes, I know for sure I'd be on the ground. You know, I just would not be who I am. Because she knows me so well.

She knows what my goals are. She knows who I'm trying to be. She knows what kind of man I'm trying to be. And, you know, if I didn't have her as a support system, if I didn't have her advice, I would make unwise choices all the time, every day.

Yeah. So maybe as a call to arms for people is to watch out for our fellow developers out there, our fellow friends out there, whether you, you know, how close you are to them is your choice. But help others not go towards burnout. Don't push them to burnout.

See, if I have a closing remark, it would be back to the point about a hobby versus a living. And the goal setting can be simplified down to, am I doing this as a hobby or am I doing this as a means of making a living? And I think determining that and holding strong to it, of course, you can switch at a certain point if you want to. But knowing what it is helps you moderate because a hobby has got to be fun.

It's got to be fun. It's got to be interesting and it can't consume your life. Now a job, sometimes you just got to do the job, right? Right.

It's work. And that's why we call it that. So I think that's a good way to judge, you know, this idea you have or this project you just started. And what you're getting yourself into is, how do I approach this?

Is it a hobby or is it a job? And I'm going to, you know, approach it appropriately for each one. That's a good way of thinking about it. I think from a technical engineer standpoint, what's fun to me is writing the code.

What's not, what's never fun is supporting users. Just because, you know, I don't have that problem. And so when they come to me and I'm solving their problem, that's work. I'm working for them to solve their problem.

And so you have to be very clear with open source, especially around support. How long are you going to support this thing? How much of an effort are you going to be supporting it? What channels are you going to support it through?

Otherwise, it'll just, it'll suck all the fun out of the project. For example, on Twitter, I saw you tweet just yesterday as I was kind of like coming back to your timeline to prepare to see if there's anything else you, any recent, you know, sustainability nuggets you've shared that we should pull into the conversation. And you were like, hey, I don't do support on Twitter. Go here.

Right. And you set it in a polite way, you know, you didn't say it as mean as I just said it, but, you know, you were, you know, you made it clear. You set expectations that support doesn't happen on Twitter. Don't ask for it.

It's a nightmare, right? 140 characters. Come on. That's not realistic.

That's no. Half of support is getting the user to define their problem. Oftentimes, when you force somebody to write out what the problem they're having is, they can solve it themselves. Yeah.

It's almost like rubber duck debugging, right? Yeah. But, you know, if someone asks you a question in 140 characters, I'm going to give you a 140-character answer, which is not going to be very useful. So, yeah, I try to make it clear to people.

And I don't, I don't, I'm not mean about it, but I just be matter of fact, I don't use Twitter for support. Twitter's here for, you know, retweeting stupid stuff and cat pictures and that sort of thing. Change all posts. Change all posts.

That's the stuff you got to retweet right there. Well, that was the stupid stuff. I'm just kidding. Well, cool.

Any other closing thoughts before we trail on though? This has been a, this has been a fun show for me to have a discussion. It's not often I even get thought as much, but it's been fun. I liked it.

Thank you for jumping on the subject and allowing me to come on. You know, actually, let me, let me open up Twitter real quick if there's another person we should thank here on the show, because they are the reason I even saw your tweet, which it was Marcello. And I don't know how you say the last name because you're from my favorite country, Brazil. But Marcello, I'm gonna say that.

And you're M-A-R-C-E-L-O-C-G on Twitter. Marcillog. Gonkalves. Marcello Gonkalves.

That's probably not right. Without the, without the proper accent, you can't say that name. So I don't sense it. And I'm already known to be a bad last name butcher.

I just, there's times I can't say my own last name. Just say his last name is UTF-8 compatible because that's, that's got some crazy. There you go. Yeah, he retweeted your tweet, Mike.

And then I was going back through at mentions for our old Twitter handle. So if you're listening to this and you're still tweeting at the changelog on Twitter, we've moved to at changelog because it's, you know, it's shorter. Saving three characters. Saving three characters.

That's right. So we did that. And,