The Oban Pros

Welcome to changelog and friends, a weekly talk show about mom and pop software shops. Shout out to our partners at fly.io, the home of changelog.com. Launch your app as close to your users as possible. Find out how at fly.io.

OK, let's talk.

Yes, let's talk about our friends over at fire hydrant real quick. They have a brand new on call feature called signals. And what you're about to hear are real reactions from pager duty users when seeing signals from fire hydrant for the first time.

Pager duty, I don't want to say they're evil, but they're an evil that we've had to maintain. I know all of our engineering teams, as well as myself, are interested in getting

this moving the correct direction as right now, just managing and maintaining our user seats has become problematic.

That's that's that's really good. Actually, this is this is a consistent problem for us and teams. Is that covering these sorts of ad hoc timeframes is very difficult. You know, putting in like overrides and specific days and different new ships is quite onerous.

And you did the most important piece, which is didn't tie them together. Is that half the problem with pager duty, right? Is I get all these alerts and then I get an incident per alert. And generally speaking, when it goes sideways, you get lots of alerts because lots of things are broken, but you only have one incident.

Yeah, I'm super impressed with that because being able to assign to different

teams is an issue for us, because like the one the one alert fires for one team. And then it seems like to have to bounce around and it never does. Which then means that we have tons of communication issues because like people aren't updated.

No, I mean, to be open and honest, when can we switch?

So you're probably tired of learning tools that feel more like a headache than a solution, right? Well, signals from fire hydrant is the alerting and on call tool designed for humans, not systems. Signals puts teams at the center, giving you the ultimate control over rules, policies and schedules. No need to configure your services or do wonky workarounds in just data seamlessly from any source using Webhooks and watch as signals filters out the noise, alerting you only on what matters, manage tasks like coverage, request and on call notifications effortlessly within Slack. You can even acknowledge alerts right there. But here's the game changer. Signals natively integrates with fire hydrant's full incident management suite. So as soon as you're alerted, you can seamlessly kick off and manage your entire incident inside a single platform. Learn more or switch today at fire hydrant dot com slash signals. Again, fire hydrant dot com slash signals.

So we're here with Parker and Shannon.

This is our BOGO episode. Buy one, get one. So we we have Parker here with us. But this is not just so we're in one. This is so we're in two. We got both Parker and Shannon. They are teammates in multiple respects. And how many ways are you two teammates to start counting? But let me count the ways.

Business partners, one spouses to we made children together. OK, three times. I don't know if that's more than one.

Keep it clean. Yeah.

So I guess that's two and she's anticipating four.

You've got to have four. She has our fourth finger.

She can she can pitch in a fourth if you have an idea.

Yeah. Hey, team teamwork on this question. That's a fourth podcasters together. He does insist upon that. Yeah, he does. A friend, I would say he's a very good friend to have. That's true. There's my best friends as well.

So that's a that's a team.

It depends on me heavily for comedic effect. Yeah. Parker sets them up and Shannon knocks them down. That's what we're going to expect from here on out. That's a that's a high bar. That's a big yeah. That's an order that I cannot maintain.

You'll be fine.

Well, this is changelog and friends. We're hanging out with Parker. We've known for a while because you are the creator, maintainer, purveyor of open the background job processing library for Elixir, which we are users of and you have open pro, which you've been having worked on for a while now. I had you on I think backstage. It was just you and I don't think Adam was there a couple of years ago talking about open pro and your desire to go full time open or retire via open. I can't remember what it was, but there was a freedom number involved. I think you still had it. Is that because you still had a day job? Help me jog my memory here about your status back when we had you on the show.

Yeah, I mean, your memory is correct about all those things. I think it was probably a year and a half ago. It was just you and I. Yes, we were talking about open and pro. We did talk about some freedom numbers. The ultimate goal, we call it our retirement project. I still do have a day job with discount. Oh, you do for a variety of reasons. One just kind of I've been there for a long time and have a responsibility to the founder, who's a good friend and longtime coworker. And then also, it's such a huge user of open and pro that pushes it that I just have daily insight into exactly where people feel pain points and what people need. So, yeah, it's still going.

Makes sense. So what is the what is the retirement situation? What is this, you know, the freedom number? What is this? I think it's a ruse. That's what I think. Because I don't think he would ever want to be free, really.

I think the definition of freedom, what is freedom?

Right. So passion, the project open is in every aspect of our life. I mean, it's at every dinner, it's drawings on the shower. It's it's in every aspect of our life. We work on it. And I don't think I realize that. Until we leave our little bubble and we're around other people and we get this mirror

image of what we're doing all the time and how often we go back to it. I don't think I'm aware of it until we're around other people outside of our bubble.

So you're with your friends. They're like, why are you talking about open?

I thought it would be hilarious. You know, when you do this, what if in your mind? I thought it would be hilarious for most

developers to create this video of our kids trying to explain to our neighbors or to anybody else what it is that we do and get them a whiteboard and have them try to draw it or have them try to describe what it is that we do. Just somebody else who sees us all the time communicating what it is they think we're doing all the time.

It doesn't have to be kids. It can just be me trying to explain to people what we do. Because I do a terrible job.

I think you do a great job. He gets so deep so quickly. I take the opposite stance. I try to stay as high level as possible. So my old line was I make websites and that worked pretty well. People are like, OK, because they understand websites. You make websites. We're done here. And then I got to write other stuff. And so I change it to like I write software or I'm in software. And that was pretty much people are done with you at that point. They're like, OK, that's nice, Jared. Let's move on. Now it's weirder. Actually, I podcast about software and they're like, you what now? Because those are two things that are foreign to me. And it usually opens up a bigger question. They don't want to ask about the software, but they do want to ask about the podcasting for some reason. That's interesting to people, but also sometimes harder to explain how it all works.

It is. You've got a meta situation, too, because you write software to make it easier for you to publish your podcast about writing software. Yeah, exactly.

Which I never go there. Like I can go there with you guys. It's a Russian doll. It's just a Russian doll situation. For sure. And even telling people what change log means that do not understand software, it's like, well, they're like, that's a kind of a weird name. But in our world, it's like that's kind of a perfect name. But they're like, what is the change log? What is change log? What is that? And I'm like, oh, well, that's that I have to explain what a change log is. And it's like, well, this is the difference between one version or another. It's how people communicate, you know, what those changes are.

Your podcast is a change log.

I'm like, well, if you were in the world, you would understand how on point the name is and how perfect it is. Unfortunately, in this moment, you're not. And so they're really impressed with our name. If you were in this world.

Well, then it's like you're explaining a joke and you can never explain. Yeah, for sure. Once you start explaining it, it's over.

It goes wrong really bad. So Obon has discussed a lot at your dinner table or just, I guess, generally everywhere where you're at. Right. Like it's right. How so? I guess I don't want to say this pejoratively or as a pejorative, but like it's just background jobs. Like how much can it be in your conversations? It's just a death tool. Yeah. Sorry about that. I had to do it.

If it was no, no, no. That makes if you put if you phrase it like that, I think it makes perfect sense. But it's not just our background jobs. It's a lot of other people's background jobs. And because there's an open source version and then there's a paid version and the paid version comes with support, although quite honestly, we're not great about just leaving people who don't pay for support to the wolves. It means that there's just a lot of helping other people with their problems with background jobs and invariably when you build a tool which can be pretty complex, you can't predict all the ways that people are going to use things or the environments they're going to use the things in and you can't test in all those environments and you put all those together and it can be pretty deep for debugging or just support and so you kind of get to know people. Some people come back more. They just have bigger issues or they're just a little chattier about the issues. And so it's not always that we're talking about Oben as much as the people around it.

It's exciting when you have a new customer that you've used their product in a in the physical world and you see their name come up that suddenly they're now a customer that will spark a conversation being

responsive to our customers and having them give feedback and accolades will lead us to another conversation. It takes very little. We take the bait.

Yeah, I think what's really important here is the partnership and the opportunity, right, because I don't know how you are, Jerry, with your work and your wife. And I know how it is with my wife. She's not deeply involved in our day to day. And so we're less partner in the things we do day to day. However, she's obviously deeply invested because, hey, we're husband and wife and the same for you and your wife. But you all are working directly together on the output, on the effects you're sharing in the ups and the downs, which makes the journey, regardless of its up or down, just a bit more fun and a bit more supportive, I suppose. You don't feel like you're falling solo, you're falling together or rising together, which to me is kind of a beautiful thing.

It stands out where an incident could very easily become an incident, though, if you're not careful in that same.

I agree with you and the positive.

I thought it was poetic.

It is poetic and I embrace that. But I hate to give somebody the whole pie in the sky without the reality of the patience it takes to restrain yourself when your partner is refactoring something or has critique of you in a response. And the familiarity leads you to a dark place. You have to be patient. You just have to be extremely patient because a work incident, right, an incident with a customer or with code, it could become a personal incident in a matter of seconds.

So it's just it's just that restraint.

Well, that's where love and respect comes into play, right? Absolutely. As partners, I think even for my wife and I'm sure Jared, you're the same because we're kindred spirits in a lot of ways. It has to begin with love and respect, right? And if you're formed there with goodwill, like I have goodwill for you and the formation of the partnership at the friend level, then the husband and wife level and then the kids level and then the business level, like if all those things are foundation on love and respect, I think even those incidents are a little easier to deal with because you do the ten second rule. Hey, I'm upset right now. I'm going to pause. I'm going to count to ten. I might even go away and count to a hundred if I have, if it's really a big incident, you know, but love and respect sort of gives certain contracts, I suppose, into place because of the foundation of love and respect. And I'm assuming that that's my foundation with my wife. So I'm just sort of like assuming that's for you all and giving it to you if you don't have it.

No, I think we do have it. I think it's a good assumption. Yes, we spend a tremendous amount of time together, possibly a disturbing amount to some couples like we were doing it before COVID, before people so frequently worked from home. But not only are we working in the same space and living in the same space and then raising kids in the same space, but working on the same things in the same space, and you have to have a tremendous amount of respect.

Yeah, it makes sense to me how you got there on the other dimensions, but on the work dimension, on the business, how did you end up here? Were you already business partners and this was the opportunity? Did Shannon start it and Parker hopped on, vice versa? Like how did it end up to be this partnership around this project?

I had been consulting originally and started my own business and wanted Parker to consult with me.

He had been working at a design firm and with the birth of our second child, we decided we were going to take the leap and do it together. We had tried to explore some other app ideas and had made it to a very shallow level, especially with something like snow and things like that. And it just didn't really take off. We wanted a passion project. We both started with Ruby and Rails and Parker really made the brilliant choice to move to Elixir.

And I think he has led us there. So I may have started it, but he's led us to where we are in a wonderful way.

And you had a proven guinea pig, so to speak, with Mike Parham and Sidekick and Sidekick Pro in the Ruby world, in the Rails world, much success, very much similar project, similar structure. That had to feel good to say, OK, here I am in a different place with different tools, probably some of the same people who remember Sidekick, like me, for instance. So there is an analog that I can draw pretty easily to Sidekick. Although in Elixir land, background jobs are less necessary, like the kind of background jobs that you provide are less necessary for people just getting started, then I think eventually you kind of do grow into wanting the persistence and a lot of the scheduling and the tooling that you provide. But I went a long time without having any background solution on our application, probably three or four years. I had to look back and see exactly when I pulled O-band in the first time. But besides that, you did have kind of Rails to run on to a certain extent. Did that give you confidence? Were you basically like saying, I'm going to take Mike Parham's playbook and apply it in this ecosystem? I mean, no shame in doing that, by the way. Like that's a that's a good way to do things. Was that part of your playbook?

That was definitely part of the playbook. And I do have history. I'm not going to say Mike's my friend, but I do have history in the past of collaborating with him and sharing some work with him and writing a tremendous amount about Redis and Sidekick and helping former contracting clients onboard enterprise and pros. I was deeply familiar with both the business and the code and all the features and saw it as such a great way to have a technical project that is a developer tool. So you're selling to developers, but also to something, you know, scratching your own itch, where you understand deeply exactly what problems you have. But you're right. In many ways, it's not as necessary in Elixir. You can get away without it for a while. And until you understand that you have certain guarantees that you want to hit of, I'm not ever going to lose this thing. So the concurrency story in Elixir compared to the concurrency story in Ruby are vastly different. It's unbelievably easy to do certain things in Elixir that would be tremendously difficult, if not impossible, to do in Ruby. And so that's part of like the springboard for open has a lot, I think, deeper features than much of what even Sidekick Enterprise still has. And that's purely because of what Elixir makes possible. But I will say one other thing is that I remember after somebody added open to the changelog code base before that, you guys were using quantum for cron. And so in a way, you were using a Sidekick Pro kind of feature, but with a different project there.

Yeah, we needed scheduled jobs. Yeah. And I reached for quantum for that. But in terms of running emails and stuff like that, like the kind of stuff that you would immediately in Ruby on Rails land, you would reach for a sidekick pretty much immediately as soon as you wanted to send an email in the background without blocking. With Elixir, even our stats processing, like a lot of the stuff that we do in the background using Obon today, which we can look at all the things, I was just doing that with straight up Elixir and the Beam and all those fancy tools. And it's not fancy like it was easy for me to do that. But once we wanted scheduling and then retries, even just visibility into once your background jobs really matter, then it was like, yeah, we want something that's going to provide more than the built in. But like I said, we lasted probably three or four years without it and probably been on it for three or four years, something like that.

Yeah. And I think when you were starting, Obon didn't exist, so you couldn't have even used that if you wanted. It would have possibly been something else.

Yeah, there's a lot of stuff that didn't exist. And so I hand rolled a lot of solutions, which are still in our code base today. We get questions sometimes like, why did you do that this way? This seems really convoluted. I'm like, because that was just how I figured it out in 2016. You know, there just wasn't like Phoenix didn't provide a way of doing that or there was no best practice style library that everybody uses. I'm thinking of CSRF stuff and a lot of the things around turbo links and just cookies and junk like that where you're just doing it yourself. You're just hand rolling it off. I think I hand rolls off stuff because it was just the early days. But so don't necessarily go look at change.com code base for how to do things today, but even context like Phoenix really promotes the idea of context now. And I just ignored them altogether. And so I tried to introduce contexts as the feature came out because the Phoenix team was really big on it and the ecosystem was big on it. And I just felt like for our application, it just felt like another layer of abstraction that I didn't necessarily need and so I just ignored it, which I love that about elixirs. You can just ignore the stuff and about Phoenix the way it's built and you don't have to use it. I mean, sure, it's the idiom. You're going to look less like a Phoenix app by doing so, but you can just ignore it and do things your way. And so I've continued to do that. And I think that most modern Phoenix apps wouldn't look like ours, at least for that reason.

And live view. Yeah, yeah, plus live view. Yeah, we for our web, for open web, for the development, we have like a single file script that's essentially an entire Phoenix application in one file that also generates random jobs and all this different timing, the kind of stuff that we have on our demo so that when you're working on it locally, you have some reasonable amount of job traffic and errors and cancellation. But that fits in exactly one file. It's not like it's an entire full blown scaffolded Phoenix app. It's just the bare bones things. And as long as you configure it right and the modules are there, it all just works. So, yeah, it's easy in that way once you understand what the parts are.

Right. Well, that was one thing that attracted me to Phoenix in the first place was how simple it was relative to Rails in terms of it for me, it was the stack traces when I threw an error on the page was the stack traces were tiny, like, you know how in Rails, probably to this day, I haven't done Rails a long time, but it's like, here's your application code trace and then like, here's the framework trace. And this one collapsed by default because you don't want to look at that one. And it's the same way in Phoenix. But when you go and like expand the framework trace, at least back in the early days, it was like eight function calls. I mean, it was nothing like my code was there. And there's you can see the entire pipeline of function calls and it was like 12 function calls. I was like, wow, this is something I can actually reason about relatively easily. Now it's probably a little more deeper than that. Now you guys probably know better than we do better than I do, perhaps. But I like that it was just it was grokable. Like you could you could see all of Phoenix and there was nothing hidden from you.

I know it's a little unorthodox, but did Phoenix bring you to Elixir then, because that would be pretty much.

I mean, Chris McCord basically brought me to Elixir. So in that way, yes, we had Chris on the show before we had Jose on the show. We were just reminiscing with Jose a few weeks back about this because I've been a web developer pretty much my whole career and Rails for many years. And Chris had a very similar story to mine. But then he found Elixir and he built Phoenix and he came on the show and he talked about how cool it all was. And I went and tried it, tried Phoenix specifically and got this little application up and running in like a couple of hours and deployed as well, which was just a simple like one endpoint, call Slack API, do a thing. It was like our old Slack Inviter before we had a full system. And that was just so fun and easy. And it looked somewhat like Ruby. And turns out it's nothing like Ruby, but it has this like facade of Ruby-esque taste, maybe has a Ruby taste to it.

It's got a slight syntax to it.

Yeah, exactly. There's a flavor there.

A veneer.

And I was like, oh, this is this is pretty cool. So it just proved itself relatively quickly. And back then I was a full time contractor, part time changelog or even just maybe nights and weekends changelog back then, not nights and weekends technically, but just spiritually, because I was an independent business owner. So I could work on it when I wanted to. So it'd be during the day times. But it was a hobby for me.

I think Adam had gone full time by then. 2015 was your full time.

I'm looking at the data. We can record that. That was March 20th, 2015 was the record and ship date, which means it's probably around the same week span, because this is prior to us having separate date fields in our CMS for those things, because this was published probably the old way prior to the CMS. And the CMS is the application we're talking about.

Well, it had to be the old way on stone tablets. Is that the old way? You're hammering it out basically.

Yeah, I don't think I went I think I went full time around that time. I think it was like February 2015. So like this was like literally when we were courageous enough to say, Adam, quit your day job and make this thing your thing. And so I guess we're coming up, I guess next year would be 10 years of being full

time on this thing. Wow, that's a great anniversary.

We celebrated our five year.

Yeah, recently. Congratulations. Big for us. Not as a people, but for ObEN. Which context? Come on.

All right. Well, dual anniversaries here. Dual anniversaries for the ObEN context. I think that would be a dream to have people choose Elixir in the way that people love Phoenix. I'm not going to say that that would ever happen, but that would be a dream that people would come to Elixir wanting to use ObEN. What's up, friends? I want to share an awesome new announcement from our friends over at Crab Nebula. Crab Nebula is the official partner of TOWRI. For the uninitiated, TOWRI is a toolkit that helps developers make applications for the major desktop platforms using virtually any front end framework in existence. The core is built with Rust and the CLI leverages Node.js, making TOWRI a genuinely polyglot approach to creating and maintaining great apps. So building applications with TOWRI has always been an incredibly joyful experience. However, once the applications are built, distributing them and rolling out updates has always been cumbersome. This is why we are thrilled to be part of this announcement from our friends at Crab Nebula on their latest product, Crab Nebula Cloud. The problem really is the cost of distributing applications, the security and the feedback and analytics. Just think about cost alone to distribute new applications at scale. It can get very expensive when bundle sizes compound with the number of users, which further compounds with frequency of application updates. Always be shipping, right? A 500 meg application distributed across 500 users with nightly updates leads to a total of around seven point five million megabytes. That's seven point five terabytes transferred in a single month. Now, based on popular cloud pricing, this could easily lead to a bill in the ballpark of around ninety thousand dollars. That's a lot of dollars. More so, distributing updates requires complex cryptography to ensure that an update is the original safe artifact for users to download, install and execute, and then collecting meaningful analytics is more challenging with desktop applications compared to web based services impacting the ability to make informed updates and improvements. So at the heart of Crab Nebula Cloud is a purpose built CDN ready for global scale, ensuring seamless integration with any CI CD pipeline and first class support for GitHub actions and security updates are a first class citizen. Leveraging the power of Tauri Updater, Crab Nebula Cloud provides an out of the box update server that any application can call to check for signed updates and if the update is available, immediately download and apply it in an instant over the air. And of course, Tauri is open source and Crab Nebula is a company born out of open source and they're giving back to the open source community by giving steep discounts and subsidies to open source projects built with Tauri. To learn more, get started and check out the docs. Go to crabnebula.dev slash cloud. That's crab c r a b nebula n e b u l a dot dev slash cloud. Once again, crabnebula dot dev slash cloud. We understand our niche pretty well. We can clarify the market all we want for us unless we have more people. More Elixir users will max out at some point. That's just the reality of such a, Elixir is just an amazing thing, right? But it's a niche. But it's a niche. So we have to, we've discussed recently doing something

to just try to widen that pool and bring more people to it.

Yeah, I think that's interesting because I think it's, it's not only a niche. It's a successful niche, first of all, but it's also a mature niche at this point. I mean, it's a pretty mature language and a mature ecosystem. And I think there can be new tools that bring people in. I think Nerves probably brings people in. I think Live View itself and a lot of the stuff that Phoenix is doing is cutting edge. And now you have, what's Chris doing at Fly with the serverless stuff? Flame. Flame, like he's still pushing, pushing on the edges, which does bring interesting or interested people in. But that being said, I think Elixir in a certain sense, and you guys can disagree, Adam, maybe you have a different viewpoint, has kind of found an audience. And so I think it's kind of like at the top end of the S-curve of adoption, perhaps, unless there's, unless ML changes it. I mean, it has great ML tooling. Jose has been investing in that. But, you know, most people are using Python and newer things, Rust and Go. And so I'm wondering if like, you know, if the Elixir ecosystem has a lot of room to grow or just some room to grow at this point, because it's pretty mature. What do you guys think?

I think the, to rewind slightly, there's the whole notion of like a killer app. The thing that brings somebody like, this is why I bought, I wanted VisiCalc. So I bought a Mac or an Apple or whatever. And I think for a long time, Phoenix has been the killer app of Elixir. And we've had other ones, like you mentioned with Nerves a little bit. And then I think the ML is opening a whole new realm of possibilities to attract people that would have been firmly in the Python camp. And we sort of dreamed that Open is also another companion killer app that it's like, there's enough compelling stuff here, enough compelling features that it's worth it to pick up and make an Elixir app just so you can use Open and the workflow stuff in Pro or all that. But even more so if you were to pair that with the ML side. So if you look at some popular tools in the Python side that are like DAGSTR or things that are meant to run workflows, they use them for ETL pipelines or complex machine learning flows and all those things do decently in Python because people have put so much time into it, but it's not as natural a fit as it is in Elixir. So the vision that we have is that it's enough that you can have your web app, but you can also have your web app orchestrate things and it can do all this ML stuff and it's all under one blanket of a single ecosystem. And then you have all of the other fantastic documentation and great packages and a really vibrant, responsive community. And you have all of those things instead of having to scatter your attention between the JavaScript for some stuff and the server-side language for some stuff and Python for the ML side.

As you describe this, I'm thinking like, do you produce any content around this attracting folks to Elixir because of this comparative nature to Python and how it's good and it does it, but it doesn't do it well, I'm paraphrasing what you said there, but you know, it sounds like you've got a bias obviously, because we know you, we know where you live in terms of where your camp is at. I'm just curious, like how much do you help with the growth, not just provide the tooling, and I don't mean that in a negative just, but like how much are you doing activism and outreach and advocacy around, you know, the depth of ability that you can have Elixir over other traditional ways or maybe ways that are being seen as, well, Python's the easy path in some cases for those kind of workflows, for example, you know, and that seems to be the default in the marketplace, so to speak, of Devland, and they don't consider Elixir because there's not enough awareness. Well, should we discuss that, which shall not be named?

I mean, what is it?

What is it?

You're obviously a surprise to all of us.

All right, deep breath. So, I mean, I think you'll see more, I think you'll see more content. So to your point, maybe not as much as we should have up until right now. We have not. I think you will see more content from us supporting that and doing that. We had researched a bit and had decided we were going to embark on a cross-platform kind of version of ObEN. We were putting our toe in for Python, and I kid you not. Go ahead.

Oh yeah, it was within a matter of time before like hatchet was, things were announced, there's been a lot of movement in the past year.

It was just a Y Combinator effort was just launched and their marketing is phenomenal. There's a lot of lessons to be learned from that, but it was within weeks of us starting to strategize and pull together on that. And we had had a lot of walks and talks about how we can really do what you said, Adam, to really bring in our efforts towards the Elixir community to support that, to, you know, what niche can we fill within that community? What can we develop? What's missing? What have we wanted? We've jotted down ideas, but we had started exploring a cross-platform version of ObEN and within weeks it was released. So I guess it's just whether or not we're going to put our efforts into picking a fight.

I'll say maybe not picking a fight, but the number one takeaway was well, I guess there are two takeaways is that the description of what they've built, it sounds fantastic, but the complexity of what they've built, you couldn't even tout those things in Elixir. They'd be so table stakes to do things. But the marketing that they have around it and the use cases they're describing are things that would work perfectly for what we want to build. And definitely, I think there's, we have to do work to try to communicate and bring people in.

I'm looking at Hatchet now, and I kind of want to preface some things because it seems like a startup, right? Backed by Y Combinator.

Totally a startup, yes.

Is Hatchet cross-platform then? Is it focused on, it's hard to tell from their description because it seems overarching, not, hey, we're in Python land, come get your Python task queues here, et cetera. It seems very much like a larger play than simply one language or one camp.

I think it is. I think they're doing sort of a Mike Perham factory kind of thing where there's a server that coordinates things, and then they have SDKs in various languages.

What's stopping you all from doing this? I mean, this, again, I think Jared asked before, like, hey, did that give you confidence because of the path of Sidekick and Sidekick Pro when you initially started, you know, this to me says there's room for a mature option, I suppose, but then that really depends on, because this goes, your whole entire operation goes from, let's just call you mom and pop. Do you mind if I call you mom and pop?

No, we definitely refer to ourselves as the mom and pop software shop.

Right. I mean, you're very mature. I mean, I don't know more of your employment. Like if you have other folks working with you, maybe you have temps. I don't know. Who knows? I don't know what you have, but it seems mom and pop. It would say, okay, you've got to graduate to a whole new level. And do you want to be at that level? You may see the market opportunity. That's going to change your lives. That's going to change a lot for you. And sometimes I've even lamented about this with podcasting, running an indie media company is like, I like what we do. I like what we do as an indie media company, but at some point the market and maybe other competition may say that we changeable media has to become more of a in quotes, behemoth of sorts or funded or operate differently because competitors compete with us for ear share, market share, mind share, et cetera. And then, so we've got to follow suit or wither on the vine and die, or just be happy with our little slice of pie. Not intended to rhyme that, but I did. So, you know, Y Combinator backed, Hatchet seems pretty like just go into their page. It seems like it's pretty strong as a competitor or at least has the firepower of Y Combinator. You never know really. I mean, this could be a beautiful paint job. Who knows? What are your thoughts on what it might do for your evolution?

It is a beautiful paint job.

I think there are a lot of lessons still. I mean, that was a moment, right? That was a moment last week to see that, discuss it.

And I think, I mean, you mentioned being an indie media provider. I don't remember the exact phrasing, but I think that's... Indie media company. Indie media company. But that's kind of the beauty of what your company is. And I think part of our size and how deeply embedded in the community, the Elixir community we are, is one of the strongest assets for our company. And I think if we were just on the outskirts and tried to push into, say, Go or something else without that deep history, I don't know. I don't know what it would take to get there or even if we would have the attention or time to do it. We don't have any temps. We don't have any other employees. There's nobody else doing support when we're on vacation or asleep or something. You know who you're getting.

We've never contracted out for pro, ever.

Or web.

Or web. So, I mean, I could say hi to David. Hi, David. I know you're listening. So...

For the server.

For the server. So I know...

David is the name of your server?

No, David Brunheisel. I'm saying hi to David.

So Leastmore is the name of our server and Leastmore is the island that is across the Bay of Oban. So there's a fun play there.

And that's where we keep the people that contract. They stay within that island. They don't... It's not like Alcatraz or... Stay there on your island. You can swim. Reminds me of Son of Anton. Gotta do the ding because that's a Silicon Valley joke right there. Son of Anton was the server stack that Guilfoyle stood up whenever they got blacklisted from cloud, essentially. Gavin Belson was like, you can't play here anymore. They got blacklisted from... They named Rackspace. That's how relevant this was back then in those days of this episode. But Son of Anton, I love naming servers, but that was the name of the one in Silicon Valley.

That's brilliant. I think all the questions you just asked were the questions we are asking each other in the last few weeks.

Well, what's the answer?

We have different answers. Do we? Let's hear them all. Let's hear all the answers. Yeah, as a wrap and go.

It must rhyme. I can see the dynamic already playing out. He asked her to wrap her response and go. That was cool. And I took my three fingers and put them in the middle of my forehead to just try to express the pain.

The answer. I don't know. Well, you can say whatever.

Our answer today was similar to the answer like four days ago. However, the answer four days before that was somewhat different. So I just want to know which one you want me to go with because I... Should I do a Tom Cruise thing here? I mean, I want the truth. You can't handle the truth. Give me the truth. What's the truth? As of this morning, our roles, we're pretty defined in our roles and hiring more people in a way that changes our life. Right now, we are happy with what we do, how we're doing it. We feel a huge amount of responsibility to our customers and to that trust that they place in us. That doesn't mean that they wouldn't make other choices. I'm not foolish enough to believe that. So I think we have to really pivot and decide if we're going to put our passion into building up that community, or if we are possibly going to try to compete and pick a fight. And I only use pick a fight as a term from a book, not that I mean that I just...

In the old 37 signals, pick a fight. In a 37 signals kind of sense. Rails versus Java kind of way.

So that's what I mean by that. I don't mean a literal fight. So I don't think we have a definitive yet.

We very much like our roles, we're very good with our time management, but all of these things don't point to which direction we really are going to go yet.

Yeah, one thing that says actually in that book, I'm pulling it up, Chapter 8 have an enemy. And I remember this, actually reading this, this brings back memories, because I think a lot of what Basecamp, they were like, we don't know what we want to be, but we know what we don't want to be. And so the enemy was very much like Microsoft based tooling and how terrible it was.

This is how I feel about this right now. I'm channeling a bit of this book right now.

This is, I understand, yeah, I feel we know our roles. We feel responsible to our customers. We might pick a fight. However, we know, we know who our real enemies are. And our real enemy is not necessarily at this point, a startup that could be wrong.

I've written lots of JavaScript and anger. I've written a tiny bit of Go and anger and I've written plenty of Ruby and Python, written thread pools and process pools and done all that. None of that is pleasant. I don't ever want to do any of those things again unless I really have to. And by comparison, working in a Beam language and working in Elixir is just so simple and joyous that the idea of leaving that to go focus on something else is, it's kind of painful.

So I think you know his answer. I think you get, his answer is very much, no, I do not want this.

I'm all full of feelings and maybe not so much logic.

And that's all right. They're important feelings. That's a good awareness to have in a moment like this, right? Like when you're in that we must pivot or consider pivoting moment, it's important to have awareness of truly the emotional response you have and then counting to 10 or kind of 100 or maybe even 10 days kind of situation, like that moment of emotion to decision, you've got to put some buffer in there as just a way to protect yourself from being too irrational, potentially irrational. Right.

Yeah, but also like for you as an indie media company, there's part of it like how much do you want to grow versus how much do you not want to face an existential crisis?

I think Jared and I can answer that pretty well. We've, I mean, I think, I don't know how Jared would answer it, but I think we're happy doing what we do. And I don't, I think we're on the long game. Like when I talk to people, they're like, wow, you're really thinking like, I was just at a, in quotes, mixer for GitHub. It's here in Austin. They were here for South by Southwest. And they invited me out to come hang out there for a couple hours while they were at the garage bar. And I was there and I was talking to folks and I was like, hey, we should pot about that sometime. They're like, well, I work at Apple and I can't tell that story. And I'm like, well, you know, we'll be here whenever you're ready. Like that sounds pretty cool whenever you can share it. And they're like, wow, you have like this long game approach. I'm like, well, I just been doing this for so long and I have a pretty good confidence in like how we've been here and what keeps us here, both individually as passion, but also as a company. And I just have confidence that we'll be here at least in a few years to maybe have that conversation. So they were just surprised that I had this long game approach to things. And I think you kind of have to. And so our long game approach isn't OMG, there's a competitor or there's a podcast that's more popular than us, or there's an influencer who's more influential. Like Jared and I are not trying to be influencers or influential. We're just literally trying to talk to people who share passion like we do, get excited about where software's going and just have amazing conversations. And from a technical level, produce a really well produced podcast that sounds like people want to listen to. We produce beats album with Breakmaster Cylinder, like we have music out there. Like what other job could Jared and I do this kind of stuff at on our own whim? Like we make the choices, you know, we get to go into the nooks and crannies and hang out there or zoom out and get bigger level. If we chose to follow, you know, the name that shall not be named kind of situation, like, oh my gosh, like we would just be chasing them and not not going after what we feel is important and what we think is more fun. You know, we're in as best as we can be. We are in control while also being in a world of chaos and total change every day. Right.

I think we're in such a similar situation.

That's where we were as of this morning. We, as of this morning, we decided to put our efforts into ensuring that the legacy and the process of us maintaining anything. If there was a tragedy, something befalls us, that our customers are in a good place, that things are in a nice,

responsive little box that people aren't left in the lurch. That's what we decided this morning.

How much I got to ask you this, too, just because it's such a an analog for me personally. I've watched this over and over and I'm seeing things that I haven't seen before. Have you all watched? I'm sorry, Jared. Silicon Valley end to end, like all the seasons.

I've never seen a single episode. So we're on Jared's side. My people. My people. I was prepared for that. I'm sorry.

Not your people. Okay. So you're missing out on wisdom here. Okay. Are we? Oh, yeah. I mean, it might hurt you a little bit, but I think there's wisdom there. And I'll just, I won't spoil the story except for that. You may assume that this name that shall not be named. If you want to keep saying that, I can.

No, Adam, you, you have carte blanche. You can do what you want.

Well, hatchet.run then I suppose. Hatchet is the, is who you've considered there. There are Y commentary and it's unclear on how well they're doing. Like you can assume that from the outside, but on the inside they could be like not doing well and not really competition.

We saw it as just kind of like a counter data point of like, oh, that's what that looks like. If you do it like that, that's.

And I think their use cases are great. There were, there were lessons that we learned in going through their material. We don't have fear in our hearts about them. Okay. We're not expecting them to pull the sword from the stone. None of this.

No, no fear.

Okay. Well, you were just saying like how you were making sure your customers are very good. If something happened to tragedy, so you were speaking melodramatic about the potential.

She's talking like really tragic. Oh no, no. I mean, yes, she made, yes. Bus factor of two.

I understand then. That's all I'm saying. Sorry. I'll clarify. I mean, we are riding around Scandinavia, Europe, cars. I mean, sometimes we take, we don't, we don't take super risky decisions, but you know, we're adventurous people. It's good to have other contingency things in place for people who depend upon us. That's all I meant. Our customers will be in a good position. That's what we've decided.

Cause you could take a deep dive into our business and our time management and you know, everything that we took so long in the beginning to set up, I feel like we're in such a good place with it now.

Can you describe your business? Can we go to like your pricing page and grok what you might be doing? Like what's the best way to examine from a business level, like beyond the software, beyond it's, you know, it's ecosystem where it hangs out at like as a business, how do you work?

You invited this and now you have to answer.

What's your business model?

Our business model is open core. That's totally in essence. We sell a couple of paid packages or a bundle of paid packages on top of an open source offering to the two packages. One is web, which is a live view power dashboard that people run right at their main application that gives them control and access and metrics and stuff all to their interior open working. And then we sell pro, which is a bunch of more complex, more advanced features built on top of open that is all possible through extensibility. And then with either of those, we have a metrics package and we have support.

And there's a custom enterprise and then there's a customer to reach, which is for if

people need more support. OK, that's the plan. That's that's the whole thing.

What's up, friends? This episode is brought to you by one of my good friends, one of my best friends, actually, one of our good friends, Tailscale. And if you've heard me on a podcast, you've heard me mention Tailscale several times in unsponsored ways because I just love Tailscale and I reached out to them and said, hey, we're talking to a lot of developers. I love Tailscale. I'd love to have you guys sponsor us. And they reciprocated. So what is Tailscale? Well, Tailscale is a programmable networking software that is private and secure by default, which makes it the easiest way to connect devices and services to each other wherever they are. You get secure remote access to production databases, servers, Kubernetes, VPCs, on prem stuff, anything. It's fast, like really, really fast. And you can install it anywhere. Windows, Linux, BSD, Mac OS, iOS, Android. It is an easy to deploy, zero config, no fuss VPN. It is zero trust network access that every organization can use. So what can you do with Tailscale? You can build simple networks across complex infrastructure. They have ACL policies to securely control access to devices and services with their next gen network access controls. You can replace legacy VPN infrastructure in just a few minutes. You can use device posture management to granularly restrict access to resources based on a wide range of attributes like OS version, user location and more. You can save time with a trusted and proven networking solution that just works. You can transform networking security with a modernized set of solutions built on revolutionary protocols designed for today's mobile and multi cloud era. You can securely connect to anything no matter what operating system, hardware type or configuration is in place, such as your GitHub runner to a database on prem. You can authenticate without authentication using Tailscale's app connectors. You can send files securely to any node on your tail net using tail drop. You can code from your iPad even with Tailscale and VS code server. There's just so much you could do with Tailscale. Like the limits are literally limitless. And that's why I love Tailscale. I've got 28 machines personally that I manage on my tail net. And if you've heard me talk on a podcast, you've heard me mention Tailscale at least once or twice. But today you can try Tailscale for free up to 100 devices like me and three users for free at Tailscale.com. No credit card required. Again, it's free up to 100 devices and three users all for free at Tailscale.com. No credit card required. Have fun. And what was your freedom number? And when did you reach your freedom number?

What was the first? He said, what's your freedom?

I was going to go there, too, because like we're now back to, you know, understanding more clearly your freedom number. What is it to get there? How close are you to it, et cetera?

I feel that I have to answer this since when I messaged Jared most recently, I

poked him with this. So I don't like specific numbers.

We'll use percentages and things.

So we use a range or something. Yeah, don't be, don't be gratuitous.

The salary of a senior developer in the U.S., a very senior developer in the U.S., that would be the freedom number.

Half a million or more.

Below that. Let's say, let's say, let's say between a quarter and...

I was hanging out with the wrong people then last night. Gosh, somebody is... You're with some Google Apple cards.

Apple, I mean, Silicon Valley people. And the Fangs. You were in the Fangs. Chicago kind of people.

Non-Fang developer salary. So we're talking about...

Non-Fang developer salary.

200 to 400, right? Correct, Jared. Okay. So that's your freedom number.

Yeah. And then we're over 200% of our freedom number.

Well, congrats. That's awesome. Well, that's a good place to be. Congratulations. Now you need to go to Mojito Island. Isn't that where you go after you reach that? Gen and gen servers. There you go.

Yeah. You're on your sailboat and I'm on the beach and I say, looking good, Shannon. And you say, feeling good.

Feeling good, Parker. Yeah. I wouldn't be too nervous about your existential business at this point.

Yeah. So it's not an existential thing. It's just, where do you, where do you want to...

Where do you want to spend your time thinking about? Do you want to grow into this other ecosystem where there's competition or do you want to firm up your foundation and make sure that if you do, you know, go out to Mojito Island and forgot to come back to work the next day, then some, you know, it's going to continue. It's going to, something's going to happen.

I think there's, there's another part, which is, this is like the acolyte in me of, I think Elixir as a language and as an ecosystem is just better than any, not, not every other language. Because of course it doesn't, it's not comparable to, you know, writing C or Rust or Zig or all these other things that just have a different category they fulfill. But if you're writing web technology, I just don't think, this is my total hot take. I just don't think anybody should be writing Next.js instead. I don't think anybody should be writing Rails instead. I think there's just more bang for your buck that's there. You'll have fewer servers.

Well, there's your answer then. It's just content creation. Why Elixir is better than Next.js? Why Elixir is better than Rails? Obviously these are two different things, but you get the point. And then you just create content and you grow the pool. You grow the pool of Elixirists and then your business grows. If you're fine with it growing a little bit slower, a little more tried and true and less, you know, vertical hockey stick, then you just work on the overall Elixir ecosystem. And as it goes, Oven goes. Right. Be the change you want to see out there. Right?

Yeah.

If you want the market to grow for, you know, the camp you want to hang out in and not ever write JavaScript again, like you said, then you've got to put some insurance in place. And the best insurance is your wisdom and directing folks to the right, to what you think is the way. Right.

You should do some, some, uh, business counseling, Adam. You've got some wisdom there.

We do it as a podcast. Yeah. Come on back. This is it, man.

This is it.

This is how we do it.

You're getting it.

Well, we, we get people on here sometimes, Jared, right? And we get, they leave pretty pumped. They're like, man, I love what I do now after talking to you too. Oh yeah. Well, you know, that's part of the game too. We're users of Oban, right? Like we, we've been users since way back in the day, I think is back in the days we can go when Jared was like, Hey, we need to deal with these background jobs and cues and stuff like that. We're, I think it was like email stuff was happening. And it wasn't even me.

It was Alex Kupmos who brought it in the first time.

Right. And I said, Hey, I don't, I haven't needed background job stuff like this before. And we needed it because I think there was a specific use case. So we had Alex doing some contract work for us. I think it was when we decided we wanted people to be able to edit comments for like three minutes or five minutes after you post it, just the typo fix. And so when you send a comment on one of our episodes, everybody who's on the episode and hasn't opted out or whoever you're replying to, they get email. So there's logic there about who gets notified. Our comment system is nice because it's not heavily used. And so each comment is pretty high signal and you want to hit, you want to know about it. There's very few, so you get the email, no big deal. However, we want to give the people the opportunity to fix the typos before we send that email. Put the comment content in the email notifications. You don't have to come back to the website. You can read what they said. Right. And I said, Alex, we want to be able to edit those comments just because typos, you know, we just want to be better than Twitter. This is back when Twitter didn't have comment or didn't have edit support. I'm like, we got to have edit support because we got to be better than Twitter. So he went ahead and was working on that. And what that required was basically a future scheduled background job. That when you create the comment for the first time, it's going to schedule the notification to go out in five minutes or three minutes or whatever the threshold is. And we couldn't get that done without Oban. I mean, we could have done it some other way, but he liked Oban. So he reached for Oban. And then I was like, well, now that it's in here, we might as well just use it for all the other things that I was just using processes for, you know, spawn or whatever it is. I can't remember the actual module name. I'm sure you know it, Parker.

Task? I'm pretty sure it's task.

Yeah, exactly.

I mean, you're still using task. You're just using task.

Yeah, I still use it.

Fast by other things.

Yeah, exactly. And so I was like, well, let's just put everything in the background jobs now that we have the library in here and we're already got the Postgres table set up. So we went through and I think you did a lot of that work, Parker, didn't you? You came in and opened up a pull request, which was like helping us use Oban better. And so that's another way to do adoption is just, you know, one open source repo at a time, go in there and open a PR.

There are a handful of really prominent open source Elixir applications. The changelog is one of them, but like plausible is another really big one in paper cups. And there are a few I'd like to mention they all use Oban, but in different ways. But any one of those should hopefully because people go there to learn how do I put these things together? What are the popular packages? It should be idiomatic. It should be kind of how you want them used.

Yeah, I think that was a really good use of your time. Go ahead and open up that pull request and making sure our use of it is idiomatic. Because while we do not use Phoenix idiomatically anymore, as I stated earlier, with context and whatnot and live view, we still have controllers in our code. I know those are out of fashion now in Phoenix land. Our use of Oban is idiomatic.

They're legal. You're allowed to do that still. It's fine.

Yeah. Like I said, our app still compiles and runs. So, but our Oban use is on point. So if you want an example Oban use, oh yeah.

You even you even got a bespoke feature added to web for your, your bizarro authentication scheme. Oh yeah.

Remind me what I requested and how that and why you built it for me.

I think it's something I know what the feature is. I don't know exactly why you guys were doing it. It's a way to have authentication that where it just redirects somewhere else. So like if you're not staff or not admin or something, you can't get in, but there are certain people that have access who aren't necessarily you. So you want them to have read only access. And I guess it was like three tiers of access is really,

yeah, it was just a case of, yeah, exactly. Whereas it was beyond simple kind of Boolean in or out, it was like three tiers and I can't remember the setup. I can look at the code and have my memory jogged, but it was basically slightly more complicated auth for the web for the web access and hopefully it wasn't too much of work for you.

Because it was months, months of work. It's all we did for months and you don't even remember.

I don't, I mean, I remember being happy when it landed and I cut over to it. I'm like, yeah, it works now. Cause I was doing something funky to work around it. I want to give you some praise that this PR was awesome because I think it showed us early. And I suppose even to now what your intentions were with the level of support and care for the software you were creating.

It's so dedicated. It's obscenely dedicated. Well, I don't know about obscene.

It's obscene. Well, I had to even email you. I recall I was like, so it's responsive. I was just like, I cannot believe that you did this. I think I'm going to read my email to some degree. I'll at least paraphrase some of it or literally quoted. I was like, first of all, like, how do you begin an email with first of all,

sounds like we're in trouble.

Oh, no. I'm not threatening you here. No, I'm not. I am thanking you. Okay. Thank you for that awesome PR. I went looking for your GitHub sponsor page. And after that PR and found the Obon site and web plus pro we'd love to support the development. And I think we supported for a bit and then we became pro users and something like that. And so I was, you know, I was like, I couldn't believe this, you know, that you had gone so deep on this PR and helped us in that way. Cause like, uh, like Jared said, we didn't know how to use your tech really. And you came in like, here's how you use my tech. And that's how we use your tech. And it's awesome.

You would think just writing how to use something, it would be a better approach, but sometimes, you know, sometimes words are hard.

It's easier to push links to docs doesn't always give the best. It's a personal touch. And I think that the world needs more of that, right? The personal touch. You get one of us. That's just the way that it lands, right? Cause there's no one else to get. It's going to be one of you guys.

Another ranty kind of thing, but I just, I wish there were a lot more independent shops out there. It doesn't have to just be two people, just, just a few people. There are some mega software companies. I just wish there were a few just cause the personality is great. It's like when you live in an area and you know, the people that own the restaurant or, you know, the people that own whatever the shop is and you have that rapport and you know exactly what you're going to get. And when there's something wrong, you just have a person to talk to.

And you made an, you made a difference, Adam. I remember where we were sitting when he opened your email, when you responded. Yeah. So this happens all the time where you write something, where you get an accolade or you get a response back from somebody or where you're working on something.

We remember where we're at all the time. People meld to these places. So you made an impression with him.

Saying thank you has got to be part of it too. You know, people don't say thank you often enough. They just sort of accept it and move along. I don't know if they're shy or just maybe they feel like they might be bothering some, I don't know what makes somebody not say thank you. But I was like, I was moved and I was like, I got to email these folks and tell them thank you. And at the time we were really trying to do a lot more with, and we still are of course, but at the time we were like more becoming more aware of like the tooling we were using, the dev tooling we were using and trying to give back on GitHub sponsors because that was becoming, you know, more and more of a thing to do. And we obviously wanted to support you all in your efforts with, with Obon. How do you feel about cron jobs? Do you like them? Do you hate them? Like how does, how does this kind of merge into your world? Cause I want to, I want to give a shout out to somebody that I love and they're pretty awesome, but they're in the cron world and I don't want to like ruffle your feathers if I don't have to.

Well, obviously we've got, we have cron as part of Obon and it's purposefully kind of bare bones. So you have a static cron tab that you set up and when your app starts, it'll, it'll go by that. It's got some, some niceties like the reboot keyword and some of the things like that. But then in pro we also have what is dynamic cron and that has some things like guaranteed scheduling. So if you were supposed to schedule something like at midnight and it's only once a month, but your server happened to restart or something happened, it will go back and identify that you missed that. It will also let you update cron tabs, retries and misses. Yeah, it'll let you update them at runtime or you can pause things. You can pause certain jobs and you can insert new ones. So we, we feel pretty strongly that cron's an important part of every production app we know of because we get a lot of config that people send us for like for diagnosing.

That's where it began for Jared too. He's like, I was using cron for these things and whatnot.

So yeah, but there's also the benefit that we, because it's Postgres backed, it's like it's centralized. And when, you know, anytime you have a set of two nodes, now you have a distributed system and either they have to have consensus or you have to centralize through something. And so we kind of get away with a lot because of that centralization part, but I'm, I'm curious who your cron friend is.

Well, yeah, I'll mention him, but I think I want to go on the note where you say you wish there were more, was the word you use small shops or small teams? How did you say it?

Independent, not, not, you know, but not faceless mega corporation kind of places.

I think they get kind of hidden.

Yeah.

And the reason why I'm going to say these folks is because they were kind of hidden to me until I had the problem. And so it's not in the application world, it's more at the Linux level world. So the app I'm going to mention is called Chronitor. Shane and his team, they're going to become a sponsor because I've been such a fan and I've been like hunting him down, telling him how I can help him. And like, just, I'm just like a super fan of Chronitor. So the website is chronitor.io and I use it heavily. And there's lots of folks in the home lab world that I think would use it more heavily because there's so many crontabs users out there. Like, and cron just fails. I mean, you can go read a log file, but that's kind of boring, right? You want it to go to an interface. It's a little easier and you want retries and grace periods and more sophisticated things, which is all part of the Chronitor platform that they have. And there's another name that comes to mind is Molehill. Now, Molehill was an early days Ruby shop. Jerry, you may remember this. They're from the Florida area. This is like 15 years ago. Well, you may know what they do now, which was they did some things in a nonprofit world helping applications out. But now their application is called Buzzsprout. And you may know that, Jerry, because they are deeply into podcasting. And that was where Founders Talk, I think, and the Web 2.0 show, the earlier podcast I had done. And I think the change was hosted there before we, did we move that from there? I'm pretty sure we did, Jerry, before it went to five by five and then from five by five to our application. So, I mean, Molehill was an early interface application development company, small shop, independent shop, however you want to frame it. Chronitor is very much the same. They have amazing revenue. They're like a few people, you know, like the CEOs doing support kind of thing, answering my emails and, you know, eventually sponsoring our podcast. I want to mention that because like I hunted them down. I'm not mentioning because they're a sponsor. Like I was so emphatically like, y'all are amazing. We've got to talk. And then over a period of probably eight months, we finally like pin something down to work together. And I'm just a fan of small teams like that. I agree. I think indie teams, and I wonder why, is it because of Cloud? Is it because of the behemoths out there? Do they just, you know, get overshadowed? What is it that makes indie teams not, I don't know even how to describe how they're not there? Like, or are they just hidden and they're hard to find? Because I didn't know about Chronitor for a while, but they've been in place for years, successful enterprise teams. Like, like they have, they're a small team with really big businesses using them.

I can hypothesize. I don't have any, it's all anecdotal, but I think safety's one part of it. You know, it's hard to be a contractor. It's really hard to start software from nothing. To bootstrap something is tricky. And the amount of time it takes, if you have a day job, to build something else for that safety to try to get to that place where you can actually run it without worrying about an income stream, takes a lot of dedication. And that's double work in some ways. And not everybody's up for that. But then also you get so many startups. And what's the goal of most startups? I mean, they're incubated in some way. They have people backing them. Therefore, those people want to pay out. And usually you have to grow to be able to get there or you're not, or you're letting down your investors. And if you let down the investors and you don't get to some sort of exit, then as a business, you're kind of a failure. Whereas if you're an indie mom and pop kind of place, or however you break it down, even if it's just a few employees, you don't have those. You just don't have that incentive, right? It's your lifestyle. So I don't know if people see lifestyle business as a detractor, but to me it sounds like the way I would hope more people could live. He's an evangelist.

You can speak to this, Jared, a little bit, right? You can speak to this, Jared, because you ran Object Lateral for multiple years as a solo dev. And you always seemed to me, I can probably suggest some ways I thought you felt and to some degree. But you always seem very confident in your ability to, and you were always very customer focused. I'm, you mentioned even recently, like, hey, I've had this responsibility with this friend of mine. I no longer do day to day work with them, but I had to help them spin it up. And it was, you were lamenting like how hard it was to get their stack back into place, basically, you know, but you've had as Object Lateral, you were an individual person. That was your full livelihood. You raised a family on it. Obviously, now we're, you know, you're working with Changelog and that's, you know, that's in your past. But like for a long time, you were just helping people and slaying apps and hiring contractors and getting the job done.

Yeah, I agree with all that. Was there, was there a question in there or something you want me to respond to?

No real question, more just like share your experience.

Share my experience. Yeah.

Well, on the idea of indie mom, pop, you know, the fear, you know, the lifestyle. And I think, you know, with Parker was hypothesizing was just essentially the fear of like not being able to have this big job with a big salary and whatever.

Yeah. Well, I think like that growth mentality is just.

Extend and pervasive on the internet, probably because of Silicon Valley, the ethos, not the TV show. Both.

Do you get a chime for that one? If it's just the name, every time, every single time I specified is just the ethos.

I did not reference a television show, so no chime. I said, there's a chime, there's a chime. I have a question. Do you feel that the lifestyle, mom and pop, what we do, we're in a bubble. So when we break out of this bubble and occasionally attend a conference or occasionally go to a meetup, do we drive people away from choosing us? Based on how intrinsically our lives are wrapped around our project. Are we driving them away? I don't like the way you're phrasing this question. You personally, just the two of you are just turning everybody off personally to the idea of just everybody's running. I don't think so. No, I think people will say lifestyle business. And when they say that it's a bit of a pejorative, like they're like, oh, it's a lifestyle business. Isn't that cute?

You know, like you're not, I don't think that's right. I'm saying I feel that term is perhaps detracting.

Right. Perhaps. I think we need to take it back. You know, we should take it back. But I think that what I did and what you guys are doing is slightly different, more than slightly. I think it's different because I was effectively a dev shop. I was a glorified freelancer. There's a lot of freelancers making livings on the internet, writing software on contract. Service companies like building software, whether as a service or products, you know, like open pro and selling them to customers, I think is a little bit of a different beast. And so I think there are a lot. There's a very vibrant freelance community and some people call themselves, you know, dev shops or contractors. Other people say they're freelance, just like some people are developers, other people are programmers. But I think that's alive and well. And I think there's more of that going on maybe than ever. But in terms of people starting small software companies in order to sell software, whether it's as a service or, you know, as a download or whatever it is, there's definitely a lot less of those that stay small or start small for that matter.

We have a few things going for us. We started later rather than earlier, which is great for us. We had already tried a few other endeavors.

I feel like that made a huge difference for us. I also feel like we stopped consulting. I realize that you have what they refer to as a day job, but that's really the only thing now aside from ObEN. We were consulting with about two clients each. So I think before COVID, we were, I would say we were pressed for, I mean, time beyond compare. Yeah, so we stopped consulting and taking on clients, and that was right before COVID really kicked off.

My mind jumped to a couple of things, too, because if you're running your own software shop or your own product, you have to wear so many different hats. I mean, there's the entrepreneurial spirit itself, and then it comes down to marketing and then having the technical chops to do that and then having the support side and then having the writing. There's just so many things you have to do that balancing all that is difficult by itself, especially if you're not bringing in a lot of other contractors. And I think the language you choose can make a difference as well. Some things, it's just it takes more time. It's harder to do something with a couple of senior people and some ecosystems compared to others.

Yeah, there's no one size fits all. I do think that maybe when it comes to products, software products, it may be that the successful ones, because of the marginal, because of the profit margins on software sales, which you all are enjoying, right? Like every marginal sale for you has not nowhere near as commensurate work on your side, right? You have support, but you could just sell them to the hills. And so when you start to actually get over that hump and the flywheel is rolling, well, it's hard to stay small at that point, because the other one I'm thinking of is, and they actually sell hardware, so it's slightly different, but it's similar is Thinxed with their canaries. We had Haroon Samir, Haroon Mir, you remember his last name, Haroon from Thinxed on the show last year talking about Canary, and they're relatively small and making really good money selling these software or these security devices into enterprises. They're like honeypots, basically, and they have a hardware aspect, which means that their margins aren't as good, but once their sales got rolling, they're making really good money. And he has to try hard to stay small because it's so easy to chase every opportunity when you have capital to spend, you know? And so maybe that's why people end up chasing larger growth is because, you know, once you've conquered the mountain, then you're like, well, wasn't there like an old saying about a guy who cried because he had no more mountains to conquer? Was it Alexander? I think it was Alexander.

Come on, Jared.

You guys know that one? I don't know that one, but I like the idea. I mean, I think that's...

Alexander as in the great or like the no good, very bad, terrible day or which Alexander? Not that one.

The great, of course. Anytime you leave off the second part, it has to be Alexander the Great. Who else could it possibly be? The terrible?

That's Ivan. You're thinking of Ivan.

No, that's Ivan the terrible, yeah.

Our growth has been stable. I feel great about it.

I really don't know what I would say other than our growth has been stable and I feel like our churn is kept relatively low. All of these things are great. When we go to balance our time, Parker is right, though. It will be Monday for writing, it's blogs, it's Tuesday. If something's on fire and we get a request, then that takes immediate priority. But we really do have to stay on top of... There's another book I read, what was like years ago, though, about the Pomodoro, like your small tasks all day long. It seems like we run these little box checkslists with each other. It is not uncommon for the two of us to sit right next to each other and not talk for three hours, which he's like, this is a lie. He's like, I never get three hours. He's like, I never get three full hours. Somebody always... One of us is talking. Yeah. Well, if we get an email from Adam or from Jared, then... You get to pause and read it and you high five each other. Do you guys have any sort of celebration routines? Like when a new sale comes in, you know, a lot of people have like some sort of a bell that goes off or a thing on the wall. Do you guys do high fives? Do you give each other a hug? Of course we do.

In the early days, we did. We would celebrate like with steak, especially if we got like an annual sale or something. But you can only eat so much steak. I mean, I'm sorry, I know there's a Texan available, but...

Which brings me back to my Alexander the Great quote. Here's my Alexander the Great quote, which is, you can only eat so much steak. This is... I don't think this is actually... I don't think he said that, but the quote is, when Alexander saw the breadth of his domain, he wept, for there were no more worlds to conquer. That was from Plutarch, I think, arguments about whether it was actually from Plutarch or whatever. But that's the idea. He needed a pair of binos. He needed some binoculars.

No, so he's, I'm going to back into this one. He's DHH in a way.

How so?

He's DHH, creates rails, conquers the world, right? Basecamp does amazingly well. Hey, he starts a racing career. He's Formula One. Does Le Mans. Everything that he attempts works perfectly. He conquers it and then he's bored. And then he laments like, well, this is, what am I going to do now? It's just, you keep conquering all the little mountains and you get there and then you're bored. And maybe I'm a lesser person and maybe a lot of us are lesser people. But no, I just redid a guide today and that guide, it's clearer and it helped these other people. And that's like a small win, but that's enough to just keep this constant forward momentum. So you're smoothing out the mountains instead of climbing a mountain, then finding a bigger mountain.

Right.

Just kind of constantly moving upward and finding some joy and peace in it.

Right.

The Zen. Sorry, DHH.

I'm over here thinking DHH is, you know, when he gets bored, he goes on Twitter and throws Molotov cocktails, you know, like he's bored. So he's going to go get into verbal spats with all of humanity. What an interesting person though, really. He is a caricature for our, I mean, innovative leader in a lot of cases, but also just like a unique individual. That's for dang Sherman. Right. If he's looking for any ideas, I feel costuming and learning to fly commercial airplanes is available. I think you should go that route. Both?

Costuming one or the other, but on maybe some, I think that's like Mitchell Hashimoto's territory flying small airplanes. That's what I was thinking.

Yeah. Yeah. Well, when you have the mills, you can do the thing. Yes. And you can get cars and drive them on. Let's just, you know, I think if Alexander the great had more hobbies, you know, like even available, you know, like Bill Burr, he flies a helicopter and I feel like if Alexander just had a, yeah. He's a trained helicopter pilot and he seems to have so much rage for flying a helicopter.

I don't, I don't know if I trust that.

I think he only flies by himself for the most part, but, um, that's what his hot, that's one of his hobbies. Like he does that to decompress. And I feel like if Alexander the great just had like a helicopter or yeah, a F1 car or something, a mountain bike, he wouldn't have cried so much.

It would've been such a crybaby.

Well, I can agree with that. I mean, gosh, I've been so at peace in my garage, just turning a wrench on my mountain bike lately. I've been doing some cool stuff and I'm just like, it's my happy place. You know, I put some music on, I jam for a couple hours by myself. No drinks, just, just turning a wrench. And it's good. It's analog, you know, it's not a computer, it's not a screen. You know, my son would come out and help me for a bit too.

The calm bomb.

Oh yeah, just calm bomb.

Just a little of that. Just the essentials. Is that Natty Ultra?

Love that everywhere.

The Natty Ultra calm bomb.

This is, it's 300 milligrams. It should be 600 to really take me to where I want to go.

Oh gosh.

Yeah. Well, we got to find our peace in our hobbies. That's for sure. I like your idea though. Flatten out the mountains though, because, uh, it's a good thing. That's a good thing. There is a lot of Zen to our life. There's a lot of balance. Sometimes I feel like.

I think our children are here. There's a lot of Zen to our life. When they listen to this, they're like, what are you talking about?

But from the chaos.

Yeah. You know, when it's chaotic enough, it just averages out.

Well, even with this pivot, you said earlier and this, uh, non-incumbent coming in, you know, making you think differently, big change. I said this before, Jared, big change brings big change. I like, we don't always know the ripple effect of a new decision, right? And if you like where you're at currently and you like your relationship and that's where it's at, I would fight to stay small and not small as in like, not, not grand vision, but, but small isn't like that. You're still in charge that you're still calling shots that you can maintain things that Jared and I, uh, established as rudders to our business has been slow and steady wins the race. That's a pretty common thing for, for folks to think about, but I don't think that slow and steady means you literally go slow. I think it means you can go as fast as you can while maintaining a version of control for where you're trying to go, that you're aware of where you're trying to go and you're going at a speed that is comfortable. That might be a hundred miles an hour, right? It doesn't have to be necessarily slow. It's more like slow and steady. So it's the two together. It's a pairing. The other one is if we get sort of over our skis and we're sort of like rethinking like, Oh my gosh, you know, this is a little out of whack or this things are off kilter, slow down. And check yourself, like, what are you optimizing for those three things? Like, what are you optimizing for slow and steady, slow down and check yourself have been like lifesavers in my personal life and in the business Jared and I run together and I can imagine he probably feels the same because he does say so. So take that, uh, as you'd like and apply it as you'd like, cause that's helped us.

Yeah. I think you get great ideas in the spur of the moment, but anytime you just take that, manifest it and then push it on the world, you, it wasn't quite there. Like you just have to take a step back and look at something like in art school you're taught when you're drawing or you're painting, take a step, 10 feet back, look at it again, and then come back in and rework it because until you take some time away, you're just not going to see everything perspective.

That's what that's about.

You need, you need time for perspective. You can't borrow it. Nobody can give it to you. You, you have to build it and grow it.

Adam, I think you said that emotional response you have, that's not always the one you want to lead with. That's not the one you make the decision with. It's important to acknowledge it, have that conversation and even have it too. Like I love my, I mean, I've written some messages that I did not send. Okay. But it felt good to write the message.

Is that what we got? No, he did send it.

In reference to us discussing that pivot or not, we've ran the tracks on a lot of different versions of which way we could go and emotionally really hearing each other, I can think of a house we went and looked at when we were first buying homes when we were home shopping and Parker turned to me the minute, I mean, we'd already put an offer on this house and it was during the home inspection. Right. And he turns to me and he's like, I don't want this house. I don't want this house. He's like, I don't want this house. This house will cause us to fight.

I can't stand in the shower. I can't stand in the basement. He turned to me and he just had this instant tirade.

It's too small. Are you a tall guy or what do you mean you can't stand in the shower?

I'm not that tall.

He's a behemoth.

I'm not that tall. I'm not tall. I'm over six feet tall. I'm six foot two.

Okay. But you have to hunch down in the shower?

That was a submarine shower. I don't know what's going on with this thing.

It was, it was like an 1860 farmhouse and a commuter, a commuter town outside of Chicago. So in a wraparound porch, I'm not saying this was the dream house, but we had agreed on it and we're looking through the house and the inspection is taking place and I think we're just kind of wandering around to kill time and he turns to me and has this, I mean, a very emotional response about I do not want this house. I do not want what will come with this house. I think it's going to cause fights. I don't like that. And I just said, okay, well, we're out.

I don't remember talking like I was in a Dr. Seuss book, but I think the sentiment's dead.

He did. He said it all. I do not like it, Sam. I am. I do not. I do. It was a, it was a con list, bullet pointed verbally.

Wow.

Did you buy the house? No, we left. Contacted the attorney and pulled it out. Have you guys ever seen The Wedding Singer?

Yeah, absolutely.

Remember how his bride doesn't show up for the wedding?

That's right. Yeah.

And then she comes to him the next day and she's like, sorry. That would have been useful. Yeah. She's like, sorry, I just couldn't marry you.

Once again, things that could have been brought to my attention yesterday.

Yeah. I'm just imagining Shannon yelling that to Parker when he's like, I don't want this house, like I appreciate the decisiveness for there and just put it out there before you make the big mistake. But yeah, didn't you notice that during the walkthrough Parker? I mean, come on, you couldn't fit in the shower the previous day too.

Did I try to get in the shower the previous day? I don't know.

Try to go more, place no blame.

No, sometimes you do something.

Let's just get out of this situation. It's a dumpster fire now. I was like, oh, this is a dumpster fire. So the first part, I just called the attorney and said, yeah, we got to get out of this. You got to get us out of this. He says, no.

You do things with a partner, whether that's a spouse or business partner or friend that, you know, maybe it doesn't seem like your idea, but it might work. It might grow on you. And, uh, maybe that's not always a good, you don't have that fight or flight. You don't have the flight part. You just know that maybe it'll work.

So it's important to listen to the bullet point con lists when somebody decides to give you an honest read like that and not emotionally. So I feel like we've had a lot of that back and forth on whether or not to pivot. And to get to that point of being able to really listen of, like Adam said, like, look, if you value this, if this is where your values are, if this is what you're working towards, recognize that that's at stake. I hear you. I hear you a wise one. Big change brings big change. That's so ominous. You're scared.

You need, it's too calm now. It's too calm.

Can I explain it a little bit?

Like, this is, oh, I think we understand, we understand it.

I want to explain it. I'm sorry. I have to, regardless of your answer, I'm explaining it. Just one second. Bear with me. Sometimes we make choices in our life and they are big changes and we think we're just making that one big change. And this is coming from my own perspective. So this is like school of hard knocks, bloody knuckles situation. And you think you're okay. I you've, you've risk factored that single one big change. And maybe you consider a couple of ripples, right? But sometimes that big change brings other big change that you did not de-risk. And that's where my perspective is with that. It's like sometimes big change brings big change because you've thought through the one thing, but have you thought through all the permutations? Now we can't do that, but everyone knows what a version of big change is in their life and apply it accordingly. Big change can bring big change.

So beware of the contagion.

Yeah. I mean, there's, there's ripple effects for sure. You know, the one big change you're considering and saying yes to isn't the only big change possibility as a result of the yes. And likewise, the no.

I feel like that's potentially crippling advice though. I mean, it's just ominous. You're like, don't make a big decision because it's going to cause other big ripple effects.

I didn't say don't. I just said big change brings big change. Prepare. Like, you know, take a, take a towel.

Is that not a warning?

It's a warning to consider your big changes. Yeah. I think it is a, it's a, I don't consider it a warning. It's more like a red flag. Like, I guess that's the warning. I don't know. I'm just, it's like a negative warning. It's just more like, Hey, if you're making a big change, consider there's other big change you haven't considered. And don't go in with like zero margin. Have some margin. When you go into a room, plan your exit or consider that you might need to exit.

Or when you go to buy a house, consider an exit, you know?

Yeah. I mean, I think that's just how I operate. At least I try to. And I get really upset when I give advice and I don't always take my own advice. And I'm like, Adam, you knew better. What is wrong with you? And then I podcast about it. That's how it works.

Oh, not taking your own advice is the life of, it's the worst, man.

Yeah.

I mean, senior developer.

Yeah, it's the worst. It's the worst when your own advice slaps you in the face. Like you knew better. Come on. But that's it. Big change brings big change. Well, we are excited for you too. We are excited to see what comes next. What big change your next big change is going to bring. I'm looking forward to some new Elixir content, some hot takes from both of you. Some widening of the Elixir ecosystem. I would love to, for you to put on paper or perhaps on video, like how ObEN is a killer app that should make you pick Elixir. Exercise that thought all the way to its logical conclusion and make that argument. I'd certainly read that. I would certainly share that around. I'm interested in that. And, um, congrats on all the success. I mean, you've doubled your freedom number and you're still rocking and rolling.

I just don't believe it will ever lead to a retirement. And that's great because that means we have options and it, the freedom is there.

It's just the freedom to choose.

The reason that people retire and then they end up going, getting another job is that they have no more mountains to conquer. You just got to keep it, keep it going.

That's right. And it always goes back to Alexander the Great. So this is what Paul Vixie said to us last week. I asked him because Paul Vixie has conquered many mountains. So he's a internet hall of Famer, instrumental in the DNS protocol, et cetera. He wrote bind. Actually Vixie's cron is still the cron that runs in most Linuxes today. Like his implementation of cron is still there. So he's been in the business, you know, 40 years, 60 years old, working at AWS at some high level. And I asked him why he hasn't retired yet. And he said, what I learned about myself, because he had an opportunity to kind of call it quits, he sold another business a few years ago, and he said, what I realized is if I didn't have a reason to get out of bed, I'm not going to get out of bed. And he learned that about himself. And so he said, so I went back to work. Now I have colleagues and I have projects and I have trips to take and stuff to do. And I'm just a happier person with a job than I was with that one. So not that he's every person. Some people can retire and find all kinds of stuff to do for themselves that are not money producing, but I think we do need to have a purpose and a reason to get out of bed in the morning. Otherwise we just kind of waste away. And, and I mean, heck, some people die young because they retire young. So that sucks.

I've got to make something or fix something or the day's just not complete.

So I hear him on that. Physical or digital?

Well, I'll answer your call. Content is coming. And we have a talk at ElixirConf EU in Lisbon, which is about scaling applications. And we have an application that we're building to push the boundaries of what's kind of possible for job processing. And that'll be part of that talk, too. So we're working on it.

We'll see if we can get in the how open is a killer app for Elixir hot take. I love it.

Before ElixirConf EU.

There you go. When you write that or record that or whatever it turns out being as media, let us know.

It's been fun. Bye friends.

Bye. Changelog++ listeners, stick around for a wild bonus segment where Adam suggests they take their elixirs better than X content series on the road. I accidentally offend Shannon, then recover gracefully with Parker's help. And Shannon makes a confession about their past that includes chickens, a sauna, and the Changelog podcast.

What, what, what?

Of course, if you don't directly support our work with your hard earned cash, join hundreds of your fellow Changelog listeners who do by signing up today at changelog.com++. As a thank you, we hook you up with an ad free feed, include bonuses like this one at the end of many episodes, send you some free stickers for your laptop and more. It's better. That's what people are saying.

It is better. It's been better for years.

Thanks again to our partners at Fly.io. To Brakemaster Cylinder for the continuous flow of fresh beats for us and our friends. And to Sentry, save a hundred bucks on their team plan by using code CHANGELOG when you sign up. Next week on the Changelog, news on Monday, Chris Moore from True NAS on Wednesday, and the much anticipated return of Cameron Say, yes, THE Cameron Say on Friday. Have a great weekend. Hook us up with a five star review if you dig it and let's talk again real soon.