Hi, you're listening to the Self-HostCast, a podcast dedicated to all things self-hosted. Today we're sitting down for an interview with Hayden Kodelman, the developer behind the popular open source projects Melee and Homebox. Thanks for listening. Hey everyone, and welcome to the Self-HostCast. I'm your host, Ethan Schaale, and today I'm joined by Hayden Kodelman, the developer of the popular self-hosted applications Melee and Homebox. Hayden, thanks so much for joining me today.
Yeah, happy to be here. I'm really excited to talk about some of the projects you have cooking up. Melee, for those of you who don't know, is a recipe manager slash grocery list management application and Homebox, which is a personal favorite of mine, is a home inventory application that allows users to track various data points and information about their assets.
But before we dive into either of those, I'd love to give you a chance to share a little bit about yourself and your background and maybe give the community a chance to get to know a little bit more about you. Yeah, so I've been a software developer professionally for about, I think I'm like three years now I've been a software developer, and I've been writing software for maybe like five years ish. I grew up kind of in Alaska and I just recently moved into the Minneapolis area.
That's been super fun. So when you talk about your software development background, do you have an education software development or is this something you picked up on your own over time? Yeah, so I went to college for about two years. I was originally planning to get a degree in history. That did not work out too well.
There's not a ton of jobs in history and it happened to coincide with some other family transitions my parents were leaving state so I had to like get a real job and move out and be on my own. So the timing didn't quite work out as well as I'd hoped to finish the degree so I ended up dropping out after two years and getting a job and building maintenance and doing that work for a while.
And then I eventually kind of transitioned into building automation work and then through that I kind of taught myself programming. So I'm actually working at the same company I did the building automation stuff with doing software development, just climbing up the ladder as you will. Wow, that's incredible.
So you're mostly self-taught when I think about or when I look at the technical details behind your software and the things you provide, all of that you've picked up in your own time as a hobby? Yeah, absolutely. I'm a little obsessive with reading books and watching courses and all kinds of stuff like that. So I spend a ridiculous amount of my time looking at a computer and reading books about computers. I do want to go back. So you mentioned you originally had studied history.
That's interesting. Was that with the goal of maybe teaching it at some point or maybe going in a different direction with research of some sort? No, I think I kind of originally wanted to be a teacher. Like a high school teacher in history, my history teacher in high school was really impactful for me and he was a really great guy. And I know I just admired him a lot. So it was kind of like, I could do that. You know, that'd be nice.
Yeah. So have you ever felt that way about computer science and the programming chops you've developed over time? Do you think one day you may find yourself teaching or passing that knowledge on in some way? Maybe. I think software development is kind of weird because you're always learning and teaching people. Like just today, I was in a call for like two hours walking this guy through some code that I had written. So there's always a little bit of that.
And maybe that's why I like working in a team is there's always like somebody doesn't know how to do something and you know how to do it. So you jump on a call and you kind of walk them through the process and they can kind of pick up a little bit too. So it's a nice little mix of that as well, the teaching stuff. And what's interesting to me is that you do it full time as your full time job, but you also spend a lot of your time outside of work programming.
So you must either really enjoy it or you're just a bit of a masochist. It's probably a little bit of both. Yeah. So like, I mean, there's two like main projects that I have that people would probably know me for is Homebox and Melee. But if you look at my GitHub, there's like, like seven other projects that I've just like, you know, spat out as things that I like that I use and I enjoy. But it's like a lot of code. So like, I'm writing code like literally all the time. It's probably not good.
I should probably get some more hobbies, but I really like it. It's interesting. I was trying to prep earlier a bit for this recording and I was just looking through your GitHub pages and I noticed on one of the projects and this was maybe a couple of hours ago. So it's, you know, we're recording this on a Friday evening. I'm assuming we both work at our full time jobs today.
And as I was browsing your GitHub, I noticed the most recent action on one of them was you had committed a change within the last hour or so. And I think to me that just kind of speaks to probably how much time you spend dedicated to these projects. Yeah. It's a little unhealthy. It's good though. Yeah. It's good for the self-hosted community and people like myself. So I'm not complaining, but I do hope maybe you can find some sort of balance in there, healthy balance, and I'm sure you can.
But can you talk a little bit about what inspired Melee and Homebox and even some of these other projects you might've mentioned that you referenced with your GitHub pages? It's interesting when I think about the needs of the self-hosted community, occasionally I'll see people asking, what's your most desired piece of software that you wish someone would develop and inevitably there are always dozens of answers. And as I scroll through, I'm always thinking, hey, most of these are really good.
I wouldn't know how to choose what to develop. And then I think my other problem would be once I pick something, I would struggle sticking with that for a long time. I feel like I have a little bit of ADHD when it comes to my self-hosted interests. So I guess that was kind of a multi-part question. How did you decide what to go with and how do you maintain and then persevere working on sticking to those and seeing them through?
I think the important part is finding something that you care about and that you are going to use is a huge thing, especially if it's open source and it's free and you're not making money from it. With Melee, before I did building automation stuff and software, I worked at a catering company and I did a lot of baking and cooking and it's just kind of a thing I like to do.
So having a place to put all those recipes was something I always wanted and I never really like... I do this thing that I'm sure a lot of self-hosting people do is like, I need this. Well, I'll just make it myself. Not even just thinking about like, oh, there's somebody who probably already made this or it already exists or I can Google recipe manager and see what's already there. No, didn't do any of that. Just straight to making it.
And it was right around the time I was doing software development or learning software development. So it was actually like the first project I ever built and became the most successful project I've ever released. It shows if you go through the GitHub history, you can see all of the weird things that I started with and what it's turned into. But the reason I think I really stuck with it is because I picked something that I wanted to use.
So I wasn't just building something like for the community, I was building something for myself and it also happened to benefit the community. Because you're going to stick with something like that. Like you got to find something that you care about. Is there, when you think about some of these projects, is there ever an end game? Or do you think it's the development site will always just be a work in progress? There always be new features that you haven't gotten around to?
I think there's like two answers to this question. One of them is like all software dies, right? Like everything dies eventually, except maybe Windows that may live forever. But you know, anything in the self-hosted community, I kind of think about it just like it's temporary in a way. I was like, nobody's going to have time to work on it forever. So that's one thing that I think about a lot is that one day I'm just going to stop working on it and that's going to be the end of it.
But the cool thing is, is that it's a community project and recently in Melee, we've been inching towards a V1 release, which is like the stable release that I've been promising for two years. Finally going to do it, I promise. And the last post I made was for the, I think the RC1, so the release candidate for the version one. So we're getting really close. And I kind of told everybody like, I don't use any of the new stuff that we're building.
I'm not super interested in like where the project is going anymore. It's not as interesting to me of like all these features that people want. It's just not, my heart's not in it anymore. And there's not money there to be made for me. So I have this other project that I'm working on called Recipient, which is kind of like the next evolution I think of what that is.
And we can talk more about that later, but I kind of threw that in there of like, this is the next thing that I'm working on and that I had a call on there for other maintainers. And at that point we had one other guy who was helping me maintain. He was doing a super great job. He's like really into the shopping list features. And after that post we got, I think two more maintainers to come online.
And that gave me a lot of space and just made me super comfortable about like having the space and like, see it was really nice to have them get more maintainers to come on board and then I could kind of take a step back and be more of like an advisor or like, oh, there's like a critical hot fix or something. And I can step in and have like, I have, I think probably the biggest brain of the code. You know, I know where all the nooks and crannies are.
It's easy for somebody to say like, this is broken and I could be like, oh yeah, it's probably this thing right here. Sorry. But that's been great. And I think that like, that's how the project lives on, you know, it's not going to live on forever. Nothing does, but when people step up and they contribute and they offer to help, like that's how it continues after I run out of steam. Do you see that same level of community interaction with Homebox as well? I haven't seen that yet.
I think it's, it's kind of a different product or piece of software. Neely is written in Python, which I think a lot of people know. It's just like a really easy programming language to pick up. It's often the first language you'll learn. Homebox is written in Go, which is a compiled statically linked language, a little more complicated, not one of like the super popular languages. It's definitely below JavaScript and Python and some of those other ones.
So I think there's a little less interest there and it's also maybe a little bit harder to set up. Homebox and Melee are different to me in that Homebox is like a much smaller scope. It's the second project. So I had like a little bit more like experience in open source and like thinking about how those things work. So I had like a really good idea of what I wanted. Like I wanted something small. I wanted to do these few things and that's it.
Like I didn't really want to build like a huge community and like get all these people in and then end up with just like some version of the snipe it or snipe IT software. That's more complicated version of Homebox is kind of how I would describe it. It's very complicated. It's very sophisticated. You can do all kinds of cool stuff with it, but it's not what I wanted. Right. I just wanted to like spin up this little thing and put my stuff in there. Right.
So from the perspective of myself as someone who doesn't have the technical or programming experience that you do, why did you choose different programming languages for the two applications?
Because I feel like when I look at them and then I don't want to oversimplify it, but they're both two web applications that take inputs from users and then do something with that input, whether it's reported in the form of recipes that people can then interact with or Homebox or inputting information about your, I'm going to say assets, but really whatever you want to track within your home that you're again later digesting in different views on the application.
So from a developer mindset, why the difference or contrast between the two of those on the back end? The short answer is it's just whatever I've wanted to do it in. I don't know that I have a super good reason, but what I've come to learn from maintaining Melee is that I don't think Python is a good language to build complicated things. At least for me, Python is a dynamically typed language, which means you can kind of just pass anything around as anything.
There's not a lot of like, there's no compilation steps. So there's no compiler that will like step in and be like, no, you probably shouldn't do that. That's not going to work. And the, the, it's a much older language. So that's been around like, I think twice as long as go, but there's a lot of like legacy and baggage, the packaging ecosystem, if you want to publish an app is like very complicated. I still don't know how to publish a Python package.
And there's just like a lot of dependencies required to build things. Like you can't just build a web app. You have to like pick a framework to build the web app in and stuff. So there's, there's like a lot of those things that make it kind of difficult. There's also a lot of runtime dependencies. So we just had an issue this morning, actually with the LDAP library for authentication. The library we were using got upgraded.
I think, I think this is what happened is it got upgraded and it required a new binary to be installed in the container. And that did not happen to get installed in the runtime or when the Docker build finished. So there's a lot of angry, angry people who installed it and it crashed, but we got it resolved now.
So, but like, there's like weird things like that, that'll happen in Python in my experiences that just like random things will break and it won't be like super clear or very easy to find. Now my experience with Go has been kind of the opposite. Like their packaging system I think is really good. I came on after the Go modules stuff was all figured out. It's been a super easy breeze for me. It's statically compiled. So there's a compilation step and it links all the things together.
So you get a single binary output and it also does like good type checking. So if I try to pass a dog as a cat, it says, no, you can't do that, man. Gotta figure something else out. So I really liked that step. It's like a little extra piece that just makes me a better developer, I think. And the build steps and the publishing the app is just so easy. You just build a binary, you put it in a container and you're done.
Do any of the tools you leverage when you're building Melee and Homebox and any of your other projects, are they ever inspired by the tools you use in your full-time job? No. I work for a very big industry company. So it's Johnson Controls. We invented the thermostat is how I try to explain it to people. So we've been around for a very long time. We're very good at building automation stuff, but it's a big company. And with that comes legacy software.
So we are not up to speed on the latest development practices or the bleeding edge, but it all works and it's great. But I don't take a lot of that stuff home, I think. I like to play with the new cutting edge stuff.
I think what I find really fascinating is when I think about, or at least what I imagine at your full-time job, when I think about a development team who's working on a large project or a product that thousands or hundreds of other companies or whoever might use or consumers, you've got departments dedicated to almost every leg of the journey to get that product to production. You don't have that or you're managing that yourself for Melee and Homebox.
So where I'm really interested to hear how you manage packaging everything yourself. And I guess what I mean by that is when I search for either, the first thing I'll come across is a GitHub page with a really robust read me section that walks everyone through installation and kind of the basic questions with also various tabs like issues where you're working with people addressing concerns and issues or problems they have with the software.
While you're managing that, while you're also developing the software, while you're developing the front end or interface for the software, which I think is probably a whole other question in itself. And then you also have websites for each of the applications as well. So there's a kind of a landing page with screenshots and features and they seem to be up to date with new features.
So clearly it's not just something you shoved out there and you just don't touch all of these things interact with each other. And you're essentially providing a full fledged, a fully packaged product for free on your own time. And so honestly, after saying all that, I'm not even sure. I feel like I have 10 questions within that statement there. Do you enjoy the aspect of managing all of those things or do you favor certain things over other?
Are there certain things that you think about and just dread like, Hey, I just updated Melee and this functionality changed. I hate that I'm going to have to go back through the documentation and take more screenshots and outline what the new steps are. I'd rather spend that time actually developing any preferences in that regard. Yeah, so I like updating documentation, but I think I write documentation for developers. I don't write documentation for people.
So I get a lot of comments of like, this doesn't make any sense. I'm like, yeah, it probably not. So a lot of the documentation I think is a good community effort. I'll throw something out there and then a lot of people will come back and clean things up for me, especially spelling mistakes. I make them all the time. So if you're looking for an easy PR, come to one of my repositories and fix some spelling mistakes. There are many. Yeah. So the documentation, keeping the screenshots up.
I think I've kind of given up on that in a lot of ways. Like it's just too hard to maintain like cutting edge documentation. It's one thing to like list out the general ideas and like, you know, here's some of the features we'll play with it. That's the best I can really do at this point. I think, I think my setup documentation for Melee is very good. I think I spent a lot of time walking through like the step by step and trying to get good and instructive documentation for that.
We even updated the app recently to be a lot of the like half, not half, but there was a lot of discord comments of like, what's the default username and password? And we'd always link them back to the docs. But we've recently improved that where like when you first start up the app, it'll just tell you in the pop-up like, hey, here's the credentials log right in. So I think that like that's the super important part.
And that's what I've spent the most time on, but most of the other documentation I wouldn't even know if it was up to date to be honest. Yeah. And actually talking through that, I think brings up another question that I'm interested in hearing your response to. Are you ever apprehensive about receiving help from the community? I would imagine if you're passionate about a lot of these projects, you know, they are your babies for lack of a better term.
And so are you worried about someone maybe contributing in a way that's not helpful or detrimental to the project? Or are you ever concerned about sloppy translations or documentation from community members, especially when it's attached to projects that are attached to your name? Yes, I've gotten a lot thicker skin over the years. So I worry about it less now than I used to. But we have like a pretty good review process through GitHub.
So everything kind of goes through somebody on the team looks at it before it gets merged, which is really awful. But you do bring up a good point of like, am I worried about people submitting code to it? And it's the truth is like all the time. I don't, if you look through the feature requests on both projects, you'll see you're like people requesting these like big, not outlandish, but just like really big features that sound simple. Like, oh, I just want to do this thing.
And it's like, oh, that's like four months of development. Or like, yeah, give me a team of three people. We could have that done in a year. Stuff like that. If we're like, it sounds really simple, because I know like all the little knobs and things I need to turn and like what UI elements I need to build and all this stuff. It becomes like one thing, little thing becomes like a giant thing.
So I'll see oftentimes, people will come in and do what a lot of people will call like a drive by commit or a drive by PR. They'll come to the project, you know, maybe they use it all the time, but they come in and they like do this like big thing. They just like throw a bunch of code at the wall and are like, here, I got this new feature submitted a PR. And then I have to go look at it and be like, yeah, sorry, man, I can't merge this. Like there's no tests. There's no end to end test coverage.
This is a huge PR to be your first PR. Like are you going to maintain any of this? I don't really know how a lot of it works, you know, like some of these features are really complicated and rely on like a bunch of different parts of the app. So like just to come in and like put all this together and then kind of walk away becomes really hard.
I think it's like that's like a lesson that I learned for sure by just like trial and error is it's like the greatest thing in the world when you start a project and people are just submitting all these like huge PRs and it's like, that's awesome. That's code I didn't have to write. After like three or four years it's like becomes like, it's scary now people submit the PRs it's like, oh, I don't want to maintain that.
But this is if anybody was thinking about starting a new project, I would really think early about like bringing other people in because you need help. You can't do it by yourself. Yeah. Interesting. And I feel like in a way it's almost a lose lose situation for you because you want these to be community driven projects. So they have the staying power they're being worked on when you don't have the time.
But you also want to be a little selective with who's contributing and how they're contributing in a way that you can maintain some sort of control or level of, you don't want to scare people away. Yeah. You want to, you want to be receptive to people because like they are taking time out of their day and like, you know, maintainers are grumpy. I understand. I've responded to many a GitHub issue very grumpily that I regret.
And like they're taking time out of their day to like think about the problem, outline the problem and say, hey, like I think it would be good if this was implemented in here. I think people would use it. Sometimes they're right and sometimes they're wrong. Yeah. You know, you said something just a minute ago that prompted me to think of an interaction you and I have had in the past that I debated whether or not I was going to bring up with you on this.
The only reason I debated about it is because it's embarrassing for me, but I'm going to talk about it anyway. It's not me. Yeah. When you announced Homebox, I remember on the self-hosted subreddit on Reddit, I installed it, I started using it. I loved it. And this was maybe a couple months after I had discovered object storage. And so I had installed Minio on one of my servers. I was using it to host assets for some other self-hosted projects.
I was like, hey, I'm uploading all these manuals and images to Homebox. It'd be cool if it supported object storage. And so in the comments on Reddit, and I actually went back today through my profile. I found it to confirm that it was actually a Homebox and I had asked. And so in the comments, I was just very cordially saying, hey, this is great. Thanks for developing it. Would you ever consider object storage? And you were very gracious about it.
You were essentially, no, you had no plans for it. And I think looking back at that, I think a month or two later, I stopped using object storage because something broke and I was too discouraged to fix it. And I couldn't figure out what was happening. And I was like, oh, I'm just going to scrap all of this. And looking back at that and thinking, oh, I had asked you and not really understanding the work that probably would have needed to go into it to get it working within Homebox.
I feel a little silly for sure. That's such a hard thing to know, right? Is the thing I'm asking good? I don't know. I'm just going to ask them. That's fine. Realistically, I shouldn't be upset or grumpy about it. Sometimes it's hard to get the same issue four times and be like, if you just look at the issues, there's a duplicate and you just would have known. But we're all just people on the internet. It's fine. I can just close the issue and move on. It's not a big deal.
Sure. Sometimes I'm grumpy. Sometimes I'm not. I feel like this is another tricky thing you probably run into with Melee and Homebox. And maybe, maybe not, but I feel like probably it's a little exclusive to open source self-hosted software.
The idea that you are developing an application for a specific purpose, but because of the self-hosted nature and how other projects play with each other, I feel like there's this expectation or this bar that people expect self-hosted applications to meet in order to satisfy whatever requirements people have come up with. So for instance, if I see a new project announced, I'm normally usually include things in a newsletter and I try and spotlight new things.
So I'm always digging through GitHub pages and release announcements, just combing through comments to see what people are saying. And everyone always wants the full package when people release software. And by that, I mean, hey, do you support single sign-on? Can I use Authentic or Othelia or Keycloak to log into this? Oh, you use a SQLite database. Can you support MySQL or Postgres or something like that instead?
I think people are just so spoiled by so many mature self-hosted projects coming pre-packaged to play nicely with all these other things people have deployed that's become somewhat of an expectation. And I wonder if that detracts from the actual development of some tools because developers might be a little hyper-focused on meeting some of these other needs that in reality probably have little to do with the actual functionality of the software. 100%.
I think that the self-hosted community is very strange. If you go on the subreddit, people will ask, I think Homebox specifically gets this, where people ask for things. I guess Melee too gets this, it's very similar for class. So people will ask for this, and I know they won't use it. I know nobody is doing this. For Melee, they'll ask, hey, it would be really cool if I could scan food and keep an inventory of food in my house.
And then when I make a recipe, it just takes it out of the inventory. It's like, great. Good luck. You'll do it for a week and then you won't ever use it again. Yeah, that sounds awful. I can't imagine anybody maintaining that. If you are and you're listening to this podcast, good for you, man. I could never be that organized ever in my entire life. That's insane. I feel like if someone had the willpower to actually do that, they're probably a fringe case anyway.
Not that they don't deserve it, but you would question if the development efforts going into that are actually worth it or not. Yeah. I've been reading this book, the SaaS Playbook. It's mostly about building a startup and scaling to millions of dollars a year, the dream for everyone. But there's a lot of good ideas on building applications and listening to customer feedback. I remember reading through the book and thinking, oh, this is the complete opposite of everything I did with Melee.
The complete opposite. I took every suggestion or every feature and just built it into that. I was like, yeah, this is awesome. This is great. People want it. Let's put it in there. Let's do it. If you looked at the first 100 or 200 feature requests for Melee and then you compared them to Homebox, it'd be a very different story. I will just close issues left and right on Homebox for feature requests. They're asking for something to be like, yeah, no, that's not in the scope of this.
You should check out these other projects. I think that's healthy. It can't be everything or it's going to suck. It's just going to be kind of crappy for everything. Or we could do this one niche thing that I like and I could do that really well. I think that's better. We need more of that. One of the things I want to make sure we talk about a little bit is do you find it difficult to design the front end of your applications?
When I think about software development and then we talked a little bit earlier about how they're usually, when a product is developed, there are teams who manage every part. I feel like there are all sorts of jokes and memes on the internet about how a backend programmer thinks versus how a front end designer or graphic designer thinks. You enjoy both sides of the coin or has it been painful to learn one versus the other? What's your experience been with that?
In a perfect world, I would write a JSON API and everybody would just use that and they would be happy with it. What do you need a UI for? Write a curl request. It'll be fine. You'll figure it out. But people want a web app. I don't mind writing the web app stuff or building the front ends or things like that, especially when it comes to the actually like the code in the background, not like the HTML and making it look nice. That stuff I'm really bad at.
But the code of managing requests and doing requests and managing state and stuff like that, that's not as big of a problem for me. JavaScript is not my favorite language, but I suffer through it for the community. For the design portion of it, I like to think that both Melee and Homebox are fairly well designed programs. That is mostly not by my doing. I was very lucky and married a very smart and capable designer who's also a front end developer now.
I will make some strange looking UI and I will show it to her and she will be like, no. She'll tell me how to fix it, which is super helpful. She's taught me a lot about color composition and UI layouts and how to use whitespace. And, you know, thinking about user patterns, like where does this stuff belong? And all those like fancy UI ideas that just stick in my head for like a day and then they're gone. I feel like maybe you're cheating a little bit. 100%.
I am a sucker for well designed applications. As I mentioned, I love Homebox and one of those boxes that it ticks for me is that I think it's really well designed and it's intuitive and I love using it. I can very quickly navigate to what I want to do. I can perform the action and I can get out with no issue. There are self-hosted applications that I install and deploy because I love how much they look and almost never use them.
There's a Doodle poll alternative called Rally and it's Rally with three L's and I've never used Doodle in my life. And I saw someone had featured it at some point and I was like, wow, that is a very beautifully designed self-hosted application. And so I spun it up and I think I've used it twice in maybe a year because I don't organize events that often. But I think a lot of people stick kind of like the front end design. They don't prioritize it.
And I understand when you think about functionality versus design, but I do think design is important when it comes to adoption and encouraging users to adopt a user application. So I'm glad to hear you have a process for managing that. And I do think Melee and Homebox both look great and are easy to use from that aspect. Thanks. That's great to hear.
Yeah. It's one of the things that I think a lot of people don't necessarily think about or spend the time on, especially if you're a backend developer like me and you build something and you're like, oh, I got to build a front end for it. You maybe don't spend as much time on that as you do with like, what should the API be? How should I lay out the database tables? That stuff's more fun for you than doing all the stuff in the UI.
So it's taking the time and spending a couple hours and watching some courses on UI design and just get the basics of how do I lay out a title, a paragraph, and an image that makes sense. Getting that basics will just help you get so far. And then you can lean on libraries. We use daisy UI in Homebox and that does a lot of the stuff for you. You get a button, you get a card, and then a lot of it just comes down to layout. So if you can learn to do the layout stuff, that'll be super far. Got it.
Does your Bounce also design the logos for you? Because I feel like in the few instances of my life where I've ever had to design a logo, I've spent a disproportionate amount of time trying to design that logo versus actually generating content for what that logo was representing. Yeah, it's like the blog problem of like, oh, I need to create a blog, so I'm going to write a blog engine and I'm never going to blog on it. Is that kind of thing?
Yeah. Yeah. So she designed the box for Homebox, like the little logo, which I love. I think it's like super great. It's super cute what she did with it. The Miele logo is actually just like a material design icon. That was me. You can see the difference there. Yeah, it's definitely more minimal. Yeah, right? That's what you get when I do it. You just find something on the internet. It's like, oh, this is free? Yeah, we'll just use that. That's fine. Who cares?
Anytime I get an idea for a project, I'll show it to her and be like, hey, can you draw a logo for this? She just has a list of five or six different things that I'm like, are you going to do that? I'm like, I don't know if like, you know, the gopher was like building scaffolding, you know, you draw that. So want to pivot back to the community a little bit. What have been your strangest interactions with the community you've developed applications for?
Or have you had any truly bizarre interactions? Most of like the bizarre interactions are just like people being like going out of their way to be just like super rude, no reason. Interesting. I've had a couple of people submit issues that are just like, this is the worst software I've ever used. I can't believe you wrote this. It's complete garbage. And then I just closed the issue and I'm like, well, that hurt my feelings. Thanks. Issue accomplished. Those are like the super strange ones.
I get a lot that are like, I don't know what we talked about that are like, like, it would be really cool if it did like X. And it's just like kind of like a nonchalant statement of like, it's not like a super well taught on idea. There's not a lot of like details. I don't really know what they're talking about. And those are just always seem kind of strange to me is like, what, what do you expect me to do with that? I guess I just don't, I don't know.
I mean, I've sure made sense of that, but when I look at it, it's like, what does that even mean? There is a developer online who I thought of as you were talking. The there's an application, an RSS aggregator called tiny, tiny RSS. I have, I have used it in the past and it's a great application, but it is infamous online for having a developer who is extremely rough around the edges. Oh yeah. I do remember reading a blog post about this.
Yeah. To the, to the point where he will just insult you on. So he has his own discourse forum or some sort of community. And if you ask basic questions that are covered anywhere in his documentation, he or one of his moderators will, will insult you. And earlier this year, I actually wrote a post about it and I got some feedback on the post and retrospect.
I don't think I'll ever take the post down just for the sake of transparency and, you know, censorship and all of that, but maybe I should go back, revisit and rewrite it.
Someone had made a point that sometimes not, not excusing that type of behavior, but I think sometimes they're just enough bad community interactions that some people either are or feel like they're driven to the point where they have no other choice, but to be sure with people and direct, maybe they can do it without the insulting, but it's still, I think it's a kind of a fascinating case and interesting.
If you Google it, I'm, you know, the first five responses you'll get will be people in various forums across the internet complaining about this developer. And it's all, the interactions are almost always hilarious. The insults are clever and you know, if you're the one asking the question, looking for a response, I know it's not fun, but going back and reading it as an outside observer, it makes me chuckle for sure.
Even thinking about maybe how many newcomers might be discouraged from self-hosting after those interactions if those were some of their first. Yeah, that's super hard. Like I totally get it. I think I read your blog post. I think that's where I remember this from and I remember reading it and being like, oh no, I totally get where it's going wrong. Like I 100% get it how you could be driven to this.
Because people will just ask you the same thing all the time and just not, like they just won't try. It's like up to you to figure it out or to look it out for them, which gets frustrating. But like I was also an idiot at one point about something I didn't know. Maybe not an idiot, but you know, I didn't know all the right things to do. I didn't know that you could search Reddit, you could search GitHub, you could search discourse.
Like there's all these places to find information or like, oh, I probably need to look in this spot in the documentation to find it. Like this is really, this like hobby that we have is like crazy complicated and just like expecting everyone to just go to look at a piece of paper and be like, yeah, so I just deployed it on my system at home. It's like a little strange. It's a very weird thing that we do. So when somebody comes in and they're like, I don't get it, I think that's pretty fair.
It's super weird. So go to explain it to anybody else you know, like they're not going to understand anything you're talking about. I remember when I started self hosting, I avoided GitHub pages because they were intimidating and it's usually because of the top sections for newcomers I think are the most intimidating when you go through and you view all the, the Docker images for various builds and what you should use.
And once you get past that and you get into some of the installation instructions and configuration, it starts to make sense, but there are entire tools developers have dedicated to streamline some of these things because they are so complicated. And I'm thinking of things like Portainer and Unraid's community store where all of the container templates are set up for you.
It is a complex thing, but in a way we also tend to handhold some users and maybe they don't always develop the skills they need to adequately deploy some of these things because their hands are held a little too long when they get started. And somewhere there's probably a balance. I'm not trying to stick up for either side. It's an interesting dynamic and just, I just find it interesting when I view and observe the interactions the community has with developers.
Yeah. I think that your point about tooling is really interesting too, because a lot of these tools, I feel like have low entry points and very low ceilings too. Specifically, I think TrueNAS is what I've had the most problems with with my applications of they have very, I think it's TrueNAS, is the, like you can't change the Docker tag.
So whatever somebody publishes as the template, or this might be Unraid that I'm thinking about, but it's these things that like the abstract Docker away in this way that like hides a lot of the implementation from you. So like you don't really know what's happening. So they'll come into the discord and be like, oh yeah, this like doesn't work and this doesn't work and this doesn't work. And then we'll be like, okay, we think we fixed that like the last like three versions.
Could you upgrade to the latest and check it out? And they'll be like, oh, I can't like I'm stuck on this version until they publish a new one. It's like, well, yeah, I don't know what to tell you, man. Sorry. We don't manage that. But like, is it like, I'll just, you know, copy a Docker compose file to a Linux machine and spin it up because that's what I know how to do. But I had everybody, not everybody knows how to do that. Yeah, I guess.
And I mean, there are plenty of great crash courses on YouTube and I think people can find, but it is intimidating, especially if you're not a technical person, you know, configuring files and making sure they're formatted correctly and the various errors your command line or terminal might throw. If you do something incorrect can be daunting. And I remember like when I started this, I was, I used computers for 15 years since I was like a little child. My dad was into computers.
I've built Windows machines and done all kinds of stuff forever. The first time I had to install a Docker container, I about threw my computer across the room. I was just trying to install WikiJS and I could not figure out these Docker volumes and like getting the access to the ports. None of it makes any sense. And I feel like I have a pretty good knowledge base about computers, but like it's just, it's such a like a different thing to think about.
And it's just so hard to like, I like, I totally get it when people post on self hosted with like what now I think are like, that's like a really silly question, but like I totally get how you're there and like, you have no idea what's going on. Cause I was also there. Like I just had to give up and be like, this is the dumbest thing ever on ever want to do this.
Once you pick up on it, you feel like you're the most powerful person in the world because you can look at any Docker runner compose and, and translate it to your environment and deploy it.
And I remember getting to that point and then the first time I discovered an application or piece of software that I had to deploy like five or six different containers in order for it to work, just kind of like turning around with my tail between my legs and realizing that I had hit another limit and one that I'm not sure I'm willing to, to surpass or try to surpass. Yeah. But for sure. But Hey, I do want to spend a little bit of time.
I know we've talked about some of your projects as we wrap up here. I do want to ask you some pivot back to some more personal questions and specifically related to your home lab. I was hoping you could tell us a little bit about what your home lab looks like, what some of your favorite self hosted applications are. And then we had talked about this a little bit before we started recording.
I'd love to hear some, some hot takes you might have on technology in general, self hosted, self hosting related, open source, whatever. I'm sure you have some interesting opinions and I'd love to hear them. Yeah. I'll try to get your podcast canceled. We'll see. Two episodes in. Thanks. I did it. Nice. So for my, my, um, my own lab, I have kind of like a, I try to keep it pretty minimal just for like power reasons. So I have, um, a Synology NAS that's like my main storage device.
I think I have like, like 20 terabytes on there. I just got two new 12 terabyte hard drives that I'm going to swap in over Christmas breaks. This is very exciting. And I have a little NUC. I bought like one of the higher end, I think NUC models got like an i7 processor, like 64 gigs of Ram. And that's like the main Proxmox server. So yeah, I run Proxmox on that one.
And then I think I have like two or three Linux virtual machines and then, um, have a little network box that runs, uh, that also runs Proxmox and then it runs OpenSense inside of it. I used to run the Unifi dream machine. I really liked that until like one day, of course, like I had family over and we were like playing video games and then it just like, it died. Like it would only do like one meg up and down.
So that's always embarrassing of when you're like the computer guy and like, oh, my network's down. Sorry guys, we can't play Diablo. Yeah. So I scrapped that. It's still sitting in a box. I need to call them and get a replacement or something because it should work. But I really liked OpenSense and I was able to consolidate like my DNS server in there. I use AdGuard for that and Uptime Kuma as well. I like that one.
That kind of lets me know when something's crashed or I log files fill up and I forget to clean them, stuff like that. I think like the most used ones, although of course I have Home Assistant running on the NUC. Um, so that's, that's probably my most used application that and doing all the automations in Node-RED is kind of the one I get into the most. And then I also run kind of a self-hosted development stack. I have Git-T running with Drone or the CI and build systems.
I was just going to ask if you use these machines for development or if you have a dedicated rig that you do most of your development and compiling on. For the compiling and everything, I do it all on my MacBook. I have the, I bought like the first edition of the M1 Pro MacBooks. I love that thing. It's just great. It's so fast. I remember when I bought it, I had, I was doing all my programming on like a big giant i7 with like 64 gigs of RAM running Windows.
And when I got the M1 backbook, it like cut my compile times in half. So happy. So how about some hot takes then? Any anything you're willing to, uh, to, to go public with? Yeah, I think that the self-hosting community just like kills applications. Oh, they just re they will drive them into the ground with feature requests and that especially for new developers, like when I started Melee, it's just so hard to know, is this a good idea? Is it not? And like people don't know, right?
They'll just like ask for whatever they want. Whatever they think is like, this is what I need in this application. Everybody's going to use it. You should build it. And then if you're a developer and you're new and like, you haven't been through the whole thing with the open source projects and where you have all this stuff and you like, you have to manage expectations and what your thing is going to do.
You just keep building things cause it's super fun and you get like feedback of like, Oh, thanks so much. This is exactly what I needed. And like, that feels good. It feels really good to like build something that people like and they use, but we just like, we'll just ask for stuff. Like I've had so many requests to add SSL into our single sign on into Melee and I won't do it because I don't care. And I don't want to maintain it and I don't want to write tests for it. That's fair.
I see a number of projects and I think the longer I go and the more I self-host, the more I sympathize. Occasionally I'll see a project where it will just say, this is feature complete. I'm not accepting requests. I'm not accepting PRs of any sort. And I remember thinking it the first time I had stumbled across that, wow, that's like, that's very anti-consumer. But the more I have conversations like this, I think the more I understand that sentiment.
Honestly, I think I would probably be in a similar boat if I were to develop something. I don't have an incredible amount of time. And so I feel like I would be hyper-focused on the things I want to do and I wouldn't want to manage a GitHub issue or issue list or feature requests that's hundreds of items long. Absolutely. Yeah. And then I think my other one is that programs like Unraid and TrueNAS and Portainer and these Docker abstraction layers are just a net negative on the community.
There's too much fragmentation on how to do things now instead of using what is already an abstraction on very complicated dependency management. And now you've put two or three more layers on top of it. So now no one online can help you. People will come into the Discord all the time and be like, I have this really weird setup and it's not working. It's like, well, I don't know, man, that's rough. If you want to deploy it on Debian Linux with the Docker Compose file, I could help you there.
That's about where my knowledge ends. It's interesting. I think it's probably a good point when you hold their hands a little too much, they become a little too dependent and don't understand the underlying infrastructure. I'm sure every time you release a project, you get the influx of people saying, is there an Unraid community template for this or something like that?
And as you mentioned earlier, those inevitably end up being the users who have their database applications pointed to the latest image version with Watchtower auto updates set as well. Yes, that's another unpopular opinion. Latest tags shouldn't exist. You just shouldn't have them. What if you're manually managing your updates? What happens if your server crashes and you have to restore from a backup and you pull the latest container? You get the same one you had?
Well, that's a fair point if you weren't aware of what container you were using. Right. You're taking something that is deterministic or is supposed to be deterministic. Docker is made so you build it and you have a virtual machine in a little box. It has all my Python dependencies. It has all my runtime dependencies. It's all in a neat little package. Then you're taking it and making it unpredictable. You pull the version image, what you should do. But the project also has to do that correctly.
I'm one to talk because I'm not really doing it correctly in Melee. I was going to say that you were making me feel bad, but maybe that makes me feel a little better now. I tag my databases with major versions. I have Postgres 16 and I'll upgrade it as the updates come through. Then when there's a major version release, I'll set aside an hour on the weekend and make sure I do the proper SQL dump and then update and restore it back in.
But almost all my non-database things, I don't tag with latest specifically, but I leave the tag empty. So I'm implying that it's latest in my file. Then I use a really handy command line tool that I'll run when I have time that'll check for container updates. I'll have to manually specify these are the containers I want to update. So I have control, but to your point, I do not track what versions I'm on.
So if something were to crash in between updates and an application update, I probably wouldn't know where I need to point my image. I had this exact problem with... I'm one to talk because I will also do this and it will also come back to bite me. Don't feel bad. We all do it. I just think we should. So I run Vicunja, which is a to-do app for planning household stuff I have to do. They did a major... I don't think it was a major update, but there was a pretty big database migration.
And I was just like, a station in my box as I do. And then I just doc or pull, sure, whatever, corrupted the database. What do I do? I'm pulling the latest tag. I have a corrupted database. I don't know what version I was on before. I can guess. So I restored the backup and I think I pulled like six or seven tags before I linked the one that I think I was on. Because of course, I don't remember when the last time I did that was. I'm not on a regular cadence.
I'm just like, oh, I should probably do that today. It should be fine. Well, you've given me a lot to think about. I'm going to go cry in a corner for a little bit and then rethink my own Docker deployment strategies before I interview another developer again. So back on the Home Lab, one of the cool things that I have that I think would help a lot of people with this is I have renovate bot configured with my Ansible playbook. The renovate bot is kind of like the Penda bot.
I don't know if you're familiar with that, but it kind of just scans your repository and says like, oh, you have these things. They need to be updated. It creates a PR with the update and then you can just merge it. So I have all of my Docker images are managed through Ansible, but it's really just like a Docker compose thing that I do. So mostly it's just Docker compose gets copied to the machine by Ansible. So I have my Docker tags defined in there with the specific version.
And then whenever a new version comes out, renovate bot runs and then it will submit a PR that upgrades that version. So I could just merge that code in. And then I have the nicety of like, the updates are like fairly automatic, but I also have control over when that happens. And I have the specific tag that I know is like the thing and it's all in version control. There's a really good history of everything that happens. And you can set that up for free on GitHub.
I was going to ask you how you track updates because that's kind of a pain too. I think not everyone has a good system for doing that, but it sounds like you have it figured out through that deployment you have there. Yeah, that setting up the renovate bot to do like the PRs to upgrade the tags is really like, I don't really think about it at all anymore. It's just, I check the PRs every week or so. And then if it's a minor version, I'll merge it in and it'll update.
And most of the time it's good. If not, I restore the backup and try it again or figure out what went wrong. How many self-hosted applications or pieces of software do you think you deploy just roughly? I think the last time I counted the applications, it was like 13. Okay. Well, I don't know if that's a lot or not, but it feels like a lot. Yeah, I think it's a fair amount for sure. I don't know how many I deploy off the top of my head, but yeah, I'd say 13 is a lot to manage.
Does that include things like open sense and databases? I guess I'm not counting, I'm counting applications, not necessarily containers. If you counted containers, it'd probably be like 25, maybe 30. That's a lot too. It's all in Ansible. It's fine. That's fair. You keep talking about Ansible. That is the one thing I'm not familiar with. I understand the principle behind it and I've read a lot about it, but I've never ventured into it myself.
I'm very particular with how I deploy my services and every little event that happens on my machine. So automating things makes me a little nervous, but enough people use it that I'm sure it's probably more efficient than what I'm doing myself. Yeah, it's super neat. You do all kinds of cool stuff with provisioning the server in a very specific way. I pull down on my.files, I install NeoVam, I get it configured just the way I like it, and that all happens automatically.
But I will say that people throw it around in the subreddit, it's just no big deal. Just go check out Ansible. But it was like learning Docker for me. It was horrible. It took weeks of trial and error and trying to figure all this stuff out. It's a good skill to learn. It's super nice. It's really turned the HomeLab thing for me into less of a tinkering hobby and more of like, I'll just set it and forget it for a while and then I'll come back to it when I have time to do it.
So it's not like kind of a thing that's always looming over my head. And it's like if everything crashes, cool, it kind of sucks, but I can restore it pretty easily. That's been kind of a nice little load off my mind. So hey, I think we need to wrap things up. I think we've had a lot of good conversation. Hayden, I'm going to throw some links in the show notes to Melee and to Homebox and some of your other projects and some of the things we've spoken about.
Are there any ways, do you have any methods of donations set up for people who are listening and want to support you or who maybe deploy your application that can thank you and show their appreciation for the work you've done? Yeah, the best way right now is through GitHub sponsors. So if you go to the repository, there should be a little icon on the right hand side of the page and then you can donate there.
Right now I'm kind of distributing that money amongst the developers who are working on it, but we're looking at some different options to make sure everybody gets a little piece of the cut. So we're working on that. So stay tuned. Perfect. I will try and go grab those links and throw them in the show notes as well. But for all of the listeners, just know you can also navigate to the GitHub pages and sounds like you can get to those links from there.
So with that being said, Hayden, thanks again for joining us. This has been great. I've really enjoyed the conversation. This has been really interesting insight into the mind of a developer. I'm going to continue loving on Homebox in my own way and I promise I won't make any ridiculous feature requests from here on out. And if I do, you can just directly turn them down and I promise I won't be offended. Awesome. Well, yeah, I look forward to hearing from you. All right.
Thanks and thanks everyone for listening. I'll see you next time. Bye.