Mike McQuaid

• My Parenting "Screen Time" Philosophy

  Like many people who now work with computers, I was told as a child I spent “too much time on screens” and then built a career out of it.

• How Homebrew Became Mac's Package Manager with Mike McQuaid

  Interviewed by Screaming in the Cloud
  

  Mike McQuaid explains how Homebrew grew from a side project into macOS’s de facto package manager and how the project is sustained today.

  Show transcript

  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

• What happened to RubyGems and what can we learn?

  
  Lessons for non-Ruby projects on non-profits, governance, money and access in open source, drawn from the RubyGems dispute.
  Show transcript

  Thank you everyone for having me today, this is my first time at the big stage in Homebrew, in Homebrew, Fosda. I've been here many years, I love this conference, it's the best open source conference in the world, but first time here. So I thought, given this topic is potentially contentious, I would get a friend of mine, hopefully make me feel a little bit better. So I sent him the screenshot of when this got accepted, and I said, oh, fuck. So he congratulated me, which was very kind. He thought nice things about the title, and then unfortunately let me down. So hopefully I am not in fact fucked, but if I am, hopefully it is entertaining for all of you to watch me, as we say in the UK, die on your arse. Anyway, so some important framing, right? We're going to talk about some stuff today, which is pretty fresh, like literally some people who have been involved in the story are possibly in the room, and I've seen people at FOSVEM, right? So who already has an awareness of what happened with RubyGems, even a vague one, right? And who has like strong opinions about maybe who was in the wrong and who was in the right? Trick question. But yeah, okay, so a few of us. So what I ask us to bear in mind, right? This is not a trial, right? It doesn't really help us to go and point fingers, particularly at individuals, actually, because this is mainly a story about groups of people, and communities, and open source foundations, and open source maintainers, and companies, and all of that interesting stuff, right? And I actually think this stuff gets, particularly when I'm sitting on a stage, and people won't be in the room, it's a bit mean, if we start pointing fingers at individuals, so I'm just not going to do that. I'm going to try and avoid naming anyone except myself, because I'm allowed to be self-deprecating because I'm British. So the next thing, again, I want us to just encourage anyone who right now is like, this group with this person, completely fucked this up, and this group of this person did everything right. Like, that's a bit of a red flag, right? You know, many of us in the room, I'm sure are engineering, right? And this group of this person did everything right? Like, that's a bit of a red flag, right? You know, many of us in the room, I'm sure are engineering, right? And this group of this person did everything right? Like, that's a bit of a red flag, right? You know, many of us in the room, I'm sure are engineering, right? We work with engineers, right? And we work with software, and complex systems fail in complex ways, right? So if you feel absolutely certain about something, that means either you're probably missing something, or maybe you have a bias. That's okay. No shame, no shade, whatever, right? But just let's try and try and come into this with an open mind, right? Again, another important framing, I think, for all this is incentives of everything, right? Like, very rarely in the world do we actually have particularly in things like open source and in workplaces and not Netflix shows or whatever like people who are just unbelievably evil and cackle away as they deliberately do the thing to maximally fuck over as many people as possible right like people are responding to the incentives that are put in front of them right people don't go into things generally with bad intentions and generally the people who we look at in these situations who we think maybe have bad intentions just have a really bad incentive structure set in front of them right so I'm also need to look at things through that lens and we're gonna try this being a lot of I guess the word drama has come up again and again when people have been talking about this right sometimes like favorably sometimes used to critique one side or another or whatever but I feel like we thankfully have moved past the drama stage right and we can be in the learning stage so let's do that this talk is about free and open source software and specifically infrastructure projects which I'll talk a a little bit later on why this is a particularly important topic for me specifically but these projects underpin an enormous amount of the internet right like for most even kind of commercial software developers who are not here who care nothing about open source who probably don't even really understand open source the amount of open source software that has to work and go right and be lined up and perfectly orient itself for that person to do their day job and increasingly their day job far removed from technology is pretty breathtaking when you think about it right it's arguably open source software is one of the best achievements we've made as mankind and I love conferences like this because I think it really highlights the kind of beauty of what we're doing here right we are creating this worldwide system of software which is incredibly powerful and many people rely on empowers so many other fields right but because it's invisible when it's working and because people don't think about it often it just fades into the background and that success that comes from making things invisible and transparent and just smoothly flowing makes it even more dramatical that's not a word even more dramatic when things fail when things fail they fail loudly they feel globally and the blast radius on important projects it's never small so Ruby gems is one of those systems and that's what the story today it's gonna be about not talking about heroes we're not talking about villains we're just talking about systems of distress and what we can learn so who am I why am I talking about this and what can you maybe learn from me firstly I think that's legitimate to ask particularly in something like this story because I think a lot of the people who maybe have a strong opinions like when you understand a bit about their background it's maybe clear why they have the view they have so I'm the project leader of homebrew a Mac package manager it runs on Linux and stuff as well so I've worked on that since 2009 so that'll be 17 years this year which is slightly terrifying and I think what that does is it gives me a little bit of context about what it's like to run a package manager what it's like to work on these open source projects for long periods of time but we'll see later I'm not super involved with this story beyond that right I was a principal engineer at github for a while that told me a fair bit about open source it told me a fair bit about Ruby because that's what github is primarily built in and scale security liabilities etc I think most importantly actually for the story I'm a Rubyist I first wrote some Ruby in 2005 I've probably written Ruby more than any other language since about 2009 and I deeply love it I like the ecosystem I like many of the people I have friends I've met because of Ruby I have jobs that I've got because of my work on Ruby and I have depend on it for most of my career finally and somewhat least importantly like I have a day job right open source is not my life I'm a CTPO a small training management software company in Scotland but as a result of that I have had to do an awful lot of like work around growing as a leader and trying to understand how systems and cultures and incentives are set up and what happens right I'm not a Ruby James maintainer I never have been I have similarly with bundler I have no affiliation with Ruby central I've never been involved with them I've never given them any money I've never done any work with them or anything like that in this situation that I was asked to mediate so some people we'll talk about later on like the way homebrew does governance was kind of cited relatively early on in this situation and as someone who was kind of very involved with with homebrew and our governance process I was asked to kind of come in and see like well how can this apply to Ruby gems or not but unfortunately my mediation did not manage to stop happening what's happened right it's interesting because pretty much this whole story takes place between September and October 2025 we've we kind of have a bit of stability now I think some of the kind of strongest emotions were kind of past that stage which probably helps us to look back a little bit so we're talking about weeks for most of these events rather than years although the context set beforehand and the stuff we'll learn afterwards we'll go back and forward I help gems that co-op you don't need to know what that is if you don't already and I help them kind of set up their governance process I learned some stuff along the way so okay who knows what Ruby gems is hand up okay most people so I'll keep this brief rubies package manager is Ruby gems it's technically you could use another package manager but that's the main default that the vast majority people use it was actually founded in 2004 and after Ruby had been around for a fair wee while like nowadays often the software kind of comes with version can version locking and package management along with the language right out the door but that was not the case with Ruby gems and Ruby there's millions of applications that are on Ruby gems and as a result it's we're not talking about some niche tool used by a few people we're talking about kind of critical infrastructure on the internet which brings up things like software supply chains and all these other kind of big grown-up selling words it's not side project as well right many open source projects are essentially run by one person in their evenings and weekends they never get any money for it they never spend any money on it and it's just like a fun little hobby but Ruby gems is not in that category Ruby gems is much more critical so money money money is messy particularly when you involve it with open source who feels a little bit uncomfortable talking about money sometimes yeah quite a lot of people and like open source money is even more potentially uncomfortable because well some things cost money servers cost money storage cost money bank with the cost money on coal if you want to pay someone well sorry if you want someone to be woken up at three o'clock in the morning on a regular basis when stuff breaks then generally you need to provide a bit more incentive to that than just peer pressure and community goodwill incidents cost money and if you've got years of work you can have it undone in a few hours when you have some critical incident and it's why organizations behave differently under stress because depending on where the money is that tends to focus attention even more closely when incidents are going on but not everything costs money let's compare with the open source project I've worked on for a while with homebrew right so this is not to say homebrew is better or worse it's just a comparison because I think we're two projects both written in ruby but we have a different approach to these things so homebrew's hosting when you download homebrew's binary packages we do not pay any money for that because we were originally hosted by sourceforge then bin tray and then nowadays it's github so the trade-off for that is that homebrew is not as independent as something like rubygems is right like rubygems is not relying on any single vendor like they push their servers on every us but they could move relatively with big finger quotes easily to another provider and probably certainly a lot easier than homebrew could so in some ways we're not even independent we're somewhat dependent on retaining in the good graces of github right I used to work there I still know a lot of people there so I'm not as worried about that as I might be something else but again that may or may not be a decision that makes sense for your project or for rubygems so let's quickly scan through the timeline of what happened these events right so ruby central the organization that's kind of often cited with this discussion was founded originally in 2001 and by a couple of people in the ruby community who wanted to provide a permanent nonprofit for running ruby community events and handling sponsorship and logistics a few of those same people were involved with releasing rubygems in March 2004 and then we have to go forward about 11 years before we kind of reach the next group that's kind of relevant this story which is ruby together so they were actually announced by ruby central in 2015 and they described their purpose as funding on-call rotations maintenance work and improvements to shared ruby infrastructure which included bundlers rubygems and rubygems.org which had in their words historically been done by volunteers in 2022 these organizations merged and became a single nonprofit described the motivation as reducing duplicated nonprofit overhead and unifying community for the events under the events under one roof so this brings us to basically the more contentious events right hands up if you were following this live on social media when it was going on in 2025 right yeah a few people here so September 2025 everything kind of goes down within a few weeks right and again i think there's some interesting context when we talk about the setup for this taking you know almost 15 years and then within a few weeks things radically change so one of the first things i think that happened was control of the main github organization which was used by rubygems related projects was changed in a way that restricted or removed access for some of the people who are maintaining rubygems and this came out of some folks who were involved with ruby central that also involved reading the github organization from rubygems to ruby central and essentially there was as far as as various people involved various people involved are concerned some people say this was very long time coming and this should have been expected and other folks felt completely blindsided by what happened there wasn't certainly any public notice of this people had some sort of behind the scenes warnings that something might be happening but certainly a bunch of people were as i said essentially blindsided by what happens and the problem with this is when you make decisions quickly and when you deliver them somewhat abruptly that always tends to you feel hostile right it feels it can feel malicious it can feel difficult it can feel targeted even if it wasn't necessarily intended that way and particularly in open source when we assume so much stuff is going to be done in the public when there's no public communication at all then it can make this very hard there was also essentially no governance process so i mentioned before homebrew's governance process we'll talk a little bit about that later but essentially at the time when this was all going on there wasn't a documented process about how people get added to how people get added to how people get and removed who controls what which non-profit is responsible for what what taking money means as a contractor or an employee or whatever with this organisation and the problem is when you don't have a written governance structure then whoever holds power ends up filling the gap and getting to make the decisions so after the initial shock we had an attempt at recovery right it looked like things were going okay to begin with so we got to mid-september there was multiple possible futures it looked like maybe we could get everything back everyone could get back on the same page there might be some hurt feelings but we'll be okay there was a governance PR proposed on september the 14th and you can go and see the url show on the screen in a few slides where you can see the kind of conversation that was going back and forth this is how I kind of ended up getting pulled in as well because it was based off homebrew's governance and then I was I kind of offered to give some input there and then got pulled into mediation as well and then shortly afterwards the access was restored for most of these people right so if you go to the PR you can kind of see how this went on and like the sort of tick-tock of what was going on in the event right so then by September the 18th we get to a point where I've offered to kind of step in and mediate between both sides there's a lot of private conversations going on a lot of private contacts going on and in public it looks good it looks like we're both sides are discussing governance and then we get to the point the access gets removed again for a bunch of people right and this is when things get a little bit messier because some folks who had their access removed and then claimed that it was a mistake that their access had been removed and then others took offense and essentially things get very messy very quickly right and then trust just gets destroyed and never really rebuilt this is when we start to get security concerns invoked as a justification as well there was mention of supply side security which in recent history there have been NPM supply side security attacks so RubyGems having a relatively similar trust model like that was concerning to people being involved it also concentrated power very quickly and made clear who had power to do what and who was citing these concerns and using them to make what decisions so by the time we get to late September we have another inflection point where it becomes public on the 28th of September the root level infrastructure access still existed outside the new control structure so the people who were maintainers and had either been removed from the project or had quit the project in protest at the changes some of them still had AWS access and AWS root access even more severely right so again this back and forth about exactly who had what access and when why and what this meant but essentially regardless this is a bad situation right you have a situation where the theoretical control of the project and the actual control of the project are diverging pretty far right and then essentially there was a lot of back and forth but eventually we reached the end state where almost a month later in October the 17th RubyGems and Butler moved to the Ruby core team so essentially Ruby central who had taken ownership of these projects then gave ownership elsewhere and then the people who had been existing maintainers of RubyGems declared that they were happy with that and they were going to allow things to move on So you can see you can read the route access event this has got kind of Ruby central's take of like what went down with the AWS access and stuff like that this was posted on the 9th of October and then while this is all going on it gets to the point where there's enough drama that like various parts of the tech press started reporting on it and people are getting quotes blog posts social media press coverage essentially take over we're not having really any discussions on PRs anymore this is all happening out in the open and then the narrative stops being controlled by the people who are just involved and things become a little bit reactive people start raising privately a lot of people in the Ruby community people's confidence drops like what does this mean for RubyGems is RubyGems still going to be running anymore and worst of all lawsuits begin like we have again publicly on the record both sides have talked about how they've engaged in legal action with the other high we have no insider knowledge as to what the statuses of said lawsuits but I think it's relatively predictable that once that happens people are no longer interested or able really to make good and be friends with people they are in lawsuits with at that point so what were the consequences what happened here well talk failed pretty quickly right so people tried to voice what was going on and how they were feeling and how they could improve things but then when people get kicked out the project then all of that just becomes public discussion instead of private discussion so a bunch of maintainers exit the project some people removed against their will and then some people removed protest so you get to the point where the majority of people who are working on RubyGems in the space of two months essentially have left and gone and done their own thing so doing their own thing what does that means well there was a single gem co-op which some of the maintainers went off and decided to build so they essentially built their own alternative to RubyGems both centralized service and they have forks of various other projects and stuff as well so this was not an overnight replacement but it was spun up relatively quickly and it built essentially a separate kind of side ecosystem which changed the power landscape right so forks don't need to necessarily win or get more users to matter and in this case I think this kind of sent a message about how things could be done differently and it also made clear that that group of people were not interested in re-entering the fold again so another interesting kind of consequence of this is I guess what I would call professional open source so what I mean by that is we have a bunch of people in this room I would guess probably the majority of people in the room how many people are paid to do open source work for primarily at the job okay I guess if you look around the room everyone that is the minority right and I would say in the open source community in general it is in the minority right so when you have people whose full-time salaried work is focused primarily on open source and when they have bosses and leaders and HR teams and their mortgage depends on them making those people happy then the incentives are radically different right and it introduces different incentives to what exists before when you have volunteers working in their free of time and also you have the blurring between the two where you have people taking contracts and doing paid work on open source they might not be an employee but they have agreed to some sort of transactional relationship in exchange for money and that makes things hard and this is even more tricky when you have a project like rubygems which is already hard because you're running critical open source infrastructure and it requires many skills outside of writing code right which is sometimes the easiest skill to be able to get from the community in open source because what this means is that volunteers have their limits and people run out right so what does this mean for careers right so a bunch of the people involved in this story had at some point been paid either full-time or part-time or were full-time employees of ruby central or ruby together or whatever it may be well my potentially contentious take is open source is not a career right and by that I don't mean those you said it's your full-time job to work on open source I don't mean that you somehow don't have a job and you're in a haze and don't really know where you are what you're doing like obviously some people do have that but most of us don't open source can be part of your career and even those folks I imagine who are working full-time open source I would imagine your day-to-day looks pretty different to how it did if it was just your evenings and weekends right it's a very different way of working and I don't think we help our community by making out that the way you work worked before you received any money can just be paid a bay area salary without any change to it so I think we also need to plan for our exit as individuals and as organizations and exit of funding and all these types of things right we need to plan for the transitions that are going to happen even when they're deeply uncomfortable because ultimately one size does not fit all every project is going to ebb and flow and change the years and context is everything so what can we learn from all this well as I said at the beginning it's not about blame right we need to not blame because it just simplifies and polarizes and it prevents learning if you're 100% sure about who's right who's wrong then that's going to feel good maybe for you but it's not going to explain very much governance and open source is really boring until it's not and at that time it's probably too late to introduce it okay maybe money entering the equation makes things better but it certainly makes things a lot more complicated and we should think really carefully about how and when and why you introduce money to the open source project let's all not focus on who was right and who was wrong not who messed up but instead just try and ask better questions let's ask about what broke and why it broke and not who did what and then we can learn something about governance or money right if your project hasn't argued about governance or money yet it probably will one day be prepared and try and do this stuff before it becomes a problem and that's the transferable lesson if you've got questions then come and speak to me outside you can email me or you can find how to contact me other ways on my website thank you very much Thank you.

• Getting Shit Done in Institutions

  Minimum Viable Management

  David Yee, VP of Engineering at The New York Times and head of its new AI platforms and products mission, joins Mike McQuaid and Neha Batra for a candid, behind-the-scenes conversation about why institutions are built to resist change and what to do about it. They dig into hidden norms, choosing the right battles, translating “how things really work” and creating stability for teams while you deliberately destabilize the system just enough to move it forward.

  Show transcript

  Hello, everyone. Welcome back. Hello, Neha. How are you today? I'm good. How are you? Very good. Thank you. We have another special guest with us today. Neha, would you like to introduce our special guest, David? Yes. Yes. This is David Yee. He's a VP of Engineering at New York Times. I'll let him say his title. But David and I got to know each other through the lead dev circuit. And because we're both kind of involved on speaking and stuff, but really, it's more of a meeting of minds. I'm really excited to have him here because we're going to transparently lay out some of the conversations we've been having behind the scenes. We tend to joke that some of our conversations are like stuff that you usually don't necessarily want to say on stage, but it's like about how to get things done, actually. So anyway, it's really nice to have someone else out there who is willing to just drop all the formalities and the, you know, the quips and whatever and just talk about how to actually get things done. And so that's why I'm really excited to have David. Do you want to introduce yourself with your former title or whatever on at New York Times? Yeah. Hi, I'm David. I'm also super psyched to be here. My title recently changed. I'm still VP of Engineering at the New York Times. I am now the head of engineering for the new AI platforms and products mission. It's a mission that's sort of coming into coming into existence recently at the New York Times. And we're building products that are sort of user-facing, reader-facing, that use large language models and the platforms to make it easier for engineers to build them. Yeah, this is going to be fun. It's the sort of transition from quiet conversations to sort of like thinking out loud about the kinds of stuff you can't say on stage. So I'm mostly just excited to be here. Yeah, I feel like my favorite stuff that we talk about is like how to get shit done. And I remember recently when we were talking, we were talking about how to get shit done. When and like, why is that so hard? And why is that a full-time job? And one of the things that you were starting to talk about was that, well, to be clear, like when you are trying to change something at an institution, right? It's job is to not change. And so like you're basically rolling a ball uphill or what is it? A boulder, a boulder uphill. And of course, it's going to be hard. And of course, it's like not natural because you're trying to introduce something unnatural to the environment. So I was curious if you've had any more thoughts around that since like we kind of went really deep into it. And I feel like that's something that a lot of people need to hear about is just like, OK, this is the fact of the matter. Like, of course, it's not easy because of these reasons. Yeah. So I think so. I've been at the New York just for some broader context. Like I've been at the New York Times for almost eight years. I've worked in startups. I've worked in sort of smaller media organizations. But and so just for some context, in terms of New York Times, it's roughly 500 engineer space. So it's smaller than some, bigger than others. But just like from the perspective of size, that's sort of one place to place it. But it is also like this year, 175 years old as a as a institution since. Yeah, that's an institution. Yeah. And it's and it's what we would call its most recent incarnation. Right. Like, so that's like the New York Times preexisted, preexisted that. But like at the time of Adolf Fox bought it and turned it into the newspaper that, you know, that everybody in New York reads and everybody in the world reads, you know, that institution has been around for a really long time. And so, yeah, I think when you and I have talked about it and I think the context that I that I give a lot of people who are starting out at the New York Times is based on essentially a reflection on the first two or three years I was at the Times when I was constantly like, you brought me here. Like with this sort of sort of quasi narcissistic, maybe typically narcissistic engineer view of like what it's like to join an organization and say, well, you brought me here to you wanted me to make more me's. You want me to change this organization. Why are you making it so hard? And I think and I think maybe it's only in the last year or two that I've come to really understand that like actually the whole point to what you said, the whole point is that it's hard, that there are a few different ways you can change the organization. But expectations, being honest about expectations with an institution is like that's my whole new thing. That's like when I talk to engineering managers joining the organization, when I talk to senior leaders joining the organization is this idea that says like you really are going to have to pick your fight. Because you don't you don't get to you don't get to like run roughshod over the whole thing. I feel like what's really interesting is, OK, cool, that makes sense for like a large institution, something that's been around for a long time. But like what happens with a small company? Because like I've recently started a new company, Motif, and so that's a small company. And Mike is also at a small company. Right. And like something, you know, there is something about like there may not be an institution, but you're inheriting some sort of culture and some sort of like a natural way of going. And it probably is based on the leaders of the company. Right. And for both Mike and I, we enter into a company and then therefore change the dynamic because we are potentially changing the institution itself. Because now I guess like there is the leaders of the company before, then you enter in and you become part of leadership. And then now from now on, you are influencing the leadership as well. So I was curious, Mike, like, have you experienced that feeling of an institution and then feeling about how it changed and, you know, people pinning their hopes on you and also you feeling like how much influence you could have over this institution? Yeah, I feel it's like in some ways a blessing and a curse, right? Being the new person to come in, like particularly if you're kind of coming in as a leader, right? Like the classic one I always think about as an engineer is like the onboarding docs or process where lots of people, I mean, generally, almost every engineer I know who's coming at almost every time. There's been something in the onboarding process that makes you go like, oh, why are we doing it that way? Right. And then give it a week, a month, six months, a year. And then you're the person being like, no, actually, there's a really good reason for that. And if you change it, then everything will fall over. Right. And I think that's, that's the thing that I find really fun, but also really hard, like knowing that my gut's going to have that adverse reaction to perhaps almost everything and almost being like, well, which are the ones that actually stick with me? The team seems to agree and seems to actually have a basis or maybe we like tweak it and things get a little bit better versus we tweak it and everything falls over and everyone starts crying. So, yeah, like, I guess that's, that's been my experience. I feel like what's interesting is that like, so David and Mike, both of you kind of talked about like the journey of like getting familiar with the company. Right. And so it's like, starts with like, I know everything. And then it's like, wait a minute, I know nothing. Right. And then it's like, okay, can I do something about it? And like, what can I do? And then you start to experiment around, you start to like, you know, knock on the different Jenga blocks and figure out what you can pull out. And then you're like, okay, I know what it takes to get it done. And then, you know, and then you like become matrix informed and you're like, okay, I see the whole matrix. I see how things are interrelated. I can do anything, but what should I do and at what cost? Right. And so I feel like if you've done it enough times, you know, that you're about to go through that journey. I think every step of that journey is important. You can't skip a step. And I also think that that first part where you're like, wait, why is this the way it is? I think it's a very precious and important step. Like, I don't think we should all impose all of our opinions on other people, but I feel like hearing that if you don't have like fresh people coming in who are questioning the way things are, then like essentially you're like stuck with every single inherited constraint so far and like you don't notice whether constraints have changed. And so I think it's a precious step to like be like question all constraints without ruining the institution and also like increasing unhappiness about constraints that you can't change. So anyway, that's like kind of I was like observing both of you are talking about your journeys and it's like it's a necessary part of being familiar with a company. So as you were talking, I was kind of thinking and like I don't know that I feel super comfortable with this analogy, but it feels a lot like dating. And so I think there's like, oh, can I change? Like, I don't really like is that how they brush their teeth? Like, you know, is there any way I could change that or like, you know, how much do I care about it? It does annoy me. Yeah. Exactly. Is this a fight that I want is a battle I want to fight? And as I thought of that, I was like, I don't think that people I don't think that most workers try to think about institutions as individual people as much as they should. Like, this is this is I think like what people often think about is like it's the CEO or it's like the CTO or this particular leader or that particular leader is just messing me up. And like you come in like certainly like I totally know exactly like how you think about it, Mike, when you walk into an organization, you're like, I don't like this. Whose idea was this? And like they are misguided. It's like it's like these this person, these people, but different to what I think people expect at a startup. And I'm really curious what you all think about smaller companies since you're both at much smaller companies, presumably than I am now. But like what I've come to learn about institutions working at a larger company is like it is very much like what they it's very much like the positioning that like the British royal family makes, which is it's not the queen. It's the crown and like an institution is an entity. It is an entity that has behaviors and flaws and preferences. And it is as as one of the people you're going to date in your lifetime. You know, the longer that they've been alive, the more hidebound they are about changing. And so, yeah, like I think if there was anything I wish I had known eight or 10 years ago, whatever, it would be that to actually really consider the personality of an organization as a real thing, like not as an imagined contract, but as a real thing because it is. Yeah, I think that's a helpful way of framing it. I like that. I like that approach because I feel like I've seen stuff with coworkers past and present. I'm sure I'll see it in the future as well, where people behave at work in a completely different way to how they do anywhere else in their life. Because that's how the organization and the culture or whatever has taught them to do. And I mean, sometimes you even forget there's like a particular name for this. But like sometimes I feel like you sometimes see this psychological thing where literally everyone is behaving in a way that no one really likes. But everyone thinks that everyone else will freak out if they don't behave that way because that's what the culture is and that's what the stage is, right? And the place I'm at right now is really interesting because it's been around for like 10 plus years and it's got a very high average tenure, but it's still a pretty small organization, you know, like 40, 50 people. And I find it kind of fascinating because everywhere I've been before has been either this size or smaller, but much like a much newer organization or a much bigger and older organization. So I feel like it's taught me a lot in that respect about kind of culture and maybe like inertia and also like what you can do as the outsider when you come in and those moments where you do notice that like I feel like maybe no one wants to do this and everyone's just doing it because they think they have to. And then you can give them permission to be like, look, let's all try not doing this for a week. If it all falls over, that's my fault. Like the CEO will tell me off and then we try it and then it doesn't fall over and then everyone's happy and you're like, great, right? And then sometimes you do it and it's a disaster and everyone's unhappy, you know, it's I wish I could predict in advance 100% accuracy which one would be which, but try and ever, I guess. I think what you mentioned about like people being a little bit different than like what they normally are like, right? And maybe not even liking who they've become, it's like must be some sort of average between the institution and the individual, right? Or like some sort of compromise between the two and the longer that you've been there, you have to adopt some sort of compromises to be different from who you are in order to stay there and to sustain and to essentially like find an identity. And, you know, if our job is to bring in change and our job is to push us forward or our job is to help the company adapt to new conditions, then like, first of all, that's easiest when you're new, right? You're new, you can kind of like take the blame and you can take a few hits. And also you don't have that established reputation at the institution and like that sort of brand that people expect from you. And so you can kind of jump out of that. But if you're not that, then, you know, you still have a responsibility as a leader to introduce that change and to find a way to break the mold and to give people a space and some place of comfortability to try something new. And I think that that comes back to what you were saying, Mike, which is like taking on the risk for the team. So, OK, cool. We have to change something. Everyone else is very used to the way things are done, especially at a 10-year-old company, a 20-year-old company. People who have been at the company for 10 years, 20 years, et cetera, right? They're stuck in a certain way. Everyone wants to change. You have to be the one to kind of take on that risk and give people permission and find a way to introduce something different, right? Yeah, like, I guess a question for David, like, well, I mean, it's kind of wild when you think of an organization that's like hundreds of years old. And obviously, the engineering organization is, I would imagine, not yet hundreds of years old. I mean, have you got examples of any cultural things that you have that maybe have gone way, way farther back than what you might have expected or anticipated? It's so old that it's hard to tell. I think there's probably, there's a ton, right? And like, some of them are just, some of them are just, they make a ton of sense when you actually look at what the organization does and what the institute, not even the organization, the institution, right? The 175-year institution values. And then you try to imagine overlaying the culture of, you know, the Silicon Valley company over that. And you're like, there's some things that are just like directly opposed. So, so the two things I can think about that are really interesting. And like, I sometimes say that, so the job I had before this, which was now years ago, was at Vox Media. And the New York Times is different from Vox Media because Vox Media was effectively, it started essentially as a sports blog company, right? So all of SB Nation was where Vox Media started. And so SB Nation and Vox Media were essentially like a digital product organization. Like they built a CMS called Chorus, which, you know, 10 years ago was like famous in the media and journalism industry for being this amazing content management system that everybody wanted to have and everybody wanted to know what it was. And so they built these newsrooms, they built The Verge, they built Vox.com, like all of the sort of companies, all the brands that Vox Media has or had were built on top of a product organization. So you had a bunch of journalists who essentially worked for a digital product organization. The New York Times is exactly the opposite. New York Times is a newsroom that is 175 years old, that has all of the history, all of the mistakes, all of the pattern matching of that organization. And everybody in the world knows that newsroom and it has a digital product organization built on top of it. And for years, like there was this question about, if you think about just content management systems, so digital content management system, there was this question of does the digital report chase the print report or does the print report chase the digital report? And there was a moment at which the literally the content management system of record became the digital one and not the one that was generating the print report because they've used computers and content management for the print report for a long time. And so there are a couple of moments like that where where you've actually had to watch the organization say the thing that moves fast, the thing that is more unpredictable, the thing that is read by people by different people to the people who subscribe to the newspaper is now the paper of record. And that was that was that was a huge shift. But the Times is deliberate, right? So when every year they have they announced the Pulitzer Prize, this is a really big thing at the New York Times and not to toot the New York Times's horn, but we do frequently win Pulitzer Prizes. And so like everybody piles into the middle of the newsroom, which is a sort of big open atrium, this two floor atrium and the executive editor, Joe Kahn, stands on the stairs in that atrium and announces all of the whoever has won a Pulitzer Prize. And then there's a whole litany of people who come up and talk about it, including the person who's done the writing or the photography or the editing, you know, all of and there's frequently dozens of people attached to any given prize. And it is not uncommon to be in that room and hear the person receiving the prize say this was this was a piece of work that was seven years in the making. Imagine if you took seven years to deliver a meaningful software product, right? No, it would never happen. Like it would never 18 months. Like we ran out of money. It's not going to happen. But like at the New York Times, they are willing to take the time to do two things. To be right on the facts and to do impactful reporting, sometimes on the order of years. What does that mean for, again, for the digital product organization? It means that sometimes, like even though in journalism companies, there's a split between the newsroom and the business that's really important to maintain, where one side really doesn't talk to the other by design to make sure that the reporting stays clear. Every once in a while, a cultural precept crosses that boundary. And so you can find yourself frequently debating small truths about a software product or about a product that you're going to deliver to your users. An engineer who's come in and worked at a faster moving place, as indeed I was when I first got there, can sometimes say, why are we talking about this? But it is because the institution has that behavior and culture. So like Mike, when you're talking about it, it's like you see people behaving differently. Like you can actually track how somebody's decision-making process changes as they become more adapted to and malleable to the practices of this organization in that way. And it's not bad, per se. It really isn't. It's just it's different to what we expect if we are engineers coming out of, you know, fast-moving startups. And there are reasons for it that you can question all day long, but ain't going to change. Well, this kind of comes into like constraints, right? So it's like there's like real-life constraints about like how humans work, about like how technology works, about how the news works. Then there's like company constraints, right? And then if you want to prevent yourself from burning out, you need to be realistic about like what constraints there are and then like where the chances are for opportunity for change, right? And also potentially at a place that's like so polar opposite in terms of rate of change, right? You almost have to like stay tuned into like what the rate of change is in the software world when you're like going, when you are trying to complement an institution that's like used to a lower rate of change and you have to like stay in tune on your own in order to drive that pace and to adhere to that pace. So like how do you know which constraints to like listen to and which not to and how do you identify opportunities for change if like an institution is used to going slower but still kind of demands you to go faster and doesn't know how to reconcile that without you? It's like the I got into a conversation with a colleague of mine earlier this week about norms because I said look we're spinning up this whole new mission so it's great like you know you know forming storming norming performing right so like what are we going to do like well let's just start with norming and I was like I was like you can do that but like you know if you're going to do it you have to be real honest about where we're starting right? Right and the my one of my favorite trips is like to look at an organization stated norms and be like okay what two are missing from this because it's like and that's actually the most important the most important norms are missing I feel like from the written norms or they're or they're the they're the flip side of a norm right? So it's like we are agile um we're like and this is I'm just imagining a norm for a company this is we're agile right you flip it it's like okay we're reckless right um or we're deliberate we're slow right and and it's not like one is true and one's not true it's just there's two different interpretations of that so the first I don't know I'm really curious what the two of you think because like for my for my part I think most most organizations and certainly institutions go way out of their way not to tell you and not to signal which things are movable and which things are immovable because like if everybody just knew the things that could be moved the rate like there's a limited taste even for that and so I'm curious like what you two have seen when you've thought about how to determine what things can be changed and what things can't be changed yeah Mike you want to go first yeah I was gonna say I can definitely relate to that sense that like both the norms that are missing and also the kind of I always love that saying that essentially I'm gonna paraphrase terribly but like you know your biggest strength is generally your biggest weakness right and that applies for like teams and cultures and organizations as well and also just I think the nice thing that we have in engineering right is we have a culture of trade-offs where so many almost maybe every choice is like look there's not a right or wrong answer here there's just if you do this this is the variables that are going to be good if you do this these are the variables that are going to be good and I guess like something I've kind of liked to do with the norms is when I see a problem or whatever and I see the cultural norms or whatever is I will try and do it the way the organization states that it's meant to be done and assume that all the stated norms are correct and maybe the unstated norms are not or whatever and then when that doesn't work then sometimes I'm just like well either I give up or I sort of like just try a different approach right so like you know for example I'm trying to think of a good one that I can actually say for example like a company that says like we like to do all our communication in the public right but then in the public people just don't say things because they don't feel comfortable doing in the public and then so you then you create a private space and then people say things and it's like well the stated norm perhaps or the value was like we believe in public communication but then the unstated one was like and if you can't say it publicly don't say it at all right whereas that's there's maybe like a higher one there where it's like well actually like we would rather you said it in public but if you can't it's better that you say it privately and we resolve the problems and whatever whatever and again like I feel like sometimes when you can those unstated ones that you made the point David but like when you can say them out loud and stuff it's like well which is more important that we don't use private slack channels or we deliver value to our customers right and that's like basically obvious in every company right unless it was organization would not put it that way but like often that's not the way people think about it or frame it or whatever and it sometimes does take an outsider to frame it like that for people to be like yeah like that when you put it like that when you put it like that it's kind of obvious the choice we're making and it's obvious maybe things need to change or whatever and then I guess my final point like Neha saw me doing this a bunch at github is like sometimes I'll just be like oh the organization says not to do this and I have no consensus or agreement I'm just going to do it and see what happens I'm prepared for like the entire organization to jump on me and say no Mike don't do it that way and then I'm like cool I learned the norm like I will undo we will return return to you know a state of calm and then sometimes it's the other way around where people like are like oh well we were just waiting for someone to kind of take the first step but yeah what about you Neha like what's your I mean I think what's interesting about what you're saying is like if you are coming in and you're on a new team you're establishing a new culture or you're just trying to learn the way of the ropes and there are established norms or stated norms the test balloon is just trusting it and then seeing how far you get to what you're actually optimizing for which is progress or delivering value to the customer or whatever and when you don't deliver value to the customer then you start to debug and then you start to learn about like what is actually missing and people will kind of come out of the woodwork and be like okay well if you actually want to get things done then this is what you do now as a manager as you're bringing in new people if you want to help your individuals your peers your manager get things done you then attempt to help them understand okay we write this norm but like if you want to get things done you can get them done faster this way and you are the cultural translator of those norms but all of that goes into reinforcing the norm when it comes to changing the norm right like you have a few options you can like this is why especially for leaders organizational design is so important understanding understanding what you're trying to understand what you're trying to understand what you're trying to do and then understanding what is the natural gravitational pull for the people that you're working with which is essentially the institution of like what your team is right and understanding what the difference is if you need to change it one of your options is to change around the people AI is like AI is changing one of the things that we're used to which is the rate of change of information and also how like we don't have a lot of clarity as to like what we want the outcome to be because of the rate of change of technology so you need people who are comfortable with ambiguity and energized by the rate of change right progress needs to be something that like they get energized by like they get energized by and stability needs to be something that they're they rely on less and so by changing those uh you know by introducing new people introducing fresh blood or finding the people who are most energized by that you might have a chance to make a little bit more progress against the institution in order to accomplish the goal and then the other piece that i've been i just started thinking about especially at my current organization is if you need to introduce change as a mandate from above or if you need to introduce change change as a mandate from above or as because of the needs of the business or their customer chances are you're changing a norm that is going to be uncomfortable for people and that is a destabilization for engineers whose job it is to stabilize a system a lot of engineers who create stability crave stability if you are going to and have to destabilize then you need to provide a different avenue for stability so that they have something as you destabilize the thing that they used to derive stability from and understanding what people derive stability from and how much they need in order to make the progress that you need to make progress on gives you the new world of like what you could try to stabilize you don't know necessarily the right answer but you have options now and you have you can see the world a little bit more clearly behind the like the current set of things and what people say and more about the norms and more about the norms and the institution and all those layers behind which is like what we spent this entire podcast talking about is all of those layers and how they like pile on top of each other so anyway that's like what you all made me think about today um and like what this conversation kind of like understanding how do you make change happen if like the gravitational pull of an institution is to stay the way it is right I was thinking this week about like the job of a manager versus the job of a director or a manager of managers is being like the most wonderful and difficult thing about being a line manager is that you have expressed in four to ten people the boundary line between the boundary line between the abstraction that is the business and the reality that is people and uh and so exactly exactly what you're talking about in terms of like the destabilization of folks on the ground is like you're giving that to the people who have the least like in general the least experience in the business and and you're asking them to hold that right that they're the bonds they're the bonds between sort of like two dodge chargers that are like pulling in opposite directions you know in fifth gear right so i think that the the the thing that i so i am very lucky in that like for a little while i get to manage engineers like for a very little while i get to manage engineers and i and i love it it's like it's like candy canes for me it's like it's perfect because i get to say the thing that i never say which is on an engineering team every new person you add to that team creates an entire new team right it is a completely new team i can't do that with like 125 person engineering organization my cto can't do it with a 500 person engineering organization you can't say yeah we hired somebody in such and such a team so it's going to revisit all of the engineering norms but you can do it on a team and like you and you can hold enough direct not even transitive but direct trust with your engineers to be able to be their stability and say the thing that isn't changing is is like our relationship my relationship to you as an individual human being so you bring somebody else in it's like oh they're like a senior engineer and they worked at google and whatever like what they like you know or or like this person comes from a different culture and like i don't know how i feel about that it's going to be weird it's like that's cool it's supposed to be weird it's a new it's a new team like you know that's the whole that's the whole point which has all sorts of implications for like more flexible staffing models to your point but like i think that there's such a wonderful thing about being able to express the change that we're talking about like i don't think most engineering managers i certainly as an engineering manager didn't think about the institution as a whole except in the ways it was indirectly its decisions were indirectly passed down to me like that abstraction again felt like people but it is the institution the only people who understand the institution directly are the people who are closest to the outside of it right or to the core of it depending on how you talk about it which is us right the people who have some authority and enough authority to look at it and be like that norm that norm that every the reason everybody is acting this way like you i have the context on that and it's just like somebody made a mistake seven years ago and like dropped the production inventory database and now like there's an audit committee for every change every migration that comes in like and we've been doing it for seven years and like everyone just forgot but that's the institution got hurt and so there's on this giant this giant entity that is your your company there's this little boo-boo on the on the on the forearm and you're like you're like it's okay it's okay we can let's let's you know let's add a column it's gonna be okay well on a positive note of it's gonna be okay david thank you for joining us neha thank you for being here and everyone thank you for listening and we'll see you next time thank you thanks bye bye


Mike McQuaid
Job security for engineers is dead.
Career security is what matters.
You build it by learning, changing, taking risks, being reliable and stepping outside your lane.
Your employer won’t prioritise your long-term career.
You should.
Comment Copy Link Share

• POSSE, Blog and Feed Updates

  I’ve been following what Justin Searls has been doing with his blog for some time. He’s been leaning into the “POSSE” (Publish on your Own Site, Syndicate Elsewhere) philosophy more and more. In practice, this looks like building your own version of a single-serving social network on your own site and exposing RSS/Atom feeds to other services to consume. Justin recently released POSSE Party which makes this easier by cross-posting to various social networks. I’ve complained for a while about (anti)social networking so I’m always up for new ways to use social networking less.

• The Most Important Skills Going Forward with CTO + Homebrew Maintainer Mike McQuaid

  Interviewed by freeCodeCamp Podcast
  

  Mike McQuaid joins Quincy Larson to discuss career lessons and the software engineering skills worth prioritizing next.

  Show transcript

  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.

• Software Estimation Choices

  The process of software estimation is frustrating for software engineers and those who consume their estimates. Consumers often ask “why can these software engineers not just tell me when it will be done?”.

• Package Management Learnings from Homebrew

  
  Homebrew 5.0.0 released in 2025. Walk through the major changes in 5.0.0, improving expectations based on other package managers and what they can learn from Homebrew's approach.
  Show transcript

  I like to do people putting their hands in the air in the talks because it stops you from falling asleep and it makes me more visibly aware that people are actually listening to what I'm saying. So put your hand in the air if you've ever used homebrew, okay, a reasonable number of people. Put your hand in the air if you ever contributed to homebrew, put your hand in the air if you ever tried to contribute to homebrew and I closed your PR. Sorry, sorry, yeah, so I'm, we've been, I've not been able to hear all the talks today. I do follow, try as much as I can closely what's going on in package management world. Shout out to Andrew's written a lot of very good comparative blog posts on this stuff this year that I've enjoyed. So I'm going to try and talk about today is like a bit more high level than I might say with homebrew stuff about, okay, what have we been doing in homebrew now and why and what can we maybe learn about it in other package managers. So who am I? Hello, I'm Mike McQuaid. If you want to know about me now, my website is the best place. It's all connected to social media and stuff. I don't read anything on social media anymore. So email me if you want me to actually see it or post on social media if you want to talk shit about me behind my back and feel great about it. My background, I guess, like how I've got into homebrew and stuff. So I've worked in software for almost 20 years. I've been working on homebrew for 17 years this year. I'm the project leader, which is an elected sort of dictatorship sort of position thing. So I'm a CTPO in my normal life, day job, whatever, and that sort of vaguely overlaps with homebrew but not very directly. So why should anyone care about homebrew, package managers, why I have to say? I mean, who in here cares about package managers? Okay, good. I'm glad that someone does other than Andrew because otherwise he'll probably cry. But I guess in my life, the thing that's great and terrible about homebrew is that it's somewhat taken for granted. Like a lot of package managers, it's just part of the infrastructure of how the internet works, how I do my job, whatever, right? So if you go and run, who's run Bruin still in the last week, say, okay, right? Like you probably didn't really think very much about it, right? Because you probably just ran something and then hopefully it worked. But then when it doesn't work, then everyone gets upset. Like most of the time, it only specific things are broken in specific ways for specific people. But then when it's all broken for everyone, then everyone gets very concerned. And the emotional reaction that people tend to have to when these tools break is heavy because they're so reliant on these tools. Like it's really important to them that it works. And in some ways it's, if I can be a little bit philosophical, it scares people a little bit when they are forced to actually think how many bits of the internet and tools that they rely on by all these people at all these places all around the world that they are completely unable to do their job unless all of these things connect together. And often the people who are the most involved with open source are the people who are the most forgiving when homebrew breaks. And the people who are the most disconnected from open source are the people who are the most angry and sometimes abusive when homebrew breaks. It's a bit like your toilet, really, because when it's working, you probably don't spend a lot of time deeply thinking about your toilet unless like me, you've recently been in Japan and you're like, wow, their toilets are so much better here. Why is my toilet like that? But then when your toilet breaks, then we just get shit everywhere, right? Like there's chaos. No one knows what they're doing. No one knows how to fix it. No one really wants to stick their hands in there. We have friends at the beginning of the talk. We may be at the end. So most people get very frustrated when their tools are slow. Another one, bundler is slow. Like everyone often complained about that for a good many years, right? And then what gets done, people get frustrated. So in, I feel like in many ecosystems, people get the same feedback about things being or feeling slow. They maybe don't even know why, but then sometimes the reason why it feels slow is because we get new tools. So cargo is often held up as an example of a package manager that like feels fast, right? And I've not done huge amounts of rust stuff, so I'm not super familiar, but it's, you know, that reputation for speed is something that's appreciated in the community. It sort of founds the community's expectations of what these tools should be like, how they should behave, how fast they should feel, how responsive they are. In some ways, it kind of helps to buy into like, what does that language community care about? Like the rust community seems to care deeply about building lots of tools that are responsive and fast, well-paralyzed and all these type of things. You know, a lot of the tools that I, one of my favorite tools that's embedded just about everywhere now is like RIP grep, which if you were like, how many people went down the path of like, oh, AK and then the silver searcher and finding the perfect tool to search through your code base increasingly quickly, right? Yeah. So if you went down that line, then you learned a few years ago, like a lot of these tools started to be built in rust and there just became this little niche of people in the rust ecosystem who really care deeply about just being like, I'm going to make the fastest version of X or I'm going to make a really paralyzed version of some existing Unix tool that hasn't really been updated in 20 or 30 years, right? UV, obviously that's another example now, right? Where that in the Python ecosystem is kind of reshaped expectations of what speed we should be expecting from these tools. What we can do and I think UV is an interesting example because I, again, I'm not super au fait, so excuse me if I misspeak slightly on this, but my understanding is some of the reasons why they've been able to be faster is because they've kind of dropped some support for legacy things, which tools like PIP or whatever might still have to rely on, right? And again, like, this is where things get a little bit more tricky and a bit more murky for us as like package manager like developers. It's like, okay, so what, to what extent do we prioritize speed or backwards compatibility or following the leads of other tools or maybe we have multiple tools in the same ecosystem? Who can say, right? So Bundler, right? Like, I feel like Bundler was a tool that 10 years ago I heard people complaining about how slow it was all the time and then a lot of work went into it and then now it's a tool where, you know, it's not the fastest thing in the world, but it's still like, it does not seem to get that complaint levied against it nearly as often as it once did, right? And I think Bundler is a nice example because they didn't throw out everything that they were doing. A lot of just time and effort went into it behind the scenes that meant that the tool ended up just being fast. You can add a few more things, then you'll have 10% that don't work, then 5% that don't work. And if you want to get 100% of packages working 100% all the time, you essentially have to reimplement most of Homebrew and that's probably going to be a bit slower than you have right now, right? So I ask us all to be collectively both inspired but cautiously skeptical of some of these tools that appear out of nowhere and say, "Hey, we've been able to do this 10x faster than anyone else." Because there's some stuff you can learn from that for sure. Like, we have learned from that in Homebrew. But there's also, it's very easy to make a prototype version of this which never quite gets around to iterating into something that works reliably and can be used at scale. Thank you. Why do people do that? In some ways, this reminds me, I don't know how many people ever saw the legendary Stack Overflow answer that descends into madness about parsing HTML with regex. Yeah. It reminds me a bit of this, right? Because it's like, you can parse HTML in a simple way with regex really quickly and easily. And it's like, look how little code this took. And it was really quick and efficient. And like, I'm 90% of the way to solving this problem. And then I just need to put a bit more time. Oh, I'm almost there. I'm almost there. But then if you know essentially enough about the problem states, you know that like fundamentally, you are trying to do something that is with most regex parses. I know this pearl does some special things. It's fundamentally impossible, right? And it's a similar sort of vein here, right? Where what they are trying to do is admirable, but they have taken a shortcut to do so that makes the end result essentially fundamentally impossible. So back to homebrew. Like, so the big thing we did recently in the last year essentially was if you've used homebrew, you've seen we do this kind of concurrent downloading stuff, right? So in fact, the person who did much of the work, Marcus, is in the room with us right now. Hats off to Marcus. And we also have done some work on like a slimmer like internal API and stuff like that to try and focus on this stuff with speed, right? Ruby 4.0.1, like the time it takes to output hello world to a terminal is dramatically slower than the time it takes back to do the same thing. And okay, most people like someone literally with the homebrew performance stuff I posted recently on social media, someone replied saying, in what world does homebrew's performance actually matter to end users anyway? Like, yes, this is a good point. But we still get people whining when like their shell initialization takes 0.1 seconds longer than it should have done or whatever, right? And then porting stuff to bash makes things, you know, in our case, sometimes 100 times faster than just by the time you spin up the Ruby interpreter, right? So again, like it's a weird thing and it's very project specific and it's not general advice. But again, for all of you working package managers, probably your three items are completely different. And some naive person from the outside looking in will probably have ideas of why you're slow and what needs to be fixed. But you will know what these things are and you need to make sure you put these things in front of your team and in front of contributors who might want to come in so that they actually know how they can improve this stuff in a meaningful fashion. So as a result of that, like I think homebrew with the 5.0 release, like people are complaining about it less. I think we've done a bit of a bundle of thing where homebrew is definitely not fast compared to its competitors, but it certainly feels a bit faster than it was before. And I think we have now room for understanding and improvement of how we can move forward. Right. So act two is let's think about like what we're doing in package manager land. We talked about like user expectations, performance and things like that. But I think another big part of software in general, right, like I've taken over as like a CTO relatively recently. And one of my big things is like, how can I make things go faster? And one way of making things go faster is performance and profiling and optimization. And let's like do that. Another way of making things go faster is thinking about what are we doing today? And what are the things we can stop doing? And if you can just do fewer things, you get this combinatorial explosion of once you have these different options and ways of building packages and their dependency trees and everything like that, such that it became almost impossible to debug these issues in a meaningful way and support them and stuff like that. Because again, we had limited CI infrastructure. So we're not able to just go and say, okay, well, we're going to build everything in every combination every time for every dependency and figure out if that works. So instead, we moved essentially to a model of like our binary packages where instead of going from Homebrew compiles a bunch of your machine, it's Homebrew gets a tar bowl that's already been built somewhere else and extracts that, right? So that was dramatically faster for users. It was dramatically less error-prone for users. But for power users, that resulted in us basically being like, hey, there's a bunch of stuff that you could do with Homebrew before that you now can't really do. Or at least, to be more exact, if you want to do this, you need to go over there and do the work yourselves because we're not going to do that work for you. Which, as far as a lot of open source users are concerned, is the same as saying this is now fundamentally impossible. But the tricky thing with this is now we're in the situation where, because not everything's being built on individual user machines, we need to figure out like, well, what are we going to support and what are we going to build and all that type of stuff. So it started off with just like, okay, we build one package on one platform. We pick a macOS version. We build on x86-64. Great. Then eventually we add Linux support. Then Apple came along with Apple Silicon. And then we have to do ARM64 support. And then we decided because we hate ourselves, we're going to do ARM64 support in Linux as well. And then I'm sure at some point there'll be something else, right? So like, yeah, exactly. Risk will come. I'm sure you can run homebrew on your toaster or whatever, right? So if, hands up, any folks in here who support like software on multiple platforms or more platforms than they did 10 years ago, right? It, it's a bit of a pain in the ass, right? About what works for 90% of people most of the time, right? And then that was their primary focus, right? So in homebrew, we've tried to do the same thing, right? We, we tried to focus on like, what do most of our users actually do? And what that looks like is getting to a point where you realize, well, we're supporting a bit too much, right? So we used to support, in theory at least, every macOS version. And then a few years ago we decided we're going to support three. We're going to support the current one and the two preceding ones, right? This makes people upset sometimes because they're still using their old Mac and they feel like Apple's abandoned them and now we've abandoned them and this is really unfair. But then even then, even with these three versions, what that looks like is, okay, well, does that mean we have to support all of this? Or actually all of this? Which just gets into madness, right? Because every like line here, if you're going to support that, like we're saying we expect all of 10,000 packages that we claim that will work on these are going to work on these all the time. And when it doesn't, it's a bug and we're going to fix it and it's going to break or whatever. And then it's come back to the like, well, Humber is slow, right? And maybe this isn't slow in terms of the behavior, but Humber is slow to fix bugs. They're slow to merge our PRs because we have this matrix of issues that we have to deal with all of the time, right? And what that means is you end up having to slim it down, right? So we say, okay, well, we're not going to support everything all the time. So we now don't build binary packages for the newest versions of macOS because we're like, well, A, we don't need to necessarily hyper optimize for that. B, we probably get reasonable matrix coverage from the otherwise and C, like Apple are dropping this, right? So on the 9th of September, sorry, on September 2026, we're going to stop building binary packages for Intel altogether, right? On macOS, still on Linux because that's the majority architecture there. But it's like, well, why are we doing this? Could we indefinitely build this? Sure we could, but it's going to make the project slower. And we're at a point where Apple will have announced their plans to get off this. So again, multi-billion dollar corporation, 30 volunteers, right, who receive a small stipend. But we should not be holding ourselves to a higher standard than multi-billion dollar corporations, right? On this particular, we have to fight harder and harder against that in order to have something that works for our users. And eventually we get to a point where we're like, well, this is a security feature anyway. No, no, we're not interested in doing this anymore, right? So we, we used to just go, okay, we have these features and we turn them off. And then now we have like with a major or minor release, we deprecate, then we disable, then we delete that code, right? And again, that, if you don't already do something like this in your project and you have like a clear cadence, please, it's, it's so satisfying going and having all that code that causes your pain in the ass. And knowing putting little markers and then be like in six months, I can just delete all of this mess and not have to think about this ever again. Okay. Yes. It breaks backwards compatibility, but then if only we like one day, I think someone will invent something. Let's hypothetically call it a version control system where if they wanted an old version of some code, they could in fact go back in time. I, it's a crazy idea, but I think one day it might pay off, but you know, people, again, it's this thing, it's entitlement. We don't have to deal with that and we shouldn't have to deal with that, right? Rust is a nice, good example of this, right? Where they just state, okay, here's our platform support. Here's what we have. We have tier one, tier one targets can be thought of as guaranteed to work. And in the spirit of open source, we almost directly stole this. And we now have our own support tiers in homebrew where we say, here we have our tier one platforms. These are what we expect to work. Tier two is like, maybe this is going to work. Tier three, it's probably going to be broken. And then to homebrew sucking, we want you to know like, hey, we told you to do it this way. You are doing it a different way. Someone said you are sucking. For those at the back, I will neither confirm nor deny that. But yeah, but it's important, right? If you can just write this stuff down, you will find people are a lot more likely to accept a thing which you put in a document or a section on your website. Even if you repeat yourself verbatim in issue comments all day long, they will argue with you until the sun goes home. But if you say, here's our support document, you can submit a PR with a proposal of why this should be changed. They will never do that and they will stop arguing with you. So, there we go. You are as welcome, asshole. Relatedly, we're going to enter the-- I thought I added disclaimer here, but I think it's maybe gone. But no, in fact, no, it's coming. Right, let's skip over that for a sec. Right, so act three, sustainability stuff, right? So what do we think is the most important thing in open source sustainability, right? Money? People, people. Put your hand up if you think it's money. The hecklers in the front are ruining this delightful setup. Ironically, the hecklers in the front have given HomeRue quite a lot of money to do that. HomeRue did without any money for many years and it worked fine. Code? Let's just fix all-- but we can fix human problems with code, right? We just need to write enough. No? No? No? Okay, yeah, okay. Like, yeah, we don't like-- yeah. Humans, okay. The humans, we are what matter, right? Like, if you are a maintainer or an open source project, it doesn't matter how much money you have. It doesn't matter how much code you have. It doesn't matter how many users you have. If you decide and you're the sole maintainer that you're not going to work on this anymore, this project is effectively dead, right? Someone can fork in it and they can take it on and lead from where you left off. Sometimes people do that. A lot of the time they do not, right? So, what this means is we need to take care of the humans, right? If you're in a project where you've got multiple maintainers, take care of each other. If it's just you, take care of yourself. I apologize in advance. There's a lot of self-promotion coming because I've written a bunch about this stuff. It's a topic I care an awful lot about and I'm not going to reiterate all my own blog posts, but I am just going to put them on the screen. So, you can go and look them up if you're really that bored. Right. So, the first one. I wrote this thing a while ago. Ironically, before AI stuff, robot pedantry human empathy. So, this idea of like what we should try and do in our projects is automate as much as we possibly can, but also not automate the stuff that humans are actually good at. Like, I remember I wrote this party in response to seeing projects that were like automating their messages of being like, you have made a new PR. Good job. You are valued as a human. And it's like, well, that doesn't really mean a lot to people. Let's have the robots do as much as we can. Get them to do, again, pre-AI. This is me mainly talking about CI when I'm talking about this. I love an AI. I'm not going to get into AI today. And that's, as humans, right, we can tell people like, good job. Thank you. You kicked ass. I'm looking forward to seeing another PR from you because you did such a good job in this stuff. That really makes a difference. There are people who contribute to open source for a long time just because of nice things one or two people did, right? There's a guy here at this conference most years, Cornelius Schumacher. He was my mentor on Google Summer of Code 2006 when I worked in KDE. I can say there's absolutely no way I would have done any work on homebrew were it not for him being a really good Google Summer of Code mentor, right? There's so many people throughout this entire conference, entire industry, who have stories like that where this one person made a difference and put me on a trajectory, right? That person could be you by just being nice, saying nice things, encouraging people, right? And I know we have to deal with a lot of toxicity and it's hard. You can get a thick skin. I have a very thick skin. But trying to free yourself out for those moments where you can connect with someone else and be like, good job, well done. It makes a big difference, right? Next thing, contributor funnel, right? All very brief TLDR of this. Think about you have a nice funnel on your project, right? A bit like a sales funnel of any of you know what that is. But basically just this idea of like the people who use your project, some small proportion of them will end up contributing to your project. And then some small proportion of them will contribute enough that you want to make them maintainers, right? But like if you can get that funnel to be as effective as transitioning between each stage, that's going to be really good. So one of the things Homebrew did really early on was some of the expectation that like, this is not a project run by us for you. This is a project run by all of us together, right? Homebrew had no way of doing automatic version bumps or anything like that when it first created. Max, the creator, was just like, right, I'm not going to appoint maintainers for every package. I'm just going to say, if you notice this is outdated, submit a pull request to fix it, right? That did a really good job of getting Homebrew a really, really decent number of contributors for the number of users we had. And we have a tiny number of maintainers, relatively, we have like 30. But still, that's way better than it was like 10 years ago. Open source economics, again, just restating the stuff about like money, right? Like money is not really what matters, right? Money helps with some problems. If you want to come to my RubyGems talk later today, you'll hear me talk about how money creates some other problems. But what we want to use is the money to help the humans, right? So we can help the humans do the right things. Because ultimately, I think the scarcest resource in open source is maintainer, not even maintainer time, maintainer motivation, right? And if you have a project where the environment and the users and the support structure and whatever makes you go, this fucking sucks, I don't want to do this anymore, then that project will die very soon. Cool. So, how do you do that? Say no to things. Say no to most things, most of the time, right? Like chances are, unless you hear a feature request a bunch of times or you strongly disagree, you can say no. That's fine. You're allowed to do that. Because ultimately, you owe no one anything. Read the licenses of your software. It says pretty much, and I'm not a lawyer, so please don't do this. If I fuck up your shit on purpose, you still can't sue me because you agreed to the license. Again, I'm not a lawyer. Do not do this. So, what do we talk about today? Default to fast, right? Like performance, people care about it, particularly when other tools are faster than yours. It's not a bad idea to think about performance, even if you're just thinking about performance from the scope of what you do with support, right? Having a support reality that you can publish, and you can use that to set expectations. And then finally, optimize for the maintainers, because they are the people who keep your project alive. So, one change is enough, right? Just think about today, the projects you work on, what's something you could do to help one of these three things. Make something faster, maybe clarify, even if it's one sentence in your readme, what you support and what you don't. Or set a boundary for yourself or other maintainers for how you can better support yourself as a human. Hands up, who's going to be one of these three things in the next month? Some people put up their hand while saying no, which is confusing. If you have questions, I don't know if we've got time for any now. We don't. But send me an email. Go on my website. You can find how to contact me. And thank you very much for coming. Thank you. Thank you. Thank you.

• Good Things Take A Long Time

  In tech, 3 years is often considered a “long tenure”. We maintain open-source projects for 2 years, then burn out. We start habits, lose momentum and quit.

• Homebrew and macOS Package Management with Mike McQuaid

  Interviewed by Software Engineering Daily
  

  Mike McQuaid discusses Homebrew’s evolution, open source maintenance on macOS, and practical package management tradeoffs.

  Show transcript

  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.

• Performance Reviews, Done Right

  Minimum Viable Management

  Performance reviews have a reputation for being stressful, confusing and often disconnected from reality. Too often they surface feedback that should have been shared months earlier or reduce a year of work into a single rating. In this episode, Mike and Neha unpack why reviews fail and how managers can turn them into a useful summary instead of a shock.

  They explore what companies expect from performance reviews, what managers struggle with and what employees actually want to hear. The conversation covers documenting early signals, balancing positive and critical feedback, avoiding ruinous empathy and ensuring no one walks into a review surprised by the outcome. They also discuss practical ways to give feedback throughout the life of a project, align on growth goals and handle mismatches between perception and reality. A grounded, experience-based discussion for anyone responsible for giving or receiving feedback.

  Show transcript

  hello neha how are you today i'm good how are you yeah wonderful thank you so in some companies and places new year's spring performance review season everyone's favorite time of year um so we're going to talk a little bit about that today i guess starting from that like you obviously did an awful lot of that i get help like what is it that companies want from their managers generally in performance review season okay well yeah there's like what companies want there's what i want and there's what like my reports want i think companies honestly i think they want to check the box i think in terms of just like making sure that there has been at least a point where like feedback is given and if anything has been held back and like held on to it's like a prompt for you to be like okay cool have i been holding on to feedback a little bit too long and i should be providing it i also think that if someone is not doing well and you might be getting to a point where you're like okay cool i don't know if this person is the right fit for the company then you need to have a track record of feedback given that is documented in some way and it needs to go into that performance review well the performance review is a natural regular form that is accepted as evidence that someone is like maybe not performing and i think what's easy or hard about that as a manager especially if you're new or you're just getting to know someone is you might be recognizing a few yellow flags that you don't know if they're red flags yet but if you wait until the second or third data point to be like oh shit we have like a trend you you're going to kick yourself for not documenting it the first time around but that also means that like if you are documenting feedback on someone and it's like temporary thing and it's going to get fixed it feels like risky in a way and you might be like worried about like oh do i really put this on someone's record forever if it's just a temporary thing the right way to do that is you should be documenting if you're recognizing some things and then like explicitly saying hey this is just i've only noticed this once it might go away and then when it goes away you just documented that i went away right and then you can clear the you can clear the track record but you're going to kick yourself if you like because usually what happens is you find out especially when i was early on and i like wasn't as experienced as a manager i'd like be like oh shit this has been going on for nine months and like this is not good anymore and we need to do something about it and then hr i'll come back and they'll say great oh we need to see a track record of three consistent points of feedback with time in between and you're like i can't wait another six months for this to happen with the team so anyway that's like one reason why the company might want it and also like in general the company expects you to be working with them on how they progress the last thing that you want is someone who's doing well that has like no career path and then they leave to go somewhere else because they feel like that's the only prospect they have in growing right and so this is an opportunity for you to check in on that career path make sure that this is what they want give them an opportunity to say what they want and so on what i want is i want to make sure that how a person is thinking about themselves and how others are thinking and how i'm thinking are somewhat aligned i often get very high performers who are so critical of themselves that they will be honing in on the wrong things and they'll be like oh i should have done this i should have done this i should have done this and i'm like none of that matters actually this thing mattered let's like refocus it or let's talk about why that wasn't on your radar and i think it's just like a great opportunity for a really good conversation if done right i think what reports want i think they want more feedback i think like generally they want to know if they're doing well they want to know like and i think that what is under appreciated and they don't always get from their manager is it's always focused on the negative it's always focused on what you could have done but like oh my god you had an incredible year did you know that you grew you grew in these areas did you know that you have this secret talent that you didn't know about and people can actually learn a lot about themselves through both the negative and the positive but only focusing on the positive is a great way to piss off a high performer because they're going to say okay cool you're just flattering me and i don't know if i believe any of it so you have to like find the balance even if you think the world of someone and you think that they should just keep on going you have to like dig deeper you have to think about like their future self so anyway that's a very long monologue from your perspective what have you observed as like what resonates with people and also like what do you wish you would gotten more in this and what do you feel like people don't tell you about what companies want yeah i feel like what i wish i got more of like maybe focusing on like my experiences when i was being managed because that's been the majority of my career i guess one piece you touched on before where it's like you know i'm not gonna self label myself as a high performer but i never got fired i guess um when i was at github at least so i was doing something all right and i guess i remember having a great manager there and i came to performance review time and i github the i still don't understand why really there was the performance process towards the end was you got a rating between zero and 200 and like 100 was like good anything below 100 was not good anything above 100 was like very good or whatever i remember getting like i don't know it was a 120 or 140 or whatever and my manager being like yeah like you've done a great job and i was like what could i do to you know like what could have been better and they're like nothing really and i was like well you didn't give me a 200 so unless you give me a 200 there was something right there's something yeah and you could tell like they were the type of person where they were like you did a good job i don't want to like be negative but as you said like i'm the type person where i want to improve i want to get better at my job and my craft whatever it is and as a result like if someone gives me nothing to go with i'm like well you know like i should be ceo then right like it come on like give me something right even if it's we talked in the past about like unfair feedback like stuff which only in hindsight even that is kind of more helpful than nothing else yeah like this happened i don't know if there's anything we would have known ahead of time to make it different but because it didn't have the impact that we wanted i can't give you more right yeah the other experience i had i guess on the other end of the scale with um not good manager was when i thought i was doing great right this was back when we had people not only do self-review at gethub but like literally give yourself a rating it was either exceeding expectations meeting expectations of not meeting expectations and it's the only time at gethub i got not meeting expectations and i had rated myself as exceeding expectations and i i felt like i felt terrible right like when i got that review right and you know who knows we might be able to talk about this later like i think in hindsight there may have been a bit of thumb being put on the scale where they thought i was doing a good job and their manager thought i wasn't so the manager overruled the review or whatever but like still i think the the thing i took away from that that i've kind of taken into being a manager is that your review should not be a surprise right if someone is either exceeding or not meeting in particular like they should not be going into their yearly review and reading that or that meeting or however it's running your company being like oh i wonder how i'm going to do it should be very obvious if you're not doing well because it's like you've been getting that feedback like again and again and again and it's just not getting addressed right but then the flip side equally like you know some okay some people are high performers and anxious and whatever and we can't you know you can't fix that but you should be trying your best to be like you are doing a good job well done like week after week in your one-on-ones right i mean i think that like that kind of expands or where i want to go with this conversation is expands it to like when should you be giving feedback right so it's like that mid-year or end of year i like for it to be a summary i like for it to i like to also i like to over exceed so it's like i uh i'll go above and beyond try to say like okay cool we've talked about all these data points here it's like a different way to think about it that like maybe we haven't considered before same data points known feedback different way of thinking and like that's where i like to like use my creativity instead of like being like hey there's new feedback that you never heard before you should be giving regular feedback but what does regular feedback mean i think that like obviously if every single conversation every single one-on-one on a weekly basis we're focusing half of it on feedback that's like going to be exhausting as well so what i like to do is like two things one is that after every project we talk about it and we say like what how did it go what went well how's it going right as i get feedback intermittently from other people i want to relay that um and that's like as it's going and essentially like if you think about it and you expand that that's like the life cycle of a project you your reports are working on projects at the beginning you set some goals you set some like okay cool like what's the thing that you're going to push yourself on that you haven't pushed yourself on before what's the thing that you're afraid of what's the thing that you definitely want me to give you feedback on as i like hear it what's something you want me to proactively collect on right that should be a dialogue at the beginning web project and we should have check-ins as we go for milestones and say like okay cool here's this milestone here's how i think we're doing here's how i think we're not doing here's what i'm hearing from other people do you want me to collect anything else and then by the end it's like how did it go and like depending on how senior an engineer is right like a junior engineer might have three or four projects within a six month period and so they should have like three or four at least unique points where we're like okay let's talk about how it went let's talk about what could be better so that the end at that mid-year end of your review it's a summary i also like to do another thing so i started doing this when i was managing managers which is so now i can't control all the feedback they're getting i can control the feedback my managers are getting but now the reports need to get feedback too and the problem is that like we're as engineering managers engineering directors etc you're just like always working you're working on the project you're thinking about how the project is going um you're thinking about company politics you're planning a year ahead of time it's so hard to sometimes take a step back on each individual career um and so i like to do like a perf review gut check like at a halfway point or at a quarter point so like every quarter between like a review period i will use my team meeting to be like okay cool write down all of your reports write down the rating that you think that they are on track for and then write down on a scale of one to five how surprised you think they'll be to hear that and if they're taking this exercise seriously it is statistically likely that at least two or three people would be like oh they might be surprised to hear this right and that's because you haven't gotten around to it or you plan on getting to it or like you just haven't gotten a second to think about it my job as someone who's managing managers is to create space for things that don't happen right and so like if they haven't had the wherewithal or the time to think about like how these individuals are doing or like feedback that might be held on to i want to create time and some sort of format to get people to think about it and then act on it right yeah so i guess one of the immediate follow-up questions for me on the managing manager stuff is and this is something it's not an experience i've had myself yet um but i've seen it a bunch and it seems really hard right so i'm hoping i don't get it there but like how do you handle when there's a big mismatch between if you're managing someone and then they think this person on their team is doing a great job and you're like they are not doing a great job right like i love this a lot yeah i'm sure let's assume like for the sake of this argument that like you're right because like you've had a bunch of feedback from a bunch of other teams and blah blah or an objective measurement whatever like how how do you go about handling those types of conversations yeah so it's like essentially what's happening is i'm talking to my report my report saying they're doing excellent work and i'm hearing otherwise and i'm like you've got this information i've got this information we need to reconcile it and you cannot ignore the fact that i'm hearing otherwise right you are not allowed to ignore the fact that i'm hearing otherwise so either everyone is wrong besides you or there's something to hear and sometimes that fits into one one-on-one sometimes it doesn't and sometimes there has to be multiple sessions where i'm like okay look this is what i'm hearing if they're like that's not possible that's not true i will go and i'll say i'll go find people to be like cool would you be willing for this manager to talk to you and hear from you directly and almost prep some people because they're like unwilling to give feedback directly and they'll only give it to me and be like well it's not an option at this point you need to go say something and so getting the manager to talk to those people so um i have an example in mind and i'm trying to think of how much i can redact this or not but yeah i had like i had a report who really thought that their report was doing well i'd heard otherwise i heard a lot of cases otherwise that person was just like oh those are like i heard about that but i don't think it's a big deal and i was like well i do now you have to talk to them all and so i made this person talk to them all they still came back and they're like i heard each individual case and if you pick apart every case there's flaws in each one and i'm like doesn't matter the collective impression is that more people don't want to work with this person anymore and you are now accountable for that impact and you need regardless of whether you think that's true or not these things have happened and people need to work with this person and people need to be excited about working with this person so either you can agree with the feedback or you have to figure out how you're going to change this right so i try to almost shift it from like i think some people get really protective over individuals and they're more defensive because it's a feedback against a person and so i try to shift the problem to a person to like a tangible problem that's like more objective that you can talk about which is like okay cool well do we all agree that people need to be excited to work with this person okay well that's not true so now you've just solved that problem right yeah and then ultimately if they're not giving feedback and i'm seeing that there is a disconnect then there's a problem with my manager yep yeah and i think that's that's the trickiest time and i think feel like that's the one that i've seen on various sides a bunch of times right is when you have someone in management where they have maybe it's ruinous empathy maybe it's conflict avoidance whatever it may be and they they sort of know there's a problem there but like they're like oh but this person's gonna be really upset or really disappointed or i guess like sometimes there's a bit of a friendship there and they're like oh i don't want to do that to my friend or or also i guess the flip side right where it can sometimes be i was just you know this person's my senior peer i just became their manager like they've been in this industry a lot longer than i am like who am i to tell them what to do like i think there's all sorts of reasons that can happen but yeah i just think it's it's just so important to give that feedback and get it out there like a little experiment i've kind of been doing is whenever i get a new report i basically try and set expectations literally in our first one-on-one i'm like look what we're gonna do is because it's neither of us are gonna like this particularly but like i'm gonna try and say something critical every single one-on-one just so we'd get in the practice of like knowing what it is and usually the first one-on-one is just like the a safe go-to i have is like you know more about some of the stuff than i do and you you rarely contradict me when i'm wrong please start contradicting me when i'm wrong because you know more than i do right so it can be almost like a sort of backhanded critique when it's like i'm criticizing myself as much as them right but yeah i think just like getting in that pattern of behavior is really helpful because i think that's maybe sometimes where it comes from is if like critical feedback is this you know great class in case of emergency thing that you only ever do on rare occasion then it's like the first time you're going to do it it's going to be terrifying in every relationship but if you just get used to doing it a little bit all the time then it's like you can have that conversation well i mean i think it's because if people are just get really used to the like the first time that they hear negative feedback there's a consequence associated with it right away and like their job might be on the line right so it's like if you normalize hey i'm going to give you constructive feedback and you can do something about it and then you actually your career gets better because you did something about it because we had time and we're talking about it frequently then they can have a positive association with negative feedback right or constructive feedback i also think that like you know sometimes people build up that conversation in their head and there's just like a lot of prompts you can use to help you kind of phrase it and even think about it to be like hey something i'm concerned about is or uh something i feel like i've been waiting for more data on is so it's like okay cool it's not a concern yet right like this is not like negative feedback i'm just like i saw two data points here and like i want a third one before i say it's like a thing you can still tell someone right like hey it's just a first data point so if it's a trend it's not a good thing if it's like something that's just like a one-time thing it's not a big deal right you can start talking about those things more regularly so i think as a manager you it's helpful to sometimes have those prompts and then have a way to phrase it so that you don't have to build up the conversation in your head right yep yeah and my experience has been with high performers often as well like you only need to tell them once right like but so if you wait till you've like amassed this portfolio of like oh you've been doing this thing every one-on-one for the last year and i didn't like it right then it's like well you wasted like 11 and a half months where for a lot of people right away exactly you could just say something exactly right and i think that's the other part of as well i think you're totally right to like suggest that you know there's prompts and ways of doing it and optimum communication styles but i still think with some of this stuff it's like look if if you can't think of a good way to say it you probably still are better to say something even if you have to you know apologize for how you phrased it or whatever afterwards then not say anything at all right because it's just that when that builds and you also see in some again i've not really seen this directly while i have been a manager but being friends with enough managers you see that resentment start to build as well where sometimes they're like getting really pissed off with someone on their team and that person doesn't even know that they're pissed off yeah yeah right like and it's like well you need to get that release out there and like start communicating with that person because it's not fair for them for you to be kind of like building up all this frustration that they don't even know about and you're not dealing with just because you aren't sure how or don't feel ready or able or whatever it may be i think uh it's like the most annoying phrase to receive and like my favorite phrase to provide um knowing it's going to annoy them but like you know when someone's complaining about someone your report your peer you're like have you told them why are you telling me it's okay to tell me if you're like using it as a way to process what you want to say and you're like looking for validation as to like whether that's something that is worth mentioning the answer is like almost always yes unless like i don't know you're kind of coming out of left field and you're not thinking about things correctly but it's like okay cool well i go tell them then like go it's it's been with me long enough i want this release for my plate like go tell them and as an individual you can catch yourself if you if you're ranting about someone and then any peer any ic also gets this right you get someone who's like ranting to you about someone else and like the question should be have you told them or if you want to be more open what have you told them so far right how is it going when you give him this feedback oh i haven't said anything hmm sounds like we should do something about that right um yeah i remember another funny github interaction is you know perhaps being like british and dealing with americans or whatever um like i remember one time saying like getting someone to read some message and say um you know do i seem too mad in this message and they read it and they said you don't seem mad at all and you clearly are very mad so like you should probably make your message maybe sound a bit more mad because this person is gonna read this and think that like there's absolutely no problem here and there is clearly a problem here because you you're very upset right like yeah i think that's the part of as well and i i think you know it's maybe it could almost be its entire own podcast about ranting or venting or whatever and i think being on either side of that i think it's tricky because there's definitely times where you need to catch yourself or help catch the other person and be like look is this how is this helping are you making a plan right now or are you just speaking to someone about this who is not going to push back because they agree and that makes you feel like you've sort of dealt with the problem you have you haven't you're just you know preaching to the choir and they already agree with you and you actually probably need to like suck it up a little and go and have the difficult conversation with the person who's not going to receive it like me being like oh yeah i hate them too yeah like and by all means get your friends or peers or manager or whoever or people you respect or people mentoring you to help you figure out how to have that conversation but like that's not a replacement for having the conversation yeah a hundred percent and i think like i i've also seen leaders get upset that people are talking about things in private channels or in secluded spaces i want to differentiate between like people need safe spaces to process feelings um the ownership is that on an individual basis you if you're going to distract everyone with your feelings you now have the responsibility of helping people get back to their jobs after they had to listen to you rant about something right so what is the you just said this right like what's the point is the point that you're like trying to get validation to see whether this is like worth saying something about is the purpose that you are still trying to articulate why you're feeling and you you're someone who processes out loud or are you just interested in distracting everyone with your feelings right like if if that if you if it's not one of the first two or i'm sure there's a few other reasons that i can't think of then it's like it's distracting and then on the other side as a friend who's listening to someone rant like no one wants to solve right away right rude right like you have to be like that sucks but then if you have someone who's consistently not doing anything about it you're just stuck in that position forever and like uh maybe you're okay with that but like that person needs to go do something about it and like if you're a real friend then you're going to be like okay cool ready for you as you process these emotions out loud but i want to make sure you're doing something about it and you gotta help them out of their comfort zone right yep yeah and i think that's the thing and sometimes the situations where either they can't do anything about it or they've they've done it they've delivered the feedback to the person that person's on a pip or that person's getting an aggregate performance view in three months or whatever right and then sometimes it's helping the other person or yourself and sometimes like you know it could be a report as well in those times being like i i'm here for your this is very frustrating situation but us talking about it for 30 minutes every week is making you feel worse it's not making you feel better it's sort of just you're picking the scab like every week and maybe you need to just move on and wait for the next step and put this on pause for three months until there's something we can actually do about it and then we can like revisit but for now you're just upsetting yourself right and as you say often upsetting other people the team you're whoever you're talking to right yeah and like there's exceptions to every rule and like these are all just we're speaking from experience that we've been in these situations before i'm probably on both sides right and so it's like there are cases where this is totally true um something else i was thinking about when it comes to doing reviews like why do we even do reviews in the first place right like for me i don't necessarily you know sometimes these reviews have like eight to 15 questions that you have to answer and like i ain't about that every company has their own process and they have like a way that they like to do things but i really like to boil it down to just a few things which is like what are three things that you did in the last period that you're really proud of that like maybe you didn't think you could do and you did and like tell me about those things right not three things that went well because some of those things are in your wheelhouse and like love that for you but like what about pushing yourself what are three things that you thought were going to go fine and didn't go and like you want to own that and you want to begin a conversation around it and then like what do you want to push yourself on and like that i think i want to hear that for my reports and i think that my reports owe it to me to hear what i was surprised by positively surprised not positively surprised negatively surprised right and like where i want them to push themselves right and be like hey months every two months every three months every six months you should be doing something risky and you should be trying something and if we agree on what you try on then i can help mitigate that risk for you and i can make it a safe space for you to try that and then we can agree on something and then you're growing and you're trying something and as our manager if i'm actually thinking about where you could grow into and how you could be there's like a thousand paths so i want to make sure that out of my box and out of your box we pick one that like is mutual and we're like okay cool we agree on this one this is both something that we want we both like see the potential of this let's like try it out together and i feel like that's that's so much better of a conversation than like well you did this and it didn't go well like i kind of want to skip past some of that and talk about what was surprising and i really do want to hear about people like what comes to mind when you think oh i could have done this better right and like some of those things as i said earlier in the conversation are not a big deal and i like want them to focus on the things that matter right yep 100 i think that's a nice summary to finish well thank you neha like i feel like i've imparted a huge amount of euros than this time but yeah and good luck to everyone else who's working on reviews an arduous process we didn't even talk about collecting feedback and the importance of that but like good luck and uh you know the next period will come again so you always get another chance oh yeah to that see you again soon bye

• Bootstrapping gem.coop Governance

  gem.coop was announced on Monday. As part of that announcement it was mentioned that I was helping gem.coop set up a governance process, continuing the work I’d first started helping with on RubyGems.

Mike McQuaid
This was a good read. Review is good but it does slow things down.
With async PR review, I prefer the “✅ with comments” review. Unblock the person from merging with trust they will read and resolve your comments first.
https://apenwarr.ca/log/20260316
apenwarr.ca
Every layer of review makes you 10x slower
We've all heard of those network effect laws: the value of a network goes up with the square of the number of members.
Comment Copy Link Share

• Minimum Viable Engineering Management

  When I first joined GitHub in 2013, there was no engineering management. They had people in engineering leadership roles (some with titles, some without) but no dedicated managers to check in with regularly. Initially I thought this was great. Over time, I realised it was actually pretty terrible. As a result, when I started my own company and was a manager for the first time, I wanted to ensure we provided “minimum viable engineering management”. What this meant was providing the necessary support and monitoring infrastructure to ensure great performance while letting managers, present (me) and future, spend most of their time on individual contributions.

• Mike McQuaid: If You Don't Like It, Quit

  Interviewed by Breaking Change - Hotfix podcast
  

  Also available in swear-free/bleeped version on The Changelog and Friends podcast There will be bleeps.

  Show transcript

  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.

• RubyGems Contribution Data with Homebrew's Tooling

  There’s ongoing discussion about recent changes to access in the RubyGems GitHub organisation. If you need context, first read Open Source Turmoil: RubyGems Maintainers Kicked Off GitHub. My goal is to share contribution data to help inform the conversation.

• Ruby on (Guard)Rails

  View Slides
  The guardrails I love in the Ruby ecosystem and why you should use and love them too.

• Why Open Source Maintainers Thrive in the LLM Era

  At the time of writing (June 2025), the prevailing view in the software industry is that LLM-powered AI is either completely useless or will imminently destroy all software engineering jobs. As you might expect, the reality is somewhere in between. In this post, I’ll share my journey with LLM tooling, from reviewing an early, internal alpha of GitHub Copilot to my current daily usage of Cursor, ChatGPT, and the latest Copilot offerings. My perspective is that of a startup founder (of Workbrew) and long-time open source software maintainer (of Homebrew)

• Mike McQuaid on the Greatest Lessons He’s Learned in Over 16 Years at Homebrew

  Interviewed by GitHub Podcast

  Homebrew’s project lead Mike McQuaid joins Abby and Andrea to unpack what it really takes to sustain one of the most-used developer tools on macOS and Linux.

  Show transcript

  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.

• Politics at Work Without Losing Your Soul

  Minimum Viable Management

  In this episode, Mike and Neha are joined by Denise, an engineering leader and former colleague from GitHub and Pivotal, to unpack the reality of workplace politics and why ignoring them is not a neutral choice. Drawing on Denise’s LeadDev talk and hard-earned lessons from management and senior IC roles, the conversation explores political capital, information asymmetry, allyship and the idea of “table flips” as a finite currency.

  Together they discuss when to spend influence, when to hold it back and how privilege shapes who gets heard. From advocating for promotions to using power responsibly on the way out of an organisation, this is a practical and candid look at how to navigate work under capitalism without burning out or selling yourself short.

  Show transcript

  Hello, everyone. We are back. Neha and I have mostly recovered from plagues, I think. And we decided, instead of you just listening to us cough for a full 30 minutes again, that we could maybe bring on a guest who's appearing so far not to be coughing. So, Neha, do you want to introduce our guest we've got today? Yes, this is Denise. Denise has worked with me and Mike at GitHub. But I first saw Denise do a talk, I think, with RightSpeakCode a long time ago, and I was captivated. Denise and I, I don't know, at the same time or not, we both worked at Pivotal as well. So, we've had some shared understanding and we got to work on the same team. I got to manage Denise for her first time as a manager, which was, I think, a new experience for both of us, actually. I was just new to managing managers as well. And since then, she's gone off to do amazing things everywhere. And most recently, I had the pleasure of watching Denise do a talk at Lead Dev that I felt like struck such a strong chord with me because it was stuff that we talked about a lot and stuff that Mike and I have talked about a lot. And it's about like politics in the workplace. So, if you watch any one talk on the Lead Dev website, her talk is called Leading Sustainably When Everything is on Fire. And I'll give my own summary if you want, and then I'll let Denise kind of talk about herself and highlight any other points you wanted to make. What resonated with me was that, you know, as managers, we navigate information asymmetry on our team. And as you can see, she's used every word very carefully. You don't let everything through. You don't prevent everything. You navigate it. You figure out what to let through. And that asymmetry and acknowledging that that asymmetry exists is a very big part of being a manager. She introduced this like currency called table flips. So, it's like a way to quantify political capital in terms of like how you could spend it. And usually you think about like accruing it instead of spending it. And so, Denise really flips the table on how to talk about it. And then I think there was another quote that I wrote down because I loved it so much. And it was about making, especially when you're trying to think about what to move and what not to move, you can't move every boulder. And so, she said, it's about making good tactical decisions around the deployment around political capital. And so, I just feel like I love talking to Denise about these things because every word she selected is like very careful and very intentional. And she really thinks about the agency of choice and the level of responsibility we have when it comes to these things. And so, that's why I'm really excited to have Denise on the podcast. Denise, do you want to add anything and share anything else that you thought about when you were making that talk? Yeah. Thanks so much to Nehan Mike for having me on the podcast. Very excited to be here. It's been a hot second since I've done any podcast, actually. So, this is super fun. Yeah, I was asked by LeadDev to do the talk back in January, February. So, the worst thing that you can do to me is ask me to do a talk like nine months in advance because I will just be spiraling about what I'm going to talk about for nine months. And so, I think I landed on the topic of basically wanting to talk about politics at work, which is obviously a huge topic. And I'm still relatively new to management. I haven't been doing management for decades. I've been doing it for a couple of years now. So, I didn't feel like I was positioned to give the, you know, like, here's the end-all guide to navigating politics in the workplace. I didn't feel comfortable coming at it from that angle. So, it was extremely, the whole talk was extremely informed by my personal experiences of making mistakes in this area. And then learning from those mistakes and applying what I learned to my management practice to try to help others avoid the same kind of mistakes that I made early career about not understanding, not understanding the basic premise that everything you do at work involves political capital. And I know that is an uncomfortable thing to think about for a lot of us, especially a lot of us who come from very technical backgrounds. We think that things should be meritocratic. We think that things, we should be judged on the fruits of our effort. It's our, you know, objective, measured, measurable outcomes, that kind of thing. But my experience over the last, you know, decade plus of being in the tech industry has shown that repeatedly, that's not true. Repeatedly, it's unfortunately not good enough to just do a really, really good job at work every day. As you get into the higher ends of the career ladder or want to go into the leadership track, building an understanding about workplace politics is actually a pretty critical survival tactic, I think both for yourself and eventually for the team that you will be responsible for. You know, what this makes me think about is like when I first met Mike at GitHub, he immediately was looking for a way to add value because I like, I'm suspicious to anyone who's nice to me, which is due to childhood trauma that we are not going to talk about right now. I was like, what is Mike up to? And I actually think that Mike's really good at building political capital. He kind of understands the game, especially when new people come in. And I'm kind of curious, Mike, from like, inside your head, how do you think about that? Yeah, I guess like, it's funny, because the way you were talking about kind of table flips and stuff earlier, like, the word I've always used internally is like karma, not that I believe in kind of like, philosophical karma, or whatever, on a real religious sense. But I definitely like see in the workplace, right? Where if, if you're someone who just like takes, takes, takes all the time, then generally people stop wanting to help you. And if you're someone who gives a lot, then you kind of build up or political capital or ability to table flip or whatever you want to call it. Right. And I guess I, I realized in GitHub, as GitHub kind of grew, I guess, in my case, for context, for anyone listening, I joined when it was about 200 people, I left when it was like, just under 4000. Seeing like, as the company gets bigger, you, as Denise said earlier, like, you can't just do a great job and hope that everyone notices or whatever, like, you have to, like, be a bit more strategic about how I'm going to get things done. And who's, who do I need to make happy to get this over the line or whatever it may be. And also just sometimes being like, okay, I'm just going to do this and maybe break some rules. And it's going to piss people off. But do I have enough karma in the bank that this is going to stop me getting fired? Right. Because again, for me, like that was the other part of the currency is that like, on one side is success, influence, getting what I want done. And then the other side is, everyone hates me, I get fired, whatever it may be, right? Yeah, I think so. And I think that like, you're good at sussing out someone who's new and kind of figuring out how they fit into the big picture. That's like, also a really critical part about being able to navigate a company is like, figuring out what they are, like, Denise had this like, diagram of like, okay, cool, you might have political capital, but does your manager have political capital? And what about like, their peers? And like, it's not enough for you to do it yourself, you have to figure out how everyone fits into the puzzle. So Denise, I was kind of curious, if you had any like, major realizations around political capital and leadership, either recently, or like one that's like, stuck with you for a really long time? My current manager uses the phrase, I am cloaked in political capital all the time as in kind of a healthy way. He recognizes that as a white guy, you know, in management, there are a lot of things that he can get away with. And that was having this kind of conversation with my manager over and over again, this past year has been one of the sort of like, you know, inputs into the talk, I spend quite a lot of time pondering how, you know, white guys specifically do have more ability to, you know, kind of do what they I also realized I didn't do this on purpose, the mug that I have right now. The just like, it's a cartoon of a cat saying, I do what I want, putting like middle fingers up, which I completely just grabbed by accident this morning. That's the goal. That's the goal in life. Yeah, exactly. This is what we all aspire for in a perfect world where we all have a perfect symmetry of political capital access. That's what we can all do. But one thing I have been thinking about more recently is if you just have political capital and nothing else, then like, what is your responsibility? So I'll give like, try to make that a little more concrete. I've seen people get to the end of their journey with an organization where they sort of realize, all right, I've, you know, I've learned all I can here. I've done the work that I want to do here. Maybe it's time for me to move on. But sometimes when you get to that stage, you still have a lot of political capital left in the bank, actually. And so one of my peers recently left the company, also a white man who really like leaned into this. And I thought that was so cool. So he, first of all, he's, he's in the EU where they have super, super long notice periods. So he was like, he had a three month notice period, and he absolutely just lit things to fire on the way out. And I thought that was so great. It's kind of like it can sometimes the fact that the company knows you're leaving can sometimes dilute the impact of you doing this, because they just sort of write you off as like, oh, he's out the door anyway. He doesn't really care. So maybe let's not like, you know, really deeply engage with the question he's asking. But I did think it was really cool how on the way out, he would just turn up to AMAs and be like, hey, remember when six months ago, you said this was going to happen? What's the timeline on that? And still, you know, diplomatic courtesy of like, you know, not not directly calling people out, but I'm still asking pointed questions and trying to create some accountability. So I don't know, like I, it's an interesting time, I think with like, the industry is is obviously changing a lot. I think a lot of the rules are being rewritten in an age when every company is getting on the AI bandwagon and the standards for, you know, like what constitutes good performance are changing a lot. I don't know that I necessarily want to get deeply into AI. But I think it's one thing that I've been thinking about since the talk is, yeah, just sort of this theme of like, if you have political capital and nothing else, if you don't have motivation, if you don't have a reason to engage with a long term vision of your team or your company, then what are some useful things you can still do? Yeah, I also think that's maybe where politics kind of gets a bad name, right? Is because people like the, I guess, the case study example of what people don't like about politics is when people exercise political capital purely for personal, like, let's say monetary game, right? So I'm just trying to get promoted and a pay rise and a bonus and more headcount purely so I can like build my empire. And like, I think that understandably makes people feel gross if it's done in a way that only benefits you, right? Whereas, even while you were talking, Denise, it's like, I, I'm too much of a kind of scaredy cat to light things on fire too much on my way out of places, but like something I, I remember I did do when I knew I was kind of getting to the end of GitHub is I basically had a list of people who I felt were like in my org who should have a promotion and I'm like, I'm going to go and dedicate a ridiculous amount of my time to trying to get those people promoted on the way out. I was able to get a bunch of them promoted and that felt really good, right? And again, like, that's the type of thing where it's like, you know, if you go from advocating for one promotion to 10 in a six month period, that kind of like burns some bridges in some ways, but also in other ways, obviously like builds bridges and you're left with kind of a sense that like, Hey, this is good. And also it's, it looks less naked. It doesn't look like I'm trying to almost like put all my pawns in the right places or whatever. When you're doing that on your way out, it looks like you're just trying to build people up. And I, I guess I would say to people who might be listening, who are like, I don't know, not unsure about getting involved with politics or whatever. If, if you're still unconvinced that you have to, then another way of looking at it is like, well, if you're like trying to be a good person and trying to help people at work, then you can't do that without political capital. Right. And if, if you almost like see a bunch of people who are playing politics and winning in a way that you don't like, it's like, well, maybe you got to play the game. If you want to like, let your team win. Right. I just wanted to respond to Mike's point and say that it's so interesting hearing Mike talk about advocating for other people to get promoted because at GitHub, you were never a manager. You were a staff engineer and then later principal engineer at GitHub. And that's so cool because the talk that I did at LeadDev was mostly pitched at engineering managers, but definitely like a huge part of it is that people at the senior plus level also have political capital. Everybody has a little bit, but I wouldn't really expect junior and mid-level engineers that, you know, you, you put your own oxygen mask on at that stage, but at the senior plus levels, everyone does have a role to play in thinking about how you spend your political capital. And you absolutely, this is one of the, the ways, like when we talk about leading from the back of the room or leading without proper, without, you know, formal authority, like this is one of those things. Yeah. And I think like also going back to what Mike said around why should I engage in politics if it's so icky, it is like, there's a natural equilibrium and there's like a natural way that like things will fall into place. And if you don't like it, then you have to get into the ring. Right. And let's be real. It is not going to be the natural equilibrium of a company is not going to be in a way that like benefits the employees the most because that's like not, you know, uh, that's not how capitalistic societies work. Um, and so obviously it's going to be a way that benefits the business or something else. And so if you want to like as a manager, or as you grow in the leadership chain, you want to put your thumb on the scale on something. Now you can't put your thumb on the scale on everything. And it, because if you put your thumb on the scale and everything, one, it's diluted to, you spend it all at once. And three, you're going to be putting your thumb on the scale on things that don't move. And that if you keep on doing that and you expend energy on something that doesn't change, you will burn out. And so you have to know, like, you know, one is understand accruing political capital level one level two is like spending political capital. And then level three is like knowing when to spend political capital. So you don't burn out as part of it. Right. I think like when you were talking, Denise, I was like, okay, so as a non white man, I may not have the same political capital as someone else does. And I want to motivate them to use political capital in a certain way. Like how do you motivate someone else to use political capital? And like, how do you assess it and then like understand and motivate someone else to use it? Mike, my question for you, which is like, not fully spicy, but a little spicy. Have you ever felt like someone was approaching you and like asking you to like blatantly spend your political capital on something? And like, when have you been like, no? And when have you been like, yes, yes, I have. Often that person was called Neha. I was, I was going to joke about that earlier. Neha and I would sometimes have these like little strategies in our one-on-one where it's like, look, is this going to come best from like a principal engineer, an open source maintainer, like the best manager GitHub's ever seen, the best director GitHub's ever seen. Almost like part when we had the same goals in mind, almost like which of us going in first is going to have a better impact there. Yeah. And like, obviously, you know, like I, as a white man, I'm not aware of the, the level of privilege I have in certain ways. I don't know what it's like to not be me, but you know, there was a certain amount of that in our discussions as well, right? Where you, you know, people in the organization who are like, look, like if it's coming from a woman of color or a white man, they're going to react the same. And then, you know, the people in the organization who it's like, yeah, that person's going to instinctively have their backup for people coming in who don't look and sound like them. So maybe someone else goes in first and that, you know, I think that's the thing. Like for me, it's all about trying to be pragmatic, right? Like I think, uh, Denise and I were talking a little bit before we got started actually about how, so GitHub staff engineer, apologies. I'm going to butcher his name, Sean Godek. I think something like that. And he works, yeah, I think he works on a team with a mutual friend of the podcast, human long nowadays. Um, but he had a post recently where he was saying software engineers should be a little bit cynical in which one of the things that kind of made me think reading about it was like about how often like I see software engineers can be so incredibly idealistic about like, that's, we'll have the code and the tech and the architecture can all be beautiful and pure and whatever. But then like, Oh, politics and like maybe even like making people like me at work, like, Oh, that stuff's kind of icky and messy. And like, I'm going to be sort of cynical about that. And just his idea of being like, you know, it makes a bit, you know, you should be aware of the politics and how that all works in an organization. And you do need to be like, not a hundred percent cynical about it, but if you're like a hundred percent idealistic about it, you're going to, I guess, as you said earlier, Neha, like burn out. And to your metaphor about table flips, Denise, like, that's what I really like about that. Right. It reminded me that metaphor as well. Like I'm sure all of us had a wide variety of teachers in our schooling experience. Right. Like, and the difference between the teachers who like lost their shit regularly and you would just tune it out because it was just happening so often the teacher, the teacher who like you were taught by them for five years and only once did they properly lose their shit. And when that happens, you're like, shit. Oh dear. Like this is actually serious. Yeah. Yeah. And I feel like that's the same thing with like table flips at work. Right. Like if you're the type of person, like even aside from political capital, like even almost like the persona you present to your coworkers, if you're just the type of person who just like flies off the handle and it's like, this is unacceptable. This is going to destroy the company about like every single thing. Then people just stop listening to you. Right. But if you can like pick your battles and when you have the political capital, when you've got the right people in place, when people don't think you're just doing it out of self-interest, then I feel like that's when you really get stuff done and can have an impact on the stuff you care about. Right. Yeah. It was really clear. I think to build on, you know, echo everything Mike is saying to build on that. I think I've heard a lot of people talk in the past year about how it's important to bring my whole self to work or I want to engage authentically with work. I want to live my work life in a way that feels true to me. The term table flippers, Neha, do you know where table flippers came from? Do you remember the channel at Pivotal? It might've been after my time. Oh, okay. Okay. So a brief history. Anyway, tell me. Yeah. Table flippers. Like I didn't just make that up actually. That was like the most inside of inside baseball for any people, any women and non-binary people who were at Pivotal R&D, mostly R&D, I think from like 2016 to maybe 2017, 2018. That was the name of a back channel that we had for all female and non-binary employees that there were like hundreds of people in there. This was like the most active back channel that I've ever seen at any workplace, but it was a place to vent and for people to find safety and security in, you know, numbers and shared identity. And one of the most common themes of discussion that came up in that channel were, hey, I had a really great interaction with this, with my white male colleagues. Sometimes it would be negative stories as well, but a lot of it was positive. A lot of it was like, here's a story about allyship. Here's a story about a time that someone on my team really got my back. And so through that back channel, all the women and the non-binary folks in the company kind of learned who are the safe men, who are the safe people we can go to. Yeah. To sort of engage for, like we didn't, we never thought about it as political capital back at that time. But essentially that was what it was. It was like a whisper network of the safe people that you can go to, to ask for political capital and help and that sort of thing. So that's, again, like another one of those, like, here's my very, very personal experience shaped into that, woven into this like larger commentary about, you know, basically like how to, how to survive at work, how to survive under capitalism. I actually edited out a thing in the talk. I wanted to go on this like four minute rant about capitalism, but then I was like, I'm already at 27 minutes, but 25 minute time slot, I need to cut this. But I, I think a lot of like bringing for, for people who, you know, if, if you hear the phrase, I want to bring my whole self to work and I want to live authentically at work, then maybe one way to do that is to figure out how you can send that signal to people who have less privilege than you and figure out like, you know, allyship obviously is a word that we've had for a very, very long time. And I think this is, this is basically an extension of that, right? It almost feels like oversimplifying to just say like, be a good ally. But I think like that is still pretty relevant. I don't know, even in 2025. So I think that's, that's a big part of it. I think I've been pretty lucky in my career so far to never have to directly ask anyone for that help, but to have people come out of the woodwork over and over again, or to just, just show through repeated behavior and repeated action that, you know, like by, by putting messages, a really good example, actually, of a way to indicate this is if you do AMAs, if, if company has like question section with our, come ask our leadership, anything, you're a woman of color, might not be totally safe to ask question like, Hey, what about those RSCs that you promised everyone? But maybe safer for, for someone who does have a little more privilege to say like, Hey, I've heard from a number of my peers that, you know, we're worried about this RSC, you know, whatever sort of frame it that way. Yeah. I mean, I've definitely done that before. Well, I think there's a few interesting layers to it. So now when I'm trying to identify if someone like has like ally potential or like ally interest, right? Like even when you do all of these trainings, these DINB trainings, if you're doing them in a group or in person, right? Like at the end, they'll always be like, Oh, what's your commitment? Right. And like, most people will be like, I want to be more aware of it. And so those people in the trash, like clearly you don't want to change anything, but if someone's like, okay, cool. I want to try one or two things. I think I'm going to try this. I'm like, okay, cool. This person thinks they want to try it. Let's like give them a taste. Right. And so I have like this small list of people in my head that I'm like, okay, cool. Next time I want to ask a question in an MA, I'm going to approach them and I'm going to ask them if they would ask on my behalf. Now, at most of the companies that I've been with, I've accrued political capital pretty quickly and I don't necessarily need someone else to ask a question for me, but that's not why I'm doing it. I'm doing it to see if, Hey, is this person an ally and willing to do it? And if they do, then I will go back to my table flippers channel and I will be like, Hey, I asked this person if they would ask a question for me, they did. Right. Like action, completion, check mark, right? Like we've got one check mark or maybe I'll wait until like three check marks before I like go back and tell the people. But like, I've had also people come to me, you know, we got to work in a team, which was very unique at some point because it was like 45% women and non-binary and it was like 40% people of color. And so finally, once we started bringing in some white men into the group, like cis white men, they would be like, Oh my God, this feels weird because I feel like I'm taking someone's spot. And like, this is all also kind of like shit you can't fully say on stage, but you know, fuck it. Um, uh, I would tell them you have a very important role. Like if you think that there's no place for you on the team, there absolutely is. Because if I like, I mean, it would be kind of great to just have like all women of color on a team, but like at some point you were going to have to connect with the rest of reality, which is like something you talk about in your talk, Denise, like you can't be in a bubble. You need to be in like a porous time-based bubble. And if we're going to re-engage with the world and they're not going to be at the same level of awareness and thinking and practice around, uh, weighing opinions equally, we're going to need some help. And so those people who say like, I don't know if this is like, is it okay that I'm on this team? I'm like, yes, we're going to ask you for help and you're going to do it. And if you're ready and you're committed and you're interested in experiencing something that you might not be able to experience before, because the composition is so fundamentally different with people with different backgrounds, you can have this privilege if you're willing to put in the work. And I absolutely would put everyone to the test. Now it's not like, Oh, cool. I've like marked them for like three tests or whatever, but those things just come up naturally because capitalism. Right. And so my favorite one that always happens is that, I mean, as you go higher and higher up, your manager changes all the time. So it's like every single time I got a new manager, they would look at the team and they'd be like, this is different. I can't tell what it is, but it feels different. Is that bad? And I'd be like, army of white men go. Right. And so like, Mike and others have like a very important responsibility, which was to take those questions and to answer with the late laden with privilege that they naturally had without even thinking or doing anything. I'm just like, Mike, can you just answer the questions and just say truthful things? And all of a sudden, you know, the eye of Sauron would move on. Right. So I don't know if you realized the full extent to, I mean, I was pretty transparent with you, Mike. I'd be like, Mike, you're a white guy. Like, can you do something for me? I don't recommend doing that all the time. But if you get to know someone pretty well, you can be a little bit more transparent about it. I think I was somewhat aware. I think like jumping back to something you talked about earlier, Denise, like, is like the whole, those of us who've been through employee surveys and it's like, you know, do you feel you bring your whole self to work? Like, it's funny because I used to kind of get grumpy about those for lots of reasons. And I've decided now, I think there's like a sweet spot in there, right? Where like 0% bring yourself full self to work is bad, but also in some ways, a hundred percent is also bad. And I think often like people who are, yeah, like people like me grew up as, you know, engineers do the computer science degree, like, you know, like just have a very stereotypical background into tech. It's like, to me, bringing a hundred percent of my full self to work is like, I get to monologue for 30 minutes about code quality. I get to interrupt people whenever I feel like it. Cause I like doing that. You know, it's like all of these things where it's like, well, maybe bring your whole self to work is not doing some of those things. And maybe like being like, I feel like I can bring 75% of myself to work, but actually that's a better version of me than my personal preferences. Like that feels like it sort of loops in with both of what you were saying. And also like this, like kind of like, oh, politics is icky. Like, I feel like I'm compromising myself by doing this. I feel like I'm compromising myself by like asking the question that I don't really care about, but Neha cares about. It's like, well, you know, you're compromising yourself all sorts of ways, right? Maybe this could be a way that you could do so that would actually be good and help people build a better organization and build a better team and all of this kind of good stuff. And maybe like shave off some of your round edges, which, you know, you may or may not have learned in therapy is probably a good idea everywhere in your life, not just in the workplace. So. Yeah. I've learned over the years that I have a better time at work if I'm intentional about what percentage of myself I do bring to work and what percentage I sort of leave at the, you know, at the door. Well, work from home, so not really. But yeah, like one exercise that I used to have, I still sort of do, I still have like my, you know, direct reports do is, especially if you're unsure about what you want to get out of work or if you're feeling lost or confused or you're like, I think I want to leave this company, but I don't know what I want to do next. It's like, sit down and literally make some lists, right? Make one list that says, what are the experiences, skills and relationships that you want to get right now? And make another list that represents what can this job, this like current team, current job with no changes, like what can this situation offer you? And figure out what's in the intersection between those two lists. And that was just like something that I had people do to have them start to think a little bit more intentionally about work and make them realize that you actually do have a little more in your control than you might realize. And the more that you can kind of strategize about how you're going to relate to this job, the less you will find yourself losing to, you know, like hopefully we slow the roll of burnout, A, like that's sort of my interest as a manager, but B, like I want you to, you know, like accept that capitalism is just going to extract from us, right? That's something that none of us have control over. But what you do have control over is like, what do you actually want to extract from your current situation? And then tell me, tell me so that as your manager, I can position you to help you gain those skills and experiences and relationships. And I really try to emphasize relationships because, you know, like look at us three sitting here, like we don't all work in the same place anymore, but relationships are such a huge part of what you should aim to take out of every single job. Because there will be a couple of good people that you work with that you might want to work with again in the future. It's not just, you know, like learn Golang, learn test-driven development, whatever that stuff, like you will eventually learn those things. And I think that when it comes to, you know, like the higher, when you're at the senior, like management level and you're like, everyone goes through the same thing again, we're like, oh God, I don't know what I want to do next. Like, I don't know. I'm not getting, I'm not learning anymore. I'm not growing. What, what, what should I be doing? So probably do the same exercise again, right? Like, but, but think about what are the things that you're currently bringing? So what, what is a hundred percent of yourself? And then like, what is the strategic 75% of yourself that you can afford to still give to the job? And maybe what's the 25% that you need to find and you need to express it in other ways in your life? Like, you know, go, go join, I don't know, improv comedy or something. I haven't done that, but go, go, go do something in your personal life that enriches you and ticks those boxes because it might be, um, unstrategic or it might be dangerous to do some of those things at work. Yeah. I think that, I mean, personally, I feel like I'm never going to bring a hundred percent of myself to work because y'all don't deserve it. Um, like I'll give you a piece of it, um, but not everything, right? Some things can be left to myself. I think what I really liked about what you said, Denise, is that it is really critical to be intentional about what you're doing this for, what you're getting out of it, what you're getting out of these experiences and every single job or every single place you go to is a CN box. And so I even feel like high school was a CN box. College was a CN box, right? Every job is a CN box. And if you feel like you're not growing anymore, test the limits. And if you've never been involved in politics anymore, if you have enough capital to be wrong once or twice, then you can test something out and try something new. And like, understand that the first out of the first three times, two of them are going to be failures. Maybe you get beginner's luck, but you may not necessarily have that continued streak. And if you do have a continued streak of being right every single time, you're not trying hard enough. Like there is no reward if you don't take risk. And it is important to be strategic about how you go about doing that. And when you start to have a purpose and you have something that you're experimenting with, things get fun again and you like can get into the flow. Yeah. That's kind of like a lot of different lessons that you can learn, especially if you might be on your way out and you have some political capital to spend, you can start experimenting a little bit and learn something about yourself on your way out too. Thank you both. That was an amazing conversation. Went a bit differently to how I thought, but this is the beauty of having a guest on who you don't know quite as well as Neha, who I know too well at this point. Thank you so much for joining us, Denise. Thank you, Neha, for being here as ever. And thank you everyone for listening and catch you next time.

• How and why I interview engineers for Workbrew

  In the last two years building Workbrew (a remote-first, enterprise Homebrew startup) I’ve hired 5 engineers (and a hybrid PM/EM). This has been my first time being a “hiring manager”. This post explains how I interview and why I do it how I do.

Mike McQuaid
In case you missed it in Homebrew 5.1.0 release notes: we’re doing a short user survey to inform future development.
https://docs.google.com/forms/d/e/1FAIpQLSeeNd7T0Zj9zOl8Y2MP1YITPk_qNUIP5knfCqSmOH2oB2O_UQ/viewform

docs.google.com
Homebrew User Survey
Questions for current users to inform future Homebrew development
Comment Copy Link Share

• Two Years Building Workbrew, a Remote-First Enterprise Homebrew Startup

  I left GitHub after 10 years to cofound Raise.dev. After an early failed experiment building IoT developer tools, we pivoted and built Workbrew: an enterprise-friendly layer over Homebrew, a project I’ve maintained since 2009 and led since 2019. Two years in, we’ve raised VC funding, built a remote team, and have happy, paying customers. Here’s what I learned so far.

• How Ruby Went Off the Rails

  Interviewed by Emanuel Maiberg on 404 Media
  

  What happened to RubyGems, Bundler, and the Open Source drama that controls the internet infrastructure.