 Welcome to the Home Lab show, episode 50. Can you believe we've done 50 episodes today? No, no, I don't think that's true. I think that must be like a miscount or something. Technically 51, because we started at zero, so this becomes, we did that episode zero just so we could have a description of what the podcast was about. That was kind of fun, but still 50 podcast episodes, because episode zero is a description one, so. Yeah, that's just a preview of what's to come, and then episode one was the real beginning, and then now we're at 50. Yep, and today's topic is going to be participating and giving back to open source, and I've already seen someone comment about something we'll be addressing, is what if someone uses my code to make money or do something stupid? And that's worth mentioning, it is the only real downside, but I don't, it's one of those, the good way, way, way outweighs the bad that can come from this, so it's not something I think is the concern or a reason to be a deterrent, but we'll give you little details in a moment. First thing we need to do is thank a sponsor of the show who also loves open source, and that's Linode. So many of the projects we've talked about in here are very relevant to Linode, and Linode is a great place to run a lot of these projects, but see because I'm working on a couple of them that you'll want some public IPs for to set some things up, and Jay has lots of projects he's talked about as well on his YouTube channel, and Linode just makes it easy to spin these things up. They use a lot of open source tooling to integrate with this, and that is a, real plus on our side, the fact that they're very open source friendly, and it just lines up with today's show topic of giving back to open source, and they've been sponsoring the show since the beginning, and if you've listened to this, you're listening to it directly from Linode because you're downloading this off of the podcast. We've been hosting it on Linode servers using a bunch of open source Linux software as well, and I don't know if there's ever, someone did ask us, and maybe sometime we'll talk a little more about it, but it's pretty much just a WordPress instance. There's nothing too special about hosting podcasts. It's just files on WordPress, in case you're wondering the simplicity of our backend on there, but Linode made it easy to spin all that up. We thank them as a sponsor. If you're interested in signing up for Linode, we do have an offer code of linode.com slash homelabshow, and that'll get you started with Linode, and thank you again for them being a sponsor. Yep, we appreciate it. All right. Where do we want to start? I think one place that we can start is why somebody might want to give back open source, right? Because what's in it for me? I get all this stuff for free. Why should I do anything else? Why should I give back? Why don't I just keep it all to myself and just go about my business? We can talk about the ways that I think that it benefits people to give back in reasons why they might want to consider that. And then we can talk about individual reasons and things after that. Yep. Oh, and let me preface this entire talk. You do not need to know how to code to contribute. That's not where this is going. Great if you can, not a requirement. You can absolutely be as bad at coding as I am and contribute open source. That is absolutely true. Yeah, we'll get into some easy ways there. I have a whole video about it. I don't know how old it is, so I don't know how well it aged. But some of the reasons why you might give back. I think one of the reasons could be that a lot of the software that you're running, you didn't pay for it. So I mean, the alternative could have been you could be paying thousands of dollars for a license for something else that you could be using, but you're not. So you could look at it as cost savings and giving a little bit of that money back by just making a donation that always helps. But that's the easiest thing. We're not going to focus on that part of it. That's just a very easy thing that you can do to give back or in one of the reasons why you might want to give back. But I think a really good reason besides the fact that you're helping people and doing a good thing, because let's be honest, that's really what it's all about. But that's also easy. If we take that out of the equation, giving back to open source is one of the best ways to hone your experiences and your skill set because it gives you a chance to work with real people. If you don't already have a job in IT, maybe you're trying to get one and you're just kind of starting out. It gives you some experience contributing to projects that might otherwise be limited just to people that work already in the industry. And you might already have that experience when you do get your job if you are going into a job in IT. You know, there's a lot of community building that goes around when you get involved in open source. And having some involvement on that, if you're going into even any kind of adjacent tech field, like not necessarily being a developer, but seeing that you contributed and worked with open source projects and worked with projects in general, is something that always, from the career standpoint, can look really good on your resume. It also really gives you a better feeling for the product itself. And honestly, even small projects, I've frequently, sometimes they buy me a coffee or whatever, I look up the developers and see what they may take as a donation. And sometimes they are just looking for a thank you because they think it's cool that someone's using their code. From that standpoint, a lot of developers are like that. They're like, cool, someone's using the thing I made and they're just excited to hear from you. Thinking them is an easy way to start that engagement. So many things start with that simple hello world encoding. And in real life, it's just saying hello. Yeah, it's actually saying hello for real. And to kind of piggyback off of that, with my experience as a hiring manager and doing actual management, I was a director of operations for some time before going out on my own, sometimes people ask me for career advice. And one of the things I might be asked is, well, how do I create a portfolio for getting a job? And then I ask, do you have a GitHub account? They'll say, yeah, why do you ask? Well, you have a portfolio then, right there, done. Check that box, you're all set. Because if you have a public GitHub account and you actually use it and have some good stuff in there and show some activity going on, in my opinion, I'm more interested in that than pretty much anything else because I'm seeing not only how you get along with other people, I'm also able to look at your code. And I'm not looking for code quality necessarily, but I might be looking for code quality over time. For example, if I'm looking at some scripts and I'm thinking that this could be adjusted better, that could be adjusted better, I don't really care because it's not going to make a decision as far as whether or not I'm going to hire that person. But what I will see for someone that's passionate is that if I go back to earlier commits and then work my way up to current, I will see that code quality is improving over time, which tells me that that person genuinely cares. And the mistakes don't matter, we all make mistakes. But we have portfolios out there and a lot of people, they don't think about GitHub as that, but it really is especially in tech. I mean, that's like the number one thing that I want to see when I'm looking at how someone works with technology. You know, one of the people I hired years ago for my retail store computer technician, he quickly pivoted because he mentioned having GitHub and didn't mention much about it because it wasn't the position he was hiring just literally to fix computers at my office, retail computers. And I looked up his GitHub that he'd had on there and I'm like, whoa, man, he had done some seriously good work. And it was like, so you didn't really mention much about your GitHub was because I'm just going to come here to fix computers. That's just a side hobby I do. Young guy. And by the way, currently he works for Blizzard Entertainment. He's a game developer. He's extremely talented. And I actually ended up hiring him first as a computer tech, but later we leveraged his coding skills and really he helped me fix a lot of things that we had that ran our early days of inventory management system and point sale system that we used in the early days. It's the code, he fixed up a lot of messy code and it was kind of cool because I occasionally still engage with him, but that alone, once I seen him, like he's done some really intense levels of work and his goal really was ultimately be a game designer. And he was in someone who says, I want to be a game designer to play games. He's like, no, no, I'm going to go through all the complicated math to understand particle physics and everything in a game. He used to write really cool, clever containerized physics games I would almost call him. He had ones where he would shift the gravity in games and make all the particles move in different directions. He said his hobby stuff was just cool to watch visually. And that's passion right there. That is the definition of passion. And that to me is more important than anything else on the resume because I'm seeing how you feel about it. I've literally had coworkers say things like, well, I can't stand IT. I only work in it because, well, the money's good. So I'll just go along with it. I'm like, who says that? Like, that's not a very marketable person right there. Like, you should at least try to get into a job that you enjoy. Yes, I know the money could be great, but it's more about going to work every day, being passionate about what you do and doing it because you like it, not just because you hate it and you just want that paycheck. I mean, if you want to hate your job, there's plenty of jobs out there you can hate. There's no shortage of those. There's certainly not. So, yeah, go ahead. Oh, I would say, go ahead what you're going to say there. I was going to say before we get off of the GitHub topic, I want to mention why I fixate on that so much, not just because of how valuable it is to the hiring process, but one of my biggest pet peeves in IT education, I don't know if it's changed recently, but at least when I was coming up, version control was not mentioned in anything. Like, we had software engineers that have graduated and gone through all the classes, got great grades, and they've never used Git ever. Like, the books never mentioned it. The classes never go over it. And I'm thinking to myself that there's this disconnect between, you know, like what the industry wants and what people are taught, which is why I fixate on Git because it's something that everybody uses, whether or not you're a software engineer, system administrator. And that's also the reason why my Ansible series, for example, throughout the series, even though it's not a Git tutorial series, I'm having people use Git while they're learning, because that way they learn both at the same time. So, yeah, Git, in general, version control is definitely a very important thing to learn. And that lends itself well to giving back to open source because when you learn how to do a pull request, when you notice a problem, then you can help fix that problem. And I think that's obviously another segue into a reason why some people might want to give back. Sometimes it's selfish. We do this mainly because, at least I hope, we want to give back or do the right thing, but not always. Let's be honest, right? How many times have you heard of somebody that notices a bug that just drives them crazy in some software? But it's not a priority bug because crashes and things like that, that's a priority. But this bug in particular drives someone nuts and they just fix it. They just put in a pull request because they just can't be bothered with this bug anymore. And then everybody benefits because they decided to go in and fix it. Now, obviously, you have to know code in order to do that, not everybody does. The moral of today's episode is you don't have to code to give back, but if you do know how to do that, then if something bothers you and you know how to fix it, why don't you go ahead and try and fix it? Absolutely. Now, as we said, no coding necessary, but maybe let's give it into a few other reasons for giving back. You get all this cool software and you want to engage with the community a little better. What are the other benefits that come from? And it can be as simple as just posting in the forums, is helping get more people involved in a project or answering some questions because you've already been there, you've already set this tool up. You know, even for myself, I'm not a code contributor in any way to PF sense, but I am someone who's definitely taken the time to answer people's questions and post in forums and of course make lots of tutorial videos to cover how a lot of things work because there's a lot of basic setup and it's daunting to start the project. But by doing that, we're increasing the community and number of people involved in a project and right away, you just start making some friends and I've actually got to meet a lot of different people through the project that are really cool people that are kernel developers and everything else. And it just becomes this whole back and forth cycle. Like I'm not someone who knows how to write some of the kernel code, but them seeing how I use it, seeing how I answer questions, got me in communication with some of these people and it lets us think deeper again about a lot of these things. It's just part of the other reason to contribute. And by the way, I mentioned in the beginning, I am bad at coding. It's almost like a public service that I don't write some of this code because at one point in time was in charge of developers and I was very honest when I hired them. If you find a lot of broken, crazy code, I know I did it. You don't even have to ask who did it. That's why I hired you. You're just going to fix it. No, that makes a good sense. So I just want to mention, you know, real quick, for those watching, if I'm just looking over my shoulder and doing this, it's because I, my desktop is going crazy right now. I don't even know why. So if you can hear a fan in the background, I don't know why maybe a render is ticking too long. But hopefully no one's able to hear it through the microphone. It's kind of loud right now. But yeah, anyway, getting back to the point, that's a great point as well. And one thing about giving back is it can be very simple. Like I, for example, have put in a few pull requests to CrunchBang++, which is a distribution of Linux that I think really needs more attention it's not for beginners, in my opinion, but it's so great. It's just so lightweight and it works well. So a long time ago, I don't even know how many years ago, I was just going through a default installation and I noticed some of the files had some typos in it, literally. All I did was I submitted some, I don't remember what it was, but I submitted some pull requests just to fix typos. That's it. I mean, it took me five minutes and I was done. I noticed a typo, okay, fine. Now is the time to practice doing a pull request and put that in there and help them out. I didn't need to know how to code. All it was, was literally a typo in a comment in a bash file. So nobody cares because of, you know, the bash script works fine, but I see, I saw a typo, you know, I have a few minutes. Let me go ahead and try to fix that because that's super easy to do. And obviously another one is documentation. A lot of people don't really think about that, but it's really important. Documentation is great. If you know how to write, you have good writing skills or you want to get good writing skills, do some documentation, write up some documentation on how to do things, start a blog and just tell people about like how to, how to do a particular function or just, you know, go to the actual documentation pages for a project and that, and just improve it. And this can really serve two purposes. By taking the time to put the documentation together for this, you know, start your own blog and document your system, how you set it up, you know, you redact anything that would be proprietary secret, but go through those configuration steps, how you configured a particular piece of software. It can serve as one, documentation for you to reference later if you have to rebuild it, two, you can now help others in the community use this software of how to set this up, and three, you can start then engaging at some point if this becomes a popular topic or something you really enjoy doing, reach out. The developers that are writing a code are not always ready to sit down and type tutorials up. And if you already have them, you'll find yourself in good company going, oh wait, can we use yours? You'd like to contribute them. We would love to give you access to contribute to tutorials of how to set up our software. This is another way you can start engaging with the community and helping out. And it's kind of cool just getting involved in some of these and kind of a little bit back on the job topic. I've known a few people, this is literally how they became employed. Matter of fact, more recent story is going to be someone like Christian McDonald who was a code contributor to the WireGuard plugin. He now works for PFSense. They're like, hey, your code's really good. Can we just hire you? And he's like, I guess. So I don't know exactly if that's how the interview went. I'm not part of that. I just think, I just know he went from in person contributing code to, hi, I work for Nutgate now. So So he's surprised that I'm pretty sure one of the top developers with Ansible kind of started that way, if I'm not mistaken. I can't remember his name, but he's, he was at least, I don't know if he is now very common in the forums, just posting all the time, answering a lot of questions, always really nice. And I asked him one time, this is why I really wish I could remember his name, how he got started. And that's how it got started. He started contributing to Ansible and kept doing it and doing it and doing it and eventually started getting paid for it. That's not a promise that anyone's going to get paid, but it could happen. If nothing else, it'll give you a skill set you could use in an actual job. Yeah. And it also gave you a deeper understanding of the project because when you start taking ownership that you're going to post something publicly, there's this immediate bashfulness of, oh man, I got to be right. And you're, you're not wrong to think that way because you're, as someone who makes a lot of YouTube content and Jake, you can pack me up on this. You're never as wrong as when you're wrong on the internet. Because boy, you say something wrong, everyone has something to say about what you said that's wrong. Oh my gosh. And sometimes I think my, ooh, wow, I'm having a lot of errors on my computer. I think my power supply is that anyway. Oh, well, Jay turns off his computer. Incident. Good news is not the one he's recording on. But this is one of those things, like you getting into it and writing all this, there's always that risk that you might be wrong. That's, that's something that takes time to learn and get better at. But this is what happens. You really start focusing on it. You read further. I do this for any of my videos I make, because obviously I go through numerous scenarios. I'll double check it, even if it's something I already know how to do, I'll go one more time and kind of review it in my head or reread through the documentation. It kind of forces you to get better at a project. And I think this is really great from the learning experience, because you put so much effort into perfecting it before you'll document something that you just become almost like a subject matter expert, even if it's only for that brief period of time when you're documenting it. But this is actually a great thing because you hyper focus on it. You really put the time and effort into it. You've helped the community out. You've helped yourself out by gaining a deeper understanding in a project. And at the same time that, you know, if you ever have to reference it again, because it's something you set up, you turn on auto update and it works beautifully and you never have to rebuild it. That's great until two years from now and you've got to redo it. And you're like, oh, I spent two years since I set this up. Oh, that's right. Good news is I made all the tutorials on how to do this. And yes, I have watched my own tutorials and so is my staff. So I'm going to mention another way to give back to open source that is extremely easy and assuming that you have a relatively decent internet provider, this might even be the easiest way to give back. And this is something that most people won't even think about. It doesn't come to your mind first and that is seeding your ISO files longer than you need to. So for example, and also you could just argue that BitTorrent in general can help. And here's why because server bandwidth bills are expensive. So if you think about it, if you have a Linux distribution or a virtualization host that is free to download and that ISO could be, you know, a gig or more times however many people are downloading it, that's huge. I mean, that's a lot of bandwidth. But if you use BitTorrent instead, then that's better. And then also if you leave BitTorrent seeding longer, assuming that you have no bandwidth cap, because if you do, you might not want to do this. Yeah. But if you don't, then you could just leave that seeding for a while and kind of, you know, help other people download it because you're giving some of your bandwidth back to them. And then by using BitTorrent, even if you don't give back, even if you're just downloading things by BitTorrent, if you can, then that's less data that's being pulled off the file servers. So that actually can give the administrators a break and can also lower the bandwidth bill. I would argue that if everybody who can use BitTorrent downloads their ISOs through BitTorrent, then that would be monumental when it comes to bandwidth savings if enough people did it. You know, this is something that I've done as well when I, you know, I frequently wrap stuff off the Torrent and if it's a distribution, I also, there's, there's been times in the cybersecurity community, DEF CON has files to host and stuff like that. And I don't have bandwidth caps at some places. So I'll go ahead and let it, go ahead and upload and let it equivalently, at least as much as I download at that minimum, I'll do that or at least double it before I never shut it down. You know, provided in maybe you want to do some scheduling on that because you don't want to suck up bandwidth when you're watching it because I don't do it at the detriment of myself because I still need my bandwidth for me, but I don't know he's using bandwidth that, you know, four in the morning. So we can turn it on for that. So. Yep. Absolutely. Now, so there's so many ways to give back. I'm trying to think of all the different ways to do that. Now, one of which is to just be active in the forums and help people out. Now, if you know you're a grumpy individual and no judgment, you know, I'm grumpy myself sometimes, believe it or not. But if that's you, that may not be the best thing for you to do. But if you're, you know, reasonably, you know, extroverted, I should say, then helping out in the forums might actually be a great thing to do because you could help people out with their, you know, things that they got going on. And obviously, if there's a bunch of people complaining about the same thing, then, you know, there's probably a bigger problem that you need to let developers know about. So that's really a great deal. If you can't do that as well. You know, you don't really have knowledge for that. You just, you know, have to look for problems that you know how to solve that you've run into yourself. And if you see someone else going through the same thing, you could just try and help them out. And that overall helps the community grow and build. And if you have a, you know, a great personality, you know, you're pretty easy going, then you could actually shift the entire culture of a, of a community that might not always be the nicest community. Because let's be honest, we've seen some communities out there that without naming any, in particular, that we're kind of afraid to post messages, messages on because we're probably going to get roasted. But that aside, if you become the change that you want to see, and how people do this, and making the communities less toxic, could actually get a big benefit as well. Yes. Yeah, that's the, for sure. All right. The next, I see a couple people meeting the audience about, it'll be fine in the podcast recording. It's must be something on YouTube because we can hear each other. All right. One of the other things that we need to talk about though is bug reporting and not just complaining. Now, bugs that you can't repeat and document probably aren't going to get solved. And proper bug reporting is a absolute crucial role or especially when you deal with anything that's going to be more related to hardware. And for example, TrueNAS, I've mentioned this before, making sure that you, if you have a hardware problem like a network card that doesn't perform properly, a minor problem with a controller card or a scenario introduced when you use a certain combination of processor with certain memory, whatever those things are, the developers who are writing software that goes on hardware don't necessarily have access to as wide a variety of machines. Now that's going to change how much access they have is going to scale with how big the project is, but especially smaller projects, but even big ones. TrueNAS, it's not like the developers go, Oh, I have one of every network card ever made. Let me set a system up with one of every network card. It's also kind of a big task to do things like that. Therefore, which really helpful to developers going, Hey, I have a Chelsea IO, this exact model card, and I'm not getting the right performance out of it, or I have an Intel DA520 and it works on the 510, or I don't think there's 510, it works on one model, the Intel card doesn't work on my DA520, whatever those details are, as you can submit them to your bug report and say, Hey, when I try this card, it works, this card doesn't in this scenario. This is really helpful to developers because then they're going to prompt you back going, Oh, that's interesting. Can you give me this piece of data? Maybe a piece of dump that comes out of the memory that would help them narrow down where the problems are, where those edge cases are? I really appreciate that, like Steve Gibson, submit GRP, who's coding and assembly language for Spinrite, he spends a lot of time in his forums having people test things and give him the scenarios where they've had repeated problems because he's found some other boards where they didn't follow certain specs on the way the controllers talk that was causing some problems with Spinrite not to work. This is that really absolute how the system works to get a developer to understand your problem. You can't just say, doesn't work on my system, you have to get detailed, you have to make a repeatable problem. You have to show that you put some effort on your part and this is where I've kind of coached people on why they've not gotten responses. Someone had a problem they were experienced with TrueNAS and they started DMing me and I said, I don't do support over Twitter and they're like, well, I didn't get any support in the forums. I said, where's your link? They sent me a link. They basically rambled on for like four paragraphs and I'm not even sure what the question was and I told them that. I said, I don't think anyone has time to read four paragraphs. I think you have a question about a hard drive but even I don't have time to read just how much writing it is. What's the concise thing and what is the repeatable problem you're having so we can fix it? And you narrow it down like that. Got to admit, I seen that person do another post and oh wow, they had a response right away because they had a very specific narrow question. You know, you got to always be respectful the developer's time, the community time, but this overall will help the project move forward because you're probably not the only one doing this. You may be the first person to notice the problem but you're probably, well publicly notice the problem but you're probably not actual first person to have the problem but some people are very, for as many users there are for some projects you'll find some people just don't want to post online. They'll just complain didn't work with this hardware. I don't like engaging with people online and we know there's plenty of computer people who are more reclusive and may not want to do it but if you get over that you can engage with the community and get these problems solved and make the thing you like to use even better. Yeah. I think another thing that I feel is important is adjusting your own mindset if I mean assuming your mindset needs adjusted. What I mean is that the whole mindset in everything around open source is different than proprietary software. I mean if you think about it when we're paying money for something we expect a return on that money otherwise why would we be paying for something but if we don't pay for something I feel like a lot of people still expect a certain amount of return similar to which they would expect from a paid software. Now what I mean is we have some I'll use the word again toxicity in the community I feel because if someone doesn't step up to help develop something because everyone's like well someone else will take care of it something else someone else will take care of it then no one takes care of it then a feature gets dropped from a project and that could be a feature that someone uses like every single day and then they'll talk about well that project's bad they just removed this feature this is a great feature why would they do this to us they just removed a great feature horrible project horrible developers why would they do this well the thing that I think most people have to keep in mind is that developers believe it or not they don't want to make anyone angry nobody wants to make anyone anyone angry nobody wants trauma but if there's a feature that is considered less important to the project maybe not to you but to the project and you'll probably see messages you know in the past like can someone please help with this can someone keep this going if no one does that and the feature gets dropped well you know that's just kind of how it goes unfortunately I don't like to see features get dropped but sometimes that happens and I think one of the I could probably use Nome as an example of this like probably of five times at least because for example desktop icons that was something that they kind of had in Nautilus for a while but it was unmaintained nobody maintained it then they dropped it and then as soon as they dropped it people were flaming the Nome project like no one stepped up to help so it got dropped that's just how it works unfortunately it's it's not what anybody wants nobody wants their favorite feature to go away and I agree it's so irritating but at the same time the whole culture of open source is different because if it was a you know I'm not trying to say proprietary is better but there is a sense that there's a bunch of people that is their job to answer these kinds of things and keep these things going but a lot of these developers they're literally unpaid and I think that's important to keep in mind that they're doing it for fun and the more people come back at them with anger and frustration over things they can't control then they might be less likely to want to continue developing that project anymore they might just walk away so we want we need to be mindful of that as well Yeah and someone pointed out something and I see this the other day and there's not an easy answer for this one it's when you do take the time to put a really articulate post in there and you just don't get any response from it one of the ones I've seen and because someone had asked me about it I'm like I just don't know the answer they have such a complex post that they had done they had just a lot of factors and they were tying to external authentication servers and everything else and then they added their pcat files and everything else I'm looking at that right up going this is extensive you're clearly using in a commercial environment in a business now whether or not you can get free community support for something like that it's it's hard to lab it out because the problem set they're having involves not just the PF sense but also external authentication to other services so there's not an easy answer for it and a lot of times what I'll do is if it's an easy question I will answer but some of the more complicated ones if someone reached out to me I would probably tell them look at some point I have to turn to consulting you don't have just an average problem it's the same problem I run into where people I call them the triple VPN people who want to have like four or five privacy VPNs with failover really complicated policy routes and they're like but it's not working I'm like you know how hard it's just it can be done it's extensively detailed and troubleshooting wise it's not something the average person uses with this project so your options really are figuring your own figure out someone who's got the time to really type up a to the explanation there's like a push pull here the answer to the problem they're having is almost more complex than the problem they're having so while there's pages of write up here on the problem they're having the answer to how to actually get that all configured when you see the problem is like who do I have time to type out about four paragraphs deep of all the settings that need to be changed to make this work it becomes kind of challenging I don't there's no easy answer for it people contribute what they can you're obviously with hey where do I find this one simple setting you're likely to get a quick reply when you have these really in-depth ones not everyone has the time it's going to vary by what products you're talking about what projects you're talking about that can be a really tricky there's not always an easy answer for getting support on that at some point you may even have to reach out to all per se hey I'm willing to pay you to help me with this it sounds like oh no that's not the open source no that is the software is free people's time is not free that's that's where the the distinction really needs to be I should say where you have to be mindful of it especially if they're not paid or if they are paid by a foundation for it this is you know you look at something like Red Hat where they offer these support contracts that's why they offer them because they're like hey you can have this software but if you really want that support for these really complex setups you having your business or these you know one-off cases that aren't just kind of general use well that's why they sell support services around it it's not that they're trying to make a product that can't be supported and we're keeping the documentation from you it's all open you can read through the code you can look at how it functions it just takes a lot of learning to get to where you understand how to deploy these really complex configs yeah and sometimes it's it's uncomfortable to admit this but sometimes you are the edge case as much as you probably don't want to say that or admit up to that but you know you can see I'm just making this up but you might see some crazy use cases out there like my automatic dog walking drone based on a boon to doesn't fly anymore now my dog hasn't been walked in a few days get this fixed now wait what you have an automatic dog walker I mean there's all these different things that you know people think of that I think are brilliant right but then when something doesn't work it's like well whose fault is it now like that's not even the use case that this is designed for you could argue and we were talking just the other day about my use case with CIFS not being quite Linux friendly because I'm using CIFS but I'm all Linux and not a mixed environment so of course I'm the edge case here because just like you were saying yesterday when we were chatting like literally like the majority of people using TrueNAS and using Samba are doing it because they want to share files between you know in a windows environment or mixed environment and here I am all Linux and I have a recording share that's CIFS and having some permissions issues because it doesn't work the way that Samba normally works in Linux which you know got me a little irritated to be honest with you but then you call me down and like hold on a minute you know you are the edge case here yeah and that's the true story right there sometimes you are the edge case that doesn't mean that all hope is lost that just means you have to approach it differently like maybe you know document why your use case matters to you why it might matter to other people make a feature request a change request or something like that because it's not always fixing things that are broken sometimes you might have like a really good idea and you just want to get this idea out there maybe you don't even have the coding skills yourself to develop this idea but it's such a great idea that you really want to let someone know about this because a lot of people would benefit from this if somebody was to step up to the plate and write that code but if you don't get that idea out there either someone else is going to get the idea out there and great because it's open source it doesn't matter who came up with it or worse nobody will and nobody will benefit from that idea yeah and then some of the engagement even I have at the developers is I look at the way the product might be deployed I've influenced a little something that maybe we'll talk about in the future when it's finished some stuff that's happened at Bitwarden I've had conversations with their devs team and things like that so there's there's always that level of engagement that you get on there I want to address a question that came up in the comments and it goes back to me saying you know and they say I feel there's a fine line between community approach and seeking help and commercial support how do you define when someone should pay for support versus I'll get free support there's no easy answer if you have a especially if it's a commercial endeavor you're doing this for a business at some point I would probably say reach out and pay them because you can't find any way to solve the problem you aren't skilled enough to solve it yourself there's not any hard-fast rule on that it's kind of a well I threw it out there and yes I have this incredibly complicated config I set up for a business that isn't working at some point you just kind of say well I guess maybe I'll pay if you can't solve it it'd be if it's worth it to you you pay us probably how the the fine line it's not like there's a other line I can think of on that so if I needed some level of support or some configuration to be managed in a way that I couldn't find support for couldn't figure out myself yeah I would probably pay the most of the products we use were so familiar with me and my team build out our own labs all the time before we deploy to clients so we're often very familiar with how these scenarios work but we are ourselves a huge part of what my company does is consulting on projects for the things we talk about so I usually people are calling us but where that line is is often the commercial one is drawn like all right this is the thing we're going to put in deployment and we need some helps so getting this all set up and we're ready to hire some experts on it so up to you essentially there's not an easy hard line on that I'm going to give an alternate explanation from a different vantage point on this because from the and you know this just as well as I do that from the business IT standpoint I feel like a lot of this paying for support comes from that and that mindset often not always I'm not trying to throw every IT company under the bus here but a good number of them are like this where they're not buying support they say they are and they are paying for support they are paying a company for support but they're not buying support what do I mean by that well they don't care about the support because a lot of times IT companies have internal people that can fix the problem but what they're buying instead of support even though on the invoice it says support contract they're buying a liability shift such that yes if if this was to go down um I don't want my IT people to be written up from HR because you know HR might not understand IT and you know is a bigger problem I want to shift that liability to the support company so that way if that if something bad happens and we don't get it fixed oh yeah the support company didn't get back to us and I hate to say that because I feel like it's throwing multiple companies under the bus but these are conversations that kind of happen behind closed doors and IT companies and sometimes it's not even that sometimes it's policy where the requirement is to have a support contract not that you actually need it but that the company's policy is that if it's in production you must have one now how does that what does that have to do with us right well a lot of us work for IT and we don't hear the other side of that conversation and instead we hear gotta have a support contract gotta have a support contract so it's kind of drilled into our heads that we have to have a support contract so we have something important in our homelab well if you know I don't get an answer from the forums what do I do I need a support contract well hold on maybe and this is kind of where I go back to piggyback up of what you said what matters most is where you draw the line and this is true a business or home of how long you could be without it for example if it's an important thing but you don't I mean you could last a week without it it's not like you know it's a big deal okay that's fine but if it's something that you would seriously be inconvenienced by more than that then you might want to consider that support agreement and that's what really defines that is how long you can be without it and what the SLA and the skill sets are of the company you're getting support from because just because you have a support agreement doesn't necessarily mean that they'll know how to fix your problem in particular because of going back to my earlier point you could be the edge case and if you are well no support no no support agreement is ever going to help you with that right reasonable expectations as well now let's talk about one of the other cool things and this is how I know Jay you can make a lot of friends in the open source community so me and Jay we're both at the same conference together and we actually submitted some talks for this upcoming conference it was pinguincon but I was a speaker there and I have been and we actually had some mutual friends if you're been following me and Jay for a while you know we were both on the Sunday morning Linux review podcast before and we met all because of our love of open source and we you know as they even call it the birds of a feather where a bunch of people get together on the same topic is that's actually what they call it at the conference and there we all are loving Linux talking about it and you know this is how even me and Jay forged our friendship he you know he lucky enough that Jay is geographically reasonably close he lives in Michigan like I do but he doesn't live that close and but this is how we connected is all through open source and I've made a lot of friends this way connecting through open source and I think that's something me and Jay we're just joking how it can be especially as you get older I don't know I don't know what the age demographic of all our listeners is but you'll learn as you're older it's a little harder sometimes to make friends but it's you know something you still want to do and you also want your friend circle to be passionate about the things you're passionate about this is something you find in the open source community you'll find people from diverge divergent backgrounds but you're all going ah we all love storage servers so we all love diving into firewall topics and things like that so you know building a lot of friends and community around that oh yeah absolutely I actually remember the first interaction that we've ever had because it's so hilarious like literally is when my YouTube channel was kind of just starting and I think at that time I was still on a very old 1280 by 700 something resolution laptop and still had a $15 microphone so we're talking like super early days when I was starting up and I was at Penguin Con and I asked somebody about a video question and they said yeah go ask Tom I'm like who's Tom and he's like that dude over there go ask him I'm like okay so then I go in the room and then I see you with like some a lot of video equipment I don't remember what all it was it looked like you had like two carts full of video equipment there and I'm like yeah so this person said you could offer some tips on video and here's what your tip was you said when you make a mistake when you're recording just say a swear word like super loud because when you swear super loud you will see the spike on the audio graph and you'll know exactly where to go to edit out your mistake and I did do that for a while but then I got kind of like scared that I forget to you know edit that out but that after that interaction then you know went to your panels and everything else I'm like this dude has some similar interest that that I have as well so that's kind of it's just that funny interaction I'll never forget yeah it's it's really fun it's all the there's so much profanity that that gets cut out because you feel better because you screw up and it's like I could just be silent and look for the dead spots but it's way better to scream profanity because you feel better you know what the F word looks like in the audio graph of I know exactly what it looks like but then knowing me and my clutsiness I'll forget to edit that out so I stopped doing that a while ago but that was really funny I'm like wow that really does work yeah but you know but I think there's a lot to be said about forming those communities around these topics this is actually really adjacent to the way the hacking communities work as well I was joked that the hacking communities are almost like this constant show a tell of hey look what I got into look at how I took this apart because if you hang out as I do sometimes with different friends who are really into hacking things and I mean in the proper way pen testing and things like that and not people who are run around exploit extort type those the the name can be used on the either side but my friends who I go to DEF CON with and things like that that is they're really into sharing in that community and you start with that common interest we I was hanging out at in 2020 I did the DEF CON car hacking village because it happened to be here in Detroit and I knew the people involved in it but you still build that community around and it's it's really to me one and the same building those communities around and I think it's just a really positive way you can get involved and have you know these common interests on there it's it's kind of like almost a side effect of open source contribution but it's actually a great reason to get into it yep absolutely and I think yeah the community aspect I mean that's the key here because you're building community a report with other people that's how you find people that share common interest that can help you you help them and I think that back and forth with people is probably the best thing because you know you scratch my back cause I scratch yours kind of thing and I think that really helps here and you know one thing I do want to kind of mention I talk about several times you are the edge case possibly well that's not a bad thing by the way I don't want to make that out to be a bad thing because I feel like homeland people we are the edge case each and every single one of us right in some form or fashion I don't think there's a single homelab person that isn't an edge case in some form or fashion I think that's what makes us stand out that's what makes us clever that's what makes us you know have the mindset that we can do the hosting ourselves we can run the server ourselves we think outside the box otherwise we wouldn't even have a homelab we would just have like some you know $200 nas thing from clearance at Walmart call it a day and that would be that but sometimes having the having an edge case or being the edge case is great because I hear about some of the things that people are doing with technology I'm like you're doing what that's awesome I never thought about that so I don't mean to disparage anybody from being the edge case but when you are the edge case you kind of have to navigate open source of it differently to let people know what exactly you're doing because they're not really aware of what you're doing because you know you're unique so just keep that in mind and explain in detail short detail what you want to achieve out of whatever it is you need help with or need fixed what you have tried what type of hardware you have what patch level you're at things like that just make it easy on people and you know that should be a good thing to do absolutely all right I think that's the end of our list or do you have anything else you know I feel like I could be I could talk about this you know constantly because oh there is one more thing I do want to mention like we need to go back to the beginning of the podcast where we saw the comment about companies using open source or their gain now I will say that with everything good there's a negative unfortunately and one example of this is you know people that know me well they know that my you know Linux is my number one passion but retro gaming is my second place so of course I have all these game systems also have some of these clone systems and Hyperkin was in the news because this is a while back they released a product I believe it was the Retron 5 and they were in trouble because if I remember correctly they didn't call out the fact that they were using open source technologies in their in their firmware and they totally were and they're selling this device selling the device isn't really a problem but not giving credit where credit is due is a problem and they're not the only company to get caught doing this so that's a big deal and then you know profiting on it yeah they might but unfortunately there's you know nothing we could do to stop them from doing that because it's just the way it goes but there's also nothing stopping you from making money either because keep in mind if you know how to work with a library or an open source project at the code level you could actually sell your services and be an independent consultant and make some major money so don't think for a minute that just because other companies are profiting off of your contributions that doesn't mean that you also can't do the same you can you just have to think outside the box and go after whatever it is you want but even if you don't do that then the experience you are getting is more valuable than any training you will ever take and I've seen some of these IT trainings cost like $20,000 for training I'm not even kidding you and imagine paying that oh my god or working with open source and contributing and getting that skill set for free I think that's a lot better in my opinion than paying something like 20 grand for a training course there's so many benefits here that even though there's some legitimate negatives I think that those negatives they just don't they aren't they aren't negative enough to disparage people from working with open source it's all about your mindset yeah and I've seen some people as I follow a couple kernel developers on Twitter and I know one of them was particularly bitter their optimization being used for some high frequency trading for some serious BS as they put it and I get it but it's not it's not enough to deter them from being a code contributor but there's certainly a bitterness that seems to have come with that you take the good with the bad I think the good far far far outweighs the bad it's yes someone may actually use the software contribution you did to integrate and so of course and some companies keep internal technology it's proprietary they took some of your code they use it to build the business they never talk about what code they're using to run it because it's a private company that's going to happen it's just one of those accepted things you move on and you know that it's just life I don't worry never know much it doesn't stop me from doing all the things I do as a matter of fact I know by putting out some of these videos you know some people I've actually had this asked me as a question you know if you offer consulting time but if you give some of the full tutorial they won't even hire you they won't even you've given away all the information now they don't even need to hire you they got it all set up I'm like great I'm glad they got it working there's enough people that do hire us that this is still a great you know the consultancy work we do still works out very well for me I love that I can give the entire tier away because I won't lie here's an easy example of this I uh my head like cracked on my Tesla you know what I watched a video on it that video made me determine that I am not is it it was and some people watching videos going I'm gonna learn this I'm gonna watch this tutorial I'm gonna read documentation I'll learn this product other people go that's a lot of complicated things but you know I'm just gonna end up reaching out to the person that wrote the complicated thing put the tutorial together so right take yeah there's like I said I won't lie it's an annoying thing it happens as you mentioned at the beginning of this podcast in the comments just your role with it it's not it don't focus on it so right you're never gonna know what your contribution or where that'll end up I mean I could hypothetically create a I don't know code for a robot that can put objects in a box it just picks up objects and drops into box and I just put that code out there in public domain and then some pizza company uses it to automate the process of putting pineapple on a pizza oh my god why are they doing this why are they using my my invention for something so horrible but there's nothing I could do about it because I put that out there and if somebody wants to put pineapple on pizza I guess I can't stop them but whatever it is joking aside you really don't know but what you have to focus on is the passion for what you do because the minute you lose that you will get burned out I have one time is my second book I got burned out I was so overwhelmed and all I could focus on was the overwhelm and not how much fun it was to write I almost didn't come out with that book but then later on I adjusted myself you know what I enjoy writing that's what I'm gonna focus on not how many chapters I have to write or how long it's going to take I love the process I'm going to enjoy it and that's what I'm going to do and once you focus on the passion literally the other stuff that doesn't matter anymore yeah so we'll leave you with that that's our full thoughts on because you're back to open source I'll also mention I don't know why I didn't know about this before but it landed on something cool that I might do a video on if I play with it some there is a option inside of github and it's called github explore and I guess it just finds random projects for you I thought that I think it's like github.com slash explore set the I feeling lucky button that Google has but the github equivalent yeah it looks at what you did and suggests things and I it oddly it suggests a project I never heard of but I liked it immediately so that I'm going to say success but you can actually just sort and explore on github as well I just thought it was weird to suggest to their product right away that was just before the show so I don't have that in the notes or anything it was just for the show as well as things that popped up but it's a cool it's a cool project and if I like that if the project works as good as the github claims I'll be doing a video on it and sometimes you'll find a project that just you know it's it's not the project that you wanted but you find out that it's what you needed and didn't know you needed it like there's there's a few out there that automate via the command line the process of ordering lunch I mean you could literally order lunch without leaving the terminal how cool is that that is awesome yes there are some projects like that yeah those are those are cool and I see people talking about things I like I see pepperoni and pineapples and jalapenos I love all those things so me too hungry I have to stop putting jalapenos on my pizza because I was probably doing damage to my stomach at that point with how many I was putting on there but totally understand yep yep all right we have reached the end of the show thank you all of us everyone for joining this was a lot of fun we do like when people join us live we've been pretty consistent on 11 am EST on Wednesdays who've been going live for those of you that are listening to this and want to know when you can where you can participate in the chat room how we're just doing this live on youtube check everything out at the home lab dot show and thanks again everyone see you later