if you want to release a new version of your package or whatever we yes we have lots of automate update tooling or whatever that might pick that up but the process of like actually getting that out to users one of our humans is always looking at that and saying yes this looks fine welcome to screaming in the cloud i'm cory quinn and today's guest is one of those he or at least his work needs no introduction to most of us mike mcquade is the project leader for homebrew if you have not been become acquainted with homebrew you either have been living under a rock for 15 years or alternately you probably don't touch mac os which is like living under a rock for the last 15 years mike thank you for joining me thanks for having me here cory this episode is sponsored in part by my day job duck bill do you have a horrifying aws bill that can mean a lot of things predicting what it's going to be determining what it should be negotiating your next long-term contract with aws or just figuring out why it increasingly resembles a phone number but nobody seems to quite know why that is to learn more visit duckbillhq.com remember you can't duck the duck bill bill bill which my ceo reliably informs me is absolutely not our slogan and i feel like i just misstated already off to a great start because i've always used homebrew on a mac but apparently it supports linux as well uh as as a first party target operating system am i misunderstanding something here no it's yeah it's been doing that for a wee while a lot of people are surprised both that that happens and then generally the next reaction is why would you do such a thing like linux has a lot of perfectly functional package managers why would you bring your no it doesn't it has things like apt and yum and that would start replaced by dnf there's there's always a thing like uh it's like thomas jefferson once said that the tree of liberty must be refreshed with the blood of patriots and it feels like generationally we need to refresh package management with a new version to supplant the old one in linux distros every distribution i can think of has gone through this entire process and it shows no sign of stopping but what's the linux story for homebrew so the linux story for homebrew i guess it started out with being a bunch of people in bioinformatics labs who were like uh i don't have root so i can't use the system package manager and if i sort of like fiddle with homebrew enough then i can use it to install shit in my home directory and then like hey presto fast forward a while and a non-trivial number of people who use it and the kind of cross-platform nature is kind of appealing for some people because you can have the same package manager commands on mac and linux and ci and development perhaps and whatever and all that good stuff and then more recently we've actually seen like there's a couple of linux distros that do the whole like immutable root file system thing and then they use homebrew uh and flatpak as their kind of primary package manager basically and so that's that's been interesting seeing those like homebrew being mentioned on the front page of a linux distro that's a new development yeah for me it came back for a very simple starting point of once upon a time back in the day a thursday i believe was the day but that's neither here nor there and i wanted to i was trying to copy and paste a command off of stack overflow which was a best practice as is for many of us and wget wasn't installed on a mac and huh what's the best way to get this installed so first i went down the primrose path for a couple of years of playing around with mac ports because i am an old dsd saw and i don't believe that homebrew really existed back in those very early days but it was just night and day once i first encountered it uh and it had all the hallmarks of a terrible decision let's be honest here oh i just copy and paste this curl bash equivalent though we didn't call it back then into my terminal it'll just do all the magic things it needs to do and set it up from a security perspective it was something of a nightmare oh it'll just install the latest version of everything so what you run today and the new developer runs next week are going to be not exactly the same thing but it worked and i started using it extensively i became a i started doing some of the packaging for a few things back in the day for homebrew i'm running my own tap now with a couple of things that have now gotten enough traction that i probably should try submitting them to core and see what happens but everything i've ever really wanted what lives inside of homebrew and when i redid a laptop for the first time in a few years a month ago suddenly all the stuff that i installed that were that was graphic utilities live within casks which used to be its own separate thing and now seems to have more or less merged into mainline what's the history there yeah so casks were again you've probably clicked on if you haven't already been familiar with homebrew before this podcast that we like our beer metaphors over here uh this was partly because max the creator of homebrew uh conceived it while under the influence uh after being in a pub in london whining about package management and having his friends tell him presumably also under the influence well if you're so smart why don't you make your own package manager and turns out thank god usually those drunken belligerent conversations turn into and that's how i built a database engine so at least this one's novel yeah exactly exactly so casks were uh again you're seeing a bit of a running theme here like also a kind of side offshoot of homebrew where some people were like okay homebrew installs all your nice open source stuff uh but what if you could use it to just like download google chrome and put that on your machine or one password or any of these other things right yeah so basically like they were running their thing it got a bit of traction we noticed in the main project and we like brought those people over and merge the two projects essentially so that's been one of the nice things with the homebrew ecosystem is that over the years essentially when people do cool stuff that are like broadly in the ecosystem we try and like bring them into the fold and make it all official and part of our main thing which is a nice approach it's i've also found what i was looking at the submission requirements recently that if you have auto updating nonsense uh claude code is a good example of this uh it doesn't really belong in homebrew core that's what casks are for i guess how do you view doing an installation dance like that where at any given moment what is being installed on your system is not going to be what it was 10 minutes ago yeah i mean that's the fun of i guess homebrew package management you alluded to that earlier right we've always been i guess what you would call in package management nerd land aka my life a rolling release package manager and what you mean by that is like we whenever we get the newest version of stuff if it doesn't break humbrew itself we generally just foist that upon people right so in casks as you say there's some more extreme stuff where the cask itself can update auto update so humbrew doesn't necessarily even know the version of the cask that you have installed at this time but that we found that works a little bit better than you know a lot of tools like maybe claude code or google chrome or whatever nowadays that end up shipping their own auto update engine and it's like there are four releases a day in some cases yeah and we could try and fight that but again like i mean the homebrew in many ways like keeps after me in terms of like i'm exceptionally lazy right so it's like if there was some so say like debian right debian is a beautiful morally pure distro and on a lot of this stuff they're like well if there's like the kindest way you could have found to put that if they're like got an auto update or they're like yeah we'll patch out that auto updater and we'll just keep patching it out forever or whatever whereas i'm just like ah that sounds like a lot of work like that's what if if that's what the software project is trying to do let's try and find a place in our ecosystem that we can slot in and they can do things the way they want to do it and we can do things the way we want to do it and users can end up ultimately moderately happy yeah i prefer being able to do it through cask just because that way i don't have to crawl across half the internet to find stuff that i care about the only time i've run into trouble with it has been oh there's this thing that i want to install forgot i got it from the mac app store and that's where the license is tied to it so okay now i have to keep a separate exception list for that but oh well too bad so sad if you didn't know about this already i'm gonna i'm gonna transform your life here cory right so they're hit me with it please i'm about to redo this machine so tell me oh yeah oh yeah it's coming it's coming prepare yourself so homebrew has this thing called homebrew bundle which uses brew files right and it's loosely based off gem files in the ruby ecosystem order so what you can do in there is you can specify your taps your formula which are things that built from source supply by homebrew your casks your mac app store apps uh recently your go clis if you've got them your visual studio code plugins someone was proposing adding cargo the rust package manager support in there as well so that file lets you basically be like okay you can dump everything you have installed to that file and you can install everything on that file um and so you could have like a global wide thing i keep mine in my dot files and then i also have a little mini open source project the most successful thing i've created by myself called strap which is basically like the idea when you get a new computer you run this one script installs homebrew it looks on your github if it finds your dot files repo it pulls that down if there's a brew files inside it it installs from the brew file so you basically have like one command you can just run to basically like install all my stuff and get my all the software on my computer released back to where it was before right so hopefully this is gonna make your new build experience that bit more pleasurable than it currently yes and the counterpoint that i find here because i built a bunch of these things before this machine has been around for a while uh let me just for example run this now brew list pipe to wc-l i have 365 which is a suspicious number of packages installed on this thing so part of me like a lot of that is stuff i needed for weird one-offs that i no longer need i honestly on my laptop i have about i don't know 15 to 20 percent of that where it's i just because i just recently did that one and it'll eventually grow in time but i don't necessarily want to have all those things reinstalled part of the reason to do a fresh install is to get away from the legacy cruft i have something like four different ways of managing nvm on this system which is kind of a problem i want to start standardizing around which is the one that i've found that i like the most these days for python it's strictly uv system wide and so on and so forth asdf get rid of it because its ergonomics are terrible i can never remember which command parameter goes where and they're positionally dependent which is just wonderful simply wonderful i have opinions and i'm belligerent and i refuse to learn new things i am the worst engineer you've ever met it's great but also a typical one yes i wish i could say that that uh rant was not representative of the typical home brewery user but you you will fit in well with our community of people who do not like it when we change their shit i guess on that so while i'm evangelizing the why brew files will change your life right so if you run brew bungle dump which dumps all your things out one thing at least of that list of 365 is that it will only output the things that you have intentionally installed so anything that was not its dependencies a lot of dependency exactly unless you also intentionally install the dependency in which case that it will remember and know to do that as well so the little workflow i have after that like sounds like you have a you know a world of craziness to unpack but maybe on this new build if you're doing it from scratch then what i do is i have my brew file i keep that in my dot files directory which is a github repository and a locally checked out git repo and then what i do is i just install my stuff and then every so often i run brew bundle dump dash dash global and then i get my brew file in my dot files repo is like being nicely replaced and because it's a git repo i don't care that it's been replaced and then i look through the diff i do a little local review in my local git gui of choice fork which i would recommend very nice little git gui and then i'm basically like which of these do i want to keep which ways do i want to delete right so i stage it i commit the stuff that i want to keep and then i maybe get rid of the changes i don't want to keep and then after that i can then run brew bundle cleanup which will then use that brew file and then uninstall everything that is not present in that brew file so then i can get myself from a world into a world of chaos into a world of order and serene package management calm i like this quite a bit yeah honestly it's going through and like uh doing the dump on this okay i've got a whole lot of lines to delete in this like rust when the hell am i going to need rust well the next time i grab something opinionated off of github but until then i can enjoy not having to build a conference talk as a prerequisite for writing code you know basic stuff in life i've also seen homebrew itself over the years has changed significantly where just even the process behind it it auto updates now which i think is great your analytics i think have been handled in the most user respectable way possible the the fact itself updates only intermittently not every time you do stuff that's phenomenal it seems to have parallelized itself a lot better than it once did as far as downloads and installs go like someone has put some thought into this there's an entire there clearly is some sort of dag involved yes there definitely is the occasional thought that happens uh that results in a change uh several of the changes you mentioned are things that people still besmirch my name across the internet for for ramming home again against the interests of the users but the problem is with things like open source right is homebrew has we guesstimate about 10 million users from like analytics analysis stuff where like we don't have like we have opt-in uh sorry opt-out analytics not opt-in again another course of contention but you you can sort of infer that the vast majority of people opt out uh based on the download numbers from github's packages uh versus the numbers we get for analytics so that's our rough guesstimate so for those 10 million people based upon the sheer number of developers in the world most yeah maybe it may maybe that's maybe that is on the lower end but uh the number of people who essentially service their requests for those people are 30 maintainers right so when when you are dealing with that level of scale a all glory to the internet and open source for making that sort of scale even flipping possible but also you end up having to make nasty little compromises sometimes like say the auto update thing right lots of people really hate that but what it stopped was 95 of issues being this thing is broken run brew update does it still happen oh no it's fixed now right and there's only so many times you can uh respond to that and not write an auto updater before your brain just turns to pulp and my brain was starting to turn to pulp update bugs are the worst because how do you fix them well yeah that that's the other beauty yeah is when when you break the auto updater which i have done once that is a whole new world of pain as well where it's like but i i did everything you said i ran the updates uh yes but the updater is broken so you can't run the updater because the updater won't update the updates uh and neither will the auto update update the updaters to run the updates you have to run another update to update this so now whatever my mom with that her nothing was working in her browser anymore turned out it fell off the google chrome update path like four years beforehand and sadness yes and and this is why like i break out in hives anytime anyone submits a pull request changing that auto updater file because i'm just like are you sure are you sure you really want to do this do you really want to roll the dice and be the person that breaks the auto updater because i've been that person and it sucks yeah but uh suddenly on the plus side once you do that everyone knows your name one way to become famous or infamous i guess yes it's do you find that people tend to pin particular brew releases i'm sorry package releases inside of brew like oh always install this particular version of this package yes sometimes so we we have like a pin command that lets you do that but like the usability around that is kind of like meh only time i've ever used it has been in highly prescriptive here's how to install a dev environment in old school stuff before the advent of docker there's a bit of that and also like what we recommend nowadays is like there's we provide version packages for some stuff so if that's available so say like it used to just be there was just postgres right and if postgres got a new major version update and you wanted to sell an older version of postgres sucks to be you right like and then we had a slightly more middle ground now where it's like okay now we have postgres i forget the versioning scheme off the top of my head but whatever it is postgres 18 postgres at 18 postgres at 17 postgres at 16 right and you can choose to jump your way between those different packages right and for a lot of people for just installing postgres is the latest stable it depends i think postgres is a special case because we're still dealing with some issues there but in general yeah in situations where it's like i need this exact version i need postgres not 18 and not 18.1 and postgres 18.1.3 because that was the best version ever it's a particularly fine vintage that year then what we recommend in that situation is like there's a command called brew extract which then pulls uh postgres out of our repositories and then gives it in your own little github repository for a very specific version and you have ultimate control over that and you can choose what to do and then you can live in happy stable land so that that's generally what we recommend it's a little bit more work but we do provide a bunch of helper commands and whatever as you may notice again there's like a brew command to do just about everything right so like even within homebrew itself the way we run the project like we give our maintainers who are remain active 300 bucks a month uh if they are like regularly contributing to homebrew which probably contributes about as much money probably less than your average like paper boy or girl gets when they're 12 years old going around the neighborhood i think that's the going rate for open source maintainer nowadays so yeah not a lot of money but like we have to have a way of figuring out oh if someone was on away for three months like do they earn that or not so we have a command brew contributions which looks at the contributions of the various maintainers in that timestamp right so essentially almost all of our tooling by default is public right and that little tool i use to figure out who gets 300 bucks in a given month or quarter or whatever right anyone can use that and you can run that tool and in fact there was a bunch of brew i yelled at just now saying your token needs the read org scope to access this api there you go what a beautiful error message if i didn't say so myself at least tells me i don't have access to a thing which is great uh brew doctor spits out three pages of nonsense because i've had this machine for too long which tells me that if ever i need to report a bug against homebrew i've got some housekeeping to do first because everyone will blame this like unbrewed files in certain places from all the various things i've used apparently post grisqueal 14 is now deprecated huzzah some installed kegs have no formula which that's novel i don't know where those came from a bunch of casks are deprecated etc etc etc like this is what happens with five years of cruft yep effectively you've had your yearly health check and the doctor said how the hell are you still alive man your blood type is chunky yes yeah it's not going super well here it's so great it's time to wind up basically rebuilding things from scratch but that's that is the nature of the beast on some level i've also found historically that having a bunch of deprecated stuff or packages you didn't you installed then removed in some district some package managers can lead to security issues apparently for a while on one of my test boxes that i use as a dev box it used it set up a postgrisqueal user with a password postgrisqueal then i uninstalled the package the users hung out so suddenly i had a problem there nice yes yeah yeah i felt real smart after that one i've also found that you folks are quick to update where the day of a new mac os release suddenly i'll get error messages that i'm not i haven't out installed the latest version of xcode it's like well that's great it's been out for 20 minutes the mirrors themselves do not have it yet but it's already telling me that you need to update your stuff if you want to be supported it seems to have backed off from that jumping the gun mentality last few releases so someone's paying attention this episode is sponsored by my own company duck bill having trouble with your aws bill perhaps it's time to renegotiate a contract with them maybe you're just wondering how to predict what's going on in the wide world of aws well that's where duck bill comes in to help remember you can't duck the duck bill bill which i am reliably informed by my business partner is absolutely not our motto to learn more visit duckbillhq.com we try to be like aggressively chill right so because we're a bleeding edge package manager we tend to attract the users who have that so generally there's like a little almost like internal homebrew bingo about like how soon after the next mac os release gets announced and till until apple says the developer beta is coming until someone opens an issue on homebrew saying this doesn't work yet right like i think we've literally had about 20 minutes after the keynote ends someone's like yeah why is that why is this not working it's like because we haven't downloaded it yet you dummies like chill your boots like but yeah so we we tend to do a little bit of that ourselves where i guess we're maybe unlike some software where what we try and do is we're like we're gonna warn you about anything that might be a problem right and like if you're not getting any warnings from homebrew at all like you know that you have been a good little boy that day right and or have not properly installed homebrew or not properly installed homebrew indeed but yeah so like our kind of like brew doctor command i feel like we were one of the first things to do that like what we're trying to do is provide it was the first time i encountered it back then most other things called it pre-flight yeah exactly so we just try and provide a lot of pointers for like look if something's broken and someone's not particularly in the early days of homebrew it's like maybe no one's awake to help you right and you want to get this fixed in the next 12 hours so here's some stuff you can try right like i mean i used to be a uh part of the cent os project this was back when i was free node network staff irc was the way that i encountered a lot of the stuff and got support for it and there's one thing that i learned and that is people are freaking terrible at asking for help in ways that make sense so having a doctor command that will identify all the issues with it and it's almost it's close cousin to a diag uh spit out where it's like okay what version of mac os oh wow i didn't realize numbers went that low what else is going on with this system that otherwise i'd have to tease out of people over a period of hours as they start trying to figure out how their system was put together yeah it's funny so like github has homebrew is one of the first users of like the github issue templates right where you have like mandatory information you have to fill in but part of the reason i think github even has them is because when i was a github employee i whined about wanting those templates so incessantly that i feel eventually someone just gave up and was like right mike if it will make you shut up we'll build these stupid issue templates and no one's going to use them and then turns out everyone uses them but anyway so like terrific gen ai use case too uh that's exactly what i was going to say yeah like so we we found we found them great for that because so our and again our issue template was basically based off and i used to have like a text expanded shortcut literally for co-workers when people would basically ask me for help in a very unhelpful way and be like okay what did you do what did you think was going to happen what actually happened tell me what i can run to see the same thing on my machine right and if you could do those four things then like hey we've got a great bug report and also as you say like for gen ai if you could say the same thing like a lot of the time like copilot will like one shot though if it's completely 100 reproducible and it's well explained in the issue like copilot can go okay run this command got this output change some code run this command until it gets the right output and then ta-da here you go there's a pr and the code quality might be garbage but like often it it gets a decent amount of the way there if it has a good template part of that is the stuff you never see because i used to do that by hand a friend ran ask me better.com which asked those exact questions there was no real submit button on it but by the time that you wrote that out and came up with a repro case you realized you were the one that forgot a comma or something weird had happened and oh i misread the documentation like the best requests for help that i've ever written are the ones i never submitted anywhere because it solved my problem going through that process 100% and that's that's a big part of the goal as well like and ironically the people that find those flows to be overly prescriptive are often the same people who if they slow down and read the flow they might have avoided having that issue in the first place what's the security posture on this stuff look like i mean i know that at this point enough people use homebrew that if i can compromise the wget package for example suddenly everyone's going to run the code that i want them to run what are the safeguards on this i know that uh pi pi pi pi pi pi however they pronounce it i get yelled at if i say the wrong one but i can't remember which is which uh they have an entire security team that looks at this pp right yeah that's what i'm gonna go with that i'm sure that mike fiedler who runs that will not punch me in the mouth the next time yeah so like we're lucky in homebrew land in that our trust model is very different to pi pi pp whatever we call it npm ruby gems etc right so those package managers fundamentally have a trust model of we will trust people to do some verification of the people whose stuff they download right and we will not be a gatekeeper middleman whatever unless it's like gratuitously obvious that this is malware or whatever right there i'm sure some of those folks would say that's a gratuitous simplification and i'm being very mean and unfair or whatever but oh well that's that's me whereas in homebrew every single change that happens in homebrew a human homebrew maintainer has to verify that reviews the code and says this looks okay right so if you want to release a new version of your package or whatever we yes we have lots of automate update tooling or whatever that might pick that up but the process of like actually getting that out to users one of our humans is always looking at that and saying yes this looks fine right and same deal with the way we kind of build packages and things like that like we operate our ci like we were pretty early to the party of having essentially binary packages built from users pull requests on gilb and then just deployed straight out to users right with again with human intervention but like as a result of that we have built everything with a trust model that essentially you can't trust anything ever right and all of our ci workflows essentially treat even the code they're running most of the time as like untrusted input right so we generate you know for example when we generate a binary package we then generate json that describes the binary package and then later we read the json because you can't embed arbitrary executable code in the json like you can in the ruby files yeah exactly challenge accepted anyone but yeah so like that's what we try and do so like our our trust model and we are lucky enough careful enough whatever it may be to touch wood have not had any major attacker driven security vulnerabilities i guess if you go through the humbrew blog you can see we've disclosed things in the past i think our worst one was based on a jenkins misconfiguration which was it called jenkins yeah well so that's one of the reasons why we don't use jenkins anymore because jenkins misconfiguration was uh rather easy to achieve i would say but yeah like generally we i think we've had a fairly good track record on this stuff and obviously as i think homebrew may have been the first project to create the curl to bash pattern right so people are going to hate us forever for that but i think in terms of actually user experience security problems as opposed to just people in the security community shouting at us and calling us morons security problems i think we're doing all right i do want to ask uh before we call this an episode about your approach to open source i mean the triggering event that's oh yeah i should really talk to you about this uh was a linkedin shit post that i did uh somewhat recently about the experience i had when i did a brew install terraform and it's a great this is an old version because the new versions are not open source licensed sspl is not open source or busl whatever the hell they're using and i thought that was a terrific position to take some people are whiny about it and i honestly don't care about them because if why don't you do volunteer work for an ibm subsidiary is one of the dumbest things i can think of to ask you yeah so i mean our our view on this is so what we say in homebrew is we have homebrew core which was our kind of original package manager like open source stuff we did and at some point we're like okay we say we only package open source stuff in here what do we actually mean when we say that the nicest definition we came across was the debian free software guidelines right and they are not as it might sound like if you're not someone deeply versed with open source or free software whatever essentially everything within their description is open source and it's a nice clear definition of things right and there we have a body called the osi who we also look to for the advice who were the one essentially the body that came up with the term open source back in the day and i have the controversial viewpoint that words mean things and it's a good idea to make words continue to mean things such as don't say literally when you don't mean literally and i will die on that figuratively is the word you're grasping for and exactly yes so with open source we have rules on this stuff and when various companies lately have decided to i guess hatchet corpse projects as example one maybe redis maybe elastic search maybe mongodb when they as vc-backed businesses decide that their business model is not well suited by their current open source license that they have just happened to rely on to get a enormous amount of adoption over the last decade right and they decide that they're going to change that and relicense everyone's contributions over that period because they were foresighted enough to require everyone to sign over their copyright which allows them to do that instantly homebrew various other projects do not do that then what that means is that they can do as you described in that linkedin post a rug pull and everyone's left going well wait a minute is this open source anymore and the companies much to my chagrin will say yeah oh yes yes this is this is totally so we're just it's just open source but uh if you want to make any money then you need to give us all your all of your money but i mean other than that it's completely open source right like it's fine but again as i say when words mean things it's like well in open source you don't get to do that right and i had a lovely conversation i will not volunteer for your for-profit enterprise because i won't let people volunteer for mine uh when i contribute to open source it is open source to which i am contributing honestly sometimes to that project's detriment because i'm terrible at it but you know i it's not for lack of caring and it's not for lack of philosophical purity it's there's a there's a sense that there are things i will volunteer my time and energy for and there are things i will do with a hope of making money out of it and i try not to cross those streams yep and i i think that's very wise right like i i was on a podcast recently with friend justin searls and i was kind of cross posted to the changelog in which i said like open source is not a career right like open source is not a business model open source is also not a career right and i think we have seen a bunch of people conflate these ideas that you need to pay all open source maintainers a market rate tomorrow otherwise it will not be sustainable and similarly with companies a company should be able to just release open source software not charge anyone any money forever and then like when they get upset that that is not a viable business model they can change their license and point at the big cloud vendors and say like wow they're they're stealing our stuff and it's like well they're stealing your stuff because you said it could be taken that's what that's what your license says back when there's a new york times article about amazon strip mining open source like that that's not accurate to my mind they are doing nothing wrong you can talk about whether they should be contributing back but that's one of those uh appealing to our better angels that is not one of those if they have an obligation to do so now i mean amazon does not do philanthropy let's be honest with ourselves they're amazon they don't know what that word means but so okay the problem that these companies made is early on and i i have some sympathy for it was in 2010 or so well we wrote the code clearly we'll be the best ones to run it as a service that didn't pan out now you have people starting open source based companies and they want all the benefits of open source without any of the drawbacks like oh should never have launched that project with an open source license yeah but no one would have used it if you hadn't so what's the story and the way i like to deal with this instead right is again blog post i wrote a long time ago a lot of people don't like me for it but a bunch of open source maintainers do so worth it uh that i titled open source maintainers owe you nothing and if you read any open source license it essentially says hey look if you use my open source and it breaks your computer on purpose then sorry you've agreed in using it that you waive me of all responsibility for that so tough luck right and to me the way if you say you know say amazon right amazon's strip money on my own source they're using this stuff well what you can do is just if anyone who's an amazon employee ever submits an issue in your project you can go close and say i don't want to fix that your company has lots of resources they can do what they want with their open source project i'm not going to help them right you can choose to not accept issues you can choose to not accept pull requests you can choose to not respond to anyone from amazon on your issue tracker ever again if that's what you want to do and you as an open source maintainer have the right to do whatever the hell you want and that's this is the beauty of it right and i think this is the problem job i've got to take the other side of it where most of the stuff i write these days i used to open source all of it because why wouldn't i i'm sorry but this way to wind up running a command simultaneously on 15 nodes at once uh in every aws region that's not a competitive differentiator that's just something i want to exist so other people can use it these days i'll write quick one-offs and i just i'll keep it in a private repo rather than open sourcing it just because i don't want to hear it from people yeah yeah because the level of entitlement is often crazy and this is a yolo coded thing in half an hour or so i just want it to work great i know that you have other use cases for it go with god have fun but i don't want to hear about it i don't care vibe code it yourself yeah and my code should mostly be told it's a cautionary tale the thing is as well as often the people are the most entitled about it ironically are often the people who are the most reliant on your free gift for them to do their job i remember one time we upgraded a version of ffmpeg or changed the codec or something in homebrew right and someone said like i'm running my entire business off this and you people have just broken my entire business like have you no shame and i was basically like sir have you no staging environment like you have learned a lesson today about relying on other people's software given freely if you're literally running brew update and brew upgrade and that hoses your entire company this is what we call a you problem sir and not a me problem i didn't tell you to do that you decided to do that and now your stuff's broken like right if you're running latest or any other bleeding edge package manager in production it's just a matter of time yeah and in some ways again this this comes back to what you're saying about the you know well we built it we should be the best to run it in production it's like well no like you've demonstrated your ability of being very good at running a database open source project you did not demonstrate your ability to provide a multi-region multi-culture like massively scalable cloud provider right which is essentially what if you're offering a hosted database provider in 2025 that's what you're doing right and chances are aws is probably quite good at that they probably have quite a lot of people who are quite good at that and again like sorry folks this is capitalism i don't feel bad that you as a company trying to make lots of money picked a fight with another company who are also trying to make lots of money and you didn't win like you don't get more sympathy because your code happens to be open source right oh for me it's there's a reason this entire conversation for the last half hour has been about what we do on developer workstations i have asked you none of the normal questions i would if you were building a package manager aimed at you know production environments because i have a whole different laundry list of this the closest i run into this is as i mentioned earlier well the next developer we hire is going to have slightly different versions of everything in their environment theoretically i really do hope that the people are updating their packages on a consistent basis which brings me to my last question for you here have you ever given thought to having brew auto update on a schedule both itself as well as the packages that have been installed from it yeah so there's actually again a nice little external command for this which was briefly in the humbrew ecosystem and then we decided it operated better independently elsewhere uh by then it's not your problem sort of yeah by a lovely chap called dom who used to be a homebrew maintainer and it's called homebrew auto update if you search for that and yeah you could basically have that as a cron job that basically every night just in the background will just bulk upgrade everything on your machine right and if that's how you want to do it then that's how you can do it right again another happy middle ground on there which i quite liked is if you say using something like brew bundle uh like i mentioned before then you can have brew bundle by default will upgrade all your packages so if you have a project say with your co-workers at work right say you are relying on mysql and rust and javascript being installed in this like particular project right you can have a brew file in your repo root that has those packages in them and then if someone runs it then it'll upgrade everything and then okay you might have someone else on the team who's in an inconsistent state but then they they can just run the same command and they will get to the same state so that the state is based on time rather than by based on a lock file but you can still get some degree of consistency there and also what you could do which is what i tend to do in those situations if you want to be like a step ahead say people are not running upgrade relatively often or you're you have an onboarding flow or whatever and you don't want it to break you can set up a github actions job with a mac os runner that just runs that every night and then when it fails it opens an issue or sends someone an email or whatever and then you know oh like something in homebrew got upgraded and now we need to go fix that right and you can deal with that when you choose to rather than just like being like oh some particular developer ran a particular thing at a particular time no like come on people like we we have ways of solving these types of problems with reproducible environments which you can do with github actions ta-da problem solved it's it's a fantastic tool i want to thank you for spending as much time as you do on getting it to work if people want to learn more where's the best place for them to go uh more about homebrew you can go to brew.sh um our lovely domain if you are interested in the code or contributing then that will also take you to the homebrew github repo which tells you all about getting involved if people want to see more about me and my ramblings on open source and other things then they can go to my website at mike mcquade.com which links out to all my other internet presences and we will of course put links to all of this in the show notes thank you so much for taking the time to speak with me i appreciate it thank you for having me cory a delight mike mcquade project leader at homebrew i'm cloud economist cory quinn and this is screaming in the cloud if you've enjoyed this podcast please leave a five-star review on your podcast platform of choice whereas if you hated this podcast episode please leave a five-star review on your podcast platform of choice along with an entitled whiny comment that we'll never see because that platform wound up having their entire stuff go down because someone ran a brew install without any idea of pinning or the fact that this is not how one should run production as a responsible grown-up

Welcome back to the FreeCodeCamp podcast. I'm Quincy Larson, teacher and founder of FreeCodeCamp.org, and today I'm interviewing Mike McQuaid, the maintainer of the Homebrew Package Manager tool used by tens of millions of developers. First, let's jump to some community news. FreeCodeCamp just published a book, a full-length book, that will teach you the math that powers most AI systems. Even if you haven't touched math since high school, you may find this book helpful in expanding your understanding of the layers of abstraction underpinning these emerging tools. You'll learn key concepts in statistics, linear algebra, calculus, and optimization theory. You'll also get a healthy dose of mathematical history. It's a full-length book. Link is in the description. And if you're finding a sudden surge in AI tools to be overwhelming, FreeCodeCamp publish this practical guide to using them effectively. Finally, this tutorial will separate the utility from the hype, and you'll learn how to minimize hallucinations with context management. You'll learn about agentic tools and in-editor assistance. It even has tips for how to prevent your own developer skills from atrophying, so you can adopt these tools without becoming overly dependent on them. Very important. 35-minute read. Link is in the description. And FreeCodeCamp this week published a course on React optimization. You'll learn key React design patterns to achieve screaming-fast front-ends. This course covers memoization, derived states, throttling, debalancing, concurrency, visualization, virtualization, and more. It's a two-hour course on YouTube. And did you know you can learn music production on FreeCodeCamp? You can. We just published a course on the popular Fruity Loop Studio, FL Studio, digital audio workstation. This course will teach you sound design fundamentals, mixing, filters, drum sequencing, bass lines, synth melodies, and even advanced concepts like kick drum ducking. You'll play along at home, and by the end of the course, you'll have your own bass house track that you can share with your friends. It's a three-hour course on the FreeCodeCamp YouTube channel. Speaking of music, this week's song of the week is 2022 song Ditto by Korean pop group New Jeans. I like the song because it feels so slow and relaxed, even though the BPM is actually like 130. It's really fast tempo, but you don't necessarily feel it. It's got this weird kind of dynamic. It has really minimalist production. It's mainly just AOA drums and vocals, like heavily processed girl group vocals. And this is perfect late-night listening. And support for this podcast comes from a grant from AlgoMonster. AlgoMonster is a platform that teaches data structure and algorithm patterns in a structured sequence so you can approach technical interview questions more systematically. Their curriculum covers patterns like sliding window, two-pointers, graph search, and dynamic programming, helping you learn each pattern once and apply it to solve many problems. Start a structured interview prep routine at algo.monster.com. Support also comes from the 10,338 kind folks who donate to our charity each month. Join them and support our mission at donate.freecodecamp.org. And you can get your FreeCodeCamp t-shirt and rep the FreeCodeCamp community with pride. I'm wearing one right now. This shirt is extremely durable. I've washed it like 100 plus times. I've got like a whole closet full of them. And I wear it like five days a week. Like every work day, I'm rocking them. And they just fit really well. And I strongly encourage you to pick one up and rep the community. 20 bucks shipped anywhere in the U.S. If you're outside the U.S., just grab our assets from our assets library and you can screen print it on a shirt yourself. But if you want the really high-quality shirt, you've got to come to the stage for that. So shop.freecodecamp.org. And here is my interview with Mike McQuaid. He is a software engineer who previously worked at GitHub and now serves as lead maintainer of Homebrew, a Mac package management tool used by tens of millions of developers. He's based in Edinburgh, Scotland, and he's worked remotely as a dev for nearly two decades. We talk about what a career in open source really looks like in terms of like resources you have available, what the day-to-day is like, what skills are going to be more important going forward now that we have all these AI code gen tools. And he uses them even at his level. He finds them to be useful and he talks about how he uses them and then how big open source infrastructure really gets ridden and really gets maintained. Mike McQuaid, welcome to the Free Code Camp podcast. Yeah, thanks for having me, man. Well, congratulations on the release of Homebrew 5.0. Millions of developers rely on Homebrew as a package manager. And I have to ask, what does it feel like to hit publish on a major release like that and have that immediately go out and be used by so many devs? Yeah, I think it's exciting. It's a little bit scary. Like you hope you've dot your I's and crossed your T's and not broken too many people's things. But yeah, I think the main part of, yeah, exciting would be probably the main word. Yeah. And maybe you can talk a little bit about some of the big improvements to Homebrew. We're going to dig into a lot of your worldview, a lot of your approach, how you use LLM tools and don't use them, a lot of your taste. But real quick, for people who are not familiar with Homebrew, what does it do? So the way I like to describe it to, I guess, less technical folks is it's like a package manager. Sorry, it's like an app store, but for open source software, right? And if people know what a terminal is, then I would describe it as being, you know, a package manager for that as well, right? So if you're a dev, if you're working on software, if you may be used to using NPM or something like that to install your JavaScript or PyPy or PIP to install your Python code or whatever it may be, and if you want to install all of the stuff that doesn't come from one of those language-based package managers, if you're on a Mac and increasingly numbers of people on a Linux, you're probably going to install that through Homebrew instead. Yeah. And you have been maintaining this project for many, many years at this point. How long? 16 years. I guess now that we're in 2026, I guess it would be, yeah, 17 this year, later this year. I mean, it's, you're one of the most veteran open source maintainers I've ever had on the Free Code Camp podcast in 200 plus episodes. And you're not just doing this. You're also working full time. You were working at GitHub for a long time as a dev. How do you balance maintaining an open source project on top of full-time work? Yeah, it's a weird one because I get asked this a lot. And I guess the short answer is I sort of don't really know because I don't feel like I'm doing anything especially different. But I guess if people looked at my calendar and how I spend my week, I think the main thing is I just don't really do very much stuff that I don't think is important, right? That's both on homebrew itself, right? There's a lot of people who spend a lot more time on homebrew than I do, probably on a given week. But also, like in life, right? Like I remember maybe dating myself a little bit when I was in college. There was the line about, you know, like work hard, party hard or whatever. And I think I still have a little bit of that ethos. Not so much the party hard in terms of like, you know, partying in a way that's hard on your body. But like when I relax, I want to take that seriously, right? Like I don't spend a lot of time doom scrolling or whatever, right? Like the things I'm doing in my life, basically everything feels either important or enjoyable or ideally both. Yeah. Okay. So it's more about what you don't do than what you do. Like the negative space of, okay, I've got work. I've got sleep. I've got family. Like what else can I fit in here? That is actually important. And as you said, doom scrolling, which is something I also do not do, is something that you don't have to do. People feel compelled to do perhaps because apps want to draw you in and like waste your time and stuff like that. Everybody's just trying to get time on site, time in app. But you've somehow figured out a way to prioritize around that. And just, you have the same 168 hours a week as everybody else, but you figured out how to use that in an optimal way where you can work as a dev and you can maintain a project. What advice would you give to somebody who is feeling like not everything they're doing all the time is important or necessary in terms of like restructuring? If you didn't know a lot about them other than they were spending like, I don't know, 15, 20 hours a week on stuff that they wouldn't consider particularly important that they could swap out for something that is important. How would you recommend the contract? Ironically, I think it's like, it's both the, like pushing yourself in both extremes in some ways, right? So I actually also play a bunch of computer games, which is maybe surprising, like not huge amounts of my time, but like enough because I find like in 15, 20 minutes of playing a computer game, I can get really relaxed really quickly, particularly if it's some game that I really love and have played a lot of. So, and sometimes I feel like your brain needs that stuff, right? Like I, I found myself during COVID, like binge reading, like relationship advice for other people and read it just because my brain like needed to just have some sort of like junk food for the brain, right? So I find like maybe some of it is like figuring out like, look, we don't, you know, there's a lot of productivity culture out there, right? We don't need to be all working 24, seven, three, six, five, right? You need to have downtime. And actually I think that helps you work better and more effectively. And I think figuring out what those things are and what those compliments are, like another thing for me, I remember when my kids were super young, right? Like when you've got, I know you've got kids as well, Quincy, like when you've got kids who are like sub a year old, right? Like they require a lot of attention to just keep them safe, but not a lot of like intelligence and thought, right? So like really fixating on keeping this little creature alive, but at the same time, like you can feel your IQ dropping by the minute. Yeah. Like that for me, it was a really nice country. I remember one time my wife, I finished work and was like doing some stuff with kids or whatever. And she was like, are you not tired from work? And I'm like, no, because these are exercising exactly the opposite parts of my brain, right? Like I've had a lot of like, use the brain very hard, but like not having to concentrate maybe as closely or, you know, think, thinking really hard, but not moving my body to being like, I have to really move my body. I have to really concentrate. But intellectually, what I'm doing is like, have they got food? Have they got nappy that's clean? Like, you know, that's, that's it. So I think having that sort of approach to your life might be helpful about being like, well, what are your goals? Like maybe just picking one of those goals and being like, I'm going to work on this, this many hours a day or week or whatever. Right. And then outside of that, I'm going to chill really hard. I'm going to find a show I really like on Netflix. I'm going to watch all of it. I'm going to find some game I really love. I'm going to hang out with my best friend, whatever it may be. And I think that kind of like being on or off is what's really helpful. And that's sort of like middle mushy ground of like, I'm sort of working, sort of not sort of relaxing, sort of not like that. That is where I feel like the lack of productivity lives. And there's kind of phantom productivity, which is illusory. It seems like you're being productive because you're responding to some like email just in time as you're getting it or some notification pops up. And you're like getting pulled out of your relaxation time into productivity mode where you're probably in a very mediocre way interacting and trying to nail down that task that needs to be done because you just aren't warmed up. You don't have the focus or anything like that. You don't necessarily have the context. You're just trying to get it done so you can have that. I'm inbox zero right now. You know that vibe. But I would imagine you're the kind of person that doesn't have a whole lot of notifications on on their phone. Yeah. A hundred percent. So I don't, when I was, well, I don't have generally, unless I'm on a work trip, like company Slack on my phone. I don't have company email on my phone. I have calendars just because it's a bit more useful unless, you know, no one's doing me scrolling their own calendar, I would hope. I don't have any social media apps on my phone. I, yeah. So basically my phone, I try to make it as boring as possible. Another hack I found is like the screen time feature that's kind of mainly designed for parental controls. I have limits on certain apps that I use to like waste my time on websites, like Hacker News. Really like Hacker News, but I can spend too much time there. And when my time is up, I don't have the passcode. My wife has the passcode. So I have to ask my wife, can I have more time on Hacker News, please? And she would say yes, but like that's humiliating. So I don't do it, right? Like, and yeah, there's various other little apps you can get that do things like that. They just kind of break that like habit forming dopamine boosting thing. And as a result, my phone is mainly for little distractions or doing work or like just reading a book, right? That's my main, almost like if I have 30 minutes to just relax and spend time on my phone, I've got post-COVID really into just like reading long form science fiction books again. And I love it. Yeah. I'm in the same boat. Like I basically don't have anything on my phone other than like podcast player. I've got the YouTube app because I do watch a lot of good YouTube video essays on like, you know, information security and stuff like that. And also just on history and I'm big into music and stuff like that. So I'll watch about like the history of like some musical piece coming together or something But, um, yeah, like just like you, you, you're really into power lifting, which we'll talk about in a little bit. And you're also very accomplished with it. Uh, and of course, power lifting Instagram, I think is like the main place that people share that sort of content. And, uh, my understanding is you'll install Instagram, fresh install. You'll sign in, you'll go watch your power lifting related videos, and then you delete the app completely after you're done at the end of every session. Pretty much like, yeah, if I'm going on and posting stuff, reviewing stuff, that's generally how I do it. Or I'm, I stay logged in on my desktop computer because it's just, there's something about like, well, I'd say desktop, you know, laptop, but like there's something about not being on the phone that just makes it like a little bit less addictive. And it's just that little like dopamine thing of like, you just pull it out your pocket and you're like, give me something, come on, just give me something good. Like the, I, I just, I have no self-control with that. And I, I will just sit and like all of the kind of anti-doom scrolling stuff. Cause like, I, it's not that I think I have more self-control than most of the listeners here. It's because I know that I don't, it's because I know that I, I am really incapable of using my personal, like mental ability in the moment to stop myself wasting hours on this stuff. Like, that's why I'm like, I just can't have it. Cause like, even, you know, I used to do this with like junk foods where I'm like, I don't prohibit myself from having junk food. I just try not to have it in my house. There's a nice shop I can walk to that's five minutes away that has loads of nice junk food. But I, then I'm pitting, like, I want junk food versus I'm lazy and I want to walk to So like they sort of cancel each other out. And I feel it's the same thing with some of the kind of screen time stuff and phone stuff and whatever is, it's just making it easier for yourself. Like just being like, I give up, I can't handle it. I'm going to just not have this. Yeah. So essentially just putting natural barriers and, and kind of like inventing mechanisms to, to not necessarily forbid you from doing things, but make it inconvenient to do those things that the, the type of behaviors that you want to limit essentially, and not cut out completely, but limit. Yeah. It's like, I, I can't remember who I heard kind of came up with this concept originally, but it's, there's this kind of almost like psychological concept that like, like now you and future, you are almost like two separate people. So like one that came up the other day, like we have cheesy Christmas lights in our house that are battery powered. And they take the same number of batteries. And I always have a gift every year where I take all the batteries out. And then the first thing I do is I go on Amazon and I order exactly the right number Again, I put it in with the packaging and then I forget. And then in Christmas time, I take them all out and I'm like, Oh, I have to buy like 17 batteries. And I'm like, Oh, I have them here already. You give the gift to yourself. Exactly. So I feel like some of this stuff around boundaries is the same type of thing where it's like, I guess maybe it's, you know, Daniel Kahneman's thinking fast and slow or whatever it may be, but it's like short-term me, like when I'm thinking in the scope of like seconds and minutes and I just want to be entertained and I'm a bit bored or whatever. It's like, I don't make good choices. Whereas long-term, what do I want to do in 2026? Like planning my life me? Like, I feel like that person makes relatively good choices. So what I want to try and do is have as many systems and processes and setups to kind of nudge like short-term me into the constrained way of thinking about the world that kind of Right. So like, even like, you know, if I, I mean, you probably can't see, but if I hold up my So my home screen, I have nothing. I removed everything. It's all in the app library. And at the bottom, I just have messages to talk to my wife and my friends, music, to listen to music, podcasts for obvious reasons and books because I'm allowed to read books. And that's like, even that little thing is just like, that's what I've decided. Those are my four most important things. Right. So you want to like, make the stuff you want to do easy and then make the stuff that you don't want yourself to do. Not maybe impossible, depending on your willpower or just even like harder, right? Like if it's, and if it's harder, then quickly you find you will do more of the stuff you want to do and less the stuff you don't want to do. Wow. So that was really cool. For anybody who's listening and not watching the video version, I mean, that was literally like a perfectly empty iPhone with just the four apps in the dock. And that was it. Uh, well, I don't think I've ever seen that before. I also use a lot of tricks like that, but you, you've taken it to the extreme, which I absolutely respect. One question I have for you is, so you're working as a dev, you've got this skillset, uh, that you've been applying to provide for your family and yourself, uh, for, you know, the past couple of decades. And at the same time, you could just go home. You could relax, you could play more video games, you could spend more time with your kids. You could do more of everything you're, that you enjoy doing, but you're instead doing this, like probably compensated in some way, but like largely, you know, volunteer role of helping maintain a major open source project along with a lot of other contributors around the world. Um, why, why spend your time in this way? Yeah. I think that's a good question. Uh, and again, it's one of those ones where like, I don't think about it much until I'm, I'm asked, but I mean, I guess like maybe some of my, my history, right? So I got involved, I grew up in Scotland. I got involved with tech basically just because I was like, I like computers, right? My, the first time my dad brought a computer home, I was just fascinated with this thing. Like he found any boring task he could get me to do for him as long as it involved the Right. And then when it came time to go off to university and all that type of stuff, then I was just like, I just want to do computers. And at this point, and particularly maybe for some of the younger listeners, this might be kind of hard to believe, but at this point, particularly in Scotland, like being a software engineer was not a particularly, you know, affluent or prosperous thing. Right. Like I grew up in an environment where it's like, be a lawyer, be a doctor. Those are like real jobs that like pay well and all this type of stuff. Right. And I sort of rebelled against that. Cause I was like, I don't know, man, I just like computers. Um, and then, yeah, like, I guess I fell into an industry probably at the lucky inflection point time when a lot of these jobs became a lot better compensated and more important. And, and the internet was taking off more and all this type of stuff. Um, so for me, I guess like that, that's kind of the same reason why I do a lot of it is that I just, I just love it. Like I, I, I still enjoy doing what I do. Like there's a certain amount with homebrew specifically where I'm like, you know, I might kind of grumble about certain things sometimes or not want to do this very specific thing And I'm like, yeah, but lots of people use this, right? Like, and it's a, it's a kind of useful, like contribution that I find anywhere between neutral to actively enjoyable and it benefits a bunch of other people. Um, so yeah, I guess that's, that's kind of why I do it. Um, and even, even the how, right. So like I have slightly more kind of blurred lines, right. Where I've worked from home exclusively since 2009. Uh, so for me, like 16 years, 17 years now. So I was doing it before COVID kind of made it cool, I guess, but like, as a part of that, like a lot of stuff that, you know, was, I, again, most of that time was for companies in different time zones or whatever. So as a result, like the whole, like you clock in at nine o'clock, you clock out at 5. PM, right. Like it's, that's not really been my life or way of working for that. So I don't have as strictly regimented, like this is, you know, work time and open source time for relaxing and whatever it may be. So these lines get like a little bit more blurry on that. Um, and I think also partly because I think this stuff kind of cross pollinates a bit as well. So, um, I think the work I, you know, everywhere I've worked pretty much like a reasonable number of my coworkers have used homebrew. Right. So it's like, well, I'm, I know that work isn't telling me to like release this fix, but I know my coworkers are going to need it. So, um, that seems worthwhile. Right. Like, and, uh, and again, maybe there's a little bit of career advice in there and that like a lot of the stuff I've done, like I'm a lot of my life and maybe balance or whatever is less about doing like, Hey, what does my boss really want me to be doing all of the time and more about like, well, you know, it's a balance between what do I want to be doing? What's my boss wanting me to be doing? What's the company want me to be doing? What do I think is best? Right. And we'll try and find some like blurred version in which everyone is like reasonably happy, but like maybe not. I used to joke with some much higher achieving coworkers than me at my, uh, at a previous company that like they should aim to get worse performance reviews because actually like they are, you know, doing exceptionally well, making everyone really happy. But in terms of like what that actually means in terms of their take home pay or compensation or impact on users or whatever, like they're like working 20% more and they're having 1% Whereas I guess I'm maybe just like a deeply lazy person or something, but like my thing is always like, what's the point at which me putting in another hour on this task delivers dramatically diminishing returns. And I just try and just not do that. Like all over my life. And that's again, maybe how and why I've found more space that other people might find difficult. So you've cultivated this instinct of, okay, this is declining marginal value, essentially like, like the average, you know, minute put into this task, the, the output is dropping and you, you developed kind of an intuition for when you should just log off essentially. Um, it sounds like that is a really cool, uh, skill that you've developed and, uh, your, your advice aimed to get worse performance reviews. Uh, because obviously the company just wants you to stamp out as many widgets as you can Right. Uh, that's, that's how managers are evaluated generally. What's the productivity of your team? How is that measured? All that stuff. And what you're saying is like, like there comes a point where you really do need to just, um, go do something else. And it's, it's not necessarily worth your time contributing even more to this manager's objective. Yeah. I, I mean, I think that's sometimes the case. And also just sometimes like, you know, the number of hours you put into something, like you can distribute them differently and get a similar result. Like something that sprung to mind was like, I wrote a book about Git a very long time ago. Um, and I was encouraged to almost be like, as a first time author, like, you know, do a little bit every day, slow and steady. And I would have two week check-ins with my publisher. But what I would do is the check-in was on a Monday. On Saturday, I would just sit at a keyboard and just write until I hit the page count. I wouldn't even read it back. I just write and write and write. And then I hit like, you know, I was trying to do 20 pages or whatever. I hit the end of page 20 and I would just stop and log off and be like, right, done. And then on Sunday, I then come with like fresh eyes and I'm like, I don't have to write I've done the writing. And then I would just read through it all and be like, this is trash, this is trash, this is typo, move this around, blah, blah, blah, whatever. And again, like that approach, I think if I, it would have been perfectly possible to do it in one sitting, I think, but it would take way longer and the output would have been worse. But instead you almost like carve the task in half and you rely on the fact that some things just do better for you coming and looking at them the next day. Right. Like, and, and that, like, it's, yeah, those types of like little weird approaches and ways of looking at things. And I think that kind of comes on with like, say like at work, right. Like where, when I was at GitHub, there was, people would talk about like, oh, I, I want to see, you know, my boss or the manager or CEO, I want to see a shitty first draft of Right. My version of shitty first draft would be like, I do no research. I just like type, I don't even read it back. And then I would send it to my manager. Like, and sometimes that would be perfect because she would say like, okay, like this is interesting, but like this full typo is like, you know, clean this up and we'll send it on to someone. And sometimes she, that would be enough for her to read it and be like, yeah, we're not Okay, cool. And if that, and if that was the case, right. If I put another hour of time in, if I, if I spend an hour instead of five minutes, then it's like that 55 minutes, which is completely wasted. But to go back to what you said before, that was work. I was working. I could have been working for another 55 minutes. I could have stayed later. I could have not done something else, whatever it may have been, but that would have just been like lost to the ether. Like, and it's, it's hard because I also feel like maybe it's like a, without getting too philosophical, like an education system stuff. Where we, we grew up and often like, if you're like, if you do well in school or high school or college or whatever, it's like, do all the things to your maximum ability, try and get Like, and then if you do that, then you will be like happy and successful in life. And it's like, sometimes for some people, sure. Like, but for me, like I was, you know, in school, my teachers hated that attitude of like, I'm going to do the minimum required effort to get an A right. Like they really did not like it, but like, actually in the workplace, like your boss might not say that, but like, sometimes like, how can I get to a good result as quickly as possible in many contexts, that's the most valuable thing you could possibly do. Right. And actually like delivering something like 1.5 times as good in twice as much time is not what anyone wants. But they might not ever tell you that that's, it's a hard, and your manager may not actually consciously realize that like, Hey, you just saved an hour of time because, uh, like you gave them what they wanted and they were able to evaluate it and make their decision that you didn't have any power in any way, uh, as to whether this is a go, no go situation. And then you went and spent that extra hour doing other work that is getting things done that the company wants to get done. Uh, so you kind of like help them manage you in a way. Yeah. And, and the, this is one of the things that like, not to get too organizational philosophical, you have a podcast where you just talk about organizational behavior, open source maintenance philosophy of being a manager, all this stuff, which is really cool because you were an IC for like so long and individual contributor. And then you got into management like much later in your career. So you have a lot of context from both sides. But, uh, one of the things that I think is really interesting is if you just give people a lot of trust and you give them a whole lot of slack, they can prioritize things for you and they can put the right amount of time into things for you. Like our staff at free code campus is 29 devs, uh, many of whom have teaching backgrounds And essentially I just like tell them like, go do what you think is the most important, get other people to help you with it. If you think it's so important and then let's just see how that goes and just check in and tell me what you're doing. And then I'll kind of give you a feel for like whether I think that is sufficiently important to do right now. Cause in a perfect world you do everything, but there's that time trade off. Everything has a marginal cost associated with it. And so by pushing the decision making down as close to the person actually using their hands to execute that work, you are making the organization way more, uh, efficient because you're not abstracting that up and giving, you know, those decisions to somebody who's several layers of abstraction removed from the work being done. Yeah, I, I definitely think like there's so much wisdom in what you were describing, right? Like high trust cultures are so helpful. Like everyone likes being in them, uh, but they are sometimes hard to build. And also sometimes part of like building that culture, at least in my case is like doing the work on yourself, right? You might not naturally be someone who's very good at trusting or delegating or whatever. And that's also a skill that you can work on, right? That requires you to admit like, Hey, maybe I'm not as great about this thing as I thought. Yeah, absolutely. Well, I want to talk about that and we'll talk about management a little bit more, but I'm more interested in talking about being managed and the day-to-day experience, uh, cause you have worked at well-funded tech companies like GitHub, for example. Uh, and then you've worked at scrappy open source projects where you're trying to do more with less essentially, or, or even get by with like fumes essentially. Uh, what can you compare and contrast the, the experience, uh, your day job as a dev working at a well-funded tech company or even like a moderately well-funded startup versus open source? So, I mean, they each have their pros and cons, I think is the interesting thing. Cause like, if, you know, if, if I never had to work again, like financially, like I would likely still do open source forever, but I don't know what types of, uh, professional work I would do or not do forever. And some of the reasons for that are, you know, like often when we're building open source, we're building something in a problem space that we as an individual deeply care about to the point that we don't have to be given any financial incentive on top of that. Whereas when we're working in a job, right? Like a job is a job, right? Even if you love your job, like for most people, if you were like, will you keep doing this indefinitely They would say, ah, no, I have, I have things I would rather do for free. Thank you very much. But also again, like pros and cons of that, like jobs and places like GitHub, like I joined, uh, in like 2013 when they had 200 and something people I left in 2023 when they had like just under 4,000 and, you know, you see a lot of change and structure and growth and process and bureaucracy and product managers and project managers and technical project managers and hierarchy and all this type of stuff, which, you know, sometimes at the time as slightly rebellious, icy type, open source type, I'm like, ah, this is all unnecessary. And then you realize like, actually, it's really helpful and it's really nice. And sometimes it's just much quicker to be able to say, hey, I'm your boss. We've had a good chat about this and now you have to do it. Whereas in, in open source land and even, I guess the difference between being a manager and being an individual contributor, right, you can't do that. Like in some ways, manager, individual contributor, like open source contributor or open source leader or whatever, like in some ways they're kind of a spectrum because when you're an IC, like there's someone in the middle, like when I was a principal engineer at GitHub, right? Like I was, you know, important fancy principal engineer, blah, blah, blah. Like I've been there a while, but I don't have any direct reports who I get to tell what they work on, right? I don't have any budget. I don't have a team. So I have to just convince people that things are a good idea. And that's much the same in open source, right? If you want to be an open source leader and you want to get volunteers who are being either unpaid or paid, I guess, in homebrew's case, like incredibly below market rate for like what, what work they might be doing, you have to convince them like, Hey, this is a good Let, let me like almost like plant the flag and, you know, lead the rallying call for like why we should care about this thing and why you should come and get involved with me. Right. Um, on this project or whatever. And yeah, that's, that's tricky. And it is harder to do that than it is to just be like, I'm your boss. You have to write. Yeah. But at the same time, like the, I'm your boss. You have to, that high trust environment you described before, like there's only so many times you can do that before you kill that, but people, people want to feel particularly as you progress in your career, particularly when you're doing stuff, not for money and in your spare time, you want to feel like you have like the ability to decide what you work on and how you work on it and what the output is. And you don't want someone to just be like, I don't know, like, I guess we've both got guitars in the background, right? I'm a bass player, right? And the worst, uh, microaggression a guitar player could do to a bass player. It's just being like, yeah, man, I want you to play like, like this. And then just like play plucking on the bottom string, exactly what they want you to play as if it being like, ideally we would just clone me, the guitar player and give me a bass and I would do it. But unfortunately we have you here. So I have to tell you what I would do instead of me just doing it. And, and sometimes in the workplace, it could feel the same way. Like if someone is just being like, I would ideally do everything myself, but I can't. So you have to do it my way. That doesn't feel nearly as good as someone who's like, Hey, I think you're better at this Like, here's a problem. Do we agree? This is a problem. Great. You go off and figure out how to solve that problem because like, you're going to figure this out better than I will. Right. Like that feels great to be on both sides of that. Yeah. So be like Slash. Don't be like Billy Corgan who insisted on recording all the guitar and bass parts himself and didn't pass his musicians on the other musicians on the band to record good takes. Yeah. And not pulling rank. Very important. Lesson for that. You can only pull rank so many times before people just start talking behind your back, making fun of you for being some guy with the stick of their butt, you know, like who doesn't necessarily have the merit who was just given the power over you. When you're in an open source community where, as you said, like everybody's doing this mostly because they care about the mission and things like that. There is that very fragile kind of like motivational purpose, like the sense of purpose that people And you don't want to disrupt that. And I want to talk a little bit about how homebrew is administered. I know that you've been elected repeatedly as homebrew's project leader by the community. And there is infrastructure that like essentially gives you power. And that power could be given to somebody else or it could be taken away from you if people disagree with what you're doing. What is it like running a major open source project day to day? Yeah. So, I mean, I think the day to day side is, again, much like, you know, any good or healthy team, like there's not a lot of kind of intervention required, right? Like everyone's just like buzzing away doing their own things. But I think the kind of tricky part of the leadership side is the, I guess, you know, dealing with crises, right? Deciding how and where and what needs to be done. And sometimes like being the person to kind of resolve some gridlock or push through maybe a slightly unpopular decision, right? So, it's funny because if you read Hacker News, which I do sometimes, when Homebrew comes up, like there's a lot of people on Hacker News that don't like me specifically and some of the stuff I've done with like leadership and whatever around Homebrew because some of the stuff I've done has been maybe forcing through some of the most controversial changes. But that's not because I unilaterally was the only person who thought that should be done. It's because I felt able to do that and to lead the charge. Yeah, you have to be the face of the changes and bear in the front. Yeah, for sure. And also, sometimes it's like, you know, when you don't know how the sausage is necessarily made, it's like there's things where, sure, would it be nice if Homebrew could do this feature or support this workflow or whatever in perpetuity? Like, yeah, sure. But like, we're a bunch of volunteers scattered around the world. We're not really paid. Like, so with that in mind, like we have to, it comes, I guess, back almost philosophically to what we were saying near the beginning, right? It's saying no to things and being like, well, what can we do and what can we not do? And I think one of the things, it's a bit more questionable now, but I liked with being in the Apple ecosystem, right? Like, ironically, the first Mac I bought was six months before I became a Homebrew maintainer and, you know, have worked on it ever since, right? But something that always influenced me about Apple's approach to software development, maybe a little bit more back then, is it's like their goal was not to give you all of the functionality that every other alternative would provide. Their goal was to be like, the functionality we provide will work well. It's not about just like ticking a box and being like, you can share, but it's a bit janky and it's a bit buggy. It's going to fail 15% of the time. As I say, unfortunately, some of this is maybe crept into the Apple ecosystem now, but it was about like, what can you actually do that's going to deliver a good experience for the vast majority of people, the vast majority of the time, right? And some of the controversial stuff that has been removed or changed to one of our Homebrew was because we could not deliver a great experience to most people most of the time. And if you're one of the kind of, you know, power user types, then that can be very frustrating because essentially we're taking a very powerful tool and we're making it less powerful because some people can't file issues correctly or whatever it may be, right? But like, that is the way the world is, right? And the problem is, and this is maybe another philosophical thing, but the problem is, is that the people, you have to have an open source. You have to let the people who are bearing the brunt of the pain of these decisions be the ones who make the decisions, right? Like there's been a lot of talk about like community involvement and users in open source and in Homebrew among all open source projects, pretty much like we do listen to users and we do take feedback or whatever, but we're not, it's not a democracy, right? Like we are the ones doing the work. If we, the maintainers stop doing the work, the project no longer exists, right? So as a result, we have to have something that allows us to work sustainably and indefinitely on the project. And if that means that we do something in a direction that you don't like anymore, then Mac ports is another package manager for Mac OS. And people, when I say that, they think I may be being like, you know, telling them to piss off or whatever, but it's like genuinely, I'm like genuinely this other tool may be a better fit for you now. And this Homebrew maybe was the best tool. And then maybe Homebrew is not the best tool for you anymore. And that for me is not, it's not a sad or an emotional thing. If someone decides another tool is better for them, right? That's a good thing. And in a weird way, I probably thought maybe long before today, right? Like at some point, Homebrew will not be the best tool for anyone anymore. And people will just stop working on it because everyone's moved to something else. And to me, that's not sad. That's just how technology evolves and computers work and whatever. Right. And every individual that kind of makes that move, I think is like part of that transition in that process. And we just need to be like, understand how that is. And it's a very different proposition to when, if someone is a customer of a company and if all the customers go away, the company no longer exists and no one gets paid and it gets shut down and whatever, like Homebrew, Homebrew's code will always be there forever. Right. Like it would be on the internet and our users are not customers. Our users are people who use the software and maybe they contribute, maybe they maintain it for however amount of time, but like it's, it's very different. It's more like a, you know, a co-op or a free food stall than it is a business. Yeah. And free code camp is similar in the sense that, uh, regardless of what happens, like a free code camp ever just ceases development. Hey, it's open source fork it and you can run with it. Um, and I think it's important that there's that release valve, uh, Apple's philosophy of just doing a few things, but doing them really well. And here's the functionality here are the different API calls you can use in Xcode and But like, these will all work pretty reliably. Uh, I, I, that I'm not like a huge Apple fanboy like you. I switched to Apple from like Linux cause I was working at a shop, uh, that, uh, when I say shop, like, like it was a rail shop. We were using Ruby on rails and they said, Hey, everybody works on Mac. It'd be a lot simpler if you're on Mac instead of, you know, Debbie and I can't remember which distribution I was on at the time. Uh, and, and that's how I got into it. And, and then as I used it more, I did come to respect a lot of the opinionated decisions, you know, the convention over configuration essentially of like, here's how we're doing things. If you don't like it, there are ways to like go and do your own thing, but like, it's not And it sounds like that is part of your philosophy as well, at least as how you steward the open One of the things you've mentioned that I thought was really interesting in the past is if somebody opens like a feature request or an issue and you're not going to do it, you don't give You just immediately kind of shut that and you're like, Hey, that's not what we're going Uh, is it hard to just constantly put down people's feature ideas and people's bugs? Yeah, it is in some ways. Um, I think that, I mean, you get, you get a thick skin off to doing it for a while. Cause like most people accept that, right? Like, and I just, there's a lot of things in life and in our industry. And whatever, where I think you make the choice between short-term or long-term kind Right. Like, and I've always been in lots of areas of life. Like I favor the kind of like short-term pain, long-term gain sort of thing. Again, back to the metaphor with kids, right? The, it's the times you catch yourself saying, well, only this once. And you're like, yeah, that's, that's not going to be a good idea. Cause my kids are not going to accept that this is a thing that happens once. They're going to want to do this again, again, again, again. Right. So like, maybe this makes my life easier right now to do this, but I'm again, current Mike and future Mike, like I'm, I'm like taking out like debt for future Mike and current Mike is benefiting that. So let's not do that. And I think people understand when you do that with their issues and stuff as well. Because, you know, I'm not going to name any names, but there's plenty of projects out there that have a hundred thousand open issues. And realistically, the vast majority of them are never going to get done ever. Right. And, but yet on a bunch of them, if someone went and closed it and said, we're not going to do this, then a bunch of people will be like, ah, but it's like, but like literally the natural state right now, again, maybe too much philosophy in me, but like the natural state is this thing is not do, is not done. You are proposing thing be done. And the current situation is it's not being done. So in the absence of someone doing it, it will not be done forever. And I think in a homebrew, but because again, we, we get a reasonable sense of like, sometimes when issues come in, whether it's like, okay, anyone could fix this pretty easily. Right. Or only someone a little bit more seasoned could fix this. Or like in sometimes cases in homebrew, there's some probably bits that it's like, okay, probably only two or three people have enough context or understanding to like fix this. And if something comes in that affects a tiny number of people that only two or three people can fix and those people are not interested in doing so, then it's like, well, let's not pretend. Right. Let's not lie to ourselves and be like, yeah, we're going to do your thing when we're not Right. And that actually, I think works reasonably well. And like, in real life in some ways as well. Like in, you know, if we've got friends who are treating us badly or, or even just like, you know, I remember in the early days of Twitter, I had a good friend who I would happily spend hours chatting with in the pub. And his Twitter, I followed him on Twitter and then I unfollowed him on Twitter. And he was like, oh, why did you unfollow me? And I'm like, cause you're not very interesting on Twitter. Like I will go to you and sit with you in the pub for two hours and listen to you talk about Cause you're fascinating. But on Twitter, like that it's not helping either of us like me following you on Twitter. And some people would look at that and be like, you know, you're excessively blunt or whatever it is, various other unkind adjectives. But, um, I guess I've just, you know, maybe it's my life, but I I've reached the age now where most people around me kind of accept that and actually value and appreciate that. Cause the nice thing of knowing someone like me is if I say like, you did a really good job on that. I'm not saying that to make you feel better. I'm saying that cause I actually think it right. Like, so people do tend to appreciate it when they, they learn that you're someone who is not just going to blow smoke up their arse and pretend that everything's going to be Um, but yeah, but it does sometimes take an adjustment and that's why, again, you know, if you look on Hacker News, like people will pick out like individual comments I made and they're like, that was very unkind or Mike's a dick or whatever it may be. And it's like, yeah, but I made 10,000 of these last year. Like, of course you will be able to find a bunch of places in which my communication was Right. But we're not talking like Linus Torvald ripping into a contributor or anything like that. We're just talking about you bluntly saying, sorry, we're not going to do that. Yeah. But I mean, even, even folks like Linus Torvald's right. Like, I think when, when you've been doing this for a while, you definitely, I wouldn't criticize how he runs his project because like, I know that it's hard. And I think it's not just that it's hard, but it's like, it's like, when you're an open source maintainer, it's like, okay, imagine you're a manager in a company, but every performance review you do, you have to do in a stadium with a hundred thousand people watching you. It's like, when are you not going to say the wrong thing sometimes that people aren't going to like, right? Or like, look at like, in some ways, like reality TV, right? Like we all watch reality TV and we're like, oh, well, no, maybe we don't. You watch this drug from reality TV. But like some of us watch reality TV sometimes. And it's like, you look at people and you're like, oh, they're so terrible or whatever. And it's like, yeah. Like, you know, they're just a person. They're just a horrible human being. They combed through like hundreds of hours of footage to find that moment where that person was in, you know, a moment of weakness, right? And yeah, you know, to credit to Linus Torvald, whom I have an incredible amount of respect for him, Torvald, he has sought anger management and he's acknowledged that he should not be behaving this way, but it's not like he's going to completely mellow out. Exactly. At the point, like there's a saying about kids will say, you're mean, but what the really saying is you mean what you say. Like when they talk to the parents, right? And I think that's like, it's kind of like a parental philosophy. Like, oh, if I entertain the notion that soon, you know, homebrew is going to have unicorns and stuff like that, uh, leprechauns and stuff like that. Like that, that's, that's ridiculous. Like, like we're never going to do this and I'm just going to nip this in the bud, so to speak, uh, before people's expectations start to get out of whack. Uh, that's kind of like how you, how you shut those down. And also like, I try and like, I guess much like the, the parenting example, right? Like the other thing I try and do is be like, you know, I'm not always right. And I'm willing to change my mind. And, and even in times when I'm not willing to change my mind, if someone's like, Hey man, like sure you closed the issue, but you were a bit mean about it. Then I try and make sure I'm like, I'm sorry, but like, it's not, it's, it's easy to say And again, you know, maybe kids, family, whatever, like advice is like a willingness to kind of admit when you're wrong and say, sorry. But the problem is again, the, like the performance review in the stadium analogy, like often it's the people who are most annoyed with me, we're not even part of that conversation. Like they're, and I, I don't feel like I owe them an apology based on something I said to someone else who isn't upset by it. Like that's, I don't know why it's, but again, it's kind of weird. Cause like we, we just don't, I don't think our brains as humans are very good at processing how to do this stuff. So I think like I met with someone who's, you know, very involved with a bunch of open source maintainers and she said like, yeah, I, I think it, you probably just all get a very thick skin and that makes you a different sort of person. And I, I think that's true. Right. Like I, I have to like remind people at work who criticize my work or whatever and are worried that I'm going to get really upset. I'm like, look, like whatever you, even if you tried to say the most horrible thing you can imagine, like people have probably said worse in my inbox over the years. So don't, don't worry about it. Right. I can tell the difference between it coming from a good place and a bad place. And again, maybe that's part of it as well. Like another thing you, you, you learn in open source pretty quickly, right. Is if someone is, you know, like now that we've got code of conducts and all that stuff, if someone's indulging in bad behavior in really any, again, be it the workplace, be it open source, be it a friend. If you can just say to them relatively calm and collected, like, Hey, that's not cool. Like you've upset my feelings or you're not doing that or whatever. Like for me, there's that pivotal moment where even if they give you the worst apology ever, cause they've never learned how to apologize properly where they're like, I'm sorry that your feelings are hurt because blah, blah, blah. Like if, if you are like, that seems to be actually coming from a genuine place, then you Right. But if that person, when you point out like, Hey, not that great, like their response is to double down and be like, fuck you. Then it might be like, it's just never worth putting a lot of energy into that because it never, it never works. You're never going to, as, as much as I have tried and will probably still continue to try, like you can't shout at people on the internet to a point where the two of you will just all get along, right? Like you can't reach everybody. I mean, some people are just, they, they need something else in their life to, to happen, to be a catalyst for change. And it's not going to be you talking to them. You're just, you're just in the way, right? You're collateral damage as they storm through their day. And that's something else I always keep in mind. Like the person I'm talking to on the other side of this comment or this email or this GitHub comment, you know, like this is a human being. They're just trying to make it through their day. Who knows what kind of horrible stuff has already happened to them today? You know, like, cool, whatever. But like, I don't have to interact with them any further. I'm just going to politely disengage or block them if I have the means to do that so that they don't do this to other people. And we're, we're going to move on and hopefully, you know, they're going to, uh, find serenity and, and find the impetus to change and not be a dick. But, but that's the thing. It's, it's, it's hard, right? Like it's, it's hard to do that. And it's hard to get like, I, I, my partner and a bunch of family members work in healthcare, right? Like, and generally people who work in healthcare are really good at that because like, why are they doing what they're doing? Like most of the time it's because they want to help people. Why am I doing what I do? Right. Like, so at the end of the day, like if, if I could somehow do homebrew in a way that involved me never talking to another human and just talking to the computers forever, I'd Like that's, that's, that sounds way better to me. That's not how the world works though. You do actually have to talk to other humans. You do. You do. Um, but, but that's the thing. Like, so I'd be the first to say like, you know, my, my people skills on this stuff and particularly that skill you mentioned right there. And I do think it's a skill that you can get better at, of being able to be in that situation where someone is, you know, on the internet screaming in your face and think to yourself like, wow, they're having a bad day, right? Like they're, yeah. Like what's happening in their life right now that is making them feel so intensely about Right. Like, and I think that's a valuable thing when you can do that. And I guess maybe pivoting back to work stuff, like, again, like that's an incredibly valuable thing to be able to do at work. And I think the more senior you become, like if, you know, the company I'm in right now, I'm like the CTPO. So I'm like the most senior technical person in the company. Right. Like, and to me, that means part of what that pay and title, whatever comes with is it's like, I need to take a lot more stuff on the chin than the, the person who just graduated And they're just, you know, new into the industry. Like as you rise through the ranks and you, you get that stuff, it's your job to like figure out how to be able to like emotionally regulate yourself, how to be able to be sympathetic and empathetic to the people you work with and your customers and your coworkers, something Right. And that's, I think like part of what it is, but the beautiful thing about that, right. Is if, if you get better than that, you're probably going to also be a better, like, like husband, wife, dad, mom, like friend. Like, yeah, it's, it's, it's a skill that works in all directions. Right. And it's so useful. Like the other, like I drive really slowly, especially when I have my kids in my car, like I'll drive like five minutes, five miles per hour below the speed limit. And in Texas, that's like, that is not cool. Like people get really pissy. They honk at me, they drive around, they flip me off, they whip around me in a very dangerous fashion to, in some sort of weird, uh, you know, machismo, uh, display, but it's cool. Like, like they're having a bad day or they're in a hurry to get to their job or something Like I, I don't take it personally when people, you know, do that. I'm fine with driving like a proverbial grandparent, you know? Um, and it actually helps me boost my temperance because I'm, you know, dealing with more hostility throughout the day. Uh, and, and that is one thing that I consider myself really good at is not losing my cool and trying to like absorb that energy without bouncing it back. Right. And it sounds like you've gotten good at that. Uh, and I think this like, we're going to get back into open source software development and stuff like this, but this is a great time to talk about like your habits because you are very much a creature of habit. My understanding is you have these recurring things that you do like every week and it's years, years and years. How long have you lived in Edinburgh, Scotland? Yeah. So I've been here, I was born here, uh, I guess I'm 41. So like on and off, I've been here the majority of my life, probably at least 30 of my 40 years I've been in the same city. Um, and you know, there's a lot of nice things about that. Right. I have my best friend from, uh, like high school, my oldest friend really, uh, we come around, he comes around like once a week. We watch sci-fi together that my wife doesn't want to watch. Um, and yeah, like it's, there's lots of nice things from just having that continuity. And similarly, I guess with like habits and stuff, right. You, you get good at things by just doing them lots and lots and lots, right. Like, and trying and repeating and whatever. And I think I've got like become a reasonable software developer, like, and various other things in my life by just doing it lots and regularly. Like, and I think there's a lot of these things where it's interesting. Like there's a famous, uh, Scottish cyclist, a guy called Chris Hoy, who's at one point, I think had more Olympic gold medals than any other person. Um, and I remember hearing him speak one time and he was saying, he was like, if you were asked in my school, like who, who was going to like win a gold medal in the Olympics, like you wouldn't have probably put me in the top 10 people. But the difference with me compared to everyone else is I just was just very consistent over a long period of time. Like I just had my training and he just trained hard, train hard, train hard, train hard, train hard, train hard, train hard, and did that. And, you know, I'm not going to put false hope in people's heads and say that like anyone can, you know, if only you just are consistent, you too can win more Olympic gold medals than Right. But there will probably be some stuff where you can go from being like average to being great, right. Just by being consistent and putting the time and effort in. Right. And that's a perfect point for us to address the fact that you are currently the Scottish champion for the M1 division of, I think it's like 81 kilogram body weight powerlifting. Is that correct? Yeah. So I guess a fun parallel between powerlifting and open source is like every time you do a powerlifting competition anywhere in the world, that's like a sort of officially sanctioned one, there's a site open powerlifting.org and they have all this open data on GitLab. And so as a GitHub employee, that was the first thing that got me to sign up for a GitLab account actually. And they have the site that's updated once a day that just has all the results for everyone. Right. So you can go and look and if you hear someone does powerlifting, you can like look them up and see what they've done or whatever. Yeah. So yeah, so like in, it's not small country, not huge amounts of competition, but yeah, like in my age and weight class or whatever, like I've won it the last kind of couple of years and hope to win it again this year. And yeah, and that, that's a classic example again of what you've said of like, it's just going to the gym a bunch of times, doing the same things a bunch of times, creature habit and slowly but surely you kind of progress. And it's fits and spurts and whatever. And cause it's very numerical, you can like literally see and be like, okay, it went up and then it stayed still for a while and then went up for a bit and stayed still, whatever it may be, you know? Yeah. And I don't know a whole lot about powerlifting. Like I, I got kind of freaked out when I was doing some heavy squats. Like, am I going to damage my spine? Like, am I going to be permanently injured? So I, I, I like, uh, but I never actually formally like competed or did power, but I did all the powerlifting exercises as part of my weight training regimen. And, uh, and, and my understanding is there's the three main exercises, uh, and correct me if I'm wrong, but just for anybody who's not familiar with powerlifting, so you can understand what we're talking about, you're squatting heavy amounts of weight, you're benching heavy amounts of weight and you're, um, what's the term for deadlifting, deadlifting. Thank you. Uh, and essentially those are the three main powerlifting exercises. And then you take the total amount of weight and you add them together and that's your like number essentially. So it's a very quantitative, uh, area of athleticism. Can you talk about like what your training range regime is regimen? Um, and like, uh, how you go about just like when you go to the gym, how frequently you go to the gym, like all that stuff. Just give us a very high level overview of sure. How you've managed to remain the champion for several years in a row and, uh, how you approach this in such a kind of like disciplined routine oriented way, as opposed to just like cramming essentially. Well, so the funny thing is try to do that too. Yeah. So the first year that I became the champion, uh, I was the champion essentially by default because no one else qualified in my age and weight class, right? Such that it, I was the one person who competed, but I still did it and did legal lifts and whatever. So sort of still counts, but like, it's, you know, just to deflate, uh, my ego somewhat. But I think the thing I get to jump back to something that you said that made me feel, uh, it's kind of interesting. It's like that, that fear, right? Like I, that's another thing, I guess there's maybe a running theme in this podcast of like cross cutting things, right? Well, so for me, that fear, like if I've got like, for me, the squats, the scariest one, like when I've got a heavy squat on my back and I need to go do it, that feeling is almost identical to the feeling of like when I've done a bungee jump. And it's also almost identical to the feeling before I go on stage and do a talk or amongst a big crowd or when I've been in a pay negotiation and I like say a number that I feel like a little bit uncomfortable with, or I'm in a job interview or whatever. And it's, it does, it feels like all of these things are kind of training, right? Like in forcing yourself to do things that are maybe uncomfortable to you. And that crossover is kind of useful, right? Um, I guess to your specific question, like I go to the gym, like sort of depends like anywhere between kind of three and five days a week. And I have like a coach, um, shout out if anyone, you will do online programming for His name's Keir White. He's based in Scotland. You can look him up on Instagram. Um, if you're interested, but yeah, he's, he's been great. I've known him before. He was my coach. I've had a few coaches in the past and yeah. And you basically just like go to the gym, lift the weights with the numbers, record a video, send it to your coach, tell him like what you think you did well or badly. He tells you what he think you did well or badly repeats for many years. Right. I guess I've been doing it for like essentially that pattern in some form on and off for like eight or nine years. Um, and I probably have gone, you know, probably coming up to eight or nine years of doing like at least one sort of squat bench or deadlift in a given week for probably that whole time. And yeah, it all sort of adds up. And I think that's the other thing that's sort of nice about it, like about sort of strength training stuff is there's no, there's no like easy fixes, right? You can't go from having never been in the gym to the strongest in the world in a year. Like that's, it's just impossible. Right. Um, and there's also like a lot of things in life, there's shortcuts, right? There's, um, different approaches and different ways of doing things and compromises and And there's things like risky, like, uh, training regimens that are more rigorous, but could increase the likelihood of injury. Or like, I guess like performance and hunting drugs. So like, uh, various sports, including powerlifting have, like in some sports they're banned, right? But in some sports, it's like, you have people who use them, who have their own division over here and people who don't use them, they have their own division over here. And the people who use them are generally much stronger. They look much better, but there are particularly sometimes long-term health consequences of these things. So, and I'm not going to tell anyone what the should or shouldn't be doing, but like, for me, that's like the priority is my health. So I'm not going to go down that route. Um, and yeah, and I think that sort of applies maybe again, tenuous metaphor, but like a little bit back to work in the workplace again, right? Where there's, there are shortcuts to get ahead, right? There are ways of like burning bridges and using people and stomping on other people and lying and being deceptive or exaggerating things or whatever. But again, all of those things feel like if you're really in this stuff for the long game, like that stuff catches up with you. Right. And the amount of people I've worked with where they treat their coworkers appallingly or whatever. And it's like, and then five or 10 years later in their career, they find things are a little bit harder than they used to be. And that's because maybe no one's written anything on the internet about it. Maybe no one works at the same company, but people talk, right? And if you're someone who consistently treats people badly, the tech industry is a surprisingly small place and people hear about it. Right. And the other way as well, right? If you're someone who I've had a bunch of coworkers, I'm sure you have as well, Quincy, where it's like, they're just a saint. And like every interaction I've had with them is amazing. And when I get the chance to like, one of my favorite things in this industry is when one of those people is like, will you give me like a reference for a job? Right. And I'm like, yes. And I can just go on and just be like, let me tell you why this person is absolutely incredible and really amazing. And like, it feels great. Like, it feels great to reward their good behavior with being able to like tell someone else, particularly with what I said before about me being the type of person who doesn't If I actually think they're terrible, then I don't give those references. So, yeah. So one way to look at it is like the wheels of justice turn slowly, but they do turn in the sense of there's like kind of a karma. There is a reputation that may be unspoken in many ways, but like at the end of the day, would you recommend this person for the role? No, I wouldn't recommend them because they're a dick. Right. They're toxic. Uh, they're, they're, they're, they're trying to be like that guy. Like I would encourage everybody to check out this movie. It's, it's not safe for kids, but, uh, I saw this movie called Nightcrawler. It's just like about the sociopath who like climbs the ranks and just, you know, he'll do anything to get ahead. And, and it's repulsive and the acting is incredible. Uh, Jake Gyllenhaal. Um, and, and like, you're going to recognize that these people are out there and, uh, they're not going to be able to sustain themselves longterm. There will be comeuppance eventually for them. And, and that is one of the things that, that gives me like when I have to interact with such a person, they, they give me a little bit of solace. It's like, they can't get away with this forever. Right. Uh, and at the same time, when you encounter somebody who's really chill, but you know, you can tell they've got great potential and they're going places and you can be a helpful in helping them go to those places. Right. You can, you can give them opportunities. You can encourage other people to try them out. Uh, you know, I think, I think that's a really cool thing about the open source. Community and software development in general, I think people are looking out for one another and they are noticing people who are really chill and really good at what they do. And they're elevating those people. Yeah. I think that's, again, something I really loved about software in general is it's right from maybe like the first work experience I ever did when I was like 14 or something, working like it support in like my dad's like office in Edinburgh. Um, just like, there's just an, an ethos of like collaboration and like, oh, you know, a That's cool. Like, let's all learn about that. And like, I, I just, I found that very, like, I, you know, I, I also did work experience. I remember when I was younger in like a law firm and like the contrast between like tech and law could not have been more stark in terms of like the, you know, like admiring and respecting kind of youth and new people coming in and new ways of doing things and new technologies and whatever. And it's in many cases, like the people who you might've expected to be most experienced and most stuck in their ways were often the people who were the most like actively embracing like youth and change and what's happening. And, and that's, I think a beautiful thing about technology, right. Is when we can, when we can try and have that attitude, right. Which doesn't always exist in other industries. And I guess it's maybe particularly rapid right now when everything's changing radically. Yeah. Well, let's talk about that change because I, no, no episode of the Free Code Camp podcast is out, is complete without a discussion of LLM tools, AI code gen, stuff like that. Um, you have been a dev for a long time. Uh, a lot of these tools didn't necessarily just explode onto your radar like they did for a lot of lay people. Like you've seen them gradually improving over time and you've seen the tools get better How do you make sense of, uh, you know, like a lot of managerial decisions and you're a manager too. So you're a perfect person to ask this question to you. Like a lot of the managers who are going out, like we're going to hire fewer developers and we're going to rely more on AI code gen. Yeah. So I don't really know where we're at with a lot of these tools right now. I think it's interesting because there's definitely a lot of people who are pushing narratives pretty hard, who, who are pushing the narratives the hardest, who are themselves like most likely to benefit. Like if you're the, the Claude code, like principal engineer, or if you're the CEO of NVIDIA, of course you're going to tell people that they should stop teaching their kids how to code. I think it's pretty much a direct quote from what he said. And I think the thing is, and I also think on the flip side, like they'll like everything, We have loads of things where like, you can go out and buy bread, right? Like very easily, but yet some people bake it at home, right? Like, why do they do that? Because they want to, they like it. They like the process. They might think it tastes better. It might taste better. Like whatever it may be. Right. And I think there's always going to be room for like an artisanal way of doing things, Like even at peak LLM, right? And I think again, like me loving open source, the beauty of open source is right. If you want to go and run your open source project in a like full speed ahead, let's do everything with LLMs, like a hundred percent all the way, all the time, you can do that. And also if you can, if you want to say, I'm not even going to allow code completion using LLMs for anyone who works on my project, you can do that. Like you, you can decide, right? I think what's more interesting and difficult and nuanced is like the industry as a whole, where does that go? And I don't know what it means long or even medium, maybe even short term for hiring and for kind of maybe more junior folks where things are a little bit difficult there. All I feel like I do know is that like, this is, this is changing things and it is going to be a big deal. And people on maybe hacker news or whatever, who are like, Oh, these tools are useless. They, they can't do anything meaningful. Like you are, if you're, if you're taking that position in, you know, early 2026, you've either not seriously tried any of these tools or you have, you know, not learned how to use them properly or something or whatever it may be, or maybe you're using them in the wrong way on the wrong code base or you are on a bad day or whatever, but there are a lot of people getting a lot of value at these tools. And I think that that's the only bit of it that I find undeniable. And I also feel like in my, you know, in my time in the industry, I guess we are, the internet, you know, coding for the internet was already established by the time I was working professionally. And then I guess the big changes were maybe like mobile or social media or crypto or whatever. Right. I feel like this is going to be bigger for actual software engineers and software engineering than any of those were in the past. Um, and I think it's going to be more like when we went from maybe a similar to, uh, writing high level program languages, um, in terms of like the impact. But I also think most of what is hard about software engineering is not writing the code, Like actually I think you could probably have had a similar conversation around the eras of like higher level programming languages. And like, well, actually, if you look at this compared to assembler, now we don't need to think about any of this stuff anymore. It just gets done for us automatically by the compiler. Right. And it's like, well, yeah, like, and also in the early days of the compiler, right? Like it was similar, right? Where in the early days of the compiler, then you should handwrite your assembler from the code that you really care about. Cause it's going to actually be like good code. Right. And over time that becomes less and less true. Um, I wrote, there's an anecdote back to Linus Torvalds of him working on, uh, if I remember correctly, like when he was working on Git and so much of the software in Git is around like the SHA one hashing function being really fast. So he was like, what's the state of the art? And there was an open SSL one, which is written in assembler for each, uh, architecture to be the fastest. And he was like, Oh, that seems really fast. But he tried his own version just written in C and based on his understanding of C and the, the way the compiler would behave or whatever it outperformed the open SSL version. Right. But that's something of like, maybe when that code was first written, the compiler version would have been trash, but these tools get better. And I think we're seeing a similar thing with LLMs where it might be that like nothing at your work right now is a good fit for LLMs. It doesn't work well with your programming language or your toolkit or your legacy code or whatever it may be. But like, if you think that that's literally going to never change, like, yeah, you, you need to reanalyze things because eventually these tools are going to come and they're going to change the way you do your job. And if you are insistent that you write every character by hand forever, I think some of those people will not have a job in the future. Let's talk about how you use it day to day. Like what tools are you using? How are you using them? To the extent that you can just give us a high level overview of how you've adopted these tools. So my main tools of choice are ChatGPT for just like a separate kind of chat interface of which I'll ask it anything, you know, program related questions, maybe small code snippets, but not like main languages, like not like multiple files or anything like that. And I like that it's kind of quite nice and separate and it's its own thing. And I can do it with my phone and my Mac and jump back and forward between the two. And then I would use opening a codex in the CLI for like my kind of like agentic kind of more vibe coding sort of stuff where I'm not looking at every line of code as it's being written, but I will review it all later, basically, unless it's a complete throwaway one time script sort of thing. And then I have my cursor is my main, like I'm coding, but with kind of AI assistance kind I used to use cursors like kind of agentic mode and questions mode or whatever a bit more, but I now mainly just use cursor because I think it has the best kind of autocomplete. And I like that way of working. So those are my main three drivers, I would say. Well, since you've got a lot of experience using these tools, I'm going to ask you a question that I've asked a lot of devs who use them a lot. Do you think that agents are the future or do you think that code completion itself is where a lot of the utility is going to remain for more senior developers like you, where you're just looking at the chunk of code and you're working directly with it and it's just helping you essentially fill it in faster? Yeah, I think it depends on what you're working on and what the code basis and the languages and whatever. So for example, on Homebrew, like I know Homebrew's code base well enough that I can read a bug report and I'm like, I know which file needs changed, right? And I could prompt an AI to change that file because I know what it is, but it's probably going to take me longer. Like literally, I think in some of those cases to use the agents would take me more keystrokes than it would be to do it manually by hand, right? Even if I gave the agent just like the issue, it's going to like turn around and do its own thing and it's probably not going to quite do it the way that I know that it needs to be done and I know some of the edge cases that maybe aren't documented or whatever. And again, I guess some people could say, maybe rightly, maybe wrongly, well, you could just add all this to your agent's MD or your documentation and over time the agent will get just as good as you. And it's like, yeah, but in this particular case, it's like I have to pull out, you know, 16 years worth of context and put it into text so the agent can understand it. Like I just don't think that's going to happen, right? But on the flip side, I now if I'm working on like a script, right? And so right now I'm doing like a, I'm working on a kind of JIRA to GitHub migration, right? And I'm doing a bunch of data analysis as part of that. And most of my data analysis now is just like, hey, OpenAI Codex, write some code that gives me this output based on the data, right? And I don't even tell it the structure of the data. It goes and looks for it, right? And so far I haven't read any of the code, right? And some people might say, but how do you know it's correct? And it's like by looking at the output, right? And this is code that's not going to be shared or used by anyone else. And once I've got the data crunched how I want it to be crunched, I'm going to throw away the script and never look at it again. And that's definitely something where probably even a year ago, like A, I don't think I would have got the output I was looking for as quickly and B, I think I would have had much more of a sense of like, I must read the code or I'm somehow being irresponsible. But given the sandboxing progressions and stuff that we've had as well, I'm just like, it's I don't need to read this. It feels weird even saying that. Yeah. But I mean, again, if it's software with an audience of one and it's just doing a task and you just care about the quality of the output, if there's some sanity checks, if you can just get a feel for like, oh, it went completely out. This value is an order of magnitude different than it should be. Then that is kind of like the canary in the coal mine that might inspire you to actually go scrutinize the code more. But a lot of this stuff is so routine. It's been done so many times that you don't need to go and reinvent the wheel. But yet there may not be like some package or some ready-made script that you can use. So you just create one. And I think that's one of the big use cases for agents and for like air quotes vibe coding. Everybody gets pissed when they use that term. But essentially, that's what you're doing in the definition of Karpathy is you're not even looking at the code. And you wouldn't do that for production-grade code, of course. But in this use case, it's perfectly serviceable. Yeah. But I mean, but increasingly, there's some cases where even if I was to make that production-grade code, like I would, again, probably a year, year and a half ago, I would have very much operated from the principle of like, I need to be reading this as I go along. Whereas now, I would basically like, I'd basically get it working without ever looking at the And then I will read the code from top to bottom, right? Like, and check every line, tweak certain things in, put it into maybe my house style. Partly, it's just almost like a learning and understanding thing as much as a, actually, I know ultimately it doesn't matter in Ruby if I use, if not, or unless, right? Like, whatever, like, but I prefer one and not the other. And I feel like that's sometimes my way of like, understanding the code is going through and like, fiddling with it, slightly rewriting it and whatever. And I think, I think that's the interesting thing is that I think even then these tools are getting better and they're getting more powerful such that it's closer to what I would have written like much more quickly and more readily, right? Particularly once you kind of learn like a few, like little catchphrases that you can spit in to your agent's MD file or whatever. And I think that that's the thing. It's that question, I guess, like what we talked about before of like, what, what is good enough, right? Like, and I think these tools are very good at getting to good enough exceptionally quickly, I think where things go a bit more is when like, you don't spend the time or effort reading it and you just almost like generate the code and throw it over the wall. And then it's someone else's problem to make sure that that's good enough. Like that's happening certainly a lot in open source. I don't think it's happening as much in the workplace, although I hear stories, but like, I think that's going to be the thing that we're going to be like, nope, like can't do that. If the AI generated it and you did the prompt, then you own that output, right? And you need to get good at understanding that code. And I think my maybe scary prediction for the next couple of years, I think we're probably going to see some very bad things happen at some point where people have just YOLO'd it a bit too hard and whoops, turns out there was no encryption on our database. Whoops, turns out it was publicly accessible. Whoops, everyone's stuff got stolen and someone will go, oh, well, that was ChatsyPT's fault, It's like, well, nope, that's not, that's not how it works. Sorry. Yeah. I mean, same thing with any tools. You are the person wielding those tools. And it's ridiculous to say that, oh, we know how these tools work. There's just token predictors, right? But they're very useful, as you pointed out. So I want to remind everybody that this is an unedited podcast interview. I have no idea how Mike McQuaid is going to answer. And it could be completely in contradiction of my own personal opinion. But I respect his opinion as a dev who's worked for decades at this point, who has worked at the highest levels of the field as an IC, worked as a manager, who's worked as a maintainer of one of the biggest open source projects, certainly in the Mac space. Mike, like, in light of how the field is changing, how would you advise somebody who's getting into the field now, like, what would you recommend they do, uh, that maybe be different from what they would do five years ago? Yeah, it's hard. I've been asked this question a lot and I never feel like I give a great answer. Um, I think the main thing I would probably do is get really good at reading code and reviewing other people's code. Like, so I wrote a blog post along these lines, which is why I think open source maintainers are good at that is because, um, you know, some people, you know, every PR you do at work, it just looks good to me. Right. And you don't really engage and grapple with other people's code and that you can do that and get away with that. And most cultures in many workplaces, no one's going to come back at you and be like, Hey, someone else wrote this code, but you didn't spot the bug. So I'm the site went down. Right. Like ideally that would be, ideally we would have a culture where it's like it's equal responsibility of the person who reviewed it and the person who created it to make sure that that code is correct. But I don't think that's the majority culture. We can change the culture though. We can, we can, but I think that's, that's in some ways where we need to be going because you need to be able to do that for your AI generated code. You're going to need to generate code probably with AI, but you need to be able to read that and understand that and analyze that and catch bugs in that by yourself without another human doing it for you or with you. And how exactly you learn that skill. I don't really know beyond being an open source maintainer, right? Like, and doing a bunch of open source and maybe reviewing other people's code and seeing how other people will do it. But I do think it's maybe a little bit of, if I can be very harsh, intellectual laziness that crept into our discipline that we got away with for a long amount of time that it's like, it's okay that you don't really read or understand anyone else's code and anyone else's code is basically legacy code as far as you're concerned. And you would ideally just rewrite it into your own style. I think that's the big thing that we can't, you can't do that anymore, right? Like you're going to have to use these tools and you're going to have to be able to understand them and catch them when they're doing the wrong thing. And that's a completely different skill to just like be able to write it all from scratch by yourself. And arguably that's gone from, you know, maybe the third, fourth, fifth, most important skill for a software engineer. That's maybe going to be the most important skill. So that's, that's the thing I would get people to focus on. That makes a lot of sense. I mean, yeah, get really good at reading code. That's I think the direct quote of what you said there. And I think that's profound. And that might, I might make the video headline because I think it's, it's, it is a change. Right. And I agree with like the intellectual laziness point that you, that you mentioned. I think laziness on a whole across many different fields is going to be on the upswing as people just want to get through their day so they can get back into TikTok or wherever, you know, Skinnerbox they want to put themselves into. But this is a new year. It's 2026. The year is filled with possibilities. What are you going to do with this year? Yeah. I mean, I guess maybe touching a little bit of each of the topics we've touched upon. I guess I want to make homebrew is like great. It's mostly feature complete, but like, I think the, the main area I care about is trying to make it more performant, right? Just trying to make it do things, the same things faster than it previously does. Right. So that's my focus. It was my focus last year. It's my focus this year as well. Like improve her homes and homebrew. Um, I guess like at work, I'm like a CTPO. I want to like grow my teams, like happiness at work, trust at work, output at work, like all of that stuff combined. And then, you know, I guess we talked about powerlifting. I want to win some medals this year. Um, and then just try and be a better dad, husband, friend, human, like hopefully get to And I'm a nicer person than I was at the beginning of it. Mike McQuaid, it's been such a privilege to talk with you and learn more, uh, with your perspectives that you shared. Uh, thanks again for coming on the show. Thanks for having me, Quincy. Yeah. And then everybody tuning in until next week. Happy coding. See you then.

Homebrew is a widely used package manager that simplifies the installation of open-source software on macOS. It was created in response to the growing demand for a lightweight, developer-friendly tool suited to an increasingly Mac-centric development ecosystem. Today, Homebrew is a near-essential part of the macOS software development toolkit. Mike McQuaid joined the project early on and collaborated closely with its creator, Max Howell. He joins the podcast with Kevin Ball to discuss Homebrew's origins, architecture, its emphasis on automation and CICD, long-term sustainability, controversial trade-offs, and much more. Kevin Ball, or Kate Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow KBall on Twitter or LinkedIn, or visit his website, KBall.llc. Mike, welcome to the show. Hey, thanks for having me, Kevin. Yeah, excited to get to talk to you. Let's maybe start with a little bit about you. Can you talk about your background and then how you got into Homebrew and where we're going to go today? Yeah, sure. So I feel like in tech, I've kind of had two lives, right? So there's my, maybe a little bit like being a really rubbish superhero, right? Where I guess my commercial job-related life, you know, I'm a guy from Scotland. I'm interested in computers, did the computer science degree thing, got the tech job thing. I've been doing that since 2007. Just, you know, like getting jobs, changing jobs, paying the bills, having fun, all that stuff. But then there's my open source life, which is generally what's of more interest to people with homebrew and all that type of background. So my love of open source, I guess, probably started while I was at university. Like I came to university. I heard about, you know, when I was in high school, people talking about installing Linux on the machine the same way that you might talk about, you know, taking illicit drugs or whatever. It was this kind of like risky, dangerous, sort of like somewhat admirable thing. So, yeah, so I got to university, like a bit of a kind of Windows power user, had not done meaningful programming really, like beyond just trying to get games working on my computer. And, you know, peer pressure happened pretty quickly. And I was like, okay, I need to get on the installing Linux on my desktop bandwagon, right? So got Linux on my desktop machine, got like a little home server of an old computer running my parents' house so I could like send data back and forth and all this type of stuff. And, yeah, and obviously, you know, desktop Linux, one of the nice things about it, I mean, probably even now, but certainly back in, you know, 2003, 2004, when I was first dabbling with it, is like open source is front and center, right? And you very quickly realize like, oh, this is like a community of people building a thing. And as much as I feel like I'm a consumer and I'm using this thing, if I file a bug, there's a very real chance that like the guy or girl who wrote that is the person who responds to my tickets. So, yeah, so I guess that kind of growing awareness, you know, I started like helping out with things and helping out on IRC channels and bug trackers and forums and all this type of stuff. And then like, you know, forking stuff myself, modifying it a little bit, publishing up the changes in case anyone cared. But, yeah, but I guess for me, the main thing was probably like I did Google Summer of Code back in 2000 and what would it be? It was 2007 for the KDE, like desktop environment still around. And, yeah, and I basically sort of fell in love with the open source community through that, really, like from spending a three-month project, just writing lots of code, seeing very high degrees of trust and mentorship and help and whatever. And then I just went on from that being a huge proponent of it in my work life. And then I guess the two streams probably crossed again in 2009. I was in London working for a stock called Mendeley across the other side of London. A friend of a friend was a guy called Max Howell, who was also working in London. A huge stock called Last.fm. That probably brings back memories for a certain number of people. And, yeah, so he had been tasked with, you know, doing various bits and pieces and building desktop applications. And I believe the official story is, like, he was in the pub one night complaining about all the package managers being terrible. And someone said to him, well, if you hate them all so much, why don't you make your own one, right? And he left the pub, went down, wrote a sort of outline of what homebrew should be, started building it. And then I got involved, you know, I can't remember what it was, like four or five months later, kind of heard about this thing. I'd sort of tried to build something vaguely similar myself. And, yeah, that was, I guess, 16 years ago, like in September, that I've been working on this thing. And, yeah, and that's my open source story, I guess. That's awesome. Yeah, I feel like a lot of us have that experience with open source of, like, this stuff is all crap. Wait, with this stuff, though, I can actually do it myself and make it my version. Yeah, totally. So I feel like in today's age, especially with Max having become, at least in the U.S. and much of Europe, the sort of de facto development environment for many, many developers, a huge number of our listeners are probably homebrew users. But I don't know how many of them have actually looked below the hood at how it works or why it became the de facto norm. Why is this one not terrible the way that all the package managers that Max was complaining about are? So how would you describe, like, what are the core, like, choices or approaches that have made homebrew so successful? Yeah. Before we get to that, I just noticed this is, again, I've been working on homebrew for 16 years. It's the first time I've ever thought of this. I think because you were saying in that sentence, and you're talking about Max, the Apple computers, and Max, the creator of homebrew, and it's only just twigged. And I'm like, oh, yeah, that's a fun little coincidence. That is a fun one. But anyway, yeah, so how homebrew works. So I think one of the things I've found in my career in general, right, is I'm a maintainer. I'm not a creator, right? Like, I'm someone who is very good at taking something that someone else has made and riffing off it and evolving it and growing it and blah, blah, blah. But, like, I am rubbish at coming up with new ideas myself, right? So a lot of the kind of brilliance of homebrew, I think, goes back to Max's original design, right? And I think the, I guess, the less interesting parts of the design first, but people might not know this, so let's tell them. Anyway, so homebrew is and was from day one written in Ruby primarily. And so, like, at the time, you know, Ruby was sort of starting, Ruby and Rails were starting to take off. Ruby was, like, a very, you know, becoming a popular language in 2009. And, you know, nowadays it's the same. You know, there's still a bunch of code that probably goes right back to the first kind of few commits. And if you sort of squint a little, you can see that, you know, the DSLs and stuff that are being used in homebrew today are still much the same as back then. So I think that brings you to the first part of our move that I think was initially brilliant, which is, like, something Ruby is very good at is building these DSLs, domain-specific languages, I guess we would call them, where because Ruby code can be at least made to look very much like just normal English, right? And because Ruby is a very low syntax, heavy language, you can build these things that look a little bit more like you're just declaring, you know, it almost looks a little bit like YAML without as much indentation and stuff sometimes, where you can just look like you're declaring data, but you're actually calling functions inside a class and things like that. And as a result of that, homebrew started off with these things called formula. So the formula is basically like a definition of how a package is built. Originally, homebrew started off being a from-source package manager, so everything is built on your machine. Nowadays, basically, everything is built by someone else, usually homebrew somewhere else elsewhere. But that kind of initial formula description was very, very easy to read and write and contribute to. So I think that was a key thing to begin with. Like, if you've ever worked with other package managers, particularly back in that era, and had to, like, package something in, you know, AppGet or RPM or whatever, like, it was a nightmare, frankly. Like, it was horrendous how many steps it would take and how many things you'd have to do to pass all the lints and test all this stuff on your local machine. Whereas the Ruby formula made it very easy to read and understand what's going on and design and contribute. And that's the next thing, I think, that was the really smart choice. Like, I was speaking with a CEO recently who said something along the lines of, you know, all the best engineers are lazy, right? And often engineers that he might have a problem with are the ones who are being insufficiently lazy, not working hard enough. But, like, there was a certain amount of that from the outside with Max, right, where he said, like, hey, like, you know, if this package manager is going to be successful, we're probably going to have, like, five, six, 10,000 packages. Like, I don't want to maintain 10,000 packages, right? Like, I also don't want to go down the route of, you know, something like Debian or whatever, where I have to find, you know, 1,000 people who are willing to maintain 10,000 packages. So this was around the era that GitHub was starting to take off. So he basically was like, right, we're going to design the package manager. So it's a GitHub-based workflow, right? And Homebrew actually predated pull requests even on GitHub. So the original flow, I mean, the first few commits I had would be, I would be on IRC and I would DM Max with, like, a commit in my fork. And he would be like, yeah, that looks good. He would then cherry pick that from my fork and then push that to the Homebrew repo, right? And then over time, we ended up pull requests and reviews and all this type of good stuff. But yeah, I think that model from the outset of designing it to be both very, very easy to contribute to, but also designing community contribution and community maintenance as being a core part of the overall flow of Homebrew is, I think, what resulted in it being as successful as it's been. That's fascinating. And I think for open source in general, the packages that sustain themselves seem to be those that manage to build that community early. So thinking about that from the beginning is great. Another thing that I think makes Homebrew different from at least the package managers that went before in Mac land and also a lot of the Linux package managers is it's pretty much all user space, right? Yeah, so that's one of the nice things about macOS and one of the reasons I'm still a fairly diehard Mac fan today is back in the Linux package manager days when I was working with that. I mean, the Linux package managers, I would still say to this day that I don't think AppGet is better than Homebrew in every way, but I think overall, it is a more powerful package manager. Like, it has a lot more stuff, a lot more sorted than Homebrew does, right? But it always, there was a slight weirdness to me always where essentially like some random utility that I'm pulling off someone's GitHub, right? That I, essentially if it breaks, it has no consequence to me. And my libc or like kernel are essentially managed in exactly the same way as far as the package manager is concerned, right? And one of the nice things about macOS or, I mean, even nowadays, again, if you sort of look at it from a funny perspective, things like WSL or like there's Linux distors that are doing this now as well. You have a kind of a mutable file system like a modern macOS does and Homebrew and Linux is taking off on those as well. It's this idea that like, as you say, you have this user space package manager, right? Which is living in a non-protected part of the file system. You don't need to run sudo to run it and stuff like that once it's installed. And then basically you sort of limit the damage that that can do to your system. And nowadays, I think partly because of maybe Homebrew becoming more popular, like the, you know, the macOS space system is like super locked down and you can get access and modify things if you want to, but you're going to have to boot your Mac in a special mode and blah, blah, blah. And that basically just means that developers on Macs now don't have to like fiddle with things in user bin. User bin is up to Apple, like opt homebrew bin is up to homebrew and you can just remove opt homebrew bin and every, at least like desktop application on your system should just continue to work fine as is, you know. All your programming projects may explode, but you know, that's, it has less of a degree of concern that you're actually going to like break your system or whatever, which was at least theoretically possible in the battle days. Yeah. Well, and it, it makes, for example, staying up to date with Apple's upgrades a lot less painful as well. I feel like it used to be, I would, and I still have some of these instincts, but I would resist forever upgrading to the newer OSs because I knew my whole dev environment would break. And I'd have to go and rebuild everything. And I feel like that problem has more or less gone away. Yeah. So that I'm glad to hear your perception is that problem has mostly gone away that, I mean, to be fair, Apple are better on some of the stuff than they used to be, but it's still, it's definitely an area of pain that projects like homebrew mainly feel. But in some ways, like if homebrew can do one thing, well, it's providing a abstraction layer over all of this stuff so that we have to care and worry about and fix this stuff and you don't. Right. So, yeah, like that's, that's very much a, a goal of our package manager is to. I wouldn't say it's completely painless at this point, but it's, I mean, it used to be days and now it's like, oh, I've got a couple hours of cleaning things up. Let's maybe actually then peel back that abstraction layer a little bit because, you know, I, as a user, I just know the APIs you provide, but what are actually the key pieces that go into making a package manager work? Yeah, so I think homebrew is a bit of a special snowflake of a package manager in lots of ways. I guess I've mentioned some of them already, you know, some of the package managers that have come after have really leaned into the same sort of model of community contribution and stuff like that. Some haven't. I think one of the things we do that often surprises people is, you know, we have, I guess, our, our stats and best estimates or whatever are like, you know, five, 10 million kind of relatively active users of homebrew, which is a scary amount of people. And then in terms of maintainers, we have like 30 people, right? And probably on a day-to-day basis, probably, you know, 10 to 15 of them are active and it's, you know, you tend to have this parallel function of even within those maintainers, there's some people who do a really disproportionate amount of the work. And in the total history of all of whom were maintainers ever, I think there's been probably less than 16 people, maybe even less than 50 people. So obviously like that's, that's good scaling, right? Like how you can get a relatively small number of people to provide that amount of service. Some of that is the contributors I mentioned before, like, you know, getting third parties to go and help and submit changes probably got like, yeah, I mean, definitely over 10,000 contributors. I don't think we're anywhere near to a hundred thousand, but you know, in the five figures there, but still there's like, you know, there's scaling effects and you're like, how can you make that happen for 20,000 packages, which are getting probably, you know, 10, 20, a hundred updates a day across that. So something we have done certainly, at least from the very early days of me being involved with Homebrew is going back to what we said before about laziness. Like I'm an exceptional lazy person. I like the people I work with to be lazy and I really encourage that, right? So my, one of my positions for a long time, which is kind of funny, now we've got AI because it's, you know, encouraging you to think about that in a different way still was almost like, I guess I wrote a blog post about this called robot pedantry, human empathy. Like, because at the time I felt like I was seeing, you know, people were almost being like, oh, I'm going to write a bot to thank first time contributors to a project or whatever. And like, my observation was, is that like, if people have a bot doing it, it doesn't mean anything. They don't really feel valued and considered by a bot, right? But like on the flip side, people are very tolerant of bots being, I don't know if you've ever had one of those pull request reviews in a work environment or whatever. That are brutal? Yeah, well, not even brutal. Like I would say like excessively pedantic, right? Where say you're using semicolons in JavaScript the way that they don't like, and you did it 20 times and they go through and on every single occurrence, they're like, use semicolons. And like when a human does that, you hate that person, right? Whereas when a, what I would call a robot or like a CI job or a linter or whatever does it, you're like, that is actively helpful. And if you didn't tell me all of the occurrences, you would not be a useful tool, right? So something I tried to encourage in myself and in others in Homebrew from the early days was being like, okay, anytime you are regularly making the same comment on say three pull requests, right? Figure out a way to turn that into an automated check that can run, that can make the CI red so that the user has that indication that like there is a problem here. And I guess there's, you know, to adopt horrible tech industry jargon, like shifting things left as well, right? And so also that idea of like, okay, ideally we move from a human comment to being a CI comment, like on a pull request or whatever. But then ideally still, we move from a CI comment to a local development environment comment. So again, we have a bunch of automated checks. So the most common linter in Ruby land is a tool called Rubocop. So we now have it configured so that if you open Homebrew in like a, in VS code, you'll get prompted to install the Rubocop plugin. And if you install that, then when you're writing Homebrew code, we will pop up straight in your editor and tell you like, this is against like essentially the description of this formula is not in the format we like. Like you have started with a or an, and we don't like you to start with a or an because it doesn't look nice in our output or whatever, right? So then you can have a user who's working on this for the first time who gets that input straight away, right? And if you've enabled auto formatting in your editor, then some of those Rubocops have auto correction. So you could start your description with an A or an an. I can't remember whether this one does auto correction or not, but we'll assume it does for this anecdote. You could type that in and you press save. And if you've got format and save enabled, then you'll just see that text just disappear, right? So obviously that contribution experience is like delightful when it all, when all the, you know, stars align and all that stuff happens. And instead of a human being like, don't do this, don't do this, don't do this, your editor is automatically making your codes the way we need it to look. So it passes CI. And even if it does make it to CI, again, like we have a pretty time zone distributed team now. So we probably have decent follow the sun coverage, but like before we had that, there was something really delightful about seeing someone open a pull request, see, you know, our linter spits out 10 warnings. They read them all, they action them all, they improve everything. And then you wake up in the morning and you're like, oh, this, there was 20 things I would have said on the first version of this pull request. Instead, our CI tooling and the robots or whatever settled this, the person has got it ready and now I can just merge it straight away, right? And then everyone has a better experience and that's how the projects can scale dramatically better in that way. And I also, my, you know, while I'm on my soapbox, like my personal experience is a lot of companies could do with moving a lot more in that direction than they think as well. Because generally, humans don't like doing that stuff. And generally, pretty much every software company in the world, if you're like, I can give you a way to move faster without negatively impacting your quality, like most people or most companies, most developers would say, yes, please. And that's how you get there. You get there by very heavy but reliable automation. There's a mindset shift there that takes a while to sink in. And I find I'm climbing that whole mental climb again now with these AI coding tools because there's things they're good at, there's things they're not good at. But a thing they are very good at is writing tools. So you can use them to automate your check that you are going to do. And it's mind boggling how much faster you can go as you accumulate those. I'm in the same space right now where I would say I'm a, like AI, I don't know, user and mild optimist. But it's like figuring out the places in which these tools are very well suited and very badly suited, right? Because, you know, it's like that old expression used to be of, I can't remember where I first heard this, but, you know, like your average not tech person would be like, I hate computers because they never do what I tell them to. And then the tech person responds is, no, you hate them because they do exactly what you tell them to when that's not what you mean, right? And I think it's interesting because I feel like a lot of the time, some of the modern LLM tools are getting better at inferring what you meant rather than what you told them to do. But then on the flip side, the responses are now non-deterministic. So you can't, you know, those examples before with the CI and the linting or whatever, I'm sure I could describe in prose and feed that into ChatGPT and have that somehow run in my CI pipelines. But the problem is if you rerun that on the same code three times, you're going to get, like, you don't get the same response every time without some sort of deterministic, like, code layer living underneath or on top that is making sure that that stuff works as it does. So, yeah, I still feel like that's a big point of growth that we're still figuring out is like figuring out how do we make these two tools play together in the nicest possible fashion. The automated validations that you're doing are actually great for that because if you can put this non-deterministic thing in a loop with deterministic validation for correctness, your quality gets so much higher. Yeah, yeah, I've definitely felt that when I've been doing stuff, I'm yet to really go hard on, like, agentic stuff, like, particularly agentic, not in my, not in a window in the foreground sort of approaches. It's on my to-do list to play around with that in the next few weeks. But even on that, like, I definitely find in tools like Cursors Agent Mode or whatever, if you can say, here's how you run the test, here's how you link the code, here's how you type check the code. So, Homebrew nowadays uses Sorbet, which is like a type checker built by Stripe kind of type checker runtime type system, runs exceptionally fast to kind of check the entire code base. Then, yeah, like, the more of those guardrails you have, then the better these tools do because they're able to validate their own behavior without you having to say, like, oh, no, that should be, you know, like an integer being passed this method, not a, you know, a number one in quotes or whatever. So, let's come back a little bit to the pieces that make Homebrew work. So, we talked about kind of the automations for contribution and the key sort of piece of formula, which are building DSLs. What's the engine inside of Homebrew? Presumably, you have some sort of dependency resolution or thing like that going on. And, like, what are the, like, I don't know the software architecture of a package manager. Yeah. So, I mean, I don't know that I know the software architecture of a package manager either, but I can speak to, yeah, Homebrew basically where you touch upon dependency resolution. That's the most common thing that, you know, of value in some ways that a package manager is providing. So, if you don't use or have never really thought about a package manager before, essentially, like, the two key things you might say that they are doing for you is one is just a way of essentially specifying, here's a bit of software. I want this installed. You figure out however that gets installed and the way of indicating you want two pieces of software installed should be the same, even if the underlying build mechanism, distribution mechanism, whatever, is radically different between those two things. So, it's that abstraction layer. Generally, as well as that, there's some sort of version-based behavior as well. This is something where Homebrew's got a lot of flack over the years and were better than we used to. But, again, let's differentiate between different types of package managers for a moment, right? So, you have, I guess, what you might call, I guess you were saying, user space earlier. Some might say, like, system package managers, right? Which would be, Homebrew would be sort of an example, but definitely something like Appget on Debian or Ubuntu, something like Yum or whatever on Fedora, I think that's been, or DNF maybe now. I can't remember, it's been a while, a merge on Gen2, Pac-Man on Arch, et cetera. So, those are responsible generally for installing everything that might be on a system or not. And, like, again, you can debate whether Homebrew is one of those or not. But what Homebrew is definitely not, which people are often more familiar with, is a language package manager. So, say something like NPM or Cargo in Rustland or PIP in Pythonland or GEM or Bundler in Rubyland, et cetera, et cetera. These package managers where everything you install through that thing will be written, at least primarily, in that language. They may also have C extensions or whatever, depending on the language. But, essentially, you're installing libraries mainly for the writing software yourself in that language. Right, so one of the big differences between the language package managers and the system package managers is the language package managers generally have this model of, like, okay, well, we basically can let anyone sort of publish anything. And, ultimately, the people who are in control of uploading a new version and deciding whether people get upgrades or not are the publishers of that package and, generally, the authors and the creators and the repo owners on GitHub. Whereas with system package managers, generally, there's a bit of a, like, okay, because of the dependencies, which we mentioned earlier, you need to verify that it is okay for everyone to get a new version of a thing, right? So, if I have some library that 1,000 packages in Homebrew depend on, I release my version 2, and I say, okay, Homebrew, we're ready for version 2 of the package, right? Like, if I'm in entire control of that happening, then, again, depending on the package manager, like, that might be okay. It might be that they can just upload version 2, and then everything sticks on version 1 until we manually, like, change it, and it says it goes to version 2. So, Homebrew was designed from the early days to be, again, more package manager terminology, I'm afraid, what you call a rolling release package manager. So, things like Ubuntu or Debian, you might be familiar that they have, every so often they've got, you know, I can't remember what an Ubuntu one is, but it's, you know, like, poetic pelican or, you know, it's always like a, you know, two letters the same or Debian buster or whatever, right? So, they generally, the way they do that is they say, okay, we're going to, like, branch off a while before we essentially get all the packages so they're, like, vaguely stable together, and then we have a point where we say, okay, we've released this new thing, we basically are only going to do security updates and bug fixes until, you know, there's ways of you working around that, but by default, that's how we're going to do things. Then you have a rolling release package manager, which is what Homebrew is, which is essentially, you get the newest version of everything all the time. So, if you just type brew install, you know, some package name, say MySQL, right, in Homebrew, at least, let's simplify things and look at Homebrew 10 years ago to start with, like, if you type brew install MySQL, you will always get the newest version of MySQL, right? And if yesterday, whoever it is that owns MySQL nowadays, Oracle, dropped a new major version, and we're on MySQL 10, and it has no backwards compatibility with MySQL 8, right, like, tough luck, right? Like, all your shit's broken, but Homebrew is internally consistent, so it's fine. We evolve from there to be like, okay, well, then we're going to at least have CI where we're going to test and make sure that everything works within Homebrew's ecosystem, at least, so you're not breaking any other packages in Homebrew. That's one of the fun artifacts of our CI is that when that happens with something like OpenSSL, which has thousands of dependencies, what that looks like is a CI job that will take two to three days to run of continuously churning away for, like, you know, 48 hours. We've had various CI providers and hosting providers who assume that that's a typo, where we say, like, hey, like, your timeouts are triggering too long. You know, they're kicking in off to, I think, like, one time it's like, we're kicking in off to 48 hours, and they're like, oh, do you mean, like, 48 minutes? No, 48 hours. They're like, yeah, that's, surely it's not taking longer than 40. No, yeah, this job takes up to 72 hours to run. So that's been a little bit of a surprise. And again, that's part of the reason why people, when they might critique Homebrew and Homebrew's model, it's like, yeah, like this, it's hard to do this stuff at this sort of scale, right? And then more recently, Homebrew has done a bit more around versioning. So now you can install MySQL at 5.7, right? And that means that you will sit on that version forever, right? But because of Homebrew's original architecture, the way we do that is we maintain a separate MySQL at 5.7 package, and we have to maintain that indefinitely. And if there's something that has to happen to all the MySQL versions for a new macOS version, we have to essentially port it between all of those, right? So there's a little bit of overhead there, which is why we don't do this for every single package all the time. So that is interesting. So what's the ICD provider using today? So nowadays we use GitHub Actions, but we have our own self-hosted runners for doing a lot of the hard work, basically. So particularly on macOS, essentially we need the newest version of macOS pretty much as a month, two months before Apple released the new version, because we want to be able to test things and verify things or whatever. And we are yet to find a, we would ideally use an entirely hosted solution, we are yet to ever find an entirely hosted solution who can do things as fast as we need them to be done, but also provide like, you know, 72 hour timeouts on things. So our self-hosted runners used to be, again, like a little bit of fun, open source lore, used to be physical Mac minis that were originally installed in a data center by me taking them down in a suitcase from Scotland on a train, which then, which ended up like going in the car of someone whose podcast I listened to, who let me stay in his house and then put them in the data center of his ISP. And then later I took another train and then moved them up back to Scotland and blah, blah, blah. So yeah, so there's, there's a bunch of funny games that happens with this before this stuff was available for, by cloud providers. But nowadays there's a company called Mac Stadium who we've worked with for a long time now, probably coming up to 10 years, who provide like hosted Macs for us to use. And they've got like a nice sort of Kubernetes-like abstraction layer that lets us kind of spin up and spin down VMs of the various macOS versions we need to run. So yeah, so that's basically what powers are, like CI, like the, the actual, where the code is being run and built side of things. But yeah, but then the, the main almost like centralized server now is all on Gap Actions. Who funds that? Do they donate those resources? So originally Mac Stadium donated all of the resources and then Apple helped when we were in the Apple Silicon transition. That's the first time I guess Apple like gave us something, which was nice. So they got us access to basically to a bunch of free Apple Silicon hardware. And then eventually, essentially we, well, and this is, to be very clear, this is completely fair enough of Mac Stadium, but essentially we kept on being like, we need more, bigger, faster, et cetera. And they were like, yeah, like I think you can pay for some stuff now, right? So we have, basically we pay Mac Stadium, but we receive a very heavy discount and you can see if you're interested in Homebrew's finances and financial situation. I guess that's another fun little thing where all our finances now are on, I think, called Open Collective, which is essentially, if you imagine that you, if you imagine you're like personal banking app, right? And you can go and see all the transactions. Oh, you know, 223 on this day, you spent this amount with this vendor or whatever. It's essentially that, but like the ledger is public. Like you, anyone could go, like Kevin, you can go and see how much money like Homebrew received and spent and from whom in the last year. And you can also see, like we do a small maintainer stipend of like whatever it is, like $300 a month for people who are still active on the project. So you can see who got that stipend and when and how much and when it was paid out and all that type of stuff. And obviously, like, you know, this sounds like a privacy accident waiting to happen, but Open Collective have been very good about making sure everything that should be private remains private and whatever. But yeah, it's quite cool. It's a quite cool open source way of doing funding where rather than having very strict rules on how money can be spent, essentially you have like this open ledger approach. So yeah, that's essentially how that's funded. You can literally go and see how much did we spend with Mac Stadium last month and all that type of stuff on our Open Collective if you were so interested. Yeah, that's actually kind of wild. I'm looking at it, just glancing at it here. That's very cool to have that level of transparency and to have, you know, for a registry, you know, you need a lot of resources. And so having that visible and having people able to see like, hey, this is what it costs to make your life just work like this. Yeah. I mean, we're lucky as well. I guess I would be remiss if I didn't mention, like, we get a lot of free resources from a bunch of companies as well. So DNS simple, one password, formerly DigitalOcean in the past, like, we basically have a lot of vendors who have given us a lot of free stuff, which is very nice. And it's obviously, I don't know how much of that reaches across the Atlantic to where you are, Kevin, but certainly Scotsmen such as myself are stereotypically very cheap and very careful with our money. So my preferred price for any vendor arrangement is always free, and that is what I've always attempted to negotiate. So, yeah, like, we're very lucky to have that. And I guess the biggest one, you know, a former employer of mine, and it's been easier to be a bit more sycophantic about them before I worked there and after I worked there, because I've been on Homebrew on both ends, is, you know, GitHub has contributed a huge amount to Homebrew in terms of why they've both given us a bunch of money, but also, like, when you download any of Homebrew's binary packages nowadays, that's all on GitHub packages kind of infrastructure, which is, like, primarily a Docker registry, which is why it might be a little bit confusing as to how we are using that for our stuff. But, yeah, but basically, we had a situation, I can't remember how long ago, it was five years ago, maybe, where our previous hosting provider, Bintrey, with about 90 days notice, were like, yeah, we can't post your stuff anymore. Sorry. And so we had to find a new provider and migrate everything over there and whatever. So that was very good of GitHub to be willing to do that. And I remember at the time seeing, essentially, when the switchover happened, like, seeing all of the internal graphs of usage and being like, yeah, like, this is, I'm sure a lot, GitHub Actors has had a lot more usage over time. But, like, you know, at the time, it was, like, 50, 75% of the usage of the entire system was people using Homebrew. So if we couldn't do that without a big funder like GitHub, and I feel like we're all so used to GitHub at this point that we kind of expect... It's just infrastructure. We expect it to just work, right? Exactly. And we expect it to all be, or just work all the time and be free to everyone, certainly everyone doing open source. So, yeah, like, I think a lot of my former co-workers have and have and do work very hard to make all this stuff work. So, yeah, particularly shout out to get help there. Yeah, for sure. Let's maybe actually talk about... So you've mentioned a couple of big changes that have happened over the years. So one was migrating to GitHub packages. I don't know if there's more to that story that's worth diving into. But some of the other ones, actually, one I'm curious around is you mentioned originally all of the building happened on developer machines, right? You install and it builds for you right there. And nowadays, very little is happening on developer machines. What drove that transition? And were there any, like, interesting technical challenges to make it a reality? Yeah, yeah. So let me get to that in one second. First, I'll say on the GitHub packages migration, I think it's quite interesting for people of a certain ilk. If that does interest you, then I did a talk at, I think it was the Staff Plus Conference in London, like, two or three years ago. And you can go and find that on their web page. If you go on my website, mikemcquade.com, under the talk section, I think there's a link over there or whatever. But, you know, that's basically the, if you're interested in a dedicated 30-minute discussion of why that was an interesting technical thing to work on, you might find that interesting. In terms of the source migration, yeah, like that, I sort of spearhead that the most, right? So it's pretty much the only concept in Homebrew that I have created myself, which is why if you hate the naming, then that's my fault. I'm sorry. So we call, keeping with the beer metaphor in Homebrew, we call our binary packages bottles, which are then poured onto the file system, right? So I created bottles originally as just a way to speed up a select number of packages, right? So I've been talking to Max and there was, I guess, QT, the kind of cross-platform programming framework that both Max and I worked on with the past. We were both using it when I was at Medley and he was at Last.fm. So we had quite a lot of experience with that. It was an early package in Homebrew that got like reasonable levels of uptake. And like the build times were just, well, were and still are kind of bonkers. Like it, you know, it would take multiple, it would take often close to or over an hour on kind of fairly standard Mac hardware at the time. So there was a element of like, this is not a great user experience for someone to type brew install QT and then have to wait an hour before they get what they want. There was also the aspect of just like errors, right? So you could sometimes get to a point where when you were compiling stuff, particularly back in the day when it was easier to play around with your macOS base system where QT would build for, you know, say it was going to take an hour, 59 minutes and 59 seconds, and then have an error and be like, oops, something went wrong. And then essentially you lose all of your progress and state and you file a bug report, right? And we would notice that these bug reports were sometimes like, well, very often when building things from source, the number of bugs that were just like, this user has done something weird with their machine, right? And we were able to defensively improve some of that, but it became pretty apparent that like, essentially when you build a bottle rather than like, say something like QT, you're running a compiler and linker to do various things or various libraries and move things around and install things and blah, blah, blah. And when that was all happening in the user's machine, when it was building from source, we would say, there's just so many things that can go wrong. Essentially, you're running probably over the course of that build system, probably in excess of like a million, maybe 10 million, maybe even like a billion separate shell commands, any of which failing for a particular reason will take down the whole thing, basically. So whereas this kind of bottle architecture we moved to was essentially, again, I'm not a particularly smart guy, so I believe in the simplest solution to any problem. So essentially, the bottles are just a toggle, right? It's basically just, we build that, we run all those commands. Originally, the first few bottles were like, literally, I just build it on my personal machine, on my MacBook. And then we have, we run brew bottle, QT, it spits out a tarball, we upload the tarball, we provide the checksums for the tarball so that you know it hasn't been tampered with, and then people download that tarball and it saves them an hour, right? So that started off being like, just on, you know, and I guess I'd say the commands from before, essentially, you go from a million commands to being essentially download tarball, extract tarball. And the ways in which that could go wrong were dramatically fewer, and it dramatically reduced our support burden. And going back to what we said way earlier, again, a big motivation in homebrew has been some of the changes which I pushed through that have been very unpopular in the package manager have basically happened because I'm like, without this, this project will die. But we do not have the resources to deal with the amount of incoming support requests we have for supporting this power user feature, which maybe lots of people love, but like generates a really spectacular number of support requests. So we are going to do it this new way, which is a way that we're actually able to support. So that was another motivation of this stuff, is it's just like, because fewer things can go wrong, fewer people submit issues, and we're able to maintain the package manager better at the cost, in some cases, of some flexibility for our users. Yeah, well, and it highlights, right, all engineering is about trade-offs. This is a trade-off that you absolutely had to make in order to support the number or the sort of scale that you're at. Do you do those binaries? Are they statically linked or can they reference libraries on the system? Or how do you navigate dealing with library code or other system dependencies? Yeah, so most of the time they're dynamically linked. So we will link to stuff provided by Apple, and we will link to stuff that's provided ourselves in other packages, bottles, libraries, etc., which is where things get a little bit more complex because if you upgrade a library and then you have to rebuild everything and that's how you get your, you know, 72-hour CI jobs. But yeah, so that's essentially this, you know, these cascading chains of dependencies where you have to ensure all the linking between all of them is consistent and stable and all that good stuff. And you sort of alluded to another change, which is this removing optional compile flags or kind of reducing the sort of set of options available. Yeah. So that's probably my, I would say, most impactful in terms of making homebrew long-term, scalable, and maintainable. But definitely the most overwhelming negative feedback I've ever received for any bit of work I've ever done and was probably the first thing that built me a much thicker skin in open source. In fact, speaking with thicker skin in open source, like just as a funny anecdote, again, like so right now I have a person who was banned from the homebrew issue tracker last week, who is now on his third new email account that he signed up with just to send me a piece of emails and I'm having this fun back and forth of he has now had two GitHub accounts banned and I'm just going through not replying to any of his emails and one by one taking the time to make sure that every new email he signs up with gets banned by this email provider. So it's, you know, like only with maybe 16 years open source could this become a fun pastime of like recognizing every time he's going to try and log into some new email provider or GitHub account or whatever, like seeing that it's banned and me taking the satisfaction in that despite not seeing like him actually seeing any response from me. As an aside, like so that example you mentioned with the options, again, this was a thing that became the natural end of the road with the, so as I mentioned, we started off doing the binary packages just for a few select packages and then we got to a point where we're like, okay, like basically everything is going to be better with these binary packages. But the problem is if we provide options, like we don't really have, we have never built and like all these things in open source, if someone had come along and built this, I would have been delighted, but no one did. We don't really have a way to kind of have this optional behavior with our binary packages. And what happens is when you provide these compile options, then those people are just falling back to building from source. We go back to this world in which everything is, again, very complex. Lots of things can go wrong. We get lots of issues filed. But also when you have, again, this is obvious to anyone who's done, you know, a decent amount of, you know, even probably high school level maths. But right, if you have one option, you know, in a formula, then you have one thing that can, then you essentially have a, that can be on or off. That's, you know, two combinations, right? You get the combinatoric explosion. Exactly. Yeah. So you have two, you have that, you have three, you have, so, you know, we would have many of our popular formulas would have five, 10 different options. And there's just a, from our perspective, felt obviously not literally, but a perceivably near infinite number of things that could go wrong. And just, we ended up constantly having this whack-a-mole, right? And some of the kind of power users said, well, you know, you could have just said that people shouldn't file issues. And, you know, like you didn't need to take away our toys just because some people were misbehaving with them. And it's like, unfortunately, again, when the scale of something like Homebrew, you only need 0.1% of users to be regularly doing the wrong thing before you just have this absolute diluge of noise. And what happens is, again, like the most, it's funny because there's a lot of talk for a while about like problems in open source and funding and sustainability and scalability and all this type of stuff, right? I think a lot of that's overblown. But like one of the things I do think is if you want to talk about sustainability in open source, the scarcest resource available in open source is the time of a maintainer, right? Money is good when it can give you more time for existing maintainers. Often it cannot. But in this case, you know, you can say, okay, well, just close these issues, don't respond to them. But it's like, but every time a maintainer, and often with the way it helps notifications or whatever work, it's not just one maintainer reading that. It's one or five or 10 or 20, right? Like say even one person reads this, you know, if we're getting 75, 90% of our issues are just this noise, then that is all time that that maintainer, I guess in many cases it was often me, cannot fix your bug. Like, I cannot release your feature. I cannot release a critical security vulnerability update because I'm spending all my time triaging just all of this noise, which essentially the only way to make it go away, because we would tell people again, like, don't file these issues, please. People keep finding that the only way to make it go away is to take your toys away and say, sorry, this kind of option behavior, it does not work for us to be able to maintain a scalable package manager with these around. And yeah, to this day, I still meet people who are very disappointed in this choice. But I think if they were aware that there was a time when it looked like we either do this, or literally the package manager will die, and everyone will quit, then they realized they would maybe realize that like, well, that that was preferable to the other outcome. I mean, I spent a couple years, about a couple years as a primary maintainer for a big open source package, I was paid to do it, right? It was a job. And it's still like, it's so exhausting to deal with the noise. And yeah, that is hard. So how, this is one example of a way that you've made maintaining homebrew a little bit more sustainable. How do you think about creating a sustainable environment for your team of maintainers? Yeah, I mean, that's, I guess that somewhat alludes back to the, the thing I said earlier, well, two things, I guess. So one is the most valuable primary resource is maintainer time. And to me, what that looks like is, I mean, in a funny way, you could say, maybe even maintainer time is an output and maintainer, and the input is maintainer motivation, right? So what that looks like is most of our maintainers, right, as I mentioned, people receive a small stipend of like $300 a month. I mean, some of our maintainers are maintaining, are like, you know, merging 300 pull requests in a week, right? So the dollar by time, like compensation. You don't do this to make money. It's not a money driven thing, right? Even, I guess, me working on it for 16 years, like the vast majority of this time, I have never been paid anything to do any of my work on homebrew. And there's never been a time when I've had more than maybe a couple of months where my primary paid responsibility has been doing anything related to homebrew directly. So like, as a result, you need to just be like, how can this stay interesting and fun and healthy and whatever? And what that looks like, again, something which I've got a bit of flack for, but I very much stand behind, is homebrew has to be a safe space for the people who are working on it. And that doesn't mean, you know, we can't have challenging conversations, and it doesn't mean we can't disagree and whatever. But what it does mean is if someone is being abusive, as nowadays, it used to be I would give them, you know, two strikes, three strikes, whatever. Nowadays, my general policy with an open source and somewhat in life is if you are being a very unpleasant, mean person, even if it's completely unintentional, like I have found, if you receive one notification saying, Hey, this is not okay, your behavior is not being appropriate, that you can judge how well that will go from the person's reaction to that, like someone who even tries and gives a horrible apology about like, I'm sorry, you felt that way, blah, blah, blah, like, you can still tell that like, they're trying, they've maybe never heard a good apology, they may be never given a good apology. But you know what, they're trying, and they're trying to adjust their behavior. Like, those people, I will give them a bunch of chances. But when someone is called out on their behavior in that way, and their response is to double down, or get incredibly defensive, or say, well, no, actually, you are the problem. Like you, you go read your code of conduct, you're bullying me or being mean, or whatever it may be, right? Like, that never ends well. Like, and if you read through people getting blocked on homebrew, sometimes people get blocked on homebrew, for what seems like almost nothing. But the reason why they get blocked is because, A, we've had a conversation privately as maintainers about this, and what's going on. Sometimes there's a bunch of stuff where someone only says one borderline thing in public, but they've sent a bunch of private emails to a bunch of people, which are significantly worse. But often, it's just like, I've been doing this for 16 years. And frankly, like, I can just tell when this is not going to end well. So the quicker we can just shut this down, the better, right. And I think that's what it looks like. Another, I guess, maybe more recent addition is, you know, for the last, maybe six years, bar a couple years break with COVID, we try and have most of the maintainers meet in person, once a year, right. And if you looked at people's contribution graphs and get up, there was an explosion of activity when that happens. Because, again, people, you're re-energized, and you meet people. And also, like, when I promised I was going to review someone's PR, and I see them in person, and then over drink, they're like, oh, did you review that PR? I'm like, oh, shit, I'm really sorry. I'm going to go review it right now, or whatever, right. And that's helpful, and it's energetic. And it's something I felt like I learned back in the day from KDE of, like, going to their conferences when it was, like, hundreds of maintainers back in, like, whatever it was, 2007, 2008, you know, and just seeing, like, oh, yeah, like, this is, you need to build something I'm not very good at, personally, but, like, you need to build a community. Like, we've talked about the community of contributors. There's also a community of maintainers, and that needs to be a small group of people who remain actually regularly using, contributing, and maintaining homebrew, who feel like they're a bit of a team, and they have some sort of sense of collective identity together. And, like, I think that helps a lot. And it also helps with, as I mentioned before, with kind of people being abusive, is, like, I just go into, even before I had kids, I go into protective dad mode, and I'm like, you know what, you can say a lot of shit to me, but the bar what I'm going to tolerate for my team of people who are spending their evenings and weekends trying to build you shit that you get to use for free, my bar of the amount of abuse I'm going to let you give them is not very high. And if that means that homebrew has lost some valued contributors over the years who we just needed to tolerate that every few months they were going to go and be very rude or ruin someone's day, so be it. Fine. We can be less. That's the one area of almost, like, productivity decrease I will happily accept is, like, if we can have a twice as fast homebrew where everyone has to deal with assholes all the time, or we can have a half as fast homebrew, then we can have a half as fast homebrew that's a nicer place to deal with. I'm aware of saying that, you know, if you Google Mike McQuaid asshole, there is a, it's a not minority position that I myself am an asshole, but I do this from a position of trying to make it a better friendly place for people, so. Yes. I think I have no stake in this, and I'm not in the community, but I wish more parts of the tech ecosystem had that type of zero tolerance for asshole. Yeah. I just, I don't know, like, again, not naming names or employers or whatever, but I've definitely, I'm sure you're the same, Kevin, where there's been people who have had problematic behaviors at previous companies I've worked for, where the signs were there in the first week, right? And I have said that, like, before when I was like, as so long as I have any influence, right, if you push the boundaries, I know you're coming really close to the line in your first week where you should be in a good, happy place, you should be trying to impress your coworkers, we should be trying to impress you. If that's the first thing you do when you enter a company, not a good fit, right, as far as I'm concerned, because at the end of the day, you know, and again, that's the other maybe difference with Homebrew compared to some other projects is that, like, we are, you know, we have a lot of perks that you don't get at work in that no one can really tell anyone what to do. I can tell people, I'm not going to let this PR be merged as is, but I can't say you have to go off and write this code by tomorrow or else, you know, like, no one gets to do that. That's nice. And you don't, you know, so you don't really have bosses bossing you around to the same extent. But the flip side of that is like, you know, I want us to have the level of interaction that would be considered standard in a workplace. And that means that, you know, just being abusive and, like, flaming people and whatever and, like, losing your temper, like, that's, you know, these things happen. But, like, essentially, how much slack you're going to get cut is proportional to, like, how much time and effort and energy you put into the project. If the first interaction we've ever had with you is very negative and angry and whatever, then no, not interested in continuing that. But if, and this has unfortunately happened with Humber in the past, if you're a prolific contributor who's been very involved, maybe a maintainer for a long period of time, and over time, those rates of problematic behavior rise and rise and rise and rise and rise, eventually we're going to have a conversation where it's like, either you need to fix this or we need to part ways. And, like, much as, like, in a job situation, you can sometimes have those people who, they used to be great, but, you know, either they changed or, in happier ways, the culture changed, right? And we all change to be people who are not going to tolerate that anymore. And I guess if there's a last note on that, if you're a maintainer listening to this, like, I would encourage you to read, like, one of my most cited posts, as far as I could tell, that I'm the proudest about, is a post I wrote a few years ago called Open Source Maintainers Owe You Nothing, which is basically, if you look through the licenses of open source software, then that's what it says. Essentially, it says, you know, we do this without warranties or disclaimers or promises of damage. And, you know, how much of this is legally enforceable is debatable. But, like, literally, most open source licenses say if a maintainer was to push out a change that deliberately destroyed all the files on your machine, like, in agreeing to the open source license and using that, you are agreeing that, like, you can't hold them responsible in any way for doing that, right? I think most people would agree that's when it crossed the line. It's been like, you know, maybe you're legally okay, but that would, at the very least, make you a bit of a dick. But the thing that I think is so crucial about that way of thinking is, it's like, if you're a maintainer, you do not have to do anything that people don't want you to do, right? And if your project, maintaining it, is not fun or interesting for you anymore, and you're just being guilted into doing things, then you can stop, and that's okay. And not only is it okay, you probably should do that, right? And you need to find a way to have your responsibilities on that open source project be something that actually you find interesting and engaging. And as you mentioned before, Kevin, like, sometimes the way you can do that is, like, I take a job where I get paid to do this, and sometimes I don't like it, but then I look at my bank balance, and I'm like, okay, this is fine, because it's worth what that is. Exactly. Yeah. If you're getting paid for to do a job, there will be parts of it you don't like that you still should do. If you're not getting paid, which most open source maintainers are not, like, you darn well better enjoy it. Yeah. And even on the, you're not getting paid, like, I guess I would extend that to say you're getting paid, like, a reasonable market rate, right? Like, someone who's getting $10 a month to get up sponsors, also does not owe anyone anything, really. Correct. Yeah, for sure. I think this is the thing. And to me, this is, again, back to open source sustainability, where I think, like, the, without sounding too, I don't know, like, cliche or whatever, like, I think a lot of sustainability comes from within. And it's about figuring out, like, what is sustainable for me as a human, like, and what can I do? And what is, you know, since I become a husband and father and whatever, like, what can I do on homebrew that is not going to negatively impact my family, right? And that is, again, all of the stuff that kind of goes into running an open source project that people don't really think about, because you don't necessarily have anyone who's going to be saying to you, hey, like, you know, like, it's 11 o'clock on a Friday evening, like, you need to be up early tomorrow. There's a problem with homebrew, you're staying up late, dealing with this right now, like, maybe you just need to let it slide. Maybe you just need to let people suffer until tomorrow morning, because actually, you need to get a good night's sleep, because you're going to be grumpy with your family or whatever you've done, right? And in most good workplaces that I've been in, your boss, or your co workers would be the people nudging you in that way. Whereas an open source, again, historically, there's not been as much of that. And something again, I hope for homebrew sake, and we do see a bit of that is when people are saying like, oh, you know, I need to step up till this is fixed. And people like, I got this, or this can wait, right? Like, you need to look after you. And like, that's the stuff that keeps people around and happy and, you know, keeps humans maintainable, as well as the software. 100%. All right, well, we're coming close to the end of our time here. Is there anything we haven't talked about yet that you think would be important to touch on or leave people with? I don't think so, especially, I guess, just to maybe extend even more of what I was saying before, like, you know, I guess I found in work in the industry for whatever, it's been like, 18 years and open source for, you know, 16 with homebrew and a few more, like it, a lot of this stuff that I maybe dismissed when I was younger about the human interpersonal stuff and squishy feelings and therapists and boundaries and all of these, like, you know, cheesy grown up words, or if you're Scottish, like cheesy American words, it's, it's all really important at the end of the day. And like, this is what stuff is built on the back of. And like, something I, I really admire when I'm looking at, you know, the LinkedIn or resume or CV or whatever you want to call it of a person who's applying for a job or I'm going to work with or whatever, is like, you know, like, we've got this industry expectation that like, you know, you don't want to be at too many jobs for like a year or less, right. But I really love when I see people who've done one thing for a decade or more, right. And I guess like almost like a challenge I would put to anyone listening to this is like, what would it take for you to be happy in your job or your industry or your open source project, or, you know, maybe to be even deeper still like your marriage or your house or your friendship or whatever. Whatever. What would it take for that to be still in a really good place in 10 years, right. And think about what you can do to get there because, you know, I used to say to myself, like, oh, you know, I've got 10 years homebrew movie and then I'm going to quit. But then I'm like, well, you know, maybe I've got 20 or 30 or whatever. I don't really know, because it remains sustainable for me to do. And it remains, hopefully at least beneficial for others to kind of receive the kind of work I'm doing. And I think, I think the world is much better when people can focus on that. And often, you know, to quote every flight attendant or whatever, like putting on your own life mask first, like helps us all be able to do more better stuff together than it does when we're monitoring ourselves. And then we burn out in two years or whatever.

It's really funny to hear them talk about it. All right, let's begin because we know we got a hard stop. Well, we are here with a breaking changelog. Justin asked me to do that pun. A crossover episode. We are publishing shows to both changelog and friends and to Justin's breaking change. Merge conflict. I don't know what this is on his pod, but it'll be there. The explicit version will be over on Justin's side. On our side, there will be bleeps because we also have not just Justin, but also Mike McQuaid with us. What's up, Mike? Thanks for having me. I hope to make heavy use of your bleep counter today, as is my Scottish self-employed tradition. Well, Mike's only requirement was that there would become a non-bleeped version of his voice out there on the internet talking about this, and so Justin will happily oblige. Yes, and I'm not going to make it a contest or anything, but I've got a feeling I'm not going to go bleep-free for what we're about to talk about. And the reason for the bleeps is because we've got trouble right here at Ruby Central. Yes, that's an old music man. What is that? Reference. For a new problem. Maybe not a new problem. An old problem. An issue that's been going on with Ruby Gems, with Ruby Central, with Ruby Together, with Ruby. The community, more so than the programming language. Language is doing just fine, isn't it, Mike? Seems to be. I wrote some today. It still works. Yeah. Did you install any Gems? I did. They installed okay. It seems to be fine. Yeah, I was actually doing an iOS project when all this stuff broke, but then I was worried that, like, you know, Ruby would stop working. So I dropped that, switched gears, and now I've been working on my posse party project in earnest to try to get it done before the servers turn off. Just in case. Just in case. Well, there's a lot of ins, a lot of outs, a lot of what have yous, as the dude would say, to this particular story. More, probably, than I can summarize, which is why I've mostly ignored this in Changelog News, because there's just so much going on. And every once in a while, I just link over to Justin, who's been commentating and color commentating. But we're going to let Mike try to set the table for us, just some of the events that's going on. For those who are uninitiated with some of the Ruby drama that's been percolating and coming to a head recently with an actual root access event published on rubygems.org. So, Mike, help everybody understand exactly what's been going down. Yeah, so I guess things kicked off probably what we are. We're October 15th at the time of recording. So, this time a month ago, things seemed to all be fairly normal and stable and whatever. No one seemed to really know much. And I guess my first personal involvement was there was like a governance PR on RubyGems that was based on the homebrew one. I was pulled in and asked to kind of give my thoughts on that. And then a few people started messaging me and whatever. But essentially what went down is Ruby Central, for the main parties involved here, is the nonprofit organization that controls rubygems.org. And they had as employees and contractors at various points, various maintainers of RubyGems, the open source projects. And those people were involved with rubygems.org, kind of on-call rotations and whatever. So, essentially, kind of, I guess, last month, you know, we're talking, I think, September the 18th or whatever. From then onwards, over the kind of following few weeks, the Ruby Central notified RubyGems maintainers, including, I guess, Andre Arco. Like, I guess, if you want to read the two differences of accounts, I guess the starkest extremes here are Andre's written a few things on his blog. RubyGems have written a few things on their blog. And basically, from September the 18th onwards, Andre and some other RubyGems maintainers were removed from the on-call rotation. They were removed from their GitHub access and various bits and pieces went down. There's kind of back and forth and arguments and disputes about what was communicated exactly by who and when and what happened and what didn't happen and whatever. But, essentially, we're at the point today where almost no one who was involved with RubyGems, the open source project, has access to be involved with it today. Andre and a bunch of the other RubyGems maintainers have created their own thing called gem.coop, which right now is essentially like a modified version fork, whatever you want to call it, of rubygems.org. It's run as, like, separate infrastructure. Andre has personally been involved with kind of some competitors to, like, Bundler and RubyGems and whatever. I think there's a tool called RV. And what seems to be now public knowledge is that both parties are writing various blog posts, targeting the other, and it sounds like there's some kind of lawsuits in action between various parties as well. Does that provide the overview you're looking for, Jared, or do you want a bit more color on particular bits? I think that's a good overview. I think that brings us to what seems to be the biggest milestone or moment, which was published just last week by Shan Kiriton, executive director at Ruby Central of this AWS Root Access event that happened in September. Justin, you want to hop in here on that, or do you want Mike to continue? Yeah, so if you're, uh, if you, if you had been following along the thing that everybody had been clamoring for, kind of regardless, like, people are taking sides. There's a lot of, even though we're not public figures, we're not famous people. It's like Ruby's been a smallish pond for a long time. A lot of these people have been there for 20 years, 20 plus years. And everybody kind of knows everybody. If you go to the conferences and we've all seen each other and people talk and there's different cliques and there's different groups. And so like, regardless of like, kind of like where your allegiances fall in terms of who, what friend group is sort of thinking this way or that way. And, and, and, and, and where things line up in general, that's like, I'm talking about a universe of like 200 people max and like way more people in the world use Ruby and, and also read the internet. And so they've been operating under this complete lack of complete just information of like, what's the whole story? Like something isn't adding up here. Uh, you know, some people have been happy to fill the void with like sort of conspiratorial thinking throughout. Like, this is all a takeover from Shopify. Cause they're trying to get after this one guy. And it was like, okay, so why? And then no one's got an answer for that. Right. Like, uh, and other people are just very honestly and earnestly being like Ruby central saying that they just removed everyone for supply chain reasons. Like why? And Ruby central is not talking, right? Like, and so that, and, and all you get is like kind of hand wavy. Oh, well, because the lawyer is telling us we can't or something like that. If you, if you ask people, uh, this blog post, which what was it? Was it the 30th? No, it was, it was more recently. It was about the event on the third. Was it published? It was published October 9th, October 9th. So the event might've been the 30th and not yet the event. No, on the 30th was the blog post that raised concerns. That's right. So part of why this is confusing is the post is a timeline, but the timeline is like three timelines in reverse order to, to, to first talk about like the last thing that happened and in what order things happened when the last thing happened. And then the next section explains like the why that, the why behind that. And then the next last section is the why behind that. Uh, and if you were to like, and I, and this is why, as soon as I read it, I put up my own blog posts. I kind of tried to unspool it to explain like, what are the stakes, what this reads like to me when you, when you go through it. So I'll first try to like summarize the, it's characterized as a post-mortem of a security incident response where on September 30th, uh, person named Joel Draper or Draper posts, a blog post that says, uh, yo, Andre Arco still has all these systems accesses. Like the only person who's like the only person who's, he's the, the only owner of a particular GitHub organization. Uh, he's still got these AWS accesses. And, and I think that the, if not expressly stated implication of the post is this is how incompetent Ruby central is that like, here we are weeks after supposedly having these accesses removed. He actually still has this access. And so look at how insecure this is. Like, you know, this is, this is Ruby central, not having their act together. Because they had taken access away from Andre as well as other Ruby gems.org maintainers prior. However, Andre still had access according to the Joel Draper's draper draper draper. It's two P's. I don't know. Two P's, but Joel Draper just sounds more natural. Yeah. And my wife and I are rewatching Mad Men coincidentally. Yes. And so it's just like, it's really hard to separate. I agree. I haven't seen it for years, but I'm still saying Draper. Anywho, this post that he says on September 30th is that they're so, I mean, the implication is that the incompetence of Ruby central, who is the, is it a foundation? Is it a nonprofit? Help us understand some of the entities here. Ruby central. Is it a for profit? My understanding is it's a 501c3. Okay. Which I, frankly, I really wish I didn't know about U.S. nonprofit organizations, considering I don't live there and I never will. But yet I've been involved with like open source nonprofit stuff long enough that I'm sadly intimately aware. So a 501c3, they're, they're somewhat hard to establish nowadays because various government agencies have decided that like open source software is a bit too easy to look businessy, right? So basically it's an organization that exists to own the assets of Ruby gems. It merged previously with Ruby together, which was started by Andre. I don't know who started Ruby central personally, but basically it exists as an entity to provide legal ownership of the service, to provide the ability to receive tax-free donations from individuals and companies, and then redistribute those to whatever nonprofit appropriate areas that they do, which has been Ruby gems maintenance, Ruby gems on call, some conferences, et cetera. And there's a lot of moving parts, which makes us hard to track. There's like the repos on GitHub. There's the servers that are actually running said code. There's the access to the servers. There's other things that make this just really hard to track, but back to, so that's Ruby central, the entity back to where Justin was. They published this post about Joel Drapper's post saying that Andre still had access or implying that there was still access. So, so, so before the post post, don't worry. Like, like they actually were notified of, of this permissions exposure. So it wasn't a zero day announcement. No, yeah, they had, it looks like seven minutes where Andre emailed them that he still had these accesses and that this was the only disclosure. Gotcha. Joel post goes up, uh, uh, you know, at five 30 UTC, uh, you know, and now this is Justin, the guy just reading a blog post or forgive me if my characterizations are at all inaccurate. Uh, you know, at that point, Ruby central has to treat it like a security incident. So they go into emergency mode, try to lock down all these systems, uh, initiate password reset, uh, and then begin a, a relatively long, you know, investigation of all these other knock on systems first over the next few hours. And then the next few days, uh, when, let's see the, the, when they backtrack, right? So that's September 30th. Then there's an analysis of events that goes back and says, Hey, look on, on September 18th, Ruby central notified Mr. Arco via email that he was going to have his access removed or that it had been removed. Uh, and while they removed his particular IAM, I assume like AWS account that presumably would be tied to his email. address, uh, they, they did not rotate the password on the AWS route account. So, you know, like if you're familiar with AWS, there's typically an email address and a root password, uh, or an email address that is effectively the root account. And it's bad practice to use that thing. Right. And log in as it, because you don't have any of the sort of like, you know, policies and procedures available to you. But because Andre was like kind of the core, one of the, one of, if not the core operator of Ruby, uh, gems.org for so long, uh, it appears that even though that he was removed from whatever their password vault system was, presumably like a one password. Uh, he had a separate copy of, of that password or that login item somewhere. Uh, because even though his, you know, email was his, his individual AWS account was apparently according to Ruby central disabled. Uh, it looks like roughly eight hours, uh, after that notice sent, uh, they state that an unauthorized actor from San Francisco logged into that AWS account into the root AWS account and then proceeded to change the password. Uh, and as far as they know, didn't do anything else, I don't, I'm not an expert in, you know, cloud forensics. So I have no idea if that's a thing that like Ruby said, it's like the absence of evidence is what's leading them to say that, or whether they have any sort of like, you know, dispositive proof that nothing. I think I read somewhere that they did have some, like, there's like some sort of immutable time-based log and they confirmed from the log, like what had happened, what hadn't happened. I read both sides of that and I think Mike's, what Mike just stated seemed like it was more informed than the ulterior, which is once you have root access, you can change everything. I don't know AWS well enough to confirm or deny a side, but I, that does, that did at the time of my reading seem to be the most reasonable stance that they could confirm it. That being said, I also don't know for sure. Yeah. I, I, I, I pride myself in my ignorance when it comes to DevOps stuff. So I'll take your word for it. AWS stuff. I, I think the thing that jumps out at me with a lot of this stuff is you, you, you can plausibly see why both sides thought they were doing the right thing a lot of times in, in this, right? So like from, I guess, Andre's perspective, what's been published is he says like, well, I thought this was, I didn't have enough information to go on that. This wasn't, was a legitimate event and it wasn't like someone at Ruby central's email or GitHub account or whatever had been hacked. So I was trying to do what I could to preserve the integrity of the service. But I think like what is hard for me with the communication of both sides, right? Is I think particularly unsurprisingly now that maybe some lawyers are involved is that I would love to, maybe it's the, just cause I'm British. I would love like a bit more from both sides and saying like, Hey, turns out in hindsight, I didn't do the best thing here. Right. And going forward, if you find yourself in the situation I was in, my advice to you is to do X instead of Y and I did Y, right? And I think that's the hard thing with all this is that it, we're now at a point where there seems to be like some degree of stability and it doesn't seem like Ruby central is going to be inviting the folks who've left, including Andre back into the fold anytime soon. It doesn't seem that like, you know, Andre and co are going to take control over Ruby gems, GitHub org or whatever, anytime soon. Like, but I feel like the main parties who have suffered through this are people in the Ruby community who, of which I include myself, who are just have a lot of uncertainty of like what's going on. And I can't remember if I said this publicly or privately, but like essentially the person I feel the most for is anyone in the last month. Who is trying to pitch a new Ruby project at work with, to a management or leadership team who looks at Hacker News even once a week, right? Like good luck, right? Because a whole lot of fear, uncertainty and doubt has come into this. And also like, I think both sides, I see, you know, I'm, I'm a strong proponent of, you know, I wrote a post a few years ago, which some people hate. Some people love called open source maintainers. Are you nothing, which points out from like a legal liability perspective, essentially every open source license says like, if you don't like the terms of that I'm providing you here, you can go fuck yourself. And just take what you're given and like it, you know, and from that perspective, like I am sympathetic and I, I tend towards my sympathy being towards the maintainers. But at the same time, we have like a critical part of the Ruby ecosystem, which essentially had no governance process, no public governance process whatsoever, right? That had, and still has to some degree, very little beyond the legal required levels of financial transparency of required of like a 501c3. And a lot of figures making decisions and making statements where most people like, I don't know who this person is, right? I don't know who this person is, how they got access, who's right, who's wrong. Are my Ruby gems safe or unsafe or whatever, right? And I think that's the part about this, what I find really frustrating is that like a whole lot of people are still in the Ruby because we're still being disrupted by this. And it doesn't seem like it's going to get solved anytime soon, maybe ever, right? Because right now, both parties are now just in damage control. Because both, again, like both sides on, I had someone that was Blue Sky or Mastodon, whatever, who was basically, oh, blah, blah, blah, you seem to have switched sides on this. And I'm like, well, I don't think, I mean, rarely in life is there a situation where what side A is 100% right, side B is 100% wrong. But like, this is definitely a situation where that's not the case. Both sides have made mistakes. You may well be inclined more towards one side than the other. But like, both sides have to do things to repair trust and fix things and improve things moving forward, right? I'm going to just jump in real quick. Sorry, Mike. Because I want to do point out like two of the things from this timeline, then we can move on to the bigger conversation. Like, open source maintainers who have an MIT license indeed owe you nothing. However, part of the complexity here is like what's under dispute. And this is just like a natural, like, and I wrote about this in my first post on the topic. Like, the fact that Ruby itself is 30 years old, mostly maintained by a committer group that's mostly based in Japan. The Ruby Gems as a tool was created in America by Americans initially and then hosted in America, has a separate lineage. And there's a three-legged stool between, like, custody of the code for Ruby Gems and then later Bundler and then later they merge, custody and management of Ruby the language, and then, like, RubyGems.org, which is like a going concern and operational, you know, system that is running in the cloud. And so, from a just accesses perspective, like, we're not talking about, like, who's got commit bit necessarily. So, when they say that he logged in with the rude email eight hours after getting noticed that his personal access had been revoked, and then he changes the password, and that's on September 18th, you know, you scroll down, and it also says on the 28th, he logged in again while he was in Tokyo at Kaigi on Rails, another conference event. And then it's only on September 30th, seven minutes before our blog post, that there's any disclosure whatsoever, right? So, like, if he was concerned about the security, their implication in this post is if he was supposedly concerned about the security, had there been a, you know, had this exposure been leaked out to other maintainers or if it was out in the wild or something, like, 12 days is an awful long fucking time to sit on that information and not disclose it. Additionally, when you go back and ask, like, so why did we get to that point? Like, what actually happened? You scroll down, and the precipitating event to why are we getting serious about supply chain security was apparently, and this is an event that, you know, predates August 3rd. So, presumably, you know, when, and I haven't met her, Shan, the new executive director at Ruby Central, doesn't have a lot of technical technology experience, but does have nonprofit experience. I imagine, you know, Mike, if it's as dire as you're saying in terms of, like, lack of governance, lack of policies and procedures, my understanding is they didn't even have, like, terms of service and privacy policy up at the website until earlier this year. I suspect she probably came in and she's like, we got to, like, get serious, right? We got to run this thing better. We got to introduce the, you know, standard operating procedure, you know, make sure that we're buttoned up from a regulatory perspective. And then we got to, you know, understanding Ruby Central has been extremely budget constrained since, since RailsConf and RailsWorld turned into the schism, also get the budget under control. And so, I knew, and I talked to Marty about this, I think, like, maybe late last year, early this year, when he was taking on the role at Ruby Central, that they were trying to get more, you know, serious about controlling the finances and getting the budget managed well. And so, like, when you, when you go through the timeline, apparently they cut the budget for secondary on-call rotation for rubygems.org, which had previously apparently been $50,000 annually, and that all of that had, or that, that amount anyway, had gone to Andre Arco's, you know, consultancy to provide that service, even though it was rarely invoked. When he was informed that they were removing that budget, he sent an email to Marty that was, you know, kind of spitballing an idea, it looks like, to say, well, in lieu of getting paid in dollars, if, if, if I could be permitted to have access to the HTTP logs, that could then be used for, presumably by a company to do some sort of analysis for some sort of marketable purpose. Uh, and there, you can debate whether there's any sort of like PII implication, or if that could be discerned from the logs. And, and Mike, my understanding is you probably have, being the homebrew guy, probably been approached by similar companies in the past, uh, regardless of the actual mechanics and what the, what, what that would look like. It was pretty clearly not something in the privacy policy currently, or the terms of service. And so this, that email is received on August 3rd, and then it looks like the board and leadership team, and I'm imagining now, and this is just speculation on my part, Shan is executive director, who's not, you know, still trying to get her bearings and trying to button the stuff up, probably sees that as like, and this is the person who has all of the access to all these systems and could just take it anyway. And it's upset that, you know, we're cutting the budget, like that's probably the precipitating event. And that's how they characterize it in this email of the thing that leads to, we got to tighten up the security and these accesses and get to, we don't have an operator agreement signed for all these people who have the, you know, operational access. And we don't have committer license agreements for all the people who are committing to this code base and could cause, you know, disputes later. And so we got to get those in place. So like first cut everyone's access, get the agreements in place, and then we can start to rebuild on a, you know, firmer footing is my understanding of the timeline. Now, like that's, that, that's what I read reading this, right. It is like, and it sure, it boils up to unauthorized access, ultimately acute alleged against Andre and changing the password and not disclosing it. But, but do I have anything there based on your, cause Mike, you've been in a lot of the same discussions that I have. And with some of the principles did, is anything that I just characterized wrong or is anything you'd want to add to that? Yeah. I don't think there's anything massively incorrect or whatever there, I guess for me, it's kind of an emphasis thing. And I, I, just to jump back, like, I guess maybe a bit of context that might be helpful for folks of where I fit into this party, right. So I'm a homebrew maintainer, homebrew being a macOS package manager. If you've not used it before, you can use it on Linux now as well. Yeah, I've worked on that for 16 years. I've essentially been probably the main person since the creator left, who's kind of stepped into leadership stuff and have kind of led us through various levels of financing and fiscal hosting and all the kind of, a lot of the kind of boring non-profit-esque stuff. But notably, homebrew does not have a dedicated non-profit. We do not have any dedicated employees or anything like that. But we have an open collective, which essentially, if you've never used open collective before, is like a online banking app, but is in the spirit of open source public, right. So you can go and see two homebrew maintainers went out for lunch about a month and a half ago in Singapore together, as our expenses, public docs say that they can do. And they had lunch, they talked about homebrew, and they expensed that to the project, and I approved that expense, right. So, like, essentially, all the money coming in and out of the project, you can just go and look, right, without even logging in and see, like, what's going on here. You can't see people's specific receipts with their credit card numbers for hopefully obvious reasons. But the thing I struggle with with a lot of this stuff is, like, like, okay, homebrew and RubyGems will be going for about the same amount of time. RubyGems has definitely received dramatically more money in that time, I would bet, than homebrew. It would surprise me if it was as little as 10x more than homebrew. But yet, we, a group of volunteers scattered around the world, have been able to have transparent governance, transparent finances for, like, five plus years. And, you know, I appreciate, like, this is all part of a kind of tightening process and whatever. But the thing that, to me, that all of these kind of blog posts and a lot of the discussion is missing is, like, okay, who got what money from who and when, right? Like, that goes as far as Ruby Central employees, Ruby Central board members, Ruby Central contractors. It goes, like, you know, there's been a lot of conspiracy about, like, how much Mike Purim, like, has provided or removed funding. DHH has provided or removed funding. Shopify has provided or removed funding, right? And I don't even want to speculate on one of those because I don't know what's true or not true. But the thing I find slightly depressing about it all is, like, it would be very easy to have all that information be at least semi-public, right? But it's not. So it becomes, like, an exercise. And I do think, again, like, with the, like, what access Andre had to what and when and how and whatever, I also think, again, what I said earlier about the open source maintainers owe you nothing thing. It's like, at that point, is he an unpaid volunteer working on a service, right? And providing that to the best of his abilities. Like, if I certainly think from the accounts we're looking at, had Andre never received a cent from Ruby Central ever, I think you would read his narrative and be like, that is 100% defensible, like what he did. And Ruby Central are 100% of the wrong because they are a well-funded organization with full-time employees who, like, sorry, the bar is just much, much higher for them than it is for unpaid volunteers. But if volunteers are paid, how much are they employees? Are they contractors? Like, what's their contract say or not say or whatever? And I think that stuff is where it just all gets very murky. And that stuff is where, personally, it makes me not happy that this is happening. But I've been sort of saying, sometimes privately, sometimes a bit more diplomatically publicly for years, that like, hey, look, it seems like a lot of people have decided that open source sustainability is a problem we solve by just throwing more money at things, right? And this is the type of thing that happens when we do that, right? It's not to say that we shouldn't, no one should have been getting paid, or we shouldn't have had money or whatever. But like, once you start getting a lot of money involved in these things, things get very complicated, right? And you need to have significant levels of like, maturity and governance and transparency and experience in open source and experience in nonprofits to not fuck it up. And then maybe even if you have all those things, you still fuck it up, right? But like, I think that's where this stuff gets interesting for me is I'm like, well, you know, in some ways, if you were to look at homebrew and look at RubyGems, you would say like, well, you know, homebrews all this in this precarious, silly situation, because they don't have a dedicated nonprofit, they don't have significant corporate backing, whatever. But in a funny way, we are immune to a lot of the problems that have happened here, because we have not gone in so hard on like, we now have significant dependencies on paying significant numbers of people, like their monthly wage, right? And again, not to say we're doing it better, they're doing it worse, whatever. But I think there's a lot of the open source, I guess I sometimes call it like big open source, right, that is trying to push a lot of people in this direction, that like, we all need to just get maintainers to be paid full time employees, right, and contract everything out and whatever. And I think what gets lost is like, well, what happens if we do that, what are the pros and cons, and to what extent that events like this happen, or at least get a lot more messy and complicated than they could have been otherwise, if there was not the same degree of money involved. So if I were to just jump to the end of this, and I'm going to jump right back where you are, Mike, but if I were to jump to the end, it's a guy who just types gem install every once in a while, or bundle, right? I know you two, I've interviewed DHH, I've interviewed Shopify people, I've never met Andre myself, I'm tangentially related to the Ruby community, as a regular old Ruby user. And to speak to Mike's point from earlier, at the end of this is a rubygems.org AWS root access event. Like, if that's what I hear, and I find out it was days or hours, or however long it was, and was it Andre, was it somebody else, were they malicious, were they not, can we verify it? Like, that's a five alarm fire, isn't it? I mean, I install my gems, just like anybody else does, unless you've switched over to gem.coop, from rubygems.org, and somebody had root access to their AWS account for some amount of time. And that's probably all that I'm hearing, maybe a little bit more about other things. And so this, the end result is a disaster. I mean, this has been disastrous. And now we're in, like you said, Mike, damage control. And so that's just incredibly unfortunate, and a fact of history now that I think comes from whether he said, she said, they did this, they did that, who's to blame, etc. It comes down to, like, money has just muddied and created no end of trouble. And it's just really, really murky now, like, how you navigate money and open source. I mean, just combining those two things together, which has been a desire and something I've preached for many years, is, like, we need more money in open source. We need to fund these people. We need to sustain these people. We need to help these people because they're giving things away for free, and then other people are using them and taking advantage and applying pressure, etc., etc. But we've gotten some money now. I mean, I'm not talking about now this year, but, like, over the last 15, 10, 15 years, money's come in in certain amounts. You know, it's not evenly distributed by any means. And it seems like, I don't know if I can say it's caused more trouble than it's solved problems. Maybe it's been better than, maybe it's a net positive. But, man, it sure made things even more complicated. And I'm not sure how we navigate this. I'm not sure how we navigate this going forward. Maybe the answer is complete transparency, and maybe the answer is, I don't know. I can't even imagine an answer that makes sense. But, Mike, your stance is, like, you can't do it. You can't do full-time open source maintainer as, you know, free to work on the project however they like. Like, whatever we all imagine would be the perfect life of an open source maintainer, like, there is no such thing. Is that your stance? Pretty much. I mean, Justin's, like, you know, hotfix podcast thing was, like, okay, come with, like, a pithy quote that's, like, a controversial statement. And I think the shortest, pithiest version I got was, like, open source is not a career, right? Like, and what I mean from that is that I think there's plenty of ways to be an open source maintainer and make a load of money, right? Like, I've done fairly well for myself financially. I have had some doors open for me that would not have been opened otherwise were it not for my open source work, for sure, right? Like, I mean, arguably, maybe bar my first job out of university, college, whatever. Like, I think every other job, my open source maintenance has influenced me getting that job. But also, every other job has never has my paid main work been working on open source, right? Like, that, and particularly working on homebrew, right? Like, I've had, when I was at GitHub, I was at GitHub for 10 years, I had, like, a couple of months in which I was, you know, given permission to help migrate us urgently from bin tray to GitHub packages, right? And I worked on a bunch of internal code for that. I worked on a bunch of external code for that in homebrew. But, like, bar that, like, that was not my job. I did homebrew stuff in bits of spare time, in evenings and weekends, in time between meetings, whatever it may be, right? And that was not what I was paid for or promoted for or whatever, right? I built stuff internally, right? I guess not unrelatedly, I was, you know, one of the first people to, first four engineers to build, like, GitHub sponsors, right? So I, you know, that was an interesting thing for me because it was being on the front line of, like, well, what happens if we put a bunch more money into open source? And I think, like, GitHub sponsors, again, it was telling because if you looked, and a lot of this is all public knowledge, right? If you look at the people who have made the most money out of GitHub sponsors, they are not the best open source maintainers. And they would not be offended in me stating that they are not the best open source maintainers. They are the people who have done the best job selling themselves and selling something which other people value through GitHub sponsors as, like, a payment provider, essentially, right? And good on them. That's great that they do that. But there's a lot of people, myself included, who just slap up at GitHub sponsors, right? Like, I do a lot of homebrew stuff, and I have done for 16 years. My monthly GitHub sponsors payment is $22 a month, right? That's not me going and saying, I want to get a bunch more. I get, you know, a bit more than that. I get $300 a month from homebrew as, like, our kind of maintainer stipend. But, you know, the reason why I don't get a load of money that way is because I have not dedicated time and energy into building, essentially, a sales process for my sponsorship pipeline. And that's how it works, right? If you want to be an open source maintainer that gets funded primarily through sponsorships and money and whatever, it doesn't look like a tip jar. It looks like you are now running, essentially, like, you know, in the same way that other influencers might have an influencer economy or whatever. And there's various routes of making that money and paying those bills and getting that open source work, right? But there's not a single easily trended path that is not without compromises. And it makes me very cross to see a bunch of particularly younger maintainers being told, like, no, this is the way. If you follow this, you will both be rich and you can work on whatever source you ever want, whenever you want, right? That's just a lie. That's just bullshit, right? Yeah. Well, hold on, Justin. For those who are putting them through the pain of watching us on video, the fringe benefit of doing the video version of this is for the last 10 minutes, you can watch Justin sit there and chomp at the bit for his opportunity. Because we've said so many things that I'm sure he wants to address. So much so that at one point he was literally holding his mouth shut because he has so many things to say right now. This guy talks for three hours uninterrupted and he hasn't had a chance to say anything for the last 10 minutes. So, Justin, just turning the floor over to you, my friend, which of these many points would you like to address first? Got to admit to anyone watching the video, I did get distracted at one point because my pen ran out of ink and I had to write down. He literally left at one point. He literally left and then came back. So that was distraction number two. Distraction number one was I saw somebody texted me that the Vision Pro with M5 was announced. Oh. Well, there's a fire alarm fire right there. Yeah. Just to tell you, my priority is as one of the five remaining daily driver Vision Pro users who I use the Mac virtual display every day, like we've discussed several times on the show even. So I will not be buying it because because it's just basically I'm using it as a monitor. But and I'd much rather just talk about that now. But to try to honor what Mike just said, when we say open source is not a career, it's kind of running a consultancy. It's helping co-found, help start whatever, like a consulting company speaking at conferences, doing some amount of open source. You know, none of I was very fortunate in life and that none of my open source was super successful. It seems like a huge pain in the ass when it when that happens for the most part in terms of the burden of issues and pull requests and yada yada. But I was visible enough that people would come up to me, younger folks, less experienced people, people trying to succeed in this industry. And they would whether it was about speaking or whether it was about blogging or whether it was about doing open source, a lot of the activities that people saw me do, they'd look at that and they'd confuse the means with the ends. So they'd say, hey, how do I break into open source? And I'm like, that's a real weird goal because like I do open source because I'm trying to get something done that makes me money, like working for a client. And like we got a you know, the first real project I did was like I was a Java client. And like we had a whole lot of JavaScript and no way to run tests against it in CI. And I was like, that won't do. And so like we started unit testing our JavaScript with Jasmine, like locally. Well, how do you get that running in CI? I was like, oh, I had to figure out a you know, this is back in 2010 or whatever, like run a pseudo HTML and JavaScript like fake environment in a Java runtime. And and then make a Maven plug in that we could incorporate into the build like and I did that on my own time on a weekend or, you know, late at night or something. And then I just plugged it into the client code the next day. Right. Now, here you go, a gift free of charge because it makes my life easier at work and we're going to ship your code better. Right. And almost every one of my open source projects was that it was I have a job that pays me money that that job would be massively improved in terms of the outcomes or my life at that job. By writing some open source. So I'm going to solve my problem and I'm going to make it open because that's that's easier than getting approval to make it closed internally. Like if I if I have some like, you know, asinine idea for how I can make things a little bit better. Forgiveness is way better than permission. Maybe it won't work. Like why? Why would I fight for like budget and time to go on some, you know, escapade to like, hey, I can vaguely improve things in a way that you don't understand when I could just go on my own GitHub, publish something. Publicly and then go and consume that at work. And if it turns out that it's useful, then work is happy to like, let me spend some hours building it because then I've got a virtuous, you know, I've got at least one person depending on it. And that's the person paying me. So then I can keep working on it a little bit and make it a little bit better, respond to issues and feedback. And that's typically how I've done open source. Right. I guess one way to do it. And in a very, very small sense that at least has like incentives aligned where it's like, I make this thing better because it's built for purpose for somebody who needs it. So that's not that's not breaking into open source. That's not saying like, OK, so what I want to do is I want to work on this open source project. And I've seen this play out lots of times, whether it's through the sponsorship deal or, you know, what Ruby together and later Ruby central did was they actually paid hourly for people to work on bundler and Ruby gems code bases. And when you're like talking about like a high one hundred fifty dollar an hour or whatever it is, hourly rate to work on an open source tool, then a lot of questions arise. Like, what do you work on? Who chooses the priority of that work? Like it's a you know, if you're talking about one hundred fifty bucks an hour or zero dollars an hour with most of the people contributing, making zero dollars an hour. Like suddenly there's a perverse incentive there to be like, all right, well, either, you know, what if there's nothing else to do? Like what if bundler is a solved problem and basically does everything it needs? Like now you've got a perverse incentive to create make work to justify more hours to get more money. And and if the goal at the end of the ends is I want to get make make a, you know, replacement level tech career doing open source activities. I think like the places that leads you in terms of the amount of complexity and machinations in terms of like how that funding gets to you and the amount of singing and dancing. And and and and and glad handing and arm twisting that you need to do to like, you know, extract those dollars from people who might not necessarily see a direct value or benefit or ROI for giving you that money. It leads to places like this that are as goddamn confusing as the situation that we're in now. And that's that's, you know, I guess maybe a twisted knife version of the picture that Mike's painting is like this is just all about at the end of the day. It's like incentives were not aligned because people wanted to get paid. And this is where this leads you. And yes, it's really sad that a lot of people do open source for free, but like a lot of people have hobbies for free. And if they choose to keep doing them, it's kind of their their task. I don't know what to tell you. And that's the thing. Like for me, genuinely, open source for free as a hobby is a beautiful thing. Like we should think very carefully before we decide to kill that by either paying everyone, which won't happen, or by making people who aren't being paid feel like they are being exploited. Right. Like I again, it really fucks me off. No end. When you have people often with minimal involvement in open source themselves going around telling open source maintainers big companies are exploiting your labor. And I said, well, if only there was a way to get a big company to pay me to write software for them. Oh, wait, we have lots of that. But the reason why lots of people, including me, enjoy open source software and have continued to work on it for a very long time is it's like I don't have a engineering manager or product manager or technical project manager being like, please sign your TPS reports. When will this be done? Is this a yellow T-shirt or a green T-shirt size project? Like being able to just opt out from all of that bureaucracy is, you know, that bureaucracy is important and necessary sometimes, but it's also nice to not have to do that. And when you don't have to do that, you can operate in a different way and work in a different way. And that's fine. And again, we go back to the open source maintainers owe you nothing, where it's like if someone doesn't like it. Like, I mean, there's legitimately issues on homebrew that people file and it's like, this is a legit issue, but you're being a dickhead about it. So I'm just going to close your issue. And when they're like, oh, but then I'm like, well, fuck you. Tough, tough luck. I can do what I want. Right. But if I'm a paid employee and if that person is a paid customer, right, in some companies you can do that. Right. But that's not terribly advisable. And I think this goes back to what we were saying about perverse incentives and like who gets paid and who doesn't get paid. It's like, well, open source maintainers owe you nothing. Sure. People who are being paid to do something owe someone something. Right. And it might. And again, in homebrew's case, we specifically do. We have like all open tooling and open documentation and blah, blah, blah. And we pay maintainers that hit a certain threshold, $300 a month. We call it a stipend. There are people for whom I'm sure the average, you know, American child delivering newspapers, if that's still a thing that happens. Like is making significantly better hourly wage than some of these open source maintainers are. But it's fine because that's just a token amount for appreciation for them. And we're not like, but even then we have had, it's not, we've not done anything publicly or whatever because we try and in homebrew do a reasonable job at keeping some of our drama behind closed doors. But even in that case, for a very small amount of money, we had a person with a very well-paid day job who was doing the wrong thing essentially because they wanted to hit a threshold to get an extra $300 a month. And that made us reconsider how we do this stuff. But to go way back to something that Justin said right at the beginning, right? Like about, you know, he did open source to solve his own problems, right? Back when I got involved first with open source in the heady days of the Linux desktop back in like 2007 when I did my first Google Summer of Code and met a lot of these KDE people and I was like a Linux guy. Like the thing that people used to say all the time then that I never hear anyone saying now is open source is about scratching your own itch, right? And what people meant by that back then was like open source is primarily about solving your own problems and then releasing it in a way that other people can benefit from you doing that, right? And that's why I did it. And it's why I do it. Because when I work on homebrew and I make homebrew a little bit better, it's usually because something in homebrew annoys me and I use homebrew, therefore I make it better. And that's completely the opposite from the attitude Justin was saying of like, how do I break it into open source? It's like, well, whenever anyone's asked me that, I'm like, well, find a tool that you use, find something annoying with that tool and then go fix it, right? And they're like, oh, but, you know, I don't know JavaScript yet or I don't know this or I haven't contributed to that code base or I can't find a mentor or whatever. And like, again, as we're being a bit more spicy on this podcast, it's like, well, congratulations, you lose. You're never going to be a successful open source maintainer, right? Like, I've never seen someone who's been a good open source maintainer who has been taught into being so, right? Or encouraged or given enough money that they kind of finally get over a line or whatever, right? That helps people contribute and it's great. And we shouldn't discount that as being a thing that we do for some people sometimes. But like most of the time, most of those people, it's intrinsic internal motivation that gets them to do this stuff, right? And that doesn't come from, I want money, I want clout, I want my resume or CV to look better. It has to come from like, I just want to do it because it's interesting and fun for me, right? Yeah. I think this goes beyond open source software because the pattern is very generic. It's like, I love doing X, so I do it for fun. I would love to do X more. If I could only make money doing X, I could do it more and then X becomes not fun anymore if that's successful. Like, basically, that's the pattern. So it's not just software but creation of all kinds. Anytime you can parlay your hobby or your passion into a job, your passion is now your job. And your job's a job and jobs aren't fun. Even if it's the exact same activity. Yeah, and you can add to that, Jared, because then you can take all your friends you have good relationships with. And I tried this one. And then you hire your friends. And then your friends aren't your friends either. That's right. And you live in a basement in Ohio and you're like, oh my God, what have I done with my life? I've destroyed my hobby and my friends. But I got money in exchange, you know, or just train it all in for money. Yeah, that's the unsolvable problem, I think, right there. And, you know, for years and years, we've been looking for more paths to funding, more ways because there's so many different kinds of open source. And there's ones that have an easy time making money because they are right there staring you in the face like they're like end user applications. And then there's the dependency, the dependency, the dependency, who only has a GitHub account and is not on any social networks and is never going to make a dollar on their GitHub sponsors because nobody even knows that they're transitively installing, you know, XZ, for instance, just naming one that was exploited. And so maybe I just thought there was different models. We need to just explore all these different models. And I remember going back years to Nadia Ekbal's Lemonade Stand repo, which she published back when she was doing her open source funding, writing. And she documented like, here's all the different ways, bounty programs, open core, blah, blah, blah, blah. And it's like, pick one that helps you. And we've explored on this show over the course of, you know, a decade now, different people doing these different models and with more or less success. At the end of the day, the happiest people that we've ever talked about, talked to about their work are the ones that are like, yeah, I do this for fun. I'm not going to monetize. And it's like, that's, that ends up being the healthiest relationship to your open source code is I do this for fun. I'm not trying to monetize it because every one of these models, we can go through them all and they all produce at some point the perverse incentives that have happened in the Ruby community. To me, it's not even monetization versus not, it's like direct monetization versus indirect monetization, right? And I can't remember who it was. I'm sure it's some much wise and old philosopher or whatever who said this. I'm going to paraphrase it and butcher it horribly. But basically, like the idea of like the best things in life are achieved indirectly, right? So like, let's not be overly crude. I'll try and be relatively diplomatic. But basically, you know, for example, if your goal is romantic companionship, right? There's ways of getting elements of that very quickly in exchange for money, right? But most people would say that actually, that's probably not the most fulfilling long term option. And the most fulfilling long term option, you know, I've been with my now wife for 23 years, like we have a perfect marriage and relationship. I'm very, very happy. That takes a lot of time and effort, right? And again, I have almost like a pending blog post brewing about just being patient feels like it pays a lot of dividends on this stuff. Like, I was at GitHub for 10 years. I've been with my wife for 23. My best friend who comes around to my house, we're currently watching Alien Earth. It's very good. Right now you're watching it? Well, I mean, not right now because I'm on a podcast. Okay, well, you said your best friend coming over and you're currently watching Alien Earth. I'm like, dang, this guy can multitask. I'll do my best to multitask. But yeah, I mean, we've been friends for like 30 years, right? And most of, and homebrew for 16 years. Like most of the good things in my life are things that I have done for more than 10 years, right? And there has been ups and downs in those times. And there's been times where if you were to look at some tiny microcosm of like the first, you know, months or weeks or whatever, or a particular segment, you'd be like, oh, well, this isn't worth it. I'm going to quit. But again, like all of these things are things that I've got and I have made me very, very happy and I'm delighted with, not because I wanted to make as much money as possible or have as much whatever as possible, human relationship, interaction, whatever. But just because like I enjoy the process going along and I still enjoy the process going along and that tends to get you to a very good place. If every day you enjoy your life and you keep doing that and keep enjoying your life and at the same time, you know, stuff like money, you're like, okay, well, I need to pay the bills. I need to make sure that I make enough money to provide for me and my family and whatever. But you're also really excited about what you're doing, then that tends to work pretty well. And if you go and chase like maximum financial return for anything, right, on a short-term basis, like, okay, you might make a bunch of money, like often you don't, but you're probably going to be miserable in the longer term. And you're going to be like, why am I doing this? And I need to quit and whatever, right? And that's the definition of sustainability, right? Like when we're not talking about open source sustainability, when we talk about anything being sustainable, the idea is how do we get people to be able to do this for a long period of time? And without being a, you know, a cheese ball, like open source sustainability comes from within, right? The reason why I have been able to do it for a long time and not burn out and literally in that 16-year window, I don't think I've gone a month without working on homebrew. I've maybe not even gone three weeks without working on homebrew. And the reason why is because I enjoyed it then and I enjoy it now. And I know what I'm willing to do and what I'm not willing to do. And for me, it has to stay enjoyable or I'm going to quit. And I built a group of maintainers where I'm very protective over them because I know that's the same for them, right? And to me, just almost looking at yourself in the mirror and be like, am I enjoying this? Is this good? Like, and if it is, great, do more of that. And if it's not, then just stop, right? And that terrifies a lot of people because it's like, oh, well, open source will collapse if we have all these maintainers who walk away. And it's like, well, actually, no, because someone will step up and do what needs to be done if what you're doing is really important. And that's maybe the hardest part of it all. It's like, maybe that open source project you've spent a huge amount of time and energy into, maybe it's not that important. Maybe it is replaceable. And maybe your role is replaceable. And that fucking sucks to look in the mirror and think that. But maybe that's true. Maybe you need to do that. Look, if you're watching this video, you're going to be probably noticing that, like, we're three white men, you know, the collective noun for white middle-aged men is podcast. I get it. But it's true. And one thing that a piece of context, right, about like that 2015 to 2021 era, especially in the US and politically, is like this conversation about like, you know, just being tut tutted by older guys who were already successful in their careers. Like, oh, just do it as a hobby. Just do open source in your free time or something. When that comes into contact with this motivation that, like, open source isn't ends, not a means. It's a way to get, because highly visible people are doing it, people rightly assume, you know, for whatever reason you're doing it, if I were to do that at the same stage or at the same level of impact or in the same high profile project, then I too would be highly visible. And therefore, I could parlay that into, you know, more marketability, right, as an employee. I'd be hired in at the staff level or the principal level, or I'd have better employment prospects. And so there's a, you know, even though I started doing open source to scratch my own itch, to Mike's point, and that's still the reason I'm ever motivated to do it, it created a virtuous cycle, not just for my employer to be able to benefit from my hobby work, but for me to be able to parlay those projects into new relationships and credibility. Because your, you know, GitHub profile kind of redounds to like at least some kind of proof that this guy can write working software and this is what it solves, right? And mixed in with all of that is like, well, what if you don't have the free time, or if you've got family responsibilities, or there's some other, you know, systemic reason why you aren't able to just work for free and make this time possible. It's creating an avenue for more privileged people who do have that luxury of time to pursue that hobby. And then, and then even though it's just a hobby, it's not like, I definitely made more, more money out of my like, programming habit, then out of my Japanese language acquisition habit, you know, like, in terms of a hobby. So, so, so like, that's not, that's not lost on me here. It's just kind of a fact of life, and I don't know how to solve it. Because when you try to solve this through the lens of, and that's why we got, like, when the conclusion, and I heard this a lot in the late 2010s was, and that's why we have to pay people to write open source. I was like, that's, there's just so many, like, you know, the number of circles and loops necessary to kind of connect these dots together in a way that's actually going to get the outcome that you want, is so convoluted, that this is probably just going to make things worse. I can't say we're in a much better place, you know, in all of these experiments where people are, and to, to, to, again, to Mike's point, where people are being directly compensated for their open source efforts, especially in an ad hoc or, or a, you know, semi-directed pseudo employment manner, like through, you know, contracting and through kind of, you know, like an amalgamation of funds and sponsors and donors. Like, it, I don't know what to do, I just want, I just want to put it out there so we don't get emails about privilege, I'll be honest, that's why I said those things. I think, I think it's a good point, and I think it's well made, and I'm glad you made that. I think for me, my take is, like, should we try and improve the diversity of open source, et cetera? Like, yeah, we should, I do, like, hopefully all of us would agree with that to some degree. But I also think not everyone having the free time, again, it's one of those things where if, sometimes I think the people pushing a certain narrative haven't done the five whys on, like, the reason why they're often doing that is because they themselves come from a position of, like, you need to do open source to have a really great career, right? And I'm like, well, no, I've worked with plenty of, like, staff plus engineers at GitHub who are phenomenal engineers who've literally never done a single open source commit ever, right? And I would not tell those people that they should or shouldn't, right? Like, considering the number of open source related emails I've had that have fascinating things to say about the size or presence of my penis, and whatever may relate to that, and various interactions with my mother, et cetera. So, like, I don't encourage anyone who, like, doesn't have a current interest in open source to sign up to receive those types of emails, right? And I don't think we're going to solve that problem anytime soon. But I think that's the thing. It's like, do we see open source as, like, an essential on-ramp that we have to use to, like, get people to be successful in the software industry? And if you start from that, like, prior, then it's like, yeah, of course you're going to start thinking, like, we have to improve diversity and pay people to encourage people in, because otherwise you're just going to, you know, really fuck up the software industry by not, like, solving that. But I don't think that is a problem. And ironically, I think that is a problem that is exacerbated by people saying we have to pay and we need to put more money in rather than it being solved by that, right? Because no one has to write open source, right? Like, that's, I think that's the fundamental thing. If I can say anything to any person who listened to this, it's like, literally, if you have a job where you write open source, even if you're a paid employee or contractor or whatever, like, I'm sure you can find something else where you don't have to do that, right? Like, everyone writing open source, in some degree, has some element of choice. Maybe not short term, maybe this month's mortgage payment relies on you, you know, writing open source and whatever, right? But, like, long term in the career. And also something, Justin, you said, you pointed this out on your podcast a lot about how there was this golden age of, you know, the three of us, again, are probably similar sort of age. There was this golden age of programming, like, the early 2000s, where, you know, if you came out and you're interested in open source, like, chances are that was going to help you into a reasonable tech job and you could probably make a decent amount of money. And then now we're seeing, you know, like, things are completely horrific for a lot of juniors trying to get into the industry. And I think that's the thing. It's like, I don't like that. I don't think anyone in this call likes that. But you can't, we can't just magically go backwards and undo that and fix that. And I think often the people I hear advocating this type of stuff around open source just have wishful thinking of, like, no, if we can go back, we'll do it right this time and we'll, like, reinvent it and whatever. And so, well, that's not how it's been. And I loved your point, Jared, about how this is just universal for hobbies, right? Like, we could probably have had exactly the same conversation we had right now about, like, music or whatever, right? Like, and money and whatever. Like, I remember when I was at GitHub and there was, I can't remember the name of the band. There was some, like, top 10 indie rock band and one, like, GitHub conference, like, GitHub had paid for this band to come play. And the band came out on stage. Was that when Cold War Kids played at a... That's, yeah, that's the name of the band. But, like, having been there in the room, and I think there was a Silicon Valley episode that was loosely based on this, like, they came out and started playing. Hold on, I got to interrupt you. Like, if you don't know this, like, most Silicon Valley episodes were based on interviews with Chris Wonstreth and people. I re-watched it all recently with my wife, and it's aged well. But anyway, so, like, they came on stage, they started playing, and, like, 75% of the people immediately left the room because they were like, I don't want to be here, right? And I'm going to confess something to the, you know, the two of you here. Hopefully no one else hears this. But, you know, like, I used to be an aspiring musician. I have anyone on video who can see my mostly now unplayed guitars behind me, right? And I immediately thought to myself, what a bunch of fucking sellouts, right? Like, I would hope to myself that I would never be at a level where I would take any amount of money to go play to a room of nerds, myself included, like, who don't want you to be here and would just immediately leave the room as soon as you start playing, right? Like, and, and again, like, you could say, we can have the same conversation, money and music, right? Like, was that bad that they had that money or took that money or whatever, right? Like, I'm not a musician. I'm sure lots of musicians are very angry at me for, based on what I've said, and I'm being a massive hypocrite. But, like, yeah, it's, I'm sure there's another podcast having an identical conversation about this. And I think, like, we're not special in software open source. And this is not the first industry to have this problem, nor will it be the last. No, I think that's a great point. And I think that I've said this before, that people, by and large, people don't make music in order to make money. They make money so that they can make music, right? And I think that there are people who've done both, and they're called rich and famous rock stars or whatever. And, of course, people idolize those because wouldn't it be the dream to be able to be rich and famous and make music? Like, that's, yeah, that's a lot of people's dream, which is why it's really hard to do. And we draw that across to open source. And we have had some people who've made livings, who've made really good livings, publishing open source code and creating a following and becoming whatever you have to be in order to get that done. You can go to the top of GitHub sponsors and see a few of those people there. It's an entirely different skill set, just like being a rich and famous rock star requires more than being able to play the guitar. Because lots of people can play the guitar, but there's more to it than just that. One of those major factors, in fact, is timing and luck. And it has nothing to do with who you are, your skill set. Another major factor is what you look like, unfortunately, but that's the case. And so open source as career might follow the exact same trajectory as music as career. It's like, yeah, a few lucky, very privileged people find a way to make that work and they live a great life. And the rest of us, it's like you got to decide if you want to do it or not. At the end of the day, open source is a gift to the world. It's you giving back. A lot of the motivations for doing it is people saying, well, I got so much for free that I felt like I should just give back. And so that's what I do. And so that's a gift. And a gift comes from a place of privilege. You have excess. And so you give it. And one of the beautiful things about the digital economy is that we can give it to everybody, whereas if I was going to go out and buy a new Vision Pro M5, I could just give it to Justin. I couldn't give it to the entire world. It's an amazing thing to be able to do your work once and gift it to the entire world. And sometimes it just has to stay that. You got my address, right, for that? I figure you already have it on order, so I'm probably just. No, no, no, not yet. You need the phone. You got to scan your face. I buy you the new one. So you send me your original, maybe sign in. I got Justin Searle's original Vision Pro. There's a thing here, right? Because we're kind of conflating programming and making a living programming and open source as like a hobby activity or whatever. And just like music, there's a difference between like being able to play music as a skill. Being able to program a computer is a skill. And being a songwriter who puts love and craft and passion and creativity and something of themselves into the music that they create is a passion, a craft. You know, it's an individual pursuit. And yes, if you do that, you are lucky to get paid. And if it does all work out and the stars align, then that's a goddamn miracle and good for you. Like, but at the same time, getting paid as a musician with that skill to go play gigs. Like, there's a guy who, you know, sings at the lobby bar at a hotel next to my house every Tuesday. And he's mostly playing, you know, Wonderwall and, you know, the old country road. And like, he's not there for his health, but like there's a transaction happening and I don't begrudge him at all. It's like, that's, you know, there's ambience and there's music. And so like, hell, you know, the Cold War kids made me laugh, Mike, because across the street, there's a new hotel that opened. I live in Orlando and it's just all resorts and stuff and pools and whatnot. The new hotel opened earlier this year or late last year and they had the Goo Goo Dolls play. And I was like, hell yeah, I'm going to go over for a free Goo Goo Dolls concert and free food and drinks. And yeah, right. I don't begrudge them at all because that was like, that was them applying their skill for, for, for money in that, in, in that sense. You know, um, I mean, the songs were written all 20 years ago and everyone's really old and they look suspiciously good. And that made me wonder about how they're maintaining that. But like when I, when I, when a programmer is applying that skill to make money at the, at the end of the day, somebody, whoever's paying that money is going to be looking for some kind of value out of it. And if you, and if, and if you're, whether you're, you're, you're working, uh, for somebody and they're, you know, why do we have planning sessions? Why do we have product owners? Why do we have requirements handed to us? It's because the things that we're typically being asked to build as programmers are at the behest of somebody else who, who wants to see that software built or, or continue to operate or to be refined or whatever in order for them to extract some kind of value out of it. And just like with the singer songwriter who can like eventually get to the point where they get to open new hotels and, and, and get paid to sing their own songs. Like every now and then you get really, really lucky. Like you, you, I worked on Ruby and, and rails for years and years and years. And now there's a Ruby and rails team at a company like Shopify and they hired me and I get to continue doing the stuff. You know, I talked to, with Aaron Patterson's a good friend with me, uh, of mine and, and, uh, yes, that's part of my bias and my allegiances is I talked to like that crowd of people more than the maintainer side of people who are involved in this particular dispute and fully own that. But like, Oh, I'll talk to him about his job and it's confusing. Sometimes I'm like, well, he has work stresses here and there and stuff, but like at the end of the day, he, he, he makes good money doing, doing that for Shopify. Shopify gets a lot of benefit out of that. Um, but like if he were to quit, he would basically be doing the same fucking thing every day for free, you know? Like, so that is the stars completely aligning. And you know what? Like I know half a dozen people for whom that is true out of how many thousands of people that I've interacted with. And so it's just an unrealistic thing. And now this is back to Mike and this, our original kind of hot fix premise. It's an unrealistic thing to just plan on your career being that it's way too high of a bar. It's way too skinny of a bottleneck to hope that you're going to like with any level of confidence squeeze through. Cause so few people do and not for lack of trying. Well, it's like all the youth right now, they all want to be YouTubers or, or TikTokers. And it's like, that's the, it's the new version of, I want to be a rock star. It's like, you know how many rock stars there are? There's like seven of them, you know? But the influence of your economy, I think that's, it's similar. And I think, again, it's been democratized to a certain degree. Yeah. And we're, I guess, as again, like, you know, three white men in our forties, like we're probably like, if we had like some Gen Z guest on, yes, it's Gen Z because I'm British. And then if we, I'm sure they would have a very different perspective here. But again, I sort of wonder whether some of this comes from like the, the concept of like the side hustle, right? Where like the side hustle is often the, like, I have a hobby and I am going to, on top of my job, I am going to monetize my hobby. And hopefully I can get to a point, like you said earlier, Jared, like where my hobby can become my job because I fully monetize it and I can pay the bills and whatever. And I think, again, music is an obvious example, right? Where there are people for whom music is their career, right? And they, I know some of them for whom they then go home and they are not interested in playing or producing music in their spare time at all anymore. Like it's, I would just do it for money. There's people for whom they are not interested in ever making any money from their career ever, right? In which if we wanted to have a horrific open source metaphor, you know, some like, I was going to say man or woman, it's probably like a dude with long hair playing their guitar around a fire while their friends, some of them might want to listen, probably most of them You know, someone could go up to them and be, you're being exploited for your labor. Like you should be paid the same as Taylor Swift for this, right? Like, and it's like, well, actually no one wants to pay that person because they're not very good and they don't want that job, right? That person is doing it entirely as a hobby. And then there's the people where there's like a blend between the two. Maybe it's their hobby and it's their job, right? And I think that's the thing. It's like career, hobby, both, right? And all of those are acceptable options, but it feels like this stuff often gets conflated. And even someone like Aaron Patterson, right? Good example, right? He's written a absolute boatload of open source code in the years. It would be interesting if you went back and somehow did accounting of like, okay, well, what's that? That's almost take the amount of money you've been paid to write open source. And then the amount of hours you have spent doing open source and hobby related things, say any work on a public repo on GitHub in your entire history as a programmer. And that's figure out like what your hourly rate is. And my guess would be like, it's obviously getting better each year that he is employed by Shopify. But my guess would be, it's actually a lot worse than you think it is because he, again, like musicians, right? Like musicians are not getting paid to play their scales, right? People are just sitting, when I used to actually be a half decent musician, a lot of it was just sitting and spending two hours playing the same riff again and again and again and again, slightly faster, slightly faster, slightly faster, slightly faster. And like, you know, no one's going to pay you to do that really boring stuff, right? And it's, I don't think open source is dissimilar. And like what I worry about is, again, I'm from an era of which it wasn't clear that open source was going to win, right? When I was at university, there was still all the kind of like Linux and like, I can't remember the name of the company that basically there was this big lawsuit and, you know, Steve Ballmer, Linux is a cancer, all this type of stuff, right? And it looked, it was like a battle between proprietary software and open source software. And some reason, the only reason we're even having this conversation is because open source software so clearly and unambiguously won. And I, maybe I'm being paranoid here, but I worry for a world in which we say, okay, any big company that uses any open source software in any capacity is extractive. And unless you are paying all those maintainers a Bay Area, like living wage, then you're an evil company, right? Like what happens if we actually go all in that viewpoint? Like, do we make those companies be like, well, you know what? I'm actually not going to touch open source anymore. I'm just going to pay a team internally to build this stuff, right? And for a lot of people like me, like that would be a very sad thing, right? And it would, that would be the end in some ways of a lot of the non-hobbyists like open source, right? And I just think, where does the money come from to pay every single open source maintainer with 10 stars on GitHub, like a living Bay Area salary, right? Particularly if, as Justin said, we say to them, hey, we just give you that money unconditionally. You don't need to have a product manager or whatever. You just build whatever you think is best, however you think is best, right? Like that's, I mean, it seems ridiculous to me. Maybe that's just me, but like, I think that's the logical conclusion we get of the like peak we should pay everyone because otherwise it's unethical argument here, right? Yeah. To that point, we just did a show recently with Feras, a book of DJ about NPM security in light of the, just the onslaught of NPM hacks, which have been going on and continue. I think after he published that there's even some newer ones and one of the things, and he runs, you know, he owns and operates a secure socket security company. And so he's very much in the infosec world and talking with, you know, CTOs and CEOs of larger corporations. And they're saying things like, well, this is not because of open source sustainability, but it's because of open source security and this, you can't trust a network thing. They're starting to have those conversations, especially because of the, you know, first time to say it on the episode, I'm glad we're over an hour in because of the new enthusiasm around AI code gen tools, they're saying things like, you know, do we need NPM? Should we have, should we use, this is not, should we contribute? This is, should we even use Ruby gems? Why don't we just write everything in house? And like that is starting to percolate amongst leadership in, you know, Silicon Valley companies. And you add to that an open source tax, so to speak of whatever, whatever it would be, Mike, when you talk about every maintainer has to get this much money, therefore every user has to pay in according to their dependencies or whatever, however you'd actually work out the impossible logistics of all that, it would just be one more reason why people will start to opt out of the economy altogether and say, yeah, because I, I look at a world, I don't know if we're going to get there guys, where my code gen tools can reproduce for me instead of a vendoring a gem, why don't you just reproduce a gem? And now I don't think we're going to be there myself anytime real soon, especially with gems such as a large, you know, rails for instance, which is not a gem, it's a meta gem of many gems, but the smaller ones, it's like, why would I even have, why would I care about open I can just generate everything. And I'm, it's, uh, we, we, it's Jared, it's funny. You mentioned this because it's not just your fever dream, but it's like increasingly a thing that I am also hearing. In fact, I, I'm living it, but I, I, my brother, uh, Jeremy, he works for cars.com. He's Elixir and Elixir programmer. And you, he gave a talk at Elixir Conf last month, uh, which the, I don't know if it was the title, but like, basically like the, the, the thrust is zero dependency software, like instead of pulling in these dependencies, and it's not from a security perspective, although that's when you're talking about open source tax, most people aren't thinking about how this stuff gets funded. They're thinking in terms of the, the, yes, maybe the security concerns that like, I don't trust the software necessarily, especially if you're in a regulated industry and you got to go and you have, or have lawyers go and check licenses and verify all that stuff there. There's that tax for sure. Right. But more so like I now, you know, I am running code that I don't control or understand, and it's going to have its own update schedule. And I have to keep all of these dependencies up to date. And of course, of course, the NPM community is famous for like really, really tiny modules. And that's lots and lots of things that you have to keep up to date. Uh, and so that upgrade burden is really high. And right now you, you, you take cloud code, you take codec CLI, you pointed at a readme and you say, all right, go clone this repo. And I just want this section from the readme. I just need this kind of a couple of features right here. Just go clean room, implement that for me, if you don't mind. And like, it'll do it. And you can just vendor that in to your point. You vendor that into your project. And so like, I'm working on this posse party rails app. And, and since going with agents, I'm trying to think now I started working with agents in April, you know, started with, you know, the GitHub copilot stuff, moved on to cursor, moved on to cloud code. Now I'm in the heart of drugs and, uh, the, the, the, I think that I may have added zero new gems, like zero new dependencies. You're doing like OAuth stuff. You're, you're talking to APIs. I mean, this is like. It's almost all integration work. That would be, you know, this would be for me to, as a starting point, it'd be all gems. I'd be like, I get the, the blue sky gem. I get the Instagram gem, right? I OAuth gem. And then I just like tie those things together. Cause it's just posting, you know, across different social networks. I won't say just to belittle it, but my point is like, I would expect that to be mostly third-party code. And 10 years ago, that's how I would have done it too. But I, you know, it's not just because of AI enabling this. It's like, I learned the hard way that if you're writing code, that's basically glue code of like eight other different things. Like, it's kind of like you're on one train and trying to jump onto another moving train, you know, like in real time is to try to keep everything in line and you're just holding the stuff together. And so, no, I've got, I've, I've written, in fact, this week I'm rewriting my LinkedIn integration that, you know, it's not just a whole bunch of HTTP requests to post stuff. You got to like, wait for it to download. So you need another whole series of, you know, self-enqueuing tasks to go check to see if the download's done. And then my wife, Becky is like, well, if it doesn't support stories, I'm not going to use it. So I'm adding story support, which I think has like supported by, as far as I know, no, definitely no Ruby gems, but I don't know if any dependencies are doing this much. And so, so the nice thing is that, you know, when you own the code, you can build on top And when it's inside the code base and it's part of the context of whatever your agents And like, there's a lot to be said for as the cost of code, and this is how we tie back to this conversation as the cost of code, basically craters to zero asymptotically here. Like the, the, the writing of the code is not the part that is necessarily making is worth So if I'm a maintainer and I want to get paid to write open source code, like that, the market dynamics for that are also flatlining, uh, right now. And so this could have, what we could be experiencing this conflict being a flashpoint and you know, where did, where did it all start? According to Ruby central, it started with them cutting budgets, right? And why were they cutting budgets? Because sponsorships declining, why is sponsors declining apart from the macro stuff and apart from the conference stuff that, that Ruby central also runs. I think a part of it is like a general sense that, uh, we've, we've already hit peak open source, right? Like in the sense of the, like people's unpaid labor is the way that we're going to get all of this stuff built, not in the sense that things are going to be necessarily open or built on open protocols and platforms. If anything, that's probably going in the opposite direction, but the, the value of an individual programmer going and hacking out a particular issue or a PR is going to go down. If like, now you can just at codex something or at Claude something. And, and Mike, you've been working with this too, like using copilot agent and finding it, you tell me how you found it. So, I mean, it's funny cause a lot, there's a lot of copilot related stuff. I was one of the first people to test an internal beta of that alpha technically. Um, and the reason why lots of people inside GitHub would like me to test things is because I seem to be allergic to telling people that things were good when I thought they were a heap of shit, even when it was strategically and politically advisable for me to say like this person's pet project is wonderful. Um, so yeah, my feedback on copilot pretty early on was like, wow, this is surprisingly not a piece of shit. Like when you describe, I mean, you have to remember like when copilot came out before chat GPT and stuff, right. Or at least it was, it was being alpha'd before that. So this sounded like ridiculous, right. That we would like use AI, whatever. And I was like, wow, this is a better auto completion for Ruby than I've ever seen using any, any ID or indexing or whatever. Right. And it immediately made me more productive. So fast forward to the kind of copilot coding agent stuff. Again, I saw the kind of memes on how I can use of like Microsoft employees being encouraged or forced to use this publicly and it just being an absolute disaster. And I was like, well, I'm going to try this out. And again, like maybe because Umbrue has borderline fascistic issue templates that demand everything of you and essentially like force you into Mike McQuaid's opinionated way of how you file a bug, right. But if you follow that template properly, it's actually really great context for an LM, particularly when it has all the comments of us discussing it, right. And I, I basically just, I think a couple of months ago, I signed every bug in the home brew package manager to copilot agents. And then, you know, it took a couple of weeks. Some of them got there 99% their first time. Some of them got 50% of the way and I finished off a lot of this stuff. But like essentially in two weeks, those were all fixed. Right. And you can go and look at the public record and see how well that went or didn't go or But like anyone who says like this stuff is not productivity boost is like in any circumstance is massively kidding themselves. And the awkward reality of it, again, back to the conversation is, I would say, is copilot agent great? Does it avoid handholding? No, definitely not. Is it better than the standards drive by a homebrew contributor? Jury's out, right. It's certainly comparable. And I definitely think at this point, like the first iteration of PR, I would struggle to tell them there's an issue between copilot and a first time contributor. A homebrew maintainer and indeed myself who's worked on homebrew longer than anyone else will do a much better job. But even then, like I find myself leaning on it because sometimes it's like there's 10 Copilot, go fucking pick one. Right. And whatever mess you make, I will clean that off and get out of the line. But it's that like empty page problem. And yeah, I think this, I'm probably not quite as, not like pro AI, but like I don't maybe buy stuff quite as heavily as Justin says about like the cost going to zero. But I definitely think it's impacting stuff pretty heavily. And I think we're in some ways seeing like a reversion in the tech industry of like back to what skills are valuable, who's valuable, whatever. Right. And back perhaps to being like, maybe tech is just a slightly less fun place to work. Right. Like going way back for me, like back in 2009, I got a job on like the third application or whatever to a company called KDAB, who I knew about them because they employed more than anyone else of KDE maintainers in the KDE ecosystem. And I was like a big Linux on the desktop guy and being contributing to KDE. I was like, woohoo, I'm going to go work for this company and I can get paid to write open source. I discovered pretty quickly on my first like 100% open source project that it's like, ah, actually getting paid to work on open source as a consultancy looks like very tedious, boring work. And I can probably say specifically now, considering it's been that long ago. So KOffice, which was like KDE's like open office alternative, essentially like a corporate sponsor was like, we want KOffice to be good. Here's a spreadsheet with 5,000 regressions compared to Microsoft Word in KOffice. Go for these particular import documents, go through and just fix these line by line, one Incredibly tedious work. No volunteer wanted to spend their spare time doing it. So a company paid people to do it. And again, this kind of comes back to a lot of the stuff in the early conversation, all the fun, enjoyable parts of open source. I don't think you're ever going to struggle to find people to do those, at least not until you tell them all they're being horribly exploited by capitalism by doing so. But like, there's going to always be a bunch of really boring, shitty, tedious work in open Maybe it's supply chain security stuff. Maybe it's whatever. That's the stuff we need to get the money towards and fund the stuff that people don't And I think that's going to be there. And again, it's one of those things where the jury's out with all the supply chain security stuff, whether the costs of that balloon beyond what people are willing to pay. Right. Like if we have a team internally or we have LLMs that mean that we don't have to pay this tax, then maybe that's what we do now. One thing I'll add, I, I've seen some people on the internet be critical of like in way back to Ruby central, that organization we're talking about at the beginning of this conversation and kind of incited this back and forth that Shan, the new executive director is not technical and not from technical communities, but rather is like more there for her nonprofit experience. You know, I, I remember when, uh, uh, Ruby central was just Ben and Evan and then they added Marty like in 2012 or whatever. And it was just the three of them as, as the chair people, I guess. Uh, and all previous, all programmers. And that felt right. And back then in that era that we kind of keep hearkening back to the writing of the code, the building of the tool that like, you know, the brilliant API and the, just the the, the, the blood, sweat and tears to get it over the finish line at a high enough level of quality, whether it's a CLI or whatever it is, a library. And then to publish it, that was like where all the action was. That was the work. That was the thing that required brilliance. And that's what the market was, you know, rewarding so handsomely in terms of great tech If it's the case that it is now no longer, you know, uh, an incredibly rare thing to have capacity for writing replacement level, decent code. That means everything else now is more valuable. And so to Mike's point, if I'm run, if I'm operating a service and, you know, Jared was scared shitless. He said, he said shitless, he bleeped it out. No, I'm kidding. I, I, I want to add more, I want to more bleeps, uh, uh, more bleeps for a minute. I want to be Mike. I was lying earlier. Oh gosh, he's got you down. Uh, he, he does. Uh, but like if I, if I'm running a service and I'm going to be scared, you know, bleepless to have, uh, uh, a root level security event occur at the place that I'm downloading all of my gems, which could then be root kidding my computer for all of, I know for, I don't know what it, what it was 12 days. Like I'm actually really glad that the executive director has a, like the hat on now to finally like shore up the governance, make sure that like their regulatory and their, their finances and their tax situation is all buttoned up. And probably, I think at the end of the day, we'll probably end up being much more transparent than they've been in the past, which was just the result of negligence, I'm sure. And not malevolence up to this point. Uh, like those are actually the skills that are more valuable because you can't just easily replace them. It requires good judgment and diligence and like experience and oversight. Um, so like, you know, part of this is a story of just an organization maturing, but I think part of it is also like a reflection of like the change in what's, what's valuable and important And as you look at open source or your conversation with frost, which I thought was excellent, you know, frost is a real smart guy. Like it's, it's, this is where the new locus of, of, of, of control goes when, when the writing of the code is no longer the most important thing. Yeah. Now I'm out of things to say, so I'll just say a cliche, the times they are a change in, are they not? As a musical cliche for Mike's on Mike's behalf. You like that one, Bob Dylan, right? Yeah. I love it. I don't know that Bob Dylan song. You don't know Bob Dylan? Come on, man. Unless it's like Northern, Northern European power metal. I'm pretty, uh, lacking right now. I don't, I don't, I don't know if they got Dylan in Scotland. They still have newspaper boys and children. I, I, do you have milk men still up there, Mike? Is that we until recently had our milk delivered to our house by. That's amazing. That's so idyllic. That is idyllic. Living a dream over here. Well, you knew so much about American culture. I figure Bob Dylan would be right in your wheelhouse, but you know, that only extends so far, I guess. Yeah. I, I only do the parts of American culture, I guess, to echo this conversation that I'm paid in order to, forced to learn in order to maintain and sustain employment. Right. And that hasn't yet gone as far as Bob Dylan. Well, I'll send you a $10 donation and a Bob Dylan album. You can just get to work on that. I feel like this is my, I, the moment when the American should make some sort of sports metaphor and I, I nod along as if I understand what baseballs, fourth strike, third innings, catch, MLB championship Fridays means. Well, this is a, this is a nerdier podcast, but the joke I was going to make was going to say, no, when do you like alien earth so much because it takes place in a world where America doesn't exist anymore. You can finally relax. It's just five corporations. You just get a continent. Just like how it should be. All right, Justin, this is as much your podcast as it is mine. If it were mine, I would say thanks and end it. But do you have more things you want to talk about? Well, since this is going to show up on my feed as a hot fix, we try to end every single interview with some sort of pithy one liner that, that, that represents what is the fix to the problem statement. And it's the guest who I guess in this case is Mike being double hosted by us. Hey, I'm just trying to, I'm trying to beat the bleep filter. You can't, you got to keep it in. That stays in. Mike, Mike, it's your job now to like help us land the plane and find a title for this thing, at least on my feed. Like what is, so if the problem statement is, you know, open source is not a career. Like, what's the fix? Like how do, what, what do you tell people instead? Like, like, like, like how should they, how should they, what's the takeaway for them in terms of like, where should their attention be? Or, or, or you tell me. Well, I guess in some ways I would divide the statement in two, right? So from the open source side of things, do open source if you want to do open source, If you don't want to do it anymore, don't do it anymore. This is when like, when this podcast gets published and like 99% of open source maintainers quit and we have a world crisis and I'm like, oh well. But like genuinely, like, and we, I very strongly encourage people in Homebrew to be like, hey, the day you're not using Homebrew anymore, thanks for all your work. Stop using it. Move on. There's been people kicked out of Homebrew who are doing a good job, but clearly Homebrew has been very bad for their mental health, so we kicked them out of Homebrew, right? Like ultimately this stuff needs to be fun and it needs to be something that you enjoy. And if you care about sustainability and burnout and open source, you want that stuff to be Like go, you know, if you're an open source maintainer, go get some therapy, right? You probably have some shit you need to deal with, like chances are. And then the career side of things is like, again, same deal, like, right? If you work in tech, chances are you have a career, which is nice, right? It's harder right now than it used to be. I'm lucky enough to have a lot of friends with careers outside of tech. You know, people who are personal trainers who are opening up the gym at like five o'clock in the morning, working like a 60-hour week with a split shift, right? Like that's fucking hard. Those people do not get paid a lot of money. They work really hard and they make a really big difference in people's lives, right? If you're in a situation where you're getting paid good money to sit in your ass in your home office nine to five Monday to Friday, like, you know, again, maybe it's about figuring out a way to be happy with that or your life. And if you don't like that, then quit, go do something else. But like, same deal, right? Find a career that has some happy medium point between paying your bills, getting what you need out of life, and that you can actually enjoy and not hate, right? And do that, right? Just in both camps, do what makes you happy, right? Because that's, at the end of the day, that's probably what is going to give you a better life and also give those around you a better life and even give like other people that work with you at your work where you're open source or whatever. If you're fucking miserable doing what you're doing, like, you're probably not very nice So let's just, it'll be happy kids. That's going to make some people cross, I think. All right. So I started with don't do open source if you don't want to, which is a little bit long for a podcast title. Then I said, do open source for you. And then I just flipped your problem statement and said, open source is a hobby. Yeah, that works. Works for you? Or just unhappy maintainers should quit? If you don't like it, quit. Yeah, pretty much. All right. Love it. Well, on that note, I'll pretend I'm going to hit my button that plays my music now. And then I'll have my call out and I'll say, hey, Jared, thanks a lot for, we're playing at Jared's house right now because we're in his Riverside account. Instead of Mike's Riverside account or my squad cast account. Just really, we're, we're all broken, but we're glad that you're listening. Hello. If you're still listening at this point, especially nobody's paying me. I've got no sponsors. That's why I get to skip the bleeps. That's right. Our sponsors pay us extra to bleep things out, you know. So we're going to make lots of money off this episode. I hope it was sufficiently brand safe for you. That's a new business model. Pay per bleep. Think about it. There's some, there's some words I decided in advance I wasn't going to say. So you should be glad for those. I appreciate it. That's a sign of a good friend, Mike. All right. Well, we'll just hit the button on both sides. I'm not going to end it. I'm going to let Justin's be the end. I'm going to hit the music when he said he's going to hit his music. So the show's over at this point. Well, all right. Okay. I'm going to keep this stuff in. So am I then. All right. Well, gosh, maybe I should just sing. If you're going to ruin your show, I'm going to ruin mine. Yeah, that's mutually assured content.

This is the GitHub Podcast, a show dedicated to the topics, trends, stories, and culture in and around the open source developer community on GitHub. I'm one of your hosts. My name is Abby from the open source programs team, and I'm joined with my lovely co-host, I am Andrea Griffiths, Senior Developer Advocate at GitHub, and I am delighted to be here today because we are talking to the amazing Mike McQuaid. And if you ever use Mac for development, you've probably used his work without knowing it. Mike is the project leader of Homebrew, the package manager that's installed on tens of millions of Macs worldwide. Project he's been maintaining for over 16 years, I think longer than anyone else. So that makes him one of the most experienced open source maintainers in the world, and we're just delighted to have Mike here with us today. We're going to talk about Homebrew, his evolution and growth as a maintainer throughout the years, and also the open source zone upcoming to GitHub Universe. Hey Mike, welcome to the show. Hey, thanks for having me. Can you tell us a bit about like, why did you start contributing to Homebrew? What it is? So Homebrew, my like one-liner to describe what it is, I guess, for the probably fairly savvy group who would be listening to this would be, it's basically like a pack app store for open source software in your terminal. And so we have other non-open source software and stuff in there as well, but that's like what most people use it for most of the time. And also, I guess another way would be saying if you're like a developer and you're on a Mac, chances are you install a bunch of stuff. All the stuff that you don't install with like NPM or RubyGems or PyPy or whatever, you're probably installing with Homebrew. So like your database and all that type of stuff. So you're likely to have used Homebrew. Some people that might be listening to this or watching us now are probably as old as Homebrew or younger than Homebrew, which is kind of wild, right? Yeah. Homebrew is all day known. Homebrew is all day known. Listen, I'm not one of those that is like back in my day, but for real, we don't appreciate Before Homebrew, Mike, what do people have to do? Like what were we subjected to then? So Homebrew was made by a guy called Max Howell originally. So he was working at a startup in London and he was complaining about Mac ports, a package manager, still a very good package manager around to this day. He was complaining in the pub in London, as you do when you're in London. And I think apparently one of his coworkers eventually snapped and said like, well, if you know so much, why don't you just go and make your own package manager? So he went home having had some beer and then wrote up his design for a beer themed package manager, which then became Homebrew. So I guess my involvement was maybe a few months into having created Homebrew. Like a few people were starting to use it mainly in the Ruby community to begin with. And I heard about this from like a friend of friend. I was also a tech startup in London at the time. And I tried to build a thing on top of Mac ports to sort of make it work in a more, what I didn't realize at the time, more Homebrew-y way. And then I came across Homebrew and I was like, oh, this is cool. I'm going to use this, right? And I didn't start using it thinking I was going to contribute code or maintain or anything like that. But I'd done bits and pieces in open source over the years with like KDE and Linux and various other bits and pieces. So when I had a problem, like it was fairly natural for me to go and be like, okay, I'm going to go and submit a change to Homebrew. I was going to say submit a pull request, but actually Homebrew predates pull requests being on GitHub. So the way it started is me and Max would both be on IRC and I would like DM him on IRC with a link to my commit on GitHub in my fork, which he would then, you know, check out locally and pull that in and then push it and whatever, right? And eventually it got to the point that like I contributed a few bits and pieces and he was like, hey, like, why don't you be a maintainer and help me do some of this? So I think I was the third person to join with Max being the first. And yeah, and then I just sort of never got around to not doing that. And I still am doing it to this day. I didn't realize there was a time GitHub didn't have pull requests. So that's news to me. That's amazing. You joined this team. You became a maintainer. At the time, it was only the two of you. How many maintainers are there now? I'm actually, I need to check because it like varies from week to week, month to month. And we just had, we're about to have some new people join and we just had some people leave. So we've got, let's see, 29 people as of today. And yeah, I would say like on a day to day basis, not all of those people are involved, but like on a week to week basis, probably like at least probably half of them are involved in some way. But yeah, but still, it's not a lot of people considering Homebrew has, we don't have exact numbers, but perhaps tens of millions of users. So yeah, it's not bad going for 30 people. Oh, of course. And the OSI did a little blog post about you. You said the ratio from, you have a hundred to one contributor to maintainer ratio, which is really impressive. How do you think you got to that place? You have so many contributors. So not to bore the listeners too much with package management minutiae, but the way most package managers like Homebrew kind of work is you have one maintainer for each package. It may well be a maintainer maintains like multiple packages or whatever, but essentially you tend to have like potentially even thousands of maintainers packaging things. When you go to like stuff like NPM, there's probably literally millions of maintainers maybe at this point. But at Homebrew, the way we did it is like, okay, like the goal of the maintainers is not to do all the work, but essentially to shepherd the work that is coming in from other people. So that's been part of it. Part of it is like the Homebrew's, I guess, DSL, like domain specific language, like the way you define what gets installed and how it gets installed is like very readable and it's written in Ruby and it's pretty easy even if you've never done literally any program for let alone any Ruby before to kind of contribute and fix things and whatever. And then the other thing which I'd like to take at least partial credit for is I'm, I am and Homebrew is very, very, very into like automation and tooling and stuff like that. Right. So you can make your first contribution to Homebrew by running like a single command that will change the version and commit it and make a pull request and open the pull request for you. So like we've just made it really, really, really easy to make a contribution, but not in the way that some projects have done where they make it easy by kind of maybe keeping issues around that remain unfixed, essentially like giving people a scratch pad to play with, but like actually letting people easily contribute valuable work for us. And then the other thing on the automation side is like we, we again, try and have as much human review instead turn into like automated tests. And to, you know, I guess there's chat in enterprise-y, software-y circles about shift But basically what that means from like the Homebrew perspective is like what might have started off as being a human says, Hey, I review your PR, please do X. Then maybe turns into a CI check that says the same thing like automatically for you. So a human doesn't need to be awake, but then we, we integrate with like your editor now. So if you use like VS code, making a Homebrew formula or whatever, then we will provide in line in editor without you having to do anything other than have Homebrew install guidance of like what you should be changing and what you should be doing. And if you have like auto formatting enabled, then you can literally like do the wrong thing, press save and watch it like all jiggle around and automatically do its stuff, which I still find very cool. So all of that stuff, basically, I guess we've just tried to make it very, very easy to contribute and try and eliminate that friction from the process whenever we can. You're reading a ton about being a maintainer about, of course, helping contributors come into the project. Some of your, my favorite writing of yours is about contributor funnels and that myth that maintainers can just tell people what to work on. The technical aspects of automation and making it easy using the tools to get folks to a place where they're contributing and it's meaningful to them is awesome. But also there is a human perspective there. How do you keep people motivated? How do you make volunteers want to do this when you can't really give them deadlines or say like, okay, well, this needs to be done first. Like I, that's always mind-boggling to me for a project this size. And that is depended on by millions of developers every day. I mean, I think the, the short answer is, I guess, soft power instead of hard power. Like, so like nowadays we have like a governance structure and I'm in the project leader and I'm elected and blah, blah, blah. So I have a certain amount of hard power in which I can say to people, I mean, I can't really say you must do this, but I can say we will not do this. Right. We're not going to move forward wherever. But in my mind, every time you do that, you sort of lose something a little bit. Like ideally everything is a conversation negotiation and you convince people that it's the right thing to do or they should work on this or whatever, rather than telling people what they have to do. And I guess one of the nice things about open source is like, you know what? In the workplace, people also prefer to be told like, Hey, I'd like you to do X rather than being like, I command you to do X. Generally people don't like that very much. And I certainly don't. And I think that's the main thing. I guess another big thing we do on Homebrew, which has made me in some ways and some places on the internet, a slightly controversial figure. And if you Google Mike McQuaid's low end swear word that begins with A, then you can find quite a lot of people talk about how I'm not very nice to deal with. But the reason why I'm sometimes not very nice to deal with is because sort of the reverse of that contributor funnel, right? So all of the maintainers of Homebrew use Homebrew, right? And we can exist and happily use Homebrew and find Homebrew to be a useful tool, even if no one else does. But the problem is, is all of these maintainers who are doing this primarily in their spare time, primarily either completely unpaid or essentially with a very small stipend that in no way matches any sort of reasonable hourly wage. Most children delivering newspapers are probably getting a better hourly wage than a homebrew maintainer does for their work. As a result, they need to want to do this stuff, right? And if you deal with really unpleasant people being unpleasant to you, then you don't want So in Homebrew, we have a very, very low level of tolerance for people being unpleasant. And we would rather lose a potential future contributor, maintainer, advocate for Homebrew or whatever, than we would lose a maintainer. Because as I mentioned before, when you have millions of users and 30 maintainers, sorry, we can afford to lose some users. We can't afford to lose maintainers who burn out just because people are being unpleasant to them. So for me, it's, you know, like if you know me in my open source life or personal life or whatever, like my take is I'm going to try and be nice and friendly and I try and let people maybe treat me a little bit worse than they should. But like if you come after my peeps, right, they're my people and I'm going to be defensive of my people and I'm going to look after them. And to me, like that's how you keep people involved, right, is people knowing that you have their back when other people might be being unpleasant to them. And I guess the second piece of that that's a little bit more recent that I feel like in, you know, post-COVID remote culture, et cetera, that I think has been super important is like we try and get together. We generally have a homebrew like AGM that we try and coincide with like Foz them every year just because it's most of our maintainers are in Europe. It's a free conference and it's unticketed and people can just turn up and do as much as they want. And yeah, that like getting to meet people and know people face-to-face is always helpful. I mean, that's a huge part of open source, right? Is that ultimately it's a wider startup product development, et cetera. Whereas like most of the time you're going to have more people who want more stuff than And there's two ways generally of handling that. One is to just tell them upfront, no, and people don't tend to like that, but it saves everyone's time and they move on. Or you make promises, which you just break. And sometimes you break those promises by essentially having an issue that sits open for 10 years and someone's like, yeah, we was definitely going to do this. And then no one ever does. And is it not better to be told? No, actually it turns out we're not going to do this. And sometimes that stirs people into action as well. Because again, an open source, as I'm sure people hate it when I say this, but I had never written any meaningful about Ruby before I'd been involved with Homebrew. I'd never really been a maintainer that reviewed anyone else before I did that in Homebrew. And like, you can just do this stuff and learn it. And if you really, really want it bad enough, you will find a way to like learn it and do it right. You mentioned Fostum and I absolutely love stopping by the Homebrew booth at Fostum. Sometimes you can get a shiny sticker. I think if you ask the right person, we have non-shiny stickers and we have shiny stickers for people who either contributed or people who donate any amount of money. So if you want a shiny one, that's how you get one. Oh, awesome. Oh, that's the secret. But you'll also be at the open source zone at GitHub Universe this year. So GitHub Universe is at the end of October, October 28th and 29th. How was it last year? Last year was great. So it was myself and Patrick, who was one of the Homebrew maintainers, were there last This year, it will be Patrick and Izzy. They're going to have a really good time there, I suspect. I guess one of the nice things about open source stuff in person is like rarely on the internet do people say like, oh, hey, I use your tool every day. I like it. Whereas when people walk past a booth, they say that stuff and that makes you feel good because often you don't get a lot of that. But also just like talking to users of Homebrew and like problems they've had and things they maybe don't know about and things that we can kind of do to improve. And like, again, it's good from my perspective to get kind of a sense with your project that maybe higher level things like so rarely do you get an issue that's just like Homebrew feels slow. Whereas when you talk to lots of people and like that's their main cause of concern, It just feels slow. So then we went away from Universe last year. We had our AGM at FOSDEM and we were like, okay, like one of the main things we want to focus on is Homebrew feels slow. Let's make it not feel slow. And we worked on a bunch of stuff in that direction. And some of it is already landed and some of it's probably going to land like maybe just before Universe actually in ways to make Homebrew both feel and be like much faster. So like that type of feedback is really lovely to kind of get and be able to turn that all the way through to like actual stuff that people are going to be able to use. That's amazing. I love that. So see, folks, when you go to these conferences and you talk to the maintainers, things actually Indeed. You actually take it all in and take it back to the teams. And listen, you still say no when you need to say no because you have to. But I'm looking forward to meeting EC and Patrick. Yeah, so the open source zone is a lovely corner of GitHub Universe where it's all different open source projects get featured. Every year there's a call for applications. So there's a chance for any open source project to get a booth at GitHub Universe, which is My favorite thing about the open source zone was just the conversations that sparked. I remember just standing in the open source zone. Mike, you called me over and you introduced me to this researcher I had to meet. And she's been amazing. And she did a lot of great work with different GitHub people since Universe. So just the connections that happened in that space were great. I love the serendipity of this stuff. And I mean, I think it's something that's kind of wonderful about open source and tech in general, right, is that often so many people are willing to help so many people. And I've had a couple of people reach out to me in the last few weeks and be like, hey, Bumbu did this thing. We're a small open source project. Can you give us some guidance? I would encourage, again, anyone listening to this, you know, if you have questions like that and you want to connect with another human and want them to maybe help you out, then just ask. They're going to say yes, probably a lot more than you think. And also people like me will reply to your email a lot more than you think. And we'll do what we can to help you out. Okay, going into this topic, because I think that for folks that are listening to this and have you in the same pestle I do, Mike, as the goat maintainer, right? And so you've been maintaining this project for so long. Of course, things have changed. Earlier in the call, we're talking about how a lot, there has been a lot of happening, obviously, in a span of 16 years. So I have two questions there. For one, I think, how does your, the way that you maintain this project change? Especially, let's say, back then to now, since you become a father to, like, obviously, priorities change. Everything shifts a bit. How has the way that you approach maintainership evolved? And then for folks who are coming in, the new maintainers, you mentioned there's going to be some new ones coming in, helping people become active maintainers, handing off responsibilities and grow in these projects without losing that institutional knowledge is a challenge. How do you do that? That's definitely front of mind. And that's definitely a thing that has changed over the years is how much I'm concerned about, like, I guess what they might call the bus factor. I guess for anyone who hasn't heard that, it's a slightly grisly definition, which is essentially, like, how many people need to get hit by a bus before the project dies, basically. And, yeah, there's certain parts of homebrew where I wouldn't say the bus factor is one on anything, but there's definitely bits where, you know, you have a maintainer who's on holiday for a few weeks and you realize, like, no one really knows how to fix this without them. And it's, you're like, okay, this probably means we need a bit more documentation or whatever. I don't really like writing very much, particularly documentation, but it's often, like, just really necessary to do. And often I find myself in a situation where it's, like, actually, like, okay, I could write a bunch of code or whatever, but, like, probably the most valuable thing for me to do is to, like, write down a doc, right? So, for example, something that's on my to-do list right now is, like, we are a package manager and we package software. And on the internet, people use software to do a wide variety of things. And we have been historically, like, on a case-by-case basis deciding, okay, like, what might be too much violence or what might be too much stuff with, like, sex or whatever for us to package it or not package it. And again, you get the fun facts of being, like, an international project where you come in not just what the project should be doing, but, like, individual maintainers' views on, like, well, my country thinks sex is no big deal and violence is a big deal, or my country thinks the other way around, or I work in a big corporation and we're going to probably block this and we don't know what homebrews to get blocked. And then people being like, well, if they block for that type of thing, then good. So, like, all of these type of negotiations and generally, like, that is best suited by writing down a document and then we can discuss something written down and then that can be almost like it settled and moved on. I guess related to that, I have become, particularly since becoming a father and spouse and stuff like that. Like, I try to do less arguing with people on the internet, as satisfying as it can sometimes be. It rarely achieves very much and I try to, like, I'm a pretty liberal use of the kind of lock thread feature, not because I'm like, oh my goodness, if anyone else speaks here, the worst thing would happen, but just because it's like, okay, look, sometimes we get to a point where it's like, you're not going to change my mind, I'm not going to change your mind. Let's not go back and forth on this. Let's just move on and you can take this to another place. For me, homebrew still is not something which, at least directly, has ever kind of driven money into my pocket. So it's like, it has to be something I actually enjoy doing and I don't really enjoy dealing with people who are shouting at me or calling me names. So as a result, there's times where, I mean, literally for me, other maintainers have different views. Like, if someone files a legitimate bug and they're just being really mean about it, I'm just going to be like, well, I don't have any desire to fix that. If someone else comes along and says like, me too, I'm affected by this and they can say it in a nice way, then cool. I might help them. People say, oh, it's a marathon, not a sprint. But I kind of genuinely think that about like open source. And I maybe have a blog post brewing at some point about doing things for a long time. I was at GitHub for 10 years. I've been with my now wife for 23 years. My best friend comes around to my house every week. We've been friends for like 30 years. And like, I want to be able to still doing homebrew, still be doing homebrew when for 20 years, maybe even 30 years, who knows, maybe even more if it still even exists at that point. And what's going to keep me doing that is enjoying it and not burning out and all that good stuff. And that also, I feel like helps me provide an example to other maintainers inside or outside homebrew to similarly, like how to survive long-term in what's not always easiest environment. Absolutely. Let's print all of that out and put it in a t-shirt. You know, I haven't stopped and thought about the fact that, yeah, this is obviously a global project and you're dealing with not just the way that you approach building software, but how it's done anywhere else in the world. And you have to take all of that into account of how you manage a project this size. So that necessary community management key. And listen, folks, Mike's been doing it for 16 years. We'll take some notes. You definitely know what you're talking about. You mentioned GitHub and homebrew sort of growing up together and like you were one of GitHub's early employees. I'm really curious to hear your thoughts on how GitHub's relationship with open source projects like homebrew have changed over the years. Yeah. I feel like it's sort of goes up and down, right? Like, like anything does. But I mean, fundamentally for me, I think the open source community is in some way forgotten that like it, and I guess from having been on the on-call rotations on GitHub and stuff, like lots of people use GitHub and lots of resources are given away for free for open source. And I feel like in some ways I can be more defensive of GitHub in that way than I was. Maybe when I was an employee, when people were like, oh, you're just paid to say that. And now I'm not paid to say that. But like, particularly now with GitHub actions minutes and stuff like that, there's a huge amount of infrastructure that is available between, I don't know, GitHub actions and co-pilot and repo hosting or whatever. In the early days in which I was doing open source, like all of that stuff had to be built individually for each project. And it had to be maintained by people and they were getting woke up in the middle of the night if things went down and all this type of stuff. And like now you don't have to do that for the vast majority of projects and you have a vast amount of very high level impressive technology available mostly for free. And that's great. To me, like that's the foundation of the relationship between GitHub and open source. It's just like the stuff that is given away for free and used for free. And you know, GitHub benefits from that as well, because that's how GitHub grew. Like GitHub grew essentially by convincing a bunch of open source projects, you should use this. And then a bunch of business followed from that. I also think I guess the relationship, it's depends what GitHub is particularly passionate about at any given time and how much that aligns. So if you're a big fan of co-pilot, which I am personally, then you're probably quite excited about what GitHub is doing with co-pilot right now. If you don't care about that, like if, if all you live in is GitHub PRs, then I can understand why you might get frustrated when the PR page is either slower or not getting faster or quick enough or whatever it may be. And so, yeah, I think like that's maybe how stuff changes over the years. And I guess finally, like, you know, GitHub is part of Microsoft now and it's like a big, bigger, more grown up company. And you can't just necessarily message your friend that works there and get stuff sorted that way. But there's good things about that and bad things you read about using AI as, you know, good out of complete. And, you know, you just mentioned that actually, yeah, you are, you are a fan of co-pilot. You review thousands of contributions to the project that they're saying. Have you seen the quality of the contributions change? What can we do? How can we help maintainers when we're wanting to use AI tools? So I think on the maintainer side, there's some stuff that's there already. Like, I think like the co-pilot code review, it's not a replacement for a human, but it definitely catches certain cases in a way that's really helpful and saves time for a human sometimes. It's funny, like pre all the current AI wave, maybe like 2018, one of my blog posts called Robot Pedantry Human Empathy, kind of about this, where I was talking about how people will accept a robot or I guess now an AI being super pedantic about like, oh, you made a typo here and here and here and here and here. Whereas when your human co-worker does that, you tend to think that they're just rather annoying. So I think like leaning into stuff like that is quite helpful. And I guess different people have had different experiences. I feel like I've had probably a pretty good experience, maybe because I know the homebrew code base so well with like assigning issues to co-pilot. The fun thing is, if you want to go see, you can go and look because it's all on the public record of the PRs. I think I just two to three months ago assigned every bug on homebrew on the package manager side, at least to co-pilot just to see what would happen. Right. And what happened was they all got fixed. Did co-pilot get a hundred percent of the way there itself? I don't think in any of the cases it did, but it certainly saved me a lot of time and would get between 50 and 95% the way there on the first time. And then with a couple of prompts get probably 60 to 99% there. And then what I do is I then just go and take over, take the wheel and then finish off the last bits. And that was still very helpful. Particularly with dealing with, I guess, people talk about it with writing a bit more like the kind of blank page problem of like, okay, there's about 10 different ways of fixing this bug. Like I can't decide which one to do. And then I'm just like, okay, right, co-pilot, you pick, and then I'll fix whatever you try and do. And I also think with homebrew, we maybe benefit a little bit more with that stuff because we were early adopters of like GitHub's like issue, mandatory issue templates. In fact, I feel like part of the reason this got built is I just whined so much about it internally for such a long period of time. One of the nice things about that is like, you know, we, we get people to provide step-by-step reproduction instructions in that. And then the AI model can then go and see that and just essentially do what the person has told them to do to find the bug and then do it again to find the repro. So yeah, stuff like that is kind of helpful. I guess on the human side, like I wouldn't say we've had a marked level of almost like contribution, either improvement or decline. Probably I think the cases where people are using AI tooling locally themselves very well is not visible. And I think that's fine. Like personally, I don't care if you did a hundred percent of the work or copilot data or clone code or cursor or whatever, as long as you as the human have given it a once over and been like, okay, like this looks good, or I'm going to tweak this or whatever before you want a homebrew human to review it. That's fine with me. In my mind, that's the key to successful AI usage, right? We're still, I think we probably will be forever, but we're still in the era where a human needs to be in the loop somewhere. You need to have a human review the output before their coworkers do it. And if you get very good at code review, then you are more likely to get better at doing that with an AI as you would with a human. But in some ways, the interactions feel pretty similar. Even a human who's not using AI, we may go through like five or 10 rounds of back and forth in a PR. And then eventually, provided I have the permissions on their fork to do so, I'm just like, look, I'll do the last bit, right? Rather than me trying to tell you what code to write, I'll just go and write the codes and then we can merge the PR and we can move on. Sometimes that final little bit, it just makes sense for the maintainer to jump in and do it. Yeah. So Mike, bummed we won't see you at Universe this year, but if someone listening goes to the open source zone, stops by the homebrew booth, what should they say to Issy and Patrick? First, assuming you use homebrew, say thanks, good job. But then after that, I just encourage you to, in a nice, polite, respectful way, like say, what things about homebrew would you like to see be better, right? And they will collect that feedback and we'll do better with that. My also tip for that with feedback for homebrew or any other technology process is to try and focus when you're saying that on the problem that you're experiencing and not the solution that you perceive. One of the perils you have of having technical users, whether you work at GitHub or we work on homebrew or whatever, is people who can write code themselves tend to jump straight from I have the problem to I can see in my head what the code should be to solve the problem. I'm going to tell you that. But like, if you don't know the homebrew code base, like the back of your hand, which you probably don't, then it's more helpful for people to know like what are the pain points of the problems you're experiencing rather than what you perceive the solution to be. Well, let's move to the section where we all share an open source project that we're excited about. Mike, you're our guest. Are you ready to go first? Yeah, so I've got like a bit of a deep cut actually right now. So there's a tool called SOMO, S-O-M-O. It's under the GitHub user Theo PFR, who's Theodore Pifer, I think, a 24-year-old programmer and student from Munich. So it is a cool little application written in Rust that shows what ports on your local Mac are open and closed. And this is a very niche thing that you probably only need every few months. But like if you accidentally end up starting your Rails server or MySQL server or something like that on a port, and then another thing is like saying, hey, I can't open this port because this other thing's got the port, then this is a very nice, easy way to figure that out. It's a cool little tool that I've liked recently. Thanks for bringing this up. Starting it right now. Boom. Andrea, do you have yours? Yes. This just so happened to be a Microsoft in-source project that was just released, I guess, a couple of weeks ago, the spec kit, that toolkit for us to start thinking about spectrum development and utilizing that methodology with the help of AI to basically ship faster. I'm excited to use it. I think it's great that we're investing on beyond the AI tools themselves and ways to help the humans work with the tools better. So now we're moving into a world where, yeah, everybody has the power of co-pilot or whatever your preferred tool is. Understanding spectrum development, understanding the who, the what they have beyond the immediate problem and the code is huge. So if you're an entrepreneur or if you want to be, I think it's a good approach to building software. What about you, Abby? What's yours? Mine's a deep cut. I came across it recently. It's a super old project, but my friend, my friend Luke, he made CSS Diner. It's flukeout.github.io. Flukeout's his handle. And it's like just this fun little tool to help you learn CSS. And there's this little animation of like plates dancing. And it tells you to select the plates. And then you learn how to use CSS to like select it. It's really fun. It's a nice way to learn how to code like CSS at least. And it's kind of old, but I wish I want to see more projects like this. This is why I bring it up. I want to see people make fun educational tools. Abby, I love this. This is so cute. And then it even has a help I'm stuck. So it gives you like a little, yeah, this is a great little tool. I love this. Shout out to that human. Well, to everyone who's been listening, this has been the GitHub podcast where we talk about the topics, trends, and culture around the open source community on GitHub. My name's Abby. You can find me at abbycabs, most places on the internet. I'm Mike McQuaid, everywhere on the internet. Pretty much mikemcquaid.com is my blog where you can find links to posts and talks and social stuff and all that good stuff. And I'm Andrea Griffiths, a la Columbia Dev in all places. I'm andreagriffiths.dev. That's my site. And it's been fun to be here with you two. Thank you. This was delightful. Thank you.

Hey folks, welcome back to another episode of the Ruby Rogues podcast. This week, I'm your host, Charles Maxwood, and we are talking to Mike McQuaid. Mike, you came on before we talked about homebrew and building homebrew and workbrew and all the stuff you were doing at the time. Is there anything else you want people to know about by way of introduction or? Yeah, not really all the same old stuff, like I'm not kind of doing as much stuff on workbrew nowadays and doing even more stuff on homebrew nowadays. So yeah, all good stuff. Nothing really has changed. Good deal. I use workbrew, or not on workbrew, I use homebrew all the time. So yeah, glad to hear it. It runs on Linux too, I think. I think I wound up using it there somewhere. Yeah, yeah. It runs on Linux and I guess because it's Linux, but we've still got a little, a few tweaks there as well on like WSL, on Windows as well. So I've ended up playing around with it on my like Windows gaming machine, which until recently has been unsullied by homebrew. Unsullied, I love it. Yeah, we talked quite a bit about homebrew and how it works last time. And I thought it'd be interesting because I find myself sometimes fiddling with like writing scripts or things like that on my machine and then thinking, you know, it wouldn't be too bad to kind of parlay this or the set of scripts into like a CLI. And so I was just curious. I don't even know where to start with that. But since you've kind of built a CLI that a lot of people use, I know you had other contributors, but yeah, let's say that I'm sitting on some stuff that I think belongs in the CLI. Where would you even start with something like that? Yeah, I think that's, it's a really good question because I think the, it, a lot of this depends on, I guess, like a lot of stuff in tech, right? It's like, what does your scaling story look like, right? To be one of those boring people of like, if it's just something that you're writing for yourself to run it once and throw it away, then, you know, thinking about like the language you use, like, you just want to reach for whatever is the most familiar to you, or I guess increasingly nowadays, like, whatever you think, chat GPT can one shot a reasonable approximation of what you want it to do. And then you can tweak it before you run it. But yeah, so like that way more than I care to admit. I mean, it's great, because I feel like there's a lot of stuff around that where there's like scripts that previously we just wouldn't have written. And then now just being like, hey, I want to pull this data from the GitHub API and previously be like, oh, it's possible, but don't really want to spend like two hours on this. And then it's not like, well, I'll spend 20 seconds asking chat GPT and look at the output. And if it's wrong, then it doesn't matter. But yeah, so I guess that's the first thing is like, so for me personally, like I tend to reach for like the smallest, dirtiest, filthiest scripts for Bash because I'm pretty comfortable in Bash. There's, Bash has like a huge amount of gotchas though. So as soon as it becomes even slightly load bearing, even for you, you probably want to go to like a, no offense, Bash authors, like a real language. And at that point, you know, stuff's pretty interchangeable. Like if we're on a Ruby podcast, so like Ruby is really good for like standalone, single file, CLI scripts. That's what I would tend to kind of go for straight away. If you're a Python person, Python's pretty good for that type of stuff as well. I think like, you know, if people don't have familiarity with those, I'd be surprised if they listen to a brewery podcast. But then, you know, I'm sure you can probably do equivalent stuff in C sharp and various other, right. More obscure languages. But like, I guess that's where I would tend to go next is just be almost like, okay, how can I put it in a single script? And you can do some kind of neat stuff with, most people are familiar with bundler for installing dependencies. But then most people are also like, okay, like bundler, I have to do like bundling stall and bundle exec and all this type of stuff. But actually, you can do some cool stuff with bundler where you can actually define a gem file inside the script itself. So the first thing it does is checks all its dependencies and installs them all. So that can be, again, quite a nice way of extending some little basic scripts. Yeah, I just want to back up on that for a minute, because I ran into that somewhere. I can't remember where, but yeah, it's just its own little syntax in there, isn't it? What exactly do you have to do in order to? Yeah, I can't remember the exact syntax off the top of my head. But yeah, basically, like, I mean, that's the nice thing about the state of bundler and Ruby in 2025 is if you're installing an even vaguely modern Ruby, it's going to come with a vaguely modern Ruby gems and bundler out of the box. And then everything essentially you can do through the CLI, you can also do through the Ruby APIs instead. And that means that essentially every input that you would previously have passed in as a parameter, you can pass in as a string or like your gem file, instead of reading it from disk, you can like have that be like a here doc in your Ruby script or whatever it Yeah, like, so that's a nice way of getting there. So like, that's what I will tend to do is have like a little bit at the top of maybe one of my scripts that's like, hey, if I need this particular gem, then install this gem at the And then I don't need to like carry along the script and a gem file and whatever, but I can just run it wherever I need to and however I need to. Yeah, I did find that you require a bundler inline and then you do gem file do, and then you basically put all your gem file stuff in there. So you do your source, which is probably rubygems.org. And then you gem whatever. And yeah, you just use your, the domain specific language for the bundler for the gem file. Yeah. And off it goes. It's pretty cool. So then when your script's getting a little bit more, I guess, load bearing, as we were saying as well, like that might be when you want to be like, hey, I want to have some like options parsing. And like the most basic way of doing that is just, you know, you've got the argv like array and you can go and say, okay, what's the first parameter, second parameter. But if you want to handle flags and switches and being passed in different orders, there's like the Ruby, again, part of the standard library, there's the Ruby kind of option parser library, which is pretty good, pretty easy to use. If you're still in bash land, there's like sort of a bash equivalent. But in my mind, even by the time I start getting towards like multiple argument parsing, it's like, that's again, a nice sign that I probably want to go into Ruby and use that kind of richer library. And there's also various gems that provide different DSLs for whatever your preferences are Yeah, that makes sense. I know a lot of people also use Optimist used to be called Trollop. If you're been around for a while and it's like Optimist, it's the same thing. So do you have a preference? It's funny because I tend to, I tend to like not, I tend to use just the most basic, like I'm going to pull stuff out of argv until it hurts. I think it's also because I've been around in Homebrew and Ruby and whatever, like long enough. It's like, I'm aware of all of the kind of edge cases that you get there. And like, if you delete a random part of argv or if you dupe it, or if you check for inclusion, like what the various gotchas are. So like, I wouldn't necessarily recommend other people do what I do. But yeah, but I guess I don't have a particular library that I prefer for this stuff. And Homebrew, because for a very long time, Homebrew kind of couldn't really by design use any Ruby libraries without fully vendoring them all, which was a big pain for us. Like Homebrew basically built its own argument parser and stuff like that. And even today, like Homebrew, we're a little bit, I wouldn't say suspicious of other libraries, but it's like the, we care, I guess this is a nice segue to the next thing you might start caring about with the CLI, which is like Homebrew nowadays, we really care about like the runtime and almost like how long is it going to take to essentially, you know, do the thing that you want it to do. So like how long, how long until you can print a hello world once you have all your libraries loaded and everything like that. And I think that's the type of thing where, like, if you have a script that you run once a month and it takes 30 seconds to run, you probably don't care if it takes five seconds or 30 seconds or a minute, right? Like it's, but if you have a script that you're running in your shell prompt, say, and then your shell's not going to be print, your shell prompt's not getting it printed until the script completes, all of a sudden you maybe don't want to require that library. You maybe want to do it by hand so that you can just boost it, or you may well be getting to the words of the point, which Homebrew is not quite able to do, but some of the other CLIs I've built more recently, I guess, like at Workbrew and at GitHub or whatever, it's like, okay, you maybe want to reach for another language at this point. So Ruby is really good language. There's been a lot of performance authorization work that's gone into Ruby in the last five or 10 years. But a lot of that comes from the Shopify's and the GitHub's who are not focused on how can I make a CLI run as fast as I possibly can, but they're focused on like, how can I have a long-lived Ruby process realistically running probably Rails or Sinatra or whatever, which can serve as many requests as possible as quickly as possible, right? So that has more performance implications around like memory management and garbage collection and jits and stuff like that. And things which rewards the longer execution of the application, which is the exact opposite of what a CLI does. Unfortunately, some things like Rubicop have kind of got around that by having, I forget what they call it, but there's basically a mode where you can essentially have Rubicop sitting in the background and you end up sending requests to an already running process. I guess we could maybe take that approach with Homebrew one day, but we've not yet. So instead, we're generally concerned about like, how can you, how can you shave that time How can you require as little as possible and push some logic into maybe Bash in Homebrew's case? But when you're writing like a prophecy ally, then that's, you know, that looks like maybe nowadays probably the best choices would be something like Rust or Go, depending on your Like Go, for example, is, if you're used to Ruby, it's a very sad language, I think, to write because it's, you cannot be expressive. I'm learning Go right now, so. Yeah. I mean, so how have your experiences been with that, about like going from the delights of Ruby land to Go land with the stuff? Yeah, yeah, I don't love it. I mean, I, I'm just barely getting into it, but they use it at work. So, um, yeah, backend engineer encompasses Ruby and Go. Yeah. And mostly I get away with not doing a lot of Go, but yeah, they, they kind of expect and need you to, so. Yep. Yeah. It's, I don't know, I feel like there's, there's definitely been several schools of languages languages where the, the underlying methodology is like, stop people from doing stupid stuff. And Ruby feels like it's almost as far in the other extreme as you can do, where it's like, you can, I mean, I'm sure you've reviewed some absolutely heinous Ruby code of the years where people have taken metaprogramming to an absurd Goldberg level where it's impossible to figure out what's going on, but that also allows you to build incredible DSLs and rails and all of this stuff, right? In Go, I'm sure you have the same Charles. I just ended up feeling like, you know, this like 20 line switch statement could be one line of code in Ruby, but you know, you don't let me have the, you know, you've taken away the keys to this particular car. So I guess I have to write the 20 line switch statement. Yeah. I just have to say, I mean, to a certain extent, like control flow and things like that, it's all the same, you know, there's some funky stuff with like variable, variable assignment and functions and things like that. But yeah, it doesn't light up my soul like Ruby does. Yeah. So like Go feels in many ways to me, like a sort of much less verbose Java. And like, I wrote a bunch of Java back in the day when it was peak Java enterprise beans and, you know, all of this like excessive boilerplate. And there's a lot less of the boilerplate in Go, but it still feels like there's non-zero amounts. But yeah, so as I say, I would still consider reaching for Go for a CLI if you really care about that like execution performance. So for example, I guess when I was at work previously, I was working on the CLI there, which wrapped around homebrew CLI. So we wanted to provide as little overhead as possible. And the amount of stuff you can do in 0.1 of a second on modern hardware in Go compared to Ruby is like fairly spectacular. Like in Ruby, you're really trying to make sure you avoid like any IO or significant computation Just because of the virtues of it being like a natively compiled language, you can just do an awful lot of stuff much faster. And like the multi-threaded story as well is like, because it's not the global interpreter lock or I can't remember if that's the Ruby name, but whatever the Ruby equivalent is. And you can, you can afford to just lead into the concurrency a lot harder. Yeah, that makes sense. So let's say that I want to build a CLI and I'm trying to think of like a super fun example. Let's say that I'm going to, you know, I'm going to get an open AI API key and I'm going to, you know, I'm going to make it talk to whatever. So, you know, maybe it'll talk to multiple services there. Right. So I'm doing stuff maybe with the podcasts, which is kind of what I'm imagining. So I, I hand off my audio or video to whisper and it bought a being, I got a transcript. Right. And then maybe I hand the transcript off to the LLM and it does some stuff. A lot of this stuff. I mean, you would put on the back of like a rails app or anything else too. Right. But, you know, I want to command line interface just to make it super easy for me to kind of navigate through some of this stuff. Where would you recommend I start? I mean, like for me with stuff like that tend to, in some ways, that's a kind of general question about like, how do you build software? Right. And I'm sure everyone has different views, but like the way I've always liked to do it is essentially just try and write the, well, I'll give my pre AI answer first. My pre AI answer is essentially just write the filthiest, hackiest code, assuming that no one will ever read it to just get the core thing done. So I guess in your case, it's like, okay, I want to write a script and I would point the I'm not going to do any argument. I'm just going to assume an argument has been passed. I'm going to pull out the first argument. I'm going to get the file, maybe the MP3 file or whatever from the podcast on disk. I'm then going to load that into memory. I'm then going to pass that off to open AI's transcription API. I'm then going to pull down the result of that as like JSON or whatever. Then I'm going to immediately get that, not store anywhere, stick that into opening AI's like MLM API, do something with that, bring that down and then print the output, right? And essentially build it in such a way that there's no error handling. If anything is in any way, not the happy path, then it will fail with a completely incomprehensible So like generally that's the way I like to feel out how to do things initially. And this episode is brought to you by Spreaker, the platform responsible for a rapidly spreading condition known as podcast brain. Symptoms include buying microphones you don't need, explaining RSS feeds to confused relatives and saying things like, sorry, I can't talk right now. I'm editing audio. If this sounds familiar, you're probably already a podcaster. The good news is Spreaker makes the whole process simple. You record your show, upload it once and Spreaker distributes it everywhere people listen. Apple Podcasts, Spotify, and about a dozen apps your cousin swears are the next big thing. Even better, Spreaker helps you monetize your show with ads, meaning your podcast might someday pay for, well, more microphones. Start your show today at Spreaker.com. Spreaker, because if you're going to talk to yourself for an hour, you might as well publish Like I think sometimes with like CLIs and stuff like that, it can be tempting to be like, oh, I'm going to add the options first, you know, because that's if you're almost like thinking from like top to bottom, that might be how you would think about it. But actually, like that's not really probably the thing you cared the most about. You're trying to figure out is this thing even viable or useful or whatever. And every minute you spend fiddling with options is a minute you're not figuring that out. Right. Not doing the core thing. That makes sense. And then, so one thing that I'm looking at is, so then do you just build the CLI around it so that you can say transcribe file name? Yeah. Yeah, exactly. So I, again, with this type of stuff, like I tend to go for like, keep everything in one file, like until it starts falling over. And I would, again, to start with not even necessarily use any methods until I am thinking about making things kind of dry and, you know, I'm having to call the same thing multiple times or whatever. So I just would tend to do that until it feels like it's getting too much. I don't know what that is, whether that's, you know, a couple hundred lines, 500 lines, a thousand lines, whatever. Right. And then start splitting up. As you said, if you had commands, like say you're passing like a transcribed command to do this or like a read out loud command or, you know, start a chat command or whatever, then that might be when I'm like, okay, well, logically there's like three different things this is doing. Probably the codes between them is not actually that similar. So maybe these could all split out into separate files that are stored a bit separately and included separately and whatever. And again, that's one of the pros and cons of kind of Ruby and Go. And stuff like that, because in Ruby, okay, you've got those different files, but you've now, once you split into multiple files, like if someone else is like, oh, cool scripts, how can I use it? Then it goes from being like, here's literally like the copy and pasted script contents to being like, you need to clone this repo. And here's how you run it. Yeah, exactly. So like, okay, you could make it a gem and then they could gem install it. But like, I'm showing my homebrew maintainer bias here, but I've, I personally, I really like Ruby gems and equivalents in other languages for like, I want a library. I'm writing Ruby. I want a library for Ruby. I kind of resent it when I'm like, I want to install a tool that just happens to be written I don't actually care what language this tool is written in. Right. And I have to use NPM or gem or PIP or whatever to install some random CLI. Like for me, I would always either reach for homebrew or if it's just something my mate wrote, ideally my mate just like sends me the script and I have like a dumping ground repo and I just like copy and paste that file into my repo and then I can run it or modify it as I choose in future. Right. So that was that. You're, you're talking around one of the things that I was going to ask, right? Because if it's just one file, it's like, okay, stick this in your path. Make it executable. Bam. Right. But if it's multiple files, yeah, I was trying to figure out, okay, how do you package that? And I guess, yeah, you could use something like homebrew or yeah, I agree with you on the, I mean, if it's a Ruby specific tool, like rake, I don't really have a problem with it being in Ruby gems, but yeah, like the, I've used other CLIs. I think it's like the Heroku CLI or the Stripe CLI. I can't remember, but one or two of those, it was like, yeah, I had to go NPM install it and I'm going, yeah, but this is not a code tool. Yeah. And that's, yeah, I agree with you there. It's like, no, this, this belongs in homebrew or apt or yum or, you know, whatever, whatever your package manager is for your operating system, where it's going to pull it in and say, hey, this is a utility you're going to use for other things. Right. It's an application essentially that runs on top of your OS. And as a Ruby podcast, it feels like a safe space to admit this, but yeah, like I, my one is like NPM where it's like, I, ideally I don't have Node.js on my system at any given So like when, when something says like, oh, the way to do this next step, like step one, NPM install X. And so, well, actually there was a step zero, which was install Node.js. Install Node. And I, and given that this thing that you're asking me to do is nothing to do with JavaScript. Like I don't see why I have to do that. So often I'm like, okay, I then go looking and I'm like, oh, is this, is this already in homebrew? And if not, maybe I package it in homebrew for my own benefit and other people in the future But yeah, I've always felt that that's that. The kind of, I think that's a, you've brought up a bigger question there about almost like And I think that's, that's a bit more kind of messy and complicated because it, it ends up being like, well, what is the distribution method? And, and homebrew somewhat infamously, I think it might be one of the first, maybe even the first to the whole, like cold to bash installer scripts that everyone is much derides, but like, you know what, if you're installing something, exactly. It works. But also like, if you're trying to install something that's kind of like non-trivial, like homebrew that involves cloning a repo and you know, again, it's like the NPM install, like we could say, okay, well, step one, get clone. And so, well, I don't have get on my machine. It's like, okay, well you need to still get, how do I do that? Well, it's still homebrew. Like, you know, whoops. I, I, I guess that's my issue. Right. Is I generally have node and NPM on my machine. Right. I'm working in rails. You know, I need some kind of JavaScript runtime. And so it's like, okay, this feels weird, but I'll do it. But yeah, if it's a pip install, cause I, I never touched Python or, you know, if, if it requires go or something like that. Now these days I'm working on go, but yeah, it's like, why do I have to install a programming language in order to get my tool when it doesn't really have anything to do with the programming language? And so, yeah, just getting into, you know, that step, I, I guess some of these come like self-packaged or when you do the install, then it'll, you know, behind the scenes, it'll install either a standalone version of the language or give you some way of building it on your machine. Or sometimes it's just an executable that's prebuilt that, you know, it has reasonable assumptions about what's already there. And so, so that works. Um, but yeah, so let's say that I am building a CLI, uh, I write it in Ruby, you know? I mean, I can tell my friend to go get clone it, right. If they're a programmer and, you know, and then it's like, okay, here's the command to run it. But yeah, let's say that it's something that's getting wider adoption and it needs that distribution, right? Where it's, Hey, you know, you're going to go run this on your own machine, right? Maybe it's a fancy CLI that cleans up large files on my hard drive or something like that, It's some other utility that, that does some of these other things, you know, it's helpful and I don't need a UI for it, or at least not a complicated UI, big graphical UI. Yeah. How do, how do I begin to package that up? So again, probably unsurprisingly, my natural response to that is like homebrew is pretty good. Distributing software, right? So with homebrew, you can kind of stick it in a repo and then call like brew create dash dash Ruby, point that at the repo and then homebrew will try its best to figure things out. And, but then, you know, if it can't, you can fiddle with that and homebrew can help you And, you know, if this is a, a thing that's pretty widespread use and you're packaging someone else's software or whatever, then you could submit it to the main repository and chances are it will be accepted fairly quickly. And then everyone can benefit that. If not, we have this thing called, called taps, which are like third party repositories, basically that you can run a command brew tap new, which basically will create a new tap for you. You can then push that up to GitHub as a repo. And we spit out some nice CI workflows. So you can use those free public repo actions minutes to put them to use. And then you could use that as your distribution method if you want instead. And then that could be a nice way of, you know, regardless of what language you write it in, if you're doing Ruby or Python or Go or whatever, then you can distribute your software that way pretty easily. So if there's any kind of setup or build step or anything like that, is there some version of like an install script or something that it runs or? Yeah, yeah. So there's like in Homebrew's Ruby formula, which is kind of like our DSL for like building and installing software, basically. There's yeah, there's like an install method. And basically you can, much like in normal Ruby, you can run a bunch of system commands in there. Like we try and do a reasonable guess of like, hey, if it's a Ruby project, you probably want to run like bundle install and then, you know, stick a Ruby file in a bin directory somewhere. And that probably gets you most of the way there. But yeah, but it's basically just like little nice DSLs that kind of help you get that software onto your machine. And it's, I think one of the nice things about Homebrew is it's definitely of most of the packaging systems I've ever interacted with. And from what I hear from people, it's one of the easiest to just get started with like an existing piece of software. Because essentially you're just like, okay, run some commands, which you can try yourself and bash and then move stuff from one place to another. And then that's you. So, I mean, in the case of Ruby, Homebrew already runs Ruby. But let's say that I reach for something like Go or Rust, or maybe I'm using Python, right? And so I can't assume that the person whose machine is going to get installed on has, you know, the language or language tools that I need in order to build and run it. How do you manage that kind of a thing? So in Homebrew, that's, we just have like a little line again with our DSL called Depends on where you can basically say, okay, I need Ruby or this particular version of Ruby or whatever it may be. Where it gets a bit more fun. And it installs that globally? Yeah. So it installs that, but Homebrew keeps track of, okay, did you ask me to install it? So say we have your OpenAI transcription thing, call it Transcribey or whatever, right? And you might install it with Bruinskull Transcribey. This episode is brought to you by Spreaker, the platform responsible for a rapidly spreading condition known as podcast brain. Symptoms include buying microphones you don't need, explaining RSS feeds to confused relatives and saying things like, sorry, I can't talk right now. I'm editing audio. So if this sounds familiar, you're probably already a podcaster. The good news is Spreaker makes the whole process simple. You record your show, upload it once, and Spreaker distributes it everywhere people listen. Apple Podcasts, Spotify, and about a dozen apps your cousin swears are the next big thing. Even better, Spreaker helps you monetize your show with ads, meaning your podcast might someday pay for, well, more microphones. Start your show today at Spreaker.com. Spreaker. Because if you're going to talk to yourself for an hour, you might as well publish it. So that would install Ruby automatically because that's what you said. But then in a year, you're like, ah, you know, Ruby sucks or whatever. I'm going to rewrite this and go. And then you switch your packaging to Go, then Homebrew knows when you ran Brewing School Transcriby, you weren't saying, hey, can I have Ruby and Transcriby? You were just, I just care about Transcriby. I don't care what Transcriby is written in, right? So then if it changes in future to Go, then Homebrew then knows like, oh, well, you never We don't need Ruby anymore. Let's give it a Ruby, right? And again, the fun thing with Go as an example is like, and this is where it gets slightly I won't go into the details unless you're really interested of like, if you're, you're building it yourself versus if Homebrew builds it for you, but if Homebrew builds it for you, then the nice thing about Go is because Go spits out binaries, then you don't even need to install Go on your system, right? You can probably use the binary that we have built for you. So then you can get rid of Ruby. You don't need Go. We need to install Go when we're building it for you in our servers, but on your system, you don't need Go unless you're building it from source, as we would say. Right, similar with Rust. Yeah, exactly. And it seems like the approach that we're taking with Ruby or Python or something that's not compiled that way, or Node is another example, right? If it's running on any of those, the install Node or install Python or install Ruby approach works fine on Linux or Mac or in the USL. Yeah. WSL, whatever it is. I am not a Windows. I help my wife with Windows, but she's not using the Linux emulator. But yeah, so that works fine there. And then if you need to package it up for something like Windows, then you're looking at another tool that's going to essentially package your language, right? It's going to put your Ruby VM in the executable so that it can run. Yeah, so that's when it starts to get a bit more messy and different languages are optimized So again, like going right back to our original, like I'm writing a CLI. So I think like one of the first questions I would probably have is like, what are the chances are that you're going to want to ship this to Windows users, right? And if, unless the chance is definitely not, then Ruby and Python and even more so things like Bash are, you know, very easy to get started across Windows and, sorry, across Linux and Mac OS from the outset. But then when you have like a Windows story, that's when it starts to get a bit more messy. Like Windows has, again, like plenty of package managers and stuff like that. But your average Windows user is not going to be familiar with those. And even a lot of Windows developers don't necessarily use like package management as widespread as it is in the Linux and Mac OS worlds. So that's when I would say like the story that Go, for example, can do for you is I'm less clued up on Rust in this way. So I might, excuse me, any Rustians who are listening that I might not know quite as much about what Rust is capable of. But certainly I know with Go, the nice thing is you can just build a single binary, which you can then have run on a Windows machine and that will work as expected, right? But the other nice thing with Go is it's the cross compilation stories very easily is very So even if you only have access to a Mac machine, you can build the binary on your Mac for all Mac OS versions, essentially, and Linux and Windows. And if you don't have access to those operating systems, you can have a reasonable degree of confidence that unless you're doing kind of wacky OS specific stuff that that binary will just run fine on all three OSes. And like that's a pretty appealing thing if you're building a CLI that you want to be used cross platform. Yeah, that makes sense. I'm a little curious. Getting into running it on Mac versus Linux, like are it seems like for the most part, things just generally work the same way. Are there meaningful differences that you need to be aware of in certain cases? Yes. I think most of the time you don't need to think too hard about things. And I think it's, it's often relatively obvious when you're sort of starting to get a little bit more detailed. So, for example, one difference would be the, I mean, you know, we're going to really nerd out on some nice OS, well, like high level OS internals here. But, you know, like macOS and Linux run different kernels, right? There's the Linux kernel and the macOS Darwin kernel. And then there's the stuff in user space as well. So like, because, yeah, like, as you mentioned, like macOS came from like a BSD kernel land, like most of the user space applications are BSD. And on Linux, most of the user space applications might be GNU ones, right? And Apple won't use those because of GPLv3, which is a whole other long and very boring But yeah, so basically, like, if you're calling out to various, say, like even GRET, right? GRET has arguments that will work on macOS, and they will not work on Linux in the same way, and vice versa. So you might, if you're shelling out to GRET, you might need to have like conditional logic based on the OS you're on. Or alternatively, instead of shelling out to GRET, you just say, okay, I'm going to instead like get all the lines, and I'm going to iterate over the lines in Ruby and do things that way So I think with like writing Ruby itself, like Ruby and Python are both generally written in such a way that like, pretty much everything you would ever try and do is going to be cross platform by default, right? It's just various little gotchas like shelling out or, again, I can't remember this still the case in 2025. I'm pretty sure it is. But like, by default, Linux generally ships with a Linux issue ship with a case sensitive file system. And macOS ships with a case insensitive file system. So if you're doing all your development on Mac, and you have like some file that you read in from your repository or whatever, and it's uppercase A, you know, Anteater with an uppercase A versus Anteater with a lowercase A, that will work just fine on macOS if you're inconsistent between the repo data on disk and how you've written in your source codes, but then on Linux that might block, right? So like these are types of little things that you need to care about when you're doing cross platform development. So yeah, I'm just trying to think through the rest of it. I'm imagining that, yeah, if I split things up into files, what it's going to do is it's going to put all of my files into one place, put the executable in the path somewhere, and then the executable is going to be aware of where the things are and just have that in the load path, essentially. Exactly. Now with testing, are there specific things that you do when you test? Or do you just kind of test the internal logic and assume that your flags and stuff work? So that's a good question as well, because I think particularly if you've never really written a CLI before, you would probably think, particularly once you get to like the multiple files level of like, okay, I'm going to write a bunch of unit tests for the internals and make sure that they work. My experience as a, you know, long-term CLI-er is that like, actually, that is going to cause you a lot of pain unless you have at least some tests that are actually shelling out and running the script externally, right? And we, I guess, relatively recently in Humbru, which in my mind is probably like 10 years ago, but that's recent as far as I'm concerned. So we used to have a lot of tests that were just, you know, unit tests. And then we would just find like really core functionality would break because all of the internals, all the internal APIs were working, you know, it's the, it's the tailors all this time with like unit tests versus integration tests, right? Of like, you can have all of your internal APIs working perfectly and are beautifully tested, but then when you fit them all together, things explode. So as a result, like I've always found with CLIs in particular, like really taking that sort of outside-in testing approach is really nice to ensure that you're like, okay, so say again, we're talking about this open AI CLI type thing. Like if I was writing a CI pipeline to test that, I would probably give GitHub Actions my, like either my or a test open AI key, and I would have it in CI, like actually trying to run a transcribe command on maybe like a single word or some very short amount of input data and actually making sure that as close to a real use of that application is actually being tested and working as expected because all the kind of clever, like all the clever unit tests you might have will just otherwise fall over when you need them the most. I like it. Um, I'm going to, oh, go ahead. I was going to say, so another thing you might find, I guess, as I've been talking about like CLI performance, cause it's sort of in front of my mind with this stuff. So there's a guy who's written loads of really helpful little CLIs in Rust. I forget his name off the top of my head, but we can find him, Google him later or whatever. So he's got a really nice tool he's built called Hyperfine, which is a CLI benchmarking tool, basically. Um, it does a bunch of other things, but that's what I've found it most useful for. So what that does is it takes this sort of outside in approach and you can say like, hey, I want you to run this command this many times and then tell me like what the performance characteristics are, or I want you to run this command and this command and tell me the difference between the two. So quite often when I'm doing like homebrew performance work, the way I will measure the performance differences is like that command could include like checking out a branch or you can, you should specify that as like preparatory command or whatever. So I'll say, okay, check out this branch, run this homebrew command, then check out this branch, run this homebrew command. And then it just has a nice little display of almost like, well, when you run this command, it's 1.4 times faster on average. And that varies by like, this episode is brought to you by Spreaker, the platform responsible for a rapidly spreading condition known as podcast brain symptoms include buying microphones. You don't need explaining RSS feeds to confused relatives and saying things like, sorry, I can't talk right now. If this sounds familiar, you're probably already a podcaster. The good news is Spreaker makes the whole process simple. You record your show, upload it once and Spreaker distributes it everywhere. People listen, Apple podcasts, Spotify, in about a dozen apps, your cousin swears are the next Even better, Spreaker helps you monetize your show with ads, meaning your podcast might someday pay for, well, more microphones. Start your show today at Spreaker.com. Spreaker, because if you're going to talk to yourself for an hour, you might as well publish 2% like across the iterations and it will, I think it runs at 10 times by default, but you can, you could say run this a thousand times or two times or whatever. And there's like, as you might expect for kind of a beautiful, like proper CLI nerd CLI like this, you know, there's like so many different options to twiddle every possible knob to get it to work exactly how you want it to. But yeah, but if you're ever in a world where you're like, I really care about the performance implications of my CLI, like that is the best tool I've ever used and works basically exactly how I want it to, because it does that inside out testing, right? Of like actually running the actual process and then measuring the actual time that like So big shout out to Hyperfine. And yeah, the, I found it on GitHub. It's a David Peter and a short DP is his GitHub handle. And yeah, yeah. Looks like a cool tool. Cause I wanted to switch gears a little bit. Yeah, please. So I was, I wound up on your blog when I was getting ready for the episode and you have an article on here and we wound up talking about AI and it seems like it's still the hot It's funny cause over the last, I don't know, three, four or five months, I've really started to use AI quite a bit. Sometimes I use it essentially to write most of the code. And then I have people, you know, get concerned about whether AI is going to take people's jobs and things like that, which you address in your article here. It says open source maintainers thrive in the LLM era. You know, you address some of that and you talk about how people are using LLMs and things like that. I'm just wondering like what, what's your experience using LLM tools like Cursor or And then the other question I have is, and you kind of address it here is, is there any hope for the people that are freaked out that AI is going to take their programming job? So I guess I'll make sure I get to both of those. But yeah, I guess the experience wise, I've been probably using some sort of tools and some Cursor capacity since the very early days. So like back when Copilot was still an internal alpha at GitHub based on, I think GPT two to Yeah. And OpenAI had publicly not really done anything except released a bunch of papers. Like I, I was asked to test it internally, essentially. And like, I was known for being the type of person who was good. If you wanted honest opinions of the things I was testing, because regardless of the political consequences, if you asked me to test something and I thought it was all trash, I try and be But like, I would not tell you that it was great. I would tell you that it was not great. But yeah. So I remember trying this and being like, this will, because I'm sure people, it's almost hard to even remember. But like, if you put yourself back in whatever this was, like 2021 or something like that, like, you know, if someone had described what you're able to do now with Copilot or Cursor, and they said, I built a thing that does this, you would be like, your eyes would roll out your head. And then you'd be like, okay, like, yeah, whatever. Like, I've seen a lot of autocomplete. Like, it always sucks. It just gets in the way. It's not useful. Like, I write Ruby now. The autocomplete in Ruby sucks. I don't really care and I don't really miss it anymore because I've got used to it and whatever. This is just nothing that I care about. Right. And I tried it. And like, my almost immediate reaction was like, even when it was way more limited, was like, wow, this is, this is not like radically transformative yet. This is not incredibly workflow changing yet, but this is really good. And this is a lot better than I expected. And ironically, you could build a pretty damn good autocomplete without any specific knowledge of Ruby as a language, but just using this kind of LLM technology. And I said to the team, I was like, yeah, I assumed this would be complete garbage and it's actually good. Well done. Like, can I keep using this, please? So I guess I went from that to using Copilot. I just want to chime in. That kind of lines up with my early experience with a lot of it where it was, it was a little beyond autocomplete and it didn't always give me what I wanted. Like, sometimes it was like, you are assuming that I am doing something wildly, drastically different from what I'm doing. But it was, it was right often enough to where it was like, oh, okay, I'm, I definitely want And I think that's the thing, like in the early days, particularly, um, and I think maybe some people who tried stuff out too early have over-indexed on this. I, I think it was very personal in terms of like, what's, what's the hit rate? Because, I mean, I find this with software engineers in general, right? Is there some software engineers I know who will look genuine, completely genuinely without any sense of irony will express, but this only solves the customer problem 99% of the time. Therefore it's pointless 1% of the time, why would you ever do that? And so, well, actually for most people, if this makes things a hundred times faster, 99% of the time, which I'm not saying AI does, but like in some decorative software cases, things do that's probably an enormous amount of business value for a lot of people. Right. But there's, we have, and I don't think it's necessarily a bad thing, but we, we tend to have a streak as a, you know, we're literally the people of zeros and ones. So it's like, we want things to be perfect. And when things aren't perfect, it's easy to kind of fall into the, like, well, why did Like, you know, what's the point? Yeah. And I, I definitely think there was only LLMs, like, um, the only copilot. It's like the auto-completion was, you know, if that's wrong 50% of the time, there's a lot of people who just find it really, really annoying. Whereas I'm the type of person. But it sped me way up. Like, whereas I, I think I'm lazy enough that I'm like, if 50% of the time I can just like, I'm, I'm a reasonably fast typer. I was never one of those like hyper fast. I've switched to the Vorak because it gets me an extra 10 per second, whatever, like them keyboard warrior types. So for me, like, I'm like, oh yeah, you know, like half as much typing some of the time is well worth it for me. And I, I can, I feel able to ignore the visual noise of it always trying to prompt me to do the wrong thing. And some people hate that and, and I get it. Right. But yeah, I guess I would say if you're one of those people that hated that in. This episode is brought to you by Spreaker, the platform responsible for a rapidly spreading condition known as podcast brain. Symptoms include buying microphones you don't need. Explaining RSS feeds to confused relatives and saying things like, sorry, I can't talk right now. I'm editing audio. If this sounds familiar, you're probably already a podcaster. The good news is Spreaker makes the whole process simple. You record your show, upload it once and Spreaker distributes it everywhere people listen. Apple podcasts, Spotify, and about a dozen apps your cousin swears are the next big thing. Even better, Spreaker helps you monetize your show with ads, meaning your podcast might someday pay for more microphones. Start your show today at Spreaker.com. Spreaker. Because if you're going to talk to yourself for an hour, you might as well publish it. You know, maybe even six to 12 months ago, like you should check back in because things are changing. Very fast, right? Yeah. So kind of getting into the question that I'm asking, I'm enjoying this, right? I'm not saying you didn't get to the point. What I'm saying is, so like this morning, right? Or last night, I think it was last night. I started it and then this morning I finished it. But, you know, I'm expanding my podcast hosting system, which also does courses and summits and coaching and podcasts and screencasts, right? Because that's all stuff I want to offer off of the back of the podcast, right? I was like, okay, well, I've got this multi-tenant setup going and so I need people to be able to sign up, right? And actually pay me to use the system. And so I said, hey, I need a signup form. And I mean, it wrote all the views in Rails. It wrote all the management and the admin system. It wrote, you know, and it basically worked. I mean, I had to tweak a couple of things because, you know, it was like, okay, you know, you got this wrong. And then when I asked to do something else, it changed it back. And I had to go in and say, no, actually you did it wrong the first time. But I mean, it would have taken me a day or so to figure out, you know, to actually build it out on my own, right? Go in and put everything together. It's all pretty basic stuff. But it, I mean, it just wrote it in like 20 minutes, right? And then, and then the tweaking took me probably another 45 minutes. And so I can see people looking at it and going, this thing is going to take my job. Yeah. And I understand why people think that. And I guess like, to me, it would be when someone with your level of experience, Charles, is able to do that. And there is zero tweaking. And like, I've done this 100 times in the last two weeks. And never at any point have I had to change a single character. Like, that would be when I would be more concerned about being like, well, you know, maybe I, I still think the job of being a software engineer wouldn't go away in that case. Because I think we are even outside of programming, right? My, it was cooking some sweet potato in the air fryer yesterday, right? And my wife and I both use ChatGPT and I transcribed it using voice. And she heard the way in which I speak to ChatGPT and the amount of context I gave it about like, here's some facts about my particular sweet potato and how I like it. Here's some facts about my air fryer and whatever. And she was like, wow, like you, you said a lot of stuff there. Whereas I would just be like, cook sweet potato in air fryer, right? And the prompt she would get back would be pretty poor. And the prompt I get back is amazing, right? So I guess some people talk about like prompt engineering or context engineering or whatever. But like, I think there's more to it than that. And I think there's a reason why the experts in prompt engineering or context engineering don't just happen to be like international tennis players or philosophers or whatever. Like there's mostly software engineers or at least software adjacent people. Cause like, this is still talking to computers and computers still like to be talked to in a, like LLMs like to be talked to in a different way to, you know, your CPU, but it's still sort of an art and a craft in that way. And like, I can definitely imagine almost the worst case scenario of when you're going to be writing a lot less codes by hand than you ever were before. And for some people that really bums them out and freaks them out. But I still think that job of like, I take customer requirements and turn them into software. And that's still a job, right? And that's still a hard job. And it's still a job that someone like yourself with a lot of experience, you are able to work with LLMs dramatically more effectively than a random person who started coding two months ago. Right? Yeah, I agree. There are a couple of things that you kind of talked through that I want to touch on. I mean, one of them is, yeah, you figure out what, essentially what context you have to give it, right? Yeah. So you give it all of the information it needs so it can break it down and go, okay, this is what I'm working with. And then, yeah, it'll give you a much better response. One other thing that I found that just kind of comes with experience with the LLMs is that, and this came up today, like I forgot to tell it, I'm not using Devise on my Rails app. And so it actually said, right, because I told it, I was like, you need to send an email confirmation when people sign up for the system, right? Not just a welcome email, because I need to confirm that their email works. And so it turned around and it said, I see that you're using Devise confirmable. And I immediately had to get in and stop it and say, I am not using Devise, right? And then it did the right thing. And so, you know, I had to remember that. And so some of that with the prompt engineering, yeah, you figure out what context it needs in order to make the right decision, and then you give it to it. And a lot of it, too, is just being thorough, right? So that it doesn't make any assumptions. I know we're kind of anthropomorphizing the LLM, and it's just a predictive language model. But, you know, yeah, it doesn't make any assumptions on what you want. And so, yeah, some of it's going to just boil down to, yeah, I'm the human that's giving it a proper prompt that gives me better outputs. But the other thing is, is that, yeah, I still find that I have to tweak it, or at least I have to verify it, right? Even if I didn't have to touch it, I have to verify that it does the thing, right? I have to spin up my app and go and click through it, or if it's a CLI, you know, I have to run it a couple of different ways to make sure that it's still doing what I want. And so there's that, too. And then the last thing that I'm going to just point out is, like, I'm not seeing companies laying people off saying, well, you know, we're using the LLMs to enhance the capabilities of our programmers, and so we don't need half of them anymore. We're not seeing that. What we're seeing is we're seeing companies go, we can get 10 times the work done, or, you know, five times the work done, or double the work done by having the engineers that we have use the tools. And I think that just accelerates. And I think any company that's short-sighted enough to turn around and go, we're going to lay off half of our technical workforce, their competitors are going to come in and eat them alive. Yeah, I think that's some people that speculate that's the case. Some companies hint towards that being the case, but I don't think it's. I think what you are seeing, and again, I think if we're talking about things that you can be freaked out about, is, like, there's definitely been a big drop in hiring for juniors, right? Like, there's measurable decrease in junior engineering positions. And I think there is this outstanding question of, like, again, you and I have touched upon Like, I say in that post, one of the reasons why I talk about, like, why I think open source maintainers are well cut out for the LLM era, right? Is that conversation you mentioned before, if you were talking about building something on an open source project, you could have equally been describing almost identically some contributor you've never worked with before, right? It's like, oh, well, you know, I opened an issue and then overnight, some random person I never met before appeared. They made a PR. Like, it was mostly all right, I had to make some tweaks, and then I merged it, right? Like, and I actually think the trust and verification process looks very similar, right? For someone like yourself, with a lot of experience, someone like me with a lot of experience, particularly if you have a lot of experience with one code base you've worked with for a long period of time, like, you're able to provide probably very in-depth review of a relatively large amount of code in a very short amount of time in a way that makes these tools valuable to you, right? If you were unable to do that, either because you lack the experience, you lack the context with the code base, you lack the programming ability yourself, then all of a sudden you end up in this precarious position where it's like, okay, either I go at 100 miles an hour and, like, if this stuff breaks, I won't know how to fix it. And I won't know even really how to describe to the LLM, like, what's gone wrong. Beyond just copy-pasting error messages. And when that fails, like, I'm just, shout out, look, right? Or I slow down and I say, okay, I just, I'm going to learn software the same way everyone learned software before LLMs, right? And then the people that I have to kind of have a bit of the FOMO or even potentially my management chain being like, hey, all the seniors are like 25, 50% more productive now. Why aren't you? And it's, I, I'm glad I'm not responsible for social engineering or whatever. Cause like, I think that's a really hard question of like, what are we going to do as an industry? Because we can't just say we don't hire more juniors anymore because that's not going to But at the same time, I don't think we have a really good answer for like what those juniors should definitely do to skill up, right? Like, yeah, it's hard. I like, I like, I completely agree with you. I think kind of reading between the lines on your blog post, it seems like part of the answer is having juniors or people who are at that level doing open source with it, right? Because then it's not, you don't have your boss or your company or the deadlines or things like that, where people are going, why are you taking so long? And then the other thing is, is that if you do take the extra minute, even if you're still generating the code with AI to then ask the LLM, okay, explain to me what you just did. Yep. Right. You, you can start to get context for what it did and why it did it. Now it may not be giving you the best practice, but it's giving you at least some context for what it's working with. And in some cases it is going to be best practice or at least common practice. So, and you're seeing that even with the LLMs now, right? Like the kind of study mode and chat GPT and things like that, where like I played with that a little bit myself when I've been kind of. This episode is brought to you by Spreaker, the platform responsible for a rapidly spreading condition known as podcast brain. Symptoms include buying microphones you don't need, explaining RSS feeds to confused relatives and saying things like, sorry, I can't talk right now. I'm editing audio. If this sounds familiar, you're probably already a podcaster. The good news is Spreaker makes the whole process simple. You record your show, upload it once, and Spreaker distributes it everywhere people listen. Apple Podcasts, Spotify, and about a dozen apps your cousin swears are the next big thing. Even better, Spreaker helps you monetize your show with ads, meaning your podcast might someday pay for, well, more microphones. Start your show today at Spreaker.com. Spreaker. Because if you're going to talk to yourself for an hour, you might as well publish it. Trying to learn new things that I don't want to overly lean on the LLM. And, you know, it's kind of trying to do a bit of Socratic method stuff and all this But even with, I think it's a great place with open source where, you know, there's a bunch of talented homeroom maintainers I know who are, in some cases, haven't had a tech job yet or still in college or relatively recently out of college. And, like, their code review abilities for typical expectations of, like, a new engineer are, like, completely off the charts. Like, some of them are dramatically better at code review than I am, having done it, you know, probably 10 times as long as they have. But they've had a lot of experience doing this. And I think that might be part of the junior story is that I think we cycle, we sort of had a little bit of an attitude, I think, for a while, at least in some cultures of companies I've seen where it's like, well, okay, we'll get everyone to review a bit of code. But really, like, the more senior people are going to be more responsible for doing the more in-depth, hardcore code review of, like, gnarly stuff, right? And that might be the culture that needs to change. But we're actually like, okay, rather than saying to the juniors, like, hey, you just spend 95% of your time coding. Don't worry about this code review stuff too much. You'll figure it out as you go along. Maybe we need to flip it around and be like, actually, you should spend 95% of your time coding. And don't worry about this coding stuff too much. If you read enough of other people's code, you're going to figure that out, right? And maybe that's where we go. And certainly that would be an attitude that would make you more qualified with working with LMs better, for sure. Right. You brought up code reviews, and that kind of reminded me of another thing, since we're talking about AI and things like that. So yesterday, I put in a PR at work, and I asked some folks to review it. And I got on this morning, and it still hadn't been reviewed. Whenever people get in and they see the message, I'm sure it'll get done. Anyway, when I checked it, GitHub asked me if I wanted Copilot to review my PR. So how do you feel about that? Yeah. I've actually, at Workbrew, and now at Homebrew, and some companies I've done contracting with, have enabled... In fact, I don't know if I've done this on Homebrew, actually. But basically, whenever I can, I enable Copilot review of PRs by default. And I think... Is it good? It's sort of... So it has definitely caught a bunch of stuff that humans have not caught on my PRs. Again, the false positive rate is pretty high. But if what you're concerned about is like, hey, I want to make sure that someone is going to catch my typos. Again, like another blog post I wrote a long time ago, and at this time, this was whatever, 2018 or something. So we weren't even talking about AI and LLMs. But I think it still kind of holds up, is I wrote about like, I called it like robot pedantry, human empathy, basically. And what I compared in that post was like, on the one side, like people are like Rubicop, you can set to be like hyper anal, right? And like really, really pedantic. And people could actually be fairly tolerant of that. I actually quite like that when it's dialed up to 11 like that. But if you as a human give the same code review feedback as a Rubicop up to 11, all your coworkers will hate you. Yeah. Often, even if you have agreed on these coding guidelines as a group or whatever, there's something about like that level of pedantry about like if someone typos something 10 times going through and every single time being like, typo, typo, typo, typo, typo, even if you use the GitHub suggestion, so it's one click for them to fix it. Like people don't like that. They really hate it when humans do that to them. But that's the expectation that robots will do that. So that's one thing I found is like useful on that side. But then again, like I said in that post, so part of why I wrote the post at the time is like there'd be more and more moves like automation and stuff like that, which I thought was really healthy and like CI. But you were starting to see people being like, oh, the first time someone makes a pull request on my repo, we should congratulate that person. So let's write a bot to congratulate them. And I remember talking to a bunch of people and they were saying like, yeah, it just, it feels completely meaningless when a bot says, well done, good job. You're a rock star now. It's like, you know, it's like, I'm in some empty room by myself and, you know, over the tannoy came a robotic voice saying, you are great. You know, it's like, whereas if a human says to you, hey, well done, like I'm pumped that you're here, like that actually has an impact. So that's, and I think this is the same thing with, with kind of code review and copilot and these tools and whatever now is just like, you know, like copilot can give you a review where it points out your typo is more effectively than a human can, but copilot can't say, wow, that was really cool. Like you solved this in half the lines of code I thought is possible. Like this is a really elegant solution. Great job. Like, and that's again, much as like the stuff about humans and jobs and whatever, right? Like most of us are probably not going to be okay with spending 40 hours a week exclusively communicating to an LLM. Like we want to deal with humans who say nice things that they actually mean that are not in the prompt, right? Like, and that does have more of an impact. And I, I, that's, I feel the same way with like code review, where it's like, these are complimentary tools and the human code review and the AI code review are sort of doing different things, but I'm glad that they're both there and I wouldn't use one to entirely replace So I guess the other question that I was asking is what AI tools are you using these days? Yeah. So for me, I'm mainly using like cursor as my kind of in editor, like code completion thing. And like their agent modes kind of sporadically, but again, I use it kind of in the, in editor And I still use chat GPT mainly for stuff where I'm just like asking it things where I'm going to probably write the code myself or with a bit of help from cursor, but like I basically use that instead of Google. And then the thing that has been interesting to me recently is, so I started, everyone was being like, all my kind of AI forward friends were like, Oh, you need to use code code, code So signed up, played around code code. I was like, okay, this is quite good. But I think just because I'm an open source maintainer, like there's this GitHub agent PR thing where you can now, if you have co-pilot for your organization or whatever, I'm not quite sure how the pricing and the enabling works or whatever. But it works on Homebrew essentially. So what you can do is you can just assign an issue to co-pilot and then it will just open a PR that's like, okay, I've tried to solve this issue for you. Right. And this is good that we're having this conversation today because it's fairly timely because in the last week, Homebrew had, I think eight open bugs on the main kind of package manager repo that I review everything on. I was like, I'm just going to assign all of them to co-pilot and see what happens. And it's similar to the thing you described earlier, right? Where it was like, in most, in a couple of cases, it was like literally spot on first In most of the cases, it required me to do the last like 10% of the code. And then in a couple of cases, it was like 25% of the way they are pretty broken. I had to have quite a bit of back and forth. I ended up kind of rewriting half of myself, but even then it sort of solved the empty page problem for me. And I think it's just something about me as an open source container that it feels good and nice to just be like assign issue, PR, review PR, check out PR to finish it off, merge PR. And like, that's the flow instead of like this thing that lives in my terminal that I need to check and whatever. Yeah. I like, I like you, you brought up the empty page situation that that's a really good way of putting, right. Cause I'll sit there and okay, how do I need to put this? Okay. And then I can, I kind of have an idea of how I want it to go. And so I start kind of fiddling with it. And instead I can just, I can prompt the AI. This is what I'm building. And sometimes I'll ask, you know, how should I start? And sometimes I'll just tell it to go for it. And I'm sure you found this as well, but like sometimes when it's, even when it's completely wrong, you probably heard that, like a camera who said this ages ago, that like the quickest way to get a stack overflow answer is to answer your own questions with the wrong answer. And then everyone will jump in and be like, no, that person's wrong. Let me tell you how it actually is. Sometimes I feel like the same way with the LLM stuff where I'm like, yeah, sometimes it goes off and it's does something completely fucking terrible. And I'm like, no, that's not how you do it. You obviously do it like this. And I'm like, oh yeah, I figured out how to do it. Well, what's funny is that there were, there were a couple of things that I was working on with the, cause I'm using cursor and agent mode. The main reason is, is because my employer provides us with credits on copilot. Yep. On VS code, which is what I kind of gotten used to, but I don't want to use works copilot credits on my personal stuff. And so I use cursor for my personal stuff and copilot for their stuff because I'm using the same GitHub account for both. And so anyway, um, there've been a couple of times where I've told it to do something and it sits there and it flails, right? It's like, yeah, I'm going to do this. Oh, wait, I think I have a better approach. So I'm going to delete everything I just did and do it this way. And it'll do like two or three things. And yeah, I'll, I'll finally just step in and say, I've been watching you. And actually, I just want you to do it this way. And it'll just turn around that. Of course, it tells me I'm smart for saying that. Right. And then again, it's like, you're a machine, you, you know, but do it my way. And yeah, and so just because it gets it wrong, doesn't mean that it can't get it right. If you give it just a little more direction. And to just speculate widely, uh, for a minute, I also have a hypothesis that maybe the reason why junior hiring could be done is the people who were previously responsible for mentoring those juniors are now essentially mentoring their LLMs. Cause like, again, that, that flow you described earlier about like with rails and all they thought I was using device and I wasn't like that again. This episode is brought to you by Spreaker, the platform responsible for a rapidly spreading condition known as podcast brain symptoms include buying microphones. You don't need explaining RSS feeds to confused relatives and saying things like, sorry, I I'm editing audio. If this sounds familiar, you're probably already a podcaster. The good news is Spreaker makes the whole process simple. You record your show, upload it once and Spreaker distributes it everywhere. People listen, Apple podcasts, Spotify, and about a dozen apps. Your cousin swears are the next big thing. Even better. Spreaker helps you monetize your show with ads, meaning your podcast might someday pay for well, more microphones. Start your show today at Spreaker.com. Spreaker, because if you're going to talk to yourself for an hour, you might as well publish 10 years ago, you could have described some new talented junior person that you hired, right? And oh, wow, they, they saved me so much time. And I had to do the last little bit to help move the line and whatever. Like, I think the flow and also like the stuff you like and the stuff that's really frustrating and exhausting about it is kind of the same. And I personally couldn't imagine a day where I spend half my days supervising agentic AI And then the other half doing the same thing with like junior folks who are struggling in Or the worst of both worlds, which we're seeing in open source now, which is someone who is junior, who is trying to use an AI agent to create a pull request. And obviously you can't really prove this, but like I had a PR today where each round of review, they were responding and then they, they would paste something into an issue comment with like the slash N characters in there rather than new lines, which makes it look like it And then I would ask, I'd be like, give them a bunch of comments, but then one of the comments would be like, Hey, like you've added two extra options to the CLI. Which one of those are you using? Do you need both this functionality or just the functionality for one? Because if we just say the functionality, if you only you need for one, and they would just completely ignore those questions and just turn it into more code. And I had that AI feel that I'm sure you're familiar with Charles of just like more code every time, every time the solution is, we're just going to add more code. Right. And it got to the point where I was like, I'm just speaking to someone's code code through if I wanted that, I would be using code code myself. So I couldn't prove it, but I just closed the PR because I was like, sorry, feels like I'm speaking to an AI, not human. And I thought to myself, I'll probably just assign this issue to copilot later and see how it does. And it's probably going to be easier than what we're doing right now. All right. Well, I've got to start wrapping up. So let's go ahead and do some picks and then we'll call it good. Before we do that, if people want to connect with you, if they have questions about homebrew or it sounds like you'll help people out for hire, at least you used to. So if there's a place for people to hire you, I'd love to have that too. But yeah, how do people connect with you on any of those levels? Yeah, sure. Best place for me is my website at mikemcquade.com. If you go there, that's got links to all my social media. It's got all my email. It's got talks or articles and all this type of stuff. Anything you might want to know about me. That's basically the best kickoff point there. All right. Well, let's go ahead and do some picks. I will get us started. Boy, it's been a while since I've done this. I'm trying to think of what games I've been playing lately. Here's one that I'll do. So I don't know if you do board games much, but... Yeah, I do a little, not a huge amount. Have you ever played... Again, like a couple of times. I've never been a DM or anything like that. Okay. So there's a game out there called Betrayal at House on the Hill. And I think there's a book or a movie or something related to it. Anyway, essentially, you take your Scooby-Doo gang into a haunted house and you go explore the house until the haunt starts. And then you, yeah, one of you becomes the trader. And so then it's the trader against the explorers until one of you wins, right? And so it gives you, you know, and there are two books. There's the trader's tome and there's the explorer's manual. And so the explorer's manual explains to them how they win and the trader's tome explains to the trader how they win. And the reason there are two books is because there are some things that the trader has to know that the explorers don't need to know or it will let help them win if they knew. Anyway, so it does that. Well, there's a version of this called Betrayal at Baldur's Gate. Baldur's Gate is, there's a video game, Baldur's Gate. But Baldur's Gate is a D&D location. And so if you ever look at anything that's Baldur's Gate, you'll notice it's Wizards of the Coast, which is the company that does D&D. And so anyway, so Betrayal at Baldur's Gate is Betrayal at House on the Hill with the D&D elements from Baldur's Gate. And so instead of exploring rooms, you're exploring areas and you have the cities, like the streets, you have indoor areas, and then you've got the catacombs underneath the city. And so you can kind of explore or whatever you want. And there are some differences. But yeah, the rest of the elements are the same. And so if you're kind of like that, it doesn't have like strong story elements. It really is just a, you know, an explore and then, you know, fight off the monsters game. But it's fun. And yeah, I played it with my guys group a couple weeks ago. Board Game Geek waits it at, I have six. So, you know, you're casual gamers. It's mildly complicated, but not so complicated that, you know, folks that just like, you know, a casual board game among friends wouldn't just pick it up. So I'm going to pick that up or I'm going to pick that came out in 2017. I don't know if it's still in print. That's the only caveat I have on that. And then on the other picks. Yeah. I've really gotten into using the agent mode on Cursor. And so I'm going to pick that as well. Incidentally, I was just kind of goofing around and I thought, okay, well, how much work would it be to get it to essentially VibeCode, a React Native app, a podcast subscription app? And I have to say that it did pretty good. It doesn't have all the features I want in it yet, but it's good enough to where I'm starting to think about whether or not I actually want to release the sucker onto the app stores. And so, you know, and I'm not a React Native developer by any means, though, again, that's another technology I want to pick up because we use it at work. So anyway, so I'm going to pick that as well. And then within React Native, I'm using Expo. Very cool. But yeah, Mike, what picks do you have? Yeah, so I guess my game related pick would probably be Avowed. So that was recommended to me by, I don't know if he's been on this pod before, but certainly legend of the Ruby community, Justin Searles. Oh, yeah. It's sort of like, you know, it's made by Obsidian. It's like a kind of Bethesda-esque, like story-driven RPG. And it's just, I don't know, like if you liked all those old school RPGs like Oblivion and Skyrim and whatever, it's got that vibe, but like lots of nice, like quality of life things. Like, so if a character ever uses a sort of bit of jargon, you can just press a button and then a glossary pops up that sort of defines the specific bit of jargon they use. And I'm like, yeah, I want this in every RPG now. And like, you know, if you're a mage, you have a wand that casts stuff and it doesn't require mana and, you know, like lots of just like little things that have annoyed me in So yeah, I'm enjoying just exploring that. I imagine it's one of those games I'm probably going to 100% just because like the world is interesting enough. Yeah. What's it called again? It's called Avald, A-V-O-W-E-D. And then my, I guess if you're not a gamer, like TV wise, we've been watching Tokyo Vice, which is pretty interesting about this guy who's a journalist and kind of lots of stuff like organized crime in Japan. That's, I can't remember what network it's on or whatever, but that's been good. It's only two seasons of that. We're about halfway through the second season enjoying that a lot. And then I guess on the computer land, I guess, yeah, I mentioned it already, but I would probably say the, the co-pilot agent mode where you can assign it from, assign an issue and it will then create a PR. There's a bunch of rough edges there, but there's something about the workflow that feels pretty different to like running agents locally and has a different trust model in a good way in that like you can let it just run arbitrary commands and it's running in some random doc container and GAOPS infrastructure that you don't care about compared to your local machine. But yeah, but for, if you're someone who lives in PRs all of the time, then it might be worth seeing if that's an agent flow that works for you more than like some terminal app or some window in your idea or whatever. Well, thanks for coming. This was fun. Yeah. Thanks for having me. Always a fun time. I'm going to go ahead and wrap us up. Until next time, folks, Max out. Max out. Thank you.

So, Homebrew is an open-source package manager, primarily targeted at macOS. It's got tens of millions of users, something like 15,000 packages available, and it's pretty much the de facto kind of app store for developers on Macs. It's pretty crazy. Like, Homebrew is unusual, I think, in terms of just being relentlessly obsessed with automation. Like, anything we can automate, we try and automate. While at the same time prioritizing the security side of things. Hi, this is Brian Douglas, and you're listening to Open Source Ready, a bi-weekly series where we discuss the evolution of open-source software and its impact on the tech landscape. Along with my co-host, John McBride, we'll explore topics like open-source AI, the business, and the life and sustainability of open-source. Open Source Ready is brought to you by Heavybit, the leading investor of developer-first startups. For more information, visit heavybit.com. If you're interested in being a guest on the show, or if you'd like to suggest a topic, find us at x.com slash open-source ready. Welcome to the installment of Open Source Ready. John McBride, you're back again as co-host. How are you doing? Hey, I'm back. How are you doing, Brian? Yeah, thanks for never letting go. You're still holding on? I try. This is episode 14, actually, at this point. Wow. We haven't podfaded, as they say in the business. I think the number seven, where you quit. Okay. So we're over the peak, you would say. Over the peak. But we're not here to talk about that. We actually have some pretty cool guests. We got Mike McQuaid and John Britton from Workbrew. Mike, how you doing? Hello, very good. Thank you for having me today. Yeah, and John, you're here as well? Yeah, thanks. It's good to be here. Cool. So let's do some intros. Mike, you can go first. Tell us, who are you? What do you do? Why are you doing this? Yeah, I'm Mike McQuaid. I live in, today, actually, truthfully sunny Edinburgh in Scotland. I have worked on developer tools for the last probably 20-ish years. Most recently, I guess we'll talk about that later, I'm working at Workbrew. That's a company I started with John. And for the last 16 years, I've worked on Homebrew, the macOS and Linux package manager. Which I've been kind of leading for the last few while as well. And I spent a decade at GitHub building developer tools there as well. Yeah, John, you've got a pretty extensive background, but what do you do? So I've spent most of my career also in developer tools, but mostly on the go-to-market side. So I got my start as a developer advocate at Twilio. I also worked at GitHub for a number of years on the education side. And then later on kind of DevRel and then developer marketing. Until I came out and started working with Mike and started Workbrew a couple of years ago now. So yeah, I've been doing developer tools and web development, that kind of stuff for 20-plus years. Yeah, so honestly, we probably just want to not bury the lead. And let's just describe what Workbrew is and where it fits today. And so how you came to this conclusion that it needed to be in the world. I mean, I think the best way to start is to start with Homebrew. So Homebrew is an open-source package manager, primarily targeted at macOS. It's got tens of millions of users, something like 15,000 packages available. And it's pretty much the de facto kind of app store for developers on Macs. And with Mike's extensive history as project leader of Homebrew, it was obvious to me as early as, let's say, 2013, that there was an opportunity here for a business. It took us quite a long time to figure out what that was. And after going out and talking to lots of companies, especially companies in regulated industries, where they have kind of rules of, you know, things that they need to keep secure and whatnot, we found that there was a need for kind of a managed version of brew. So that's where we ended up going and building Workbrew, essentially taking Homebrew from a single-player experience on one developer's machine to a multiplayer, team-wide experience with kind of centralized management. Our core value proposition is that you have one place to manage all of the software installed across your entire fleet of devices. You get full visibility, you get the ability to, you know, kind of remotely manage, patch, upgrade things, and set kind of some compliance guardrails to make sure that, you know, your developers are happy, but also safe and secure. Yeah, this is great and actually really resonates with me because years ago, I built, I mean, it was really just a bunch of bash scripts for bootstrapping workstations at Pivotal. And the way Pivotal worked was, you know, everybody just sat at a workstation to do pair programming together. So ideally, you could just like move around to any of these different computers. You had to do a bunch of this different stuff. And it was constantly breaking. So I can really appreciate this work and know that it's very, very valuable. Mike has an open source project from GitHub Times. Maybe you want to talk a little bit about Strat, Mike? Yeah, we did the same sort of things at GitHub where Homebrew is kind of fairly integral to the developer experience there. So yeah, we built, well, I guess I built a thing called Strap that was basically just the delivery mechanism for the first thing you could run on your laptop to get kind of Homebrew set up in your machine. And then kind of on top of that, you could have your personal like brew file, which is a big, maybe the coolest part of Homebrew I feel like people don't know a lot about, which is basically like a declarative way that you can like list, I want all these packages on my machine. And then you could keep that in your .files repository. And then basically that's, you can get everything from Homebrew bootstrapped on your machine that But also in GitHub, we use them extensively across projects as well. So rather than having a new readme like, oh yeah, remember to install Postgres and set You could have scripts that would call the brew file in the repo to make sure that everything was, that the projects needed, had that installed in the right directory. So yeah, that all worked pretty nicely. And as you say, John, like I think the goal for this stuff is always onboarding, making that speedy, turning documentation into code, making it consistent, all this good stuff. Yeah, and John McBride, I don't know if you, you mentioned Pivotal in passing, but like some people might not even know Pivotal's like engineering culture, where it was like paraprogramming all the time, every day at the paraprogramming station, which is like amazing that that was even a I don't know if that's still a thing at companies today, but like I've got like my personal keyboard that has like my touch and feel, like I can't type without it. It goes everywhere with me. I couldn't imagine having, not only not having my keyboard, but also not having my setup. And like just before we got on this call, I upgraded my Postgres to like 14.7 using brew Nice. So I was going to ask the question because I've been, so John's been working on this like AI agent framework in Go, and I've been like testing it out. I'm not a Go, I don't feel like I'm a Gopher yet. And I don't really know a lot about setups. I just do, I used to be a copy and paster from Stack Overflow, but I constantly run into like the problem of like, I don't have the right versions. I don't have the right things set up. My user bin, local, whatever, it's all messed up because I don't know how ZSH works. So I guess the question is like, is Workbrew today, is that solving that for like engineering Yeah. So I think basically like Workbrew has two main audiences in mind, right? So one of them is Mac admins that we talked about before, essentially like the people in your IT or security team who are making sure that all the Macs have the right software and are in compliance and stuff like that. And historically, that crowd has kind of not been a huge fan of Homebrew because they don't The tools they use like Jamf, Kanji, MDM tools don't play nicely with Homebrew. So basically like that's the main first piece we've built right now. And then we also care a lot about developers. Obviously, like we are building a developer tool inside of Homebrew. And like the goal with Workbrew so far has essentially been to provide all of the compliance and security stuff that those folks work and a identical developer experience, basically. A just as good, you wouldn't know that you're using Workbrew instead of Homebrew. But we're not ready to announce anything just now, but we definitely we have stuff in the pipeline related to what you were talking about, Brian, where we have heard those concerns before about like the issues around, say, reproducibility with Homebrew and being able to set up a And then turns out everything that was working fine on the old machine is now not working on the new machine. And basically like the only thing we can say there is like we've heard that loud and clear and we at Workbrew are working on solving that. We just don't have the announcement for that type of stuff yet. Yeah. And I think like just to add to that, the idea behind Workbrew also is not just to give the same level of experience on the developer side, but to make it better. How can we make things better for teams that are using Brew? I've used Brew with lots of different teams and generally there's some patterns that people follow and find. Oftentimes it's like Mike said, there's a read need with a bunch of packages you need to install. Maybe there's a script that calls Brew Bundle. Maybe there's different stuff, but there's not a recommended path, let's say. And I think we can go a long way in giving companies more of a recommended path to make sure that their developer environments are consistent and reliable and easy to set up and smooth and also secure and have the latest things and free from vulnerabilities and whatnot. So yeah, there's more to come on that front for sure. Yeah. So it seems like there's a very bright future for Workbrew and the Brew ecosystem at large. Mike, I did want to ask you about like kind of the past and like where we're coming from. Because I mean, for me, Brew itself is almost table stakes, even on like my Linux desktop. Like there's just some packages I got to get off of Brew. But where has this like community gone? You know, you've been maintaining it for a long time. How do you handle all that pressure across, you know, basically every developer's MacBook Yeah, it's pretty crazy. Like Homebrew is unusual, I think, in terms of how much stuff goes on and how many packages we provide and how few people are involved day to day. So we have like, I think, 30 something maintainers. In reality, probably like 15 are pretty regular. And then on like a daily basis, you know, you might have, you know, 10 or so who kind of are interacting with the project. And yeah, I guess that seems pretty crazy in terms of how do you keep on top of version of taste for like 20,000 packages. And I guess the answer has been twofold. And I'd like to take credit for at least some of that. Like one is just being relentlessly obsessed with automation. Like anything we can automate, we try and automate. While at the same time prioritizing the security side of things. So for example, like John McBride, if you had a GitHub project or whatever, and you release some new version and it's packaged in Homebrew, then basically we would have software that would essentially detect that on a very regular basis and then just go, okay, John's releasing more software, make a PR, build it, package it, test it, make sure everything looks fine. But then we still have a human required to basically look at that, check the results, check the pull requests, check the changes, essentially make sure the automation is going well, and then So I guess I like to think that I was, you know, we were doing a human in the loop before it was the buzzword du jour. Yeah. Honestly, a huge, huge mad respect to that because like, I mean, just the vast amount of software that floats through Brew, like pretty insane, you know, the stability and the secure aspect of that. So yeah, mad respect, honestly. The other, I think, piece of that, which I feel like doesn't get talked about that much in open source really, is like being pretty aggressive with our like interpersonal boundaries, right? So I am a member of two simultaneous camps that I don't think are unrelated. One is someone who's actually been continually maintaining the same piece of software on a near daily basis for 15 years. And the second is being somewhat known as like a fairly brusque individual who has very strict interpersonal boundaries when it comes to open source. And like for me, like that's how I've been able to not burn out, frankly, is because I, and I encourage everyone on the project to behave the same way. Like I don't feel like I have to do things, right? And if people are being very rude or entitled or their behavior is inappropriate, when they're dealing with a volunteer run open source project like Homebrew, it's like, well, essentially you're living off the goodwill of the maintainers who are working on that. And actually, in almost all cases, they are just more important than you, right? If they burn out, many more people suffer than if your issue doesn't get responded to or fixed or whatever it may be. So we've kind of really fostered this culture of like prioritizing the mental health of the maintainers and stuff like that over necessarily trying to implement everything that everyone might want us to implement. And in some cases, that's meant like getting rid of features in Homebrew because lots of people like them, but the support burden is just too high. And that's the nice thing with Workbrew is that now finally, like A, when it's actually a day job, you know, you can not just have to learn personal boundaries, but you have an actual team and like contracts and all these nice, beautiful things that we have, thanks capitalism. And also, you have the ability to support people at a higher level, right? Like if you're doing evenings and weekends stuff, right? If someone's like, hey, I need help for two weeks building some integration with an MDM provider, like that's a no for me for my evenings and weekends. And that's a yes for me on my, you know, nine to five, Monday to Friday, right? Like I'm more than happy to do that stuff and build something awesome that does what Yeah. Amen to that. Honestly, I've been on the burnout track for a long time with some of my open source stuff. So yeah, that really resonates. It's hard to not like feel that burden. So it's amazing that you've been able to kind of separate yourself. I'm sure it's been like a big part of that sustainability. I know, Brian, do you, have you like experienced that before? Like in some of your open source work? Yeah, it's funny how, I can't remember I mentioned this on recording or before the recording, but like I worked for John at GitHub and then I worked with Mike at GitHub as well. And even like with Strap, actually the job before GitHub, I remember actually using a sort of carbon copy of what Strap was to get started in our environment. But like so much of what Mike says, what he just said really about maintaining open source is like what I've also kind of thought through. Like a lot of my open source is like GitHub Actions because I happen to be the face of that But I'm like totally fine with like never responding to a random issue in action. And I just archived like three repos like just last week because I'm like, hey, story changed. Like my goals have changed. Priorities have changed. I can't support this anymore. So like clone it, fork it, whatever. It's in the readme. So yeah, it's hard because like there's a lot of folks who have like main character energy when it comes to like and getting involved in open source and like, hey, I found this cool thing and it's going to solve all my problems if you spend more time on this. But I've got three kids and I prefer to make myself available to them first, which means Outrageous. Yeah, right. I can imagine like growing a human in this world and like not being on my laptop all the time. Like that's crazy. But I mean, people pick your poison. Like everyone's got their opportunities and their things that they want to get accomplished. So I'm also 38 years old. So like I don't have the energy to spend all that time maintaining software that was a cool like fever dream that I had like a few months ago. Can I just say I'm delighted to hear that you are archiving repos? Because fun fact, I actually built that feature. This is it all gets basically connected. I built that feature while on John's team, not in engineering at GitHub. Basically, just because I was hearing again and again from open source maintainers, they were like, yeah, I'm just like done with this project. And basically my options are either I delete it, in which case that feels like the nuclear option, or I just get spammed with issues for the rest of eternity. So yeah, so like there was some code in GitHub for like migrating repos to GitHub Enterprise And I was like, yeah, but if you like sort of put them in like migration modes and then just never take them out, then that's kind of like archiving, right? Like we can just make it shut up and then no one could contact you. And then yeah, like so it makes me very happy whenever I hear anyone being like, oh yeah, I archived the repo just because I couldn't handle it anymore. I'm like, great, you did exactly what I hoped you would do. I think one of my favorite non-obvious sustainability options like that Homebrew employs is the idea of not supporting every feature that people ask for and just saying, you know, this is hard to support, so we're not going to make it. Or, you know, kind of leaving the configuration available and telling the user, this is officially an unsupported configuration. If you try to get support from us for this, we will not support you. But, you know, proceed at your own risk, right? So if you have a team, and we know of many companies where they effectively take the open source version of Homebrew and they run an internal mirror of it with their own kind of security and compliance functionality baked in, that's not officially supported by the open source project. And that's like, you know, some of those hooks are there and people can benefit from that But the maintainers of the project, it's not of their interest, you know, to build features that are custom tailored to like one giant corporation that has tons and tons of money for free. And that also creates a great opportunity for us to come along with Workbrew and say, hey, you know, we'll build that stuff for you and we'll turn into a product. Yeah, that's a good point, John. And I was gonna, like, I wanted to ask about Docker in a moment, but actually, I know Solomon Hikes, co-creator of Docker. I actually sat down with him like a couple years ago, and was like, hey, why did Docker And this is like a public conversations on the open source podcast. And the thing he cited like immediately, and I was like, oh, this is bold, but also great that you realize this is that they Docker got to the point where they said yes to everything. And like the challenge of them trying to get profitability and have VC scale, but also enterprise ready products, they just had too much bloat in the product and the company and what they And it got to a point where it couldn't really sustain itself. So like going back to this conversation around homebrew, it's like, it is nice to hear that like, yeah, there's things that actually we're in a delete eventually. There's things that probably belong in Workbrew and not in Homebrew, which it sounds like that seems like a very natural progression of like where people can get their questions answered and eventually hopefully pay for it. But I want to ask the question of like the relation to Docker, because like when I think about environments and like setups, and now we've got like these like agent environments where I cannot have a runtime for my agent in like in the context of AI, like where does Homebrew, Workbrew, where does that fit in that world? Are we replacing Docker eventually? You know, I kind of want to like frame this as a, you know, how developers get their jobs done kind of positioning. And why does Docker exist? Why do VMs exist? Why do, you know, the cloud IDEs exist? Ultimately, what we're trying to do is we're trying to give developers environments to do their work that are repeatable. They're really easy to set up. They're smooth. They're fast. They're inexpensive. They're secure. There's all kinds of things that we want. But for me, one of the most important, you know, aspects of this is, is the environment ergonomic. And what I mean by ergonomic is like what you were saying before. I have my setup. I can use my tools. I can use my IDE. I can use my file system. I can use my network. You know, I don't have to configure, you know, various mappings and all this stuff. And so ultimately, all of these different tools are trying to solve a problem of like a great developer experience, a great developer environment. And they solve them with all different methods, right? You know, with a VM, you have like a full copy of the operating system. With Docker, you have a more lightweight copy, but you still have the drawbacks of, you know, high number usage, high battery usage, slow, lack of ergonomics, whatever. With like cloud IDs and stuff like that, it's similar. Maybe there's an additional cost. You buy a $5,000 MacBook Pro just to like remote into a cloud ID environment and pay Amazon or Google or, you know, Microsoft per minute of your developer environment. Like it just doesn't seem economical to do that kind of stuff. And so, you know, with WorkBrew, our take on that is around like developers are already using Brew as part of their environment tool chain. How can we level up that tool chain to the point that it's like better for teams, better for collaboration, better for that kind of stuff. And so I would like try to frame all of this stuff around the idea of these are all related in the sense of we want to have a great experience, but they're doing it with different methods. And I know Mike has like a bunch of opinions about this as well. Yeah. I mean, I would echo what John said, but I guess to go back to something you said, Brian, like it's funny because for me, I guess Docker didn't fail, right? I think Docker is great. But where I would agree is that like, yeah, Docker became overextended. Like, so the original intent of Docker of being like, hey, particularly for servers, right? The kind of containership metaphor of you can just have like a fairly stupid host that basically just takes a Docker container, runs it, exposes some ports to the world, spins it up, spins it down, maybe you've got some Kubernetes in the background to go and do like auto scaling, whatever it may be. Like that for me is wonderful, right? Like, and we use that at Workbook right now. Like we use Docker files for deploying all Linux servers. And I love that. I think it's a really perfect fit for that particular job. Where I think things got messy is, and this is often what happens with Unix tools, right? Is when people tried to find every single hole that looked vaguely Docker shape and just like smash the Docker whale into the hole. And the classic one for me was when, you know, when there was that wave of, there's not much of this anymore of like, oh yeah, everyone should go and run their developer environments inside a Docker container, right? And like, sure, yeah, you get reproducibility and some other stuff from that, but like at what cost, right? If you're someone who could just SSH in and Vim and clone your Docker files inside the Docker container, yeah, it wasn't that bad. If you're someone who really loves like native Mac OS, like graphical tools and that way of dealing with things, then yeah, the developer experience sucks. And it's somewhat the same way that if you use kind of some of the kind of cloud development environments, you know, say GitHub Codespaces, which I kind of briefly worked on as well, like, you know, it solves some problems, but fundamentally the experience compared to just doing it on your local Mac is not good. If you're on Linux, okay, things with Docker are a little bit less painful because, you know, you're not spinning up a full VM every time, but it's still this, you know, you still have the separation issues of essentially spinning up a full OS to go and run somewhere else just so that you can kind of get your libraries versioned the right way for a project. And it just, I don't know, it just feels gratuitously overkill for me. At the same time, I understand why people do that because sometimes that reproducibility is not easy to find elsewhere and that's why they do it. I certainly would never claim that we are out to completely replace Docker in every single way in every single circumstance. Like to me, that would be falling prey to the very thing that Docker itself did of realizing what's the right tool for the job. But I definitely think there are some kind of, say, local development uses of Docker right now that I look at and I'm like, yeah, we shouldn't be doing that. We have better systems. And, you know, we're all paying, if you've got a Mac, you've paid a decent amount for some shiny piece of Apple Silicon, right? So you probably want to make use of that not by just firing up VMs and not by SSHing to some server that you're paying for by the minute. Yeah. It seems like one of the core kind of tenants of what you're really looking at is that good developer experience. Something I've been thinking a lot about recently, and I don't know, maybe I get wax poetic about this, but just like the developer experience at large seems kind of like it's converging or just kind of getting, you know, gravitationally all pulled together towards like one or two things. You know, maybe this is, you know, an age old question, but do you see things kind of coming together to being like, oh, you're probably just going to be on a VS Code fork and you're probably just going to use this like one package manager thing. You're probably going to be on a Mac and like we could just expect that that's going to be what mostly everybody's going to be doing. And like, is that okay? And maybe it's the other question about that. But yeah, do you see that convergence happening in your space, like working in developer tooling or is it more like diverse than I'm assuming? I think that convergence exists. I think where it gets tricky is, again, like almost everything in software, right? Is like going from 50% of people are using the same tooling to like 90% of people using Yeah, like we're probably seeing more of that. We're probably seeing more people using some sort of VS Code fork than we were previously. You know, I used to be like a diehard text make guy, like Atom and VS Code are too slow. And eventually I'm just like, yeah, like this is too easy to not do. And then nowadays I'm a cursor guy because, you know, that works well for me. But for me, stuff like, I'm sure you probably have had or will have like the Zed guys on the podcast at some point. But like, you know, you have things like Zed out there that are doing things in a radically I still have it installed my machine because it's just lightning fast for certain tasks. And like, I think in some ways we've seen with browsers what happens when you get too much of a monoculture, right? Like there's problems that come from that. So my like happy path is basically to be like, hey, there's like a paved path for this stuff, right? If you're like a new developer, I feel like we're a lot better now being like, do you have an editor of choice already? Because if not, it should probably be VS Code. You're probably going to have an easier time. But like, personally, I would feel very uncomfortable ever being in a company where I'm like, anyone who wants to use Vim is, you know, forbidden, right? You shall not use Vim. You shall use VS Code and the Vim plugin or whatever. And if that's not good enough for you, then, you know, too late. We as an industry have standardized on VS Code. So I worry about that type of thing. Because I think it leaves no room for innovation as well and things to get better. We don't standardize on SourceForge and Subversion 20 years ago, right? And it's probably a good thing that we didn't stay there. It's kind of a fine line because there's also that, like, you know, the aspect of, like, over-customization. When you sit down in your machine and you have, like, a million keyboard shortcuts and you sit down at a different computer and you, like, are totally useless. You don't know what to do. You don't know how anything works. It's like, that's also got its drawbacks. But, you know, having, like, a good middle ground where there's, like, sensible defaults that's mostly accepted and then the space for people to do things their own way is also, you know, quite nice. Yeah, that's an amazing perspective. I've definitely fallen prey to that other side where it's like, man, like, I barely know how to do anything outside of Vim. Or I'm like, yeah, I got the Moonlander. I mean, I was getting all this wrist pain with a normal keyboard. So, you know, Brian, speaking of nice, shiny keyboards, check out the Moonlander. Actually, on my list, I'm going to pick up one. You know, I'm getting old. I'm, what, a geriatric millennial at this point. So, yeah, yeah. Got to protect the wrist and make sure the fingers and arthritis are not inflamed. Dude, I'm older than you and I'm just rocking the standard Apple. Nice. The standard Apple wireless keyboard. Yeah, that's totally on brand for you, Mike. It's like default. Just use the macOS defaults. Use the Apple defaults. Don't do anything special. Pretty much. Speaking of Apple defaults, I did ask this to some of the Phlox people when we last chatted with them, but, you know, Apple and the Apple ecosystem, I still, it still just shocks me that they don't have a default package manager in macOS. And, you know, maybe that's licensing reasons. Maybe that's, you know, maintainability reasons. But from y'all's perspective, do you see a reason that, you know, macOS and Apple wouldn't want to do this? Well, the Apple old school pedant that I am would point out that they technically do have a package manager. It's just really bad. So every time you install a .pkg file, technically you're using Apple's package manager to install things using package util and they have a big list of things. It just doesn't support anything like versions or dependencies or anything that you were searching or any of that good stuff. Yeah, yeah. It's funny because, again, this sort of leads to the conversation from previously, I think, where there was, I'm sure at some point there's been a conversation at Apple about like, should we make, you know, initially Mac ports because they had, they supplied a bunch of hosting and all this type of things. Should we bake this into the US? Should this be a default package manager? But I kind of think we've ended up in a better place from not having a default because, again, it allows people to change in that way. And also because, you know, the app store is a wonderful thing, but there's a lot of things that you don't need to do because you're not in the app store, right? Like we had something in a package submitted to Homebrew a couple of weeks ago, which was a manager for your porn. And we had a discussion as a group and it's like, you know, there's nothing not safe for work about the software itself, the packaging process or the website. It's just designed for a not safe for work thing. And it's like Apple on the app store would have probably not allowed that, right? But we're like, hey, this is software. People want to install it. Like it's not malware. It's not doing anything sketchy, right? Like why wouldn't you let people? And I think this, as much as I love Apple, like I think, I think they recognize that internally There's a certain amount of, if they were to bring one of these open source projects into the fold and be like, this is an Apple thing now, there's a bunch of stuff that those projects do that they probably wouldn't be able to keep doing anymore. And I think that would be a shame. Yeah, it'd be a shame if it wasn't called OnlyBrews as well, that package manager for Amazing. Your files. Sorry, I was sitting on that one. But speaking of that, I did want to really, before we wind down this conversation, talk about the Workbrew business model. Because I think with open source and like Homebrew being a very strong community and open source project, what's the business model for Workbrew? Like, what's the persona of the folks that are going to be reaching for this? It's a really simple business model. We write software and we sell it. You know, it's pretty straightforward. Actually, like, you know, there's all these different kind of open source models. I'm kind of tongue in cheek when I say this, but like, there's all kinds of different models. But like, really, what we're doing is we're building a separate piece of software that's complementary to Homebrew. And we're charging people money for that software. So we're not putting functionality into the open source project and paywalling it or anything like that. All of the existing Homebrew project is under MIT license or BSD2, Mike. Am I saying this correctly this time? Yeah. So it's open source license. You can get it and do whatever you want with it according to the license. And we're doing the same thing. We're helping our customers install Brew. So we give them, as part of our free plan, the best way to install Brew on tens or hundreds or tens of thousands of Macs. We give a simple deployment process you can use with like an IT MDM tool. We give them visibility into everything that's going on. And then give them a way to manage everything at scale. And the way that we achieve that is by basically building a control plane. So all of the work Brew software is how do we connect kind of these individual developer instances to a centralized place to have analytics and visibility and whatnot, management functionality, but without really modifying how Brew works. So it's all about kind of putting a wrapper around how Homebrew works and giving you one coaxes package for a larger team or a larger company. And yeah, and then we just charge money for that. And customers are willing to pay for it. That's awesome. I mean, you said it's simple, but yeah, it makes sense. And definitely appreciate the approach. This week, there was an announcement of FaunaDB shutting down, which is quite unfortunate. Years of serverless databases. And in the threads of folks on X chatting about it, it's like, someone asked a question years ago of like, what if Fauna shuts down? What happens to my project? And today, you've got 60 days to migrate it. It sounds like whatever happens to Workbrew in the future, like you could still have an experience that mirrors what's happening in open source. Yeah, I mean, kind of like the underlying architecture of Workbrew is the foundation is Homebrew. So to the extent that something that our customers need lives in Homebrew, we get it into Homebrew using the normal Homebrew open source process. We'll make a pull request, somebody will go and send it, and we make sure that it's valuable to every user, you know, as many users as possible of Homebrew. And then with those kind of underlying, you know, functionalities, we can build on top of it. So for example of this, Homebrew has this functionality called taps. Taps are libraries of collections of packages you can install. And there are two official taps in Homebrew. Homebrew core and Homebrew cast with about 15,000 packages. When Mike was talking earlier about, you know, some human review going into each of these, you know, that's because the Homebrew project manages those taps. But anybody can create a tap. And so, you know, we built some functionality that lets companies create their own taps and distribute those taps without having to manage authentication, for example. We also built some functionality around giving companies visibility to what taps are in use so they can find out if anybody's using an unofficial Homebrew tap. Maybe there's some software that they're not happy that is being installed, they can check And they can also put guardrails around the process for adding new taps. So by default, the Homebrew core and Homebrew cast taps are enabled. And if you want to add additional taps that are through parties, that might need to go through a review process before they get added for everybody in their company. And so all of that functionality, what's great about it is that it lives in Homebrew as part of the Homebrew configuration. You go to the Homebrew man page, you can read about it, you can use it, and you could build your own control plane for that stuff. We at Workbrew have built a control plane that uses those things, and you can buy it instead of building it yourself. Cool. Thanks for the clarification. And at this point, I want to wind the conversation down and move us into reads. So a question for John and Mike. Are you ready to read? Of course. Let's do it. Reads. Excellent. All right. Well, John McBride, you've got some reads. Do you want to walk us through this? Yeah, sure. I got two reads this week. GIMP 3.0 is finally released, which is kind of insane. I think this thing has been in development like five some years or something. But this is pretty big, especially for anybody on desktop Linux wanting to modify photos or I'm sure anybody out there who wanted to avoid the belly of the beast doing Adobe Photoshop or something or Adobe Cloud now or whatever it is has used this. So more modern design. I'm just excited about it. It's going to be great, especially when I reboot up my desktop Linux. John, Mike, have you guys used GIMP in the past? Of course. A little bit. Not a ton, but I used to run desktop Linux back in, I don't know, college. So ever since I got a Mac, I stopped using desktop Linux. Yeah, that's fair. The other one I've been using recently is Pixelmatter Pro, which actually was acquired by Apple. Oh, I use that quite a lot. Yeah, they were acquired by Apple, so good for that team. Really excellent piece of software. So yeah, excited to see this space moving forward and yeah, some cool stuff happening. I was going to say my GIMP experiences, my previous avatar on GitHub was like a cartoon of me. I made that in GIMP in college because my serial cracked Adobe Photoshop that I had back in the day no longer worked. And then I found out that GIMP was a thing. So earliest version of GIMP, I thought I was going to be a graphic designer and I was a heavy user. Interesting. Yeah, yeah. It's a good piece of software. It's one of those that I feel like, yeah, everybody touches at least once in their computing lifetime. The other read I had this week was very interesting, especially from, you know, work I've done in infrastructure and Kubernetes, as well as some of the AI stuff and AI engineering. This piece is titled, FOSS infrastructure is under attack by AI companies. I thought this was especially interesting for John and Mike. Kind of TLDR this is that, you know, a lot of these companies going and scraping data just across the internet, you know, this isn't new. But it seems, at least from what a lot of these FOSS free and open source software sites, you know, they're like ignoring robots.txt and just like scraping and scraping and scraping and bringing down infrastructure that is probably just like somebody's home lab in their office. So, nothing that can really sustain a lot of scraping. I'm curious if you all have seen anything like this on, you know, things like getting scraped off of Homebrew taps or even sites that you maintain or homebrew.org, you know, having anything like this happen. Curious if you've seen anything like this. So, this is a nice, another maybe design principle of Homebrew is that Homebrew has no hosting, basically, anywhere, right? So, everything that can be done for free in Homebrew and done on GitHub pages is done there. The Homebrew, like, JSON API is actually hosted on GitHub pages. If you want to see using liquid rendering to create a JSON file and watch the parser crying while it does so, I would recommend checking out the Homebrew site for that. But, yeah, so as a result, like, we're fairly unaffected by this stuff. I guess as an anecdote in the other direction, like, when our tooling gets flagged for this stuff, then we try and be very communicative with development project. And if they're like, hey, please don't do this, then we're like, okay, well, we won't do this or we'll change our rates or whatever. Like, yeah, it's, I don't know, it feels like a sad indictment of the modern internet that we've decided to just ignore these types of conventions, right? Yeah, I agree. It's, I don't know, I don't know what the future of this is going to be. Further down in the post, they talk about embellishing robots.txt with AI.robots.txt. And, you know, starting to build in some, like, more features. And, like, some of the things that people have started doing basically is adding more of these, like, CAPTCHAs or, like, more obnoxious and difficult CAPTCHAs, which just kind of makes the internet worse to use as a person, right? That kills the experience for the end user. That's why we can't have nice things on the internet. Basically, anytime anything is nice, it gets, you know, tragic, it's a commons. People just take, take, take, take, take until it's not sustainable. Yeah, we'll put this in the show notes. Definitely get this one read. Cool. I have a quick read, which is kind of related to the GIMP thing. I was looking at X, it was an X.com thread of the Gemma 3 model is now taking out the Shutterstock watermark, which is like, again, going back to my college days, like, this is a dream of mine. To be like, hey, can I use this image for free? Folks listening, please pay for your content. Please don't steal. But college, Brian, would have loved this experience. You also had cracked Photoshop. Is that what I heard? Yeah, it was a, it was dark times. You know, I was, I was in college on scholarship, didn't have a lot of money. So you had to, you know, it was a wild, wild west. If you think it's bad now, back in the day, like, let me show you some bear share and LimeWire and Torrance. Yeah. This actually reminds me of a story I was listening to. It might have been on Hard Fork, but it was something about how Chegg, the cheating website, they're like suing Google because, you know, now, you know, Google AI results can just give you a bunch of stuff that they scraped off of Chegg, essentially. Which is like, it's kind of hard to feel bad for them. Like, okay, Chegg, like, maybe, maybe that wasn't, I don't know, I say that now, but, you know, I'm not deeply familiar with their business model. Is that kind of a similar thing, Brian? Quick correction. Like, I don't think Chegg's business model is specifically cheat on your test in your college work, but that's what people use it for. Okay, my bad, my bad. Just saving ourselves from the legal blowback from the Chegg team. So is this Shutterstock thing kind of similar to that where, you know, there's an impending, I don't know, legal suit against, you know, AI use on these things? I imagine, like, we saw with Reddit and also with Twitter slash X, they kind of put a block on, like, API usage and how much data you can take off the platform to then turn around and be like, no, we have our AI solution for Reddit and Twitter and Stack Overflow and et cetera. So it makes sense because, like, in the world of AI, like, the data is the most expensive part, or sorry, the most valuable part, rather. And, like, we're going to have these guardrails and these weird GDPR cookie banners and stuff like that inside of our open source projects to prevent things like this. Like, I don't know, like, we're going to be looking at the old times and, like, thinking very fondly. I don't know, this is a weird therapy session on this podcast, but I remember back in the day, like, we had cable TV, and you get this, I don't know if it was like this in the UK, Mike, but you get the scrambled pay-per-view channels. So I remember, like, you can get the audio of, like, the World Rumble, like WWE, but you couldn't actually see it. It was like, you'd have to get a de-scrambler. So then I'd be, like, on the forums and trying to find out how you can de-scramble your cable TV. So, again, we're always going to find a way to work around things. Folks, pay for your cable, pay for your whatever your streaming service is. I'm, like, implicating myself. I'll need a pardon from Trump pretty soon. The thing that gets me about this is, like, again, this is another case where, like, the end user, like, loses. So you mentioned, you know, the CAPTCHA is being added, API access going away. Like, you know, I'm a Reddit user. I read a lot of stuff on Reddit. And I used, like, you know, a Reddit mobile app. And when they had their whole kind of API change-up happening, and it took away all the access, all the apps died. Luckily, I don't know how, but the app that I use managed to survive. I think I'd pay, like, a dollar a month to use it for just, like, Reddit's API access or something. But, you know, ultimately, what ends up happening is you take away those things and the engineers, you know, people building all these nice little apps, like all the moderators. Like Mike mentioned in Homebrew, like, they automate everything. And these massive communities with hundreds of thousands, if not millions of subscribers on Reddit now lose access to all their moderation tools because they take away the API access to prevent data, you know, going to the AI companies. Like, it has knock-on effects for everybody, so. Well, I appreciate both of you coming on, chatting about Workbrew, Homebrew, open source, and even some banter in the reads as well. So, listeners, stay ready. That's all the time we have for today. If you're interested in being a guest on the show, or if you'd like to suggest a topic, find us at x.com slash open source ready. Open source ready is brought to you by HeavyBit, the leading investor of developer-first startups. For more information, visit heavybit.com. .

This week's episode of the Mac Admins Podcast is brought to you by Kanji. Imagine an AI assistant that speaks your language and knows your Apple fleet inside and out. Meet Kai, Kanji's groundbreaking AI assistant for device management. It can give you insights on the state of your devices in Kanji in response to conversational questions. You can ask Kai anything, which devices don't have FileVault enabled, or how many iPad devices have been updated to iOS 18. You will get immediate answers and custom reports built for you whenever you need it. Kai empowers every team member in IT with analyst-led insights, freeing you from more creative and strategic work. You can request an invitation to experience Kai at kanji.io forward slash Kai. That's K-A-N-D-J-I dot I-O forward slash K-A-I. Thanks again to Kanji for sponsoring this episode of the Mac Admins Podcast. Hello and welcome to the Mac Admins Podcast. I'm your host, Tom Pridge. And Marcus, is it snowing where you are or is that just me? It's definitely just you. It is most definitely not snowing. I am wearing shorts, which doesn't happen very often. Oh, you lucky, lucky, lucky man. I don't know. It is freezing here. I may be lucky that people who are seeing my knees, not so lucky. Well, fair. Small price to pay. So what's it like where you are, Tom? Well, so I'm up in the mountains of West Virginia. And the state motto here is, of course, wild and wonderful. And I will agree with the wonderful part. Maybe the wild part. Okay. Maybe a little bit less. We've gotten about six inches of snow, which I understand doing the metric math is like 15 centimeters. Does that sound close to right? It's a fair amount of snow-ish. It's more snow than I have. And yeah. And so I was going to say, it has caused me to still be here. We'd intended to leave this morning and go home. And I'd be recording this from the studio. But with the snow coming and the snow coming a lot, I was going to say, we've gotten that six inches of snow in the last three hours. Roads being what they are, we decided to stay up in the mountains another day. So I was going to say, the conditions for sledding are incredible. I even attempted skiing and didn't die, for which I think a lot of people are both, one, surprised, and two, a little grateful. But I was going to say, it's the winter holiday season here. We're having a blast. Awesome. Well, I'm just trying to think of a segue to go from skiing and snow into software bill of materials. And I think that's about as good a segue as I can do. I think we have done that as about as good a segue as we can come. So we've got two incredible guests this week. Our friends from Work Brew are back. John Britton, Mike McQuaid, welcome back to the MacAdmin's Podcast. Thanks for having us. Thanks. And so it's been a little while since we talked. We talked last in March of 2024. How have things been going for Work Brew? You guys have really made a splash over the last year. Yeah. I mean, we've been incredibly busy, hard at work. Kind of the biggest news that we have is a couple of months ago, back in November, we launched Work Brew 1.0. We have a slew of new features, including a free plan for unlimited devices and unlimited features, which gives Mac admins the easiest way possible to deploy brew to every device in their fleet and get full visibility into all of the packages that are installed. And, you know, today's topic, SBOM, software bill of materials, knowing what's installed on your devices is pretty important. So we're really excited about that. The other big announcement that we made back in November was our seed funding. So we raised $5 million in seed funding. And just last week, we completed our SOC 2 Type 1 certification. So we're, you know, coming along really well. The team is growing. So that would have been easy, straightforward, I'm guessing. Everything I know about SOC 2 compliance, it's just a walk in the park. I'd actually let Mike comment on that. Yeah. I'm the one who did most of the legwork on that. It was, you know what? It was not as bad as I was expecting it to be, put it that way. And I felt like I learned some things through the process. So there we go. That's the, yeah, I guess. Congratulations. Yeah. And last time that we spoke with you all back in March, we were kind of in a position of private beta. We were working with early customers that were just really trying to get feedback about how they're using brew and what kind of help they needed. And we've really kind of gotten to a rhythm with our customers and found that, you know, there is a problem here. We kind of understand it pretty well and we're able to give people solutions that they're looking for. So that feels really good. You know, when we were talking last time, it was still kind of a nascent idea of like, what exactly is this thing? What are people trying to do? So that's been really great as well. I don't know if Mike, you want to share anything about some of the developments on the product side, you know, stuff that's new, but, you know, that's kind of where we're at now. I mean, on the product side, we're basically just continue. The nice thing about being a small company with a small but very effective team is we ship features very, very quickly, which is very nice. It's nice to be able to be so responsive. I guess it's this nice, what do you call it, mutual cycle in software development as we've got more customers and people getting interested in people using it, like the product gets better. We listen to feedback. We fix things. We improve things. There you go. So, yeah, I guess at the higher level, we're just essentially like exposing more of the parts of kind of working with homebrew that people maybe aren't aware of. Like there's these things called brew files that we kind of essentially it's a way of kind of dealing with homebrew in a more declarative fashion where instead of saying brew install this, brew update this, whatever, you can say, okay, here's the state I want to be in and then let homebrew figure out how to do that. So, we found that's been quite a nice match. We call that kind of default packages. So, you can go and assign, okay, these particular machines, I want to have these packages installed and these services upgraded and commands run and stuff like that. So, that's been kind of one of our bigger features that's been released more recently on the workbrew side. And, yeah, on the homebrew side, it's the normal kind of we've had since we were last on the podcast. We've got macOS Sequoia. I'm sure you folks have talked all about that. So, yeah, so not too bad on the homebrew side. Getting a few bits and pieces working there. There was some usual Apple fun on the workbrew side where some documented stuff. I'm sure a bunch of listeners to this dealt with this as well where they had a UID range that was supported for creating groups. And then in Sequoia, they changed the range and some commands output the old range and some output the new range. And, yeah, that was a lot of fun getting that all smoothed over. But, you know, we're in a good place now. And, yeah, just various security and performance improvements on the homebrew side as well. Those are two big focuses there right now. My Sun Scout Trooper would refer to that as type 2 fun. You know, not the easy, you know, enjoyable type, but the type that is fun in retrospect. You know, the other thing that I think would be really super interesting to hear is that, you know, the last time we talked, you guys were both new to the Mac admins community. You've had a really busy year this year. I think we ran into each other at Penn State. You know, I heard you were at Mac DevOps. How has it gone being part of the community over the last year? So I have a long background working in kind of developer communities, mostly on API-focused products. And I've been in this position before of being kind of the new entrant into an established community. And I have to say that the Mac admins community is outstanding in its level of being welcoming and kind of the infrastructure that you all have built. Just having the foundation is very, like, so helpful. There's that Mac admins Slack channel. You know, our kind of entrance into this community was last March when we joined the Mac admins podcast. And every single one of those events that I've been to, I've had dozens of people come up to me and just say, hey, we heard about you on the Mac admins podcast. It was really great, you know, to have that interview and to chat. And I just can't say thank you enough to, you know, all of the individuals in the community, but also all of the organizers and the people behind kind of the foundation that make this community thrive, you know, so well. You know, as you mentioned, I was at Mac DevOps Vancouver. I was at PSU. I was at JNUC. And the other thing that I came to conclude is that there are so many great events that it's actually impossible to be at them all. You know, some of them are happening at the same times on the other side of the world from each other. And so, yeah, we're really enthusiastic about being part of the community and participating in any way we can. And it's been outstanding. The thing I found sort of fascinating and very enjoyable as well is, I guess, like John, being in a bunch of communities over the years, then the really nice thing about the Mac admins community is it seems like it's actually one community rather than, you know, in so many of these ecosystems, it's, you know, you've got the Jamf people over here or the Kanji people over here. And they don't really talk to each other and they're all using different tools. And I feel like it's a really nice, like, sign of this community of how much everyone seems to share information across their different parts of the ecosystem. But it's kind of in one place and one group of people who identify in the same sort of way. So what you're saying is we need a good schism to sort of separate the community and create tension and all of those sorts of things. No. Yes. I've definitely seen that happen elsewhere. But when the Mac admin Slack came out, there was a real moment there where people were insisting that IRC was the way to go. And it looked like there was going to be that fragmentation. But it's been fantastic to see that pretty much everyone has come along for the ride and stayed, you know, we argue like cats and dogs about everybody's particular opinions and choices. But I think we're drawn together because we enjoy that arguing rather than thinking that it divides us. Our love for insisting that we're right and everybody else is wrong is probably what brings us together. Love to hear it. So we're here to talk about software bill of materials today. So do you want to give us a basic primer on what an S-BOM is? I'll take a stab at this. So, you know, for me, I think that the kind of high level view of what a software bill of materials or an S-BOM is, is kind of like, if you use an analogy, the nutrition facts on the food you buy at the grocery. It's a index key that tells you what comprises the software that you're consuming, producing, distributing, selling, whatever it might be. And it's really valuable because it gives you, you know, insight to know what exactly the components are. I mean, you know, we're both from kind of the open source free software, you know, background. And one of the kind of key benefits of using open source or using, you know, free software is that you can see what's inside. And it's a fact of life that you can't always see what's inside of all of the software that we consume. But with S-BOMs, we can kind of help to surface some of that stuff so that you have a better way to know what's going on, what comprises it. On the, like, more technical end, I think there are, you know, there are various different formats and there's different kind of, you know, requirements of what they might entail. But I think that's a good high level view. And so, really, it's just a listing of applications or binaries that might be part of those applications. So, hey, we're using these developer tools. These developer tools also include things like curl and, you know, an SSL or an SSH config and an SSL config and, you know, a bunch of other different pieces of that that are underlying tools that represent part of that. Does that seem pretty fair? I'd say so. Mike, what do you think on the, you know, depth of S-BOMs? Well, I think the interesting thing with S-BOMs is, like, John's done a great explanation already of almost what they are and how they look, you know, as a standard format. But I guess it's worth thinking as well, like, why, to take a step back, why do they even exist? Why do we care, right? And I think the open source example is a nice one to sort of start with, where, you know, if you're thinking of homebrew or a Linux package manager or whatever it may be, you can go and generally find some website or run some tool and be like, okay, this depends on this, depends on this, depends on this. And you see this nice little chain of, like, all the things that go down in the software, right? And unless you're actually, like, someone who's packaging software for a living, you might not really care about that list other than why does all this stuff have to be installed every time I want to just install the thing that I want to use. But it's thinking about, I guess, two big things would be, like, licenses and vulnerabilities. So on the licensing front, if you're using, like, essentially every company is, at this point nowadays, some amount of open source software, unless you're a hardcore open source licensing nerd, like I proudly am, you know, I'm from an era of open source where everyone cared about these things, maybe a little bit too much. But it's being aware of, like, okay, am I using MIT license software or BSD license software or GPL software? Is it GPLv2 or GPLv3? Because all those things, it may be fine for you to use all of those in your application, but all of them have slightly different requirements on what that means as someone who builds and distributes that application. So you need to be able to know, okay, what licenses am I using here? On the vulnerability side, generally, kind of vulnerabilities and versions kind of map one-on-one. And again, you know, back in the kind of pre-internet era where we're all shipping software on CDs or whatever, it was fine. You know, you picked a version of a library, you shipped that version, and unless people's houses are starting on fire, that's the version you should ship forever. Whereas now, you can't do that, right? You have to be keeping track of all the software, all the versions, all the vulnerabilities, and making, and if there is a vulnerability, being like, okay, what software versions that I have does that affect? Who do I need to notify? What do I need to do to change? What version do I upgrade to? How do I upgrade to that version? And all of this stuff. So basically, there's this kind of, the expression I would use is the software supply chain of this idea of this very large chain of software, all of which is kind of built on each other. And if you're a company, again, many, maybe even most software companies are building software that is used by other companies that use other software, so your vulnerabilities affect potentially other things up and down in that chain. So SBOMs are kind of a standardized way of essentially being like, okay, what's in my software? How can I tell other people what's in my software, and how can they find out? An efficient way for lawyers and auditors to monetize free open source software, I'm guessing, as well. I'm glad you raised the, well, because that's the other side of this stuff that is interesting, is that there's been, I can't remember who it was, I'm sure we could put it in the show notes, but there was an open source maintainer who wrote a post last year who said, I believe it was titled something along the lines of I am not your software supply chain, where it's like, hey, well, there's all these requirements and people are saying these are the things that kind of software projects need to do. But, you know, I do this in my evenings and weekends, and I have no interest in being your supply chain or providing your SBOMs or whatever. The nice thing is, over in Homebrew and Workbrew land, we have, you know, Homebrew, when you install things, you can get SBOMs for all the software you've installed, we kind of generate that for you. But then in Homebrew, obviously, sorry, in Workbrew land, like, we are more than happy to provide those levels of guarantees of like, and our tooling and our software exists to let you know, rot is running on your machines, what is the software that goes into building the software. So we are very happy to oblige when others may not be. Well, and I think this gets into a really interesting part of the questions for how what SBOMs are for, and how organizations need to think about them. You know, I was going to say, well, I was going to ask the very pointed question, how are organizations using SBOMs? And it feels like, you know, tracking, you know, the presence of software on your machines has one set of value, which is, you know, tremendous for a lot of organizations. But are there other utilizations that are super important for us to think about as we look at SBOMs generally? I think they've, they've essentially filled this hole as being a nice data interchange format, where because we have a standard way of defining this stuff, it basically provides people, I guess, Marcus mentioned kind of auditors, like, I think we're still in relatively early days of SBOMs, where I think the main thing they're being used for is this kind of idea of tracking, okay, what has gone into making this software that I have here. But over time, I would not be surprised if we're seeing more and more tools that essentially are using SBOMs primarily as their kind of import and output format, so that we can have a standardized way of saying, hey, what is the software I'm using and not using and all that type of thing. Because, so at GitHub, I worked a while ago at a thing called GitHub Enterprise, and they, as they went through their own compliance processes and stuff like that, they realized, hey, we need to provide an SBOM for GitHub Enterprise. And the nice thing about stuff like that is it's like a lot of these tools, day one, pretty much at Workbrew, I was, I installed all the same tooling that GitHub used. And then when we kind of went to raise financing and we had people who were coming and saying, hey, can you tell us what software you're using? Hey, we know this is probably going to take you a few weeks to give us the exact versions and everything like that. So no, no, I can do that for you in like two minutes, right? So that's the other side of this stuff, is it's one of the things, like many other areas of tech, where it's unfortunately going to become an additional requirement of how we build software. It's just getting this stuff sorted. And it's much easier if you get that stuff sorted earlier in the software development process, rather than later being like, oh, I have a thousand libraries, and I'm going to have to figure out a way to track them all and handle them all. Just for like an example of real world use case, you know, I talked to a lot of people in the Mac admins kind of role. And especially I talked to a lot of folks who work in regulated industries, healthcare, finance, insurance, government. And, you know, like Mike said, you know, licensing is a big part of it, vulnerabilities, but also intellectual property. And so I've seen these highly regulated organizations where they use SBOMs essentially as a filter list to permit or reject new dependencies from their software ecosystem that their developers might be pulling in, in an automated fashion. So they might know that certain libraries use IP that they don't want in their tool chain, or they might know that certain libraries or certain licenses are not allowed in their tool chain. And so they're building kind of automated tooling around this using SBOMs as kind of the underlying infrastructure as well. And I think we've seen as we're recording right now, we're in the midst of the TikTok apocalypse, which sort of highlights in a way that it's really important to know exactly what it is you're dealing with, with software, because there may, you may be using something that is not allowed in a particular region for, you know, political, social, whatever reasons. You know, CapCut is a great tool for, you know, social media video editing, which unfortunately, because it's made by ByteDance, means it's against the law to use in the United States as we record this. It's Sunday, January 19th. I'm not to put too fine a date on it, but, you know, we're in an evolving state of play, you know, with a lot of these licensing agreements. And so knowing what your, what your own SBOM is for your organization is very helpful when it comes time, when you have to deal with questions from legal or from security on, well, what part of this, you know, TikTok apocalypse is, you know, is going to affect our business? Are we going to rapidly have to retool? Are we going to have to, you know, figure out a new pathway for some of our social media editors, for example? A lot of organizations have one of those these days who may or may not be having to switch to iMovie or God help them clips. But, you know, there's, there are all sorts of, of ways to actually handle that. But also, also just not having to get dragged into lots of meetings about these things as well. As you just mentioned, the ability to say, oh no, we have all that information. We can give that to you is a lot better than anything. You know, getting invited to five discussion groups to work out how we're going to approach this problem. The MacAdmins podcast is brought to you by 1Password. Imagine your company's security for a moment. Think about it a bit like the campus at a university. Chemistry department over here, economics over there, and a big student union all surrounded by a quad. Those nice brick paths are your company-built infrastructure, like IT-approved apps and managed employee identities. But, of course, there's always a well-worn path outside those nice walkways, isn't there? A shortcut worn through the grass with a gap in the hedges that shows where everyone actually walks. Those are your unmanaged devices, your shadow IT apps, and contractor identities that don't quite fit the usual path. Most security tools only work on those happy brick paths, and a whole lot of security problems take place on the shortcuts. 1Password Extended Access Management is the first security solution that brings all the unmanaged devices, apps, and identities under your control. It ensures that every credential is strong and protected, every device is known and healthy, and every app is visible. 1Password Extended Access Management solves the problems traditional IM and MDM can't. It's security for the way we work today, and it's now generally available to companies with Okta and Microsoft Entra, and in beta for Google Workspace customers. I've been a 1Password customer for the better part of a decade now, and I just can't imagine life without it. I just got a new machine for work, and it was the first thing I put on there after I got it. 1Password's award-winning password manager is trusted by millions of users and over 150,000 businesses from IBM to Slack. And now they're securing more than just passwords with 1Password Extended Access Management. Secure every app, device, and identity, even the unmanaged ones, at 1password.com slash macadminspodcast, all lowercase. That's 1password.com slash macadminspodcast. And thanks to our friends at 1Password. So, you know, we talked a little bit about the format of the object, you know, the SBOM itself takes on a specific format. What does an SBOM actually mean to a security organization in that state or to an IT team in that state? So the thing that I hear over and over again talking to IT managers and security managers is that one of the biggest challenges they face is disability, just knowing what's going on. And this can be true of, you know, your software dependency stack. It can be true of your endpoints. It can be true of your infrastructure. It can be true of your CI. You know, all the different components in your, you know, information systems, just knowing what's going on is an incredibly difficult challenge. And so what SBOMs do in some of those cases is makes it possible to just be able to know what the differences are, know what has changed over time, and manage that change, right? If you don't know what's going on, you can't manage it. You know, maybe this is a little bit tongue-in-cheek, but there is a bit of box ticking that goes on with this as well. You know, you often hear from the lawyers. You hear from the, you know, compliance or risk departments. And what it really is is it's just – it's a good practice to be able to know that you can answer the question if it's asked, right? And so, you know, like you were just saying before, that if the lawyers come to you and ask, like, hey, what's in this, is it a three-week ordeal for you to figure out or is it a two-minute kind of easy-to-do thing? And then I think, like, the actual use cases kind of fall into, you know, two buckets, proactive and reactive. So proactive is kind of what I was just talking about. It's like take your vitamins, know what's going on, be able to talk, you know, in an informed way about what's happening and monitor change. But then when an incident happens – so we've had numerous security incidents over the years. Like I think last time when we were on the podcast, we talked about the XE vulnerability. And, you know, with SBOMS, you can know what of your systems are vulnerable immediately and know how to respond to those things. So, you know, I think that that's a lot of how it's being used right now. And then I guess, like, kind of a third bucket is just inter-organizational kind of operations. So we have a lot of, you know, vendor approvals that we have to go through. Being able to say to another company that's a customer or a partner, you know, we know what's going on in our IT systems is very valuable. And it helps build trust between different organizations as well. What about – you know, we've spoken about software that's installed on your machine or libraries you're using. What about when the software is outside of your organization? So, you know, software as a service and SaaS tools. How does that affect SBOMS? I think it's one of those things where currently you're not generally in a situation where you can go to all of your vendors and be like, hey, I want to see all your SBOMS for everything you're running, right? That's not – I mean, that might be a world in which we get to. Certainly, I'm aware that the U.S. kind of compliance changes around the SBOMS and the kind of – at least the – I think, again, at time of recording, current administration's executive orders around this stuff mean that that might be a future we end up with. But I think in reality, it's more the stuff that they're trying to push is less the idea of we're sending these lovely JSON files to each other and more this idea of like, look, you've got to track your dependencies and licenses and stuff, right? You need to be aware, right? It's the type of thing of – again, to use a horrific metaphor, right? It's getting people to like, look underneath their car before they drive off to make sure there's nothing sleeping under there. Not because they're like, there will always be an animal sleeping under your car, but the idea of like, if you look, then we're going to avoid some problems, right? For every 10 people you make look, maybe only one of them needed to, but they're going to solve these things. And again, I think it depends on the part of the ecosystem you're in because, again, from – if you're in open source land and GitHub land and all this type of stuff, then it's like, hey, we've got – using Homebrew as an example, right? Like Homebrew has – itself doesn't generate sbomb files for the application itself and what goes into Homebrew. But we have, okay, here's our gem file.lock because we're in Ruby land or package.json for NPM-related stuff. Then we have Dependibot, which goes on a daily or weekly basis, like checks all the versions and updates them to the newest version and submits a pull request and then submits emergency pull request if there's a security vulnerability. And that's all hooked up to people's compliance databases and stuff like this. So I think, like, sbombs are part of that piece that fits into that wider ecosystem of basically being like, hey, make sure you're doing all this stuff properly. Make sure, as I mentioned earlier, you're aware of your licenses. Make sure you're aware that you're not running on some horribly unstable version of something. Or make sure that when you do get some vulnerability in XZ, we mentioned before, like iTerm, I think that was a relatively big one in the last few months, that you know how to be able to say, okay, I know what version I'm on. I know who's running that version. And I can get my whole fleet updated sooner or later. And I think that's when it comes increasingly more over to, like, Mac admins on IT folks is, again, it's less about sbombs in the file format, but more about, like, okay, thinking about the software that you're providing on your systems and how you can kind of keep track of that and keep everything up to date. Well, in that vein, right, like, if we're really supposed to be thinking about what's on our devices, if we're supposed to be thinking about, you know, what's the version that we got, how did it get there, all of those things, what kind of things should Mac admins be asking vendors, for example, when they're adding new software to be ahead of these kinds of security challenges? Because the last thing you want to do, I mean, anytime you add to your sbomb, it's one more thing you've got to keep updated. It's another thing that you've got to keep aware of. It's another thing that you've got to kind of, like, have in the back of your mind as part of that process. So what kind of things should you be asking your vendors in terms of, like, hey, how do you guys build what you build? I think what you want to be, you know, rather than a specific question, you know, hey, ask these two or three questions, it's what you need to evaluate, right? And what you're really evaluating for is maturity of software or supply chain management, right? So if you're evaluating a vendor and you want to know, you know, is this a vendor that I can trust, it's not as much do they use this format or that format, do they use this tool or that tool, but do they have some rigor around how they manage, you know, what's in and what's out in their systems, whether it's the software that they build or their endpoints or all those different things. And I would also, you know, add to that, that it's not just about the vendor, but how does it impact your software supply chain management, right? So what's your process? And I've talked to, you know, folks in all different kinds of organizations from, you know, small startups to Fortune 500s to regulated businesses. And they all have different, you know, needs and different requirements around what level of management they need in this stuff. But, you know, at a base level, it's things like, do you know, do you track, you know, what components are being used in your projects, on your endpoints and whatnot? Do you have any way to cross-reference that with vulnerabilities? Are you able to respond to vulnerabilities and in what timeline, right? Unfortunately, many of these conversations I have with, you know, folks who are interested in Workbrew, they'll come on and they'll say, you know, our process for a vulnerability happening is we heard there was vulnerability. We go into Jamf, we write some custom script, we deploy it to all our devices, we run it. That script tells us with like a 90% confidence whether or not any of the hosts have the vulnerability. And then we have to, you know, build our own kind of process for patching it. You know, in the more sophisticated places, they might have another tool that they use for patching. But, you know, you want to be looking into how do they manage responding to those vulnerabilities. And then also kind of the last thing I would think about is, is there a process for accepting changes into your software buildings, into your supply chain? That doesn't mean that every company needs to have a process that's heavy-handed, that involves lots of paperwork. But I've spoken to some organizations where they essentially warn all of their software engineers. They say, hey, look, we care a lot about, you know, what goes into our product. We want to think twice about introducing new dependencies. Whenever you add a new dependency, we want to make sure that you do these evaluations. We leave it up to the software engineer to do the evaluation, but they train them on how to evaluate software to make sure it's a good dependency. You know, some heuristics you can use when you're evaluating the software is how frequently is it updated? Are there any known vulnerabilities? When those vulnerabilities happened, how long was it before a patch was available? And this is something that your team can do as they're introducing new software into your, you know, into your organization to evaluate it. And so going back to your original question, it's like, what should we be asking? I think it's what, this is how you should evaluate this stuff for a potential vendor that you're bringing in and also how you present yourself to others or how you manage your supply chain. So let's turn to WorkBrew now. So how does WorkBrew fit into this world of SBOMs? I think there's two ways of looking at how we sort of fit in. So one is the, essentially, the kind of homebrew side of the equation. So if you're someone who either themselves or people in your fleet that you're organizing as a Mac admin, you have anyone running homebrew, then essentially, all this conversation we had before about, okay, what versions are people running? How do I upgrade them? What do I do with this vulnerability? How do I know whether there are vulnerabilities? Essentially, WorkBrew just solves that for you, right? So we give you all the packages you've got on all the machines. You can see them in aggregate fashion. You can see what are the known vulnerabilities that we have from the kind of special vulnerability data that we pulled from many sources and mapped to homebrew applications. And then you can upgrade all those packages and all those machines in a single click. And coming fairly soon, like, you can just say automatically, if there's a vulnerability of this level or whatever, I want you to automatically upgrade on those machines. So that's one side of the equation. The other side, I guess, is what John was saying about, like, if you're an organization thinking, what is even your process, right? Like, to upgrading things. So it might be that you deal with some great vendors and they are just like, oh, yeah, whenever we have vulnerability, we'll just push you out and auto-update. And that will auto-update on all the machines and no one will be able to use the application until they have auto-updated if it's critical vulnerability or whatever. Wonderful. Or it might be you have some vendors who they don't have a built-in auto-updater. You had to do some use auto-package or whatever to repackage it in a way that works for you and all this type of stuff. And then all of a sudden it becomes, oh, like, this is maybe a multi-day effort when we have some critical vulnerability. And Workbrew can help you on that side by almost essentially pushing more of this stuff through Homebrew. So you could use Workbrew to distribute more of this software so that essentially then if you're distributing the software on the machine, you know, even stuff that we might not associate with Homebrew like Visual Studio or Google Chrome or whatever it may be. And that's a way of installing these packages. Then you can use everything I said before, get all the information you want from Workbrew, get all the packages and stuff like that. And then when you get a vulnerability, you can then push that out and upgrade all your fleet in a way that is as simple to do as it would be with any other Homebrew package. This week's episode of the Mac Admins podcast is also brought to you by iAmazing, the world's favorite iPhone manager. Have you ever felt your MDM configurations leave much to desire when setting up fleets of iPhones, iPads and more? Say hello to iAmazing Profile Editor, the smarter way to take control of your Apple device configurations. Navigate the most extensive Apple settings catalog effortlessly with an intuitive graphical interface and powerful deep search. Ensure your configurations are tamper-proof with built-in profile signing. Deploy with confidence, backed by extensive in-app documentation and integrated validation tools. Take your device management to the next level with iAmazing Profile Editor, the free, powerful tool from the iAmazing Enterprise Suite. Download it today and experience the difference at iAmazing.com slash profile hyphen editor. With Workbrew now out of beta and into 1.0 land and beyond, you've got a bunch of new integrations that are out. You know, as I was going to say, I looked and saw a couple up on your website. So what can you do with Workbrew through these integrations for, say, mobile device management and other tools? Yeah, so the first thing I would say is that there are two different kind of levels of MDM support that we have. The first thing is when you deploy Workbrew to your fleet, you can deploy it with any MDM. If your MDM is capable of deploying a PKG file, you're going to be able to deploy Workbrew with it. We do have a deeper integration with several MDMs, Jamf, Kanji, Fleet, and Simple MDM, where we do inventory management through the MDM as well. And I expect in the future we'll be adding additional functionality that we'll be able to pull from your MDM. But for now, it's inventory management. What I mean by inventory management is that part of the story of Workbrew is we want to give you the easiest way possible to deploy Brew. Whether it's your developers or other end users who you want to have a standard way to deploy and deliver software and update and patch. Or if it's you want to give your software engineers the ability to pull the dependencies that they need. We've heard over and over again from Mac admins that it's challenging to get Brew out onto the fleet. There's lots of different ways to do it. There's the famous GitHub gist that lots of people use as like a Jamf policy. And we really just want the best and easiest way to install Brew to be with Workbrew. So you take the Workbrew PKG, you put it into your MDM, everything's up and running. And add to that, you get full visibility into everything for free. Unlimited devices, unlimited users. Now, on the deeper integrations, the inventory management, playing along with that keeping it easy, we don't have end user accounts for the people who have the devices. So the only people who get Workbrew accounts are your IT and security folks, the people who are managing Workbrew at the company-wide level. And what this means is that there's no sign-up process for your end users. There's no login process. There's no fiddling with keys or anything like that. It's totally transparent, very, very easy to get them up and running. But also for admins, it's not that easy to manage a fleet of devices. And the more devices you have, the harder it gets if you just can look at the serial number. And so what we've done with the deeper MDM integrations is Workbrew will pull all of your inventory data based off of serial number from your MDM. So when you get up and running, you can install on hundreds or thousands of devices in an afternoon and have full visibility and know which device belongs to which person. So that's some of the MDM integration that we have right now. We have had some requests about integrations, mostly around sharing data to third-party kind of integrators. So that's like we want an integration with Splunk or we want an integration with some other logging tool or alerting tool or pager duty. And so our answer to that has been that we built a data export feature that has, you know, JSON and CSV and, you know, different format support. And we've also built an API that, you know, we have web hooks and we can send events out to those users. So, you know, there's a little bit of self-service around some of those integrations, but we have an answer to some of that now. And so where do folks go if they want to request an integration, like, for example, with another MDM that isn't currently documented or part of the product? What's the best way for them to speak to someone about that? Absolutely. So if you go to our website, we have a page that is called Works with Workbrew. So it's just workbrew.com slash works dash with. And from that page, you can see all the integrations, but you can also request adding a new integration, whether that's, you know, if you're a representative of a company that would like to integrate with us, that's a great way to get in touch with us to do that. Or if you're a customer who would like to see an integration added, you can. I know, for example, there are several product managers. There's some MDMs that listen to this podcast. I would encourage all of them to give you guys a ring. We'd be happy to talk to them. Because I think that there's a lot of deep. Now, are they happy to talk to you? I was going to say some PMs are very, very closed about their roadmap. And I totally get that. I can respect that. But I would definitely consider folks interested in that. One of the things I think I'd love to ask around, you know, Brew, generally speaking, is that we think about it for command line functionality. We think about it for tools like Carl or, you know, SSH or any number of other things along those lines. But it's not just for that, though, is it? It's also for applications? Yeah, I think Mike is probably the best person to talk about this. He can talk about the difference between formula and casks and kind of how all that stuff fits in. Yeah, so this is actually a nice trip down history lane in some ways for Homebrew. Because Homebrew started off supporting just, it was focused primarily on command line interface tools or, like, databases or whatever stuff. You're going to run, install in your terminal, run it in your terminal. And eventually someone kind of thought, hey, like, this seems like a nice way of installing, like, potentially other software as well. So they made this little thing called Homebrew Cask, which was, like, an unofficial, like, third-party thing. And over time, like, more and more people ended up using both, basically, and then we integrated it in. So now, nowadays, Homebrew has all the kind of beer methodology. Some people hate it, but we're, in some ways, we're too far down this rabbit hole to ever see the light of day again at this point, unfortunately. So Homebrew has formula, which are, I guess, in the beer metaphor, you know, the formula. Because Homebrew was originally building everything from source. That was your idea of almost, like, the description of how the beer is made, the description of how the package is made. So, like, you have formula, so that's how you install your CLIs, open-source software, or whatever. And you have casks. And casks are this idea of, like, wrapping software provided by a third-party vendor. So that could be anything from 1Password, Google Chrome, VS Code, whatever. So the nice thing about casks is some people might be like, okay, well, okay, I can just install all that stuff outside of Homebrew. Yeah, like, if I want to install MySQL and it's got, we mentioned dependency earlier, like, 20 dependencies. Okay, I'm not going to go and manually download all this open-source software and build it from scratch on my machine. But, like, I can just go to, you know, the Google Chrome website and click a few buttons and have that installed. And that's great. I imagine, you know, this is the Mac Edmonds podcast, after all. I imagine the Mac Edmonds amongst us are already thinking, like, well, actually, like, you kind of want to be able to automate that stuff. And really, we want a PKG file and all this type of stuff. And basically, that's essentially what casks give you, which is the way I like to look at it is the brew install Google Chrome that you can do, for example. Essentially, you now have one API to install 10,000 pieces of different software, right? You want to install 1Password, you want to install Cursor, you want to install whatever it may be on your machine. You can essentially do that all through the same interface. And we mentioned earlier the kind of brew files, brew files, they support formulas and casks and various other bits and pieces. You can actually even install stuff from the Mac App Store through there as well. So what this means, if you kind of join all this stuff together, if you're someone who, like me, is obsessed with automating everything, perhaps unnecessarily to high degrees, then you can have, like, one little file, which I have, which essentially describes all the software that's installed on my machine. And if I were to throw my MacBook out my window, and you give me a new MacBook, I would have all that software installed on my machine again, probably within about 10 minutes. Because it's all using Homebrew or the Mac App Store or whatever, and you can automate it and describe, here's everything that I want to be installed. And obviously, from our perspective in Workbrew land as well, we see this as being a huge opportunity for people who are deploying software across many, many different machines and fleets and customizing things per users. Because, okay, it's nice for Mike to have highly optimized a process that every two to four years saves me a couple of hours of my time. But if you're doing this on 100, 1,000, 10,000 Macs, and you're having to define the software on each machine in a different way, and you want it to be up-to-date, then I personally still think there's no better way of doing that than with Homebrew. Well, yeah, and getting to brew files, I mean, you know, I say this because I'm on an iPad this week because I baptized my laptop unexpectedly this week. And so it's off at Apple being repaired. Boy, you know, the thing I, the genius was like, you know, hey, do you have a backup of your data? And I was like, yes, and I still don't necessarily want to have to reprovision my entire device. So, I mean, if it could come back the way it went out, that would be amazing. But, you know, being able to know with some degree of comfort that between what's in my iCloud account, what's in Monkey, and what's in my MDM, I can deploy those things out and get into a state, a declared state of good operation is probably the most comfortable thing I could have said in that moment. I don't know what state my backup's in on that system because I haven't had to think about it in a long time. I'm going to care a lot about the restore when that machine comes back from Apple. But knowing that I could easily, you know, just get back the key resources because I know how to declare that state of machine compliance is so helpful. The other bit that I find fascinating, it's this intersection between, you know, to quote a certain tech luminary, the intersection between Mac admins and developers. And for Mac admins, the developers were always the, you know, the troubled child that you had to deal with because they had lots of very strong opinions about how their device should be set up, how it should be managed, wanting control for very good reasons often that, you know, they needed it this way to be able to work efficiently. And, you know, they have their people who are into automation and they need their automations that they have to work really well. So, having a way that Mac admins can allow the developers to have that degree of control, but then also providing back that visibility and certainty and also doing it using the tools that the developers trust and are familiar with. I know, Tom, I'm guessing you've had situations before where you've had to go and explain to developers, okay, so you're used to doing things this way. So, we're going to bring in these tools called something you've never heard of before that's going to look after that for you. And that always goes well, doesn't it? That's usually when the pitchforks and the torches come out of their desk drawer. I don't know how they keep a lit torch in their desk drawer, but they usually do. And, yeah, I was going to say showing up with an alternative package manager for, you know, for system use is, you know, usually the kind of thing that causes uproar, revolt, and possible deposition. For the stereotypically introverted folks, you can really bring developers out of their shell pretty quickly by suggesting something like this. Yes, you will definitely get to know everything about that developer very, very fast. You know, you say this thing that, like, you know, the developers are the problem, you know, the problem child in this relationship. We definitely have had a lot of conversations with, you know, IT and security folks. And what's great, what I love about this community is, like, you could have this mindset of it's such a pain. But actually, what most of these folks, the Mac admins have, is they totally understand that it's all about the productivity for the end user, and they want to give them the best possible solution. And it's really actually not, like, a big fight between them, even though it sometimes is presented that way. Generally, they understand and they want to give, you know, the best experience possible within the guardrails of what is legally allowed or what's within their compliance department requirements or risk department. So, yeah, it's just like another case of, you know, this community being great. Yeah, for me personally, I think the other thing is a lot of people in, on both sides, in the developer side of the Mac admin side, have been told for a long time that this is some sort of zero-sum game. And essentially, you have to pick between high levels of compliance and high levels of security or giving the developers everything they want. And I think, for me, with somewhat with Homebrew in the past and very much with Workbrew now, I guess I just refuse to accept that those things are opposing forces. I think you can deliver, which I think we have and are through Workbrew, the highest class of developer experience while at the same time providing absolutely everything the security and IT department need. And I refuse to see the idea that, like, one party has to lose out of this. And I think this is where I feel for both sides, because I think they've been put in these discussions where, in the past, they have had to pick a side and say, okay, either the Mac admin gets a bad time and the developers are allowed to run right using whatever they want, or the developers get told, hey, you've got all these projects you have to ship by the end of the year. And by the way, you're going to have to do it with one hand tied behind your back now. And no, we can have great tools that are, you know, world class from the security and developer perspective, I think. So it's a bit like the SBOM discussion that, you know, these, you know, arguments that we're set up to have can actually be, oh, yeah, that's a solved problem. We can sort that out. Move on. Let's now tackle operating system updates, because that's also a solved problem. Right? This week's episode of the Mac Ammons podcast is also brought to you by SmallStep. Remember Skep? Yeah, that tire fire of a protocol for device certificates. It's basically a password system for your devices. And we all know how secure those are, right? Not exactly the rock solid foundation you want for your company's security. But what if I told you there was a better way to lock down your company devices, a way to guarantee that only your devices access your most sensitive stuff, code, financials, customer data, the whole shebang. Enter SmallStep. They saw the limitations of Skep and decided to do something about it. They worked with Apple and Google to create a new IETF standard called Acme device attestation. This isn't just another security product. It's a fundamental shift in how we think about device identity. Acme DA leverages the hardware already built into your devices. Secure enclaves. TPM chips. Strong stuff. No more passwords. Just secure. Verifiable device identity. Imagine this. A new employee gets a laptop. It automatically enrolls itself. Gets the right certificates. Secure access to everything they need. No more Skep headaches. Just smooth, automatic security that works everywhere. macOS, Windows, even Linux. SmallStep makes life easier for IET2 with centralized management, automation, and seamless integration. Less troubleshooting, more innovating. SmallStep is the leader in high assurance device identity. They're trusted by companies of all sizes to protect their most valuable assets. Ready to take control? Visit smallstep.com slash macadmins and lock down your devices today. Thanks again to SmallStep for sponsoring this episode of the MacAdmins Podcast. You know, like a lot of new products, you know, early adopters oftentimes provide great feedback about additional functionality they'd love to see. What are some of the common requests that you're hearing from people trying out WorkBrew now? I love this so much. We get tons and tons of requests. And what's been great about it is most of it is in the same direction. You know, we get the same requests over and over and over again. So I'll start with a couple that we actually have already addressed. So one of the most frequent ones was default packages. Everybody had been asking us, hey, is there going to be a way that we can, you know, by default install these 20 packages on devices for our data science team or our customer service team or engineers or, you know, whatever group it might be. And like Mike was saying before, he built brew files into WorkBrew and you can do that. Another one that we got a lot was about an API. We have an upcoming, you know, API. I don't know. Mike can probably say whether or not it's shipped to production yet, but it's very close to being shipped to production if it's not already. And then on the upcoming kind of things that people have been asking about, automation is one that comes up over and over again. Right now within the WorkBrew product, we will service information to you in real time, but making changes generally requires human intervention. And that mostly comes from not wanting to disrupt the developer experience. We don't want a situation where things are getting updated under a developer's, you know, without them knowing just because an automation is set up. And so we want to give finer grain control around when those automations might run. We talked a little bit before about integrations. We've had a lot of requests for different types of integrations, whether it's MDMs or if it's, you know, logging tools or alerting tools or things like that. Another one is private taps. Oftentimes, so I'll start with what is a tap. In homebrew speak, a tap is a repository of packages that can be installed. So homebrew has two official taps, homebrew core and homebrew cask that Mike talked about earlier. Those are for open source tools and binaries provided by vendors that are managed by the homebrew project. But anybody can create a tap and make available any arbitrary software. And so when it comes to, you know, managing your software supply chain, taps are a very important part of that. You know, if you can insert whatever tap you want with whatever software in it, you don't know what might be coming in. And often customers will ask us for private taps and say, hey, we want a way to control what's going out to our endpoints. And they might ask for it for the wrong reason. They might ask for it because they want to limit the available software to those machines. But the real reason why it's useful is actually to distribute your own internal software. So a private tap is valuable. Say you have a bunch of command line tools that you've built for internal processes. You can put them into a tap and make them available to your entire organization. One of the challenges with that, though, is authentication to the tap. So let's say you're in an environment where you have 5,000 MACs. Every single one of those 5,000 MACs needs to have an authentication token that can connect to your tap to keep it private. And managing that is difficult. So with Workbrew, we're making a way that, you know, you can do that without having to manage the opportunity. And then the last one, which is the most frequently requested functionality, is an allow list. And I saved the best for last because I kind of wanted to tee it up for Mike so he can talk a little bit about, you know, kind of how we see allow lists with regard to developer experience. Because it's a very easy kind of knee-jerk reaction when folks see our product to say, hey, how can I make it so only the software that I want to allow people to install is available? And, you know, that's what people are asking for, but may not be actually solving the problem. So, Mike, maybe you want to talk a little bit about allow lists and what we've heard and what we've kind of come to. Yeah, so I think, as John said, allow lists are a very interesting problem because they seem like a fairly obvious thing, particularly if we're looking at it from a Mac admin perspective, right? Of, okay, well, I decide what is installed on my user's machine. I maybe don't give them admin rights or Mac App Store rights or whatever it may be. So, in that applications folder, I essentially have a allow list of the things that they have there. So, I just want to do the same thing for my developers using Homebrew, right? Easy. Unfortunately, not very easy because what happens is, I mentioned earlier, a good kind of introduction to this conversation when we're talking about SBOMs and you have these kind of dependencies that go all the way down. So, we have, you know, what we would in Homebrew call the dependencies for an application, which is everything that it relies on to get its job done. But then, also, those dependencies may themselves have dependencies, and we call that recursive dependencies because you end up having to recurse all the way down that tree. And then, you call the reverse dependence when you have something that has something that depends on it. So, it all gets kind of relatively easy from an allow list perspective if you assume, which is a reasonable assumption, that all software is static and you will only ever need one version for the rest of time. Sadly, the way that the software world works, and I say this particularly as someone who builds software, unfortunately, there is sometimes a need to release more than one version of a given piece of software. And when that happens, when you have this dependency tree, as I mentioned earlier, if you have an allow list, well, what happens when something underneath you gets updated? Because there's a critical update there. Do you say, okay, that thing can update and then nothing else can update? But then, that thing updating then breaks other things unless they also get updated. And then, some things have to be updated and then other things can't be updated. And basically, you end up with this kind of nightmare that keeps people like package maintainers and homebrew up at night of trying to figure out how to resolve all these things. And one of the nice things about being a homebrew maintainer is knowing that you are solving these problems for people in this way. So, essentially, what we've ended up with in Workbrew is that we get people who ask for the allow list. And what we talk about is, okay, like, instead of, as us technology people want to do, instead of, like, jumping straight to the solution, let's hear about what are the problems you're having, right? And those problems are like, well, we need to control, we need to know what people have installed, we need to have the ability to get them on the latest versions, we need to respond to vulnerabilities quickly, we can't just have everyone installing anything, we don't know what versions are vulnerable or not, we don't know what software is vulnerable or not. And we have generally found, like, if we can go to these people and say, well, actually, we can give you everything that you need, and that you want from an allow list, but without having to have the micromanagement that will involve for you with that allow list, does that solve your problem? And we're finding that that does solve the problem for those folks. And we're building it from that perspective. And again, this goes back to what I was saying before, where that idea of we say, okay, we either optimize for the security perspective, we have the allow lists, or we optimize for the kind of developer experience, and we let them install whatever they want. Again, I reject either of those poles of the spectrum. And I think that we can have something where everyone gets what they want here, right? But it might just be that it's not exactly what everyone went into the conversation thinking that they wanted. The challenge around allow list is when there's regulatory frameworks that think that they're a fantastic idea, and that they're achievable, which is also a fantastic idea. You know, I like to throw it back to people, we mentioned this before about feature requests, because it's not even just, you know, updating all of the tools further down the dependency list. It's also those dependencies changing. And so, see that feature request you had over there, would it surprise you to know that that required additional tools to be included to be able to achieve that? And so, the people, you know, who are saying we need this to be static and not to be changed are also the same people who like new things and additional functionality, because we're all, you know, wanting nice things. So, you know, being able to frame that in what's actually going on and how complex this is to achieve and why it's something that you actually need tools to help you make this a better experience, rather than just something you can tick a box in some sort of management tool and make everything stop. I think this is what I love about dealing with the Mac admins community here is that, you know, we in Workbrew and in Homebrewland have a reasonable amount of support on Linux and Windows through WSL. But, you know, Mac land is our, that's our original home and that's where we kind of take a lot of our ethos from, like Apple's way of doing things. And I think that's the nice thing about when you deal with Mac admins, because they get this, right, is that, like, it doesn't fly to say to your users of macOS, by the way, we're going to support macOS 12 for the next 10 years. And then in a decade, we'll evaluate which is the next best version of macOS. No, like, most of your users, most of the time, are going to want to upgrade their OS every year, right? And I've been in environments where the IT team or whoever's responsible for those macOS updates are saying, hey, you can actually kind of upgrade for the, you know, until six months after a major release is out. And anyone who likes Apple devices gets very grumpy, right? Because turns out you probably, as I have, bought on the hype train with various new features. And if you hear all the stuff about Apple intelligence and then say, oh, I now can't touch any of these features, even the purely on device ones that have no meaningful privacy implications. I can't touch any of these features for six months because a team over there says that I can't have it, right? Like, the best people I've worked with in this community know that, like, hey, you need to be able to provide this. Maybe not on day one. Maybe that's unrealistic in a large organization. But, you know, you need to be able to provide some of this stuff to the people in the timescales they expect. And I think that's what I loved about what you were saying there, Mark, is that I think that's the balancing out there is it's figuring out how can we give people what they want and at the same time meet all our regulatory requirements. Or you're like Tom, whose machine has taken a bath and he may have to get a new one. And the new one won't run Snow Leopard, sadly, Tom. You're going to have to take a step down in operating system stability and quality. Alas. Maybe they'll run Mojave. Maybe we can get a Mojave machine for me. So, what can we expect? You know, 2024 sounds like it's been a pretty big year for work, Bruce. So, what can we expect for 2025? We have a lot planned for 2025. You know, just going off of what we were just talking about with allow lists, the way that we're approaching trying to solve that problem on the product front is using approval workflows. So, rather than saying, here's a defined list of what's allowed up front, going back to the original conversation around SBOMs, the idea is that how can we help an organization have good governance around when they add things to their software dependency list, their software supply chain onto their endpoints, and make it so it's as easy as possible for their end users to do that within the framework that's set by the organization. So, as I had mentioned, you know, some of these organizations that we talk to, you know, have policies where they just have their engineers evaluate the risk and then accept it. And there's no formal process or documentation or anything around that. And so, I think that with Workbrew, we'll be able to help folks get a level of hygiene around managing their dependencies and around managing what they're installing on their machines very easily with very little negative impact on usability or developer experience. So, that's one thing that we're really focused on. Another thing that I think is going to be coming in 2025 that we're, you know, very excited about is more functionality for the developers. So, when we started Workbrew, you know, Mike's been involved in Homebrew for 15 years, more or less. And Homebrew is well-loved and well-liked. And so, we really set out to, you know, build the multiplayer features. You know, that's what Workbrew is. It's how do you use Homebrew, you know, for an entire team and also how do you make Homebrew more consumable to somebody who might not be an end-user developer and make it valuable to them. And so, I think in 2025, another one of our big focus areas is how can we build more functionality for teams that are using Homebrew that's more focused on the developer experience rather than on IT, you know, the Mac admin and the security experience, but also helping to improve that. And that will come with a lot of improvements on the free product as well. A couple other things that I've been thinking about, you know, I don't want to say that we're definitely doing this, but we've heard it come up quite a bit, which is, you know, what's the intersection of Workbrew and, you know, DevOps, configuration as code? As you know, we have default packages. They use a brew file. You know, there could be a world where we say, hey, the way that we handle some of this stuff is around using, you know, version control systems, using a code management system with those files and making it so that it's more of a configuration of code or DevOps operation. And then, you know, we've met a lot of folks in this community from MSPs and from other vendors, and so we're going to do as much as we can to get connected with those folks. So if you're an MSP service provider and you think this is interesting, you can always reach out to me and also, you know, kind of as we said before, anybody who's building an MDM or works with an MDM, we want to make sure that this tool works with them really well. And then lastly, I want to be at as many of the Mac admins community events as we can. So that'll be me. That'll be Mike. That'll be my co-founder, Vanessa. We have some new folks joining the team as well. So we're just going to be out there, you know, listening to what you all have to say and trying to, you know, help solve your problems. So you're going to aim for the Mac admins grand slam in 2025 of making every Mac admins conference around the globe? I don't know. Well, there's some of them that are on the same days. That's the problem. I can't get to all of them, right? I think it was, what's the one in, I think it's in Sweden? Yeah, Max's admin and JNUC were at the same time. Yeah, so I had the very hard choice that I had to go to one and not the other, and I really wanted to go to Max's admin, and I ended up going to JNUC. I hope that I can go next year. They're separate weeks this year, so you don't have to be Phil Collins at LiveAid taking a concord between continents. Continents to be able to achieve that. And I might suggest, Mike, I don't know if you want to add anything else on kind of the end user developer experience for 2025 or potentially anything related to Homebrew in 2025. I'll start off with Homebrew. I guess Homebrew has reached this kind of slightly funny place as a project where, like, every big feature that we've kind of talked about over the years, we've pretty much done them all at this point. So, essentially, my Homebrew product roadmap at this point is driven mainly off of people both on the internet and respected community members and nerd friends I have who send me things on iMessage of, like, what are their haters hating about the most, right? And generally, people complain about Homebrew being slow. So, that was one of our big focuses last year. It's going to be one of our big focuses this year as well. Like, we're going to try and work on more parallelization around downloading and stuff like that, which should make at least the experience of I install a thing and it is already a lot quicker. On the Workbrew side, John mentioned some of the kind of developer-focused stuff we're doing. It's still in kind of more experimental stages there. We hope to have more stuff to talk about kind of by the middle of the year. But, essentially, one of the main problems we're focusing on is, I mentioned earlier, kind of, you know, if you're in the Ruby ecosystem, you've got gem files and gemfile.lock. And if you're in the, you know, Node.js ecosystem, package.lock and all this type of stuff. Essentially, if you're working with Homebrew, I mentioned the brew files, but we actually unshipped the brew file, sorry, the lock file support in brew files because they were kind of complex because they were a lock file that you essentially were just telling you what the state was rather than giving you any ability to control that. And a big problem that we've seen a lot of folks in the developer space say is, like, hey, like, okay, being on the latest version of everything all the time may work for some people with Homebrew. But, actually, in a lot of teams, the way you expect to work with most language package management ecosystems is to say, hey, I want to be on these versions of all these things and keep me on those versions until I say otherwise. So, thank you very much. And John mentioned the kind of configuration as code stuff earlier. So, we're basically working on some stuff in that area, basically. The idea of giving more ability to have control over what versions you're running of your software in Homebrew in your various projects that you're working on. And that will be a free Workbrew feature that we kind of will release for people. One of the nice, again, things with, like, Homebrew and Workbrew is that some of these things, people might be like, well, why didn't Homebrew solve this? Or why is this in Workbrew and not in Homebrew? And there's a bunch of the features that people have been asking for in Homebrew for a long time, like that, where the Homebrew folks said a long time ago and continue to say now, like, we don't have the bandwidth to support this, right? Like, we need someone, like a business or whatever, to step up and say, provide the ability for this functionality because we as a bunch of volunteers don't have that. And that's been a nice thing that we've been able to do with more and more things in the Homebrew ecosystem where we can say, hey, the first big one was MDM, right, where the Homebrew folks are like, hey, no thanks, don't want to support this. So, we can say, hey, on the Workbrew side, we can do this. And, yeah, I expect that to grow more this year and in future as Workbrew evolves. That's awesome. We just want to take a minute to thank our wonderful list of Patreon backers who help us get these episodes out to you every week. So, a huge thank you to Weldon Dodd, Graham Gilbert, Bill Smith, Justin Holt, Daniel McLaughlin, Chad Swadow, Tim Sutton, Stefan Weinstein, our friends over at Command Control Power, Seb Nash, Will O'Neill, Jose Farah, Nate Sinahal, Tim Purford, Tobias Linder, Adden Berg, Hamlin Crouson, Stu McDonald, Jeffrey Compton, Anoush Dovill, Melvin Vives, Bill Seitz, Mike Boylan, Rick Goody, Adam Selby, Dwan Maas, Pax, Julian Reddick, Tim Camps, Scott Blake, and Tony Honorati. Thank you so much for being a Patreon backer of the MacAdmins Podcast. One of the rich traditions here on the MacAdmins Podcast is that of the bonus question. You know, the bonus question is often frivolous, and this year is no exception. What in your world needs an equivalent to an S-bomb, but for something other than software? You know, we talked a little bit about the nutritional label, and that that has its own value. You know, what are you thinking in terms of, you know, you need a detailed understanding of, you know, the internals of some organization. John, I'll let you go first. This is complicated. You know, I think that there is maybe, are you talking about in my life or in? Your whole life doesn't even have to be tech. Okay, cool. Yeah, I mean, I think like one of them, I would say, is probably just stuff. Like, I have this habit of collecting things and never getting rid of them. And it's not usually like big stuff. It's like, you know, for example, I love to keep all the tickets to like every concert I go to and my flight tickets and stops and stuff like that. I just have boxes and boxes of that stuff that I just like, I'll organize that someday. I don't even know what's in there anymore. Like, if I had like a beautiful inventory that told me everything and I could easily locate it and know what it was and why I had it, that would be like incredibly valuable to me. I love that. I think that's spectacular. I, you know, I've been using Flighty for the last couple of years as I've done a lot more flying. And I feel like that's my equivalent for like flights that I've taken or the boarding passes and other things like that. It does a really nice like year-end summary of all the places you've gone and how much time you've spent in the air and all of those things. I think it's pretty neat. What did they call that trend? It was like in the 2000s when you like kept all the data about everything. Do you know what I'm talking about? Oh, yeah, yeah. It is. Oh, shoot. It's at the tip of my tongue. I love that kind of stuff, though. Where you're just like logging. It's like quantified self or something like that. Yeah, quantified self. So, yeah, my like kind of, you know, thing that I do in that space is just logging all the places that I go. So I used to live in New York City. I was part of the New York City tech scene back in the early days when Foursquare came on. I still use one to this day. And I've used it every day of my life for like 15 years. So I have, you know, an incredible catalog of all the places I've ever been all over the world, which I love. I am the mayor of my coffee shop. I'm just saying. That hasn't been relevant for 20 years. Almost. But that is neither here. I find that keeping that sort of information is a much better way of remembering the things you've done and the events you've had rather than just, you know, holding up a phone and trying to take photographs of everything. I like to keep the memories and the imagery inside my head and just have those sort of, like you were saying, concert tickets or, you know, boarding passes or, you know, the lanyards from conferences, those sorts of things that just trigger those memories. And S-bomb would help to not have to dig through, you know, enormous plastic tubs of stuff. So, you know, the S-bomb can definitely stand for stuff. What about you, Mike? Stuff, bill of materials. I love that. I guess I guess I'm going to be cheeky and have sort of two. So, the one that I feel like already exists is, I don't know how many of you are gamers or whatever, but there's a website if you're building a PC called PCportpicker.com, where you can basically like bind together all of the Lego pieces that are a modern gaming PC. So, that's fun for almost like having an S-bomb of like what's in my PC and being able to share them and see other people's or whatever. The one I would really like is the guys who are on video can see I've got some instruments behind me that are somewhat defunct since I had children and no longer have time to play them. But like I would really love, particularly when I was trying to do a lot more covers of music, if I could have an S-bomb for a given song where it could be like, okay, this track was made in Logic. This is the guitar the guy used. This is the strings he used. This is the effects pedals. Like having that breakdown. And it's funny because, again, in tech, like I feel like I can see Tom happily noddling away. Like a lot of tech people get this and I say this to like music people and they're like, dude, why do you care? Like just it sounds good, right? Like why do you need to know like what pedals they used and what compressor plug-in they put in Logic or whatever? I'm with you on that. I was literally the other day looking at some, you know, there are some amazing fellow nerds out there who have documented this going through Stone Rose's songs and documenting what John Squire was doing, which particular model of MIDI verb he had and, you know, the next step from that is that then means that we can create plug-ins for, you know, whilst you have the collection like I do of all of these vintage instruments and the original effects, you know, it's you don't get the time to go in and settle that up and plug it in, but we have these amazing digital modelers where you can just feed that in and mess about for an hour and pretend that you're in a stadium somewhere and that, you know, I'm actually a competent musician or anything like that. So absolutely with you on that. And it also is a nice way of justifying buying more instruments, equipment, everything like that, which we all need. It's not just tech. We all need an, I don't know about an excuse, a justification to ourselves for adding to the pile of stuff. But what I'm suggesting is that we go even more like S-bombs and that we actually have, you know, not just, it's lovely that those people have made those websites trying to document this markets, but what I'm proposing is that some US president makes an executive order. This is required. Absolutely. When I buy an album, I should be able to see the bill of materials for every single track on that album. I need the details. That's my right as a listener of music. More of those, please. Exactly. That's what we need. The nutrition facts of the album. And we could get jobs as auditors. I'm here for it. If a particular distortion pedal is deprecated and we need to revitalize that, you know, plug in a new distortion pedal, rebuild the track, soared. Marcus, how about you? What are you looking for? For me, there was a discussion. We're having some folks on Mac Admin Slack. And I've realized, you know, whenever I go traveling, I'm about an hour away from the airport. And there's usually that moment about justice we've gotten on the freeway, either in my own car or on Uber, where it's like, did I pack X? And the number of times I've pulled over onto the service road in the freeway to go and check my bag to go, yes, in fact, I do have that. But to be able to do a live S-bomb of what is in my luggage and, most importantly, what is not in my luggage, to be able to make that decision where, is it easy to turn around and get the thing I don't have? Or is this something I can just, you know, acquire when I get there? Or just think about something else rather than what's in my freaking luggage. So that's it for me. What about you, Tom? Well, you know, my choice may be a little controversial, but, you know, we've made jokes in the United States for years that our politicians should wear NASCAR suits with all the patches of the, you know, the people that are supporting their campaigns and that have contributed to their PACs and all of those things. I am all for this. I think that that is exactly what you should do. Right now in the media, there's frequently, it's, you get the person's name and it's their party affiliation in the state that they're from. And, you know, I would love to see, give me the, on the chyron, I mean, it was going to say, it's a moving chyron. It's not like the old days. Give me the dynamic list of the top 10 people that donated to the last election. And let's see what that looks like. Because I think that would be a truth in lending kind of situation that I think would be very, very valuable. Especially, you know, now, here we are. I was talking with some friends today about, of course, the TikTokpocalypse, which is, it seems to be going and ongoing all at once. We don't know where this is going to land. But, you know, all of the different reasons why this was a really good idea, terribly, terribly, terribly executed. And I think that, you know, understanding, you know, some of the other things that may weigh into their decision-making process would be a helpful thing. So, that's my thought. I will accept your letters at devnull at macadminspodcast.com. Please address them appropriately. I will give them all the due consideration there, that they aren't. Mike, John, thank you both so much for spending the last hour with us. It's been absolutely incredible talking with you guys about Workbrew. We wish you guys nothing but the best this season. Hope to see you guys. Now, I was going to say, Mike, I'll give you a special invite because I know you're in Edinburgh. Four hours south of you, you know, five hours, I guess, in Brighton is Macad in the middle of May this year. May 14th through 17th. If you guys happen to come up for that, I'd love to see your beers on me. So, or we'll find some good music to go watch and that'll be even better. So, come join us. Thank you both so much for joining us today. It's been such a pleasure to have you. Thanks so much for having us. It's great to be back and look forward to the next time. Thanks for having us. For sure. And open invite. If you've got something fun to talk about, we'd love to talk about it. So, that's fantastic. Thanks so much to our wonderful sponsors this week. That's our friends at Kanji, 1Password, iMazing, and SmallStep. And thanks, everybody. We'll see you next time. See you later. The MacAdmins Podcast is a production of MacAdmins Podcast, LLC. Our producer is Tom Bridge. Our sound editor and mixing engineer is James Smith. Our theme music was produced by Adam Kudiga the first time he opened GarageBand. Sponsorship for the MacAdmins Podcast is provided by the MacAdmins.org Slack, where you can join thousands of MacAdmins in a free Slack instance. Visit MacAdmins.org. And also by Technolutionary, LLC. Technically, we can help. For more information about this podcast and other broadcasts like it, please visit Podcast.MacAdmins.org. Since we've converted this podcast to APFS, the funny metadata joke is at the end.

Today's guests are Mike McQuaid and John Britton. They met while working together at GitHub. Mike and John are the founders of Workbrew, a startup built to provide the missing enterprise features for managing Homebrew. Mike is the project lead and longest serving maintainer of Homebrew, applause, the package manager for Mac that almost every one of you will have used. I used it today to install Docker. We get the inside story on Homebrew, including its London pub origins. I would never have imagined that it began in a pub in London with a random chat. I mean, I guess the naming and the beer theme might have led one slightly more in that direction. We learn what it's been like to work with the biggest company in the world, Apple. He's based in the Shetland Islands of Scotland. If you look at a map, Shetland is far away. Essentially, that's the short version. Someone in Apple being like, oh, we have to get this thing here. Like, can it not just go to an office or a bigger city or whatever? We can't. Like, if you want this to happen, this is what you need to show out, right? We learn how Mike and John think about open source sustainability. You will find various parts of the internet that don't like me very much for this viewpoint. But in the end, to me, the only way you are able to successfully scale that is you say some of these features go away. And how Mike and John are taking these lessons forward to build Workbrew with a very unique approach. Enjoy. Probably everyone listening has used Brew, Homebrew, to manage their packages on Mac, unless they're, like, really hardcore on Linux or Windows. Do you want to talk a bit about the actual, like, story of Homebrew? Because this is a tool that we all use. So I just want to say something about the hardcore Linux users. Is that I would say that, like, both Mike and I kind of came to be as hardcore Linux users and ended up in this situation of working on a Mac because of its similarity to Unix operating systems. But there was something huge missing there. And I think that the story of Homebrew's origin and whatnot that Mike will tell is definitely, like, going to encompass that as well. So, I mean, I guess as John said, I almost mentioned this earlier. But, yeah, for me, I realized recently I think I was a, you know, Linux user for, I don't know, like, five or six years primarily. And at less than a year after moving from Linux to macOS, I ended up maintaining Homebrew. So that's, you know, how I ended up over there. I've, my, occasionally when Linux people give me trouble, I point out I have, like, one commit in Linux kernel from back in the day, like, 2000 and whatever year it was. So, yeah, that's my nice little Linux fight back thing that I have. Linux credibility. Yeah, exactly. Also, fun fact, Homebrew itself runs on Linux nowadays as well. So we might talk about that later because it's sometimes a little bit confusing why you would want to do that. But anyway, so, right, we're back in 2009. I'm working in London for a stock called Mendeley. There's a guy called Max Howell also working in London for another stock called Last.fm. He has irritations with the way package management is currently working on Mac. He's been playing around with Mac ports and think and coming by. There was one other option that, like, leaves my mind right now. And I think he was whining about it in the pub one day and basically someone said to him, hey, if you hate package management and you know all this stuff so much, why don't you make your own package manager? I think mainly intending him to just shut up. But he went off and started work on Homebrew. It's interesting. You can kind of go back and look through the Git logs. It's like one of the kind of few examples, I guess, of a big open source project that was started with kind of re-be-driven development. So the first project commit in Homebrew itself is like a description of how Homebrew is going to work. And Mac wrote all that down before he wrote the codes. And I often think, like, that's a sign when things are going to be optimized for usability and developer happiness as you think from the outside in. Think, like, how should people be interacting with this rather than just, like, writing code and then being like, well, they interact with it how I tell them to. Anyway, so he'd been working on this for a little while. He open sourced it. It started to get picked up by a few more people. I discovered it because I basically built a sort of hack on top of Mac ports to make it work in the way I didn't know at the time. But this Homebrew tool worked to use a lot more stuff from the system so it'd be kind of faster to build various tools. I discovered Homebrew. I was like, this is cool, and sort of just started getting involved. And, yeah, I think one other non-Macs person had kind of been getting involved as a maintainer at that time. And, yeah, like, I guess, fast forward 15 years, we've got kind of gone from, you know, a few contributors, a few maintainers to about 30 maintainers. We've got about, I think, 15,000 or something contributors, maybe more than that, and 20,000 packages kind of in our, like, officially supported ecosystem and then probably tens of thousands more in the kind of wider ecosystem. That's so cool. I would never have imagined that it began in a pub in London with a random chat. I mean, I guess the naming and the beer theme might have led one slightly more in that direction if you ponder it sufficiently. Yeah, that makes more sense now. Wow. So, Mike, could you just tell me what you just told me about WorkOS? Because I just told Mike that WorkOS is the sponsor, and this is what Mike said. Yeah, so WorkOS isn't paying me any money for this. I pay WorkOS money for this, but WorkOS is, like, one of the best developer tools I've, like, ever used. It's the documentation and the experience with building with them is so, so good. Like, I initially was almost like, okay, this seems expensive, but then, like, I built an integration with them in about 20 minutes that I had spent two hours, sorry, two days, banged my head off the wall trying to build it directly with Okta. I then have, like, many, many SSO providers, like, support instead of just one. So, yeah, like, for me, WorkOS is one of the nicest developer experiences I've encountered in the last, like, five years, probably. And it's still surprising because a bunch of the developer team are ex-GitHub and therefore very good at their job. Amazing. And was it a case of, like, build it and they will come? I don't think so. I mean, the funny thing in open source land, back then we used to talk a lot more about this than we do now when it's, you know, there's a bit more of, like, oh, clout and you should get some GitHub stuff on your resume or CV or whatever. Like, back then I remember people said a lot of open source is just scratching your own itch, right? Where essentially Max had a problem himself that he wanted to solve primarily for himself and then he was like, okay, well, I'll put this on. At the time, also quite new, this thing called GitHub. And I guess that was the other sort of interesting thing and it's been interesting for me kind of being on both sides of that is, like, Homebrew was also one of the first software projects, certainly the first package managers to kind of really lean in heavily on the kind of GitHub way of doing things, right? So Max, from the outset, I guess he would say that he was being lazy and I guess, you know, maybe he was being lazy, but he was also being smart. The best engineers, in my opinion, are often fairly lazy because he had the attitude of, like, hey, I don't want to maintain this all myself. I want to have the community maintain this. And if you want the community to maintain it, you need to make getting involved, merchant pull requests, all this type of stuff, like, as easy as possible. So that was a big focus of his in the early days and that was, I guess, a big focus of mine increasingly with Homebrew and GitHub and things like that is that generally you want to take the behaviors that you want people to do in a developer tool and make them as easy as possible. And if the stuff you don't want people to do, you want to make that either impossible or harder for them to do than the easy thing, than the right thing. That makes sense. And what does that, like, functionally kind of look like? To me, in something like Homebrew, it looks like, I guess it depends on what layer you look at, right? So part of it is, essentially, we really try and optimize the friction of, like, onboarding, I guess, both from a user level and a contributor level and a maintainer level. So for a user, Homebrew was, I think, maybe one of the first projects, maybe the first to the now infamous, get a bash script and pipe it into curl that some people don't like very much. And if you don't like that then you might want to hear more about Workbrew later. We'll talk about that. But I guess from that perspective, a lot of these tools that have installers, having something where you can, like, get installed a single command, no dependencies, everything gets done for you. that was very heavily optimizing Similarly for contributors, the docs, the automation, the tooling, everything like that, such that the flow as possible for that person getting started with the project. And when we see people multiple times, we're quite aggressive about jumping on them and really prioritizing fixing that stuff the project scales, And we have still very, very many more than we have maintainers. And then the last thing is similarly doing that for the maintainer approach and they're making it easy for us to add new maintainers but also making it easy to do their job, trying to automate the absolute living hell out of everything we possibly can, trying to lean into, robots, automation, CI all over the place, linting all over the place to try and essentially just remove the amount of manual work that a human has to do that can be done by a robot or a CI or a GitHub action or whatever it may be. I mean, what makes it possible for such a relatively small team of volunteers to run a huge part of the infrastructure of Mac development. unbelievable to me how small but mighty that group of people is and they deserve all the accolades and all the support for, you know, as a developer myself, I'm a user of Homebrew. I use it every day. I couldn't imagine and it's just, like, unbelievable that, you know, it's possible to do something like that you know, small, dedicated crew. Yeah, I mean, it almost feels like, I don't know if I ever really thought about, oh, where did Brew come from? It's, like, like, inherent part of, like, like, developing with Macs. such a, did, did, like, Apple get involved in it at all? Not really. Like, they've helped us out So we have contacts at Apple who we can kind of escalate stuff to and help us out there and ask questions I guess the most notable case of Apple helping us out because obviously they realized that it was very much in their self-interest in that case to do it was when there was the Apple Silicon transition, you know, pretty much, as soon as they announced, like, move to Apple Silicon and there was these and stuff like that, they got in contact with us straight away and we're basically, like, of these kits of your maintainers and we also want to, like, get these kits in data centers so you can start building, building stuff in CI and automating things and packaging things and integrate that into your workflow and you're not having to, pay out the nose for a lot of this stuff. And even that process was kind of an interesting case of, like, worlds colliding there was conversations with some of the Apple folks, some of them knew already, some of them would go, so where's the homebrew office? And it's like, there is no homebrew office. There is no homebrew office. Okay, so what country are your maintainers based in? Like, All of them? Maybe, like, 20 countries, right? And I remember, like, one of the folks who was very early getting a lot of our stuff sorted out and he's a workbrew employee nowadays as well and he's based in the Shetland Islands of Scotland. So, like, if you look at a map, Shetland is far away, That's the short version. And, yeah, basically, like, someone in Apple being like, how, like, we have to get this thing here. can it not just go to an office or a bigger city or whatever? And it's like, no, we can't. This is, like, if you want this to happen, this is what you need to sort out, right? And it did all get sorted out and it was all fine. But it's, it's definitely an interesting cultural thing. And I think Apple, you know, I'm a massive Apple fanboy. I basically own essentially almost every thing they've ever made with the exception And I'll take one if anyone wants to give one to me for free. But anyone's listening. for my startup lifestyle But, yeah, you know, But they definitely, like, don't quite get open source, there's certain teams and individuals in the organization who have that background or relationships or whatever. organizationally is, like, they're not, super tuned in until almost, how to partner with a bunch of volunteers with no legal entities scattered around the world. Yeah, it's actually really surprising that they're not giving bucket loads of money to you guys. I don't know. Well, this is a lot around open source right now, where it's like, why? I'm actually not being too facetious hopefully, why should they? They don't have to. Humbro is operating fine without getting buckets from Apple. And from both parties' it would be hard to justify going from nothing to buckets without some sort understanding that relationship is, of quid pro quo. And, you know, that's when you have a volunteer scattered around and, you know, maybe the world, I haven't checked Close to the largest company in the world. in the world, there's an imbalance there. also, maybe it's pertinent to maybe the way right now, where there's an awful in and around open source right now. And I'm maybe one of the old school maybe even free software people, kind of the point is they don't have to give you anything. I don't feel like any company who uses Homebrew or relies on Homebrew is obliged to Homebrew. a bunch of them do and that's great when they do appreciate that useful for us. But, if the license, if we demanded that every company gave us money, then in my mind, we're not open We're a different thing. We're a proprietary product with a free tier, right? My message would be like, don't try to use open source as a playbook. You know, build your product, get people to use it. Like, the idea that, open source is a marketing strategy is something I just see like way too often. Yeah. And I guess it depends what you're optimizing for, right? If you're trying to maximize reach, then, yeah, make it open source, put it under the most liberal open source license possible, the MIT license let everyone in the world But then converting those people into paying customers later is not something that you have built your relationship right? And it's funny because I guess the open source in some ways, I think like open source is a short-term business model. It's not a long-term profit-making business model. And it's one that when these companies get bigger and zero interest rates and investor pressure and all these types of things happen and you get squeezed more, then it's like, you know, to what, are you able to your, like, whoever it may be, your community, your customers, your employees hey, all this open source like, turns out, changed our minds. Bad idea. I don't know how to do that anymore. yeah, and I think John and I share a similarly bad taste in our mouth from places that have done that where it's not even doing the wrong thing. It's just, you cause a lot of aggro that you don't and that aggro ends up feeling like it is open source's fault whereas I think it's the exact opposite of that. open source to be something that it's not. that makes sense and yeah, it's like, it definitely is like one of the biggest conversations right now. I think even like the whole WordPress stuff is like this kind of like whether you should pay things that you're not obligated to or whether you should that you're not obligated to. I mean, to like looking at the origins and looking at the licensing. for me, it's like we have this internal that we talk about which is don't give what you'll later have to take away and when you think about open source, like what you're really doing is if you come from like the free software it's like the freedoms. The freedom to copy, the freedom to change, the freedom to distribute, you know, all of those like core tenants. if you're starting where you're telling what you're giving them, then of course the internet is going to be mad at you when you change that. Whereas like from our perspective the idea you know, building a business around open source is that this is an open source project. It's open to for anybody to do right? that doesn't have to change. You can come along and build a business related to it try to solve more problems the same problem space and not put yourself where your entire business model is like hinging on the fact that you need to change something about the way your open source project Like I think I'm not actually familiar with the situation with WordPress. like read over it like very briefly but there's definitely this case of open source projects there's like a valuable service and the business model provide support or the business model is provide a hosted version and to turn around we're the only people that can provide is a big challenge, And that's what a lot kind of come down to hey, we invested all of this effort an open source project and now we're going to like try to retain for ourselves the ability to be the only one as a hosted service and that just seems very challenging to operate and to execute and it doesn't really jive with the expectations want out of open source and so I just think a flawed logic. I think it's a much to say there's a huge infrastructure people make get a lot of value as it is and if there are why not go build those bits additional bits that are not that are kind of complimentary I think this brings us really easily into the concept building this it's the missing pieces Mike uses this analogy of like the Lego set if you think about and you think about the code and the available modules the standard bricks you can go and build with the standard bricks but when you buy that set that's the Millennium Falcon all these pieces that are super custom to your exact use case and those are the bits that we build right you've got Chewbacca's yeah exactly yeah they're not the Chewbacca is too specific to like your company you know that makes total sense and I guess it's also reassuring in the sense of like the open source part you you couldn't even if you wanted to do like a massive rug pull and be like homebrew no longer like or whatever because you you're working that I guess homebrew is not part of workbrew it's something that you're heavily affiliated to but you're not you don't own you're like building on top as well right Mike should talk like in a little I mean for me this sort of like why why now because various people including John for the last like you know 10 years 10 years hey you should go and make like a work a homebrew company and I've been like I don't like that idea and I think like for various reasons but one of those reasons was the fact that homebrew was in a place that there was a risk have happened 10 years ago that like if a big injection of VC happened to go into something around you know in the homebrew that you could quite easily capture that project was so nebulous right whereas now governance structure like I'm leader of as was mentioned am literally elected to that position every year like it just so no one against me and no one has ever been elected except me had that position but that's not a guaranteed and if I were to really annoy everyone involved community and all the I would not get re-elected like someone else and they would and they would homebrew right so that structure means as well as boring licensing details stuff I wouldn't essentially is its it's a and it that way forever workbrew may or may like involved with homebrew like past present future whatever the idea that workbrew could somehow homebrew and take it's not right it's set up that that a tenable in some ways that I actually like the most and I don't work through so I'm not paid to say the relationship git and github was like I think that's look at like like a big has with that's the internally we kind of jive because it's like was github the development of a bunch in git sure like did github help of git but back when like and bitbucket and various of relatively git hosts were around like github trying to like eliminate or fork git or like find a way to like everyone who uses git on their needs to us money that was thing but I also think the growth of github hand in back and being a git bunch of I guess some of like I a bunch git that be there not been for github working full features right and the same homebrew some ways the features substantial we're still company but there's still stuff in homebrew which was and would there not for that we in the right and for all the use however yeah that's actually really cool and I the kind of comparison I ever heard anyone even make the link between git and github in the oh like this is you know like people do it like I don't people complain about like this project is too tied to this one um I you about git github um which is really cool as well thing you hear people periodically on the orange site is people being like hey people can think github are the same thing and they're not and isn't that bad right like and it's you know I don't think github cares very much about um about about not being associated one-to-one with git because they feel like that's not necessary for them right grown a brand which is bigger than git right and that's you know I think the way that both parties handled that admirable really other other ways to look at that too similarities between git and github and between what workbrew and you know git is kind of the behind the scenes like technical enabler of the product but you know the stuff github successful it wasn't just obviously there was like timing with git and decentralized version branching and merging all that stuff but like you know and the pull big you know the big drivers of the and I think that it's similar you that it's like there's this underlying architecture that brew is the software onto a machine there's a to do more than you know just the libraries that there's a huge opportunity for teams to have shared environments and do things that don't make sense player model and model and so you know we the opportunity add a lot of complementary functionality and you know build a business on that another kind of company that I really admire in this space of it's not quite open core like open core right like it's not they control git thing it's this complementary style and I'm not sure if you're company called tail scale but amazing kind of I want to call them like a VPN not quite a VPN it's a peer-to-peer tunneling like overlay network tool but it's built off of this called WireGuard and you know people don't really make the correlation and WireGuard unless they're really nerdy about it underlying enabling technology that they build kind of a multiplayer peer-to-peer administration layer on top of and they run you know all these like web do like stun tunneling and they do you know NAT traversals and complicated networking stuff that you but really there's a huge value in them and what's what's it's like all of functionality makes WireGuard feel like magic and that's their product and it's like WireGuard enabling technology and I think that you know for us similarly Brew is enabling technology that's really awesome and we want to magic to teams right bring it to can say you know get your engineers up and running as fast as possible on day one make sure makes a change to the developer environment it works you're not repeating yourselves over and over again when of date you can easily when there's a vulnerability you away you know about it you can you know remediate you an audit history of what's going on like all of this stuff is really really valuable from a business perspective and it's not something that you know the open source community is like eager to build like I don't see a lot of open source engineers in their what does this billion dollar company need to with my open source project let me spend my time working on it for free right so we can build some of those bits and and I mean that was in some ways the earliest motivation for work brew really was like we sort of decided on this we're going to build a commercial layer around homebrew before we nailed down the exact ideas but the exact ideas came from people in the homebrew community including one grumpy scotsman who may or may not be a very I don't know whatever adjective you want to like I said no to a lot of these things over the would come from a big company and say my compliance requirements mean I need to ABCD and and it would be a non-trivial lift for the homebrew folks and I'd be like now we're not going to periodically I would other maintainers and be like I'm just no one's super passionate about doing they're all like no don't want to do this how about project receives a large company to complete your questionnaire yeah exactly classic example right but I mean I found this actually like a previous job so like Linux guy and I worked on KDE like the Linux desktop environment and and one of the things I about back then I worked for a company called KDAB who consultancy company around QT that the tech that and KDE was built in and I because they were like the the biggest contributor to KDE of any like company right so I joined and I was like I'm this open source work gonna be sorry for money and it's gonna whatever and then I learned that like a lot of the open source work for money work around this stuff is the stuff right because all of the fun jobs that's the stuff that they problems getting volunteers in their spare time to make sure that they do this but like a essentially when you have a spec and you need to hell up something to make sure that like you behave in the same way as some software on windows or a bigger open whatever and you want to just like nail that down such that you completely of the specification right that's that's not so fun right like but it is really valuable and important to big companies and that they will pay for people to do right and in some ways I'm also inspired by that where it's previously with those organizations it wasn't that I was saying like we don't that your right it's your they did have problems and they them but it's like we can't solve that we're not the right people we're not qualified well enough and in some cases when even when people would come pull requests to this functionality functionality it was like well now no one's using it so it bit rots and then a year later someone tries to use it again it because homebrew doesn't use it right and 99.99% of homebrew users whereas now we have a world with workbrew with this it's like we have customers using this stuff every single day right so if project has an issue there we fix it within minutes or hours right instead of it being like a year of this thing just being broken right and so yeah I think I different way of doing this stuff this stuff and I think it's where people are best aligned right we in workbrew are best aligned to solve these problems for customers and we do it with some some proprietary software and we do some stuff for free and some stuff for money right and whereas workbrew is sorry homebrew is best aligned to do what suits the community to kind of coalesce behind the stuff that works for 99% of people right and if you're in some very niche use case or 0.1% or whatever then it's you know it's probably not good for you as workbrew might be this is also the configuration or simple defaults or solving the case for the majority of people you know there are a lot of you know I'm not a I'm not a maintainer but I'm a contributor to homebrew and I'm a heavy user and there are some things in work the way I want them to but kind of the consensus is like this is the way it is because we need to make life manageable for the maintainers if we changed it the support load or the burden of maintain maintenance would be much higher so we've optimized for you know the homebrew project has optimized some things for maintainers rather than for users in the sense that like this always works it never has a problem we're never having to support it and so kind of the the idea of the project the open source project is kind of the one true way to use the thing that applies to the most people and is the most reliable and the most robust and the easiest to maintain and know every time a new mac os version gets released homebrew is waiting right like that's accomplishment for the project but when it comes to you know big companies something that we learned at our time at github was that you know a small company of 100 employees telling a company of 100,000 engineers how to build software is kind of laughable the idea that the 100 person company knows how 100,000 person companies should be running their software teams and that you know controls aren't necessary right like these these kind of like very I don't know very basic ideas right and the reality is that those really big companies or you know the companies that have requirements they get a lot of value out of the things to have checkboxes and have options and to be able to say this is we make this tool you know fit our working style rather than having to conform to what's there and so another took away from our time make github and what we kind of emphasize that you know the idea of configurability is kind of a debt that you have to maintain and a burden and you know the open source project is not really willing to do that in in some cases but for us that's willing to sell we're to maintain to make this thing work for you know various sizes of companies with different controls and security and compliance requirements and all that kind of stuff and make that our value add to make it fit your needs and so I think it's just like a great opportunity to work with them work on an open source project but model and it's not really open core it's not really like an open source company it's more of like a complementary business to an existing open source company or an existing open source project I comes back in some ways to the title of the podcast right this is scaling dev tools right and in some ways there is the the open source way and there is the the business way and I think where it gets messy or people get confused is when they try and combine the two so about sustainability and open source nowadays right and I have been you know moderately critical on the internet and more loudly critical in person at that about the idea that essentially the way you fix open source sustainability is just throw money at every that fixes all the problems right it doesn't it doesn't I've seen it in hubbrew and I've seen it in many other projects and many other maintainers who are in my inbox like trying to done right the way in my experience the way you sustainability is by figuring out what sustainability looks like open source project right and some of that comes from personal boundaries of the maintainers with each other with the community personal boundaries with maintainers in terms of like what what are we doing here what are we trying to build right are we gonna do the Jamie Zawinski rule of like every all software grows client right or are we gonna say no this is the line beyond which we don't we don't go we're not interested that's out of scope use this other project whatever it may be and that's how you have to do this because in you know 10 years ago homebrew had probably like half the number of maintainers maybe a third uh but we had like maybe one like one tenth if not much less than that of the users right and the way you scale doing that as John kind of mentioned and alluded to as well is you do that by filing off the rough edges right and if you have a feature that blows up for users 10% of the time right there might be a bunch of used power users who love that feature and it makes their life really happy and the workflows are great but like if 10% of users who bump into that even they have like 0.1% of those users go and complain on our discussions or like in the past when we had IRC channels or in our issue track or whatever that gets very very hard for 30 people to manage right and the only way in the end like I've been you know some you will find various parts of the internet that don't like viewpoint but in the end to me the only way you are able to successfully scale that is you say some of these features go away right if you want to build a plugin or support your own way of doing things over here that's fine but in the open source project we do not have the infrastructure to do this stuff like we can't do it and if you there's that doesn't solve the problem either because you end up in this I should probably name for it but like this sort of open source sustainability money-wise gulf of like too much money for stickers not enough money to pay anyone right where like if you don't have a quite even one person's full-time salary coming it reliably but you've got way too much like what do you do with that and how do you use that to somehow magically scale the project so that everyone is able to do more with less or the same amount right but I think on the business side that's when it gets can go and build a business where if you most businesses well no most businesses certainly are business you start from the outset with a model of looking at being like well ultimately we are going to have to build something and we're people money for a product and exchange for that product like they are going to get a great user experience that they don't otherwise get right and to me like that's another way that you build sustainability both for open source and for dev tools in general right like github as a you know if you look at the offering on github nowadays and how many billions of features they have and ci runners thing you couldn't do that with a bunch of volunteers like you can do that with 30 volunteers working right like maybe their 2007 or 8 or whatever it was you could have done that you maybe that indefinitely with like a small number of people just doing things but you wouldn't scale that to you know like hundreds of millions of users for sure like that's all of that stuff requires many many people being having a level of dedication that is not really compatible with them having a full-time job yeah it may it makes uh it makes sense what you're saying there about like um you know how you unless you're paying people the full salary like money is not really going to help like do that and that you do need a company to go and like give those like those extra features that maybe not so many people need that cause a lot of problems you know you're you're willing to do all the boring fiddly things that big companies need and that is not fitting for open source it makes so much sense this is very cool i honestly like i hadn't really seen this sort of model or like really thought about this maybe it's probably the right way i'd seen it i guess but not thought about it um it's very cool and it seems like you're not gonna have to worry about really any of the kind of issues that a lot of open source companies have with like monetizing uh the project um it's very cool and we're kind but i just wanted to ask like who who are you like kind of selling to it's like it departments or how yeah so there there are really three you know types of people that are interested in in work brew um obviously first and foremost is the developer um homebrew is incredibly popular with developers on max and at the minimum there are developers out there that work at companies where they have security and compliance requirements that prevent them from using homebrew you know imagine trying to do your work without access to homebrew how much less productive you would be um so really one of the core you know values that we provide is just the ability for engineers that these security compliance requirements to have access to the tools that they already know and love and use um in addition for engineers we aim to you know make the process better help them get up and running faster um and really make it so that it's a treat your local development developer environment like its infrastructure and the idea being that you know i have worked in vms i've containers i've worked in cloud idees and they all have a trade-off in that you get consistency speed of startup all those types of things in exchange for worse ergonomics i love working on my local machine with my local editor on my local file system with my local network with all the things that are ergonomic and the way that i like them and anytime i introduce a docker or vm or cloud id or anything like that into my workflow it drains me it makes me less productive in addition all of those options cost more they're either you're paying for vms you're using more battery life using more processor you're doing whatever you have these really amazing apple silicon devices you're dollars pop for and then you're shelling out into a cloud environment like what what are we even doing it doesn't make any sense so that's the story for the developers it's like have access and have really great ergonomics the next big category of people is the it managers so these are the folks who in your company they're responsible for issuing you a laptop and making sure that you're up and running and for engineers oftentimes these people you don't need to interact with you can self-serve you can fix your own it department at github was amazing the people on that team you know were there to support you when you needed them they helped you situation they helped you with getting access to things but at the had the situation where we had a lot of talented engineers who knew what they were doing so it where they had a lot of trust and there was make sure things that were necessary got done and so as it managers we want to give them a way to lighten their workload and be able to get brew into the hands of their team in a reliable repeatable really easy way and then once it's out there know what's going on have visibility into how are people using this thing do i need to be worried that they're installing some software that could have a supply chain attack or things like that and then the last people that were you know trying to serve are whether it's a CISO or you know kind of somebody who's on the AppSec side but they're they're interested in is secure we're building a bunch of functionality around making sure that compliance standards so you know there's SOC 2 there's ISO 27001 there's you know all the different kind of credit card compliance like there's there's all different industries have their compliance standards and inevitably they people are using whether it means you know the people on their devices are using admin accounts rather than the standard users and what what's entailed interacts with that or if it's about what pieces of integrated into their workflows so you know we're serving those people by saying hey level overview of happening you can get alerts about when there are vulnerabilities you vulnerabilities you can set policies and guidelines to make sure that the usage of these tools are contained one of the really powerful features of homebrew is that it's not tied to one library of packages they're the official packages in homebrew core and homebrew cask but you can actually add a third-party library called a tap and install any software homebrew you can create your own taps you can use taps by third-party vendors and that represents for security folks a really really big issue they're like oh my god literally anything could be installed in the machines I have no idea about it and so you know for them we're making it so you can see are people using third-party libraries third-party taps which which ones are they using do you have a control policy that you need to implement so stuff around there that's really valuable and so you know those are the people we're trying to serve and I think that kind of the last thing I'll say about this is kind of the business model and like how this so we have pretty much two two stories version and one there's a paid version so workbrew is available for free for unlimited users unlimited devices it's the best way to install brew on a fleet whether you have 10 or 10,000 devices you can go to workbrew you can install brew on every device have it be consistent get it ready minutes and have full visibility into everything there this is kind of like table stakes for any company that's doing any kind of sock to compliance or any kind of you know good security practices and we made that totally free then beyond that if security controls or if you want to add remote management or if you want to have any kind of interaction around automation and default packages and kind of environment setup then we have a paid plan that you can get additional features from but it's really targeted those those three use cases very cool very cool kind of reminds me of like sneak in a sense of like the kind of model that if you've thought about it that way but like I can totally imagine like I've I've had to use sneak at work because we went through sock to compliance and it was like just like my manager loved it because you know you can just everything is like you know compliant bits in with vanter and stuff like that and then for me it was like generally good because you know a lot of the time you just press a button upgrade and stuff rather than like solving it yourself but um yeah that's very cool it's uh very very exciting um yeah and thank you so much for sharing the journey and um yeah and thanks uh thanks mike for helping us download all the stuff we need onto our max so um yeah thank you john and mike um and thanks everyone for listening uh so workbrew.com if people want to learn more check out workbrew.com and you know thank you so much podcast we're really grateful to be here and have this conversation you know look forward to coming back at some point in the future and giving an update amazing yep thanks jack and listening

Oh hey, how are you? Great to hear. Here, come in. Make yourself comfortable. Like a drink? Sure. There you go. Welcome to the Tech Lounge. Shall we begin? Hello everybody and welcome to another Tech Lounge. I hope you are all sitting comfortably because today's interview is a good one. This interview formed the basis of an article I published on the Next Web a few months ago with Mike McQuaid, maintainer of Homebrew and now one of the co-founders of Workbrew. A lot of people who use macOS will have heard of Homebrew and the article was very popular. So I am looking forward to seeing what people think of this interview too. So let's just jump right in. Before we begin, there's just a few people at the door with some things to say that won't take very long. If you'd rather not hear these interruptions, then please support the show. You can find details in the episode and show notes. So, Mike, how are you today? Yeah, doing great, thanks. How are you, Chris? Good. I can see a guitar amp behind you. This is exciting too. Yeah, it's a bass guitar amp. I have a few guitars hiding behind me, unfortunately. I'm actually mostly a drummer. I have an electric drum kit, like just there. Oh, very cool. Yeah. I'm minor sadly, mostly for show nowadays, since I had kids. I had visions of my kids being virtuosic musicians at a young age and they have no interest in learning music so far. Yeah, my dad tried to do the same because my dad was a professional and I didn't get interested until I was a teenager and realized there were benefits to playing music, shall we say, as a young teen. So I found my own motivation. Anyway, so you represent two organizations, one organization, one company, both with a similar ending, homebrew and workbrew. I think we should, let's begin with homebrew. And let's, for those, I mean, in certain sectors it's very well known, but for those who don't know what it is, what is it? And I think a more important question might be, why is it as well? Sure. So I guess my highest level description of homebrew tends to be for people who aren't even in tech and have no idea really about computers is it's, I first asked them, have you heard of open source software? And if they haven't, I tend to give up. But assuming you have heard of open source software, which I imagine is most of the listeners to this, then homebrew is basically an app store for open source software. So it's a way for primarily developers, but a bunch of other people to install open source software primarily on their Macs. But it also supports Linux now. It also installs a bunch of non-open source now. And yeah, but that's the simplest one-liner, I think. Yeah. I mean, for any Linux people listening, it's a package manager as well, sort of, I suppose. But yeah, you are, like, I've used it for a very long time. And I, I would say it's probably about 50-50 at this point that I'm also using it for the non-open just because of the convenience. Yeah. Just to have everything in one place as much as possible is kind of nice because that doesn't really exist on Mac. It may surprise some people to hear this, but it's not really a thing. And it's, you were not the original maintainer or creator, were you, I think, from memory? No. So the original creator was a guy called Max Howell. So he created it, I guess, 15 years ago, last May. And I sort of knew of Max. He was a friend of, a friend. We both worked at startups in London. He was at Last.fm, which if you were in tech in that particular era. Yeah, scrubbling. Lots of scrubbling. And yeah, I was in a sort of similar startup in London called Mendeley. And yeah, and basically he, he used some other package managers on Max and he didn't like them. And he came up with Homebrew. And I found Homebrew fairly early on. I think I got involved, you know, probably less than six months after it was created. Started contributing, no real expectations of doing anything. And then now have been maintaining it for 15 years and contributed to the package manager itself, at least probably more than anyone else. You've been maintaining it for 15 years? 15 years. So the project is older than 15 years? So the project is 15 years. Sorry. I go by calendar years and things. So the project turned 15 a couple of months ago. And this is my 15th year. I guess my official 15 year anniversary would be like September or something. Yeah. Which is relatively, relatively old, long and mature in terms of sort of modern open source. That's, yeah, I guess. Yeah, I guess so. Yeah. And actually on a, on a side thing, I feel like didn't, didn't Max then go on to do CocoaPods? Or have I got that mixed up? So he worked later, he went and joined Apple at a later point in his career and he worked on the Swift package manager, which was, I don't really know that ecosystem super well, but I think that was sort of a somewhat related version of, like the official version of Cocoa Pops or something, but just for Swift. And when did the Linux version begin? Yeah. So that's, I can't remember the exact years off the top of my head, but there was a guy called Sean Jackman, I think, who started it originally. He started like a fork of Homebrew basically because he worked in bioinformatics. And the problem they had was they had these big, you know, supercomputers that they were allowed to compile software on, but they didn't get root. So they couldn't use the system package manager. And he figured out like, oh yeah, if I sort of like hack Homebrew this way and that way, then I can use it to install some stuff in my home directory. And yeah. And basically like over time, we sort of like built up relations with, with them. And then eventually the package managers merged and then the package repositories merged as well. So now Homebrew like officially supports Mac analytics. Ah, okay. So it's the same. So, okay. I have to be careful here. So for, for, for people who don't know with, with Homebrew, most things are called a formula. So you have the same formulas for all, all combinations these days. Yeah. Yeah. So the same formula is used to install stuff on Mac and Linux. I mean, there's some formula that only work on Linux and some formula that only work on Macs, but generally most of them work on Macs. And I know there have also been various decisions along the way in regards to the open, the non-open, the compiled, the non-compiled. Tell me a little bit of that journey. And, and I feel like there's been most recently this journey to reconsolidate as much as no, sort of. Yeah, maybe let's, let's, let's tell me the journey anyway. Sure. So Homebrew started off as what we would call like a from source package manager, which basically meant that if you've used in the Linux world, I guess something like Gen2, or I think even that's lesser nowadays, but certainly, so it would download the source code of the package and then it would fire up a compiler and turn away and then spit out in the end some binaries, you call them on your machine. And it's while it started off like that, like that was a very time consuming for users because some, you know, software would take minutes to install some software would take hours to install and, and B for us as maintainers, it was very error prone because there are a lot more things that can go wrong with compilation than not. Yep. So I remember Max initially kind of mentioned to me like, Hey, you know, it'd be worth playing around with this. And, and I created, so Homebrew has a beer theme overall and maybe clue from the name. So I created what I called bottles. So bottles are poured onto your, your system. And, uh, yeah. And basically like that started off just being a few of the most expensive packages to build being built on my machine, then evolved to a VM. And then we did a Kickstarter and whatever it was 2012 or 14 or something like that to get some of our own hardware. And then over time, eventually, um, we were building more and more things and then decided to kind of build basically everything on all our supported operating systems. Um, and we sort of flipped and sort of gradually from a from source package manager to a binary package manager. So you now, if you like brew install, whatever you will download our prebuilt version of whatever the open source software is, um, and that will be installed on your machine and that saves you time. It saves the world, probably some energy use or greenhouse emissions or whatever you want to say. Um, and yeah, and it's, it's also like way easier to support because stuff can still go wrong, but like the, the amount of stuff that goes wrong is, is dramatically reduced in that environment. And I guess the second part of your question. Um, so again, similarly, I can't remember the years with this, there was another, not really fork of homebrew, but almost like a sort of companion project to homebrew called homebrew casks. So homebrew casks or homebrew was doing to install open source software. And they thought, Hey, like, wouldn't it be nice to have something a bit like this that I could use to install, I don't Google Chrome, one password, whatever. Right. Um, so instead of downloading open source software, and then either in the old days building on your machine or nowadays building on our servers and then distributing that you just download with homebrew cask, the, the pre-compiled binaries from say Google or one password or whomever. Um, and then those are installed. And then I think again, maybe 2016, something around those eras, um, the two projects merged. It was mainly the work of a Google Summer of Code student called Anastasia. Um, and she worked, uh, really hard to get that done. And yeah. And then nowadays, if you write brew install, then it behaves pretty similar, like most of the time identically for packages, sorry, for formula, which are the things that are built from source and for casks, which are these, what we call these kind of binary packages. Yep. It's actually interesting. My other series of interviews at the moment, uh, this week is around immutable operating systems and you can kind of fake it a little bit with homebrew and you have this bundle thing as well. Yep. Of course the Mac isn't really designed like this though. And, and bundle we get you so far and maybe it doesn't work completely because most of the application developers are not expecting you to do this. So, uh, yeah, but it's, um, it's, um, it's interesting. You can kind of basically end up with a bit of a, uh, kind of a config file of your applications. Um, and there are other projects that sort of relate, but they're not quite as, um, as well maintained as homebrew or not as big, I suppose, um, for preferences and Mac app store and stuff like that. But you know, it's, it's, it's probably a very small group of Mac users who really actually want to do this. Yeah. So, so to dig a little deeper in case you are someone who that's piqued your interest, yeah, there's a promo project called homebrew bundle or if you like brew bundle. So that pulls things from a brew file, which looks a little bit like a gem file. If you've ever written any Ruby or, you know, Python requirements.txt or npm like package.json. And that basically says, here are the, the packages I want to install from homebrew, homebrew cask, or as you said, mentioned the Mac app store, or I think the other thing is like VS code extensions. And basically pull those down and install them. So that's a nice way of like having one file for either everything on your machine. So like, you know, setting up a new machine is dramatically quicker that way. Or alternatively, like you can also use it on like a project by project basis where you say this project needs, because again, a common thing in software projects is you might having to read me, okay, before you run gem install or whatever bundle install, you have to install Postgres and Redis and whatever your dependencies are. So this provides a nice way of doing that programmatically. And then you can like test that in CI and all this other thing. And you mentioned before about the immutability. And when we talk a little bit about work brew later on, like people, if they're interested in that, they should watch this space because this is something that I'm actively finding what I'm doing in the future. It's good I'm talking to you. I wasn't necessarily going to talk to you on that side, but we can mix it up a bit. And just, you mentioned Ruby files. Obviously, if you consider the time when homebrew started, Ruby was, I don't really want to get into the department of saying more or less popular, but it was maybe more commonly chosen as an option. And it's perfectly reasonable for what it does in homebrew. But has there been any thought about changing that at some point? Because, you know, programmers like to go with the new shiny and a lot of them don't think Ruby is the new shiny. Yeah. Well, so from a personal basis, I personally still love Ruby. Again, stuff at work brew that we'll talk about later, like I, all of our web application stack is built in Ruby on Rails because I still think that's the, one of the best ways of kind of getting started with a web application nowadays. But yeah, and there's always regular conversation about, oh, you know, should home Ruby move to another language? But the problem is the kind of formula that I mentioned before and tasks. So we would call them like a DSL, which stands for domain specific language. So it's basically like, if you go and look at a formula file, if you say, have, you know, used a Linux package manager before, you could probably look at that and without anyone explaining to you what's going on, have a reasonable understanding through a combination of the DSL being quite good and Ruby itself being quite expressive. You could look at that and be like, okay, I understand what's going on here. If it's downloading this from this place, it depends on this. It's then going to run these instructions, et cetera, et cetera. So the tricky thing with homebrew is if you want it to move to another language, then that Ruby based DSL is essentially supporting that in another language means supporting Ruby. So you're going to have to have some Ruby somewhere to shell out there, or you're going to have to do a homebrew, you know, homebrew is higher than v2 at this point, but like a massive breaking change versus homebrew where you break everything that exists already and move to like a new way of doing things. And in my experience, when you do that in an open source project, more times than not, you kill the project because people just don't want to migrate, make a fork. So yeah. So would we choose Ruby if we were building homebrew from scratch today? Probably not. Is it going to migrate away from Ruby? Also probably not. Yeah. And there's, yeah, we do more and more. The main, to be honest, the main problem with Ruby is just performance. So, and that's not a Ruby problem per se. It's more like how we use it and the competitors of like Swift and Go and whatever for CLI applications are just faster. They don't have to boot up a VM. But yeah, so essentially we're just trying to make homebrew faster instead of trying to rewrite it in another language that could potentially be faster. And there is a tremendous amount of tooling. That's the thing behind the scenes. Most people will just encounter one bit, but if you ever contribute and things like that, there's a lot of other tools that are all part of this ecosystem as well, I guess. So yeah. Yeah. And, and on that, before we kind of, I think this is a bridge question into workbrew. The project, I think, I don't know about any more, but certainly at periods of time was one of the biggest open source projects, however you measure that, uh, out there. Um, and so firstly, yeah. What is that like? Yeah. I know there have been challenges here, there and everywhere, um, throughout the project history, but yeah. What is that like? And this very much leads into workbrew in a second, but what is that like? Yeah. So, I mean, it's nice in some ways. Um, it's, it's funny. I had, uh, uh, opportune timing because, um, I worked from home in Scotland, in Edinburgh and over here, like tech's not nearly as big as it is in the U S and stuff. But I had a, a young lad come up to me in the gym today and be like, Oh, are you, are you the homebrew guy? Like, like, and he was like, Oh, I can't believe like a tech celebrity goes to my gym, which me being Scottish makes me like cringe unbearably. Someone's a flattery in public like that. Um, but yeah, so it's very, that part of it is strange, but nice, frankly. Like it's nice when I work on homebrew to know that like lots of people use this and that me spending my time on this stuff has a positive impact on other people. And people seem to generally feel favorably to it and enjoy using it and have good experiences. So yeah, that feels great. And, um, I still enjoy it, which is nice. I guess the, the flip slash slightly darker side to that is, you know, like being a large project, you get a lot of, um, hate from people like either people who are just frustrated because they hit a bug or because you changed something and they didn't read the release notes and now something that their work's broken or just people who, uh, frankly, there's a lot of entitled, uh, noisy whiners in open source who contribute very little and like to shout at people, make them feel bad. And my, one of my problems slash strengths is I have very little time for those people. And I just insta block them or like lock their issues, close their issues. I won't fix, I won't go on my way to spend my time fixing problems that are, you know, the people who are asking them or asking them in a, you know, borderline abusive way. And I'm also super protective of my maintainers and I don't want them to be treated that way either. Uh, so I guess that's the flip side of it, but you know, I, I guess I talked to another podcast recently about like open source and mental health. Exactly. And this year as well, I think you had a talk. Yeah. Yeah. So I, you know, this stuff comes up and I think for me, like I've, I would say I've never been burned out in the 15 years that I've worked on homebrew. I've probably not had more than a week or two weeks at most where I've not worked on homebrew in that time. And that's not because I feel compelled to it's because I enjoy doing it and I still enjoy working on it and I still value the people who use it and maintain it and stuff like that. And yeah. Yeah. Now, so this brings us to an interesting point. I may have been naive here because when I saw the, the, the work brew kind of announcements over the past sort of six to 12 months, and then I noticed, I think before that you were working at GitHub, I think. Yeah. Yep. Yeah. So I spent a decade at GitHub and this actually surprised me. So this is kind of, you know, a project of homebrew size and there are contributions and things. You've already mentioned a lot of infrastructure costs and I imagine they are pretty high. I was, actually surprised and maybe I'm naive here to see that that was the case, that you were working somewhere all that time, that there wasn't enough in the bank to pay one person, which took me by surprise. And it's somewhat damning of, I think the nature of something like homebrew as well, because he's largely a consumer open source project, not like something you could build a startup on, you know, traditionally. Yeah. So it's interesting. Like there's, there's pros and cons in some ways of that. So yeah, I guess it's funny because again, when I was at GitHub, the assumption most people have is that my primary job there was working at homebrew. And that was literally never the case. Like at, at most I spent, I think on maybe two occasions in 10 years, I spent two to three months where my primary project was something where GitHub needed homebrew to do something, homebrew needed something. So I was like, okay, cool. Can I spend some time on this? Um, but yeah, but most of the time that wasn't the case. And I just did it in my, I guess, you know, I did some of it during working hours, but you know, when you work from home for an American company, like what is a working hour or not a working hour, you know, it's a little bit, a bit nebulous. Right. And I think GitHub benefited from stuff I learned on homebrew, homebrew benefit from stuff I had on GitHub and GitHub were very heavy users of homebrew and GitHub, you know, paid my salary and also pay a lot of those expensive infrastructure costs that you mentioned are born by GitHub. Yeah. So yeah. Like, I mean, I don't, I guess like, you know, maybe I'm a, an older generation of open source kind of guy, but like personally, I don't see it as, uh, necessarily like a bad thing that the project didn't have enough money to pay me to work on it full time because I'm actually not sure I would have wanted that. Yeah. And like we're in the interesting middle ground as a project where we have essentially, I guess the way I frame it is like too much for stickers, not enough for a salary. Right. Well, we could pay someone a salary, but we couldn't look and say, okay, well, we can definitely pay someone a market rate ish salary for like years at a time. Um, without there being potential difficulties in that. So, yeah. So explain, I think, uh, again, probably the same question we began with, what is work brew and why is work brew? Why now? I think is maybe another question to add to that. Yeah. So work brew is essentially, we're building a commercial company on top of homebrew. So a pattern I'd seen again and again over the years working on homebrew is that you get big organizations with more compliance requirements, particularly who may have requirements to use stuff like MDM tools. They might have requirements that their users don't have admin access. They might have requirements around vulnerability mitigations or like SLAs or security reviews and things like that. And these were just things that homebrew, uh, either couldn't do or the homebrew maintainers who volunteers didn't have any interest in doing. Yeah. So it always seemed to me like there was a little bit of a commercial opportunity there and the time felt right for me and my co-founders, uh, formerly of GitHub to kind of enter the space and say, okay, well, the project's in a good place in terms of having like a decent governance structure and stability and good community, goodwill. And we're in a decent place in terms of like, it seems like a, a ripe kind of time to, to kind of try and go into this space and try and make homebrew better in this way for kind of enterprise customers. So, yeah, so that's, that's sort of where, uh, aligned and what workbrew looks like today. We're in private beta. We're going to go into public beta very shortly. And basically right now we're, uh, a like fleet management tool essentially for homebrew that kind of glues into your MDM tools. So you can run any homebrew command and configure homebrew on across all of the machines in your fleet, uh, in the same way, basically. And we have a slightly security enhanced version of homebrew where we're running things as a different user in like a different sandbox and stuff like that. And, but for the end user, it essentially feels exactly the same as as using homebrew normally where you just, you still run brew commands in a terminal and you get things working the same way. It's an interesting idea because yeah, that macOS sort of has a handful of these somewhat, um, there's a couple of the commercial MDM tools. I have used some of them being employed by also American companies at a distance in the past. Uh, and also I've also worked at companies that had like a weird assemblage of like a puppet scripts and things to do something similar. But there's always, it's MacOS and Apple have periodically had their own solutions with profiles and things which kind of come and go in terms of their enthusiasm for them. But there's never really been anything that cohesive that you would get on, on windows. And it's actually interesting that you, you know, I would say a lot of developer focused companies, it's highly likely that the engineers on Mac are using homebrew anyway. So, so it's an interesting play. Well, and there's an interesting other place where the, um, that almost like the cart and the horse being flipped here where there are some companies where due to their compliance requirements, they can't have developers using Macs. Right. And they've contacted us saying like, Hey, we have all these developers who want to use Macs. Our compliance requirements mean like ISO 2701 or whatever that they, uh, they have to have software be approved before it can be installed on their machines and stuff like that. And that means that they can't use homebrew. Like does workbrew have a solution to that? And we're able to say, yeah, we do have a solution to that. So the, the interesting thing that I didn't really think about when I was getting into this is it's not just upping the security profile for the people who are using homebrew in these bigger companies, but also enabling more people to use homebrew who want to and maybe use it at home when they're hobby projects, but aren't able to use it at work yet. Yeah. Yeah. Yeah. Just on the subject of the MDMs, like a lot of the ones I've used tend to to have their own kind of app store that you install from. Um, so how have you found integrating with those? Like, are they open to integration or are you kind of almost seen as like a competitor to their own internal tools? No, no, I don't think we're competing with those MDM tools. So they're, they're like in their app stores are, um, I mean, I can't speak for all of them, but the ones we've been in contact with seem to be happy with us kind of wanting to integrate with them. And it feels like it's win-win there because we're kind of solving different problems in some ways. Like, you know, there's some overlap. You could obviously use homebrew to install some of your software there, but generally the way people are using MDM tools, they're leaning on their MDM tool to do more of this stuff and homebrew to do less of this stuff. But there's some kind of nice blurred lines there and they'll allow us to kind of be value add where you can use us and an MDM tool and kind of get more value out of using both than you would out of just using us separately. Yeah. Um, and, uh, you, we, we, you kind of hinted at it, but this like immutability idea, I think that relates to the rollout, I guess, you know, um, something comes pre-installed that on boot runs through a bunch of brew scripts to install and set up. Yeah, exactly. So right now we're primarily focused on building something for kind of security and IT professionals where essentially the, I have partly working in, I worked on internal and external developer tools almost my entire time at GitHub. And I've worked on homebrew obviously for a while. So I have like a very high bar for myself and my company and everything like that for developer experience. So for me, like using homebrew should feel just as good, if not better, uh, when you're using it under workbrew as when you're using it without workbrew. So like that essentially for developers, the experience should be the same. And then we're building something where for security and it professionals, it's like dramatically better because workbrew does, sorry, homebrew does not play nicely with these MDM tools out of the box and workbrew does. Um, and we have very decent integration, but yeah, over time we're building more and more in the kind of developer space as well. So we don't have anything kind of ready for announcement or release yet there, but we definitely, I worked on some of these problems at, uh, GitHub and like a common complaint that people have with homebrew, for example, is because it's a, what you call a rolling release package manager, which essentially means homebrew will always try and be on the latest version of everything that it's not compatible with how most companies work. Most companies want to have everyone on the team be at least, you know, even if they're very upgrade happy, they want to be able to say, okay, well, let's upgrade everything for everyone on the team at the same time. And homebrew with brew files doesn't really let you do that yet. Um, and that's on the workbrew side, like that's probably our biggest developer centric problem that we're solving is we don't, as I say, we don't have anything ready for that now, but like the, the problem that we are aware is there and that we are, we have some early plans working on that is to essentially build something where you're able to kind of lock things down in that way so that you are able to protect versions like that. Interesting on that, because I noticed you, you listed on a feature list, like a, the console and you mentioned the kind of security and auditing that kind of thing. Um, does this go as far because I don't think core homebrew has this concept either, but introducing things like, you know, CVEs and vulnerabilities detected in packages, and that will also be a feature in homebrew? Yes. So that's, that's a feature we're building in workbrew. So you're right to say that there, there are some sources out there that provide, if you go looking, you can figure out kind of what CVs are in what homebrew packages, but there's an awful lot of false positives and false negatives in there. Um, and one of the advantages we have at workbrew is we're building this in a way that, um, because we have homebrew maintainers, for example, who work for us, that people can really benefit and the community will be able to benefit from essentially us using this information. But then our customers have a flow to be able to say, okay, this thing is right now outdated and very shortly if you have a CVE and then you can press literally one button to update that package over your entire fleet of devices and monitor which devices are on which versions and stuff like that. So, um, not that in any way I would will us another heartbleed or other like horrible vulnerabilities where people have to upgrade everything at once, but we will inevitably get to another one of those cases. And, um, my experience has been in the past, that's when poor Mac admins who themselves may not even use homebrew are put in a situation where they have to like hack together some script like yesterday to upgrade all their devices and then they find homebrew doesn't want to play nicely with their MDM provider and whatever. And instead work in those situations for our workbrew customers, it's like, okay, well, you go into the console, you click one button and then in 15 minutes, assuming the devices are on, they'll be updated to the latest version. So it makes, it makes people's lives a lot easier in those situations. Yeah. I'm interested to know how that kind of relationship works because homebrew has generally been a user, uh, initializes, whereas in this case you kind of have to have some sort of agent saying, Hey, initialize, you know, so it's a different dynamic as well. Yeah. Um, and are you planning a Linux version? Does it not make sense for workbrew? No, I mean, we're, we have our, uh, our eyes and ears open with this stuff. I mean, as you would expect for a kind of relatively early stage startup, we have lots of plans, but then the plans are, um, very heavily influenced by what our customers are interested in. And yeah, we're going to have, uh, we definitely have some customers who are interested in us having more support on Linux and we have essentially internal internally. Most of this stuff is already working for Linux, but we just haven't packaged it up nicely and made it an official kind of thing that we claim to support. We're definitely seeing most of the demand is on the Mac side right now, but on Linux and you know, who knows maybe one day on windows, then we have the potential to kind of support more of these things. One day homebrew and chocolatey will merge. That would be cool. Who knows? Stranger things have happened. Um, and, uh, if you don't mind me asking, like what is the, what has been the kind of the, the, the less tech side of things? Did you receive funding? Was it bootstrapped? Uh, how's that side of things going? Yeah. So we're, we're not ready to kind of announce things fully on that side. Um, but basically, yeah, we, we're kind of, um, yeah, we're just building, building the company, how we kind of think is best at the moment. If, you know, if you're the type of person who goes digging on the internet, you can probably find out more than I'm telling you now. But, uh, yeah, for now we will announce more in future, but for now we're sort of doing that stuff. And, uh, I feel like some people might ask as well, because, you know, this sort of relationship you've had, um, as you mentioned earlier is a more old school open source journey where, uh, you worked on something for a long time for the, the main motivation to make something good. And then later kind of thought, hmm, maybe I can monetize this. Whereas a lot of modern startups kind of look the other way with open source. Um, so the other question would be, do you anticipate, and then maybe it's too early to say anything from work brew actually rolling back into homebrew? Oh, I mean, already there's been many things actually that have gone into, into homebrew. So when you use workbrew and you run brew install on your machine, you're not running a fork of homebrew, you're running homebrew itself. So there's a certain amount of functionality that is just necessary that it goes into homebrew. But, uh, the nice way, I mean, as you said, well, I have been involved with open source for a while. I maybe have a little bit more of an old school ethos, but, um, one of our biggest principles as a company, um, and this comes from my CEO, John Britton, who says this one time, and I couldn't agree more is not to give away things today that you're going to have to take back tomorrow. Right. So, um, there is, there's a, there's parts of work brew that in future, they may that today you have to pay and in future might be free or open source or whatever, who knows. Um, but right now we're making sure that the stuff we do do is like tightly separated. And again, similarly, like everything in homebrew is open source, right. And we'll open, homebrew will be an open source, probably primarily volunteer run community run project forever. And, um, work group will probably be a for profit commercial enterprise, um, forever. At least it's nice and clear, I suppose. Yeah. And the separation there, because I mean, like without naming two specific names, obviously we've seen a lot of churn in the last few years of, um, various companies who made licensing decisions five or 10 years ago, which have now changed quite dramatically and had generated quite a lot of community backlash. And you know, I, I'm very sensitive to that. And I am a little bit of a open source purist in the, I still consider, you know, the open source, um, initiatives definition of open source to be what open source means. And if you don't comply with them, then you can be another thing, but I think you're probably not open source. Um, and if you go looking again, sniffing around work group stuff, you will see that we've generated a lot of open source contributions to homebrew, but we as a product ourselves are not open source. Um, and for me that, you know, there's, there's pros and cons of doing things different ways, but I think that we're doing things in a way I feel that is most respectful to the community, um, and most respectful to the maintainers of homebrew and the people who've got it to where it is today, where we say we have these separate entities and work group and homebrew are very good friends, but right now at least they are separate entities and they live in different houses and I'm the CTO and co-founder of work group and I'm the project leader of homebrew. So like that helps to avoid the falling out between those two things. But even then, like me being a project leader on homebrew, that's an elected position. I stand for an election every year and get elected by, um, the maintainers and other kind of wider scale community people. So yeah, it's, I think there's a nice, uh, separation there. And it's, it's funny, even the, the people who kind of are homebrew maintainers and work with us on workbrew, you know, one of the things I say is that, you know, I, when we're working on workbrew, I'm your boss now, but when we work on homebrew, I'm still not your boss, right? Like if you think I'm saying something and it's a bad idea, you tell me it's a bad idea, right? Like that's things don't change there. Cause I think that's how open source works the best. And if anything, I was very inspired by early GitHub that behaved a lot. Like, you know, there was some minor dysfunctions, but you know, it behaved a lot like working in open source community and an open source project where there was not as there was not a focus on hierarchy and I've been here longer. I know more, whatever. But instead it was a kind of fairly open marketplace of these types of discussions. And I felt like that made the product a lot better. And I think that's the case for homebrew as well. One final question, if you just have a couple of minutes, um, just sort of more on the, the, the European side. Um, you mentioned obviously where you are already, there are a handful of, uh, I think reasonably moderately well-known open source projects around the kind of Glasgow Edinburgh area. Um, what's, so yeah, what's it like in open source in Scotland in that, I don't know if Scotland refers to that area in a particular way, but in that, in that, uh, in, in that part of the world, what's it like? Well, so in Scotland we would call like the Glasgow Edinburgh area, the central belt because you almost like have a belt of almost continuous towns and transport and whatever between the two. But yeah, it's funny because, you know, it's such an international world nowadays that, I mean, those open source projects, the funny thing is you probably have a much better idea of what projects are in Edinburgh, Glasgow than I do. And half the time, you know, I'll be at some conference and chatting with someone and I'll have known their work on open source for a while. And then we're like, oh, turns out we live like five minutes down the road from each other. And I had no idea because, you know, I'm going by, you know, in a funny way, like, you know, GitHub feels, GitHub.com feels more like the place I live when I'm doing open source than, than Edinburgh in Scotland. That just happens to be the place where my, my body inhabits meat space, you know? Okay. Yeah. Um, yeah, I, I must admit we have been to Edinburgh and Glasgow, and I think I prefer Glasgow just because it's a bit bigger and a bit more lively, but... Oh, well, I'm glad you said that at the end of the conversation because, you know, I don't know if we can be friends now. Both are very nice, but you know, Edinburgh, I'm going to sound a bit odd here because I don't live there, but Edinburgh was like more tourist and Glasgow felt more like, it's also way bigger. I didn't realize how much bigger it was. Yeah, that's probably fair. I mean, Edinburgh is definitely more of a tourist city, but you know, as a, well, I've lived in Edinburgh most of my life. I was raised here and grew up here and whatever. So there's, unfortunately I'm bound by my, uh, geography that I can never admit that Glasgow is better for essentially anything, except maybe like music. Also a huge, and I'm going to use the American term just to make it easier for people to know what I'm talking about, but I'm a huge Scotch fan. So, so that, okay, is, is there anyway. Single malt whiskey. Yeah, pretty much, pretty much. There's actually a very nice bar, I remember, in Edinburgh that I took my friends to when we were passing through last year after a, after a, um, a space site trip, actually. So, and I can never remember the name of it, but I know where it is. So good. Awesome. Well, Mike, um, keep things going because I know a lot of people rely on, on the project, uh, and probably a lot of listeners. So yeah. And good luck with, with work brew. And I look forward to seeing what these announcements may be that you alluded to. So awesome. You will see. Thank you very much. Keeping it all a bit mysterious for now. Thanks Chris. Have a good And rather appropriately and excitingly, I can now see that these announcements did result in something. There is now a beta self-service tier for work brew. They've also changed the, the logo and the look a little bit. There is a free tier, a pro tier and enterprise tier. So things did eventuate into months. So sometimes it can pay to wait before you release something. That's going to be my justification and excuse. Anyway, news from me. Well, I have a couple of new videos up on YouTube, including a roundup of text editors and IDs for Mac OS. Also the first part of my new drumming video series. And there's some other things I'm still undergoing a few bits of change. Sort of November is going to be where I launch a few new things and things will maybe get more interesting. I don't know who says. And I will also be on the road a little bit in November. I'm not doing quite as much as in September, but I'll be back at Web Summit. If any of you happen to be there, I always end up meeting a lot of people there. And I'll also be at an event in Cambridge and Lincoln of all places in the UK, private events. But if you happen to be around in those places and want to have a chat, then do let me know as always much more over at kristenchiller.com. I have been Kristen Chiller. Thank you for joining me in the Tech Lounge and take care, everybody. So that was it. That was our guest today. Thank you very much for joining me in the Tech Lounge. I have been Christian Chiller. If you want to know more about Tech Lounge, head on over to kristenchiller.com or please tell your friends about us. It's quiet and cozy in here, but the more listeners, the merrier. You can find more at kristenchiller.com/podcast or in the show notes or episode notes, wherever you found this podcast. Thank you very much for joining me and you're most welcome next time. Thank you.

Hey, this week David joins me and we talk with John Britton and Mike McQuaid about Homebrew, the package manager that macOS is missing, and Workbrew, the new commercial offering built on top of it. It's a lot of fun, you don't want to miss it, so stay tuned. This is Floss Weekly, episode 796, recorded August 13th. Homebrew, I'm more of a whopper guy. Hey folks, it's time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett, and we've got something real fun today. We've got, first off, David is in the secondary hot seat, the co-pilot chair. He's my wingman. He is the co-host today. David Webham. I'm holding it down. I'm holding it down. Yeah. Now, today, our topic is, well, it's Homebrew, which is the package manager that macOS wishes it had. And neither of us are big Mac guys, are we? No. I use it at least once a week, but not extensively. So, yes, I have lots of questions that will be the Luddite type. You're our audience proxy for, I don't know much about this. That happens. That's fine. I have, I've actually used Homebrew back years ago. We were talking about before the show, I was a part of an organization and someone else that was there was a huge Mac fan. And so, they bought some Mac machines. And the whole time I was going, he was associated with the military. So, the whole time I'm going, I know he's going to move away and I'm going to be the one stuck administering these machines. And guess what happened? Yeah. I was stuck administering the machines. So, I installed Linux on one of them and I installed Homebrew on the other. And we made out very well with that. So, I've got a little bit of Homebrew experience and a little bit of Mac experience. But, you know, rather than us talking about what we know and don't know about the project, let's bring the guys on. So, we have John Britton and Mike McQuaid. Let me see if I have this right. John is the business guy and Mike is the homebrew guy. Is that sort of the way the land lays here? Yeah, I don't know if John likes it put that way, but I'm fine with that discussion. Yeah, I mean, I definitely wear more of the business hat, but I'm also a software engineer. So, you know, being called a business guy is a little bit rough. Right now, it looks like you're wearing the Tron hat. Yeah. I like it. So, first off, how did we do about Homebrew? Let's start there and then we'll get into this kind of the business thing that's going on. But I want to know first, let our folks know. And so, obviously, this is probably a question mostly for Mike. Why would somebody use Homebrew? What's the point? So, my, I guess, description for non-tech friends and family is generally Homebrew is a app store for open source software, essentially. And if they want to get deeper on that, you can go down the line, the fact that it's mainly both the software installed by Homebrew and Homebrew itself are primarily operated through the terminal. So, yeah, basically, that's the starting point of why you care about Homebrew. Yeah, and it's, it's all, is it all open source? Like, so, I'm pretty sure that Homebrew itself, the entire thing is open source, but all of the software that you go out and grab. Now, how much of it do you build from source at install? It almost seems like that's one of the things that you at least can do. Yeah, so that's a differentiation between kind of two parts of Homebrew, like the original and some stuff that's come later. So, originally, Homebrew was, everything was built from source on the user's machine. So, I guess you would call it like a build from source package manager. And over time, Homebrew decided that we were going to take more of that open source software that was built from source and build it ourselves. And then now we build everything ourselves. So, most users, most of the time, are going to be given a pre-compiled binary package, what we like to call a bottle, because everything in Homebrew has like a beer metaphor running through it. But then, over time, there was a project that, it started off as its own separate project, but it's been brought into Homebrew proper, now called casks. So, we have things called formula, which are used to install things from source, which are open source software. And then we have casks, which are used to install software that is a binary that we get from somewhere else. So, a classic example of a formula might be something like WGET or some other command line tool you're used to interacting with, or MySQL, or Database, or whatever. And then a classic example of a cask might be something like 1Password, or Google Chrome, or Zoom, or something like that, where essentially the flow otherwise would be download from a browser, click, click, click, whatever. How long has Homebrew been around? Like, when was the initiator of this idea? When did somebody first start writing code to make it happen? So, yeah. Homebrew turned 15 this year in May, if I remember correctly. It was created by a chap in London called Max Howell, who was working for Last.fm at the Oh, interesting. That may bring back memories for some of you. I'm sure they still exist, but, you know, less widely used nowadays as they once were. So, yeah. He basically was exploring different package managers, and he could never find one that kind of quite met his needs. And I think he was nudged by someone in the pub one evening to go and, well, you know, if you hate them all so much, why don't you make your own one? And he did. And that's the future, really. So, yeah. So, that was 2009, and then I got involved with Homebrew later on that year, like, I guess, September 2009 or so. Max was a friend of a friend in London, and I heard about it, and I was also dabbling in package manager things, and I sort of just started contributing and never really stopped, So, yeah, 15 years ago. Is Max... I was just going to say, a couple of months ago, we had Max over, and we did a live stream kind of going through the history of 15 years of Homebrew as well. Oh, okay, cool. So, is Max still involved with the project? No, he's doing his own things nowadays. Sure. He was involved for, kind of, I guess, maybe five years at the beginning, and then he sort of handed it off to others. Yeah, that's great. It's one of the problems we see with some open source projects, even really popular ones, where somebody starts it, and it's like, well, I guess enough people like it that I'm stuck here for life. And so, genuinely good for him that he was able to get off the boat and that the boat didn't crash. Congratulations. Your open source project is successful. You have an unpaid job for the rest of your life. Ah, yes. Well, it's a huge problem. It really is. And, you know, there's the classic XKCD comic. Like, you have this whole, you know, massive software stack, all the building blocks, and you have this one little piece that holds everything else up. And it's like, this is just maintained for nothing by one guy in Kansas. And the scary thing is, there's multiple projects like that. Like, you can talk about the network time protocol has been that way for the longest time. Even things people don't know about, but are super important, like the term info files. And there's legitimately only like three people in the entire world that actually understand term info, I think. I'm fully convinced of this. But, you know, if those break, we're all in trouble. So, let's, this seems like a good place to at least dabble in the concept. I've heard of something called Workbrew. And it is apparently related to Homebrew. And it is apparently also you guys. What, and this is probably, if I understand the lay of the land correctly, this is a question What is Workbrew? And why are we trying to do it? Yeah, so, Homebrew is, you know, insanely popular, used on macOS. There's more than 30 million devices with Homebrew installed. And it's pretty much made to be a single player experience. You sign on to your machine, you open up the terminal, you install some things. It's all managed kind of on your machine. And what we're doing with Workbrew is trying to make it so that it's more of a multiplayer It's built for teams. It's built for companies so that you can have kind of a shared set of developer environments across all your machines, a shared set of policies, a shared way to manage and deploy and install, get analytics and observability, know what's going on within your fleet, and keep everything secure and compliant. So what we're building now is really focused on how teams are using Homebrew day to day and trying to solve their major problems. So I think, you know, maybe Mike, you want to say a little bit more, but I'd say that's kind of the starting point. Yeah. Yeah, no, I think that's a good start. Now, is Workbrew open source as well? Workbrew is not open source. We're built on top of Homebrew. I like to think about it as kind of complementary. So at the foundation of Workbrew, we're using Brew, the open source package manager. We don't have a private fork. We don't have our own custom version. It's exactly the same as the open source project. But on top of it, we build a bunch of complementary tools for deployment, analytics, remote management, security and compliance, those type of things. And our approach, I think this is actually probably the topic that's worth getting into in a podcast like this, is our approach to commercial software in an open source world. So as you know, Homebrew is an MIT licensed open source project. BSD. BSD. Apologies. BSD licensed open source project. And we basically upstream all of our changes that are necessary. So anything that needs to be available inside of Brew as the core kind of foundation, we make Then there's kind of a line, and that line is pretty well defined. And it's multiplayer. It's enterprise, like kind of security and compliance features. It's managing remotely. It's all of those types of things that are on top of Homebrew that are closed source. We don't make that available open source right now. Yeah, and that makes sense. I think it's going to serve you well that you've figured out that line and you have a clear delineation and you make it clear up front that like this is the part. That's always going to be open source. This is the way we're going to manage that. And then this is the part that we're going to build on top of it that's not. And at least I, as a potential user, I really appreciate that. And so do you generally pull from the same like list of packages? So from what I understand, WorkBrew is going to be doing much the same thing. We're installing extra packages on Mac. I think something that's useful to explain about Brew is kind of the two components. One component is the CLI. So it's the actual package manager responsible for putting software onto your device. And then the second kind of component is the packages themselves. The library of, you know, as Mike was saying, formula and casks. The Homebrew project has two official kind of package repositories. One's called core and one's called cask. In Homebrew core, you'll see all of your built from source packages. And in cask, you'll see all your binary distributions. A lot of that stuff may not be open source. Some of it may be open source to distribute as a binary from the upstream vendor. But ultimately, you have those two components. So when it comes to WorkBrew, you're still using Brew, the open source package manager. And you're still able to use the library of packages that are available for Homebrew in core and in cask. But you can also create your own taps, as they're called in Homebrew speak, that are repositories of your own internal packages distributed within your organization. And you can kind of set rules and manage how that stuff is done at an organization level. So that's kind of where the delineation is. Oh, yeah. That makes a lot of sense. Yeah. David, I'm sure you're chomping at the bit. We haven't let you got anything in yet. So a couple of questions just from listening to you there. The first one, I noticed that you refer to Brew and Homebrew and WorkBrew. So what are the, like, is Brew core to both Homebrew and WorkBrew? Or is Brew and Homebrew synonymous and just a shorthand? I'll get this one. So essentially, like, we often use Brew as a shorthand for either Homebrew or WorkBrew. Because Brew is, that's the CLI command that you type in to your terminal if you're invoking Homebrew or WorkBrew. I guess to jump back a little bit, because it might be interesting. Again, like, the approach that we're taking. And it might explain how things fit together. So essentially, the flow for WorkBrew is you run our installer. And our installer installs some WorkBrew stuff. And it installs Homebrew. So Homebrew is installed completely normally to the normal location. But we just do some stuff where if you were to go and say that to the Homebrew open source project, they would be like, why would you do that? But because we have a bunch of Homebrew maintainers and people like me who have worked in Homebrew for 15 years, like, we can do some slightly more unconventional things with Homebrew. But on your system, you still have a completely unpatched, normal, open source version of Homebrew running on your system. But then we have essentially, like, a wrapper that we have on top of that. So when you run Brew and you have WorkBrew installed in your system, you run WorkBrew, which then calls into Homebrew. But the essential behavior for end users is it looks exactly the same. So I guess John talked on this earlier. Like, me as a kind of long-term lover of open source software, I kind of like this approach of kind of combining the two because it means that both the open source software, Homebrew, gets better over time. But also we have the way, as John mentioned, like the realities of kind of making commercial software in an open source world where we can't give away everything for free or it wouldn't be a business. So, yeah, I think you get the nice best of both worlds. And the other kind of fun, I guess, analogy I've used with this stuff is it's like, my apologies to John, who's heard this particular analogy about 8,000 times, is it's like Lego, right? I don't know how much any of you are playing with Lego nowadays, but one of my kids is super into it. And Lego now feels pretty different to what it used to be, where I remember there was a lot more modification of models and stuff like that. Whereas now it's like a pretty hard line between like the super customized, this Lego T-Rex comes with a particular claw that is made only for this one piece and you can't use it for anything else really. Or you just buy a bucket of blocks and you assemble it and make it up yourself, right? Like essentially what we're doing with Workbrew is if you look through the pull requests that are opened by me and other people in the last year or so, you can probably see the blocks of how you could go about building your own Workbrew. But I guess our value proposition is essentially like, well, we built it for you and we can support it for you and everything like that. So, you know, maybe you're better to buy it off us. But the open source project still has a lot more of these kind of like hooks and things that you can plug into that makes the open source project better and more useful for people as it goes along. Yeah, absolutely. And the next question that I had, as I already established at the opening, I'm not a great, I don't have a lot of Mac experience other than some user. And I've maybe have used Brew once or twice, but I do have Linux experience, an open source experience. And so kind of relating Brew to package managers I'm used to, I have two questions and you can answer them however you desire. The first one is do you have package maintainers that are responsible for specific applications within, you know, that homebrew would pull down? And then the second one is you mentioned taps as something you could do inside your corporation as kind of like your own repository. Are there publicly available taps that are like maintained by people not directly related to homebrew? I'm thinking of kind of like PPAs and Ubuntu. Yeah. So in terms of package maintainers, I guess that's an interesting thing with homebrew is that we don't have specific package maintainers. We have like somewhat officially, unofficially people who might maintain individual packages, but the maintainers of homebrew are relatively few. So we've got, I think, 30 something people right now. And between them, they essentially maintain everything. But that doesn't mean that they do everything. Because homebrew was built with GitHub and collaboration in mind from the outside. I think Max on the video call that John mentioned earlier that we had to kind of talk about it, like one of his things from the outside, I'm sure he won't mind me saying this if he didn't use this exact word, was essentially to be lazy and be, okay, I don't want to maintain everything by myself. So how can I build this from the outset such that essentially the community maintains this? And I don't. The other difference we have nowadays is we have very, very, very heavy amounts of automation to essentially detect changes and keep things up to date and things like that. But I guess to specifically answer your question, no, we have a slightly different model where we don't have like hundreds of different people who each maintain one or two packages. We have a small number of people who maintain everything and like review community contributions to all of those things. The next question about taps. Yeah, we have essentially the tap model is very similar to a PPA model or something like that, where any arbitrary person on the internet can just decide to set up a tap. And then by default, the easiest flow is having them on GitHub, but really you can put them anywhere where you can have a Git repository. I mean, technically, they're just a folder on a disk. So any way that you can get a folder onto a disk and keep it relatively in sync, you can make that a tap. And they behave much in the same way, regardless of whether they're being maintained by homebrew ourselves or whether they're being maintained by the community. It's more just like we set a higher standard for like both the licenses and stuff like that and styling and, you know, making sure our best practices are followed that the community don't have to do and may decide they don't want to do, may decide they can't be bothered to do. And that's basically how that kind of ecosystem fits in. So one follow-up question, how many packages is everything? Right now, I think it's about 20,000 between all of the formula and all of the casks. So 20,000 official ones. So if you go wider onto all of the third-party taps and stuff as well, there is probably considerably more than that. But basically, at least 20,000 or so. That's astounding. Yes. Especially for a small team, as you have maintaining it. And you've mentioned casks several times, which I understand because you've explained that. And you talked about formulas. But I've heard references to bottles. What are bottles? And how do they relate? So a bottle is basically like the original, as I mentioned, way home we worked. It was a build from source package manager. So the formula, I guess, it fits more, obviously, in the metaphor in the original stage. In a formula, if you imagine a formula for a beer, it might say, you know, I want, whatever, I don't make beer. Like some sort of liquid and some sort of not liquid and mix them together and you get some sort of beer. So essentially, a formula is a series of build instructions for like how you take an upstream source. So like, say, something like Wget, the tarball containing the source code for Wget, how you would go and run various instructions on your machine and produce a binary at the end. So what we do nowadays in Homebrew is that formula for most of the people most of the time is only essentially used for building a binary package on our servers. So when that formula is modified on GitHub, then we will run through those instructions. We will build a new bottle, which is what we call the tarball that contains the binary package. And then we then upload that to, we use like GitHub packages to store our, all our binary software, basically. And then when a user types brew install on their machine, instead of doing through all those steps, it will essentially just download that binary package, that bottle, and it will pour the bottle, extracting the tarball, into the place on disk. And then a user can have that up and running. And for, you know, for smaller things, the time difference is minimal. For larger items, if you have a relatively normal slash fast internet connection, you can, you're talking about the difference between, you know, less than a minute versus, you know, even on high end or hardware, like four or five, six hours to compile some of the really big meaty stuff. So it can be a huge time saver for certain people and users. And it's also a lot less hour prone. So somebody had a lot of fun coming up with that extended metaphor and figuring out all the ways that it fit. Well, the bottle's name, I came up with that. So if you want to blame anyone for that particular strange metaphor, that's me. And then most of the original stuff was Max. Yeah, you can definitely tell that this was developed on a napkin in a pub. Yeah. They were looking around the room, creating parts of the infrastructure. Yeah, the first commit ever to homebrew is interesting. It's something I actually, I did a bit of at GitHub when I worked there as well. And I recommend it for people when they're doing projects. It's this idea of like readme driven development. I don't know if you've heard of that before. But the idea being before you start a project, essentially start by writing the documentation of what you think it should look like and how it should work. So thinking from the outside in. So that's how homebrew originally worked. And if you look at the first commit to homebrew, the first commit is actually a readme of how homebrew works, despite the fact that there's no code at this point. And yeah, and the last question in the readme is, was homebrew conceived while under the influence of alcohol? And the answer is yes. Wow. That's great. Both Unix and Linux were conceived under the influence of various substances. Yeah. It's true. It's true. All right. I'm going to jump in and I want to ask John a couple of questions about Workbrew in particular. And let's see. So I'm assuming that the way we could set this up is a business would say, look, these are the packages that we want to allow people to install on their machines that we're in charge of. And then we have this whole other block of packages that we don't want to allow. Like that's the sort of tooling that you guys give with Workbrew, right? To some extent, I think like I would actually preface it by saying that for us, the most important thing is a developer experience. Brew is kind of a tool, a tool belt for software engineers. They go to Brew and they get all the things they need to do their jobs. The reality of the situation is that companies, especially in highly regulated industries, you know, we talk to a lot of banks, a lot of, you know, fintech type companies, governments, insurance companies, healthcare. The rules of the road there are just you have to do certain things a certain way. And so rather than think about it as a way to limit folks and what they can do, it's more a way to enable developers to continue to use the tools that they know and love at work. So we think about it as without Workbrew, the people in those companies would be told, no, sorry, you can't use Brew. It doesn't meet our security and compliance requirements. And so with Workbrew, what we do is we make it so that the IT folks, the security folks are able to feel comfortable with the risk profile of giving end users, developers the ability to go out and install 20,000 different open source packages. And in some cases, you know, especially the financials that I talked to, they have some requirements around things like data protection, data loss protection. So they don't want to allow anything that opens up tunnels in the network. So particular VPN packages, WireGuard, you know, NGROC, stuff like that, where, you know, they're honestly like useful tools that are not necessarily nefarious, but because of the risk profile of those businesses, they just can't allow it. And so that's really where the kind of security and compliance type of, you know, restrictions come in in Workbrew. And with every customer that we work with, we talk to them about, you know, the developer experience and how they can maintain a positive developer experience. And instead of, you know, using hard and fast rules, setting policies that they can monitor and see if something is out of policy. So every user that we have, generally the way that they come on board is they do a complete audit of every package that's installed on every machine via homebrew. This is a huge amount of information for them. They had no visibility previously as to, you know, let's say they have 500 engineers, 1,000 engineers, what packages were being used, what their, you know, potential surface area for attacks was, whether it's supply chain attacks or, you know, other kinds of data loss or things like that. So they can do an audit and they can see everything that's happening. And then once they have that information, they can take steps to provide alternatives. Rather than just say, hey, this is turned off, you have no access. We give them a way to say, hey, the preferred tooling for this job is X. And we really are excited about the features around kind of collaborative developer environments for software engineers. So the idea is that rather than each person in kind of a single player mode managing their entire kind of development stack themselves, if one person finds a problem, whether it's a security issue, a productivity thing where they can move faster, when they make that change, they're able to share it with their entire team, you know, seamlessly. So that's, that's some of the ways that we think about, you know, the same thing that you were saying, but really from a first principles, you know, mindset, why are we doing this? Sure, sure. Does either workbrew or and or homebrew provide like automatic updates? Or do you have to go in and say, all right, all the packages I've installed, go check for new updates and install them? I mean, the short answer to that is kind of, it depends what you want. This is another one of kind of the principles that we're trying to follow, which is one size doesn't fit all. We have, you know, these fast moving tech companies that really want to embrace the cutting edge, and they always want to have the latest version of everything all the time. And on the other hand, we have, again, these highly regulated industries where they say, I know that a release came out, but we cannot deploy that new release into production until a human has reviewed it. They've created a signature, we've entered an entry in our audit log, and we've allowed it to enter the production environment, right? And so these are two polar opposites. So our principle here is like, one size does not fit all. We want to give people the ability to kind of choose how this should work. And Mike can talk about, you know, homebrew's auto-updating facilities. Yeah, I'm curious about that too. Mike, I'll let you take it for a minute. And what's the solution there with homebrew itself? Yeah, so homebrew by default will basically, almost every time you run a significant command, it will auto-update itself. And it will try to ensure that it always results in a consistent state, which involves, it will do things like auto-update, auto-upgrade, like reverse dependencies, and all this type of stuff. So I guess in general, like homebrew is a developer tool. Like my thinking is, if you ever are having to have in tools a thing where you say, oh, if you run this command, make sure you run this command afterwards, then that's generally not very good UI, right? So my goal is over time that homebrew, essentially, you can just get away with installing software and everything else that you might need to do, running updates, doing cleanups, upgrading things, getting rid of things you don't need anymore, auto-removing things you don't need anymore. Like all of that stuff is done fairly seamlessly and automatically. And I guess another note related to a couple of things that came up before, I guess we haven't mentioned explicitly in this call before, but I would be sad if I were not to mention the fact that homebrew also runs on Linux, which is, it makes me slightly strange as to why one would ever want to do such a thing. One of the cases we've seen on Linux is, I guess, what John mentioned earlier, where one of the things with homebrew, because it's a rolling release package manager, which essentially means when homebrew can get the latest update of a thing and it works and it doesn't break homebrew stuff, then homebrew will upgrade to a newer version. We've seen people using a more stable base layer OS, like Debian, Ubuntu, whatever, and then they might install homebrew somewhere on their system on Linux and then they can get access to kind of maybe the bleeding edge for certain developer tools. Like if you have, I don't know, like a classic, like CLI I love is RIP grep, it's RG is the command and it basically just does really, really, really fast recursive grepping through folders and stuff like that. It's what VS Code uses for file finding text and files. And so a tool like that for me, it's like, I, if I'm on a Linux machine, I get frustrated if I have to wait, you know, like months for someone to get me the newest shiny version of RIP grep. And also the, the blast radius, if it, if it doesn't work, then it doesn't really impact anything else in my system. So then you, you can get this nice combination. And in a funny way, that's sort of how homebrew works on macOS as well in the, the, the reason why I'm drawn to macOS is because when I was using Linux, uh, I'm too much of a tinkerer and I would just continually breach my system by being like, oh, if I, if I increase, I'm sure my age a little bit here. If I change X.org settings to do this, then maybe the refresh rate will look slightly nicer. Oh no, no, I'm stuck in a terminal for 24 hours and all this type of stuff. Whereas the, for me in the macOS world, like essentially Apple have like nailed down that, um, that trunk of my, or bonnet, as we'd say over here to my car. So I can't get inside there and that's for people like me, that's better for other people that's worse, but you can sort of have a, I'm more Mac like feeling with your package manager if you run homebrew Linux in that way. Yeah. So I was going to, I was going to ask about, I have a little note here on my notes to ask about running it on Linux. Um, so this, there, there's a question that obviously follows up. Uh, can we run workbrew on Linux? Does that make any sense? Yes, but, uh, I would say not yet. Um, this is something that we've talked about. I've had definite, definite interest, um, from folks we've been talking to just have consistency across all platforms, the ability to see what's happening everywhere and be able to remotely manage them. Um, we don't have folks using, uh, workbrew on Linux today, but I expect we will in the near future. Okay. And now we have internal prototypes basically. We have not yet released for work, but I mean, essentially homebrew works similarly enough in both cases. And our internal prototypes are, it's the type of thing where it's the classic engineer thing of, uh, if I was earlier in my career, I would say, oh yeah, we could have a Linux version out in a couple of days because it all compiles, right? Like it, that's, that's the easy bit. It compiles, what could go wrong? Exactly. I, I've learned enough over the years that I'm like, well, you know, there's, there's probably more, the iceberg here is perhaps a little deeper than I might want it to be. So, yeah. In the past 24 hours, I've pushed code that compiles. I must admit, I was that developer today within the past 24 hours. Uh, now work, workbrew is available though. Like not, not the Linux side of it yet, but on, on Mac, if somebody really, if like, if this is the tool that meets their needs, workbrew is out there, they can get it. Today, the way to get workbrew is to come to our website, workbrew.com, uh, get on a call with me and I'll show you around. We expect very soon, um, probably in a matter of weeks to have it publicly available, uh, for folks to just get on and try. Uh, but right now it involves, um, kind of a conversation with us to see if it's a good fit for you. Um, and really the reason for that is that we're, we're looking for design partners. We're looking for companies, we're looking for, for teams that see the same set of problems that we see with using brew in a team environment and who really want to give feedback and help us build this tool together. Um, but we have it in production with a number of different companies. We use it ourselves every single day. Um, so it is there and it's up and running, but it's not entirely self-service as of this moment. Right. What's the, uh, what's the uptake look like? Have you had quite a few companies that are a good fit that have, that have come on? We had a really interesting, uh, situation maybe a couple of weeks ago. Um, Mike was interviewed on the next web and there was an article that led to quite a lot of interest. Um, over the last few weeks, I've basically been in nonstop conversations with lots and lots of name brand companies that you've probably heard of, but I can't talk about. Um, but again, many of them are in these like kind of regulated spaces where it's, we're a finance company. We're a healthcare company, we're insurance, we're government, um, you know, some kinds of, you know, different use cases for exactly the same thing. It's all different industries, but they're all saying, we'd love to use this, but our requirements are such that the open source thing just doesn't, won't fly here. Um, and really there's kind of like three stories that we see at companies. The first story is do nothing. They just let brew kind of be the wild west. Um, every developer who wants to use it just installs it on their machine. And I can't security look the other way. Um, the second kind of big category of folks is, you know, this informed trust model where you start at the company. There's a read me that says part of setting up your dev environment, installing brew, installing these 27 packages. Here's a guide, probably the guide's at a date and it doesn't work when you first start. And then if something's wrong, there's that one expert who's done a lot of stuff with brew that you go and ask for help. Um, and that's really, really common. Um, and then kind of the least common, but pretty popular case, especially among very large companies is that they have some kind of internal tooling built around this already. Um, so they'll build custom scripts to integrate with their MDM tools so they can manage a fleet wide deployment of brew. They'll build scripts to do things like inventorying what, what packages are installed on their devices, reporting version numbers and cross-referencing that with vulnerabilities databases. Um, they'll do things like add self-service scripts to their MDM tools so that end users who don't have admin privileges on their devices are able to install brew packages. But the downside to that is that for every single package in brew that your company uses, you have to have a staff member who's like maintaining that in your MDM tool, keeping it up to date, keeping it in sync. Um, it's just like unbelievable the amount of hurdles that people go through to make this work. And so, uh, yeah, the interest has been phenomenal. People are very interested. Um, and kind of those three categories of, of folks, they all hear from us and they say, why, why is this taken so long? Why hasn't this been here before? Like, it's so obvious. Um, so yeah. And as fast as I can, John. And I assume part of the, part of the cell is rather than you have to have this one guy at your business that understands brew, you've got the actual brew guys that understand brew and you pay us enough money. You can call us and we'll fix things for you. Yeah, that's definitely part of it. I mean, Mike is very generous with his time with our customers in terms of getting them up to speed on what needs to happen with brew. So, yeah, I mean, that's sort of a win-win for everybody though, right? Like I know how to do this very specific thing. You need somebody to do this very specific thing. You give me money and I do the thing like that's. Well, the, the really beautiful part of this whole thing is it's not just one company that needs this. They all, they all need the same thing and doing it once and making it, you know, reusable and, and, and package in a way that every single company that has this problem can adopt a standardized tool. We're basically saving an entire team's worth of effort at every one of these companies. Yeah. And so the individual kind of ROI calculation that each of these companies has to do is incredibly obvious that it's the right decision for them. You know, rather than paying a team, you know, I could, I could list off probably five or six of these companies that everybody knows and uses their products every single day. And they all have teams of people that are managing this problem. And in every single one of those cases, they would get a better solution from us. It'd be more purpose-built. It'd be more highly integrated with homebrew. It'd be less maintenance costs for them, less kind of distraction for their teams to have to manage it. It's just a very, very easy decision for them to make the buy versus build decision because, you know, the lack of expertise, the ongoing maintenance costs, what happens when a new version of brew is released? What happens when a new version of Mac OS is released? You have to, you know, if something doesn't work when one of those events happens, every single engineer in your company is stuck. You know, that's a high cost. So, you know, we make sure that never happens. Just make sure that you don't pull a crowd strike. Oh, absolutely. Yeah. I would be remiss if I said that that hasn't been a thing that has been talked about recently when we've been talking about certain deployment strategies and things like that of, yeah, there's ways to do this and ways not to do this. And let's not do it the way that maybe doesn't always go so well. Yes. Have you gotten to the point to where, particularly based out of these conversations with businesses, you've started adding things that you hadn't thought of to either work brew or home brew? Oh, absolutely. Yeah. That's kind of the biggest thing that we're doing right now is just listening to these customers about the problems that they face and trying to build the most general solution. I mean, Mike likes to say this thing about the baby. Do you want to give your kind of baby analogy about how this works? Well, so what it's funny, at home brew, I'm probably the closest thing home brews had to like a product manager, at least since Max left. And I guess working at GitHub for 10 years, I saw some product management done very, very well. And occasionally it's a product management done less than perfectly. And something I feel like I learned from this stuff over the years, particularly when your audience is developers, is the line I like to use is users are, or customers or developers or whatever you want to pick, are like babies in that they can cry and tell you that there is a problem. But they cannot tell you what the solution is to the problem, the tricky thing is developers compared to actual babies, even if those babies may one day grow up to be developers, developers tend to tell you go jump straight from I have problem to, and if you task me with how I would build this solution, how would I build the solution? And they come to you saying, what I need is the solution that I would have been tasked with building. And often they don't necessarily have the context that you do. They don't maybe think about like, what are the average users like? So a classic thing that this would come up in home brew quite often. And the nice thing in home brew is you can just decide to do these things because it's not as higher stakes as certainly GitHub was. And work brew is increasingly becoming is on home brew, someone might say, hey, I've added a new option that I want to opt into for this particular behavior. And then I read it and I think about it for sometimes not very long. And I'm like, why would you ever want that option turned off? It's essentially like, I've added a flag. So when you run this home brew command, if I have my face puncher plugged in my USB port, it doesn't punch me in the face. So I sat home brew underscore no punch me in the face, please, equal to one. And I'm like, well, maybe punching you in the face could be opt in, you know, like that's flip the logic round. Or maybe that's just make home brew punch free software. Like maybe we can skip this flag altogether. So to me, like that's the type of stuff that comes up. And again, I don't blame any person who makes a PR like that because they're trying to be a good dev and be like, OK, I need to. I'm not sure that anyone except me cares about this. I want to narrow the impact radius here. But I can look and be like, well, actually, everyone cares about this. Yeah, I don't want to break anybody's workflow, right? I don't want to stop overheating when you hold the space bar down for everybody. That might be important to somebody's workflow. And that I did the baby analogy. I like that. David, I'm sure you get this too. Like a customer will come to us and say, I need this. And then they'll tell you this most off-the-wall thing like, I need a new server that's got a GPU in it. You need a what now? And then, OK, what's the problem that you're having? Well, we'd like to be able to use – we'd like to be able to do this. And it's like, oh, we need to get you an account at ChatGPT. We don't need to build a server that's got a GPU in it. I'm sure you get that too, David. Reverse it. You kind of have to – you're given – instead of the baby crying, they come to you with a solution. And then you have to reverse engineer the solution to figure out what the original cry was so you can give them a better solution. To your original question, though, about what have we built that's come out of customer conversations, we've had a number of customers come to us. And our kind of very common customer profile is a head of IT, somebody who's responsible for managing their MDM at the company, like the Jam for Kanji or one of those type of tools. And they'll come to us and say, hey, one of my jobs is software patching, and I need a way to know when something has a vulnerability and how I can really quickly fix that vulnerability and know that it's been fixed across my entire fleet of thousands of devices. And so we built a vulnerabilities dashboard that effectively takes a look at every single package installed across your entire fleet, catalogs all the version numbers, knowing exactly which version is installed on each device, and cross-references that with a bunch of different data sources where you have information about all known vulnerabilities in those packages. And we present this as a nice, simple report for this IT manager to say, hey, package X has a vulnerability at this version, and it impacts 205 devices at your company. Click this button to apply a patch that fixes that on every single device. And after about 15 minutes, you can see 95% compliance, all of those have been patched, and a few of the devices that were turned off, you know which devices they were, so you can send a Slack message or give somebody a call to make sure they boot up their device and upgrade that package so that the vulnerability is addressed. And that came directly out of, you know, customer requests. Yeah, so you guys kind of provide a software bill of materials for across the whole organization. Yeah. Yeah, absolutely. Super interesting. Okay, now with Brew itself, we've talked a lot about command line applications. Do we do GUI applications? Can we install, you know, more complicated or less complicated, but GUI-based applications? Can we do real crazy things? Can we install entire, like, can we install Firefox with Brew? Is that a thing that works? Yep. And not only is it a thing that works, so this is essentially the way I interact with Homebrew primarily nowadays. So one of the things we built on top of Homebrew was this thing called Brew Bundle, which essentially the bundle part of the name relates to it. Homebrew is written in Ruby, and there's a tool called Bundle, or Bundler, I guess is the full name, that consumes gem files, which are a list of Ruby gems, essentially like third-party Ruby modules, and then builds them all together. So you kind of have all these in your app. So Homebrew, there's a part of Homebrew called Brew Bundle, which does the same thing with brew files, where you can basically have a bunch of software in there, and you can specify, okay, I want these formulas, I want these casks, I want these things from the App Store, the Mac App Store, I want these VS Code extensions, and, you know, probably more to come in future. And basically, like, the way that allows you to use Homebrew is instead of saying, okay, install this, install that, uninstall this, install that. Instead, you can have a list of essentially, here's everything I want installed on my machine, and anything that's missing, I want you to install it, anything that's out of date, I want you to upgrade it, any, you know, background services that I specify, I want you to run them. And you can also tell it to do a cleanup, which means any software that is not on that list, I want you to uninstall it from my machine, which is probably mostly useful to people like me who accumulate huge amounts of craft, testing various homebrew packages. But the nice thing with that brew file is then you can, like, my most popular not homebrew open source project is a thing called Strap I built for, primarily, originally for GitHub's internal use, but it can be used by anyone. And basically, what that lets you do is say, okay, when I first set up my machine, the first thing I want to do is pull down this list from a GitHub repo and install all the software. So, as long as you're kind of relatively diligent about, like, dumping software to that list, and then committing that to that repo, then you can get, essentially, a nice single file description of, here's everything on my machine. And if you're one of those people who likes .files, like, having all your .configuration files, like that, that's the repo that I put that in, and again, that tool pulls down your .files repo. And essentially, my goal with that repo is I should get my machine 90, 95% set up by just the contents of that repo being pulled down and all these scripts run and stuff like that. And nowadays, I even have all sorts of mad things that extract secrets from 1Password and write them to the right locations on disk and all this type of good stuff. But yeah, but as you can tell, this workflow is very heavily GitHub-centric right now. So, if you are interested in a non-GitHub-centric version, then, again, stay tuned to what Workbrew is up to in the future. Yeah, interesting. Now, does Brew help with doing, like, program installs without using Brew? So, like, on Mac, the normal way to install software is, like, you get your package, you double-click it, and it gives you this nice window with, here's the application, and here's your applications, and you just click and drag. Can we do something real fancy, like, build a package in Brew and then spit out that zip that then someone can install without using Brew? Is that in scope? This is exactly what casks are, basically. Most casks, that's what they do. So, if you, the Google Chrome cask, effectively, what that does is downloads the Google Chrome. So, in comparison to maybe a Linux package manager, a Google Chrome cask, that's not some special version of Google Chrome that's made by the homebrew team. That just downloads the installer from Apple's, sorry, Apple? Apple not making Google Chrome. Installs the installer from Google's website, and effectively, that kind of drag and drop or click through an installer, next, next, next, accept license, yada, yada, yada, yada. Like, all of those steps are essentially automated inside the cask. So, instead, I can type Brew install Google Chrome, and then, at the end, I get the exact same result as if I'd gone and walked through those steps manually of the Google Chrome installer. And the nice thing about that is it essentially provides a higher level API on how, so there's about 10,000 casks, as I mentioned before. That's essentially 10,000 pieces of software where the API for how to install it is, well, do I drag this thing? Do I click the thing? Do I download it from here? Do I, like, have to run a terminal command? No, you run the same terminal command for essentially any of those pieces of software, and they are all installed the same way. And to me, that's the most powerful thing about both casks being in Homebrew, but Homebrew itself, is essentially you have this high-level API for this stuff. And when I was talking about my brew file before, my brew file has a bunch of casks in it. So, I'm not just installing my developer command line tools that way. I'm installing Slack that way. I'm installing Zoom that way. I'm installing, like, all my, like, Safari extensions that way. So, essentially, pretty much all the software on my machine is being, in fact, probably literally all the software on my machine that is not provided by Apple is being installed through Homebrew in some way. Yeah, and on the software that's provided by Apple via the Mac App Store, Brew Bundle also has an integration with a tool called MAS, which is the Mac App Store command line. And so, you can actually add to your brew file, just like you would add brew in the name of a formula or cask in the name of the cask. You can add MAS and the identifier of an app in the Apple App Store, and it will automate the process of opening up the Apple App Store and requesting to install the program from Apple onto your device as well. So, literally everything can be put into this brew file and automated. Yeah, that's great. If there's show notes or people watching along, in some ways it's easier to kind of see rather than do it. So, if you Google for Mike McQuaid, which is my name, you may struggle with the spelling of that, but I'm sure you'll get there in the end. And then brew file, B-E-R-E-W file, then you will get the top hit to my brew file in my public .files repo, and then you can see what that looks like. And please don't critique my particular choices of software, because that's very near and dear to me. Yeah, do not me, exactly. Now, can we go the opposite direction? So, let's say, and I have this question because I've had to work through this before. It's been years ago, but for a while I was developing an application, a cross-platform GUI-based application. And one of the things that was a challenge was building that drag-and-drop installer. So, you know, if you didn't want to tell – so you can tell people, okay, go install brew and then install my application. But if you don't want to do that, you want to give people that zipped-up installer where you just drag and drop it and that's it. And it seems to me that there could be an opportunity here to have a script inside of brew where you run the build and it gives you the installer that then you can go out and give to people. And has anybody done that? Is that something that brew can do? I know that's kind of a weird – it's a weird idea, but it would have been useful to me back then. I've seen people do such things in the past. I think what makes it tricky is – well, so I guess the two sides of homebrew, right? So the casks, for example, that essentially already exists. If you have a cask for, as I mentioned, Google Chrome, that means that that's already been provided by the upstream software. But then with homebrew's formulas for, you know, say you want to install some sort of open source software that way, the tricky thing is because homebrew has its own little special snowflake ecosystem where everything works just such how it does, essentially in homebrew, everything wants to pull everything else from homebrew and be updated by homebrew and be in the location of homebrew. So that doesn't make it impossible. I mean, you know, technically it would be possible to do such things, but it makes it trickier. My best actual experience in the past, to give a shout out to another open source project, is this a cross-platform build tool called CMake you may well have heard of. What's less known is it comes with a thing called CPack, which is C-P-A-C-K. So that basically lets you do cross-platform packaging like this. At previous jobs, I've used it for essentially generating, you know, like when I used to work on Qt applications for generating a nice clicky-clicky Windows installer or a RPM or DEB for, you know, Debian or Red Hat-based distributions, or a macOS kind of drag-and-drop style or like traditional clicky-clicky installer, like you can essentially spit all of those out from the same project. And that also provides some third-party tooling, some of which I may have contributed to myself, that aids in doing things like pulling all the libraries from Homebrew and putting them in the right place and all this type of stuff. So it's kind of out of scope of the Homebrew project itself, but like you can, you know, if you look a little bit funny at the problem and take tools like CPack, then you can definitely rely on Homebrew a little bit to solve this problem a little bit easier. Yeah, sure. Okay, so is there, and it seems like there used to be, is it MacPorts is also sort of in the same space? There are some other projects that sort of solve some of these same problems, right? Yep. So MacPorts is one, Think is another. And I guess, yeah, nowadays people are using Nix in some cases as well. Is there any cross-pollination? Like some of the same, maybe same people doing the package management or? Yeah. So I wouldn't say, I mean, we definitely talk to each other. So, and sometimes not, well, I mean, when I say talk, I mean, I don't mean it in the silly way that, you know, normal humans would actually talk to each other like we're doing right now. We type things at each other on the internet and there is collaboration in some ways between the projects. Some of it is explicit, like where we might go and we have kind of shared channels with some of these folks where we might kind of figure out problems. And then some of it is the, in the nicest open source spirit of the world, us like various projects stealing patches off each other where, you know, maybe there's some new Mac OS version or compiler version or whatever it may be. And someone, one of the package managers writes a patch and the other package managers need the same patch. So then they can take it from each other. So we've all, again, there's a nice collaboration, but we've all done that from each other. And also sometimes for inspiration where if a particular package is not working on homebrew as well as it should, or we get a complaint and someone says, hey, this works fine on Mac ports or Nix or whatever. We might go and look and see how they do it. And again, I'm sure the same thing is happening in reverse. And same with the, with the, there's probably just as much, if not more actually with the Linux package managers as well. And the BSDs as well. Because the BSDs use CLang as their compiler, which is the same as what we use. So yeah. So there's basically, it's nice. It's kind of classic open source collaboration in action really in that like all these projects, because we're all open source, we can all share information and resources and help each other out with stuff. So yeah. Has anybody interested in workbrew asked about any of those other, other tools, you know, so I could, all I can imagine someone saying at workbrew sounds great, but we want to be able to use Nix as the backend. Haven't, haven't heard that one yet. But we have had some folks that are, you know, coming with like cross platform requests. So they say, for example, we want to have consistency across all three major platforms, Windows, Mac, and Linux. And it's been particularly interesting with regards to non-developers. So there are definitely companies where they have kind of a wide range of employees and some of those employees are using brew today and they understand it and they rely on it. But they also don't want to have a different system for, for example, their customer service team or for their data engineers or for data science or, you know, folks who depend on code and packages, but may not be as comfortable using the terminal and installing things. And so we've talked to them about how can we provide a single way to provide a developer environment across all three of those platforms. So that's been probably the most similar kind of questioning that we've had from people, but not directly to say, hey, I have like five different kinds of package managers. How do I use them all together? More it's like, we use this one thing. It's really cool. How can we make it work for everyone? So I assume on Windows, since brew works on Linux, you could run brew under WSL today, but it's the Windows specific stuff that probably needs some magic. Yeah, you can run brew under WSL today. That's how most of the people that I talk to who have interest in it are doing it. So I've talked to potential customers who say, you know, we have this 10, 20 people over in this department who are using WSL on Windows because X reason. Can we get those mapped into work brew as well? I haven't had the same question about, hey, can you run this natively on Windows? That almost never has come up. But there are other, rather than saying like, hey, we have this MDM tool. Because really the people that we talk to a lot are the ones who are, you know, the IT managers who are responsible for getting the fleet out into the hands of the company's employees and making sure they have the tools they need to do their job. And so what they're saying is, hey, my MDM tool, whether it's Microsoft Intune, Jamf, Kanji, whatever, has a couple dozen applications in its built-in package manager. In Kanji, they call them auto apps. In Jamf, I think they call them catalogs. But the idea is that, you know, Google Chrome, Zoom, Slack, all of those come as like default packages that the MDM provider keeps up to date. But they say, well, we have this, you know, this couple dozen packages that are not managed by them. We have to manage ourselves. But brew manages them. Can we use brew instead? And so they want to standardize on one tool for all of this. That makes a lot of sense. So another question that I had was just about the interface. So you talked to, you mentioned the cross-system management and like you talked about how you could see your systems updating with work brew and identify the ones. Is that a web portal? Is that something built into the work brew command line? Yeah, the overall architecture of what we ship is three pieces on top of brew. So it's brew, the open source project, plus we ship an installer PKG file, which is a Mac PKG, that basically enables zero-touch deployment of brew. It makes it so that if you have a brand new Mac registered Apple business manager, the first time that you turn it on, brew is installed and everything is secured. If you have existing devices with brew installed and maybe dozens or hundreds of packages installed on those devices, you can run the PKG file locally or you can run it via your MDM tool. And brew on that device will effectively be upgraded to work brew. So it will have that kind of connection back to the system. On the kind of administrative interface, there's what we call the console, which is a web portal that gives you a high-level overview of every device in your system or in your fleet. And it gives you a high-level overview of every package. So you could say, for example, which devices is OpenSSL installed on, what versions are installed, are there any known CVEs against it, and then run a patch to say upgrade it to the latest version because there was a known vulnerability we want patched. So that's kind of how the interaction works. On the device, there's one more thing that kind of goes to what I was mentioning earlier. One size does not fit all. So on the device, we give companies the opportunity to choose different permission models. We call them restricted, managed, and guided. So restricted is the most controlled. This is kind of useful for individuals who don't know what the command line is, may not have any interest in brew, may not even know what brew is. And you want to manage all their installed software in the same way as every other device. So you can install work on their device and essentially provide it in a restricted manner where the end user has no access to the brew CLI. It's only managed remotely. So, again, great for, like, a customer service team or maybe data analysts, people who might not be comfortable with the CLI. Then there's managed mode, which is kind of the big, most popular thing that we're seeing among companies with developers, where we install brew on their device for them via the PKG, via their MDM tool, and give the end user access to brew via the brew secure CLI, the wrapper that we have around brew. For the end user, it behaves just like normal brew. So you can do brew install, brew uninstall, upgrade, tap, pin, whatever they want to do, any normal command. And those commands are parsed and kind of made subject to policies or configuration options in brew so that, you know, we keep things secure and compliant. In those cases, what's really interesting is the end user on the device doesn't necessarily have to have admin privileges. So one of the big kind of points that we hear from, especially the regulated companies, is we can't let people use brew because in order to use brew successfully, they need to be admins on their devices. And for legal reasons, we're not allowed to have them have admin rights on their devices. We just cannot do it. So we basically enable them to give their users the same brew experience that they know and love without having to offer admin privileges on the device. And then the third kind of mode is more progressive companies that want to give their engineers full access. It's essentially the same kind of guardrails around policies and how you can use brew. But if they have admin privileges on the device, they're able to effectively escalate the privileges and go around these guardrails and say, even though it's out of policy, I'm going to do it anyway, so I'm not blocked. And then the kind of management or the IT and security teams will get an alert to show them that this device is out of policy or this package is installed in my fleet out of policy and then get up to date that way. Yeah. So it sounds like you're not planning to bring brew itself to Windows PowerShell. I was going to ask about that. I think Mike is best suited to answer that. Never say never. It just sounds like pain and suffering, though. A follow-up question on the whole dependency management. So I have DevOps experience where you're developing web pages or web applications. And so you need to keep your dev system in sync with the same versions that you're running on your production systems. Do you have anybody using brew to manage the software stack on production systems? Right now, not really. Essentially, homebrew, as you mentioned there, the limitation you generally have in production is you want to have everything locked down to very, very specific versions that are consistent across your entire fleet. That's not the model in which homebrew operates by default. That is increasingly the model we're seeing people wanting workbrew to operate in default. So we are building stuff in that direction. Again, sorry, I can't say too much there. But essentially, like that, well, I guess it goes back to the babies we were talking about earlier, right? Like, essentially, this is a crying baby problem that we are aware exists, even in development mode. But certainly, the desire to have everything consistent between CI, dev, production, that is a problem that exists today. There is not a great solution to, and there is a problem that we are working on right now. I guess the homebrew middle ground there is, because homebrew is a rolling release package manager, it used to be homebrew was just you get the latest version or you don't get a version, right? Like, you have to just pick between. Now, more popular packages with kind of better support for kind of running older versions, say something like MySQL or Postgres or Node.js, Ruby, whatever it may be, that still provide bug fixes, security releases, etc. For versions beyond the most recent one, you can install a package and you might say, you know, brew install Node.js at 18 or whatever, right? Which gets you a, like, less than the current newest version, but will continue to get you patch releases and security updates and stuff like that. I guess a sort of balance I've seen with this stuff as well is that historically, the maybe individual developer model is let's just have the newest version of everything all the time. And the enterprise model has been, let's pick a set of versions that work and then essentially only ever upgrade them if we absolutely have to. But the problem with that flow is you often end up in a situation where, whoops, we probably should have upgraded this version a while ago. And now a bunch of bad actors have got access to our either development machines or servers or whatever it may be because we decided to sit on this version indefinitely, even where there were security updates that we were too scared to install. So to me, there's a, there's a happy middle ground to be found homebrew leans slightly more towards the like, you know, let's have the newest thing of everything all the time. But as I say, in work brew land, we're building, essentially, we already have some tooling there to essentially get that middle ground of like, okay, well, this package is actually vulnerable right now. So I don't care if you're trying to sit on an older version because some perceived view of stability, like let's upgrade everyone. So at least they're not on a vulnerable version anymore. Excellent. All right, well, we, we have hit the, the top of the hour. So I want to get into rap. And one of the, one of the things I want to ask you guys is, is there anything we missed? Is there anything we should have asked you about? You wanted to let folks know about that we didn't cover? It's kind of a challenging question, because you've got to do some set math and think about all the things that we talked about. But if there's anything that comes to mind. I mean, I guess there's one, one thing that I might mention, which is, yeah, I think I mentioned like Linux before and development environments and stuff like that. And something where we've actually seen quite a lot of use of Homebrew that might be worth playing around for folks who are listening here is Homebrew runs pretty well in, if you're using GitHub Actions or, you know, GitLab Runners or whatever it may be. And that's, that's a nice way, because the packages are the same on Linux and Mac, and because the versions are in sync, that can sometimes be a nice way to have your development environment and your CI environment in sync, where you might have your developers using Macs locally, say, but then they might have a bunch of tests running on CI boxes, which are most of the time for cheapness reasons, going to be running on Linux. So if you do, you know, use a brew file, like I mentioned before, or even just run brew install, go or whatever it might be, then that means you can have that consistency between what you're doing locally on your Mac and what you're running in your CI environment. And that can be kind of quite nice. Yeah, absolutely. I was just going to say that, you know, if this, any of this sounds interesting to you, Mike and I are both available, you know, to talk to people, you can find us on our website, workbrew.com, there's a contact form that goes directly to my inbox, I'd be happy to chat with anybody there. We're also active on, you know, GitHub and Twitter and things like that, we'll give our contact information for that as well. Yeah, and we'll make sure and get that in the show notes for folks if they want to reach out. Probably a question mostly for Mike, although, John, if you have any stories, you certainly can tell us. What's the most surprising thing somebody's done with brew? What has somebody messaged you or written about and go, I didn't know you could do that with brew? Or why would somebody want to do that with brew? Well, I'm actually going to choose to misinterpret your question because I think you'll find it slightly more funny. So the thing that jumped into my head was almost like, what's the stupidest thing you've seen happen with homebrew? Stupid can be surprising. Yeah, so my favorite bug of all time, actually, is we might be able to, if you've got show notes or whatever, like, fire me an email or something and I can send you the link. Because this is open source, you know, you can actually read. So there's a bit of debugging that went on. Someone was getting some very strange messages when they were running homebrew. And this is in the earlier days of macOS. So nowadays, mac ships with a thing called system integrity protection, which essentially means, like, look, I don't care if you run sudo. There's certain stuff on your disk that's more important and we're not going to let you just, like, screw around with it. So stay away. But before they had that, someone was running around homebrew, getting very strange error messages. And what was figured out was that they had managed to replace bin bash, which is, you know, on a Unix system, a relatively important thing for you to have, somehow with Node.js. So every time they were attempting to run a bash script, they were getting JavaScript errors in their shell. So that, to this day, is my favorite issue I've ever seen on homebrew. Oh, that's beautiful. That is beautiful chaos. I love it. All right. I was just going to say, just one of the things that I was, like, surprised about is, I can't mention names, but several very large enterprises that make a lot of the core technology that we depend on have their own internal forks of brew. And so, you know, they're basically maintaining an entire parallel infrastructure where they're, like, reviewing everything themselves, you know, to get at these, like, kind of supply chain story, like, keeping things up to date, vulnerabilities. It's just, like, unbelievable that it's, you know, brew is that important to them that they can't decide, oh, no, we just won't use this. No, we actually, the only option we have is to maintain this ourselves internally as a totally separate fork. So that just kind of goes to the, you know, the idea that it's a very essential tool for a lot of developers. Yeah. Yeah, that's great. All right. So I'm going to ask each of you a final two questions, and that is your favorite text editor and scripting language. And we'll start with John. I mean, this is pretty easy for me. So Ruby is my favorite scripting language. I, you know, I used to work at GitHub for close to seven years with Mike, and I was so happy when I joined GitHub because it was finally a company that used Ruby as, like, their main language. I had always been, like, a web dev. You know, in my early days, I was doing, like, PHP and, like, Java and stuff like that. Yeah. And when I moved into writing Ruby, you know, at work, it was, like, the best thing ever. And then I kind of have a soft spot for Pico. Okay. As my editor, I first, when I started writing code, that was the first editor that I learned how to use on a Unix machine. I was running, like, a Gen 2 box. And old habits die hard. It's, like, still the thing that I just opened by default in my terminal. Pico and not nano? Yeah. Pico, not nano. That's great. I have an alias, usually. Makes sense. And Mike? Yeah. So scripting language, I'm actually going to disagree with, John. And so I use Ruby for, like, proper programming nowadays. But if I just need to quickly solve a problem, I always go to Bash. Like, me and Bash, Bash has treated me so badly so many times. But, yeah, I keep coming back. Like, I don't know what it is. And, yeah, as for text editor, like, nowadays, I feel like I'm, I wouldn't say begrudgingly, but, you know, it feels like a lot of developers are in VS Code now. And it makes just life easier for me to just follow the flow and go there. But, yeah, I'm still, I'm still keeping my eye on other things. Like, the extension ecosystem in VS Code is great, but, like, you know, it's not the fastest thing in the world. And there's a text editor by an ex-GitHubber called Zed that is kind of up and coming, written in Rust. It's super-duper-duper fast. And I've been playing around with that every so often. And it doesn't have quite all the features I feel like I need. But, like, yeah, I have my hope for that as a potential feature option. Yeah, absolutely. We interviewed a young man back a few weeks ago building the Amber language that is intended to be Bash Code with some of those Bash pain points removed. That one might be interesting to look at. We had a lot of fun talking about it. I kind of like the pain points at this point. Everything Bash does wrong is just, you know, it's almost like scar tissue that feels like it's part of me, you know. Yeah. I'm trying to figure out. It seems like we either interviewed or we're going to. Ah, I'm in contact with the guys from Zed about hopefully getting them on the show. So watch for that, too. Guys, thank you so much for being here. I appreciate it very much. And it was really fun to get to learn about Homebrew, which, you know, has been around for forever. And then Workbrew, which is a really, really fascinating project, a business that's been built. And, boy, hopefully it'll continue to go well. And maybe here in about a year we can have you guys back on and talk about what's happened since. Oh, we love it. Thank you so much for inviting us. Good to you. All right. Ah, I love it. I, of course, as we started at the beginning, I'm not a big Mac guy, but I'm interested in playing Routebrew on Linux. Yeah. I tell you what really fascinates me the most is, for my use, is brew in GitHub Actions. Like, I never had that thought. That is very surprising to me. But, you know, as they describe what you can do with it, it makes sense that, you know, your GitHub runner may be running something very different than what your develop machine is. And having this external package manager that can put the exact same packages on all of them, like, that's kind of compelling. So that's definitely something that I will have to keep in mind for the future that could be interesting to do. I like that. I'm also just thinking about the conversation we had. I am impressed with the way that they are building Workbrew on top of Homebrew. And I don't know if you would call that – I don't think you would call that an open core project. I don't think that's fair to call it that. But just that they have this very clear line of demarcation between the two. And they're pushing features into Homebrew as needed to make Workbrew work. I think it's a good model. And I think it will serve them well. So, you know, looking forward to hearing about their success as time goes by. Absolutely. Yeah. All right. David, is there anything that you want to plug before we let folks go? Not specifically. But I always like to take the opportunity to plug Club Twit and the Twit Network. They're going through changes that I think are positive in the long run. And we have fun over there. So, come on over. Yes. We've got our show that David is, from time to time, a co-host on. And that's the Untitled Linux show where we talk about all kinds of fun Linux news and open source news. And there's some – as we say, there's some cross-pollination between Floss and ULS. Coming up on Floss Weekly next week, we actually have Pedrag Brady from Core Utils. And we talked about the Rust Core Utils a few weeks back. And I got an email that said, hey, you know, we're the OG Core Utils. We'd love to talk to you, too. So, we've got them coming on. And looking forward to that next week. We'll be back at our regular time next week on Tuesday as we recorded a little early today. And then, yeah, we appreciate Hackaday being the sponsor of the show, giving us a place to land. And you can follow my work there. The security column goes live every Friday morning. And that's always a lot of fun, too, to keep up with what's going on in the world of security. But other than that, I just want to say thanks. We appreciate everybody being here, catching us live and on the download. And we will see you next week on Floss Weekly.

Welcome back to the Open Source Startup Podcast. I'm Robbie, one of your co-hosts and joined as always by Tim Chen, my awesome co-host from Essence VC. And today we are super excited to not have one but two guests with us. We have John and Mike here who are the co-founders of Workbrew, which is a company that provides missing features and support for companies using Homebrew. And I'm sure many folks in our audience are going to know what Homebrew is. It's a very, very widely adopted package manager, but we're thrilled to have them on and hear about the Homebrew and Workbrew story. So welcome, Mike. Welcome, John. Thanks for having us. Awesome. So Mike, we're going to start with you and go all the way back to the founding and creation of Homebrew. So why don't you talk to us a bit about where that idea for a project Yeah. So I think Homebrew started kind of early-ish 2009. There was a guy called Max Howell working for Last.fm. It's a nice blast from the past reference. I don't know how many Last.fm users there are out there anymore. So he was working Last.fm doing kind of package management stuff on Mac, played around with various tools, wasn't really happy with any of them. And yeah, he decided one night to kind of just try and build his own thing. So he kind of wrote a sort of manifesto. I think the first commit to the repo was like the readme about like what he was making and why he was making it and what the idea was behind it. And then he just started kind of building away by himself on GitHub. One of the, I guess, the interesting early approaches that Homebrew did that was a little bit different was most package managers were like, you know, get a bunch of people together and we'll kind of split up and divide the responsibility. Cause you know, this is like maybe two years after GitHub was founded and Max was a GitHub user. So he was like, okay, well let's get the community to get involved from day one. Right. So I can be a bit more his words, but we don't mind lazy about having to do everything himself. So maybe like six months later, I I'd been kind of dabbling around with my own package management problems and kind of hacked some stuff around with existing stuff. And I couldn't really equally find anything that worked the way I wanted it to. And I heard about this Homebrew thing, like Max was a friend of friends in London where I was working at the time as well for another startup over there. And yeah, I basically just started kind of adding some stuff to Homebrew and just never really stopped. And yeah, the project's kind of grown over that time. I guess I was the third person to kind of get involved as a maintainer. I'm the only one left of that kind of early crew. And yeah, we've now got like 30 maintainers and many thousands of packages and thousands of contributors and all that good stuff. Yeah. That's amazing. I think Max was actually on our podcast before talking about tea. So we definitely had our own fun talking about Homebrew. So you joined a little later as contributor and now become a maintainer, right? I don't think people understand what is maintaining a package manager really feels like. What do you do? Because I'm actually, I'm personally curious, like, what do you do that much these days? Because there's going to be the packages and a bunch of vendors or users contributing side. And there's also the core system side, right? Like, what do you spend most of your time on these days to maintain Homebrew? Yeah. I mean, me personally, nowadays, I mainly spend my time on the code side, I guess, on everything except the packages themselves. Like I get pulled in sometimes when there's some something contentious or whatever. But day to day, like most of the packaging stuff gets handled by other people. In my earlier days, I did a bit of everything. And it's kind of, if anyone's interested in getting involved with a package manager, the fun thing about it is you can go from writing like a couple of lines of C++ to a couple lines of Haskell to a couple lines of Go, like all within a few hours of each other, because you're just having to kind of dip your toe into many different pools. But yeah, but for me, like nowadays, a lot of it is just code review and investigating kind of what the other maintainers, what some kind of new contributors or whoever are wanting to do in Homebrew, any new bugs in Homebrew, like triaging those, like trying to figure out what do we want to be building in the next one, six, 12 months, and then like talking with a bunch of the maintainers in Slack. I guess I feel like I sort of wear that out of, if Homebrew was a company, which is not of like sort of a combo between CEO, CTO, head of product, and security guards. And so, you know, whenever we're looking at a very widely adopted popular open source projects, I'm always curious, like now we can look back why Homebrew is actually that popular, right? You know, back in the day, I probably have no clue. But in your opinion, what made Homebrew the default thing? Because there's a Mac force before, there are some other things happen, come here and goes, but Homebrew definitely is the one that stays. And everybody has no mistake now, brew install is by default there, which is truly amazing. It's not an Apple thing at all, right? This is pretty much a community contributed project that made it become like the standard. What do you think is like the secret of Homebrew or things that got right that made it become the default thing? Yeah, I mean, that's a great question. I think, as you say, like this stuff is often more obvious in hindsight, I think, than it was at the time. So one big thing, I think I sort of alluded to a little bit before, which was like going all in on GitHub. And we've still continued to do that to this day. We use a lot of GitHub infrastructure. You know, John and I used to work there. Like it's definitely something where even if I didn't work there and before I worked there, I was still very much like, okay, like it makes sense to kind of do this. And I guess really leading into the idea of, which was very innovative in 2009, seems less so now, but the idea that the best way of maintaining something at really high scale is not to have a small number of people doing a lot of work, but an awful lot of people doing small amounts of work and that things work well. That way you can kind of fan things out and have a contribution model. And the maintainers are operating more like kind of shepherds than the people who are expected to do the bulk of work by themselves. And I think the other thing is just like usability. I think there's, you know, Mac ports, and I don't want to talk ill of the other projects, but I think I definitely feel like with Homebrew, it has always tried to embody that Apple ethos of trying to be really, really usable and try to really care about what the interface looks like. Don't support things if you can't support them well, make error messages really clear for people, make it really clear what needs to be done if rather than telling a user to do something, if you can just do it for them automatically, sensible defaults, like all this type of stuff. I think like that's what has contributed most to Homebrew success. And in many of those cases, those changes to get things more usable or a little bit nicer or trimming down options have been, there's been a vocal minority who've been very unhappy about them along the way. But I actually think like, that's partly why it's been successful is being willing to embrace usability over necessarily making the maybe very loud power users sometimes the happiest. Yeah, I think adding on to the like choosing to do a lot of things, you know, fully embrace GitHub. Also, Homebrew is a project, I'm a contributor, you know, I've been using Homebrew since the very early days. And whenever something I don't like doesn't work correctly, or there's not a package that I need, the ease of contributing is just like, so, so easy. And the way that the project is managed, as a newcomer to the project, getting up to speed, everything is super well documented, there's kind of guardrails in place that are automated, things like telling you that you're doing something wrong, and enforcing a rule is done by a bot rather than by a human, right? So the human comes along and tells you, hey, let me help you out. But the bot saying, sorry, you can't do it that way, figure out a new way. And I just think from a contribution perspective, the project, the fact that it's like formula are written, you know, the packages are written in like a DSL, it's really easy to understand, it just makes it way more approachable than, you know, other really complicated projects. And it's amazing that the project's been around for so long, and still has that usability, because usually over time, things complicate themselves. And it's hard to remain, you know, simple and very user friendly. I'm curious, so this is a question for either or both of you, the project's been around for so long. Company is quite new. Why start Workbrew when you did? Like, what were kind of the signals that said, okay, like now is when we should start this company? So I think that the first time we had an idea for doing something like this was back in like 2012. So Mike and I worked together at GitHub for a number of years. And I always said, like, you know, Homebrew is a great project. I think there's a really big opportunity here. But just the timing wasn't right among the people who were involved. You know, we were working at GitHub during a really high growth phase, doing a lot of really interesting stuff. And in 2019, after I left the company, I knew I wanted to be an entrepreneur and start a new company and had been working. And as soon as I left, I kind of reached out to Mike and was like, hey, Mike, you should come join me and we should start a company together. And that took a few years, but eventually it came through to him. He decided, you know, to leave GitHub. And when we started working together, we weren't actually working on Workbrew. And we had this really, like, very pivotal conversation where Mike said to me, he's like, you know, we should really be focused on things that we're good at and play to our strengths. And I just reminded him, I said, you know, we could always do, you know, features for Homebrew for this open source project for the enterprise, like we should work on that. And that's when we decided to start. So that wasn't all that long ago, but it's been an idea kind of in the back of our minds for a very long time. And I think that the other story that relates to our experience, both having worked at GitHub in the past and kind of what we're doing with Workbrew is there was an internal kind of meme at GitHub called Remember Chatboxes. And it's basically this idea that over time, software gets more complicated. People ask for more features. And you kind of alluded to this with Homebrew being really simple and easy to use. And that's because in Homebrew world, they're really, really focused on the most common standard experience, making sure that people have a really good out-of-the-box experience. But when it comes to enterprise software, it's not our job to tell a big company with 20,000, 100,000 employees how they should run their development and run their stuff. And they need checkboxes. They need customization. They need different kinds of compliance, all kinds of features like that. And so it kind of like fits really well in saying like, yeah, there's this thing out there. Everybody loves it. But there are some situations where big companies need something a little more customized, a little more flexible for them. And that's where we come in with the business. You know, that's the fun thing about starting a company is that I think John was convinced this was a good idea, as he said, back from 2012. Like, whereas I wasn't convinced this was a good idea, even when he eventually said that. And then I went and had dinner with my kids. And I was like, the only reason that convinced me it was a good idea is I was like, yeah, we should be playing to our strengths. And I was like, yeah. I mean, based on what I said to John, if I actually believe what I said, he's completely right. Right. But even if, you know, before I came and joined him, he was like, hey, Mike, let's go and do the homebrew. It's almost, it's the funny thing that like, sometimes you have to be like in the right place to like hear that stuff. And I think also for me, it was the, I guess I always wanted homebrew to be in the right place as well. Like there was some kind of minor controversy a few years ago about people feeling like I had too much power in the project. And I was maybe approaching sort of BFDL sort of status and that. And then now we have like a kind of governance model and leadership committee and elections and all this type of stuff. And I feel much more comfortable kind of starting a company around homebrew now than I did before, because, you know, even if I decided tomorrow, like my evil master plan is to somehow try and take homebrew away and make everyone pay for homebrew. I don't have the power to do that, you know? And there was a point where I maybe did. And in some ways like that kind of scared me a bit because like I, it would make some things easier, but it would make the homebrew project much more at risk. And I guess we've seen a lot of stuff with open source recently where you have had that more, I guess, blurred line between the commercial organization and the open source project. And there's been a few stories in the news recently about maybe the community, not always being terribly happy about how that ends up. Yeah. Just given the nature of the project, you are very, I guess, dependent and also you want to almost mass contribution to your project. So I think there's definitely sensitivity when it comes to like, hey, here's a company behind it, right? But I guess you're not even saying this is behind it. This is almost like a company that's working primarily with it, right? That's probably almost like one way to kind of key it. I think that's really an interesting perspective to take is it's not that we're behind it. I mean, we fully support homebrew and want to do everything we can to make the project better for everybody that uses it. But I like to think of it as we're complimentary to the project. All of these situations with like other companies doing open source and then you see like maybe they change their open source licensing or they like none of that stuff is possible in our situation. And we have no interest in that, but we sell a product. You know, we make enterprise software and we sell it for money and it's complimentary to homebrew. It's not part of homebrew. It's not a fork of homebrew. All of our customers use the exact same open source homebrew that everybody else does. And if we have something that needs to get support in homebrew, you know, we make an open source contribution to homebrew and it will get accepted if it's something that's beneficial to the entire community. Right. And so that's, it's really like a complimentary situation rather than a fork or any, any other kind of model. Yeah. So there was a nice example in the last week, in fact, where there was some stuff where like some parts of homebrew that workbrew relies on more heavily than your typical user might. And some stuff was really slow and that was really annoying me. So I made it like, you know, like 50 times faster because it was annoying me how slow it was. But the thing is, is that's something where everyone who uses homebrew now, who uses that command and that flow can benefit from that thing being 50 times faster. And so I think there's this nice kind of symbiotic relationship where as workbrew gets better and as workbrew has to make homebrew better for our own benefit, then it also makes homebrew better for everyone. And in some ways, again, I feel like I kind of got good practice at this at GitHub, where there was times where, you know, homebrew was very widely used inside of GitHub right from the very early days and homebrew relied very heavily on GitHub itself. So there was this nice kind of balance where there's a few API calls in the GitHub API and features on GitHub that were added primarily for homebrew and are now used by many other places. But then also vice versa, there's various times where like GitHub was migrating to rely on homebrew more heavily. And I would spend a bit of my time at work kind of making homebrew kind of work better in a way that worked for GitHub, but then worked for other places. So I don't know. I feel like there's always a little bit of this kind of balancing act that you have to be kind of careful, but I feel like I'm used to that by now from kind of having that had this split for a fairly while. So I want to talk a bit about who workbrew is built for and how you made that decision, because I imagine just with the number of homebrew users, there are different product directions you could go into. And it sounds like you landed on enterprise, but even the definition of enterprise is kind of all over the place these days. So how did you determine who the user was going to be for workbrew? And like, what was kind of the iteration process? Like, was it always kind of the direction you're on now? Or did you try a few different things? We did a lot of research. We looked at all kinds of issues in the homebrew issue tracker. We talked to people, we looked for problems. And one of the problems that came up over and over again was homebrew is widely used. And it's often used in companies where they're engineers on Macs, and they use it for their developer environments. They use it for consistent setup process, getting people onboarded more quickly. There's a lot of different use cases why companies are using homebrew. But as you add more endpoints, more end user devices into the system, the problem becomes more multifaceted and there are more considerations. And so what we found was that in environments where there's maybe a dozen or so Macs with homebrew, it's pretty easy to just manage that individually. But in environments where you have hundreds to thousands or tens of thousands of devices, sure, each end user can manage those things. But those types of organizations are often regulated. They might have security requirements, you know, have to be compliant with like SOC 2 or ISO. They might have additional kind of regulation around the type of industry they're in, whether it's healthcare or financial. And they might have some kind of restrictions on the way that end users can use their devices. And so we found that the people who are responsible for solving those problems tend to be IT managers. You know, people who are in the IT department who often will be dealing with things like MDM tooling or other kind of on-device security detection, things like that. And so when we set out to build Workbrew, we really set out to try to solve some of their problems. And we talked about this a little bit before the recording, but the idea of there's kind of like deployment, getting Homebrew onto the devices. There's like analytics and management, and then there's also like a security component to this. And so the main kind of key person in that whole situation is the IT manager. They're the ones who kind of like choose the tool, deploy the tool into production, are responsible for running it. And they have stakeholders in both engineering and the security departments. So that's how we kind of got to this customer profile. But I think that over time, like you were saying, there are a lot of different paths we could go with a lot of, you know, different values we can add for the different kind of personas. It's just that this IT management situation is very, very urgent for people. It's something we hear over and over again. There's no solution on the market for them right now. And what it means is that big companies, you know, like Fortune 500 companies are out there building their own tooling that's in the direction of what we're building at Workbrew, but it's far inferior. They don't have the staff to maintain it. And it doesn't have the same kind of synergy with the Homebrew open source project where we can lean on all the experience that Mike has from being a maintainer and a contributor for such a long time. So that's how we ended up where we are now. So I'm curious because Homebrew, given it's like a 2009 project, I know it's been maintained over time, but definitely has like a long history at this point. Now you're trying to build a product around it. I would imagine it may not be the easiest thing on earth. You can just stick one project, you know, controls our Homebrew. So let me talk about what does the product do today? And then very curious about what kind of things you have to do to make sure a product can work on top of Homebrew. Because that doesn't seem like the most obvious thing right now. Did you have to fork Homebrew, for example? Or did you have to do some kind of crazy modifications to it to be able to support anything? Like, maybe talk about some of that. Yeah. I think that like a good way to answer this is just to kind of talk about the architecture of Workbrew and like how it actually works. We talked a little bit before about the idea of it being complimentary to Homebrew. So what we've built is essentially a control center. You know, I hear this phrasing all the time from people when I'm talking to them about, you know, the problems they're facing with Homebrew. And they say they're trying to get their hands around Homebrew at their organization. What does that mean? That means they have no idea who has it installed. They have no idea what packages are installed on their machines. They have no idea what's out of date. What might be a security vulnerability? Are they compliant with the certifications that they need? That's kind of the idea of like, I need to get my hands around this. And so what we've built is effectively an installer, a way to deploy Homebrew at scale zero touch. So if you're in an organization where you use something like Apple Business Manager and an MDM tool, you can now take a brand new Mac out of the box, turn it on for the first time. When it connects to the network, it will have Workbrew installed, right? Then kind of the next thing is analytics and, you know, observability, knowing what's installed across your fleet, having some kind of way to make sure that that's within, you know, whatever your operating guidelines are. And then getting alerts around security vulnerabilities. We had just a couple of weeks ago, a month ago, the XZ vulnerability. We had tons of people reach out to us and say, we've got 10,000 Macs with Homebrew installed. How do I make sure that XZ is up to date on all of those machines? So this is definitely a problem that's related to a wide scale issue. So anyways, we have this kind of installer that makes the deployment much easier. The next thing is kind of an agent. The installer puts this on the machine, lets your machine kind of check in with Workbrew and provide, you know, diagnostics, analytics, but it also provides for the IT manager to help keep your machine up to date. Install packages that might be important for a team so they have an environment ready to go on day one. And then lastly, there's the console, which is kind of a dashboard where you can log in, view your entire fleet, manage it in groups and things like that. But what's interesting, you asked, is this a fork of Homebrew? And like, that's decidedly no, right? We are not a fork of Homebrew. You're using exactly the same open source project as everyone else. And another question I get a lot is, what if we have a fleet, you know, we have 10,000 devices with Homebrew already installed and each of those people has a bunch of packages installed and we want to get Workbrew, what happens to those existing Homebrew installations? Well, because they're literally the exact same Homebrew that we use, upgrading is effectively installing Workbrew, flipping a couple of bits here and there, and then you're able to keep all the packages you have on your machine installed, use the existing Homebrew installation, but get all of the kind of enterprise like fleet level features right away. When you talk about the product value for Workbrew really being around scale and around enterprise use cases, so that's going to be applicable to some parts of the Homebrew community, not all. How do you think about or how have you gone to market alongside Homebrew? Like, do you leverage the community or like message to the community? Do you do independent product marketing? Like, how do you kind of grow with the community and let folks know that there's kind of another option here if they want to manage at scale? Like, how does that go to market work? I mean, John talked earlier about the, I guess our initial persona we're going off to as the kind of Mac admin, but definitely in the longer term, we're also looking at engineers and security teams and stuff like that as well. And we've kind of had the principle for this stuff that any feature or functionality we add in Workbrew makes life better for at least one of those three demographics, and does not make life worse for any of the demographics. So I love the questions you had, Tim, about, you know, are you running a forked version of Homebrew or do we need some crazy modifications or whatever? And the nice thing about that is that using Workbrew feels exactly the same as using Homebrew, essentially. There is some stuff going on under the hood that means it's actually, even if you're just using it on your machine, it's a lot more secure than Homebrew. There's a much smaller attack surface and much kind of better separation and stuff like that. And the performance basically feels exactly the same. But yeah, we have ideas in the future, I guess, partly based on my experiences of maintaining Homebrew, but also kind of working in many teams across places like GitHub of Homebrew works really well as John used to talk about, like single player and multiplayer. So Homebrew works really well as a single player tool. If you're just installing stuff in your machine and you pull down a version of a package and you want to upgrade it or whatever, then that works fine. But as soon as you start to work on developer teams of, you know, maybe even five to ten people, let alone a kind of developer orgs of 100, 1000, 10,000 people, you know, you get everyone to install something using Homebrew and run a command. And it turns out those people now have, because they installed at different times, five different versions of the thing installed. And when they run the command, they will get five different behaviors. So like, this is the type of thing that for your average Homebrew user, if you're just like a hobbyist and you're playing around in your evening and you don't really care what versions things are, that doesn't matter. But if you're doing like serious professional software development, like that really matters. Like it matters if your team cannot get mapped on a single kind of locked in version of the software they're using. And even just, I have to hat tip to John, like the name, the conversation we had where John pitched the idea, he pitched the name Workbrew at almost exactly the same time. And I think for me, I like the kind of differentiation where this, we don't see Workbrew as almost like a competitor to Homebrew, but it's more like one is single player, the other is multiplayer. One is free software, the other is paid software. One is for use at home, the other is for use at work. Right. And over time, I think as we keep adding offerings for IT people, for engineers, for security people, like I think Workbrew is going to become the dominant way of using Homebrew at work, because our offering is just going to be so much more, I guess, easy for teams to use in a more consistent way than Homebrew is today. Yeah. And on the second part, regarding like go to market and what we've done so far, part of it has been just engaging with community about the problems that they face. We could come up with a list of, you know, 15 or 20 different problems that these type of IT admins are trying to solve with Homebrew. Things like, you know, I have a fleet of a thousand machines, how do I make sure all the right packages are installed on day one? In order to do that, they have to write a bunch of custom scripts, deploy them through the MDM tool, or use another open source project like one of Mike's projects called Strap to set the machine up on the first run. But doing that is labor intensive. They have a lot of custom code and there's no kind of standardized way to do it. And what we've done is just kind of talk to people about these various problems and, you know, give them solutions. We had a kind of a online like webinar conversation with a handful of potential customers. And we went through all these different problems and just gave them the solution. You know, here's, here's a way to solve the problem. Like we had one problem that comes up a lot, which is we work in a regulated industry, let's say a bank, and our end users are not allowed to have admin privileges on their device. As a developer, that sounds terrible to me. I want admin privileges on my device, but like when you work at a bank, you're not allowed, right? And so the way to solve that problem, when it comes to using Homebrew, it's like, you need to have admin privileges to run Homebrew. When it comes to solving that problem, there is a way to do it. And there are a bunch of different privilege escalation tools. So what you can do is have Homebrew installed, your end user doesn't have admin privileges, they click a button in this privilege escalation tool, and they ask for admin privileges, it gets approved. And for a temporary period, they can install stuff with Homebrew, and then they get removed from the admin group, like after the time limits up, and they have to have an audit log for each one of these things. And that's kind of a painful experience, but it's a workaround and you can do it. And so what we've been doing in terms of like go to market is just showing people what the solutions out there are for those things, but then also giving them a much better alternative, which is to use Workbrew, which out of the box works in that situation. You know, you can have end users installing packages on their machines without having admin privileges on the device. You know, you can have zero touch deployment without having to write any custom code. And so that's really been the main activity we've been doing. And then there's also a relatively established community of people that self identify as they're called themselves Mac admins. So IT administrators who work on predominantly Mac fleets. And, you know, there's like a conference, there's a podcast, there's, you know, an open source foundation, there's a Slack channel. And we just try to, you know, participate in those kinds of events and those kinds of communities in a really genuine way and answer questions about Homebrew. When they ask about how to solve something that's not in scope for Homebrew, we give them alternatives and then, you know, show them the way with Workbrew. Maybe going back a little bit. I'm very curious how you landed to this product because Homebrew has such a massive user base. You can spend your whole lifetime talking to everybody and figure out what they need. And I'm sure it's not going to be easy. There's too many signals, potentially. What are the kind of the areas you was contemplating about what to start with? And what was the process for you to even talk to? Like, did you have to segment into like small, large companies and Mac admins, non-Mac admins? Like, what are the possibilities here? And then say, okay, this might be a better route to take. I'm just curious how that process went for you guys. Well, so the nice thing with Homebrew is because it's a still essentially entirely volunteer run project. You know, there's like a small stipend, but like that doesn't go about covering anyone anywhere approaching like market level wages. I mean, probably not even market level wages to, you know, work in a grocery store, to be honest, but you know, it gives people some compensation, but as a result, things only get done if a maintainer or contributor want them to get done. So we've had a long tail of, I guess, particularly maybe over the last, maybe more of the last five or 10 years than the whole 15 years of the project where Homebrew is being used super widely in a lot of big companies. And, you know, every so often you get someone in one of those big companies who Homebrew doesn't play nicely with the way they do things. I guess John sort of alluded to that earlier. And they come to Homebrew and they say, "Hey, Homebrew, like we're a big, serious, important company, right? So you have to change the way you're doing things because, you know, we're doing it the right way and you're doing the wrong way and go about that." And previously, people would, you know, there was one particularly grumpy Homebrew retainer, I think he was called Mike McQuaid or something, who would regularly tell people like, "No, you can't have this and you can't tell us what to do. We're all volunteers. Nah, nah, nah, nah." So the nice thing is when we kind of went to looking at this stuff, we had a very long tail of lots of almost entirely public conversations where often myself or other Homebrew maintainers had said, "Hey, like we don't have the time or energy or inclination or whatever to build this stuff." And we had people in big companies often citing the names of their companies to try and get these features developed saying like, "Hey, we need this thing. Like, why wouldn't you do this thing?" So that kind of gave us a really nice opportunity to begin with for painstorming. And I remember the first few weeks after us having this idea, me just like trolling through the Homebrew issue tracker and discussion boards and stuff like that, and just generating lists upon lists of like, here's people asking for stuff, right? And what are the themes that are coming out of this? And what seems like the sort of lowest hanging fruit that could be like a viable MVP that solves an actual real problem for real people today, that there's no real good solution out there, right? And in some cases as well, like there's some parts of what we built with Workbrew where if you go searching around GitHub, like there's abandoned projects that haven't been touched in eight years that tried to solve some of these problems. But the problem is partly in the macOS ecosystem as well, that things are forever changing. So if you sign up to do one of these things, you're sort of signing up to do it forever. So it's very hard to keep something that works well on Macs, works well with Homebrew, and keep that going indefinitely without being sufficiently plugged into either Apple or Homebrew itself. And we are lucky enough to be plugged into Homebrew itself. Yeah. So I think that's what helped from the beginning with us not having to just guess or interview thousands of Homebrew users on what they need because we could see this stuff. And again, even with that, like the kind of interview process, I think the thing that I've learned through, I guess, doing essentially product management on Homebrew for an awfully long time is I have, I guess, a line on product management in the, it doesn't sound very nice, but humor me, users are like babies and they can tell you that there's something wrong, but they can't tell you what they need. And I find that's often the case, again, with these problems where you go and read what people ask for, that we're not building exactly what they said they wanted implemented. Because often if you ask engineering centric people, they jump straight to a solution, but we're being like, okay, what is the shared problem all of these people have? And what's the best solution to their problem? Even if they don't know about it yet. So yeah, I feel like that's how we've got to where we are with what we built. Yeah. Another like kind of component of that, Mike said the low-hanging fruit, you know, when we look at those lists of possible things we could build, everything we've built so far as a prerequisite, you know, no matter which direction we go on any of those, you know, many, many opportunities of features or potential products we could build fundamentally having a fleet management idea of all of the devices within your organization is kind of a prerequisite to any of those things. And so that combined with the fact that people are asking for automate deployment, do things like have default packages installed, make sure that I know about security vulnerabilities. I mean, they're all like pretty straightforward in a lot of ways. So I'm curious because we have a lot of founders on this podcast that for the most part have only had projects that have been around for a couple of years. This is probably one of the longest standing projects that a company is built around. And I'm curious, what's hard about that? Because I mentioned on like the plus side, you have a lot of like users already, you have kind of this like group that you can build products for. But on the flip side, like there might already be like set user expectations or competitors. Like what's hard about building the kind of company that you're building right now? I think probably like a sense of momentum or inertia, right? As you, I guess you touched upon a few things there where I think people have a certain idea of how homebrew is and how homebrew works. And I think with the problems as well, like it's funny, John will probably remember, we've had a few discovery calls where we've said to people, okay, so like what problems are you experiencing in your business with homebrew? And they say, no, but it turns out what they actually mean when you dig in, because there's been times we've had those and you can see like John starts sweating, whatever. And I say like, we've come to terms. Yeah. Have you ever had this thing happen? And they're like, yeah, you know, like, so I guess like a classic example might be like, have you ever had the situation where like, you know, homebrew pushes the version upgrade, a bunch of your team upgrades, and then it breaks all your libraries? Like they're like, yeah, like they're like, yeah, that happens at least three or four times a year. And it's like, how much engineer time would you say that cost you? And it's like, well, probably like about a week to two weeks per engineer per year. And it's like, that sounds like, and how many engineers you have using homebrew? Like, oh, a thousand. That sounds like quite a big problem. But like in their head, because homebrew has been around for so long, because homebrew works the way it's always worked in their head, they're just like, this is just a thing. This is like a tax you pay for using an open source project like homebrew, and you just have to deal with this forever. And maybe they tried Nix or Mac ports or something like that, and that just had its own problems. And then they came back to homebrew. So like the idea that like someone could actually fix this so that it never happens again, and those week or two weeks of engineering time of year don't happen, that's much harder for them to like come up with by themselves. And sometimes people really need poked and be, and the funny thing is like, there's some stuff on our roadmap where if we shared it publicly today, we'd probably get like laughed out the room because people are like, there's no way you're ever going to do that. That's way too hard. Right. And I guess I actually know, like, it's actually not that hard. This is doable stuff, but sometimes people's like imagination is, does not stretch big enough to encompass like, what are the easy things and what are the hard things. And I guess another strength that you sort of alluded to Robbie is, you know, we've hired some people already from the homebrew community who are like staggeringly intelligent, talented engineers and know like macOS and like Apple internals and how to make macOS do absurd things that I had no idea it could do that open all these doors for us to do things. And actually, you know, like a lot of the stuff that they maybe don't know as well, like, you know, we're built on a rail stack and they're the people we've heard so far, like new to rails, but it's like, but that's kind of the easy bit, right? Like doing kind of crud logic is easy, but like doing all the kind of complicated wrangling across OSs and like POSIX layers and whatever is all the kind of gnarly hard stuff. So yeah, hopefully that answers your question. Yeah. And when it comes to that tax too, you know, another one of the reasons why the people, you know, the users kind of like have come to terms with it is like the alternative of not using homebrew at all is like just a non-starter, right? I've talked to a number of customers where they're like, yeah, we have an ISO security requirement, but if we actually enforce the ISO security requirement, that means our engineers can't use homebrew. And that's just not an option. We won't do that. So it ends up with them either talking to us or saying we're going to devote an entire engineering team to this for the next year and a half to like make our own internal solution, which I know of a handful of companies that have done that. So yeah, it's, it's definitely a mindset shift of like, you know, homebrew has been around for a long time. It's kind of like, it's part of the ecosystem. People know it and are used to it and that's a benefit, but it also has this kind of, well, they know it for what it is, not for what else you could do with it or, you know, what we might be able to add as well. Cool. So jumping to another side of questions here, you've been working at homebrew for so long and joining me working at GitHub, you've seen a lot of developers in this ecosystem pretty familiar with. What are biggest challenges you didn't anticipate? And now you learn almost like surprises, like, oh wow, this is actually harder than I thought, or I didn't even think of this will be a big problem. What are those kinds of challenges you face, you know, starting this company so far? I mean, one of the reasons I left GitHub in the end and, you know, I joined when we were like 200-ish people and left. And even then that was the second biggest company I'd ever worked for. So for me at workbrew, it's when I came, we're doing a completely greenfield code base, all this type of thing. And, you know, between that and co-pilot and all these tools we have nowadays, I can move so fast and I can get things done like staggeringly quickly. But then every so often you run into a wall of like, oh, I have to like get verified with like Apple Business Manager or like DUNS or some MVM tool or whatever. And it's like, it's so hard to have something where like, I guess there was, you know, some products that we've integrated in and building the integration entirely took two hours, but getting like all the paperwork done so that I could play with the integration took like two months. Yeah. This is like, it's maybe not even hard as a founder. It's just hard for my soul having to deal with things that just take so long. And it just feels so unnecessary that it must take so long, but I get it. These big boy and girl companies can't be startups forever. Yeah. From my perspective, the biggest challenge is like doing things you've never done before. I'm an engineer by background. And I'm also, I've done like a lot of like go to market on developer tools. But as far as a founder goes, you know, I've not really done sales and being an enterprise product, I have a lot of sales conversations. And so I mostly take them from kind of the founder sales approach of just being helpful, trying to understand their problems. And what I found really interesting about that is this is an entire career path that tons of people are very, very talented in and spend many, many years, more years than I've spent as an engineer or as a marketer, you know, honing those skills. And as a new founder, it's like, you have to do it. So one of the things that's been really valuable for me is working with, you know, a former salesperson from GitHub, who I knew really well, and who can kind of like go through the deal process with me, talk to me about like, kind of this particular company that you're talking to, I've sold to, you know, a multimillion dollar deal before, these are the people you need to talk to how to do it. And it's like, there's just a ton and ton of new stuff that we have to learn all the time. And I think that's true for all three of us doing things that are outside of our comfort zone. I actually have an addition there as well, where I think it's the sense of responsibility. Like I had a conversation, I'm hopefully she wouldn't mind me sharing this with my wife a while ago. And she was like, hey, like, are you actually happy at work through? Because you seem to kind of come to me with like so many more problems than when you were at GitHub. And I realized like, yeah, I am happier, but the difference is every problem I had at GitHub, like particularly by the end, it's like 99% of those are outside of my control. Some, my bosses, bosses, bosses, bosses, boss, or someone at Microsoft decided that like, this thing is not happening anymore. And I can't talk to them. I can't influence them. Whereas with the start, with, you know, the three of us are now with employees or whatever. It's like, everything is my problem, right? Like everything is, it might not be on my plate necessarily to solve every problem, but like I have influence over everything. And like that's simultaneously liberating and incredibly terrifying at the same time. And it means that, you know, there's a lot more conversation with my wife where I'm like, what should I do? And she's like, I don't know. And I'm like, well, I don't know. I kind of have to decide because I don't have any adults anymore to decide for me. I feel similarly. So final question for each of you, what's one piece of advice you'd have for an open source founder that is earlier on than you? I guess from my perspective, you know, I'll go back actually to when I started the company. So I started this company in 2019 when I left GitHub shortly thereafter. And I was a solo founder doing something totally different. And I've been through, you know, a number of different pivots. It wasn't necessarily open source, but it was always kind of engineering related. And I think my biggest lesson was like, don't go it alone. Ever since having Vanessa and Mike join, I feel like I've been much happier, had a lot more clarity. You know, when things are confusing or I don't know what to do, it's very easy to just like, you know, talk to my co-founders and work with them. And so I think it's like a very, very special kind of person who could be a solo founder. I thought I was one of them, but I'm definitely not. I would recommend, you know, don't go it alone, whether it's having co-founders or just like a really good network of advisors, people like deeply involved in your business, having other people involved in your open source project, obviously, as well. But, you know, that was like the single biggest inflection point for me and being a founder. I'm going to focus on the open source side of the open source founder, I guess. And I think it's particularly relevant right now. As I said, there's been all this stuff in the news, but I think it's worth paying attention to that stuff. Not necessarily worth paying attention to the naysayers and, you know, the Hacker News crowd who are not always the most positive bunch. But the thing that is worth paying attention to is I think we're all, when you start a company, a product of the moment you're in, right? And you can't look at what worked five years ago or 10 years ago or sometimes even one year ago and try and replicate that model and get the same success. You have to be influenced by them and learn the lessons from the greats and your kind of peers in the industry. But it doesn't work to go and say, well, this model worked for Red Hat or GitHub or whoever, and I'm going to just follow this model with a letter and do things that way. Because we're in a different world now. And like some of these places paved the path in a good way. And some of them, I don't know what the opposite of paving the path is, but, you know, maybe blew up the path along the way and you can't go that way anymore. So, yeah, I guess for me, it's been really helpful to kind of read and learn and soak up as much information as I can about what other open source companies have done and are doing and are planning on doing and just kind of learn from that and combine that with what my co-founders think, what my peers think, and try and pave our own way. And hopefully it works. Awesome. Well, this conversation has been fantastic. We so appreciate both of you joining us. I think our audience is going to take a lot away from this. Thanks for having us. Yeah, it's been great.

Welcome to The Bug Mind, audio only edition. I'm Lorenzo, and you may know me as Calcet, and I'm your host. I've worked many years in open source and have been seeing a therapist for almost as long. In The Bug Mind, I talk with other people in tech about their own mental health stories, hoping that sharing our experiences can help you deal with your own challenges. Get ready, we're diving deep. Hey Mike, it's great to have you here. Welcome. Thanks for having me. Yeah, I'm so happy that you're here. You're literally one of my personal heroes when it comes to open source, so I'm super grateful that you've decided to do this with me. Before we dive into deep, because I'm already so excited, can you tell us a bit more about what you do in tech for someone that doesn't know who you are, which probably are very few people, but just for them. For my mom, probably. Sure thing. So I guess I'll maybe start with what I'm doing right now and then work backwards. So right now I am CTO and co-founder of a startup called Workbrew, who is doing kind of commercialization in the homebrew space. What our product offering is right now is providing MDM support, commercial enterprise level support and general kind of features that kind of big companies need around using homebrew. If you know what homebrew is already, then great. If you don't, it's an open source package manager for predominantly macOS, but also for Linux. I've worked on homebrew for 15 years. I'm the project leader, which means, I guess, kind of tech lead and figurehead in some ways, but it's also an elected position. And I am also, I guess, I've worked as a maintainer doing bits and pieces on homebrew for that entire time. And homebrew was 15 earlier this week. So it's a nice little celebration. Happy birthday, homebrew. Yeah, happy birthday to homebrew. So before I was working at Workbrew, I worked at GitHub for 10 years, where I left as a principal engineer. I worked on all sorts of things. Like I built the archiving repos feature. That was my kind of idea. And then the GitHub sponsors worked on that, the merge queue, all sorts of like little bits and pieces over the years. Before that, worked at a few other kind of random startups and companies and stuff and did the kind of, you know, I guess, most stereotypical slash traditional route into tech of doing a computer science. And business degree back in the day. Awesome. And, you know, you mentioned being an open source maintainer. And this is what we want to talk about today. We're both open source maintainers. This month is May, as you were saying earlier. And it's both Mental Health Month, Mental Health Awareness Month, and GitHub's maintainers month. So it felt like a nice coincidence to have these two months collide and have the two of us talking about, you know, not only our experience in open source, but also like the mental health aspect of it. Because I think that open source maintainers in particular, like they're very prone to burnout. They're very prone to isolation. And, you know, I think we've both had our fair share of experiences that have been stressful or, you know, challenging. And I would love for people to basically, you know, learn from our experience and create for themselves maybe an healthier approach towards open source. And, you know, that's actually where I wanted to start about. So let's say you would start today doing open source, right, with your previous experiences, but like everything else is like the real world doesn't know about it. You're kind of like reincarnated in a younger version of you. Like, how would you set up your relationship to open source? That's a great question. I think the main thing I would say is boundaries. So the boundaries are kind of all over the place. So some of it's boundaries with myself, some of it's boundaries with other people, some of it's boundaries with work, all that type of thing. But I guess I might spell out some specifics of what that might look like. So nowadays, what I have is all my Homebrew GitHub notifications, for example, go to a separate email account, which is, you know, my mikeatbrew.sh address. And what that means for me is I can check them separately. I can add or remove them to my phone. I can add or remove them to any computer or device. Separately, I can log in. And I have that separation between what's going on in my kind of day-to-day, what's going on in my work, and what's going on in Homebrew stuff. So, for example, I don't have Homebrew emails on my phone. Similarly with Slack. Homebrew has a Slack for maintainers to talk with each other. I don't have that on my phone either, unless I'm going on, like, a trip where I'm with Homebrew maintainers all the time and all that type of stuff. So, basically, what this ends up meaning is I can be a lot more intentional about the time I spend and when I'm almost, like, ready for that energy in my life and thinking about Homebrew stuff, getting involved with Homebrew stuff, replying to Homebrew stuff. And in my case, it's kind of in more of a leadership role nowadays than I necessarily always have been. It also gives other people space to be, like, if someone's like, oh, this is on fire, then it's not like Mike jumps in straight away and fixes it. You know, sometimes, depending on when you ask, depending on the week, it may be if you ask that at 5.31 p.m. on a Friday, then Mike is not going to respond until 8.30 a.m. or later on a Monday, even on, like, almost like a normal working week, because I want to spend my weekend with my wife and kids and all that type of stuff. And I think it's a very strong strategy, like, creating this separation. It's basically the same. I do a similar thing for React Native. Basically, I'm even, in a way, more extreme when it comes to email. Like, I literally have disabled GitHub sending me emails of any shape or form. So, in that sense, like, what I do is I'm very intentional, like, subscribing to certain issues, subscribing to certain repositories. And, you know, like, I only interact with GitHub when I'm on GitHub. So, there is that, you know, step of intentionality that you create. Like, oh, I'm not passively receiving everything constantly, but I'm like, okay, if now I have time to, you know, spend an hour looking at through GitHub notifications and replying to people, I'm going to open GitHub, and that's the time where I'm going to do that, right? So, I think that's super important in general. And it's also, in the broader mental health community, there's these, like, the theory of the spoons, in a way. Have you heard of it? Yeah. Yeah, it's basically that, right? You have a certain set of spoons that you can use every day for your tasks. So, acknowledging yourself, you know, you're like, okay, today I have only three spoons, today I have seven spoons. Like, knowing, like, that you, your battery has a limit, and be like, okay, being intentional, I'm going to use two spoons for GitHub today. It's, I think it's one of the, yeah, it's a very healthy strategy, I find. And, why do you think it's necessary? Like, kind of like, you know, flipping the question on its head, like, what's going on in open source for maybe someone that is not as involved as, like, that, you know, you kind of need to create these. You kind of need to create this healthier relationship. Yeah. So, I think it's, for me, again, like, my patterns with open source have somewhat mirrored my patterns with work. They've been maybe slightly kind of time lagged compared to my patterns with work. But, you know, when I was young and enthusiastic and working for a kind of working all hours startup, which is not, you know, I work hard right now on my startup, but I'm not working as many hours as I did when I was 25, because I have other commitments. But there was that sense of being switched on and being engaged 24-7 and being responsive 24-7 and that being a desirable thing that resulted in better quality software and, you know, more whatever, like, for employees or employers or whatever. Whereas, I think I realized on the work side first that, like, I actually think that results in, in the long term, like, worse software, worse teams, worse happiness for everyone involved compared to if you separate things. And I like that one used before, intentionality. I feel like that's a really big thing where it's just important to kind of think about when you're spending that time and energy. So, for me, from, you know, a relatively early stage at GitHub, when I worked there, I'm based in Scotland, and most of my coworkers, most of the time I was at GitHub, were in the US. So, what would happen is if I just had Slack on my phone, then my evening would just be ping, ping, ping, ping, ping, ping, right? So, Slack was the first to go, and then, particularly because once I was on on-call rotations, it's like, well, if someone really needs me, they can page me, right? So, it's, if it's critical, I'll do it that way. And then, you know, email went similarly that I didn't put work email on my phone unless I was on a work trip or whatever, and frankly, I just, like, wanted the distraction because I was away from my family and stuff. But open source kind of maybe took a little bit longer for me to internalize the same attitudes, but I do actually think in lots of ways, frankly, almost everyone would be better probably making open source a bit more like work. I mean, for some people, maybe yourself, Lorenzo, I'm actually not sure right now, like, like React Native is maybe a big part of or your primary day job purpose, right? If you're an open source person in that situation, I think you should treat it 100% as work, right? And evenings and weekends and holidays and whatever, you should entirely disconnect as most people would agree would be sensible for work. I think people find that harder when they're doing open source because there's less of an expectation there. But I think even if you're a volunteer or a hobbyist, I think it's still valuable to almost be like, right, I work on this, you know, 9 to 5 on Friday or whatever it may be, right? That's, I appreciate that's harder for people whose employers maybe say, right, you cannot spend even two minutes on open source during your work day. But again, I would, in my case, I probably had at most a couple of years at GitHub where it was deemed officially acceptable for me to spend any time on homebrew. And I probably had a couple of months every three or four years where I worked on a homebrew related project. But the rest of that time, it was like, you know, essentially, as long as I'm getting my work done, no one cares. But equally, if I, if they were aware quite how much time I spent on homebrew during working hours, someone would probably be like, hey, like, that's too much. But I got my work done. I got good performance reviews. So ultimately, that's not their problem. And it's easier for me to balance things that way. Things are a bit more blurred now because I'm doing a startup that is directly attached to homebrew, which involves, you know, sometimes building homebrew features for my day job, effectively. But even before that, like, even in GitHub, I was probably doing the majority of my homebrew stuff is like within working hours in a working capacity. And I also even think like open source, again, in terms of boundaries, like open source interpersonal relationships can sometimes be quite, I guess, non-work. Like, you know, either work in appropriate conversation, either people speaking to each other in a way that would get one of them fired in a workplace, like people being unreasonable, unwilling and unable to do things that would be a very basic expectation of a junior engineer in a workspace, a workplace even. And I think all of this stuff, you know, it's, it has its place. And for some people, sometimes it makes open source better. But I'm not convinced that actually, you know, certainly if you're a project at like homebrew's level of scale, I think indulging people who want to behave in a way that would get them almost instantly fired in most workplaces is not a good idea. Like you shouldn't, like that people have the freedom to decide to when to show up, what to do, what not to do on an open source project. I'm the leader of homebrew, but I can't make anyone do anything on the project. I can sort of stop people doing things, but I can't make people do things. And to me, like that's, that's the side that makes it better and more enjoyable than work. Like, it shouldn't be that we're like, oh, well, we can all do whatever and behave in kind of very weird, inappropriate ways. Not saying this is the case in homebrew, but has been some isolated cases in the past where there has been that. And it's taken me too long to be like, hey, actually, you know what, like this wouldn't be acceptable in a workplace. It's not acceptable here. Like change it or move on. Yeah. There's so much to unpacking what you just said. I think I want to try to separate a few threads. So first off, so yes, at the moment, I think that like your current role and my current role at Microsoft mirror each other quite well in the sense that the project that we help maintain in the open source and that started as something separate from work has become an intrinsic part of our work. And if I were to give someone as a suggestion, I would say that's probably one of the healthier ways to approach open source that you were saying, because at that point it's like, okay, this is work. When I'm not working, I'm not connected to that. And that feeds into the second thing that you kind of like mentioned, which is like open source by its inherent nature. It's kind of like on 24 seven, you know, when you're maybe, you know, you're in Scotland, it means that maybe during the time you're sleeping, someone is using homebrew in some other parts of the world and they're opening an issue. And maybe it's something urgent and important for them, but you're, you know, in Scotland, you're sleeping, it's the middle of the night. So having this aspect of the open source being always up, always running, always someone doing something, I think that that's like one of the traps that a lot of people fall into. Because like, well, I just received this email, it's like, you know, 11pm, but this person really needs my help. Sometimes people just like feel this overwhelming sense of responsibility, which is where like, you know, having boundaries, I think it's very important. And kind of going down this route for a second, um, and mentioning what is probably like the most, uh, the most impactful blog post I've read in many years. I wanted to touch a second on, you know, one of the articles you wrote, I think in 2017 or even earlier than that, which was called, um, maintainers owe you nothing. Like, uh, to quickly give a backstory, I was just starting out as a maintainer. I was like, um, yeah, 2017 around then. And basically I started, I, it wasn't part of my daily job. So I was doing it on the side and I was doing it a lot, like many, many hours every weekend. And in less than three months, I basically burned out. And then I found your blog post that basically says, well, you know, like it's open source and open source project. I'll have a license and this license says the software is provided as is, uh, without warranty guarantees, et cetera, et cetera. And, you know, you through that blog post explaining that that's kind of the contract that you create with your consumers. Um, like that should set your expectations for yourself and also for your community to kind of like, if you use it, it's not my responsibility, how it goes. And yeah, I don't know. I, I still think that's one of the most important things that all the maintainers should learn. Uh, how did you, what, let's start from the beginning. How did you decide to write that? What motivated you to go there? Uh, I can't quite remember. I think it was, I mean, obviously I'd been involved with Homebrew for a while at that point. And I'd had a bunch of conversations with maintainers kind of over the years and I realized that I guess at this point I'd been working on Homebrew for five plus years. And in contrast to many of the people around me in Homebrew and many other projects, I had never burned out, right? Like I had never both in the perspective of like, and I still say that today, but I I've had 15 years. I've never burned out of Homebrew. I have there been times when Homebrew has been more enjoyable and less enjoyable for sure. But probably in 15 years, I don't think there has been a, a month in which I've not done something related to Homebrew in that time. Um, and, and also I, but the thing is, I've not felt the obligation either to do that. Like I've, I've done it and I've continued to do it and I continue to do it because I want to and because I enjoy it. And I also interesting, I didn't realize this at the time, but if you, uh, if you Google my name, you find my website and stuff like that. But if you Google Mike McQuaid asshole, uh, you will find various people on, uh, mainly Reddit, I think. But I think, you know, there's a couple of people in Hacker News who don't, oh no, exactly. Well, I think, I think there's an important point in that though. Cause I think what is interesting is that, um, you, what you need to set yourself up for expectations wise, and this is a good, maybe lesson for life, not just open source is that if you have healthy boundaries and if you are doing things like, as I say, want to be an open source maintainer, working on the same project for 15 years and not get burned out. Some people are not going to like that, right? Some people are going to call you an asshole. Some people are going to call you selfish. Some people are going to call you the one who's entitled or lazy or a bad engineer or whatever it may be. But the thing is, is that that those two things go together. And if you are chasing people's praise, then you are going to be the one who, as you say, is answering the email at 11 o'clock at night. The issue, this person desperately needs my help. I need to drop everything and help them because I owe this person stuff. It's like, actually you don't, right? Like, as the blog post goes into the details of and as open source licenses state, you don't know anyone anything. Like, literally, if you dig into what the licenses say, it's actually quite surprising where the licenses literally say, if I break things on purpose on your computer, that is, in using the software, you waive me of all liability and responsibility. Now, whether that would stand up in court, if you actually did that on purpose, remains to be seen. But, like, that is what the licenses state. The licenses state, like, if you want to use this software, you agree to all these terms in using the software. Right. So, if you don't like it, that's fine. And now you can't use it. Right. So, I think there's the letter of the law with this stuff. And then there's, like, the popular conception, which is like, well, actually, you know, and even in responses to this blog post, I've seen people like, well, you know, okay, technically, open source maintainers don't owe you anything. But, like, you know, really, they should, if there's an urgent thing that needs fixed, like, they should fix that because they put this out into the world and they have that degree of responsibility. And I just, I reject that. Like, I don't think that applies to people who are volunteers. By all means, hold billion dollar corporations to that standard. By all means, hold companies that you are paying and have a support contract with to that standard. But some random person who has received either none or through GitHub sponsors probably, like, you know, 100x below market rate level compensation for their open source work, it's, that person owes you nothing. And you are, particularly if you're a large organization or corporation, if you expect that person to jump when you need them to, like, you're actually very foolish. Like, you are being very irresponsible and silly to put the back of your organization on the back of that one individual. So, I think that's where it came from, basically. The blog post, it just, it felt like something that I had internalized quite a while before and a lot of people needed to hear. And as I sort of predicted when I wrote it, like, a lot of maintainers really liked it, resonated with them heavily. I've got a lot of public and private feedback and I still see random people posting it and sending it to other maintainers on Twitter or Mastodon or whatever to this day. And an awful lot of open source users who have never been a maintainer find it incredibly offensive. And I think, the thing is, I don't think you could do it without, I don't think you could do one of those things without the other, basically. Yeah, it's, I guess, in a way, it created this polarization because some people have a perception that open source is supposed to be something. And if someone tells them, okay, here's the line, they're like, well, that's not my line. So they kind of like, get offended. And it's, I think that it's, I'm so happy, by the way, to hear that you never had a burnout. I had one and a half, like the first one was before I found out your blog post. The second one was kind of like, for work-related reasons back then. But it's, I think that it's very unique in a sense, like how your ability to create these boundaries allowed you to survive this long in a way. Literally, I think last week or two weeks ago, there was a maintainer that, like, out of the blue, like, literally archived their projects because they received an email that was absolutely, like, vile. Like, it was just, like, full of insults and everything. And they, and what they did was, you know, name and shame. They literally screenshotted the email and put it in the readme. Like, well, the project is not being maintained anymore because of this. And especially now, not only this type of behavior sadly still exists in open source, and we should call it out as something that people should not do. Let's be clear. People should not behave like that in open source. Like, you're not entitled to anything. But also, we've learned that, for example, for the XY, XZ attack, basically what happened was that the actor basically social engineered to get the maintainer because they were in a vulnerable position, like, a person working on their own, working on a side project. Like, they managed to barely, basically, as far as I understood, like, bully them out of the project. So, if anything, right now, it's even more important that, you know, what you're stating in the blog post is, like, basically, we need all the open source maintainers to kind of, like, create those barriers in their mind. Like, create this level of, like, extra skin around their body to kind of, like, make sure that they don't get overwhelmed. Especially, like, you also brought up Reddit, and I still think that we're entering now a phase where people sometimes, I don't know if that's also your experience, but some people act in GitHub, in the GitHub issues, literally as if it was Reddit, like, and that's incredible to me. And, you know, you mentioned, like, the role of, like, being a lead in a big project and, like, you know, telling people, okay, if you behave this way, you're not welcome here. Open source projects have code of conducts and similar things. How do you think, does these things help in your experience with, like, how your community uses your project? I think so. So, for me, code of conducts have gone back and forth, I think. And I think my view is they're helpful, but not as helpful as people might think they are, and only helpful when they're not tokenistic, right? Like, so, if you're just, like, oh, well, you know, GitHub tells me to add a code of conduct, so I'm going to add a code of conduct, and then you don't enforce it or even really read it, and you just use someone else's copy-pasted thing that you don't really think about. I don't think that's, I don't think that really achieves anything, right? Because you're not actually making it a better or safer space. We took a code of conduct, I think, from before it was that popular or widely done on GitHub repos. We were one of the kind of earlier projects to kind of have a code of conduct, and we avoided some of the kind of drama around whether code of conducts are good or bad, I think, as a result of that, because we were, you know, we got in there before, and we, I think, we based it off Python's, maybe, like, in-person event code of conduct. But the big thing with us on code of conduct is it's, like, essentially, it's, we have a very, very low, again, things people don't like about homebrew, things people don't like about me, we have a very low tolerance to banning people, particularly people who have never contributed to the project, right? Like, if, essentially, my rule on almost any open source interaction, right, is, if it's going south on homebrew, is, if I consider your behavior to be inappropriate, whether or not you agree or not, that's, you know, in some ways irrelevant, right? Like, if I consider your behavior to be inappropriate, I will publicly state on GitHub, providing I don't have any sort of private means of contacting you, which I normally don't. I will publicly state on GitHub, like, essentially, this is out of order, like, please read our code of conduct and adjust your behavior. Nine times out of 10, maybe 95 times out of 100, that person will then apologize, sometimes with a very bad apology, but, like, at least they're trying, right? They will apologize, they will adjust their behavior, and then we're fine moving forwards. The other proportion of the time, people get argumentative or defensive or say, no, actually, I don't have to behave that way, or, actually, Mike McQuaid, your behavior is worse than my behavior, whatever. My experience has been, and it's up to people, what they do on their different projects, as soon as things go that way, that is never recovered, right? Like, a person who, when called out on bad behavior, and again, another open source to real world tip, if you have friends, family members, whatever, who, if you say, hey, you've upset me or hurt me or whatever, if their response is generally, like, anything other than, sorry, and then they can go and say their piece afterwards, like, then, that's not great. But yeah, in open source, my response now is, like, if that person basically doubles down on their behavior, or doesn't apologize, and doesn't even try and do, like, a shitty, I'm sorry you feel that way. I was about to say the same thing. Sorry you feel that way is, like, a bad apology, but, like, sometimes people are actually trying to apologize. They just have never got very good at apologizing, right? And, like, you know, I take that as, like, and then, for me, I'm then, like, okay, like, thank you for the apology. We're all good, right? Whereas the other people, I will almost certainly immediately ban them from the project. If they are someone for whom we haven't seen positive contributions or whatever before, they will get banned forever, basically, straight away, right? And that means they can't submit issues, pull requests, discussion comments. Essentially, for the homebrew organization on GitHub, they have no access to that ever again. And, again, for me, that's, this is the benefit of the code of conduct, because the code of conduct sets quite clear expectations on what behavior is inappropriate and inappropriate. And, again, some people don't get even asked for, to apologize. So, if you jump in with, like, an ethnic slur or, like, a, you know, sexist or transphobic slur or whatever, then, like, you just get banned straight away. There's not even a conversation there. There's no, particularly, you know, as I say, if you're someone who we've had no interaction with before, and you decide, yeah, my first contribution to the homebrew issue tracker is going to be posting, like, garbage like that, then it's like, well, no, like, fuck it. Like, it's not even worth the emotional energy trying to deal with and fix those people. But, in some way, that leads me to, like, a, just a wider point on this stuff, which is, I think, another funny thing with hierarchy and open source. And I do think it's good that there's a lot more encouragement than there used to be to try and get design resources, docs resources, whatever, involved in projects, getting people contributing and stuff like that. But, fundamentally, in a software project, maintainers who are working on code, they are the most important thing on that project. Because if they do not get involved, if all the maintainers who write all the code, review the PRs, do the releases, if they all go away or they stop replying to their notifications, that project is now dead. That project does not exist anymore. That software is now unmaintained. So, at the end of the day, like, actually, and again, the other funny opposite end of the spectrum is, if you are a software company selling things to people for money or, you know, selling people's eyeballs, if you're an advertising-funded company, your users are your customers and they're important to the success of your business. In open source, a user who never files an issue report that actually ends up, you know, being a reproducible bug that is fixed for other people or whatever, never files a PR, whatever, they just use the software, they provide no value to the open source project, right? So, with those people, the minute they are in a situation where they are ruining the day of maintainers and sapping the motivation of maintainers to work on that project, those people need to be, their communication needs to be stopped immediately. Because those people actually, and I'm not exaggerating, those are the people who are at the biggest risk of killing open source software, are entitled people who are rude and who make maintainers be like, you know, I guess the 11 o'clock email example, right? Like, there might be a maintainer who's spending their evening having a great time working on some code and an issue comes in and then they're just like, oh, fuck this. I don't want to spend the rest of my evening doing this. I'm going to go and have an early night or have a drink or watch some TV or whatever instead because this person has now just made my evening not fun. Like, that time that that maintainer would have spent has been stolen by the person being rude or entitled or horrible or whatever. So, like, those people have no value in open source and we should just silence them as quickly and as effectively as we can. So, like, I think that maybe, you know, it's more likely that the people listening to this are also, like, not maintainers. So, just to explain it to them, I think, I don't know about you, but I think at some point you kind of, like, get quite adjusted to recognizing how someone is communicating and figuring out, okay, this is probably a person that wants to still be helpful. They'll just have, you know, a bit of a more direct style of communication and instead, like, recognizing that versus someone that is actually just trying to be provocative, toxic, or, you know, as you were saying, like, detrimental to the project. So, and not just that, the GitHub interface will tell you, like, if this person has ever contributed to your project. And if you've worked on a project for a long time, sometimes you start recognizing the usernames and the avatars. So, you know, I'm not saying you should fear the maintainers, but, like, don't think the maintainers are stupid. Yeah. That's, I guess, what I wanted to say. It's just, like, they are humans. Yeah. Given your caveat that most people listening to this are not open source maintainers themselves, I guess the two things I would state there is, one, as I mentioned before, when I talk about, like, silencing these people or whatever as quickly as possible, I mean the people who, when they're asked to apologize, do not apologize, right? If your communication is, I have very direct communication style, and if someone is like, Mike, you're being a dick or whatever, then I will almost, almost always be like, I'm sorry. Like, I'm sorry. And then try and adjust my behavior and communication going forward. So, like, but, and the second thing is, like a lot of things in life, right? Like, I heard a good line a while ago, like, you know, if you're worrying about whether or not you're a good parent, you're probably a good parent. It's, you know, the bad parents are the ones who are not worrying about whether or not they're good, right? It's the same thing where if you heard what I said before and you're like, oh, no, maybe I'm this person, maybe I'm the one who's, like, a toxic open source contributor I never realized until now, you're not, right? Like, the people who are like that, because I've had the misfortune sometimes to meet a couple of them in person, like, they are completely oblivious and completely convinced that they are in the right and the open source projects are in the wrong, right? So, if you have that, if you heard me say this before and you're now getting a nagging sense of, like, oh, that's maybe not, that's me. It's not you. I'm not talking about you. Like, I'm talking about the people who will hear this and think that's definitely not me. Yeah, and also, like, to kind of, like, hammer down, like, if you're worried about this, you're probably not one of them. I think after a certain point, you also recognize when English is not their first language. Maybe for me it's also easier because I'm also a person that doesn't have English as first language. So, at some point, you recognize if someone is inadvertently being, you know, abrasive just because maybe what they did was literally put in Google Translate their phrase, copy-pasted it, and Translate just went for it. So, you know, yeah, it's that bit of the second interactions where it's really telling if there's intentionality. Yeah, and, yeah, I mean, okay, so we've talked about the bad aspect of the community, you know, and how that can really weigh down on a maintainer and, like, literally destroy their mental health, especially if they don't have, you know, these good level of separation and boundaries. Maybe, you know, just to kind of, like, lift the spirits a bit, like, how do you see the role of the community around an open source project? You mentioned, you know, that the software engineers, the people that are actually working on the project themselves are the very important people because they are the ones bringing the project forward. Like, in Direct Native, I've seen, like, how the power of the community and creating a good community and healthy community around the project is really what, you know, maximizes the impact and, you know, the success of the project. So, what do you think about that? How do you find that your relationship with the community works? Yeah, I mean, I've heard, like, there's been a bunch of successful communities I've been part of. Some open source, some not. But, like, one of the rules that I think is nicest with, like, if you want to be a good member of a community or if you want to have a community mainly full of good people, it's you should be aiming to help others as much, if not ideally more than you are yourself being helped. If you are just, the only time you ever interact with a homebrew is your tracker is to ask a question and then your question gets answered, then you never do anything ever again. Like, that's fine. Like, that's not, I'm not saying, like, that's terrible. But I'm saying if you have a community that is entirely of that nature, then, like, that is not great. And even on that, you know, if you ask a question and you get help and, you know, even just stuff like saying, thank you, homebrew's great, you rock, like, those messages are surprisingly rare. And if someone just shows a bit of gratitude, then it does, it's the opposite of what I said before of, like, you know, ruining maintainer's evening. Like, sometimes that can sort of make a maintainer's day of being like, oh, great, this person was really nice and helpful. But, yeah, but that's the thing is I've talked, it's a little bit, like, maybe of a random tangent, but, like, I've talked before and I wrote a blog post about this thing I called the mentorship diamond, where, you know, when I was principal engineer at GitHub, like, an increasing proportion of my job as I got promoted was doing mentorship, right? And not just mentoring, but, like, mentoring other people on how to mentor and all this type of stuff. And the idea of, like, the diamond is that, like, every person has, and in some ways I stole this from when I used to be religious, I forget the religious version, but essentially, like, every person should ideally have, like, people above them that you can receive mentorship from, people below them that you can give mentorship to, and then peers who you can almost, like, sort of have a kind of mutual kind of mentor-mentee relationship depending on what you're talking about or, like, support each other and whatever, right? And I think the same thing goes for open source. It's, like, if you've, you know, used Homebrew for a year, say, right, and you've never had any issues, you never had any problems on the issue tracker, there's still probably questions that people ask in the Homebrew discussion forum that you could answer, right? So it's, I think the community is getting the idea that, like, no one is not knowledgeable enough to help, and it's about motivation and time investment and how much do you want to do stuff. Because, again, like, a relatively common practice that we have in Homebrew is, like, we have essentially, like, three types of issues that maybe get opened. So one might be, like, yeah, we should definitely do this, one of the maintainers is probably going to jump on this, and whether it's a bug or a feature or whatever, like, yeah, like, essentially, great idea, someone will do this, like, well done. And then at the other end, we have a, like, no one is going to do this, right, even if someone makes a perfect pull request for this, we do not want Homebrew to do this thing. And then there's the middle ground, which is, in some ways, the most interesting, where we're, like, none of the maintainers are probably going to do this right now. But if you want to do this, then we will accept this, right? Like, we would accept that functionality. And, again, that's when I think the community stuff gets more interesting, because, like, we try and essentially then we're sort of doing a bit of a nudge to be like, hey, like, you're a user, you want a thing, like, nudge, nudge, you too could become a contributor. And that's what often people say, you know, oh, well, I've never written any Ruby before, so I couldn't possibly do any of this. And my response is often, like, I hadn't written any Ruby before, before I started contributing to Homebrew. And now I've been doing it professionally for 15 years, and I speak at Ruby conferences and whatever, right? Like, it's one of those things where, like, your willingness to kind of, like, walk that way goes a very long way. And also, like, even your willingness to kind of open a PR that's completely broken, but, like, at least you've tried, and then maintainers will get involved and help you out and all that type of thing. So I think that's what I see with almost, like, the community side is that I want to see, like, people trying to help, and then that, in turn, attracts help from others and, like, people get together and do that. Whereas when people are being more extractive, they just want to get out, they're probably being solved, and then they're going to go away and have to talk to you ever again. Like, that's fine. Like, that happens. That's probably even the majority of people in the community, and that's okay. But, like, that's not really what we want to be encouraging or rewarding, and that's not really the top of my priorities to kind of help those type of people, basically. Yeah. You, to talk to our audience, like, don't be the person with opening issue, saying that they have a problem, and then a week later, write a comment, oh, never mind, solved, and don't explain how you solved it. Like, that's the very minimal. Like, you at least want to contribute that small piece back of, like, hey, I fixed this this way, you know? And I get a lot of people asking me, like, how they can get started in open source and, you know, how to do, how to become a maintainer, how to be part of a project. And as you were just saying, like, it's just about showing up, being willing to collaborate with others, and, you know, don't be scared to try things out that you've never tried yourself. Like, your project, even React Native is, like, by, is inerity nature, you know, it's JavaScript, Kotlin, Java, Objective-C, Swift, like, there's the layer, and then there are all these layers below. So it's, like, seven or eight technologies that are just working in a massive concert. Like, there's no way someone knows all of all of them, you know? So you cannot expect, like, oh, if I want to become a maintainer of that project, I need to be good in everything. It's like, no one, even of the existing maintainers, is that good. So, yeah, talking about that, and kind of, like, going back to you, in a way, like, you mentioned, you know, you've been doing it for 15 years, you've been doing it because you like what you do. Like, if you had to, I guess, explain how motivation works for you, how does that look like? Like, how can you do something for 15 years? I find that, for me, thinking to do something for 15 years is incredibly exhausting. Like, how do you find that motivation? Well, I mean, I guess I would say that it's, you know, aside from my marriage and some of my closest friendships, you know, it's the, I haven't done anything for 15 years as long as home room in my life other than that, right? But I think for me, it's, I don't know, I, again, like, maybe my, my marriage is a kind of a good example, like, without getting into too many details, you know, we, we met when we were both young and whatever. And it, it wasn't one of these things where we were like, you know, where, when we started going out, like, oh, we're going to get, like, instantly, like, we're going to get married and have kids and, you know, whatever. It was just like, I like this person, they like me, we have a good time, and we kept having a good time. And, you know, in my case, over 20 years later, we're still having a good time, right? And it's kind of the same thing with homebrew, with me in some ways, where it's like, I just started getting involved because I was like, I need this tool to do some stuff it doesn't currently do. And I want to do it, and doing that is fun, right? So doing homebrew stuff is still fun. I still find it engages me in a way that is enjoyable. And particularly when, when I have had kind of day jobs in the past, like, there is a refreshing, I find, like, my homebrew contributions have been balanced out by essentially, like, how, how much autonomy I have in whatever day job I'm doing. Like, like, how much control I have over what I'm doing, when I'm working, like, how I write my code, whatever. Because in open source, you have, like, at the absolute minimum, like, a lot more autonomy generally than a typical day job. And I think that's the thing for me, it's just, I mean, every time I sit down and do homebrew stuff, it's, you know, if someone was to literally say, like, you know, why are you doing this? You know, I'd be like, well, because homebrew's fun. And if it, you know, is it frustrating sometimes when I can't get a bloody test to pass? Yes, of course. But, like, it's still kind of worth it overall in, like, kind of bigger picture thing. And I think, I don't know, like, I guess I'm funny, I'm still, like, a big gamer, I play, you know, a reasonable amount of computer games and stuff like that. But, like, it's funny, because there's certain games that just, like, they hit my brain in the same way as, like, like, a friend got me into, I think it was, like, Factorio or something like that. Oh, Factorio, yeah. Yeah, like, kind of logic-y based ones. And it's funny, because eventually they, like, hit my brain in a way that I was like, oh, this is, like, the same as programming, right? Nice. The difference is, like, in a funny way, for me, it's actually, like, not nice, because I'm, like, this is just the same amount of fun, no more or no less than homebrew. But when I do homebrew, particularly nowadays, it's, like, literally millions of people benefit from the stuff I do, right? So, it's, like, when it's fun for me and it's beneficial to lots of people, then that's a kind of a nice sweet spot. And, again, you know, I mentioned before all the haters and stuff like that. It's, like, at the end of the day, like, you know, I wouldn't say I'm an arrogant guy, but I'm definitely a guy who's, like, has sufficient self-confidence. And, like, you know, when I get some person being, like, oh, you should run your project this way or, like, you're terrible at this or whatever. It's, like, well, you know, I was principal engineer at GitHub. Like, I've been running the homebrew for a while. Homebrew's got quite a lot of users. Like, the thing I don't say, but I do think, is, like, what have you done, right? And most of the time, the people who are the quickest to criticize, the answer is nothing. Like, they've not done anything of any real note or whatever, right? And that's fine. I'm not saying they should have done, but it is saying, like, I'm not going to let that person define my self-worth, right? Like, if John Carmack or someone who, you know, some other person that I grew up, like, idolizing, right? Like, if he, like, met me at a conference and was, like, oh, by the way, Mike, I've been following your career closely. Turns out you're actually worth this piece of shit, right? Like, that would probably hit me a little bit harder, right? Like, even then, I still think I'd be, like, well, actually, you know what? Like, I have a happy life. I'm balanced. But, like, I think that's the thing. I think it's, at the end of the day, I guess, the shorter answer to a lot of this stuff would be most of my motivation for most of my stuff in my life is intrinsic. Like, I don't do it for external validation. Or when I, or when my intrinsic motivation involves other people, it's knowing that other people are benefiting from what I'm doing, even if they don't say thank you to me. It's, like, every time I see someone type a home root command into a terminal, like, them typing that command, like, I hear a little, you know, you're welcome. Thank you. Or, like, you know, and I have a little, like, mental, like, yeah, you're welcome. Like, and to some people that would seem maybe very, I mean, particularly British or Scottish people, like, that would seem maybe very arrogant or self-involved or whatever. But I think for me, it's, like, that's how I get through it, right? So it's, like, and, again, to jump way back to what you were saying about burnout, it's, like, at the end of the day, the best thing for you as an open source maintainer is to not get burned out, right? Like, if you work on a project, particularly if you're a solo maintainer, right, like, what your community and your users want is they want you to be around. Like, you're still doing this in 10 years, right? Like, and if you answering a issue at 11 p.m. makes, every time you do that, you're probably making it a little bit less likely that you're going to be around in a few years. Like, that's actually, they don't know that they don't want you to do that, but they actually kind of don't want you to do that, right? It's kind of self-defeating for their own interests, like, them being, like, this is very important and you need to not sleep enough tonight to fix this thing. Yeah. Yeah, there's, you know, the shortened goals and the long-term sustainability of the project, in a way, at a play when you take those decisions. And there's, I loved your answer also because, kind of, like, reframe it in a certain way. Like, there's, you know, control over what you do. You see, you know, a result out of your direct actions and you also, and that's all, like, around a good core of, you know, knowing yourself and being able to, you say, okay, this thing is outside of me. Like, even if John Carmack said to me that I'm not good at my thing, I can individually, like, by myself, identify the things that are good for my life and the things that I'm good at. And the spy team, I would still have, like, this good core internally. And I think this is very important and it's not, like, necessarily an innate skill, like, being able to recognize why you like something. Even, you know, having, like, this, you know, this strong core internally to kind of, like, make sure you don't weave too much. Some time ago, you also wrote a blog post about therapy and, you know, finding a therapist. Is that something that helped with that? Do you think that, how would you help someone, you know, create this core and, like, this level of, you know, awareness and knowing your limits and knowing what works and doesn't work for you? Yeah, I mean, I think therapy for me has been very helpful. Like, I started therapy for the first time during COVID. And, yeah, I think it was just, you know, obviously that was a tough time for, you know, literally the majority of the world. So, but, yeah, like, I think it was something I found very helpful in kind of figuring stuff out. And also, like, for me, it was, like, having kids and being, like, aware. So, A, I'm not going to go into, like, details really here. But, like, you know, I had some aspects of my upbringing were pretty tough. And there's, like, pros and cons from that. Like, one of the cons, which I wanted to address in therapy, is, like, hey, like, how do I stop these? This is me using current therapeutic language. I didn't, I wouldn't have put it this way at the beginning. But essentially, like, how do I stop myself using these kind of coping mechanisms that maybe in the past have been very helpful, but right now are not helping me, right? But the flip side of that is, like, I have, you know, as the result of kind of a difficult past, like, essentially my life gets better every year, right? And has done pretty much since my school days. And for me, like, I came into open source with probably a, well, almost certainly a dramatically thicker skin than average, right? Like, I don't get, people have sent me some truly horrendous emails and, like, I'm able to kind of, even before therapy, found myself able to laugh them off more often than not. Because I'm just, like, you know, this person thinks, like, essentially, like, this person thinks that they're going to really succeed and hurt me by saying this stuff. They don't know me. Like, I don't care. They're a moron. Whatever. But, yeah, but I guess I have found therapy particularly useful in the last few years of identifying, like, what do I need? What should I be doing with my time? What should I have in my life? And, yeah, and I just, it's something I've just found very, like, particularly as, like, life gets more full and stressful and difficult. It's, it just really helps to have that space where I have someone kind of to talk to and figure out, like, what should I be doing? Like, what do I think in a very, like, non-judgmental, like, centered around my values rather than the other person kind of trying to project their values on me and stuff like that. And as you mentioned, the kind of blog post I wrote, like, if anyone listening to this thinks, oh, like, therapy is something that kind of I might try or is helpful, or I would say even more so if someone listening to this has had essentially anyone in their life who have done therapy be like, hey, by the way, it would probably be helpful for you. You'd probably benefit from doing therapy. Then I'd strongly encourage you to investigate that. And the blog post I wrote was essentially, I stole it off some other people who told it to me, which was, like, a step-by-step guide of, like, okay, I want to get a therapist. Like, how do I do that? Like, and it's basically just, like, here's where you go. Here's the things you select. Here's my recommend process of, like, speaking to a few people and whatever. And I've mentioned boundaries quite a few times here. The other really nice thing with therapists is you can do stuff, like, almost, like, interview a few and get a feel of, like, who do you gel the most with? And, like, therapists are generally, like, you know, boss-level people when it comes to, like, personal boundaries. So, like, don't worry about asking the therapist for something that you're, like, you know, or maybe they won't be okay with doing this or maybe this is kind of taking advantage of them, whatever. Because my experience is, like, in general, like, most therapists are the people who will not let you take advantage of them. Like, they're exceptionally good at not doing stuff like that. So, basically, like, you know, it's something I'd very heavily recommend at least investigating. If it's something you can do and afford and you have the resources to kind of find a therapist and get help and whatever. And the bar for kind of how, like, how many issues you need to have or whatever is dramatically lower than you would probably think. Yeah. You don't need, like, a big traumatic event to start therapy. Like, you can just get started today. And, you know, there's, well, also, I did, I also did write a blog post about finding a therapist. So, you can read both of ours. But, basically, they said the same thing started. And kind of, like, parroting back the questions you were saying at the start about, you know, being a good parent. Like, if you ask yourself if you need to go to therapy, you should probably go to therapy. And there was one more thing I wanted to chat for a second about. But it went away from my mind. And I can feel the muscles in my face. I'm not used to smile and be positive and happy for this long, usually. So, I can feel them, like, why are these muscles all tense? You're not supposed to be smiling. So, I think this is probably, like, around a good time where we can start to close this conversation. And to close it off, kind of, I usually ask everyone the same question. So, Mike, if there was, like, one key learning that you would, like, you know, a person listening to our conversation, maybe an open source maintainer, maybe just someone that uses open source, like, what's the one key learning they should take from you and, like, apply to their life? I think, for me, the key learning would be boundaries are really important and valuable. But, and I maybe didn't say this as directly before now, boundaries are also a thing that you have to be willing to enforce yourself. It's not enough to just tell other people your boundaries and then throw up your hands and be like, oh, they stepped all over my boundaries. No, it's your job to figure out not just what your boundaries are, but how you will respond if others do not respect those boundaries. And, I guess, the final piece is a really good person to figure out. If you can't figure out what your boundaries are or should be, and you can't figure out how to enforce those boundaries in an appropriate fashion, then a therapist is a really good person to do that with. And, I guess, as a flip side, because it's not really being mentioned, stuff like Reddit is, like, you know, there's all these places on Reddit where you can ask for advice. Do not use Reddit to help inform your boundaries. Because, generally, if you ask Reddit, like, oh, like, you know, this person I'm best friends with and have been for 20 years, him and I had a minor falling out, Reddit will tell you to, like, excommunicate that person and never speak to them ever again. So, like, yeah. Go, don't see a Reddit person. Go see a real therapist. And, that will probably be something that is helpful for you. Not everyone can afford a therapist, but if you're someone working in tech on a kind of tech worker salary, I'm not saying that, like, you necessarily have the money, but I think you probably, if you shuffle things around enough and you feel like it would be beneficial, you can probably find a way of affording it. And, it's probably something that you will find will be well worth the money and very justifiable for you. Awesome. Perfect. And, to kind of close it off, and also because it came back to me, like, I think that if there's one fear rouged with all the things that Mike said and I said is that you're really always the same person. You cannot, like, the boundaries doesn't mean that, oh, when I'm in work mode, I'm a work person. And, when I'm in my personal life, I'm in my personal life. The things between the two worlds will actually influence each other. So, as we were saying earlier, you know, the email at 11 p.m., like, that's your personal life. But, if you get that work email, it will ruin your personal life evening, right? So, that's why boundaries are important. And, how you enforce them are important. Because, you really need to remember that you're just one person dealing with all these things all the time. So, yeah, I think this is a great point to finish up. Mike, thank you so much again. This has been so great. I'm so grateful that you decided to do this with me. Thanks for inviting me, Lorenzo. I've had a good time as well. And, that's it for this episode. One more shout out to Mike for showing up and sharing their experiences. Since you are here, it would mean a lot to me if you could help this project out. Leave a review or share it on socials. If you want to check out the video, head over to YouTube, to subscribe. You can find me on all socials at Kelset. And, the project is at TheBuyMind Everywhere. More details are in the description. And, if you want to reach out, if you have any feedback or nominations for guests, use those channels. I hope you have a great rest of your week and please remember to take care of yourself.

hello and welcome to the live stream homebrew is turning 15 happy birthday homebrew my name is john britton i'm the co-founder and ceo of forkbrew and today i'm joined by two outstanding guests uh max howell welcome to the show hey thanks for having us let's see if i can do this there we go so uh hello uh let me give it a short introduction so uh mike is the uh project leader of homebrew my co-founder and cpo at workbrew and max is the original creator of homebrew um welcome and maybe you could each give a little introduction about yourself uh max why don't you go first uh thanks john and thanks for having me on uh good to see you again mike nice tank top yeah so uh i'm max how i've uh been in open source for more than 20 years i stopped counting at some point i got involved in open source because uh i thought i wanted to be a scientist which turned out to be incorrect as everybody else told me in my life chemistry is super boring i i thought i enjoyed it but just turned out i like the academic side of things didn't like actually working in it so one day in a depressed funk i went home and installed linux on my home computer and discovered the open source communities of the world this was like 2003 2004 it's about then i met mike actually we were both working on kde at the time uh which is this desktop environment for linux which i think still exists i don't know i haven't used it in a while but uh i'm just got me a job in the industry lost fem in london that's where i created homebrew um back in 2009 ish so yeah 15 15 years about 11 hours ago almost 11 hours ago apparently my commit was four minutes past midnight yeah well mike was saying the other day how when we uh started working on homebrew like debian was 15 years old and uh that felt ancient and here we are 15 years so yeah thanks for having me on looking forward to this uh this whole chat yeah thanks max yeah mike why don't you go ahead and introduce yourself and kind of your relation to homebrew yeah of course um yeah i feel honored to lead max not just for his contributions to homebrew but his contributions to excellent voices whenever i i forget because we normally talk of our text message nowadays whenever i hear max on a podcast or whatever i just think he is most delightfully deep voice in the world so i'll do my best to have a suitable timber uh yeah so i'm mike uh i've worked on open source not as long as max but probably you know like sub 20 slightly over 15 years um i got into software i guess the more traditional route just going and doing a cs degree and got uh fell into linux distros and all that nonsense when i was at university and ended up with one commit in the licks kernel which is always a nice kind of little humble brag when people accuse me of being one of the mac people who doesn't know anything about linux um so yeah i guess i uh also ended up in london at the same sort of time as max i worked for a startup called mendeley uh down there at the time and i was kind of trying to wrestle with mac ports to make it do what i wanted to and not install so many dependencies and stuff and then max was a friend of a friend of mine i think we showed fred emmett maybe in common max um and he told me about this guy max who was doing this thing called homebrew and then i went and looked at it and i was like oh it's written in this weird ruby thing which i hadn't really had any experience over the time um and yeah i basically just ended up getting involved like bit by bit like later on i guess the same year that humbrew got created i think max created it in may and then i think i started getting involved in like september or something like that and was like a maintainer before the end of the year um and yeah and i guess i've never managed to give up since so still working on it to this day excellent yeah so you both mentioned linux i have a question what was your first linux distribution ah susa susa was mine i'm not sure what the first was for me it was maybe maybe fedora technically in terms of like the first i ever installed but the one that held the the warmest part in my heart in that era was gentoo uh just for like everything being built from source and i had this old pentium 233 basically my parents old machine that they were going to like throw out which by what year was it like 2004 or 5 was pretty long in the tooth and i remember like getting an ubuntu install like sorry i gentoo install where i wanted the base system to work like the machine had to compile continuously for about two days to like get the machine set up and it was such a glorious waste of my time but i felt like i sort of learned some stuff which ended up useful in the homebrew days through doing that yeah emerge was my first my first package manager from gen so yeah that was i remember those days um yeah so maybe just for uh just for clarity and and completeness what is homebrew like i i don't know if you have the same definition of homebrew for both of you but like what is it why are we here and why are we celebrating 15 years of its existence yeah well always my definition it's probably not accurate anymore but you know um i'd say like it's the base of an awful lot of modern software nowadays is is the truth of it i don't think either me or mike imagined that it would become so you know enormous when uh when uh we were working on it back in 2010 or so but uh you know it's just a package manager i uh i was very fond of package managers at the time and switched to mac in a fit of rage one one day because uh i upgraded my linux kernel and uh my wi-fi stopped working and i was stuck at home by myself mirror before smartphones so i didn't have the internet to uh help me fix it so i switched to mac and then while i was there i discovered that uh the package managers weren't quite as good on mac as they were on linux i was used to like trying out all the different linux distributions and things so yeah i'm homebrew as a package manager but i think we took a lot of new ideas and ran with them and that's part of the reason that it became so prevalent and uh it it it was the right toward the right time in many ways so yeah it's the base of many people's stacks nowadays uh and makes it possible to get development done what do you think mike yeah i mean the when i describe homebrew to non-technical people i guess i go for like it's i basically try and get them to be like do you know what an app store is and they're like yes and then if i can get them to be like do you know what open source software is yes do you know what a terminal is yes well it's an app store for open source software in your terminal right and that's maybe slightly reductive but like that feels like that's what it has become in essence for pretty much everyone on mac like if they're installing open source on their mac they're installing either the open source itself or the thing required to install the open source they want if it's like npm whatever pro will be using homebrew together and yeah i i think you're right about like the the time and the moment like i to me that the two things that felt linked in some ways were because you know homebrew was one of the first big projects to kind of come out of github and be very heavily community run and have huge numbers of community contributions i remember it was like in the first few years that github would publish those reports homer was regularly in the like the top charts for like most forked most contributed all this type of stuff and i think that's basically what helped get it going in the direction that it went right is that because it was github native before maybe any other big project ended up being that way uh i think that's yeah it's a big part of it yeah like i have a small list that i've assembled over the years of the reasons that i think homebrew was so successful but we can talk about that when when you like john yeah sure well i think the next kind of area is just thinking about like the history and how how homebrew came to be um what was i mean max this is probably mostly for you uh as you were the the creator what was the the inspiration you know behind it and you also kind of mentioned like that it's gone a really long way and it's it's become much more than you ever expected i'm curious to know as somebody who's had some small open source projects what did you expect like you know obviously like i think it's pretty easy to say that this went way past what you expected but like you had to be motivated in some way what were you hoping would happen oh i was hoping this would happen such amazing forethought yeah it's weird i had this feeling while i was building it that it was going to be big and like that feeling didn't i didn't lose it and i didn't lose the confidence in it and so i put my all into it and then it happened uh which was really bad for me i was 26 so uh i spent the next like 10 years of my career thinking that everything i touched would turn to gold and uh it doesn't it doesn't usually work that way i i definitely recommend not having a huge success when you're young uh but um yeah i got over that in the end but yeah like i created it because i was working at lost fan at the time and i was the lead developer of our apps team and we had six apps windows mac linux android o phone and the blackberry app which uh was the worst and hardest to build but the unifying uh machine to build all these things on was mac because partly because of apple's lock in for their platforms but partly because you know it's unix underneath so you could run all the other different sdks and systems and you could emulate windows uh so uh we were using a lot of open source tooling on mac and like the package manager kept like coming up as a problem like mac ports was like gentle you had to compile everything from source like mike was saying uh it insisted on building everything from like uh glibc upwards even though the mac came with a bunch of uh open source libraries that are usually that base that you don't have to build so i used to complain about how the package management solutions were holding us back at the pub after work like on a relatively frequent basis to the point that one of my co-workers got fed up with me and told me to just shut up and do something about it and uh i went home and i was like well it would be kind of fun to work on something like that so i started you know the that was the beginning i i called on like uh all the ideas i've had over the years working on different open source projects i worked on this music player called america on linux for a long time and uh the issues that everyone was always having were related to auto tools and getting the dependencies in place and building from source and so i wanted to build something that i felt could be a solution to those kinds of problems for people trying to build out open source work on open source work in open source and do development in general uh so i wanted it to be a programmable package manager so like all the formulas i uh called them uh were in ruby so that you know we're programmers i figured we wanted a programming language in order to like build these complex and different pieces of software and i picked ruby because it was very fashionable at the time and it came with the mac ruby on rails was really getting uh a lot of attention at the time uh it's one of the reasons i was successful for sure picking ruby because the ruby community loved that it was written in ruby and that you could use ruby in order to uh work on homebrew um and then yeah like picking github was a big part of the success as well for sure like github was relatively new right i think github had come out a couple of years before that and we've been using github at last fm and i saw that uh it was a great place like i think the alternatives for source forward right we we've been struggling with these terrible uh tools for doing open source work online for a long time so yeah i picked all these things and put it out there i managed to get some attention for it with uh replying to some people on twitter you know twitter used to be a better place dare i say it where it was an awful lot of tech people so you could go on there and just talk to tech people and see what they were doing and talk about like new tools and things and so i got the attention of simon willison probably you've heard of him with uh tweet about homebrew and then i got the attention of josh peak who was working at 37 signals at the time ruby on rails uh was built by them and he tweeted out about how he was going to install homebrew on his new mac that he was getting that had osx leopard and like that was the moment where it really started to take off before that you know i was telling people about it they were like oh so i'll tell call me call me when like anyone else is using it a typical open source start you know like when you make some open source you do have to do a bunch of marketing yourself in order to uh get some attention for it so yeah i was really motivated i really wanted it to succeed and yeah like those first few years it was crazy uh we were dealing with a ton of uh issues pull requests well pull requests when they turned up you know when we when homebrew initially was created the pull request was not a thing nobody had figured out how to uh handle contributions on github at this point they had forks and you could browse the four graphs so that's what we used to do right like the uh the first person that i merged some of their contributions in that he didn't message me to tell me that he was building these formula i just found his contributions in the ford graph and then merged them in and then message him saying hey i merged your stuff in i hope that's okay because that was how we had to do it at the time you know i'm waffling here and mike how about you where did you uh how did you come across homebrew and kind of what got you involved and why did you why did you decide to become a contributor yeah so i mean i guess i i used to hear a lot of people saying this back in the day not as many people say it now is the idea with open source of like scratching your own itch right and we've just heard max explain how homebrew came to be created from his scratching his own itch right and it was the same with my contributions really where i heard about homebrew and i thought it was cool when i started using it but i didn't have this idea of like oh i'm gonna get involved here or i'm still gonna be doing this in 15 years or any of that sort of nonsense it was just like oh like it's a package manager it's missing some stuff that i want so i'm gonna add some stuff right um and every time i came across something that i needed i would go and submit a contribution and then eventually the package manager itself didn't do some of the stuff that i wanted it to so i submitted kind of changes to that and and whatever and i think it was i don't know again as i mentioned before is that this all being on github there was something about it being on github that just felt so much more accessible i think in the early days um the there was github and i guess before pull request there was like an irc channel like i vaguely remember like you know instead of pull requests i would like dm max on irc and be like here's a commit and then max would like cherry pick that commit in and push it and tell me what it was pushed and stuff but yeah it just it felt like the barrier to entry was very low um but i guess i guess the other thing that kind of captured my interest with homebrew which again i thought was very different and very creative from the outset was just the way that errors were handled you know most software most of the time particularly relatively immature software generally operates from the assumption that nothing will ever go wrong and if it ever does go wrong then like just throw your hands up in the air and just be like oh well you know like some programmer come along and fix this right whereas i remember right from the outset homebrew was really impressively well designed to give good error messages and even to stuff like the i've seen a bunch of other tools copy this now but like the kind of brew doctor command which again was relatively early on but this idea of being like hey like we have some ideas of stuff that could be wrong right like run this command and these are not necessarily all problems that you need to fix but like if you are having problems chances are it's going to be one of these you know um and yeah i just felt like that approach just as what it it gelled with my brain and it sucked me in and it just felt so much more accessible and maybe even scalable in hindsight than the models that a lot of other linux distros were having and other package managers on mac that felt very much more like the linux distro model we're having yeah like it reminds me it's just that from the start i knew i didn't want to do it all by myself and i had faith in the users that if you give them the right messaging and docs and tooling that they can fix their own problems and i really wanted to encourage that so you had the brew dog to come on the good error messages um even the way like you cloned homebrew initially and that's where it built and so you had a clone and you also could immediately start contributing there wasn't any like fancy build steps or anything that was required you just opened up your editor and make changes and then push them back to github those things i just really wanted everybody to feel like they could participate and you know you've seen some projects do more of that since homebrew i think sort of introduced the idea of doing it but still i think in general like you go to a readme for most open source projects and there's no section saying hey how do you get started you know it tells you how to install it but it doesn't say how you can get involved in the project i still think it's very important it's rare so 15 years is a really long time um homebrew has been around for for a very very long time i was hoping we could do a little bit of a you know a short timeline of the major milestones in the history of homebrew so um starting from and i'll share my screen for this um let's see if i can do this starting from here uh max this is probably for you um this is the first commit uh to homebrew let me see if i can make it a little bit bigger here we go so the first commit of homebrew um maybe you want to tell us about your state of mind when you were doing this and any other kind of interesting uh anything you'd like to share i'll leave it up to you yeah well um i still do this i don't start a project with code i start with the readme and this was something i learned while working on kde i went to a kde conference and one of the people that worked on cute which was the c plus plus toolkit that kde used uh still exists i believe yeah i did a presentation where they talked about how they didn't start with code they started by writing out what the api would be doing example code showing how they wanted the final api to be and then they build the code around that so i started doing similar things but yeah here i was starting with the remi so i spent more time on the remi initially before i started building any code out and i was like how do i want this to be how do i how do i want it to feel and so yeah this this was what i imagined it would be before i started writing any of the code and uh you know you can see a bunch of the stuff in there that i wanted like the naming theme which homebrew is uh famous for which i did because i knew that the world of package managers was so full of uh things that were difficult to describe because the terminology was terrible of what does the word package even mean i don't think anyone can really tell you the answer to that and so i wanted there to be a theme that allowed people to see uh analogies and metaphors in all of the uh the system and the code uh so that it would bootstrap their ability to understand how to contribute or how to use it so yeah you can see like the slash brewery there which you can no longer create that folder on macros thanks to apple but at the time i think that was where i thought it would go eventually we changed that to use a local right because it made so many things work better it was an important decision in the just works aspect of homebrew which was important to the the way i designed it the way i thought about it yeah like uh this is this is what i wrote with the typos and bad uh grammar throughout and this is where it all this is where it all started um just on the theme of uh of homebrew i think that there's something like in that era of ruby time i feel like every ruby project had some kind of an interesting theme as well did you see that elsewhere was was it mostly like a or is that a ruby thing that am i misremembering that or is that how it was no you're probably right i i probably don't remember it but i'm sure that i was inspired to do the naming theme by other great projects and they just really suited what i wanted to do i think my reasons for doing it was slightly different i think a lot of projects at the time that had themes we're just doing it for the funsies while i was trying to make it useful and then the vast majority of open source at the time was just like terrible naming and terrible if any theming um you know it would be called what it did you know uh decrypt library dot lib so now you know we've seen kind of where it began um in the past 15 years you know if we had to highlight maybe three or four big inflection points in the project what would you say you know maybe um were the biggest ones or the most the most significant uh to share yeah it's a difficult one i could i could suggest a few i think taps were the first that was one of your big creations max that was probably one of your latter like big creations on the project where you just came out of nowhere and again similarly like had this design and you're just like here's taps here's what it looks like here's how it plugs together and i think that's been like before so taps are essentially like third party repositories for homebrew if anyone who doesn't know and before we had taps you could only install stuff in homebrew that had been added to the main homebrew repository essentially and i mean there were other ways you could sort of hack around and stuff but i think taps are what blew homebrew from turning from like just a project to being like an ecosystem because then you can have well anyone can now create their packages in any way if you're a company you can have internal taps if you're um you know if you're an open source project you can have your own tap if you're and even within homebrew itself like homebrew now has a bunch of different taps and that's like homebrew cask that got merged into homebrew itself started off as a tap all the linux stuff started off as a tap like it's just i think it just enabled kind of the ecosystem to sort of flourish a bit more in that respect um i guess another one i might suggest after that would be like my uh true love and joy is like bottles the binary packages that uh because i think i implemented the first version of that and we're still using more or less a pretty similar model today um and yeah and i guess over time we kind of moved from being almost from exclusively built from source to predominantly built from source to mainly built from uh binary packages as it is kind of today yeah can you say a little bit more about what bottles are and how they work yeah i mean basically a bottle is just essentially we build everything from source the way we used to uh on user's machine but now we do it on github actions runners uh we basically make a bottle which is a complicated uh format of just a tarball of the thing that we installed again i feel like i learned a lot i learned a lot from max in this era and in general that like often there's these really overtly uh complex formats that happen on this stuff and often it's like well if you've got a directory of stuff and you want to put the directory of stuff somewhere else can we just make a tarball of that directory and extract it somewhere else is that good enough and the answer from the last 10 plus years or whatever seems to be yes right and instead we could have made this complicated custom binary format and made everything three percent more efficient or whatever but then the whole system becomes harder to explain and understand and all the tooling you use is different yeah and whatever and i i don't i feel like that's for me like a big part of homebrew as well has been trying to avoid that unnecessary complexity and you know i think that's something i took from your initial design max and from us working together over the years and has inspired me in homebrew and outside of homebrew as well um yeah well it's good to hear because yeah like before that i i'd already recognized how complexity can destroy productivity and the ability to iterate and it was uh it was a key thing you know one of the things with the initial remi that we were just looking at was i wanted you to be able to use the unix tools you already knew like rm and ls to uh query the package manager i didn't want it to need another tool apart from when it was absolutely necessary and those sort of designs filtered through throughout i think in open source in general there's often a a desire to over complex things um partly because it makes us feel good hey i designed and built this really complex thing but it can hinder like i think most of the most successful open source projects are simple enough that people get the gist really quickly that inspires them to want to continue diving in and then get involved and open source lives and dies by a community like it's one of the key aspects that enables it to exist and for it to thrive so yeah and bottles yeah it was super super important it was interesting at the time right because when i built homebrew initially i got a bunch of like negative feedback from people saying oh god you're building from source i don't want to build from source just uh you should make binary packages i'm like well yeah sure but who's who's going to pay for that because at the time there wasn't stuff like github giving you free bandwidth and storage and compute in order to do these things as an open source maintainer you had to figure out who was going to pay for it and i wasn't going to pay for it yeah i mean the first version of our binary packages like the the evolution essentially went from being built on my machine to being built on a vm on my machine then we did a kickstarter and then they were built on some macs then built in a vm on those macs and then the macs ended up being cloud hosted and you know like it's yeah it's i i think it's easy to look back at those days and be like why didn't they build a binary package manager from the outset and forget that like what you mentioned already max that pull request didn't even exist like travis ci and all those systems github actions none of these existed you know even aws like you know it existed but you couldn't use it for building anything on macs uh so yeah like i mean essentially you were like right well you somehow have to have build a bunch of hardware yourself and build all this all the integrations and decide how that goes with the workflow and and all this type of stuff and and even then like i think the homebrew workflow the contribution workflow meant and means that like building binary packages is trickier than if you're like a debian and you do a release of software every so often you can just be like okay i maintainer has changed the thing we'll kick off a job the binary package is done when it's done you know like it's much more complex when you have a user who submits a thing and you want it as soon as the user merges the thing you want the binary packages to be ready for the user and all this type of stuff so yeah it's it's interesting it's been a an interesting transition but a worthwhile one i think something that i think is also kind of a milestone and you may you mentioned it a little bit mike uh is casks so as a you know occasional contributor and a heavy user of homebrew i use casks all the time and i really love the feature uh you mentioned that it was previously a tap and then it got merged in i don't actually know the history or the backstory of how that happened but i think it was a pretty important thing in the history of homebrew maybe you could share a little bit about how that came to be yeah so i'm not entirely sure i think it was i can't remember the name of the guy i think it was fins was his uh github handle but yeah someone set up this homebrew tap with enormous amounts of custom ruby code and it was probably the the homebrew tap that had the most additional stuff in it with this they came up with like a new dsl and this new concept called casks um for installing like binary packages you know google chrome one password whatever it may be um and yeah and then after this project been going on for a while like we'd kind of built closer and closer ties with that project and then it was someone i think it was a a russian google summer code student called anastasia um and she basically was involved with like merging the two repos and merging essentially all of the like the actual like underlying like code logic for casks into into homebrew and then yeah like it everything was pretty separate to begin with but then over time like casks and formula have been more and more kind of like together and then now it's i think the nice thing that casks do is that it's you know it means fewer people use them by quite a long way but it means if you want to just use homebrew to install pretty much everything on your computer you can do that now which is between the mac app store and casks and uh like humber itself and then there's the thing brew bundle which lets you kind of put them all into a brew file and kind of have a somewhat decorative format and that supports installing things from the mac app store as well so yeah so you can basically like i have essentially everything my machine is being installed through homebrew in in some shape or form and it's yeah it again has it broadened the ecosystem and wasn't was probably the biggest idea that came from outside of the core team and got merged back in and other than we can talk about this later john uh like the linux sport as well which had a similar kind of evolution yeah i have that on the on the agenda so any other big milestones that you guys wanted to talk about i just want to talk about casks for a bit because uh i don't like casks right uh i never like casks and uh it's very popular thing if you talk to anyone about homebrew they're like oh yeah the first thing i do is cask install everything on my computer and then like all the other tools as well i don't like casks uh but you know it was important that it wasn't all about what i wanted and i always made sure that was the case and so we built brew like all the time and mike was extremely instrumental in some of these pieces right i remember when you merged the sub command support that wasn't something that i was thinking of but you added that so that people could do brew dash whatever put it in the path and then that would be something you could execute via brew and uh it was just always important that we allowed the community to experiment and see where they wanted to take through and then if the community liked those things then yeah we would support them or merge them in more fully so yeah it's important as an aspect of how to manage an open source project but you allow that kind of thing i don't know exactly why i don't like them but yeah just a matter of preference i think that's fair everybody deserves their their own preference um you reminded me there with the external command stuff max it was also nice because we as you said it let the community go off and do stuff um and there were a few times that people proposed kind of fairly massive changes to homebrew which would require a lot of work and we were able to say hey we'll go off and uh go off and build this in a tap and then if that gets some sort of you know adoption then we might consider emerging in later and uh a little secret for any of the open source maintainers who might be watching like a lot of the time in my head i was just thinking like there's no way you're actually going to do that but so one of the the early successes of that i think before even casks which someone said like hey like we should have descriptions for all the formula like a nice little textual description of what it is um and it was like okay well that's going to require someone to go through and add lines to 5 000 packages describing them all i was like if you go off and do that and you get a description for all the formula then we'll consider merging that back in thinking that person is not going to do it no one's ever going to do this this is fine i've essentially told them to go away in a nicer way and then you know this person reappeared in like you know four or six months or something and was like cool yeah i'm done i'm done now i've we've got descriptions for all of them and then we merged it back in and then with with a lot of these changes it's then once you got that thing it's much easier to say hey every new formula we add has to have a description now and it felt like a big leveling up for the project but you know it felt like i guess as max said earlier like you have to be um you know i think it's good having a vision of what you like and what you don't and and even like max not liking costs i think like that's a good example of like you know we we all have our own preferences and our design decisions and whatever and we can't expect them to be the same but at the same time max was not trying to ensure that casks could not be created by someone else and the same with the description stuff i thought this was not going to happen but i wanted to like leave the door open that like well if someone goes and essentially does all the work for free then yeah we can we can include descriptions why not yeah i deliberately didn't put descriptions in the initial formula and i remember like fighting people to keep them out so it's all objective everyone like i have a different description we'll end up with edit wars and this information is easy to google etc but like uh yeah it's very useful metadata for sure um with like package x which uh i recently built right which is an attempt at something new in the package management space didn't add descriptions as well and i was like oh we use ai to generate descriptions um which mostly worked but then for some packages it was just abysmal and we actually got a lot of backlash to that so uh it's um a difficult one sometimes figuring out what you want to support because when you add something like that yeah then that means that every package from then on needs a description so you're increasing the burden but that was very minor thing should have been in there from the start probably so i kind of wanted to shift uh gears a little bit and talk about apple um so it's pretty intertwined like homebrew is pretty uh there is a linux support and some other stuff but um you know max you mentioned when you came over to the apple ecosystem that there was no good package manager you weren't very satisfied and i think that homebrew actually has really really improved the experience for developers on apple devices and apple changes relatively quickly uh you know the operating systems and whatnot like they're they're always advancing their underlying architecture um so i wanted to talk about maybe two or three things there one is the uh the move to a unix like posix based operating system right uh with mac os 10. uh the other is the constant march of progress with apple operating systems deprecating things changing the rules on the platform and then also their architecture going from ppc to intel now apple silicon those have all been major changes relevant to homebrew and i was wondering if you know either you had commentary about that or experiences from you know using those things and going through them yourselves yeah i'll quickly chime in then pass to mike because i think he has much more experience in uh the various important changes especially the uh apple silicon one more recently but um i think at this point honestly apple cannot change some things about mac os because of homebrew they they would risk um enormous problems for the global developer ecosystem if they did but yeah earlier days it was more problematic but i've been very good about binary compatibility uh in their libraries we only had a few issues um every time they do an upgrade in general but yeah mike has uh more experience yeah i mean i guess the early one is you initially released homebrew on leopards and then it was the snow leopards i think leopard had some x64 support right and that but it was like not really and then snow leopard went a bit more all in on x86 64. like so that transition was like i think the first and a relatively easy one um shout out to misty de mayo a former homebrew maintainer plc member uh who had a thing called tiger brew which like back ported homebrew to run on like pvc chips i i believe is still kind of working on those ancient apple devices today um and then yeah i guess you mentioned john more recently the kind of apple silicon transition i i mean i think like you know it's no secret that every new version of mac os tends to break some stuff in homebrew or either mac os or xcode or whatever um but like you know i i think compared to the earlier days we definitely have a private but decent communication channel with apple when stuff really needs to be kind of addressed and particularly the apple silicon transition was made much easier by apple like proactively essentially as soon as the keynote was done where they announced apple silicon like before there was any hardware in anyone's hands they reached out to us proactively and we're saying like hey how can we get the right apple silicon in the hands of the right people in the right place and whatever um and yeah and i think it's it's funny because i think there's definitely a bunch of two-way learning that's gone on i think homebrew's learned like how to identify apple and how to work with them and figure out like what that looks like but i i think apple's also like been getting better with open source and learning that like you know sending hardware to homebrew people may involve sending it to like a this is not even a a uh fictional example but like some distant scottish island um and like you can sometimes hear the confusion the apple people's voices that it's like you're not just all in this office somewhere in the world you're like scattered all around like what's the legal entity we should attach this to oh there isn't one oh uh this is going to be tricky uh but you know in the end i think we've got something that i think work brutes or homebrew has been tremendously beneficial to apple over the years and i think you know obviously if we didn't love our apple devices like homebrew probably wouldn't exist in the first place because we would have just stayed on linux doing linuxy things with linux package managers which were good enough that homebrew would probably have not been created yeah and speaking of linux and also other platforms i know that homebrew has support for linux there's linux brew right and there's also uh what is it uh the windows uh wsl some people can use homebrew there so what's the project's position now on other operating systems is it like officially supported by the project how how do you approach that yeah so linux is officially supported with homebrew now and it's kind of fully integrated in terms of the package manager itself and all the formula and homebrew core are run on you know this specific formula that might be mac only or linux only or whatever but essentially everything we are aiming to have feature parity version parity and everything like that and we have maintainers who run exclusively on linux and maintainers who run exclusively on uh mac but mac is still our predominant uh ecosystem if it feels like an apple level uh perhaps slightly silly discussion but um there's been a lot of back and forth on pull requests and internally about like well how do we communicate that because homebrew is still used way more on mac os than on linux um so on the home page we have you know homebrew the missing package manager for mac os or linux and the or linux is parenthesized to sort of indicate that we do support linux but it's like you know not quite as popular or you can look at the numbers i think linux usage is about maybe 10 or something of mac os usage based on analytics and also like maybe interesting maybe boring uh like mac os is like predominantly people running on their actual match and like i think it's like 10 20 or something it is running on like ci environments whereas linux is like 50 actual users 50 ci so i think that's again where the linux support is kind of kind of useful like even for us in homebrew ourselves like having the ability to like bump mac os packages and like run style checks and all this type of stuff on linux runners because i guess despite our conversation earlier where you know back in the day when there's no mac os versions mac os runners available even nowadays like the mac os compute per minute price is dramatically higher on any platform than the linux uh compute price so essentially if you can farm a job out to a linux system instead of a mac system it makes life much easier but again like we said earlier like the linux stuff started with a fork of homebrew called linux brew over the package manager itself and then it had its own version of homebrew core where all the formula are called linux brew core and over time the package manager in uh the main package manager repo homebrew we call it was kind of made to be more and more linux compatible and the eventually like the homebrew core became linux compatible as well and a little shout out to the past max mentioned he was working when we were in london we were both working on qt applications actually and yeah and i felt like from my cross-platform qt days i learned a lot about how to make the uh the package manager part of homebrew not just a mess of like if mac if linux if mac if linux like all over the place which is what kind of naive cross-platform porting tends to look like and be very painful to deal with max so you you had mentioned that uh you know you don't recommend having a big success early in your career uh when you're when you're young i'd love to hear from you um kind of how homebrew has impacted you professionally and what that's done to your kind of trajectory as an engineer and as i know you're an entrepreneur like what are you up to now where are they like where are they now and like how did homebrew kind of put you in that path yeah well uh homebrew definitely impacted everything about my life very much that's for sure hopefully for the better yeah well definitely like um i can't talk fondly enough about how open source has given me so many opportunities that i wouldn't have otherwise had but uh you know let's start with a personal level like suddenly i became very arrogant for a while about it because uh you know it was the biggest project on github and it was on my username slash mxcl slash homebrew um and uh you know i'd meet people and they i remember one conversation in like 2014-ish maybe 2013 and i was sitting at a bar with some other devs and this guy says oh have you heard of homebrew this package manager it's really cool and i just started laughing and then everyone else around me was like what did he ask and i said oh he asked me if i'd heard of homebrew and they were like and they talked about how i was the creator i've always been somewhat humble in that respect i don't usually bring it up because i find that you get a bit of hero worship what you probably find similarly mike and uh it changes how people act with you so i've had this interesting sort of life where um among like geeks i'm famous but among everyone else fortunately i am not i don't i don't have to be uh a celebrity in uh in most circles and uh you know it's definitely got me career opportunities and you know obviously famously didn't get into google but not getting into google got me an awful lot of other opportunities and yeah i think the worst thing was definitely that after homebrew nothing i could work on seemed successful unless it had you know a frac some some fraction at least of homebrew's success so i abandoned a lot of open source projects i probably shouldn't have because homebrew was successful very quickly and i turned down a lot of interesting startups that i could have worked on because they just didn't seem cool enough um but yeah still always done open source i've got a couple of other big projects on my uh github and uh missed out on some interesting airdrops because mike decided to deprecate the original homebrew repo at some point you owe me uh some token for that like yeah um it was a couple of years ago years ago that i founded t protocol which is what i'm doing now and uh it was based on my career in in work and open source and like the the fact that nothing but open source ever really felt worth doing to me and over the last 15 years uh open source has really gone from being something that was kind of derided you know like it you could see how open source was becoming successful 15 years ago when homebrew was created but it's still the case that if you wanted a real job then no one was using open source and they thought you were a hipster or an idiot for wanting to use it so now we're like the idea of building something without an open source base is preposterous and um yeah in those 15 years i think it all kind of took us by surprise how much open source became the bedrock of all modern software development so a couple years ago i was looking for funding solutions for open source once again and i didn't find anything that seemed like it was going to work for me i'd already tried a few things so vanity protocol to try and fix it by changing that narrative it's a crypto project which obviously a lot of people are skeptical of but we're doing very well so the idea is we're trying to make open source sustainable by giving free crypto token rewards to open source developers and we have almost 1.5 million people who've signed up for our testnet so far at 15 000 open source projects some of them uh very impactful ones so yeah we're launching it properly later this year and the idea is to make it so you know like my homebrew story was that i quit my job to work on homebrew full-time and if i hadn't done that i don't think it would exist quite honestly and it's not really something we can expect the people who are building the foundation of the internet to do on a regular basis we can't rely on the software industry and all the software that we build that's so important nowadays to exist when we were expecting people to somehow try and make these sacrifices i couldn't do that now at 26 you know i was single didn't have kids it was fine but so yeah we're trying to change that t protocol makes it so that you don't think of open source as a charity which is how everyone else goes about it you're begging for donations changing into like a value ecosystem where you're you're participating in the value of open source excellent yeah i mean i can only imagine that homebrew has had a major a major impact on your entire life and i can relate to what you were saying about you know when you have a big success it's very difficult to try to do another project and have it be successful like i've i've kind of developed this muscle of don't try to do the same thing twice um where if something happens to be a home run it's a combination of good good work you know forethought but also a healthy dose of luck and you can't expect the luck to be there every time um but yeah i definitely i definitely can relate to some of the things that you were saying right like um yeah mike how about you how has homebrew impacted your career and uh you know where are you now what are you up to these days yeah i mean similarly to max like i've had a bunch of doors that got opened probably only due to homebrew right so i started working on homebrew and ruby and you know i dabbled very briefly one university course back in the day but um you know homebrew is what kind of got me doing ruby and then i've definitely found like there was a few as homebrew became more successful uh when i changed jobs and i had like homebrew maintainer on my resume like that seemed to be the only thing that people would care about and that got me through the door and got me kind of speaking to people and i i applied for github three times before i got a job there but you know i went from essentially being a nobody who uh like just a random member of the tech industry to kind of being able to get a chat with one of the github founders back in whatever it was 2012 or 13 or um and yeah and i think that door was opened exclusively because of homebrew and i think yeah i spent 10 years at github i left there last year and i think i learned a lot about making homebrew better from github and a lot about making github better from homebrew and there's probably some stuff i'm not going to go into right now that hope that github does differently as a company uh and as a software project because of homebrew right and if homebrew didn't do it first then github probably wouldn't be doing it um but yeah nowadays i guess kind of like max i i've also almost like had a like thinking about what does this look like going forward and like what what do we do here and i co-founded workbrew with yourself john and our co-founder vanessa who's not on the call and we're basically doing i guess it's interesting how like max and i are both kind of riffed off the the homebrew idea in different directions but basically what we're doing is building uh commercial support for homebrew and what that looks like today is providing um better support for the stuff that homebrew doesn't really want to do that the volunteers are not interested in like making homebrew work really well with mdms in environments where users don't have administrators and tightly integrating with kind of security protocols cvd disclosures and stuff like that but moving forward we're basically making homebrew better for engineers using it as well and security professionals too and so yeah we're basically working on making homebrew better but also providing a kind of commercial layer on top of homebrew uh to make that better for the people who are using it i love what you guys are doing and i wish you all the success with it i think it makes a ton of sense honestly i remember in um i think it was 2014 i got a call from some uh san francisco vc who was like how can we make homebrew into something commercial because they they were looking at npm right which had just just done that and at the time i was like i just don't see how we can do it because i didn't have the right mindset and also because it was just such a big open source project i didn't understand how we could like say hey community um it was open source but now it's not uh it's kind of something else so what you're doing is the right way to go about it i wish i thought of it then might have been a very different world for me and all of us but uh you know building on top adding extra services on top i think it's only the last few years that commercial open source really people figured out how to do that and like i think there's a lot of good opportunities in that space well i mean the funny thing is john had been probably from a similar sort of era trying to convince me to that this was a good idea and i felt the same as you that like well i don't really see how we can do this but for me it was like two things kind of came along so one thing was the um i guess like homebrew actually having an established government structure governance structure and its own funding and a non-profit and a board and all this type of stuff like and that gave me the separation that i feel more comfortable with where it's like okay now it work brew even if we wanted to try and somehow take over the open source project we can't do that because it's its own thing and it has voting and everything like that right so that that feels a lot more comfortable to me um but then also on on our side i guess having seen over the years something i actually learned a couple of companies before homebrew is it was this company kda i used to work on again doing qt consulting um and i was really excited because they were the biggest kitty contributors in terms of a company that was out there um and i was like great i'm gonna get to work on all this cool exciting open source stuff and get paid to do it and then i learned pretty quickly like oh no no if you're getting paid to do the open source stuff you're getting paid to do the boring things right because all the fun stuff people will be happy for free in their spare time and it's and i think one of the projects was something like uh k office the kind of open office alternative and it was like working on a compliance suite of like okay here's the like essentially 2 000 ways in which k office doesn't render things the same as words just go through and like fix them all right and no one wanted to spend the readings and weekends doing that so we were paid to do that right and i feel like it's a similar model to what we're doing with workbrew essentially where there's a bunch of stuff that i've seen over the years like humber maintainers are like ah i don't really like this is only that you only use this in lockdown environments where security and compliance concerns are really important like that's not me that's not my personal laptop like why do i want to spend like a day working on this and so it doesn't get done and instead of saying no to people we can now say okay well like instead of having homebrew solve all these problems for you which only apply really to companies that kind of have these type of problems rather than individuals working at home then this workbook can solve them for you instead so yeah um so just to wrap up we have a couple a couple minutes left but i i really wanted to uh you know kind of see if there's any advice that you have for people who want to be open source you know open source developers like you um if you were to go back to when you first got involved with homebrew you know what advice would you give yourself at that time now that you've got basically 15 years behind you well i'll go first um so i always say that the most important thing is it's something you need like in in general when you're working with you know you've got to be working on something else and then as you're working on that other thing you're like oh this this thing doesn't exist or this tool isn't what i need it to be i need it to be able to do something else and so if you're going to start a new project like it's one of those things but if it's the latter you might find there's a tool that exists and you can start contributing to that like you know that's a lot of open source people got involved that way by finding that it had to be them who made that feature and uh if you have great uh core maintainers like mike who encourage you to go do that partly because he's lazy partly because he's made sure that over the years uh the ability for you to like bolt in your own functionality is easy then uh yeah it's going to be something you're going to be passionate about if you're just doing it because you think it's going to get you a good resume then you'll find after a few weeks you're not doing it yeah i'd echo what max said like we actually have that in one of our like comfort maintainer guidelines that like if you find yourself in a situation where you're no longer using homebrew day-to-day like you're doing your day job on linux and all your personal machines are on linux and you just don't use homework there or whatever it may be then we recommend people step down because at that point not only like is it not that interesting to you but also like at that point um you know you're probably not going to do the best decisions for the project because you don't care personally and yeah like i i don't know like i think it's for me thinking back 15 years like i don't know i've just i've learned a lot along the way that i don't know if i would have learned if someone told me because i'm super stubborn like that um but yeah i guess for me the biggest transition has been just having more boundaries and being better at like dealing with people being entitled or like i no longer have like homebrew slack or notifications or whatever on my personal phone and stuff like that so it's yeah i guess that has both helped kind of let other people pick up the slack and like share the load a bit more but it also just stops random open source people who are 99.9 of the time lovely and sometimes less than lovely uh from intruding on my personal life and my personal space and when i'm having time with my wife and kids and stuff like that yeah well yeah mike was always a lot better about that than i was you know he knew how to keep the rest of his life separate and i you know that's why i burned out while uh mike kept going for sure so yeah something i can learn i think we all can um well thank you both for for joining us um this has been awesome uh congratulations to both of you also 15 years since homebrew was created and i think um thank you to everybody in the community who uses homebrew who contributes to homebrew i think that all of the you know everybody who's got commits in there whether it's you know features or documentation or really anything to help out with the project you know you deserve to celebrate as well um thank you max uh thank you mike for joining uh have a great day everybody bye bye thanks

Thank you. ...is much more than the place where you can store code. But let's see it in action. Meet Mona, a developer who's just been assigned a new project. Mona uses GitHub projects to manage her tasks and track iterations of work. GitHub's customizable views, filters and layouts make it easy for teams to work their way. Mona quickly sets up an on-demand development environment using GitHub Codespaces, no more fighting with dependencies. She dives into coding with GitHub Copilot, making her code more readable and efficient. She then sets up automated testing with GitHub Actions, easily version-controlled like the rest of her code. Meanwhile, Mona's colleague had set up repository rules to enforce DevOps governance practices across their GitHub organization. Mona avoids leaking secrets by using GitHub Advanced Security Secret Scanning Push Protection, and also identifies potential security vulnerabilities using code scanning. In this short video, we've seen how GitHub can streamline your experience throughout the development lifecycle. that we've seen how GitHub is being able to do a lot of work, and we've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work, and we've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work, and we've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work. We've seen how GitHub is being able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work, and we've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. We've seen how GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. GitHub has been able to do a lot of work. And I guess thank you for a very nice introduction and a very humble one. It was a real pleasure and treat working with Andrea. If anyone watching this gets the chance to do so, I would thoroughly recommend it. She's a lovely person to work with and is very good at her job. And my face exploded. Thank you, Mike. I appreciate you. And I appreciate you taking the time of coming by. It's been a moment since you let GitHub. Not a year. No. Yeah, just over a year. Just over a year. Happy. Okay, wow. And of course, you went off to do your own thing, co-found your own company, which is super exciting. I do want us to touch on all the amazing work that you're doing with Workbrew. And for folks here who might be interested in a solution like that, it'd be great to, you know, maybe show them if you're up for it. But I also want to talk to you, take it way back. When we think about open source, taught leadership, and that's, I use that term loosely, because there's a lot more than taught leadership that you do. But there is so much incredible content that you put out to support other maintainers based, of course, on your own experiences from leading and maintaining this project that is so pivotal to all of us for so many years. But we have to take it way back. We're going to do a little bit digging here, because I don't think I've ever actually asked you this question. How did you come about being the maintainer and project leader for Homebrew? Like, how did that happen? Yeah, so I mean, I guess the, yeah, the maintaining came before the leading by quite a long way. So I guess in 2009, when Homebrew kind of originally got created, that was a guy called Max Howell, MXCL on GitHub. He was using kind of package managers on Mac and stuff like that. And he never found anything that kind of quite fit his needs. So he wants to make his own thing called Homebrew. And he had worked on it for a while. I'd heard about it and stuff like that. And then I'd be kind of like building something else, like not really my own package manager, but you know, like a sort of hacking a different package manager to work the way I wanted it to. And then I saw Homebrew and it was like, oh, this looks like this is kind of, this works how I want it to work. So I just submitted some pull requests. You know, this is, I think he created it maybe April, May 2009. You know, this is probably like August, September, 2009. Wow. Submit some pull requests of just like stuff I wanted to be in there for my own use. And then kind of more pull requests. And then, yeah, eventually I guess got asked to kind of join the project and review other people's stuff. And, you know, it went on from there. Although I guess I realized I just misspoke actually, because in, I believe in 2009 when I started GitHub didn't have pull requests yet. So the way things used to work is you would open an issue with a, I think it was like a link to your, a commit in your fork or like message Max on IRC with a commit to your fork. And then he would like pull it in that way. And so, yeah, so that, that's, I guess how I got started. And then I just sort of never really stopped, I guess. Yeah. We're, we're 15 years later and, uh, I'm still working on homebrews, still reviewing pull requests, still trying to fix stuff and make the project grow and be better each year than it was the year before. Yeah. I love the fact that you were actually kind of doing your own hacky solution and then found a thing that was like, okay, yeah, this is actually, let me, let me contribute to that. Um, you haven't taken a break in being a, uh, maintainer of homebrew, right? Like you've been continuously. Yeah. I mean, I've, I've taken holidays where. Of course. Yes. Of course. Yeah. I think it's probably more than, I don't know, at most two weeks, probably in that, uh, 15 year periods where I've not reviewed at least some pull requests. Oh my gosh, Mike. And how many, uh, maintainers are there now on the, like the. I'm not sure. I can't remember the exact number off the top of my head. I think it's 30 something. If you go to homebrew. So one of the things that I really like about homebrew is, uh, we partly inspired by me and partly a lot of people. Some other people around there, like we really lean really heavily into automation. So if you go on the read me, there's like a list of, you know, who all the people are in homebrew and the current maintainers and stuff like that. I think there's 30 of us. Um, and yeah, that list is like automated. So if someone gets, you know, added to or removed to the homebrew maintainers list, a little bot in the background will then open up a PR to change the read me and all this type of stuff. So that's, cause this is open source. Of course you can go and look at the code. If you, if you're like, Hey, I want to do that in my project, then, you know, go have a look at the codes and you can figure out how to do it yourself. Awesome. All of you who are looking to create your organizations, read me and do it in a way that makes sense and automated. Go check out the homebrew ripple and leave them a star while you're at it, please. Not that you need them. It's got plenty. I noticed you have a discussions also there. That's super active too. I'm going to share the link for this on the screen too. So like folks go check out the discussions so you can get a feel for how is. How the community is, but okay. So you join, you started contributing. You did such a great job that they invited you to be part of the first three. I suppose at that time, if you were a maintainer number three, and then you have not stopped. And how many years now since 15, 15 years, 15 years, no end in sight for Mike, no end in sight for Mike. You know, I've read a lot of the content that it, but, and by the way, folks, if you have not check out Mike's website and the content that he writes is absolutely fantastic. Especially for you, if you're a maintainer or someone who is aspiring to take on the big responsibility of maintaining, contributing to a project, take a look, take a look. I've quoted you so many times. One of the last bits that you did about maintainers don't owe you anything. When I was reading it, my neck about broke it. I was like, yes, yes, yes, exactly. It's so easy for us to become so entitled. And we come a long way from having to send the link to the commit to the upload request. Like, wow. It's, it's, it's been a journey for sure. So definitely check out Mike's website. I'm going to put it on the chat. Um, so that you can give it a read when, when you have some time, because there's definitely a ton of stuff going on there. So obviously it's been 15 years. A lot has changed. The original idea is there, right? You're still the missing component to Linux and Mac. You're still so essential to developers in the world. Um, if you look back at like all the work that you've done in this 15 years, like, is there any milestone in particular that you're super proud of that you're like, when we did this, when you have created the pull request and it was easier. No, not that one, but for the project in particular, is there something that you look back and you're like, that was, uh, sort of like a shift in. Moment. Uh, and home. Yeah. I dunno. Like the nice thing is there's been, there's been so many things that, I mean, there's been a few things I've done kind of by myself. And there's been lots of things I've been involved with or reviewed or whatever, I guess. Um, me personally, probably the biggest thing I felt like I did was, um, I guess transition homebrew from being when homebrew started, it was, I guess what we would call a from source package manager. So, uh, you, when you run an install command, it would go and download the stuff, the source code from maybe a gal repo, build everything on your machines. This was back in Intel Mac days. So your fans were going spinning away, something like a spaceship was going to take off. Um, but yeah, but like that ended up, that was a huge waste of like time and energy. Cause essentially like everyone's machine ended up building the same thing. So I created again, leading into the, the beer metaphor, this thing called like bottles for homebrew, which was our binary packages. And I kind of designed the first kind of system of doing that. And originally that was all built by me on my machine and then built by me in a VM and on my machine. And then we did the Kickstarter and that then turned into be, you know, we had our dedicated hardware that it ran on and then VMs on those hardware and then virtualized hardware. And now it's kind of all plugged into GitHub actions and stuff like that. And yeah, it's, it's kind of nice. Just having seen, you know, now we kind of are delivering whatever it is like thousands of packages with probably hundreds of updates every week. Um, all through that kind of infrastructure and using that packaging format that I sort of like relatively naively created back in. I don't know what year it would have been maybe 2010 or something like that. Um, yeah, so that, that, that makes me feel happy every time I see a little, like, you know, pouring the bottle in, uh, homebrew on someone's screen. I'm like, yeah, like I, I helped do that. So yeah, that's probably my, my, my proudest little addition to homebrew. I love that. If you have been using the homebrew long enough to. Notice this transition definitely leave a comment. A big thank you for making that happen and making it easy. Um, easier for everyone else to use it. I love the beer metaphors. I have to ask, where did that come from? Like why homebrew? You know why he named it that? I think just Max, the creator, he liked beer a lot. And then I think he came up with the original idea after having drink, been drinking some beer. Uh, so like that there's, you can see in the first commit for, uh, homebrew ever. It's like the kind of initial read me of like describing the project. And yeah. And one of the things was, you know, I think the last question that he asked himself that's in the read me is, you know, did you create homebrew while under the influence of beer? And it was the answer was yes. So, um, yeah, that's, that's where the, you know, some people don't really like the beer theme. Uh, other people are fine with the beer theme, but hates the brown color scheme on the website and everything like that. But I don't know, like I feel it's kind of got its own quirky charm at this point. Yeah. I love that. Well, um, listen, you can please everyone with aesthetics. So it does the job. I love the cask. I like everything is kind of, it ties together. Like the packages from the tap, like everything is, is sort of the same. I actually, I find that quirkiness flipping nerdy awesomeness. So that's fantastic. Thank you. Thank you for sharing that. Okay. So we talked a little bit about, you know, when you got started, um, sort of the pivotal moment for you that, well, a big development, something that you contributed to the project. Um, what are you now as a project? What is the future hold? I'm not trying to fast forward too much, but I know there are folks that joined because they're particularly interested in talking roadmap. And, um, yeah, so far I've seen a lot of comments loving homebrew, but I'm sure there'll be someone that comes up with some grievances. Uh, but I wanted, I wanted to hear from you, like as a team, what you're thinking. And if there's anything in particular that you could share, what else that'd be great. Well, shout out to, I saw George's comment there that just got highlighted. I mean, that's particularly satisfying for me because the, the last big project I worked on when I was still at GitHub was the merge queue. So that's, it's nice kind of when the two things overlap like that. Um, but yeah, with, with homebrew, the future is we don't, it's interesting. Cause we like, as each year goes on there in the past has been kind of like really big things that it's like, oh, well, we must transition from this to this. So whatever. Um, I, I don't know that there's lots of big things like that, uh, coming up with homebrew in the near future, but I guess two of our big concerns maybe for the, the rest of the year are just kind of improving performance and improving security. Like we're aware if I did a, um, you know, Google image, sorry, Google like auto completions the other day. And, you know, one of the things that was pops up and people ask is like, why is homebrew slow? So we have a bunch of maintainers in, I think a month or two, actually, who are going to have probably some sort of hackathon where they're going to focus on performance and security work in homebrew. So I would imagine after that, like certain aspects of homebrew will be faster. But still I merged some performance related pull requests this week. Um, and yeah, we're, I guess we're just trying to make homebrew continually faster, more reliable, more secure, and just better for people. I love that. I love that. And thanks Tanki for the comment. You've seen a lot of change in the last five years. That's awesome. That's awesome. Things are getting better. Uh, the talk of this hackathon, this is a group of maintainers that's organizing, or is it just, uh, contributors to the project that decided to like focus on it? Yeah. So it's, we have like a project leadership committee, which is some of those people are maintainers. And some of them are people just passionate about homebrew who want to kind of help with the organization and stuff like that. So the project leadership committee are the ones who've organized it and homebrew has some kind of funds. You can go and look at our open collective to see the money that's been currently donated to the project. So we're using some of those funds to sponsor some maintainers to get together in one place, um, in like the next few months, basically. Um, so that they can work together on this stuff and try and improve some performance and security aspects of homebrew. Oh, fantastic. Okay. And are it. It's well, we'll talk a little bit about what it takes. How can one become first a contributor? And then how do you, um, pull into maintainers? Um, but before we do that, folks, if you use homebrew and likely you do go ahead and sponsor homebrew and the homebrew project. So they can go ahead and do things like sponsor these maintainers to take the time to work on the things that matter to you. And apparently a lot of Google searches out. So, um, you can sponsor them through GitHub as you see on the screen or through your open collective, which I am going to pull and add up to it as well. Although I personally particularly like it when you use GitHub sponsors, because again, that was one of the things I helped to build a GitHub. It makes me happy whenever anyone uses it. So. Right. I love this energy. It's like, it's your thing and also your thing. So that's fantastic. Okay, folks. There you hear it. And again, this is one of those things that like any contribution matters. Uh, anything that you can put towards the project is only gonna go towards the needs of the project. And I love the transparency of like how all the funds are being spent. Um, that's, you know, that's a beautiful open source, everything out in the open. Um, questions. If you don't have, uh, the money to donate right now, that's completely fine. And if you have time instead, then feel free to. You can donate your, your code and your brain instead. That is equally, if not more valuable than any financial donation. A hundred percent. I agree. So let's talk about that. How can one become a contributor to the homebrew project? What does it take to have a PR merge? And how do I go back and start it? Homebrew has a nice little section. If you look, go to the homebrew repository that was linked earlier. Uh, you can see there's a contributing section and that kind of has a nice description of like how to get involved with homebrew. Uh, we've got some fairly extensive documentation that kind of guides you through things and some nice little ways of kind of getting started because we've got so many packages in homebrew. Chances are one of them is outdated or could do with some little code being cleaned up or whatever. And that's how most people get started with homebrew. Most people start as a repository. Homebrew is sort of split between the package manager itself, which is in a repository we call homebrew brew, which is like github.com slash homebrew slash brew. And then there's homebrew core, which is the main package for formula, which are like the main packages in homebrew. Um, so most people pretty much all maintainers, I guess myself included, get started with modifying formula before they go and start digging into the homebrew internals or the package manager itself. Um, unfortunately I don't review as much of the formula land anymore because we have lots of other maintainers who do that way better than me. So you might not see me until you go and make a pull request over in homebrew one day. But yeah, that's the best way to get involved. And we have, I think the, let's see. So the, the package manager homebrew brew has had 960 contributors over the years and homebrew core is I think quite a lot higher than that. Give me one second while I find the exact number. Uh, so we seem to be at, uh, yeah, over 5,000. I think it's over 10,000 actually like this. Yeah. Lots of contributors to homebrew core over the years. Uh, so yeah, if that's something you're interested in, then there's a very good chance that you'll be able to find something and get involved. A common thing you may get, uh, is people say, oh, well this is written in Ruby and I don't know Ruby yet. I would encourage you to take a look anyway. Uh, Ruby is quite an easy language to get started with. Um, and particularly like homebrew core. Like it doesn't really feel like you're writing Ruby as much as just kind of writing homebrew's own special little language. Um, and also I guess encouragement for anyone out there. So for me, the first Ruby I ever really wrote was for homebrew. Um, and then, you know, I've had a career since then where I've been mostly writing Ruby. So sometimes, uh, it's a nice way of kind of with homebrew or any open source project, I guess. It's a nice way of kind of getting started with maybe a language or a technology or a framework. You don't already know. Exactly. This is a good, well, for all of you Ruby, it's a perfect fit. And for all of you who might be interested in learning a new programming language, maybe it's Ruby. Maybe you take a look and this is how you start. So that's cool. So you think for folks who are starting the formulas will probably be like a good point of entry. Yeah. Starting clear up, updating that. I'm sure that documentation is beautiful and fantastic and it has all the things that you need to know. So that, you know, you make sure everything is stable and compatible as you're doing all your work. So you hear from Mike, if you can contribute financially, please do. But if you cannot, then you can also contribute with your brain power and take a look at there is likely to be something that needs to be updated. And why not go give the team a hand? Um, any other community initiatives that you have going? Um, besides of course, contributions of code and like the core team having the hackathons and stuff like that. Yeah. I guess we always value people kind of submitting pull requests, uh, for stuff. Like both fixing bugs, improving the style of stuff. But also if there's, you know, a feature of homebrew that you feel like is missing or some small addition, then that's always viable. Also in our kind of discussions forum that you linked earlier, Andrew, uh, there is lots of people asking questions in there. So if you go in there and you see the answer to a question is in your head and you're like, no one's answered this yet, then it's really lovely to go and help people out that way and answer questions that way. Um, and then similarly on our kind of issues, sometimes it's helpful if someone is asking for help in an issue. Like if you know what the solution is already, then that's a good place to jump in. But that's, that's a little bit more tricky. Cause I guess most of the times by the time people are opening an issue, it's generally like they might need one of the maintainers to help them out. Gotcha. Okay. Well, listen, this is all excellent, excellent advice. Um, so now, you know, if this is a project that you're interested in contributing in, um, there is many ways that you can do it. And I love the idea of helping folks out in the discussions. Cause even if you're new to homebrew, uh, heck new to software engineering and being a developer, you already know more today than you do the person who started, you know, yesterday or. They're not something like that, you know, you already have something to share. Um, so definitely it's nice to, to be able to do that. Okay. Well, so we know a little bit about what you're thinking for the future. We talked a little bit about how you became a maintainer, um, what the core team is doing. Love that you took chair with us, that there is going to be a focus on performance. So stay tuned because I, I guess the next five years are going to be even more awesome than the last five years. Uh, like someone commented, um, I, I appreciate you sharing a bit of background on that. And then I have to ask, especially because you have such a, just wealth of knowledge and experience being a maintainer. If you give someone who's seriously looking, maybe some, they started maintaining some packages. Maybe they started and now they're really considering, you know what? I think I'm going to, if I get invited to be a core maintainer, I'm going to do it. Um, there isn't really a manual out there anywhere telling people, that's a book you can write, Mike. They're telling folks like, you should think about this before you do that. Like, what is something that you wish you knew before you accepted that slack message? Or I don't know what, what, what are you using then? Yeah. DM. Yeah. So, uh, I think it was probably an IRC DM. Uh, I forget what they call that in IRC days, but yeah. So I mean, I, I guess like a lot of the stuff that I wish I knew, thankfully has between homebrews got some documentation that is, if you go to docs.brew.sh, I mentioned before with our automation, like our documentation is okay. It could always be better, but we try and have documentation for maintainers and even homebrew commands for maintainers to use and things like that all be nice and out there and open. So other people can learn from things and stuff like that. Essentially we try and keep things private as little as possible. Um, as you know, as long as it kind of makes the project kind of function well and be safe. So if you check out like the homebrews, uh, documentation, there's some maintainer advice there, like guidelines for maintainers and stuff like that. And then as Andrea mentioned more generally, like outside of homebrew, like I've written a little bit on my blog over the years about things like, I guess the, the post you highlighted earlier, I guess one of my more amongst some demographics, popular posts. Some people don't like it very much is, uh, open source maintainers. Are you nothing? And in some ways, yeah, I wrote that to myself, uh, for something I wish that I had had very early on. Like it's, it's very easy when you're maintaining open source software to feel kind of overwhelmed by the expectations of other people. Or like if someone is being really entitled or very rude or is very angry that you introduced a bug, which negatively infect them. It's very easy to kind of internalize that stuff and feel like this is my fault. I have to stay up all night fixing this or whatever it may be. And just, you know, knowing that you don't actually have to do literally anything with open source, right? It's, it's always up to you. What you do is I think really helpful. And I think for me being involved with, uh, homebrew for 15 years, I think that's the thing that's managed to help me stay involved is that figuring out that stuff and having a bit more, I guess, like work life balance, open source life balance. Maybe perhaps where I don't have homebrew github notifications on my phone. I don't have homebrew slack on my phone for maintainers. Like for me, it's homebrew is a thing I do when I sit down on my computer and when I'm not on my computer, I don't get bothered by homebrew stuff. And if somehow there was some urgent homebrew thing that only, you know, I only, I have access to be able to do this thing. Then enough of the maintainers have my personal cell number that they could get in touch and let me know that way. But that's, that's not happened or at least hasn't happened for at least five years. So yeah, it's, it's, it's nice to kind of feel like partly through attitude shift and partly through kind of hard work. It's at a point where it's probably not dependent on any one person, including myself. And, uh, it's, yeah, it's a bit more of a chilled vibe. And we, I guess kind of like families, like we look out for each other, right? Like another nice thing I like about the homebrew project that I've tried to introduce is if you're really, rude or unkind to one of the other maintainers or, you know, a bunch of our users or contributors, then we, we don't like that. And particularly when the maintainers are giving up most of the time, they're unpaid labor on evenings and weekends. You know, it's if you can't be polite and you can't be civil. And if you're asked to adjust your behavior and you don't adjust your behavior, then that maintainers having a good day is more important than your pull request or issue being fixed or whatever it may be. Because at the end of the day, if you don't have any humans who want to work on homebrew anymore, then the project is dead. So the most important thing is the humans behind it. A hundred percent. I think it's so easy to lose that. We kind of dehumanize what we can see. And so the people in the background doing all the work become just like dots. And yeah, I seen some of the comments. I mean, there is plenty, please read my song because there is a lot of experiences and stuff there that would just kind of make you just sometimes just lose faith in humanity. But we're all here supporting open source. We're here on Friday talking about it. So we're going to create a new generation of folks that are going to be much more grateful to folks like you who put in so much of their time. This separation of like how you view work and view maintaining the project. Were you like that from the beginning? Because 15 years is a long time to maintain something without burning out, without just saying like, I'm sorry, I'm out. No, I definitely wasn't like that at the beginning. In the early days, I had homebrew slack on my phone. I was doing a lot more stuff on like late into my evenings and my weekends. And, you know, if I got pinged at the dinner table when I was eating my meal, you know, go and let my food get cold when I went and fix things. You know, it took a long time to learn that because I didn't really have anyone to sort of teach me that stuff. But also, you know, like getting older and, you know, I've got several kids now and a dog and a wife and a therapist and, you know, all of these things kind of help you like figure out your priorities and what's important and what's not and what needs to be done right now versus later. And I mean, and I think also just the stuff makes you more efficient with your time partly as well. And I feel like it nothing sharpens the mind and knowing that, well, at this time, I'm going to have dinner with my kids. And if this isn't fixed by this time, then it's not fixed today. So, yeah, stuff like that is it's helpful. But, yeah, it's something I would encourage everyone to think about. It's less you don't need to be quite maybe as strict as I am on some of this stuff when you're younger. But, you know, the older you get, if you want to still be around in 10 years, then, yeah, it's the sustainability aspect is very important, I think. Please take note, young and old people alike. I needed this message today, by the way. I needed this message today. So thank you. Thank you for that. Nothing is the end of the world, folks. I promise you that. Even though we feel it and we take everything so personal, I'm like that. I take a lot of pride in my work. So to me, everything is an emergency. But I need to slow that. There is a question from Jorge or Georgie. Sorry. Let's see if we can help. Mike, thanks for the session. Can you give us any color on the work Homebrew is doing via Alpha Omega OpenSSF? How is it going so far? What's securing the packaging supply chain? What respect to the security? That's a great question. And it's, I guess what they might call in the music land a deep cut, because it's a small effort, but it's very important, but kind of not widely known. There's some kind of ongoing work now going on through the OpenSSF and we've got some home maintainers and some non-maintainers who are kind of getting involved right now to essentially increase the confidence. I mentioned bottles earlier. This is kind of, I guess, part of kind of securing that. So when you download a binary package, a bottle, then we automatically want to check some on that to make sure that it's verified appropriately and things like this. So there's another layer on top of that, where you have the ability with GitHub actions. Now it has a support for, I think it's attestations. Yeah. Do you see it now? Yeah, exactly. So that's what this is related to. So this is effectively saying, because we build stuff on GitHub actions, having a way that you can with right now, it's like an opt in homebrew command, but eventually it will be part of the actual full flow and homebrew itself. But being able to say, Hey, this thing that I downloaded, it's that definitely like legit and from homebrew itself and being able to follow the chain essentially to GitHub and say, and GitHub can verify. Yeah, this was built from this GitHub actions build at this time in this day and whatever. So we're going to have that and backfill it as well for some of our binary packages. Well, eventually all of our binary packages. So yeah, so that work that Georgia mentioned is going really well. And yeah, I'm very, very happy with the progress that's been in so far. Awesome. Okay. Let's talk about your new venture, please, because I'm super curious as to how was it born? Obviously, and I'm, I guess was there, there was no other company doing this, right? Yeah. Yeah. So, I mean, there's been kind of, people have talked to, I guess, me and probably some other homebrew interners for years about the idea of like, Hey, like, what about having a company around homebrew? There's quite a lot of open source projects. There's not all good news around that in the news recently, without naming any names, but there's been a lot of, you know, open source oriented companies that have kind of tried to figure out, Hey, can we make a business around this open source project? And yeah, I, in the past have been kind of never that kind of into the idea, probably never felt like the right time for either me or for the homebrew project itself. But now homebrew has like a really robust kind of nonprofit governance structure and its own funds and stuff like that. It felt like it was a good time. I was leaving GitHub anyway, and I had two former GitHub coworkers who I loved working with. And the three of us kind of got together and came up with this thing that my CEO, John, called Workbrew. It was a, I thought an excellent idea of the name. And it's essentially, you know, what homebrew is to doing stuff at home, workbrew is to doing stuff at work. So we're building like a layer on top of workbrew itself, on top of homebrew, sorry, itself. So it makes it easier for people to be, right now we're focused on if you've got like a, if you're a security professional, a Mac admin, IT admin, and you have, you know, say like a hundred, a thousand devices in your company that are all running homebrew. And you have something like the, the X Z or X Z, I guess, as the Americans would call it vulnerability from like a few months ago. Then right now there's not really a good way of saying, Hey, I want to make sure that I have the latest version of that on every machine. So we, we built something that can kind of do that. We have a version of homebrew called workbrew that runs on your machine. It looks and feels exactly the same as normal homebrew, but it runs under its own user for improved security. And on top of that as well, we have our console, like a cloud service called the workbrew console, and then a background service that runs on your machine called the workbrew agent. And effectively between the three of them, you have the ability to run stuff in homebrew as you normally would, but in a more secure fashion and allow your kind of IT administrator to be able to upgrade like stuff throughout the, their fleet of devices as they need to. So that provides kind of improved security for people. And we've got a lot more stuff coming down the pipeline to make work group even better for engineers who are using homebrew at work, who want a little bit more in the way of kind of stability and better handling of versions and things like that. So we're in private beta right now, but if you go to workbrew.com, you could read more details. You can get a demo with our CEO, but we expect that we're going to be in public beta later this year, and maybe even have a full public release later this year. And then we'll be able to release all our pricing information and stuff like that. Amazing. Okay. Well, so I added a link to the website. So you're on private beta now, but there is a contact. I think there is a contact option there. So if you're interested, definitely hit them up. I don't know if your private beta is closed now, but Yeah, so we're still looking for more people for the private beta. So we're looking for, I guess, what we call design partners right now, which would be people who sign up, start using it, appreciate that we're not kind of a V1 yet. And people who are kind of willing to work with us to kind of give us feedback in exchange for us kind of building the product more in the direction that might be useful to them than they otherwise might get if they join later down the line when we've got more customers in a year or two. Yeah. I love that. This is like an administrator's dream, because you don't have to pester everybody to do like your updates or like now, I guess you control everything virtually, right? Like they have complete control. Yeah. And we're also trying to do like a fairly, I guess, again, I alluded earlier to some of the kind of less popular stuff around open source. One of the nice things we're trying to do as well is the work brew itself is something that you pay money for, you know, we'll have free trials and demos and all that type of stuff as you would expect. But essentially work brew is like a paid project to be used by companies and homebrew is, is and will remain an open source project used by individuals. And in the course of our work on work brew and even my personal work on work brew, I end up doing a bunch of stuff that makes homebrew better for people as well. So I feel like it's, it's also one of those nice things because I can now dedicate more of my time to focusing on work group. I need and want homebrew to be better. So like in the last week, I, this performance optimization in homebrew sometimes looks like porting a bunch of Ruby code to bash code because it runs even faster. So I ported a bunch of Ruby stuff to bash stuff and reordered a bunch of things. So a few commands run a hundred times faster than they did before. And that was primarily oriented for work brew and for our customers and the way they're using our project. But the nice thing is, is that benefits everyone who uses homebrew. So you have more people spending more time working on making homebrew better now because of work brew. Amazing. Can you show us anything? Are you up for it? Yeah, sure. All right. Let me see. So just screen share for a little demo. Yeah. There should be a little, there should be a little plus. Let me do it. Let me do it. So let's see. And folks, go ahead and check out the website. And at the beginning of the session, I said, we're going to do a little giveaway. So I'm going to put that link again so you can enter and we'll do it before we go. Let me see what I'll be able to see when your screen pops up, Mike. Is that popping up or not? Let's see. Not yet. I only see. Yeah, not yet. I think it says I might have to rejoin the stream. Can I leave and come back? Oh, that missed me. Absolutely. No, you'll be fine. Let me try this. I'll be back in one second, everyone. Wait, please. All right. Please don't leave. Mike is coming back. Wow. Mike is not here. Let's try this again. Let's see if I can share this banner while keeping myself there. I feel like that should work. Oh, here we go. All right. So now, Mike, you're back. I'll go ahead and share the QR code again for the giveaway, but I'll share the shortened version so you can go ahead and enter. If you're up for it, you can buy yourself something nice at the shop. Why not? And I dropped the link and yes, Workbrew does sound dope. Let's take a look at it. So this is Workbrew. This is the Workbrew console. Right now, as it says, you only can get access if you're in our private beta, but I'll give you a little sneak preview of what we're doing so far. So I'm going to sign with GitHub because we're on open source Friday. Why not? Let's do that thing. So we're going in here. So if I see like I've got my little avatar up here, I've got a few things over here that I can do. I'll just click through these briefly. So this is my Workbrew workspace that I'm on here right now. So that's basically just my collection of things. These devices are all different Macs. So this is my Mac here right now. So we're going to go and have a look and see like what I've got installed. This is also linked to an MDM provider called Kanji. You can download the kind of Workbrew package here, which is nicely signed or like distributed through your MDM provider if you're using one of those. If I go through here, I can see essentially like the stuff that's on my machine. I can see all my packages that you have. This is all you can infer this from my brew files. So this is all public anyway. I've got this Node.js is currently outdated. There's a 22.1.0 updated here. So I could click that button and I can go and say, I want to upgrade that machine. Make a upgrade node on that machine. I could run that just on my machine here, or I can run them on all the devices in the fleet. And similarly as well, I could go and customize homebrew on any given machine. I can go and pass some homebrew environment variables here. There's all the stuff in the man page in here of all the stuff you can get homebrew to do. So I could go and apply that on the machine. And then that is set in this kind of system-wide location. That means any homebrew on that machine is going to use these environment variables. So that's our today's little brief demo. Oh, no. In fact, let me see. I'll share my terminal actually as well. Oh, perfect. Even more fun times in terminal land. Give me one second. So where are we? Present show screen. So. There we go. This is my -- let's see. Can I make this a bigger size so you can see some of this? Let me -- I'm going to try and make this nice and big. Thank you. Oh, no. It's now going too big. This is like Tetris with a terminal. This is terrifying what's happening. Anyway, so this is my terminal. My machine is called MicBook because I'm a dad and I like silly jokes like that. Yeah. So homebrew and workbrew work pretty similar. So if I run brew version, then I can see I'm on workbrew 0.6. And then homebrew has all these details. If I run brew config, then I can see all my stuff that I've been using. My stuff that I've set up by, you know, my workbrew version. But then all my homebrew stuff runs as it normally does. If I have -- I guess we saw the node stuff earlier. So let's upgrade node. So this is using homebrew. If any of you haven't seen homebrew before, this is like the typical way that homebrew is doing its thing. As I said, that's the pouring thing that I mentioned earlier. So this makes me -- oh, this is a new bug. I'm probably going to go fix this later. So I've gone and poured nodes here, which has got my new version of node.js. I have homebrew auto clean up everything afterwards. So that's in here. And the only real sign that this is anything different, this is workbrew, is this little coffee cup here. So instead of using the beer icon, by default, homebrew -- sorry, workbrew will use this little coffee cup. But yeah. But other than that, everything works pretty much the same. But if you -- if we want to -- if you want to go in the real -- the real fun deep dive stuff, you can go and look. So we have -- if I'd one -- excuse me while I figure my current setup. But yeah, we want which brew. This is not actually going -- normally this would go to opt homebrew bin brew. So let's see what's going on there. So we have opt homebrew bin brew, which is like a normal homebrew installation. Everything in here is like what you would normally see in homebrew. But this is now all owned by workbrew now. So when I'm running brew from the opt workbrew bin, it is running this. This is owned by root instead of normally by workbrew or by the normal user. So this lets me go and run everything and I don't need to be an admin. And it all intelligently changes to the other user and stuff like that. So it's basically -- it's nice. It works essentially the same way as homebrew, but it's dramatically more secure and nicely integrated. So I can kind of send commands to the machine from the remote console that I showed you before and everything like that. So welcome to workbrew. Very neat. Very neat. Let's see the question. So we can push package out to a fleet with workbrew. This is -- there is a good package that should use code committed send. I'm not sure. Committed send. I'm going to have to check it out. Yeah. And there was a really good question above actually from -- Let me see. I think. Oh, yeah. Let me see. Was it about -- It wasn't about workbrew, but it was about open source stuff. So I thought that -- but I thought it was really interesting. Oh, yes. Yes. We got to that before we finish. Absolutely. Yes, please. This one. And this is dear and dear to everybody that's thinking about maybe contributing doesn't feel like they're quite there yet. So how much time did it take you? What did it take to become confident in open source contributing? Yep. And how do you deal with the expectations of all reviewers? Or when do you know your code is good enough? Yep. So I'm going to work backwards from the end. So your code is never good enough. My code is never good enough. I've been doing, you know, I've been probably writing code in some form for, I don't know, maybe, I guess, just probably over 20 years now. And I've been working on Homebrew for 15, but I still -- this very week, you can go and have a look at the Homebrew tracker and see how in that performance PR I mentioned earlier. I also broke something which broke a bunch of Homebrew's testing. It broke things for some users and everything like that. So that code was not good enough. It got reviewed by someone else, a very talented code reviewer and programmer, but he did not spot the mistake either. So there you go. That's what's going to happen. But I think if I can give anyone advice, and this goes to whether you're doing open source or whether you're doing closed source stuff or working or learning or whatever, you're going to write bugs. The one inevitability with all software is there are going to be bugs. And, like, also, the sooner you can detach the sense of if you introduce the bug that, like, you don't beat yourself up and be like, I'm a bad person, I'm an idiot, I suck, whatever it may be. And it's just be like, well, everyone writes code and sometimes you write some bugs and sometimes you don't write some bugs, right? And if I was writing code that had to be on the space shuttle or whatever, then chances are probably the number of bugs would be reduced, but it would take me a lot longer to do it. And sometimes actually spending that time and doing things really, really, really slowly, but really carefully is what's worthwhile. And sometimes it's not. And as to the first question, how much time did it take you to become confident in open source contributing? I guess I got started with open source probably, you know, less than two or three years after I started coding for the first time ever, really. I didn't really do any meaningful coding before I did a degree when I did computer science. And I used Linux back in those days and I kind of, you know, I sort of start getting involved with contribution. That was all this was all before GitHub. So the contribution and I sent a few patches back and forth and stuff like that. But it mainly looked in the early days, like just hang out in RC channels and helping people out where I could or posting on issues where I could figure stuff out or testing other people's patches or whatever it may be and writing some docs and stuff. But with GitHub, the beautiful thing is, I mean, I don't think you need to be really great or really confident or whatever. Like it's the best way to learn and to get good is just to get started. Right. And as I said, with Homebrew, I didn't know any Ruby to begin with. And a lot of the Ruby I wrote was terrible. A lot of the Ruby I still write is terrible, but it's about kind of just learning along the way and trying to enjoy that experience. And at the end of the day, on a project like Homebrew, if you're sending a contribution, like everyone wants you to succeed. Everyone wants you to learn and get better. And we all kind of care about growing the number of people who contribute to open source and Homebrew and everything like that. So, yeah, I would just encourage you to, like, just try it. And a good thing that people used to say a lot less so now in open source was this idea of scratching your own itch and what was meant by that. And I think it's a good thing that you can learn from if you want to get started with open source contribution is this idea of the best bug to fix is a bug that's really annoying you. Because even if it might be harder than a really easy bug, then I guess, yeah, Pranav just asked. He said he wanted to contribute as well. Like, yeah, the best way to contribute is find something that annoys you. It's either a bug or something doesn't work quite the way you expect it to or maybe fail some of the time or whatever. And it's much easier, I think, to motivate yourself to work on that stuff where it's something where, you know, like, hey, if this gets merged and included and depending on the software and a new release or gets released straight away, then I can benefit from that straight away. You know, at the end of the day, I still use Homebrew. I still use Homebrew every day. Right. And the things I'm most likely to fix most quickly in Homebrew are the things that annoy me the most. The performance improvement I added for, you know, for work brew but went into Homebrew. No one told me to do that. A customer don't request that. I essentially requested myself because I noticed something was too slow. And I was getting very angry because I'm very impatient that something took a second when I thought it should take 0.1 of a second. So I made it take 0.1 of a second instead of taking a second. And now I'm happy. But if, you know, if I'd gone to a list and was like, oh, well, you know, which issue is going to help other people the most? It probably wouldn't have been that one, but it's the one that I found it the easiest to make myself to work on. So there you go. Good luck to all of you. Yeah. Thank you so much. The motivation came from a personal problem. So find the thing that annoys you, the thing that you want to fix or the thing that you're into, the thing that you're like, you know, interested on and it makes you excited to sit down and write code. Mike, it's been so nice having you. Thank you so much. Is there anything coming up for you that you want to share? Like, are you going to go talk somewhere or no? Come back here and talk. Yeah. So I'm going to speak at, if anyone's in Japan next, in a couple of weeks, I think it is, there's the Ruby Kygi conference. It's the main kind of international conference for Ruby in Japan. So I'm going to be going over there and I'm going to be speaking about humbrew and Ruby. So I'm really excited to do that. And I'm pretty much every year. I'm at FOSDEM, the free and open source developers European meetup in Brussels in February. So humbrew generally has our AGM where we kind of try and get everyone together around that sort of time. And so if you're there, if you see me, please don't be shy. Like, please come and say hello. And I met at a conference last year, a guy called Bruce Perez, who's the guy who created the term open source. And I took a gratuitous selfie with him massively fangirled because I feel like, you know, so the thing to remember is if you see me at a conference and if you feel shy or whatever, like, however shy you feel. So I felt just as shy if not 10 times as shy when I've met my heroes too. And I'm very friendly, really. I don't bite and come and say hi, tap me on the shoulder and we'll have a lovely chat. Amazing. Unless your meat bite or something like, let's let Mike eat. And then, then you can go talk to them. But thank you so much, Mike. I appreciate it. I posted the comment, um, on the website for Ruby Kai, Kai, Kai, I can't say it. Um, and look at you. My Ruby is not Ruby and you're going to speak on a Ruby conference. So I love that. I love that so much. And hopefully, yeah, Sam, hopefully we'll see you there. Um, Mike, you're the best. Thank you so much for all the amazing advice. Thank you to everyone who showed up and asked such thoughtful questions. Super appreciate you being here. And thank you for, you gave us like a lot, like real life advice and real technical advice. So I'm super grateful for your time today. Thank you. You're very welcome. And anyone who asked a question, thank you so much. Anyone who's question. I didn't get a chance to answer. Feel free to send me an email. My emails. I'm not going to give it out right now. It's an exercise to the reader, but it's relatively easy to find. And if you email me, then I'll do my best to respond. Have a great weekend, everyone. There you go. Thank you, Mike. We'll see you hopefully again soon. Once you go out with work, would you have to come back and do it on a demo? Please, please, please. Thank you. Thank you, Mike. Appreciate you so much. Thank you everyone who joined us for Open Source Friday. Wow. That was incredible. So exciting to get to catch up with Mike and also like see what Workbrew is going to be doing. Really, really exciting things coming up. I love that as a byproduct of creating this company, Homebrew is only going to get better and better and better and better. Like how cool is that? So definitely shout out to that team that's building this solution and shout out to all of the core contributor maintainers, folks that are keeping Homebrew alive. Thank you for everything you do. Let's do this giveaway, please. Please, please, please. Don't leave me yet. I'm going to beam the... There we go. If you haven't entered yet, I'm going to give it like 10, 9, 8, 7, 6, 5, 4, 3, 2, 1. And we'll go ahead and do this giveaway because today is a special day, folks. Special day. Thank you again to everyone who joined. You're the absolute best. All right. Let's go ahead and... And I'm going to use the tool. I'm going to use the little app. So there shall be no nepotism in the giving of the awards. But thank you. Let's do it quickly. And shout out to this. I think... I don't know if it's not an open source project, but we're definitely taking it. Maybe you had an MIT license that allowed us to take it. So the original creator of this is called iSlam. We're going to drop them a shout out and some stars. All right. Let's see. Beautiful. Congratulations, GearHeads. Thank you for being here. And to every single one of you who was here with us this Open Source Friday, thank you for supporting Open Source. Hey, if you know a maintainer, tell them congratulations. I feel like the entire month of May is a month for maintainers to be celebrated. So tell them congratulations. Give them a shout out on Twitter. Never X. On LinkedIn. Whatever. You know, let's do these things in public and show our appreciation and bring some positivity to this. That is so important to all of us. Thank you, everyone. GearHeads, I'll be sending you an email shortly. I appreciate all of you. We'll see you next week for another Open Source Friday. Thank you for being here. Bye-bye. Take the rest of the day off.

This week's episode of the MacAdmin's podcast is brought to you by Kanji. If you've ever enforced a security framework across your Apple fleet, you know that it can be extremely tedious. Kanji makes this a lot easier. Most MDM solutions give you the tools to help you manually achieve general security compliance. But with Kanji's device management solution, the scripts, controls, and settings needed to achieve compliance are already built in and organized into templates so you can get going on day one. To quote a customer, Kanji has helped us achieve much higher compliance with much better results, all while delivering a better experience for both end users and admins. Check them out at kanji.io slash macadmins. That's K-A-N-D-J-I dot I-O slash macadmins or join the Kanji channel on the MacAdmin Slack to say hi and see what they're up to. Thanks again to Kanji for sponsoring this episode of the MacAdmin's podcast. Hello and welcome to the MacAdmin's podcast. I'm your host today, Marcus Ransom. And Charles, how are you going? I am well. It's a stunning weekend. I got so much done. Joel and I started writing this weird project for the Vision Pro. I blame Joel for my lack of spare time these days. So you've got your Vision Pro replacement back. Have you managed to break this one? I have not broken a second. I did print a Vision Pro holder to keep me from breaking anything. So crossing fingers. There we go. And how are you, Marcus? Well, I'm fine. I've been traveling for a week along with, well, not along with, but alongside about a couple of hundred thousand Taylor Swift fans going to and from Melbourne and Sydney, which, you know, so the airport was full of lots of people exchanging beads. Access to hotels in Sydney where I was staying was challenging. So I've been dealing with a hotel where the access card to my room would spontaneously stop working, taps falling off, interesting odors, those sorts of things. So, you know, it's good to be home. I don't remember the weird odors when I took my kid to see Taylor Swift. I do remember some weird odors, like when I went to see the Black Crows, but I'm guessing they were very different odors. I don't know. Probably, probably. You know, I, yeah, exactly. Hotel odors, going to see band odors, very different things. Usually don't spend too much time. But we have great guests today, right? We do. Let's talk about interesting things. So we've got the team from Workbrew here joining us to discuss the challenges Mac admins face with Homebrew at their companies. So we're going to talk about ways to cut down on IT busy work while also getting ahead with your engineering and security teams, an uncompromising approach to engineering productivity and security posture. So along the way, we're going to touch upon maintaining Homebrew open source project and their approach to building a business around open source. So welcome to the podcast, everyone. Thanks for having us. Thanks. Hey. Well, what we might do first is how about we get you to introduce yourselves and let us know how you met and what got you to where you are now starting a startup. Yeah. So I guess I can go first. So my name is Mike McQuaid. I'm the CTO of Workbrew. And outside of that, I'm the project leader of Homebrew, the macOS and Linux package manager for open source, which I've been working on for 15 years. I'm based in not so sunny Edinburgh in Scotland. And I left GitHub where I spent a decade finishing as a principal engineer last year to go and join John and Vanessa, my co-founders, to start Workbrew, our exciting startup doing some interesting commercial stuff in the Homebrew space. Hi. So my name is John Britton. I like to call myself a software developer, but really I focus mostly on developer tools and helping people become better developers. So I got my start in this space. My first startup that I worked at was a publishing company where I worked with Vanessa. I was a software engineer there and we worked in building college textbooks for people in like a customized way that was also open source. Following that, I joined Twilio and I was a developer evangelist there. That was an excellent introduction to kind of the Silicon Valley startup scene. And then after that, I joined GitHub to lead the GitHub education program. So while I was there, I created the GitHub Student Developer Pack, which is a bunch of developer tools for students, built GitHub Classroom, and later went on to lead all of developer marketing for GitHub up through the Microsoft acquisition. While I was at GitHub, I worked with Mike and Vanessa very closely. And yeah, in 2019, I left to kind of go out on my own. And a few years later, they both joined me and now we're working on Workbrew. Love it. So I was just looking through my personal blog and I think the first time that I wrote an article that included installing something with homebrew was 2011. And that was a long time ago. So I guess package management to me was always a nightmare and homebrew definitely made it easier. Do you guys want to take us through what homebrew is for listeners who maybe haven't used it? Yeah, sure. I'll start with like a little bit of history, I guess. You mentioned 2011. So homebrew was created originally in 2009 by a guy called Max Howell, who was, happened to be working for a little start of Lost FM. That probably brings back some memories of what was all the rage in those days. Scrabbling. Sure. Less, less of the rage nowadays. But yeah, so he had played around with various Linux and Mac package managers and sort of got some inspiration from various places, but didn't really like anything that he landed on Mac OS, I guess, which would have been Mac OS X. I appreciate the audience of this podcast probably likes the level of pedantry that we homebrew maintainers also like. I thought it was called Mac OS X. I don't think like. Yeah, true, true. Yeah. Mac OS X. Thank you. If you're going to be correct. Yeah. If you're going to be a pedant about it, like it's better get it right. But yeah, so he decided to create his own thing, which ended up being called homebrew. It was, if you could read the read me of, from his initial commit where he talks about the beer theme and also that he consumed beer while he was creating the original beer theme, which is part of the inspiration. So yeah. So what, one of the interesting things he did with homebrew back in the day, it was kind of created, like GitHub was relatively early in those days as well. And like, I think like pull requests, which are kind of people's primary interaction with GitHub nowadays didn't exist when homebrew was first published on GitHub. And Mac's had the idea of like, unlike the way most package managers work of instead of he maintaining himself or like appointing maintainers for every package or groups of packages that essentially it would be a bit more of a free for all. And he would kind of moderate, um, what was coming in. So I guess I sort of knew Max through a friend of friend in London and I kind of heard about this project like fairly early on and I kind of played around with it and it sort of matched my sort of ideas for how package management should be on Mac OS, which, uh, essentially was use as much stuff from the system as you can and try and make things fast and nicely optimized and care about nice error messages and yada, yada, yada, all this type of stuff. Um, so yeah, so I started working on it in 2009 as well, uh, about maybe six months after the project kind of originally was created. I think I was maintained at number three or something like that. And for my sins, I've stuck around that. I'm still doing this stuff 15 years later. And I guess for those of you who don't know what homebrew is and have never heard of it in any way or used it in any way, I guess the way I tend to describe it is it's essentially like an app store for your terminal for open source software primarily, although it's kind of slightly grown in scope since then so that it will also run on Linux nowadays. And it can also be used to install, uh, like binary software that's like proprietary software, let's say like Google Chrome or whatever you can install with a brew install Google Chrome. Love it. And I feel like, so I've, I still use, um, that Ruby command that was posted gobs of years ago, um, that curls it down from GitHub and runs the install. Is that, is that the way that you would say is kind of the right-ish way to install it? That's still the primary installation method. I think lots of very angry people on the internet for a very long time have, would strongly disagree with the implication that it's the right way because people don't like that. But I, I, again, I think homebrew is one of the first places to do the, like curl this, the script of the internet and, you know, pipe that into your terminal approach, which is now a really easy way to install a bunch of software. But yeah, nowadays homebrew also has like a macOS like package that, um, and workbrew has our own enhanced version of that, which we'll, I'm sure we'll get onto later as well. Oh, for sure. Um, yeah, I, I guess the objections that people might have is that someone could be masquerading the DNS and you can be installing something else, you know, or, or what have you. But I, I get that. I, I hadn't even thought about that until you just said it. But there, but there's good, you know, if someone's doing security properly, there's ways to ensure that that's not happening and, you know, um, put steps in place, uh, which, which is generally what brings us to the, um, the challenges that Mac admins have with homebrew. Um, most Mac admins will, will either use homebrew themselves or have used homebrew, whether it be for, you know, personal machines or machines that they're developing on. But when it comes to using and managing homebrew in an organization, so this is something that, you know, can best be described as a little bit chaotic for someone who's trying to have complete control and, um, consistency about a system, um, letting developers have access to something that can, you know, add an update software outside of that management tool can be a bit problematic. So, you know, what have you observed from Mac admins, uh, trying to use homebrew in their organizations and how they've gotten around that? I think there's the way Mac admins tend to kind of want to package and consume software, like often, you know, PKG files and turning software that doesn't work that way into that format. And the way homebrew kind of deals with this stuff to kind of consume PKG files, like in some ways it's kind of looking through the same telescope from different ends. Like I think the, the ends are generally the same, but the problem is, is that again, when you get into kind of Mac admin land, like the way you're kind of generally used to doing things as you have something on the machine, you know, some MDM provider say that's pushing PKG files down, which are run as root. But then I don't know if this is something that you Marcus or yourself, Charles have experienced personally, but the, the issue comes when you want to then run homebrew that way because homebrew refuses to be run as root. Um, and if you, uh, it's, it's funny because if you want to know like a little backstory behind that, like if we, I've always wondered. Yeah. So the reason why is, uh, so homebrew relies on the Mac OS sandbox as the, basically the sandbox that is used by like the app store and stuff as like somewhat of a kind of security measure to stop kind of when you install packages, then be able to just have full access to your system. And the issue there is that the, at least last time I checked, the Mac OS sandbox is severely limited or, and or completely broken if you run it as root. So like that was the reasoning for there is that it's again, like a bunch of stuff in homebrew, it, it could be maybe explained a little bit better, but essentially like we don't let people do it because it's extremely dangerous and they run the risk of on Linux. It's even worse because you don't have a sandbox there at all. So you're, if you're installing software from source on Linux with a default homebrew configuration, like any make file could just write or remove any file anywhere on your system at any time, uh, which is a little bit scary. And again, like bring back to your question, I guess this is the, the Mac admin perspective is like, you don't really like the idea of like random software running random things as roots or as the user with unconstrained access to all their files and everything like that on the system. Especially when you compare that to the, the general security principle of using a least privileged user. So, you know, we won't allow users to be administrators on their machines so that they can't install software, um, modify, um, things on the machine, whereas, you know, which is the way, you know, you're doing things in homebrew where you're not using the root user yet. You're giving the users the ability to install and update all of these binaries, which, you know, is, as you're saying along the way that Apple have designed the operating system to allow users to have the functionality that they need and get the most out of their machine without compromising the operating system or getting in the way and preventing things from running every time they have an update. So it's, it's a real challenge when most of our management tools are designed to stop people doing things the wrong way. Um, and here comes a tool that does things the right way. And so many of those guardrails then become challenging because somebody has read the instruction manuals in a way, yeah. But also, I mean, it's not like this idea is super, um, new. It's just, I always felt like homebrew had more of an atomic operation than like a pip or for Python or a CPAN or any of the other package managers that I used because it could drop things from, you know, Ruby gems or just all kinds of different tools into one central place. And then all of a sudden I have a binary that can run that, that has all the dependencies just built. And, you know, coming from an era where we were trying to run Linux on a desktop, you know, and life sucked, just trying to get a CD to burn of all those. I remember those days quite well running Linux on the desktop. I started with, uh, I started with Gentoo on my desktop and, uh, they had a package manager emerge. And at the time everything was source built. And so installing KDE was like a three day prospect. Um, so that was kind of a nightmare. I learned, I learned how to depend on a package manager. It was just a very, very slow and arduous process to, you know, be able to get all those benefits. And when Mac, when I kind of like made the transition onto using a Mac computer and, you know, Apple released OS 10, which was Unix based, it was very obvious to me that the package manager was missing, right? It was like, oh my God, how do I survive on this system? And I'm sure you've probably heard of Mac ports. And so I used Mac ports in the early days. And for me, like it was very similar to using emerge. It was, you know, get all the sources, build everything locally. And like a lot of the times something was not configured correctly and it would not build and you'd have a terrible time. And so when I finally, uh, I don't know, discovered homebrew for myself, it was, uh, like a total transition, uh, from, you know, using what felt like an incomplete operating system to something that was more like what I expected as a developer. Um, and yeah, just, uh, got into it, got started using it like, uh, pretty much for everything, like, uh, leaning on all that stuff. But like, yeah, like you were saying running, running, uh, running Linux on the desktop was just a different, a different era. Yeah. And I thought it was never going to happen until, uh, Chrome OS, I guess, you know, and then I'm like, Oh, someone finally did those right. So I mean, maybe Ubuntu kind of, but not whatever, no shade. I mean, I feel like, I feel like using Mac OS with homebrew is like a nice middle ground. It's like, you've got all the niceties of a Unix operating system, command line access. You can run everything just like it runs on your Linux boxes and you have a package manager, but you also have a system with drivers that work and you know, displays and network cards that work right out of the box. Yeah. In a pre-rootless, uh, context, I agree. I think the sandbox and the kind of breaking of all the POSIX compliance stuff started to shift that a little bit and make it more of a closed ecosystem, but you can still do anything under the hood, so this week's episode of the Mac happens podcast is brought to you by collide. You've probably heard us talk about collide before, but have you heard that collide was just acquired by one password? That's pretty big news since these two companies are leading the industry in creating security solutions that put users first. For over a year, collide device trust has helped companies with Okta ensure that only known and secure devices can access their data. And that's what they're still doing, but now as a part of one password. So if you've got Okta and you've been meaning to check out collide, Collide now is a great time. Collide comes with a library of pre-built device posture checks, and you can even write your own custom checks for just about anything you can think of. Plus you can use Collide on device without MDM like your Linux fleet, contractor devices, and every BYOD phone and laptop in your company. Now that Collide is part of one password, we're only going to get better. Check out Collide at collide.com/macadminspodcast to learn more and watch the demo today. That's K-O-L-I-D-E.com/macadminspodcast. Thanks to Collide for sponsoring this episode of the Mac admins podcast. So here you are a developer. And I mean, I think from many of the Mac admins that I talked to, they're like, let's try to figure out how to block, you know, CPAN, PIP, BRU, etc. Simply because that's a threat in a large environment where potentially that might be seen as the root of a supply chain attack or something like that. So did you find that Homebrew was getting feature requests or PRs that were sitting there trying to make it more compliant for Mac admins, I guess? Yeah, there's two parts that I think are interesting. So one is the PRs and the other is like the supply chain stuff. And so on the PRs, like, yeah, like this is something we've seen on and off for kind of, I guess probably 10 years, particularly like in the early days, Homebrew was very much geared towards engineers only really used by engineers and like, you know, random end users didn't really have any interest in it. And also, I guess, even like the state of MDM and like actually looking after people's endpoints was less mature and the communities who are more into Homebrew were less likely to be in higher compliance environments like that, right? Like, and yeah, so that there ended up being and still continues to be a bunch of requests of can Homebrew do this? Can Homebrew do that? Like, it would be nice if it was more compliant with the way my organization works. And the issue that Homebrew's kind of experienced is like the volunteers, because it is still a almost exclusively volunteer run project. I guess I'm probably the one exception to that rule at this point. And they don't want to do a lot of that, right? Like again, particularly like enterprise IT compliance, right? Like there's a reason people get paid to do that rather than spending their evenings and weekends, you know, like Charles, you were talking about your Vision Pro and stuff like that, right? There's a reason why you're probably playing with that in your evenings and weekends rather than being like, oh, you know, I would really love to read a SAML white paper this weekend because that's the most exciting part of my life, right? Um, so yeah, so we have this interesting impasse effectively where people who are in the situation of having to manage a fleet of Macs for their day job, like, and they have very real meaningful problems they're experiencing due to Homebrew. And then you have the people who are actually running Homebrew who are like, I don't experience these problems and I'm not particularly inclined to fix these problems, right? Um, so this is, yeah, like, this is the interesting thing that I guess I learned about open source. Like I previously worked at a consulting company back when I was a KDE developer, partly because I was like, hey, they hire more KDE developers than anyone else. Like, this seems like the greatest opportunity, right? Like I can go and work in open source and get paid to do it. Like, isn't that the dream? And then I learned pretty quickly in that job at this consulting company that like, actually the open source work you get paid to do is a lot less fun than the open source work that the volunteers do for fun in their free time, because that's the stuff that like, it's not getting done and someone needs to get it done. So someone pays someone else to get it done, right? Like, and this is a, uh, you know, it's, it's maybe, uh, less of a pitch to work on this stuff, but it is fun, honest. Um, but like, I think that's where we've ended up with this sort of interesting conflict where, because there's no commercial relationships or money passing hands or that incentivization to do this stuff, it ends up not happening. And the last, just to jump on your other point, I think the other interesting thing is like from a supply chain perspective that like, we, we have these words like package managers, right? That mean kind of radically different things depending on the context. So I guess the example is you use like, uh, PyPy or NPM or RubyGems. So the interesting thing with these ecosystems, um, where supply chain attacks are like a, a pretty big problem is because anyone could upload anything at any time, basically. Right. So I can just, no one is essentially vetting my work. If I have a popular package and I want to push a new version, like no one's checking that version before I push it. And no one's checking that that version matches what is on my GitHub or whatever, although there's a little bit of work happening with this stuff now. Whereas in Homebrew's case, it sort of get, often gets conflated with those tools because it feels like it's part of the same ecosystem. But every change that goes into Homebrew, a human looks at that change and says, one of the Homebrew integers, it says, yes, this looks okay. And it gets merged in before it happens. So we have a lot of automation that goes on and we have a lot of external contributions that go on and stuff like that. But ultimately there's 30 people, probably fewer than 30 people in any given repository who have to say, okay, this looks okay. And like that gets checked. And again, those people, yeah. And those people are audited and if they are inactive for too long and they get their permissions get revoked and all this type of stuff. So yeah. So there, there is a higher threshold for this stuff than, than the perspective is, but still, you still have these problems of like, okay, the security supply chain may be less problematic, but the features are not there. The features that we need as Mac admins. I was speaking to somebody who was a Mac admin, um, just the other day and they quoted back to me, you know, there are 17 different tools in my organization that people within the company can use to install other things. Um, all different package managers, whether it's language specific package managers or system, you know, system installers or things like that. And what was interesting about when they quoted me that was that they also said that, you know, in the case of homebrew, homebrew runs on the endpoint and rather than like, you know, in our code base and running on, uh, like RCI devices or in our production deployments or whatnot. And given the fact that homebrew runs on the endpoint, the tool that they lean on the most has been like their MDM or their, um, other kind of endpoint scanning tools to make sure that that stuff is safe. And there's not really a great story for how to do that with homebrew. Every person I've talked to has their own different way that they've kind of like custom built or like, you probably have seen these gists where there's like, you know, a couple hundred lines of scripts that people have been commenting on for the past five years and keep getting reused. So yeah, it's definitely something that people are feeling and talking about. But, um, like Mike said, it's not quite, uh, an interest for the open source maintainers to want to work on. And that's fair. I mean, I think the point about developers writing tool for develop tools for developers and having fun doing it because it solves their specific need. I mean, if I was using homebrew to do a task, to get something ready to deploy to devices that I didn't want homebrew on, then I might just make a package out of what homebrew made by snapshotting the machine before and after, and then deploying whatever changed in the middle. However, if you're working with a large team of developers who are constantly asking for things, you can't keep up by compiling everything they need on their behalf and then going back. So I think that's where something like workbrew kind of comes into play in my mind. Um, but I don't know. So go ahead, Marcus. Before we get into workbrew, I just thought, given that we've got three people who have been involved in homebrew here, we've discussed how many different ways there are of doing things and there's always different opinions. So I thought we thought it'd be great to get you to explain how homebrew works and whether between the three of you, there's a consistent view as to how homebrew works. So like most open source tools, we're going to get three very different opinions as to how homebrew works. So do we want to maybe get down to brass tacks and have you explain for, for some, for somebody who hasn't used homebrew or for somebody who is using homebrew to, to explain from, from a nuts and bolts point of view, how it works? So I think for all, all three of us, it's our, our interactions are all going to be, are going to be quite different from like how we've been involved in the project. So like Mike, you know, he's been involved for 15 years. He's a, you know, the project leader and, and, and does a ton of, you know, every single day I see him working on pull requests and working on features for, for homebrew. But, um, you know, in my experience, I'm more of a user, right? Um, my, my experience with homebrew has been, uh, I set up my machine. I use one of Mike's open source projects called strap, uh, to kind of write a bunch of bootstrapping scripts for my machine, set up my dot files. Homebrew is part of that, install all the packages that I want to have. And maybe here or there, there's a couple of packages that don't exist. So I've contributed packages. And then, uh, you know, maybe there's something that doesn't exist in the brew command. And I've like made one or two contributions to the actual command line tool. And, you know, I'm just a normal user for, for all intents and purposes. Like I just, uh, you know, use it just like a normal developer. Um, I think Vanessa's interaction has also been like quite different. So maybe you want to say, let's talk about that. Yeah, we just got back from FOSDEM. I don't know if you all remember developer conferences. Uh, that was really, that was quite fun. And we also, we also had a chance to attend the homebrew, uh, AGM. What does AGM stand for again, Mike? Annual general meeting. Annual general meeting where they get everyone together. If you're involved with open source projects, you're probably familiar with this drill where you go over the sort of annual business before the people who do the work. And, uh, Mike's been involved with this, as I think he said, for 15 years, he could have a teenager that is his, his, this open source project. Uh, and when we worked together at GitHub, uh, something that he always appreciated, I think about our interactions, he taught me get like over a series of zoom calls. Uh, and that was also, you know, my introduction to the world of, of homebrew and, uh, and Mike's role in it. Uh, and then, but, but he was always like, Vanessa, you just make things go like the, you, you make things happen. And so that's, I felt amazing that he, you know, gifted his time and now he wanted some more of my time back. And so he asked me to run, uh, for the product, for the PLC, uh, product leadership committee, project leadership committee. And now I'm helping, I'm actually on a few different nonprofit boards here in Philadelphia, helping them get their governance, right, get their goals, right, helping the trains run on time. And so now I am doing that as a leader at homebrew. I love it. And then your explanation of how it works, Mike. Well, Mike, Mike might actually be able to talk to you about the actual nuts and bolts of how it works rather than how we're involved in it. Yeah. So, I mean, I guess like there's the technical side and the social side, like, are you interested in, in, in one more than the other or, uh, both? I mean, whatever you want. Um, there is a future question that we can bring forward of like, hey, what's a cask? Yeah, sure. Okay. Well, so I'll, I'll try and touch on that as well. Right. Uh, so like social side, I think I mentioned before, like homebrew is, um, about 30 maintainers right now, um, of people who work mainly in evenings and weekends. Like we, we've got a financial situation such that, I guess I like to call it the open source, uh, curse of having enough money, way too much money for stickers and not enough money to pay any individual really. Yeah. So like we, we've started doing like stipends so we can kind of compensate people a little bit for their work and stuff like that. But I mean, it's, you know, it's one of those things where if you start, particularly those of us who do quite a lot of work on homebrew, if you start trying to add up and do market rates and things like that, um, then it starts to get, I don't know if either of you have, uh, Vanessa has also written a book. I wrote a very boring book about Git about a decade ago. And I remember what a previous boss who talked me into, you know, writing a technical book. I remember he once said, um, don't ever at any point, uh, try and calculate how much time you've spent on it and how much money you make, because it will just make you very, they're not related. It will make you very, very sad. Perhaps an inverse relationship to those two things. Exactly. So it's similar kind of vibes in homebrew where people are doing it for the love, not for the, you know, very small amounts of money they get. Um, we've got a team distributed throughout the world. You know, we've got people in Australia, Shetland islands of Scotland in, you know, basically pretty much every continent in the world, I think, except, you know, Antarctica. And, uh, yeah, like we collaborate mainly over GitHub and a little bit, we've got our private space in Slack and stuff like that. And that team's kind of slowly grown from one person, um, in 2009 to like 30 or so of us. Now it's been like 50 maintainers in total over that time. Then we have a wider group of like about 10,000 people who've contributed at least like one pull request at one point to something in homebrew. Um, in the earlier days of GitHub, like homebrew was like one of the most like forked and contributed to projects. Um, and then we've got, we reckon like tens of millions of users, however, uh, which some of those are, are bots. Um, but you know, bots are just as important as humans to us who are maintainers. So we try and make their lives easy to have feelings too. Exactly. Almost, almost more important in the automation world, right? Yeah. Let's be, let's be kind because eventually they're going to be ruling over us all. So we want to make sure we're, we're kind in the game. That's why I keep telling the kid to be nice to A-L-E-X-A, but yeah. Yeah. So on the technical side, homebrew is built mainly in Ruby. Um, again, that was a language that max liked to work in that was kind of available on Mac OS 10 in the kind of early days. Like nowadays, homebrew ships its own Ruby because the Mac OS version is too old and all that type of stuff. It has smatterings of bash and Swift here and there. And obviously we kind of have to play around with Apple technologies to do stuff like building the PKG installer and all this type of stuff. And then essentially the way most people interact with homebrew most of the time is just installing some software. So to do that, you would type, you know, if you want to install the W get the like open source downloader, you would type brew install W get, and then it will like download the binary package that we, that homebrew kind of architecture is built for you. It would pull it down to your machine, extract it and get it ready to go in like, you know, under a minute basically. Um, so originally homebrew was all built from source on your machine. I guess like John mentioned earlier, like gen two and emerge and stuff like that. And, you know, back in the good old days of Intel max, your, your fans would be like spinning frantically, something like some sort of space shuttle takeoff for a few minutes, uh, while your software was built. And then at the end, everyone would have essentially the same artifact. So it was a huge amount of waste of time, resources, electricity, heating, space shuttle sound effects, et cetera. Um, so eventually we moved, we introduced these things called bottles, which are, um, like binary packages for homebrew, essentially. So pre-compiled stuff that you can download. Um, and the instructions to install the package that kind of would be programmed by people in this nice little Ruby domain specific language were called formula. Um, so formula produced bottles, which were then downloaded. So later on, there was this other project coming to the casks. You mentioned Charles, um, where there was this kind of adjacent project to homebrew called homebrew cask, which thought, Hey, homebrew is nice, but like homebrew is just all installing open source software built from source, whatever. But like, wouldn't it be nice if you could install Google Chrome by doing brew install Google Chrome. Um, so they had their own little command. It was like brew cask install Google Chrome. But I think five or six years ago, um, we sort of, the two projects were merged by a Google summer of code student that kind of worked with us. And yeah. And then nowadays, essentially the interfaces are the same. So you can type just brew install Google dash Chrome, and then that will install Chrome down on your machine and effectively produce the same output as if you'd installed it yourself, download it off the website, double click the installer, click through all the buttons, whatever. Like it's, that's when I guess with the cask stuff world, this is when we're getting a lot more overlap with the kind of Mac admins world, because often we are taking the same pkg files that you might have previously been deploying via your MDM tool of choice. And then we're using those same pkg files and installing them in the same way. So I think there's, this is where they're kind of probably comes the most overlap and the most opportunity for kind of combining efforts, but also I would imagine I've never been a Mac Avenue myself, the most potential cause for frustration that no, they should be, they should really should be getting this pkg file through our way of doing things and not through the Humber way of doing things. Except when you're managing machines that developers use. And then it's like trying to manage machines that graphic artists use and being like, no, we have to install all your Photoshop plugins or, um, video editors and we have to install all your, you know, uh, plugins for the various video editing tools. Like, it's just a nightmare. Are your employees practicing safe SaaS? Find out with nudge security. Their patented approach to SaaS discovery gives you a full inventory of all apps ever introduced by anyone in your org in minutes, no agents, browser plugins, or network proxies required. The best part, you don't even have to know what apps you're looking for. After a quick one-time setup with your email provider, nudge security discovers and categorizes every SaaS and cloud account, giving you a full inventory of who has access to what. You'll see which accounts have MFA enabled, which apps are enrolled in SSO, and an inventory of OAuth grants to help you identify risky scopes and revoke grants if needed. Nudge security also includes playbooks to automate tedious time-consuming tasks like conducting user access reviews, off-boarding employees, orchestrating SSO onboarding, and more. Start a free 14-day trial today at nudgesecurity.com/macadmins. So fonts sort of ended up with the joys of font management tools to overcome that. And I guess that probably then brings us to work brew with the idea of, well, rather than making this go away and saying, all right, no homebrew, which is what we see in some regulated industries, which can make it incredibly frustrating for the developers who are used to working that way, frustrating for the Mac admin, who now has a list of 400,000 items they need to manage and deploy on the endpoint for the users. So, you know, do you want to go through work brew for us and talk about, you know, how you're trying to, you know, make things more organization friendly? Um, so you mentioned fonts, you should check out homebrew fonts. And then the other thing on homebrew that I was going to suggest that Mike might want to mention is brew files, because brew files are a super under, like underutilized feature in homebrew. Um, so I don't know, uh, Mike, if you want to say anything about that at all. Yeah, I guess I could mention that. So brew files, uh, are inspired off this, this package, uh, sorry, this repository that's part of homebrew called homebrew bundle. Um, and that lets you have a command called brew bundle, which runs a brew file that was sort of inspired by like gem files, essentially. Um, for those of you who've kind of played at the Ruby ecosystem, if you haven't, it's, if you're in, in NPM land, if you've played with that, it's like package.json files. If you've not used either of those things, essentially it's a list of packages. So it's a, it's a way of interacting with homebrew and using homebrew, but in a kind of different way. So instead of like manually running a bunch of commands or having a script that runs this command and this command, this command, instead in a brew file, you can say, well, I want these formula. I want these casks. I want say, you know, Postgres if like the database, if you want to have that installed, I also want that to be started up like as like a daemon running in the background. Um, and various things like that, that you can effectively specify. You can also install stuff from the Mac app store and stuff like that. And it basically allows you to specify that in this brew file, like in a declarative format. So you can, instead of like having a script that individually runs a bunch of commands, brew bundle lets you say, okay, just what I want is everything in this file to be set up how I say it will. And you can run brew bundle or brew bundle check to say like, Hey, is everything in place there? And that's a very, very quick operation to do. And then the, this is nice for kind of, I guess, two ways, like John mentioned this project strap I work on. Um, it's my kind of the, probably the only, uh, personal open source project I've ever made that has had any sort of, um, repute, I guess. Um, so what that leans on is using this idea of you have a brew file of everything you want installed on your machine, like a global brew file, we would call it. And then I can say, here's all my formula or my casks or my Mac app store stuff. And then basically, like I want, when I provision a new machine or even just when I'm, you know, doing updates and restoring myself to a consistent state, here's all the stuff I want you to install. And I can kind of commit that file in a repository. That's if you want to go look, I guess we could put it in the show notes. You can see like my brew file in my dot files repository that kind of contains Mike's canonical list of stuff that he has installed in his machine right now. But you can also, and we use this a lot more extensively at GitHub. You could also, if you're kind of working on a bunch of different projects, have like one brew file per project. So you could say, okay, well, this Python project uses Postgres, it needs Python, it needs wget maybe. And then we also have in the same company, a Ruby project that needs this tool and this tool and this tool. And again, there's some overlap with the kind of Mac admin space here, because I'm sure, again, you see this world where when organizations grow and particularly developers are sometimes very pernickety about what stuff is or is not on their machines, right? You don't want to install all of the Ruby stuff for the Python people, and you don't want to install the Python stuff for the Ruby people. So it's kind of nice when you can segment these kind of groups. And like doing that per project or repository with brew files was a nice little way of doing that. And I guess if you can do all that stuff in a declarative fashion, if it's just a JSON file, basically, does that make building the agent for work brew a lot easier? Because now you've got this kind of declarative framework to just plug in and, you know, you send a command with the agent and you say, do that, do a thing. And then all the compilation is done on the client side. And now it's not something you have to go through in too much depth, maybe with a separate work to build or something. Yeah. I mean, the way homebrew works in this way does make things a lot nicer in the work brew space. And I guess you mentioned the work brew agent. So that's a nice, I guess, segue to like the way that we're building work brew. So we have some big ideas for what we're doing in the future. But right now, like the kind of the stuff that we have in private beta essentially is built up of these kind of three components, which combined we kind of call work brew. So one is the installer. So I mentioned earlier, homebrew has its own like PKG installer, which has essentially worked pretty similar to the kind of the download things off the internet package, where the disadvantages are that it needs kind of an internet connection, just like fully set up homebrew along the way. You need to have a user that's already set up on the machine that is being run with and stuff like that. So it kind of knows to put the right stuff in the right place. Whereas the work brew installer is used to set up both homebrew and work brew. And it runs homebrew as like a separate work brew user. And as a result, it doesn't need you to have provisioned any user on the machine already. So I guess that's one advantage from the outset is that if you're doing like a first provisioning of a machine, like all the kind of automated stuff where you, you know, it's integrated based on your serial number and pulls everything down and sets up the machine for the new hire, exactly how you as the Mac admin would like it to be. You can have work brews install and set everything up that way. So like that's, that's, I guess, a nice starting point. And it's also designed such that that installation process, you have a fully working homebrew after then, which doesn't need to immediately then fetch something from the internet. So the work brew installer, as well as installing homebrew, installs this thing we call the work brew agent on the machine. So this kind of provides two roles essentially. So one is, it makes that I mentioned like homebrew is now running as a separate work brew user on the machine. Like my goal is, I guess, from a developer experience perspective is always to kind of try and make things absolutely transparent and seamless as possible. So the agent kind of does some sort of essentially like proxying and managing of, of homebrew such that you can just run brew. It's actually running work brew instead of running homebrew, but it passes everything through and everything looks exactly the same as normal homebrew, except when you install stuff, instead of seeing a little beer mug, you see a little coffee cup now instead. But other than that, it's kind of managing all that. But then it also runs as a daemon in the background, which is basically monitoring what you have installed on your machine. And then periodically it reports that up to what we call the work brew console, which is essentially our cloud centralized like location that's used for kind of managing and reporting that back. So there's kind of two way relationship there between the work brew agent and the work brew console. So the work brew agent is periodically sending information to the console saying, what packages do you have on your machine? What versions are those packages at? So that we then on the work brew console can say, okay, well, Charles has this package installed. It's actually really outdated. And we might happen to know that like this version of this package has a security vulnerability. So we can then go and say, okay, well, Charles needs to update that stat. So previously, like prior to work brew land, that might look like you, if you even had a way of figuring out that Charles had this outdated thing, I've seen some very pretty horrendous scripts that people have had to try and run through their MDM provider to work around the fact that homebrew refuses to be run as root and all this type of stuff to get this information back and try and scrape it out of homebrew's JSON, whereas we provide a nice, easy web interface instead. So you might have at that point, then you then have to have another hacky script that you might've used to then go and try and upgrade something on, on Charles' machine. Whereas because we have this two way agent relationship, you can then just say, okay, just upgrade this from the console on Charles' machine. Tell me when it's done, show me the logs, show me whether it passed or failed. And then you have this kind of ability to essentially just make sure that Charles' homebrew installation is set up the way that we want it to be. It's configured the way we want it to be. It's, we can run the commands that we need to run when we need to run them. And we're kind of able to kind of monitor and make sure that kind of, if there's any old versions or vulnerable versions, or even just software, we don't want to be running on Charles' machine. We can kind of see that. And then you as the Mac admin can then take whatever actions you want to mainly through the Workbook console itself. Love it. Yeah. There's probably plenty of people who think I shouldn't run any software on anything ever again. Including Apple when they shut down your Vision Pro almost immediately. That's what happened, right? Oh yeah. I, I went to do my first spatial capture and it just never recovered. It just stayed. And I think I'm doing a thing, but I'm not. And you reboot and factory, nevermind. Moving on from that. I'm getting over the trauma as we speak, mostly because I have the device back in my grubby hands and I'm compiling code for it again. By the way, physics. Oh my God. Any kid who ever says, I'm never going to use this when they come home from geometry. Yeah, right. You've never tried right. Augmented reality code. But moving on from that. This week's episode of the Mac admins podcast is brought to you by SIT. Hello Mac admins. Let's talk about the backbone of efficient IT operations, understanding how your systems and processes work together. Our sponsor SIT brings you a game changing solution, unified IT infrastructure. Picture this, a world where your IT systems seamlessly connect, empowering you to optimize and streamline operations, ultimately reducing downtime and boosting efficiency. SIT's unified IT infrastructure offers a panoramic asset inventory view, allowing you to track and manage your assets effortlessly. Monitor your SaaS applications with ease and get a comprehensive usage view, ensuring everything runs like a well-oiled machine. But here's the real magic. By integrating your IT infrastructure, SIT provides invaluable insights for internal service improvements. It's like having a crystal clear roadmap for enhancing your IT ecosystem. Ready to unify your IT operations? Dive into SIT. Visit SIT.io. That's S-I-I-T.io to explore how SIT can transform your IT infrastructure. Thanks again to SIT for sponsoring this episode of the Mac admins podcast. So I don't know how you know how many outdated packages I have on my home boxes, but let's talk about policies from the console. So I have a developer who has an outdated version of a formula with a known security vulnerability or something like that. You mentioned that there are certain steps that you can take. I guess, what other restrictions can I apply and what kind of remediations can I put in place, if that makes sense? Because you might not want to just say, oh, and install the latest version of this library or something because it's a developer that might break my bills. I don't know. Consistency is a goal, I guess. So you said something that was really interesting a little bit earlier, which is, you know, developers are special in some kind of way, kind of like how the creative folks are or, you know, the video editors or the people using Adobe's tools. And that's right. Like they do have different needs than the other personas kind of at your company. And something that we've uncovered from talking to lots of different like Mac admins and talking to lots of different developers and also talking to a lot of different security people is that as an organization grows and adds more and more and more endpoints where homebrew is installed, all three of those personas have needs that come up. You know, from the security perspective, it's how do I mitigate the exposure to a critical security vulnerability that was just announced? How do I quickly lock that down? From a developer's perspective, it's, you know, how do I get my machine up and running on the first day of work or when I start working on a new project really quickly without having to deal with some kind of a policy of asking for the ability to install something that I need to do my job? And from the IT person's perspective, it's, you know, how do I make sure that I'm providing a great service, a great level of service to everybody in the company while also like making sure I tick all the boxes, right? And so this is something we spent a lot of time talking about and thinking about. And I think Mike has a really good perspective on this as well, which is that we always want to be, you know, improving the lives of all of these different stakeholders while never, you know, compromising on how the existing, like how users are already accustomed to using homebrew and what they expect out of homebrew. So I just wanted to kind of like get ahead of the conversation you were saying about like policies and whatnot with our philosophy of, you know, how we approach this. And so, you know, there's a lot of different things that we can do to solve the problems that you're trying to solve. And, you know, for example, if something goes out of date, you know, Marcus was saying, but we can't just change the version out from under them, they might be reliant on that, right? So I think that there's definitely different kind of postures that organizations can take, and we want to support the ability for different organizations that have different needs to take a different posture. So maybe, Mike, I think you wanted to continue a little bit more about, you know, the practicality of like how to do some of that stuff. Yeah. So essentially what we have today, like we're, as I mentioned before, we're in private beta and we're kind of working with some kind of customers we have right now, and we're actively looking for more of this sounds interesting to you to kind of collaborate with us as design partners. But basically, like we, an example of a policy that we have right now is the ability to say, and this is in our kind of little demo on our website, say, hey, we don't want to let you install anything with these licenses. So this is something, again, I've kind of heard in Homebrew for a very long time, is that there's some companies that just do not like, say like, HEPL v3, right? It's a license. That's, you know, it's not one of those podcasts where we can unfortunately nerd out on the open source licensing for too long. But the TLDR essentially is that it's a license that is very hard to comply with. And a license where if you accidentally use that in your proprietary software project, like, you're potentially in trouble, right? So some organizations have found it easier to just say, hey, like, we just don't want anyone to install using this license ever, right? So with Workgroup, you can just say that, like, you can configure that essentially for your organization. Like, you say, yeah, just forbid this license. And then when people try and install using that license, it will say, no, sorry, you can't do that. And that, to me, like, that's an example of something where the licenses are relatively, like, minimal enough that AGPL v3 that there's, you know, it's fairly reasonable to just say, okay, well, you just can't do this. But then when you get beyond that, we essentially, we're building out a lot of flexibility here right now. And we haven't, we're essentially figuring out with individual customers what their individual policies want to be. And as John mentioned, that's going to kind of differ. But we're trying to make sure that as we do that, that, like, any policy is essentially, as John mentioned, not stopping people from doing their job, but at the same time, meaning that you can kind of get the compliance needs you want. And the worst case scenario, I think, for everyone, which again, is what we're trying to address, is I'm sure the developers hate it if you just say as an organization, hey, we just ban Homebrew, we just don't let you use this, right? And I'm sure as, like, Mac admins, like, you don't want to be doing that as well, right? Like, that's, I can only imagine that's a sort of last resort that makes you not feel great when you're having to say, hey, people want to use this software, but we just can't let them at all. It's, like, not a good outcome. So to us, like, we're trying to deliver the best we can to both of those groups at the same time, basically. Like, I think we have an offering, even right now, that makes the life's better for IT admins and security people and engineering people. And I've been very determined since day one that we do not build anything that looks like a, you know, crippled version of Homebrew, because that's what's, you know, required. Because ultimately, people won't want to use that. So that doesn't, again, serve the interests of the IT admins or the security people either, because it's, you know, it's not the same as maybe banning Homebrew entirely, but it's not great. So, like, we're building, trying to build something where, right now, we're building essentially Workbrew to have feature parity with Homebrew for an engineer. But as time goes on, we expect Workbrew will be a better version of Homebrew for the engineer as well, and that they would actively rather be using this, and the IT admin would rather be using this, and the security department in your company would rather you be using this as well. So rather than saying we don't allow you to use Homebrew in this organisation, it's like, this is how we implement Homebrew in this organisation. If there's anything that's not giving you what you need on your machine, here's where we put in the internal feature requests or requests for, for things that you need to be able to do on, on your machine. And this is what our, you know, approval process is to get, get those things on your machine. Exactly. Yeah. And for, for an example, I'm sure you've seen engineering teams where when you first, you know, you first set up the project, there's a checklist, maybe there's like, you know, a read me document, it's one or two pages, and it says, first make sure you have brew installed, then install these 15 packages, you know, then make sure you like start these services and do this and that and the other thing. And the kind of like better world for the engineer is that stuff's just automated. It just works. And the better world for the IT administrator is that stuff's always up to date and working with, you know, the code bases that they're working on. And if there's a security vulnerability, you know, the security team gets a notice and you know how many endpoints are affected, who hasn't updated yet, you can nag them, or you can, for example, you know, I had a customer that I spoke to that rather than enforcing the policy of blocking something from happening on their machine, or stopping them from installing something, or even updating software for them, instead, their preference is to send out an alert to that end user and say, hey, you're on X version, you need to be on Y version as soon as possible. If it's not done within 48 hours, you'll be blocked from our VPN, right? And so that's like a different kind of enforcement mechanism than saying, you just can't do this thing. Instead, it's like, hey, this is very important. As an organization, we take security very seriously. We take our, you know, compliance very seriously. Please do the things that you need to do to have good practices. And if you don't, it's not that you're not going to be able to access your machine, but you're not going to be able to access production. You're not going to be able to access any of these machines that have highly sensitive information on them. Um, because that's, you know, and they give you the out, you know, they give you the out upfront to say, please fix this now. So something you mentioned just then, which, which really resonated with me is the idea of sort of automating that configuration and setup of developer machines. There's been so many scenarios where I've been working with organizations, they're going from hand-built machines to using MDM for zero touch enrollment, and everything's great until we get to the developers. And then I get handed that read me file you mentioned there, and they're going, oh, can you automate this to build it? So, you know, it's quite often a set of seemingly manual processes, although they may be leveraging some automation tools. So you go through and build out orchestration for that to be able to be automatically set up on the machine. And then you go and get them to start testing it. And they're like, oh, that's out of date. Um, that was what, that was what it was two weeks ago when we gave you that file. Now it's something else. And you go through and update it and then find that it's changed again. So this idea of being able to decouple the building and configuration and securing of the machine in general from the setting up of that developer environment with things specific for that even team. Because that's also when you discover that, great, that read me file was only for this team here. They forgot to tell you that, you know, because it's all about them. And then there's the team next door that doesn't have a read me file. They use a whole other different way of provisioning their team. So that way to be able to get that granular configuration and, you know, have that managed and updated by people who have that deep knowledge of what those particular teams need in conjunction with security, operations, those sorts of things is, you know, a really exciting prospect for those of us who have tried to make that a better experience with tools that maybe weren't designed properly around that. I've heard this story a bunch of times in talking to different like IT admins, Mac admins, and the story of my zero touch deployment doesn't work with Homebrew is like super common. Like you have to have the account already set up. You can't do it during, you know, the enrollment phase. You have to wait until it's done, which leads to that manual, which is five pages of steps that you have to do manually. Now with Workbrew, our goal is to say zero touch deployment is totally possible. You get Workbrew installed, the agents there, and then imagine you have an engineering team, or you have five different engineering teams, and they have certain dependencies that they need installed. They can self-manage that via Workbrew for the entire team. So, for example, a, you know, a lead engineer on a project might say, "What we need in this situation is different than it used to be last week." And they go and they make the change, and then that's shared out automatically with everybody on their team, right? This is definitely something that's possible, you know, for us in the future. Right now, our main focus area is like on the Mac admins needs. So not serve the Mac admins needs without, you know, hurting the experience for the other folks involved. And then kind of as we continue down this path, it's things like we were just talking about, like helping with better development environment set up and, you know, doing different things around security, vulnerability scanning, or CVE detection, or detection and remediation and things like that. So yeah, definitely. Yeah. Correct me if I'm wrong. I can get, because I think I've done this, a dump of all the licenses used from stuff that's been installed by Homebrew on a machine, right? That's a thing. Yeah. So you've already got all that in JSON, and you've got this declarative environment. And so now you can just build a policy engine by doing a little regex on those things. And so if people have other policies they want, then that's just a matter of, let's do some more of that. And, or let's build a framework where you can just insert your own fields and allow for, you know, globbing or whatever in there. Right? Well, yeah. And of course, this is the beauty of the relationship we have as well, in that building some of these features, like you mentioned, like what's in the JSON and what's not. And this is all, you know, publicly exposed stuff where in theory, Charles, you could, you know, just bang out your own script to do a similar thing to the workroom console does or whatever. But I guess what we've been finding, I guess, I don't know how Charles and Marcus and John and Vanessa are going to groan because they've heard this, me make this metaphor about a billion times at this point. But, uh, like how much you've played with like modern Lego. Right. Whereas when I was younger, it felt like Lego was a lot more kind of modular and there was like, you know, like a bunch of different bricks, a bunch of different components. You bought a thing and you could like rebuild it in different ways. But like the Lego my six year old plays with essentially has two worlds, right? It either has the, you go to the Lego store and you buy a box of like 500 bricks and then you just build those bricks into whatever monstrosity you want. Or there's like the hyper customized, like this is a Velociraptor. And this is the only piece of Lego that has this particular Velociraptor claw or whatever. And I guess like I see what we're doing with work for the open source project in some ways, um, as being comparable, I guess we've already banged on the Linux desktop here a little bit. So I'll, I'll bring out my favorite Linux desktop quote, which was, uh, Linux on the desktop is only free if your time is worth nothing. Um, I remember that from back in the day. And there's a similar one here. I think where like, yeah, I mean, sure. Like in your organization, could you build all this from scratch using the open source project and all the open data that's available? Like, yeah. Yeah. And I also hope your time is worth nothing because that's going to take you forever. And you're going to have to kind of, you know, you probably don't have the level of expertise with the open source project to be able to do that. Whereas even while we've been building work brew, this is the nice kind of collaborative aspect I have for my CTO hat. And my project leader hat is, you know, there's some stuff sometimes where we're like, Oh, to solve this policy problem, we need to have more stuff in the JSON that homebrew outputs. And it's like, well, I can then just make a PR to homebrew and then say, Hey, other homebrew maintainers, does it seem reasonable that we had this JSON field? And they were like, sure, let's add this in. Right. But it's like, but are, you know, in your organization, are you going to do that? Are you going to have the confidence and know how to do that? Whatever. Like, maybe, like maybe. Yeah. I wouldn't want to do that, but I also wouldn't want to maintain my own separate agent. If I can pay someone else to have that sovereign agent and console provided that they're SOC 2 compliant or whatever other things that, that I need my organization to comply with, you know, so. Also brings in the concept that I love Rich Troughton's term of this, the lottery bus, rather than saying someone getting hit by a bus, they get hit by the lottery bus. So you have that person in your organization who would love nothing more than to spend that time building out all of that information. And I've been in this position before where somebody has moved on to another role or they've won the lottery or whatever, and then you're presented with their code. And it's like, this is your job to maintain this and you're reading it and going, I'm not smart enough to be able to do this. And I don't have the patience to become smart enough to be able to do this. So, you know, having an organization that is going to be looking after that for you so that you're not at risk of either having someone who can't move on to more productive things to be doing with their time or that person no longer being there and then being caught between a rock and a hard place. Totally. So let's talk security. So have you put anything into Workbrew to try and make it more secure than regular Homebrew to give that functionality to the organizations that are using it? Was there anything you've found that was missing in Homebrew? Yeah, so I mean, the biggest thing, as I mentioned before, is like that Workbrew is run by it in its own separate user. And so, you know, as I said, Homebrew relies a certain amount on the macOS sandbox and stuff like that. But there's a degree of just separation there, which is essentially that this stuff is not we've never seen a lot of stuff exploited out there in the wild. But there's ways in which the Homebrew security model had a certain degree of trust of the code being run as the same user, which we wanted to go a step beyond that with Workbrew. It serves two purposes in some ways where both you have the multi-user system perspective, you have the ability to kind of provision that Workbrew user on boot before the user may have even chosen their username. But you also have the separation of saying Workbrew is running over here in its own little user and it's not able to just like read and write arbitrary files from, you know, my documents folder or my iCloud library or whatever it may be. And that that that separation is a little bit more clean and better. And as I said, that that's the one like the way it actually works that we consider to be more secure. But then there's also just the kind of the increased security posture of in Homebrew, for example, like you can disable auto updates. And then if you say, hey, which packages are outdated that relies on your like local essentially store of which packages are up to date and not up to date being itself up to date. So you can end up in slightly confusing user configurations where it's like, hey, well, we have Homebrew says all my packages are up to date and there's nothing to worry about. But actually, we know in Workbrew land that like because we pull directly from Homebrew sources itself that like, OK, well, you say that version one point two is the newest on your machine. But we know one point three was already released and we know that there's a critical vulnerability or whatever. So like we know that not only do you need to upgrade that package, but you also need to upgrade your like definitions on that machine of what the packages are. So essentially, we have a lower level of trust in the data on any given machine and instead like a centralized approach where we can tell like what's outdated and what's not. No, I'd also add to that that the security posture of an organization is different than the security posture of an individual. And from organization to organization, that's also different. So I don't really think about it as how is Workbrew more secure than Homebrew. It's when you use Homebrew at work, how are the security needs different than they are for an individual user? And how can we make sure that we're serving them correctly? And depending on the organization, that posture can look very different. So I talked to some companies where the head of security is like, we really trust our engineers. We never want to be blocking for them. We give them root access on their machines. We teach them how to do things in a secure way and we rely on them to report and have auditing and things like that. And then there are other places maybe in a highly regulated industry. Let's say, for example, a financial institution where they, by regulation, cannot just give the keys to the castle to their developers. Things have to be super tight and locked down. And so our position is to make those different security postures viable depending on what the organization needs. And most of those challenges arise not just out of using Homebrew, but using Homebrew across many endpoints at the same time and having to have compliance and security across all of the endpoints. Having one machine that's got three pieces of vulnerable software is one thing, but having a thousand machines where only one of them has three pieces of software that are vulnerable is a whole different story from a risk perspective. And having that visibility over the machines to not just assume everybody is at the same degree of vulnerability and to be able to then make decisions on how much effort are we going to put in? Is this something where we need to spin up a task force to track and resolve this? Or do we just need to send someone a Slack message and say, can you please connect your machine to the internet so we can actually make sure it's up to date? And, oh, that's right. That person's actually on leave and their machine's off in a cupboard. So that's the mitigation of the risk. So we're going to be able to know what's going on there. Another mitigation, I guess, is integration with MDM or other DevSecOps, DevOps, InfoSec, whatever other acronym or shortened term we can insert here for all the people who love those. But working with MDM providers, I would say, is part of that. So if the world is just an endpoint with a whole bunch of more JSON or XML away, how are you all thinking about working with MDM providers or any of those other types of tools that we mentioned? Yeah, so we're building the workflow console, particularly to be kind of pretty tightly integrated with MDM providers and SSO providers as well, because that's obviously the two seem to go hand in hand at this point. In terms of specific companies, I don't want to mention who we're picking first. But essentially, if you were to list the top five MDM providers, we're actively building for one or two of them right now. And we essentially will, within the year, I would imagine, build support for essentially everyone. But yeah, again, this is what we're actively kind of working with our design partners are like early private beta customers on is we're prioritizing the MDM solutions that they use. And if you're chomping at the bit to get involved with Homebrew and you really, really want to see your MDM solution built sooner rather than later, then that would be a good reason for you to reach out to us. And we will do that. Yeah, and I think that the strategy here is that as a company, we know that there are a lot of different tools that the different personas involved in this space are using. And to start, our main area of focus is eliminating the needs to do custom things for Homebrew across your fleet. So that might be you have a vulnerability scanner. How do you make sure that vulnerability scanner is scanning all the packages installed by Homebrew? Well, use Workbrew. You have an MDM tool that you use for zero-touch deployment and you want to deploy Homebrew and that doesn't work? Use Workbrew. You know, you have some kind of engineering productivity tool that helps engineers get up to speed faster. Like we want to integrate with that with Workbrew, right? Like every different, you know, touch point in the organization, we want to make sure that there's an easy story for, you know, how to make your life easier without having to write your own glue code, without having to, you know, go and depend on some gist that someone else put together and it just works. So something that's, you know, my brain started spinning around thinking of all the possibilities here and usually when we're trying to build automation and build security and consistency, I like to put myself in the hands of the user and go, all right, well, what's the user going to try and do here that may break this? So one of the things that came to mind is what happens if you're running Workbrew and you've got an engineer that's got, you know, the ability to install software and they go and install Homebrew on their machine? What happens if you try and run the two of them together? Well, so essentially the two of them are run together right now. That's, I guess there's two parts to this. So one is if Workbrew uses Homebrew in the default location. So Homebrew essentially insists on being owned by your typically like your kind of admin user on the machine that's running. So mic user on my machine. So essentially the only difference in Workbrew land is that there's still Homebrew, the open source project, but it's now owned by the Workbrew user instead of the mic user. And then when I run brew, it's running Workbrew, which then just passes through to that Workbrew user essentially like and nicely handles all the permissions there. But the other part of that, I guess, with what you mentioned is, well, what if, because you can technically install Homebrew anywhere. So what if that user was to go and install some random version of Homebrew somewhere random on their machine? So that's something, again, that we've kind of built into Homebrew. It's kind of not really enforceable in Homebrew without Workbrew, but we now have the ability to kind of set some of these policies at like a system wide level. So if you install any Homebrew anywhere in the system, you can set this policy and effectively restrict any Homebrew installation that any user has installed and not just a one specific installation that the user has manually configured as per your organization readme or whatever, like we might have mentioned earlier. It's like you've come across this problem before. So a related question that I've heard people ask is the other way around. What happens if you install Workbrew, but they already have Homebrew installed? So we often talk about this idea of like zero touch deployment and provisioning the machines. But also you have, you know, 1500 machines out in production right now with Homebrew installed on them, and each one of them has 100 packages installed via Homebrew. What happens when you do the deployment? Well, what's great about it is with the Workbrew installer, it effectively just upgrades their permissions to the point where it's under a Workbrew user, but all of their installed packages continue to work. All of their installed, like it's as if it had been Workbrew from day one. Awesome. No, that's, that's fantastic. So let's talk about the future a little bit. So since you're building on top of Homebrew and actively involved as possible, how are you thinking about the Workbrew relationship with the open source project ongoing? So we basically tried to make sure that we have extremely high levels of trust for the open source project from the early stages, essentially. So before we even kind of make Workbrew the company, I reached out to a bunch of Homebrew maintainers and the kind of folks on leadership there and said like, hey, we're going to tell you a bunch of stuff or we tell our potential customers, like, and we're going to trust you to like, do us the right thing and not immediately screenshot this and put this on the internet. And if you do that, then we're going to be able to have a long, nice, very trustworthy relationship. And so far that that approach, I think, from both sides has gone really well. Like, so we, through extending that trust, and I guess through some of the people in our community seeing other projects that have not extended that trust and it's gone badly, we've kind of built a really nice culture where we are able to kind of have very frank and open discussions with the Homebrew maintainers in more private spaces, because both parties can be franker in those situations. But we also have a nice kind of situation now where we have people like Vanessa, who's deeply involved with Workbrew, but also has recently been elected to the Homebrew PLC. So that's kind of partly an acknowledgement as well that like, there's a kind of growing relationship between these two organizations. And also I think just the fairly strict separation we've gone for with the naming and stuff like that. Like we're not selling Homebrew enterprise or whatever, right? We're selling a separate product that is called Workbrew that is very heavily integrated with and commercializing some of the ecosystem around Homebrew, but not Homebrew itself. We're not trying to take Homebrew and saying, you know, you need to pay money for this or whatever. And also, I guess like our plan from day one, and I stand by this, and this is one of the reasons why I'm so excited about Workbrew is that in five or 10 years, if you've never heard of Workbrew, which if we are successful, like we would like to be, that will hopefully be unlikely. But if you work in tech, you love Homebrew, you never hear of Workbrew, you will look back at like this sort of time as an inflection point in which Homebrew gets way better for everyone in the next kind of five or 10 years, right? And I think that is enabled by a lot of things. You mentioned the relationship with the open source project, like Homebrew has its own governance structures in place. Homebrew has elections. It has its own bank accounts through Open Collective. It has all these kind of policies on how the project is run. It has like essentially this kind of really quite mature governing nonprofit structure at this point. So the nice thing about that is both parties are kind of protected through that. So Workbrew has had to be set up as an external organization of its own thing because we couldn't just hijack Homebrew even though we wanted to, which we wouldn't and didn't. But it also means that the open source project kind of has the ability to decide how it wants to kind of have its relationship with Workbrew and how we're going to grow that with time. But essentially, like, you know, my view with this stuff is it's natural with various things where people have seen this stuff maybe go wrong in the past with open source software and companies. It's natural for people to maybe be a little bit afraid or a little bit suspicious on both ends. But if trust is something I believe is like earned rather than just given. And I think we have earned a lot of trust from the open source community already around Homebrew. And we continue to prioritize earning that trust and building that and showing that we are the best possible people to be doing this with the community and with our customers. I've seen it go right plenty, especially when you have a motif. Let's call it a motif. I'm not sure what other better word to use where Homebrew has like this beer iconography and Workbrew has this coffee iconography. I mean, you couldn't have made this up. You literally did make it up. But I love that kind of symmetry between this, like, coffee's for work, beers for home. You know, that works very well for me in my head. So you mentioned beta. What can we expect from Workbrew in the coming weeks and months? So I mentioned before we're in private beta right now. So what essentially that means is we're working with a small group of companies we call design partners. So essentially they are people who are coming on board with the expectation that Workbrew is not done yet. We're not 1.0. We're not public. And so they're kind of working with us to provide lots of feedback for us while we build something that is more in keeping with our needs. And maybe, you know, if we had a roadmap of things, if they say this thing which is on your roadmap is really, really important to us. And we really want this ASAP, then we look at our roadmap and we adjust it according to their needs. So if that's something that interests anyone listening to this, then please come and talk to us about that at workbrew.com/macadmins. That's the best way to kind of reach out to us there. But we're expecting if that, you know, if you want to kind of wait and see a little bit more, we're expecting that we will have a public beta or maybe even a full public launch at some point later in this year. And you can kind of follow along. We'll be kind of making sure that we kind of announce and keep people posted in our various kind of internet profiles and in the Mac admins community on Slack as well. We've been kind of keeping people up to date in there because we've got a Workbrew channel in there in which people seem to be quite interested. And yeah, and also if you fancy going in there at any time and just, you know, at mentioning me or John or Vanessa and asking us random questions about Workbrew, then that's a good place to do that as well. Thank you all so much for coming on, talking about what you're working on, talking about private betas. I'm in one right now with some software I'm working on. It can be incredibly infuriating when you don't know exactly what you're allowed to say or don't want to over promise for the future or any of that. So thank you so much. And also thank you for the background on all the homebrew stuff and the contributions to all the homebrew stuff, because that has been incredibly useful to me over the years. I mean, I went from spending sometimes a day or two to get some of these packages installed, like Libi mobile device, I think was an early one that I used homebrew and I got it done in like five minutes. Like, oh, my God, I just got a whole day's worth of work done in like five minutes. That's crazy. So thank you for all of that. We just want to say a huge thank you to all of our wonderful Patreon backers who make sure that these episodes go out every week. Weldon Dodd, thank you. William Smith, thank you. Justin Holt, thank you. Daniel McLaughlin, thank you. Chad Swarthout, thank you. Tim Sutton, thank you. Steven Weinstein, thank you. Command Control Power, thanks, guys. Sebastian Nash, thank you. Will O'Neill, thank you. Joe Sfara, Nate Sinall, thank you. Tobias Linder from AnyKey, Adam Berg, Hamlin Crewson, Stu McDonald, Jeffrey Compton, Anoush Dorville from Advisory, thank you. Bill Stites, thank you. Melvin Vives, thank you. Mike Boylan, Rick Goody, Michael Tsai, thank you. Adam Selby, Dwayne Moss, Pax, Julian Reddick, and Tim Camps. Thank you all so much for your wonderful sponsorship of the Mac Admins Podcast. We happen to have a bonus question. So, Marcus, do you want to ask it, or do you want me? Yeah, I'll ask the bonus question. So, what's the silliest thing you've ever had to write a package for? So, we can have some time to think. But does anyone want to go first? Yeah, I'll start. It's a sort of slight dodge of the question in that it's technically an error message. But if you type brew install updog into homebrew, then it implies error what's updog. So, there's actually a specific code to handle that particular case that was reviewed and approved, I believe, by myself and some other people back in the day. That's awesome. And I'm guessing that got reviewed very quickly. Oh, yeah. That was a must-have feature. Definitely a feature. I don't know if it's silly, but most of the packages, like the silly packages that I've contributed, are probably against homebrew's policy. Because similar to Wikipedia, I think there's a policy that says, like, on Wikipedia, don't edit your own Wikipedia page. And on homebrew, it's like, don't publish your own packages. So, I have, like, a handful of desktop apps that I built with Electron over the years that I've, like, sent PRs to, you know, homebrew Cask. Maybe it was before Cask was merged into Brew and maybe they didn't have that policy. I'm going to go with that. But, yeah, I've done a handful of different desktop apps that I've written and distributed through homebrew in that way. Love it. And I don't think I've written a package, but I think that means Mike is going to make me in the coming days. Fair enough. How about you, Marcus? You've got to have something good. You used to. Yeah. Oh, no, I've done dreadful things. You know, there was the silly one. There was the getting, which I'm sure as people developing or working with developers, the security in air quotes software that usually slows everything down to the point where developers can't work. So we decided to create a piece of software that would, which was really just a package that would massively automate that process. So it was just a launch demon that shut the machine down, which gave the same experience of running those kind of security tools without having to wait for it to kernel panic and shut down. I just did it straight away. But the worst package I've had to write or the silliest package I've had to write because of choices that a developer made was for some USB microscope software that required licensing, despite the fact you needed this expensive microscope to be able to use the software. And the developer was applying the license file in ways that I could not work out how to automate. So, you know, the process we normally find where you can just, you know, dump a license file somewhere in the operating system and it will detect it or you can work out what that license file is after you manually write it and put it in there. I could not work out what they were doing here. And so in the end, I created a package that would open up a text file with that license key in it, open up the licensing window and a prompt to tell the user copy and paste this into there and then clean it up and walk away and solve the next problem. I mean, it's a lot faster than installing Selenium and then using Selenium or something like that. Exactly. And the other thing that made me laugh was this was also not a license file that updated every year or anything like that. So I'm guessing that school is potentially still using the package I created, which scares me on a whole other level. But what about you, Charles? What's the silliest thing you've written a package for? Um, I would say, uh, to disable natural scrolling or to, uh, remember when Apple switched from you scroll up to you scroll down, you know, trying to mirror the way the iPhone worked. Um, I, I was, uh, a Luddite, uh, and I refused to scroll the opposite direction, uh, for a few years. I have since corrected the error of my voice. So my friends at Apple cannot scoff at me, but I was slow to adopt the new modality. So I, I literally used one of my colleagues machines last week and they had it set to the old slash incorrect way of scrolling. And, and, and I judged them. I judged them. I judged them as a result of that. Just, just turn your magic trackpad upside down and then. Exactly. Or if you're not using a magic trackpad, just turn the computer upside down and do it that way. Love it. Well, thank you so much for, for joining us here on the podcast. We're, we're really, um, excited with what you're creating and can't wait to see it where it gets to and what sort of, um, things you're going to be able to do to make life a lot easier, not just for Mac admins, but for developers wanting to be able to get that functionality of homebrew in their organization. So if people want to hear more about what you're doing, where can they find you on the internet? The best, the best place to find us is workbrew.com. And for folks listening to this podcast, head to workbrew.com slash Mac admins, where we'll have a bunch of additional information specifically for this audience. Awesome. And we'll put that link in the show notes. Uh, thank you to our sponsors. Sorry, James, I'll get you to put the latest sponsor list in here. With your dulcet tones. Yes. Thanks to our sponsors this week. That's Kanji, Collide, Sit, Nudge Security, and our awesome Patreon backers. And we'll see you next time. See you next time. The Mac admins podcast is a production of Mac admins podcast, LLC. Our producer is Tom Bridge. Our sound editor and mixing engineer is James Smith. Our theme music was produced by Adam Kudiga the first time he opened GarageBand. Sponsorship for the Mac admins podcast is provided by the macadmins.org Slack, where you can join thousands of Mac admins in a free Slack instance. Visit macadmins.org. And also by Technolutionary LLC. Technically, we can help. For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org. Since we've converted this podcast to APFS, the funny metadata joke is at the end.

hey welcome back to another episode of the ruby rogues podcast this week i'm talking to mike mcquade mike is one of the maintainers of homebrew uh if you have a mac you know and if you don't have a mac then we'll we'll get into what it is but yeah cool stuff uh calling in from scotland is that what you said yep edinburgh and scotland very cool um i have some scottish in me i have a whole bunch of other european countries in me too but anyway uh do you want to just jump in and let us know what else people ought to know about you before we get rolling hey folks this is charles maxwood i've been talking to a whole bunch of people that want to update their resume and find a better job and i figure well why not just share my resume so you if you go to topendevs.com slash resume enter your name and email address then you'll get a copy of the resume that i use that i've used through freelancing through most of my career as i've kind of refined it and tweaked it to get me the jobs that i want uh like i said topendevs.com slash resume will get you that and you can just kind of use the formatting it comes in word and pages formats and you can just fill it in from there sure so yeah as uh charles honestly said i'm mike mcquade uh he said my name perfectly which is not always something you can rely on which is very nice and so i'm currently working on uh homebrew in my you know volunteer life spare time sort of stuff worked on it for 15 years since 2009 2009 i got involved i think i was the third person to get a commit bit on the project and i'm oh wow i'm still standing after that time and i'm like the project leader which basically means i'm sort of an elected like figurehead slash tech lead etc um so yeah so in my kind of outside of my homebrew life work-wise and i'm working right now started a company last year with some ex-github people called workbrew where we're working on commercializing some stuff around homebrew and basically building the features that kind of small medium large companies need that homebrew does not have so that they can work in the way they want to work while homebrew plays nicely with that and then before i was working here i worked at github for 10 years and i left as like a principal engineer last year and i was bounced all over the place there but particularly i guess focused on like developer experience stuff and open source and scratching my own itches basically very cool yeah i've uh known a few people who've worked at uh github i also remember way back in the day when chris and tom put their heads together and started the thing as kind of a project in a restaurant or something and yeah it's kind of funny to look at where it all wound up with microsoft buy in them and everything else um let's just kind of start with the fundamentals here i did kind of mention that if you have a mac you probably know what homebrew is but do you want to people a rundown of what it is sure so homebrew is a open source package manager for mac os primarily and also increasingly linux as well interestingly oh really could talk a little bit more about that later because that's sometimes confusing to particularly mac people um but yeah so basically if you you write brew which is the kind of shorthand brew install and then pretty much any application you would want and you can install that on your mac um so it's i believe i then kind of we have some degree of evidence that you know about 30 million people and or bots make use of homebrew and it's yeah in our opinion like the best way of installing open source software on your mac well you may not know as well with homebrew it started off just being like a building everything from source package manager for like open source tools wget curl whatever whereas nowadays you can also install like upstream binaries so like say like chrome which i i'm a diehard safari guy so i'm streaming in chrome today because i had my usual sadness of learning the website didn't support safari so i fired up chrome but i i install chrome by just typing brew install google chrome and then it sticks everything in my applications folder sets it all up and and all that type of things and there's a long tail of like ecosystems where you can have like brew bundle is another favorite of mine where you can have like declarative ways of telling homebrew what to do and all this type of stuff so yeah that's basically and my uh my non-tech explanation of homebrew is like a app store for open source in your terminal right yeah you just brew install whatever you want and off it runs and does its thing in fact a lot of tutorials if you need a particular piece of the puzzle a lot of the gems and things that i use in ruby it'll it'll basically say go brew install your blah blah blah right and then and then you can run from there so yeah it's definitely something that i use and i reach for and i don't even think anymore that oh gee somebody actually made this right it's just part of life so anyway um so yeah so i'm kind of curious uh as we kind of get into this a little bit and there's a lot to talk about right because i do want to get into workbrew and what what that's all about but um before we do that uh for those of us who have used homebrew for a long time and are excited to see um you know maybe where it came from and what all is entailed in it um where did it come from you said you weren't in it from necessarily the beginning but you got to commit yeah pretty early so yeah what's the story there i think i got involved about you know maybe started using it four or five months and started contributing pretty short after when it was first created it was made in 2009 by a guy called max howell uh who was in london i think he was working at last fm at the time it's a blast from the past that probably still exists but not as widely used as it once was um so he had i have kids younger than homebrew yeah i'm sure yeah i i also have kids younger than homebrew it's and it's distressing when you meet kids who are the same age as homebrew and how articulate that they are um so he basically had played around with all the package managers on the mac at the time you know there's mac ports and think and uh oh yeah i remember those yeah i can't remember what the other one was um but yeah yeah mac ports is probably the dominant one um and he didn't have a huge amount of like good time using mac ports felt that it kind of did too much and he didn't like the approach so he built homebrew which was this kind of beer themed package manager um and yeah and the other still called casks yeah the packages are still called like formulae and casks and it still got all the the beer themes all over the place but one of the interesting things he did as well is it was you know this was i can't remember you probably know charles actually what year github opened to the public but certainly this was in 2009 so github was like relatively new i'm pretty sure when homebrew first got created the pull request didn't exist yet and but max from the outset had decided like hey i want to make this thing but i can't maintain thousands of packages all by myself so i'm going to have to kind of open this up and make it a community effort to do that and so yeah so that's basically what happened and more and more people kind of particularly in the ruby community like i think the ruby community was one of the early adopters of homebrew because homebrew itself was written and it still is primarily within ruby and uh yeah basically just it kind of grew more people got involved more people contributed and then you know people who contributed lots and end up doing a bunch of reviews and stuff like that i guess folks like me ended up kind of becoming maintainers and then the projects just sort of grown and grown over the time so yeah it went from originally like just max in 2009 to nowadays we've got i think 30 something maintainers we probably had like wow 50 total all time and then we've had like over 10 000 people contribute to some part of the project at least once very cool so i have so many questions um so one of them is is there there are kind of a bunch of different pieces to this right you've got the command line interface and then you've got the hey go grab the thing and how do i know how to build the thing and how do i know where to put the thing and how right and so um let's just start with the command line interface so um what what tools did you start out working with and and has that changed over the last what 13 14 years yeah yeah so homebrew was written originally exclusively in ruby pretty much um and it's still primarily ruby like uh the the irony in homebrew land compared to maybe other bits of ruby where because we're like a cli and because we're we are installing a bunch of stuff related to compilers and things but we can't rely on them necessarily being there and we haven't wanted to ship native binaries for the application itself when we want to make things faster in homebrew often they are ported from ruby to bash so an increasing amount of wow they're kind of very performance intensive bits of homebrew like the bits where like you want to be able to run a command and have a response instantly or you want to be able to have a command that you can run every time you open your shell and then not have too much overhead so some of that more of that stuff is kind of ported to like bash and like the updaters and bash and because homebrew installs its own ruby nowadays because the you know we originally used just the whatever ruby ship with mac os and that worked all right for a pretty long time but i think last year we were speaking to our kind of apple contacts and they'd theoretically deprecated ruby i think a few years ago in the system and we said hey can we get a newer one i think it's still there it is still there but it's a 2.6 yeah i was gonna say it's not a current version yeah pretty ancient and so yeah so we we ended up we we were rolling our own for really old mac os versions and for linux anyway so we just like well we can roll our own for for everyone now and just make it mandatory right and i think it's ruby 3.1 or 2 or something like that uh-huh nowadays and yeah and that's a much nicer experience for us and makes everything a bit faster and snappier and stuff so yeah so the main package manager is all in ruby and then we have i guess two main repositories so there's like homebrew brew we would call it which is like yard.com slash homebrew slash brew that's the package manager and that's like that's my personal like favorite happy place to live and i kind of review pretty much every pr that is in that repo and and then there's like homebrew slash homebrew core and so that's like the core formula like basically everything in there has to be open source and there's like 6 000 packages or whatever in there and that again is i think one of the reasons why ruby was such a good pick originally like is that the like the the files that kind of describe how to install something or known as formula and and again going down the beer theme and that it's like a really nice ruby dsl that kind of is i would say fairly if you're if you kind of have a basic understanding of almost like you know configure make make install like how unix programs are generally built like it's you can read through that and it's pretty obvious how to get started and if you've ever had the this episode is brought to you by spreaker the platform responsible for a rapidly spreading condition known as podcast brain symptoms include buying microphones you don't need explaining rss feeds to confused relatives and saying things like sorry i can't talk right now i'm editing audio if this sounds familiar you're probably already a podcaster the good news is spreaker makes the whole process simple you record your show upload it once and spreaker distributes it everywhere people listen apple podcasts spotify and about a dozen apps your cousin swears are the next big thing even better spreaker helps you monetize your show with ads meaning your podcast might someday pay for well more microphones start your show today at spreaker.com spreaker because if you're going to talk to yourself for an hour you might as well publish it uh misfortune of having to try and package like rpms or like debian packages or whatever which are very very robust arguably better than homebrew once they're there but like the actual just process of going from nothing to something that works is very time consuming in my experience um whereas in homebrew you can just uh you know like make a fairly short little thing and then have yourself up and running installing applications in a pretty quick time and and i think that's why it's grown and stayed big because it's quite easy for people to contribute and modify and change things and it's just you know you can do it all on github nowadays right so when i was in college i w i was a systems administrator on mostly red hat systems and so i've i've written some fugly bash scripts to do all kinds of things and and i've also done rpm packaging and you know later on i yeah there are a few things that i've had to fiddle with and maybe put into a debian package and yeah that is not a fun process and then you just kind of have to put it out there and then pull it in with your package manager or with some utility that can pull it in and unpack it and do whatever it does and oh man yeah homebrew's pretty nice that way uh also done plenty of stuff with make which is it's a powerful utility but it's a little arcane sometimes and so yeah i i definitely feel you there so um um yeah so it's all written in ruby is it pretty is it pretty simple or there are a lot of edge cases you have to handle or is that mostly in the packages or the formula or whatever yeah a bit of both like i mean there's i think with with stuff like homebrew is like a really long tail so i guess with the stuff that max created in the first place um you know i can't remember how many packages he's almost like shipped with to begin with but um it's one of those things where if you have a hundred packages everything seems pretty simple if you have a thousand things start to get a bit more complex and then when you start getting up to like five six thousand it's like it gets really messy all the weird and wonderful things that things do and as a packager of software you have this kind of weird decision framework where there's often the way the the people who write their software originally i guess we would refer to them as upstream and the way they want to release their software is not necessarily the way your users want to consume the software or the way you want to be keeping it up to date and stuff so you're trying to sort of balance these things and yeah i mean the thing i've enjoyed about it personally is like i've always been a bit of a kind of generalist software ride so like with ruby particularly when i was doing a lot more of the packaging stuff than i do probably today you know in a given week you could be writing ruby c c plus plus haskell like having to play around with like 10 20 different languages and frameworks and you kind of develop a sense of how this stuff plays nicely together and what the what the edge cases are and what you need to watch out for and everything like that but yeah i mean software is a a wily beast uh and packaging it's no less so interesting so um yeah so what are your dependencies i know that you have to have the xcode build tools installed does it yes in the rest of them for me yeah basically that's you on a mac like that's all you need you just need to have the xcode uh like utilities installed um and then even then like we've we've sort of tried in the past like sometimes to make them not required but it's it's pretty hard given like the state of right things in apple land to to go completely without that and you know every few years apple introduced some new requirement which requires using a cli that only they provide and there's no open source version and we're kind of back to square one there so yeah basically just the xcode command line tools are the only dependency and then if you're running hobo and linux there's a few other bits and pieces there but and the big one i mentioned before like ruby like we we build our own kind of statically compiled ruby which you can just use anywhere that's auto installed for you and everything so i guess uh some of the something else that i'm wondering is are you taking advantage of some of the newer features in ruby so for example you've got yjit right that speeds things up quite a bit or uh the other one is like uh fiber scheduler and stuff like that which gives you some level of concurrency or are you digging into any of that or is that kind of upcoming when you get to it yeah so we've we've played around with like bits and pieces around there like so it's it's funny because homebrew is very much you know that there's been this kind of meme in the ruby community for a while that like people get sad that like ruby is associated almost entirely with rails most of the time um and like homebrew is pretty much as as far away from that as you can get you know we're not we're not even a web app we're not attached to a database like you're running a cli so it's funny um i i guess a lot of the places from where the jets come from like it never say never like it may well make things faster in the future but right now all of the kind of jets different jets we've tried in the different jet sessions we've tried like just the way homebrew runs even if it's doing a relatively complex task like a this episode is brought to you by spreaker the platform responsible for a rapidly spreading condition known as podcast brain symptoms include buying microphones you don't need explaining rss feeds to confused relatives and saying things like sorry i can't talk right now i'm editing audio if this sounds familiar you're probably already a podcaster the good news is spreaker makes the whole process simple you record your show upload it once and spreaker distributes it everywhere people listen apple podcasts spotify and about a dozen apps your cousin swears are the next big thing even better spreaker helps you monetize your show with ads meaning your podcast might someday pay for well more microphones start your show today at spreaker.com spreaker because if you're going to talk to yourself for an hour you might as well publish it the run times are relatively short the process only sticks around right for you know at most probably a few minutes um but then a lot of the time it's just around for a second and there's new data every time so you can't necessarily cache things super hard um and like basically everywhere where homebrew is slow and like that's the most common complaint about homebrew is that homebrew is slow um the almost everywhere it's slow it's slow because of um the like io basically like we're either downloading something off the internet we're writing something to your your hard drive we're reading something from your hard drive whatever and we can maybe do a little bit more parallelization but again like in the past uh there's been times where uh there's been times where i've and again some of this may be changing from spinning platters to ssds or whatever there's been times where i've ripped out paralyzed code that we have in homebrew and it's actually dramatically faster running really than it is parallel um so yeah i mean we we we definitely have a decent amount of like profiling tools like we rely on like stack but basically everything you would expect in rubyland stack prof co-prof all these types of things um but yeah but we do try and make things as fast as we can and the jets don't seem to really be helping much for us at the moment but as i say maybe yeah so um i'm going to move on a little bit to you mentioned homebrew core so is that the list of casks and formulae so homebrew core is the list of formula so we have homebrew cask and homebrew core so the difference between casks and formula are like homebrew costs used to be a certain like separate project and that's the way that's what you use for installing like binaries from other people so like right like google chrome or one password or whatever like if you're installing that basically if if the project is whether it's open source or not if if the main way that that's delivered is like a pre-compiled thing or like a dot app or dmg or dot pkg or whatever then you're installing that with homebrew cask like the essentially to the user the interface is more or less the same nowadays like you type brew install google chrome or brew install wget and it's it looks essentially transparent under the hoods but right yeah they're they're managed in separate repos like this was previously like a requirement due to some open source political nonsense um but yeah so everything in homebrew core is open source software and everything and homebrew cask has a much looser uh requirement basically there um so yeah they're managed separately they have roughly the same amount of packages but then like again the the dsl that's used are kind of slightly different and homebrew cask is a bit more friendly to like proprietary software for guis whatever and then homebrew core is a bit more friendly to like clis and there's open source software i gotcha so yeah and see i didn't even know you could install some of those binaries with homebrew because i always just go to the website and download it and run the installer and right yeah or open the dmg and drag it to applications or whatever so that that's really interesting um as you get into some of the open source stuff in particular how do you know how to build it are you always looking for the make file or is there something else to it or so sometimes there's instructions in like a github repo or whatever or sometimes there's kind of you know it's got to make file and sometimes you just kind of try it out and figure it out and hopefully you can do the right thing and then two years later the the author pops up and they say hey you're building this totally wrong and it's like well you didn't tell us what to do dude so like that's that's what's gonna happen yeah so yeah it's it's always a like a there's definitely like uh a certain amount of kind of trends and traits of things that behave pretty similarly and those projects are very nice to deal with and then there's projects who decide hey i'm gonna invent my own build system because all the other ones suck and yeah those are less fun to deal with right so um essentially if i do a brew install on something like google chrome it's just gonna pull the binary off of wherever and it's gonna put it wherever it goes and make sure it's in my path or whatever whatever it has to do in order for me to be able to run it yeah exactly and then for a formula it's going to go through some kind of build process and it sounds like you don't like auto detect uh the build script you go and you look it up and you add that to the formula and tell it how to build it yeah exactly so what we we try and do like certain bits of water detection and for an end user for the you know if you're running brew and saw on your machine uh the experience is actually kind of similar because you're you're still downloading a binary most of the time if you installed homebrew on like a supported macOS version which is one of the the last three and the kind of default location right then what it will do is essentially when someone submits a formula or an update to a formula we have our pull requests on github our continuous integration we'll go and like build that and then when that works we then have a process that kind of that build artifact gets uploaded we call those like bottles the binary packages and okay like that that was my probably favorite contribution to homebrew was doing that just for the amount of time it's probably saved the world uh because before that you know if you wanted to install wget it would take five minutes and everyone would essentially spend five minutes with their cpu fans you know in the days before right silicon like going 100 to spit out essentially the the same binary at the end um so yeah now we kind of have these binary packages and those are downloaded on your machine and installed and it's all nice and and also it's way less error prone because um with the compilation stuff there's always things where you know you have some random utility on your machine and the build script detects that and then blows up or whatever so you don't have those same issues with the binaries and hey there this is charles maxwood i'm excited because i wanted to let you know about this thing that i pulled together that i had just i've been dying to have this for years and i never felt like i could and then i just realized that there's no reason why i can't so um i'm putting together a book club and we're going to read development focused books career books you know technical books whatever the first book that we're going to do is going to be clean architecture by uncle bob martin if you're not familiar with clean code or some of the other stuff that bob has done check that out i've also talked to him on the clean coders podcast which is on top end devs but uh yeah we're going to get on he's going to show up to some of our meetings and what i'm thinking is we'll probably have like five or six people uh part of the conversation along with bob and i at the same time and we'll just uh so somebody can come on they can ask their question and then we'll just rotate people through so we'll we'll mute one person unmute another person when it's their turn to come on and be part of the discussion so we'll do that for like an hour hour and a half and then the other part of it that i'm putting together is just kind of a meet and greet gather area on gather town and so after the the meetup and the call what we'll do is we'll all go over to gather town and you can just log in walk up to a group and have a conversation and that way we can all kind of get to know each other and and make friends and and get to know people across the world uh one thing that i'm finding is that yeah the meetups are starting to come back but a lot of people don't have the opportunity to go to a meetup and i really want to meet you guys and talk to you so we're going to put all that together it'll all be part of that book club you can go to topendevs.com book club to be part of it and i'm looking forward to seeing you there the first book club meeting will be in december the beginning of december we're starting the first week of december and um you'll also be part of the conversation about which book we do next i have one in mind but i want to see where everybody's at so there you go right so it looks at my setup and says oh i know that this bottle's compatible so i'm just going to give you the binary instead of making you build it totally and then if it can't for whatever reason then it'll do the build step or the build process yeah yeah and i mean that that essentially should never happen on you know a supported mac and a supported location but yeah if you're outside of that then it will fall back to kind of building from source and when it can't do that otherwise uh but yeah but most most things most of the time will always be you get like a binary package for most users so right so just backing up a little bit because you mentioned homebrew core and homebrew casks is kind of the places where these things live is homebrew literally going to github and cloning it or like how does it get that list yeah originally well until very recently yes we we did that uh to get hubs yeah so the original updater for homebrew was just it had one repo uh which was like mxcl which is max house github uh mxcl slash homebrew and that would just be cloned in a directory and when you ran brew update to like you know pull the latest packages that was just doing a git pull basically um so over over time that became more and more sophisticated um as homebrew grew that became slower and slower like even the no-op operation of just doing a git fetch on that repo and it's telling you you don't need anything that was taking like a couple of seconds at the time i worked at github and i was getting annoyed with how slow it was so i actually added a entry to the github api to specifically to make homebrews updates faster and uh like it ended up being used by a bunch of other cases and package managers or whatever essentially what you could do is you could just like pass the the hash that you have i i have used the the uh what's called the http e tag so you could pass the the git commit hash as the e tag and then you would get a whatever i can call it is the the status code that says no not modified essentially so it would do that and it also wouldn't count against your github rate limit because that was very heavily cached that operation so that basically meant you could get a really really fast response for like github repos and we still rely on that api to this day um and yeah so until very recently like that was still how it was done and we would like fetch stuff or whatever but um over time that was getting slower and slower and also like github were like you know they were pretty nice about it all but i think at some point i believe there was like a dedicated bare metal server that was essentially just 24 7 serving homebrew core to people uh because also the way that that that repo had super long history loads of contributors right didn't i did a lot of like uh squash and rebasing so like not very kind like history management um and again like thousands of files in a folder which we never knew when humbrew was created is extreme if you have very deep histories get gets very angry and the performance goes to um bad places pretty quick this episode is brought to you by spreaker the platform responsible for a rapidly spreading condition known as podcast brain symptoms include buying microphones you don't need explaining rss feeds to confused relatives and saying things like sorry i can't talk right now i'm editing audio if this sounds familiar you're probably already a podcaster the good news is spreaker makes the whole process simple you record your show upload it once and spreaker distributes it everywhere people listen apple podcasts spotify and about a dozen apps your cousin swears are the next big thing even better spreaker helps you monetize your show with ads meaning your podcast might someday pay for well more microphones start your show today at spreaker.com spreaker because if you're going to talk to yourself for an hour you might as well publish it um so yeah so as of i think it was year and a half maybe two years ago uh like someone one of the home room maintainers kind of started the first attempt at like a little project to see about okay well we can we you can effectively turn pretty much all the homebrew packages into like json output anyway right and when you're just downloading binary packages you're basically just downloading a thing off the internet and sticking it in um like installing it that way anyway you don't need all the kind of sophisticated build information for every package um so yeah so as of yeah like about a year ago i think we've migrated entirely to what we call our kind of json api which is downloading just a single json file which provides all the details for those packages um and then you just have that single download you don't need to have that git repository on your machine anymore which saves a bunch of space and it's like a lot quicker of downloading um right and yeah and the implementation of that api is another disgusting uh thing where so perhaps because i'm scottish um we are known for such things or just i don't know uh i don't like paying for things and and in open source projects i think that's universal even less uh so our our json api is actually on github pages um and it's yeah so it's all like it's a statically generated api essentially so like every 15 minutes we like regenerate our packages and what that means is that it's really really really fast and essentially you know nigh infinitely scalable for github to stick a cdn in front of that and host it that way and and it's also pretty easy for us to kind of download and debug and we're not maintaining some like complex um like you know when i worked on the the api github like maintaining the performance on that thing when you were at the scales we were at was not an easy feat and yeah and i i saw that i guess for homebrew and i was like nope i'm gonna if i can make this just entirely static unauthenticated api then let's do that so that's the route we went down and it's been working pretty well for us that's awesome i love that it also makes me think a little bit that sometimes i might be over complicating my life by trying to make it work the other way right the more traditional i'm gonna build i'm gonna build an endpoint on rails and it's gonna give all this stuff and it's gonna check all these things instead of just saying hey it doesn't matter if everybody knows this and it'll be way faster and it's not that big a file so yeah just go get it yeah it's funny because i had this idea for like over a decade about like building essentially static apis where because you know like static site i've used like jackal and github pages for my oh yeah for a long time um i i kind of like that sort of static site builder model and you know the results are nice and super fast and it's really cheap and easy to host and very non-error prone right once once you've generated the files you're like well nothing can go wrong now right compared to like maintaining a rails app um but yeah so i always kind of like the idea of having something behind i was i was pleased that i was actually finally able to do it because in cases where essentially you want to deliver the data to absolutely everyone the data is the same it's not like user dependent whatever and the data only needs updated like not very often like you're not updating like second by second from some database but you're updating it like you know a few times an hour then yeah like this approach has actually been really quite cool and fun and yeah and encourage others to play out below uh play around with the approach and maybe not on get on pages because get on my gang room so well i can imagine though because i'm just thinking through maybe what i want to do with building an app for the podcast network right yeah and yeah like 99 of the stuff that i'm putting out there it's going to be the same for everybody and it's all public and right so i i don't have to protect it at all and so yeah why not just have a static file out there that it can just go oh you want the list of podcasts here right oh you want this podcast and all of its episodes here right now granted some of the podcasts have more than 500 episodes at this point and so you might get a little longer json file but still it's not terribly large and you know you start getting into it really when you start pulling down images or audio files yeah you know i can put those in as urls on the json and just make it really wicked fast and then it's okay now i have restricted access for memberships and stuff like that that's where i can you know maybe put a check in front of it but still then just have them pick up a statically generated thing because once you're authenticated that's all the same too so yep totally i'm really digging this yeah it's it's been fun i think i don't know that this is the thing i like about working with open source and stuff like homebrew is that you know you get i guess the thing i've learned in my career is the most interesting projects are the ones often with any sort of constraints right like the projects would like you know take as long as you want you have as many people as you want do it whatever you want in whatever language you want like they're they're often like maybe i'm just a masochist but i i find them often like less fun whereas the fun thing with something like homebrew as well it's like you're building homebrew's api and it's like well we we have like i i guess the way i describe homebrew's financial situation is like not enough to pay anyone but too much for stickers right so you have like this like middle ground of money uh and as a result like it's this tricky thing of like well i don't really want to put us in a situation where we're paying vast hosting bills so let's try and figure out a way of doing this for free essentially but it has to be able to scale to like you know millions if not tens of millions of people like using this thing um so yeah so like that's been a a fun kind of comparison uh compared to as i say you know like github days where you're scaling to many more people than that but you also have particularly post microsoft acquisition like many more resources to your disposal in order to achieve those scales and you're not working quite as much as much about the bottom line as you go along yeah yeah the other thing that i i just went through my head was and this isn't json it's xml but rss feeds right oh yeah yeah yeah yep so yeah um all right so we've kind of talked through how the repository works and um let's say that i decided i wanted to build the cli and it was moderately complex are there are there things that you recommend to me as a ruby developer as places to get started um i mean the funny thing is i i wasn't you know i realized this uh maybe um i don't know a controversial take for the podcast but like i mean nowadays i probably wouldn't necessarily reach for ruby for a cli like it's it's okay for like doing doing you know i still think it's great for doing web apps but like you know when i've i've been building like a new cli for some of the stuff we've been doing with work brew um and like go feels like a more i was basically weighing up between like go rust and swift basically um as oh okay like the switch i wouldn't have pegged swift for that well i yeah i i didn't peg swift in the end for various reasons but you know i ended up going with go which i it's i don't know like for me go is just it's good at what it does it's such a boring language i i don't have any fun when i'm writing go but you can ship a single static oh it's fast yeah and it's super fast and for cli it's like it's like the responsiveness is really great i think i think that's the thing that i maybe i'm just burned for like 15 years of working on a ruby cli but like there's a certain amount of people will complain about the slowness that it's like literally even like a ruby interpreter spinning up and saying hello world is like unacceptably slow to some people right and at that level i can't really do anything to make it it faster but yeah i guess if you if you are going down the route of almost like really wanting to get into a make it some sort of ruby cli or whatever i guess i would just say like you know the beauty of ruby is that you can start with like a single script right you can just right have a script stick the shebang at the top like the for those who don't know that's the thing where it has um like exclamation mark hash like user bin anyway like user bin ruby or whatever and then you can just start writing ruby code straight away right and and like that's that's how i think is the best way to maybe get started with like clis whatever it's just like rather than almost like reaching for some option parsing framework whatever no just go and just start writing some ruby and right just read the argv which is the array of like the arguments you pass into the script and like just read that yourself and just you know don't don't go too fast too quickly and you'll probably have like a good time because again like when you're clis if you're wanting to distribute them to other people like if they you know if you start relying on loads of other gems and stuff then it becomes like a little bit more of a headache to kind of distribute and use these things and keep them up to date and whatever so like yeah i think the beauty of ruby is like ruby has like a pretty decent broad standard library you could do a lot with like a single script and even like an old version of ruby like the ones that ship with like mac os like there's still you know it's still a powerful like pleasant language to work in so yeah very cool um so yeah so is there anything new coming in homebrew or yeah i mean we're always working on this it's funny because uh people quite people ask periodically about like the roadmap for homebrew and because we're essentially i mean maybe except for me now like essentially almost everyone is like a volunteer the the roadmap for homebrew is kind of like well let's see what people want to work whatever people want to work on right and it's yeah like the product management on homebrew kind of looks more like uh nerds attempting to nerd snipe other maintainers into um solving problems than it does like you know building a team and assigning them a six-month project right so yeah i mean i think like a big thing is like performance like we're continually trying to kind of eke out better performance where we can um and then yeah and i guess like i'm looking at it from the kind of work brew end as well of being like okay well so if uh if me and a team of people are actually able to work on homebrew full-time or like spend like a decent amount of time putting into homebrew like what are the really big impactful things in homebrew that kind of might people might look at and say that's just impossible that we could do if we have like a paid team of people who are working on this stuff full-time um and i don't want to you know i don't want to be too spoilery with that but um yeah there's definitely there's definitely some stuff we're exploring where if we see that there's interest and we can kind of pull it off i think people will really say wow about but um i in the short term medium term i think there's more along the lines of yeah just like making homebrew faster more secure making the contribution process better and just trying to do everything we do right now like better basically like i mean i i'm a big fan at github and on homebrew of like um when i was at github that was like reading really really heavily into automation so again like a lot of what we're trying to do on homebrew sometimes it's like we've only got 30 people maintaining the the project but yeah the throughput of like prs we have and it's fairly ridiculous and we just try and have so much automation lean have more and more and more heavily into that and any time you know i catch people doing things that i'm like a bot could do this then it's like right i try and write some code and get the humans doing the human things and save the the bot work for the bots so i was gonna ask about work brew and i'm gonna ask about in a second but you did mention um uh maintainers and so if somebody is like oh i've got a great idea for homebrew or um you know i use this all the time and i'd like to contribute back to it right is is there a good way for people to get started with contributing yeah so homebrew the best way to get started is there's like a contribution section on the readme of the homebrew brew so if you go there then you'll or if you even just search for like contributing to homebrew like the result like results are pretty decent i would say our our docs are probably like on the better end uh for like contribution like our tooling is probably pretty good but like i would say like it's a really easy project to get started with um and we we really try to kind of cheerlead the people who want to get involved with the project so like if you're in any doubt just try something and we'll help you out and you can mention me by my github handle or whatever if you say that it's your first pr and you're struggling and i'll try and do what i can to help you and stuff like that um it's a yeah i as i say i think it's a really good project to kind of get started with um but as you know for some of us at least it's also can be uh fairly addictive at times so be be wary from that perspective as well yep all right so the other question i have then is yeah do you want to talk about work brew like what it is and where you're heading with that yeah so i mean as i mentioned earlier with like homebrew like i've been working on homebrew for about 15 years and for you know probably 10 of those years there's been people who have been encouraging me at various points that oh you know you should make a company doing stuff around homebrew and i i have been historically kind of down on this idea or fairly cynical particularly when i mean i'm not going to name any names but you know there's been various companies who kind of have done open source stuff and then you know they complain down the line when everyone uses their software but they're not making enough money or whatever it may be and right i guess to me it's like open source itself is not a business model i know and also like i you know i kept like you mentioned earlier like you've got you know kids younger than homebrew and stuff like i i also feel like homebrew is kind of my first child and i feel quite precious of it and i wouldn't want to you know like destroy it or whatever so it's it yeah it took a while for me to get to a place that i was like yeah actually it feels like a few things have come together so one is like homebrew feels i mean even with the road map stuff like if we'd had this conversation a year ago or two years ago i probably would have said like more stuff on the horizon but it feels like fairly close to kind of feature complete at this point and without almost like a big um injection of kind of effort and stuff so that was one part the other part is like we've got i won't go into all the boring details of like open source governance but you know but we have an open collective we have a like a leadership committee we have elections every year we have like ways of getting involved with the project beyond just like current docs and stuff like that we have money that we're using to like provide stipends to some maintainers and pay for them to kind of come and meet each other in person and stuff so the project feels like it's in a really good mature place and it's also in a place where no one party could ever kind of completely take over homebrew even if they wanted to and so yeah so and it it's also on the backdrop of this i guess like you know i left github last year and was sort of looking for a new challenge or something new and you know again over the last 10 years there's been various times where companies come and say hey we'd like you know homebrew to do this or that or whatever and this episode is brought to you by spreaker the platform responsible for a rapidly spreading condition known as podcast brain symptoms include buying microphones you don't need explaining rss feeds to confused relatives and saying things like sorry i can't talk right now i'm editing audio if this sounds familiar you're probably already a podcaster the good news is spreaker makes the whole process simple you record your show upload it once and spreaker distributes it everywhere people listen apple podcasts spotify and about a dozen apps your cousin swears are the next big thing even better spreaker helps you monetize your show with ads meaning your podcast might someday pay for well more microphones start your show today at spreaker.com spreaker because if you're going to talk to yourself for an hour you might as well publish it essentially what a lot of homebrew features come down to is like do the volunteers who are mainly working in their spare time want to build and support this right and for a lot of like big enterprise stuff i don't know charles have you ever had the misfortune of uh reading through like a saml spec or something like that before but you know once once you get into this like big enterprise tech like it's often not very fun and it's not what people want to spend their evenings and weekends doing and i previously worked like before my homebrew days in like an open source company back when i was a kde contributor and this company uh consulting company and they hired more kde contributors than anyone else and i worked and i thought sweet i'm gonna be able to work on open source most of the time but i i learned pretty quickly that their open source projects were actually not super fun because they were basically stuff that people would pay a consulting company to go and like hey like we've got this stuff which we can't get anyone to do for fun so will you do this for money and then they're like okay well fine um so with work brew i kind of see it as being a similar thing where what we're trying to do is you know there's a lot of talk about sustainability and open source and stuff right now um and i guess that's on my mind i worked on the original team of people who built get up sponsors and have helped kind of homebrew yeah have that open collective and to me like this is the next almost like step in the evolution of like what sustainability could look like for homebrew is having a commercial entity where we're trying to kind of make a sustainable like commercial entity who has an interest in making money in the homebrew ecosystem but not charging money directly for homebrew itself homebrew itself will is and will always remain like free of charge but we're going to make homebrew better by making workbrew better and be providing services to companies um in the homebrew ecosystem through our expertise and by building stuff that tightly integrates with homebrew so essentially the version of workbrew that i like run on my local machine today it looks and behaves almost exactly the same as homebrew right except it's got a little coffee cup instead of a beer emoji um but it's you know it's running in a different way it's running in a more isolated like fashion a multi-user fashion right it's like reporting back to do fleet management so someone could upgrade like if i've got critical vulnerabilities remotely and so that people can see kind of oh like you've um you haven't updated in six months and we've got some problems with that whatever it may be um so yeah so essentially that's what we've tried to do we're trying to build something that provides a better experience for using homebrew at work um but for most hobbyists i i mean we very much have the goal that if you in five or ten years if we're successful even if you've never heard of workbrew even if you never interact with workbrew you will look at essentially roundabout now as being an inflection point where homebrew gets really really good in the next five or ten years and it gets noticeably better for everyone using it because we're able to kind of get involved and improve the sustainability of the project through the commercialization of this part of the ecosystem that's cool um if people want to know a little bit more about what's going on with that like you have a mailing list or something or yeah so date somehow yeah the best way of like getting in touch with us we've got a contact form on our website if you go to workbrew.com contact and then you can like send us a message and then we can go and get in touch and we'll kind of send you emails and stuff like that and you can also see if you go to workbrew.com our demo of what we have in private beta right now which is essentially like a fleet management for homebrew and kind of integrated with mdm tools and so that basically like mac admins and primarily and you know security professional developer experience folks can basically get a nicer experience of using um homebrew at work and so yeah so we're recruiting like design partners for that right now which essentially means like people who will give us lots of feedback while we make the beta kind of more to their requirements so again if you're interested in that best way is reaching out through the contact form and and if you have any thoughts equally as well if it's easier if you're one of these people who gets spooked by contact forms you can send me an email um my email address is pretty easily findable on the internet so if you do that or it's just mike at workbrew.com or at brew.sh if you want my open source email awesome all right well um if people want to connect with you on some other level where do they find you on the internet so i'm still i'm basically read only mainly on twitter nowadays uh i'm mike mcquade on there but the best place probably is uh i'm mike mcquade at mastodon.social on like mastodon nowadays um or if you just find my website at mike mcquade.com that's basically got you know my i try and kind of put if i write blog posts or like do talks and all my contact information is there and stuff as well so yeah and you'd be surprised how few people actually just email me to say hi or share their opinions so feel free to do that for almost anything except for saying my home is broken please fix it in which case right all right good deal well i'm gonna go ahead and uh roll us into the picks here have you ever wish that you had a group of people that were just as passionate about writing code as you are i know i did i did that for most of my career i'd go to the meetups i try and create other opportunities and it was just really hard right the meetups i got some of that but they were only like once or twice a month and it was just really hard to find that group of people that i connected with and and really wanted to you know talk about code a lot right i mean i love writing code i think it's the best and so i've decided to create this community and create it a worldwide community that we can all jump in and do it so we're going to have two workshops every week one of those or two of those every month there are going to be q a calls right where you can get on you can ask me or me and another expert questions uh the rest of them are going to be focused on different aspects of career or programming or things like that right so it'll go anywhere from like deployments and containers all the way up to managing your 401k and negotiating your benefits package well we'll cover all of it okay and then we're also going to have meetups every month for your particular technology area so we have shows about javascript react angular view and so on we're going to have meetups for all of those things i'm going to revive the freelancer show we'll have one about that right so you can get started freelancing or continue freelancing if that's where you're at and i'm working on finding authors who can actually do weekly video tutorials on something for 10 minutes this related again to those technology areas so that you can stay current keep growing so if you're interested go to topendevs.com/signup and you can get in right now for 39 when we're done that price is going to go up to 75 and the 39 price gets you access to two calls per week the the full price at 150 which is going to be 75 over the next few weeks that price is going to get you access to all of the calls and all of the tutorials and everything else that we put out from top end devs along with member pricing for our remote conferences that are coming up next year so go check it out top end devs.com/signup um and i we usually have the host go first so i'll go first um one of the first picks i have i always pick a board game when i uh when i do my picks and so i'm going to pick a board game called fire tower and basically it's a it was a relatively simple game let me look it up on board game geek real quick while i tell you how how it's played but um essentially all of the players have uh fire towers in the corners of the board and uh so what you're trying to do is you're trying to burn everybody else's tower down before the fire gets to and burns your tower down and so um you can play two to four players we played it with four people it was a lot of fun uh board game geek rates it at 1.77 uh i tell people that a two is kind of a reasonably complicated game it's complicated to be fun but not so complicated that it's hard to pick up and so yeah this is right in there at that level um playing time it says 15 to 30 minutes i think we played at 45 but it was our first time um uh yeah 10 plus player or 10 plus on age i honestly think my eight-year-old could play this game right um it's it's pretty simple and after she played it once or twice she'd probably get most of the strategies figured out right don't have the wind blow toward your tower um put put down the fire tokens in a way that gets it closer to the other people's towers i mean right anyway so um so i'm gonna go ahead and pick that uh it was a super fun game really enjoyed it um one other one that i'm gonna pick is we were talking about some of the install stuff and daniel kehoe who's used to be in the ruby community way back in the day uh he has a website mac.install.guide and it walks through how to install like ruby and a bunch of other stuff and it pretty heavily uh refers people to homebrew so um anyway i'm gonna refer to that just as a resource that people can uh go check out and then um i had something else and i'm i'm just kind of blanking on it anyway i'm the the the where i talked to daniel most recently was when i picked up the rails composer.com domain from him um and so um i'm working on that you can actually watch me build rails composer and all of the different uh rails engines that i plan on putting together for that um on the rails clips um video series so just go to topendevs.com you can find it i think i also own rails clips.com and i think that goes to the right place so uh go check that out but uh anyway um yeah good stuff uh mike what do you want to pick on the show yeah okay i guess i will do three little picks uh so one would be i'm reading a book right now by a guy called alistair reynolds and he's a science fiction author he's written a lot of kind of space opera stuff i've written read all of his books uh that he's ever written so far um and he released a new one a couple of months ago which i'm 88 of the way through called machine vendetta that you penny arcade talked about it um and you probably don't want to jump straight into uh machine vendetta as there's been a couple of books preceding it in the series unless you want to deal with the discussion of hyper pigs in the first paragraph which may throw you off um my second recommendation would be a band uh you may or may not be into their vibe they're called ale storm uh like a storm of beer and i guess you can see there's a theme going on they are a scottish pirate metal band um i'm seeing them live uh next sunday uh in scotland uh but they play internationally and they my kids really like a song from their latest album called uh pirate party because it has a a moment with a man drinking from a shoe which is apparently very funny when you're four and six years old uh but generally i would not recommend most of their songs to children and as they are very heavily expletive written in some of them but you but you know whatever they may work for you or not and my final recommendation i guess on the theme of um open source maintenance in particular is therapy i've been doing therapy intermittently since 2020 and i've something i found tremendously helpful personally um with all sorts of things in work personal life my uh relationships with my friends family kids wife and and even on occasion i have sessions where i talk about a particular difficult person i'm dealing with open source land uh in a given therapy session so if you're if you're interested i would highly recommend it and i've written a blog post on my website of like a step-by-step guide if that's your way of doing things of like how to find a therapist so if you are interested and that's useful to you please consider doing that oh man given the last few months that i've had i might need that anyway uh what was the name of the band again and if you can put a link into the comments that'd be great yeah yeah i will drop a link into the band obviously um but yeah we'll go ahead and wrap up here um one other thing i was just going to put out there this is the thing i forgot is that uh my contract work has slowed down a bit so if you're looking i'm either looking for a full-time job or a contract prefer contract but you know if you've got an interesting set of problems and you're gonna pay me well to fix them then i am happy to consider full-time work um you can just email me chuck at top endevs.com all right thanks for coming mike this was really really interesting thanks for having me chuck and have a good rest of your day everyone yeah you too max out everybody