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.
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.