The Changelog: Software Development, Open Source - Homebrew and package management (Interview)

Episode Date: October 7, 2016

Mike McQuaid joined us to catch us up on the latest in Homebrew and the recent 1.0.0 release. We talked about no more `/usr/local` — Homebrew moves to `/usr/local/Homebrew` to keep `/usr/local` cleaner, auto-updates, the growth of the Homebrew community and how it has grown to almost 6000 unique contributors, and more.

I'm Mike McQuaid, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 223, and today, Jared and I are joined by Mike McQuaid, the maintainer of Homebrew. We talked about Homebrew's 1.0 release recently. We talked about a lot of the changes happening. There's no more user local. Homebrew now lives at user local Homebrew to keep user local cleaner. Homebrew also auto updates now. And in the seven years of Homebrew, the community has grown to nearly 6,000 unique contributors. There's also talks of Linux Brew, which is a fork of homebrew,

joining in lots of fun stuff happening in this package manager space for the operating systems. We have three sponsors on today's show, Rollbar, TopTal, and Linode. First sponsor of the show is our friends at Rollbar. Rollbar puts errors in their place. Head to rollbar.com slash changelog, get the bootstrap plan for free for 90 days. And today I'm sharing a conversation with you that I had with Paul Bigger, the founder of CircleCI, and he talked deeply about how they use Rollbar and how important that tool is to their developers. Take a listen. One of the key parts about doing continuous delivery, you don't just have to test your software, but you have to constantly keep track of it.

You're going to be doing deploys 10 times a day or 20 times a day, and you have to know that each deploy works, and the way to do that is to have really good monitoring. And Rollbar is literally the thing that you need to do that monitoring. You need to make sure that every time you deploy, you're going to get an alert if something goes wrong, And that's exactly what Rollbar does for CircleCI. Oh, that's awesome. Thanks, Paul. I appreciate your time. So listeners, we have a special offer for you. Go to rollbar.com slash changelog, sign up, get the bootstrap plan for free for 90 days.

That's 300,000 errors tracked totally for free if roll bar trying today head over to rollbar.com slash changelog we're back we got a fun show lined up got uh Mike LaQuade here from Homebrew. Homebrew fame. Obviously, Homebrew 1.0. Jared, what do you think about that, man? I was excited. I think our whole community was excited. It's a big announcement from a big project that many of us have relied upon for years and years. And it's awesome to see anything hit that 1.0 milestone. So, Mike, congratulations on the big release and welcome to the Change Dog. Thank you very much.

Thanks for having me, guys. Yeah, no, it's an exciting time, I think, for most of the Homebrew team as well, because we've been sort of a bit haphazard with the version numbers. If you look at, I went through and actually took the time before the release to go and tag all the old versions through there. And some of them are, you know, multiple versions in the space of a week. And then you have years, I think, between some versions and they roll a little bit arbitrary. And now it's kind of giving us this chance to sort of become a more real software project and start doing like semantic versioning and start kind of thinking about how we're doing our release process and try and have that stable base for people to be able to rely on.

Now, Adam, you had a homebrew show back before I was a co-host of The Change Log all the way back in 2010, episode 35. You want to give us a little bit of background on that? I wish I could, Matt. I wish I could remember six years back. I can barely remember last week or last month. But just based on our own show notes, me and Wynn, when Wynn was part of the show, and it's kind of funny because now Wynn works with Mike, his manager manager of somebody's manager,

or something like that at GitHub, but we caught up with Max Howell, talked about Homebrew. I think the show was a lot more loose then. I don't think we were quite as standardized as we are now, where we kind of go into the history and kind of go deep like this. It was a bit more of a wing it kind of show i guess then but fun talking to max i can't remember a single thing we talked about i know we talked about at least mac beer and scrabbling because that's what the notes say so there you go but you can check that out at changelog.com slash 35 or

scroll all the way back or pretty far back in the list of podcasts that you have there in your listener. Yeah. So it's been a long time and definitely kind of a catch-up show, but a new show, an introduction to Mike. Mike, we like to get backgrounds, origin stories, kind of the roots of where you began in the programming trades. So can you tell us how you got started and what got you to where you are now? Sure thing. So I guess I first got interested in computers and computer things being young and when my parents brought a PC home. And it was always... I guess my parents learned that they could pretty much get me to do any chore, including mind- numbing spreadsheet entry if it was on the computer

and and i was just i don't know i was always fascinated with the thing so when the time came to go off to college i went and studied uh computer science and yeah and basically just got more into i guess open source while i was doing that there was our curriculum was quite kind of unix focused so i ended up kind of using linux on my desktop and all the fun that that produced uh back in 2007 using gen 2 to compile everything from source so take like days to get my system ready in 24 hours hardcore well i mean i don't know if it was so much hardcore as just masochistic but it was certainly i certainly learned a wee bit along the way about you know how how software gets put together and how things kind of build and how they fail and

stuff like that so um yeah i kind of dabbled with that through uni started doing little bits of open source programming kind of by myself like publishing stuff on my website or whatever but not really collaborating with anyone and beyond kind of university group projects um until after i guess i was sort of got a bit involved with the gentoo kind of bug tracker and stuff like that and then my uh summer after graduating i did google summer of code on the kde project uh which is the the linux like i guess a desktop environment or like the kind of gooey and stuff like that um and yeah and i kind of worked on that for a few years and that that was great fun and then in the end i remember the very so i had a job um where i was doing like cute the kind of toolkit it's based on which everyone thinks is cutie but it's actually cute which is

always interesting when you refer to someone who doesn't know this as oh they are also a cute developer and then yeah so there you go um but yeah so i was doing that so part of the job a lot of clients back then at least were wanting stuff that would run on at least two out of three platforms windows mac and linux so i would i had like an environment for each of those platforms and so i had i had like an environment for each of those platforms and so i had kind of a mac that i kind of had picked up because of that and i didn't really use it for much and then i remember one day i had some friends around we were trying to watch a dual monitor set up and i was trying to watch a dvd without tearing on my new nvidia card or whatever and and i couldn't get a dvd to play and this was in 2008 i think uh you know 2008 2009

and i couldn't get a dvd to play properly and i was just like that was the day i realized that my my days with desktop linux were done and so i i pulled out the mac plugged it in and then that all worked perfectly and then sort of slightly moved my approach over to the mac was doing some kde on mac stuff before i kind of gave up um and then kind of used mac ports a bit and then i ended up creating this while working on this thing called mac ports dummies which kind of sort of led me a little bit into homebrew mac ports dummies was a way of like sort of pretending that a bunch of stuff was installed that was provided by osx and then i kind of knew, he was a friend of a friend. And we

ended up kind of meeting up and going for a beer and stuff like that. And he was like, Oh, yeah, you know, there's this homebrew thing I've kind of made, you should check it out. It sounds like it's sort of in keeping with your interests. So I guess that was about 2009. I started working on homebrew. And I guess since then, I've been kind of working as a maintainer. And yeah, just never really stopped. So that's an interesting way to go to the mac i guess my story was a little different i was on windows and it just was a better machine so i just kind of went to the mac and didn't look back but uh you know moving to the mac is that's kind of interesting story to to kind of get to the mac basically

yeah it's it's weird i guess because when i talk to a lot of people who i guess being involved with a project like homebrew and i'm also kind of really obsessive about like osx styling like i still use textmate as my main editor just because i mean as much as i love things like atom and sublime they don't look like quite right right so everyone assumes i'd be one of those people who's been on a mac since i was you know purist yeah exactly like since what year was that because i mean you might be a purist well so i guess that was 2000 and yeah 2008 or 9 i kind of yeah so the first mac i had was on leopard on 10.5 also the first version of osx that homebrew supported and so yeah i've been on it a wee while at this time,

but I feel like the really hardcore folks are the people who had the OS 9 machine at home. Right. I was a little bit sooner to the party than you, but not much. In fact, my path is very similar. Only I was on Ubuntu in college. Started off in Windows in high school,

Ubuntu in college, and just got sick of of having to deal with mostly device drivers and wi-fi back then um and the mac was tantalizing i think it's probably 2007 and leopard was also my first version that being said man i'm far moved away from text me at this point are you at least on text mate 2 or are you like real old school yeah i'm on text me too and i'm i'm kind of scratching my own itches quite a bit more like you know i've made a few bundles for it and all this type of thing but it just fits pretty well with with my workflow so as i say i try other things but then i just there's tiny

little things that annoy me and i might just be too old and far gone at this point to stuck in my ways so give us a little bit of the context around, you gave us how you met Max and you started contributing to Homebrew and using it a lot. Give us the timeframe around Max's kind of transition. Now you're now lead maintainer. Of course, it's a huge project with thousands of contributors.

And many of that is because of the way that you used to contribute formula, which has recently changed. We'll talk about that soon. But help us out with the transition where you became the man when it comes to the homebrew community and project. Well, I mean, I guess so the lead maintainer thing is quite recent. Like that title, at least, is literally just something we sort of decided shortly before homebrew 1.0 um so max i guess like like any open source project and we try and build this into the way we kind of run homebrew

there's the expectation that people will kind of come in and come out and stuff like that and i think max just ended up having a different job and was spending less time on homebrew and some other people stepped up and were spending more time on homebrew and you know in the end i think he just ended up sort of drifting out and other people ended up drifting in and when max left so he he was the kind of you know the lead at that point and when he left we kind of agreed that we'd sort of have a sort of democratic situation where you know we would decide things more or less by committee and stuff like that and i think that and there's definitely a lot of open source projects where that that goes pretty far i think where we struggled and where we felt the kind of pain

of that coming up recently was when what i was kind of contributing a lot more than other people were and when you have the idea that almost it's a democracy and everyone gets a vote, like it doesn't. With the way I guess I read a thing about the governance models and the best one, you know, the meritocratics are really loaded term and it's not. I don't think it applies in open source but that what people have described as the meritocratic governance model is almost like you you have more decision making power based on doing more work basically so you know and that's not commit counts or lines of code changed or whatever but basically if you're more involved if you're spending more time in the project and you're kind of leading the direction a bit more then you probably have a bit more say.

So I think the lead maintainer thing came about because I was essentially kind of filling that role. And, you know, to validate some other kind of complaints, I think, that were made, I was maybe sort of overruling or pushing through some things and not really operating by the committee side of things. And my understanding was that people were annoyed that I was doing that, whereas I think actually,

like having talked about it more and come to the lead maintainer thing, what was annoying people more was actually this disconnect between the reality of like me kind of basically leading and other people feeling like they couldn't overrule me on things. And yeah, I i guess you know i'm sure you've all read and heard about you know all the stuff about implicit and

explicit power structures and githubs as a company has had its movement through there as well and i think that's basically what the move has been is that it's moved from being an implicit to an explicit thing and it's just as a result it's made a few little things a little bit easier. So there was an explicit transition then from Max to you or? Well, no, I guess so. The transition was from Max to, I guess, every, to all of the maintainers. I think it was five or six of us at that point. And then that we grew up to, I think, 13 maintainers. And then the transition from that model to being me with the kind of majority agreeing that that was a good move.

I'm sitting here on the contributors tab. I mean, it's funny you say that, too, that it wasn't just contributors in terms of code, but contributors in terms of effort across the project, whether it's thought, leadership, governance, whatever. I think that that's something that the contributors tab doesn't really reflect very well. But one thing that I was thinking about on the contributors tab is I'm looking at Jack Nagel, I'm looking at you, I'm looking at Adam V, I'm looking at Max. And so for others that kind of line up there, I kind of wish we can overlap, you know, see Mike and you and Max and Adam, see all of your graphs kind of in the same timeline because just kind of like looking at them,

I can see where Max was having fits and starts during a couple, during 2012, and you seem to like start to get more involved in terms of contributions. And then it seems like when Max dipped away and stepped off to do his own thing or go to Apple or wherever his path has taken him is when you got more involved in the same thing with Jack

and a little bit the same thing with Adam as well. So it's kind of interesting to look at the contributor graph that way. Yeah, and it's interesting as well because as I think you were, I suspected you were going to mention later on anyway, there's the, we've split into two repositories now. So you've got the Homebrew Brew,

which is the package manager and Homebrew Core, which is the formula. And we kind of split the history between them as well. So you can kind of see the kind of, there's quite a difference in contribution patterns between the two. And there's the same sort of faces in there, but you know, there's someone who,

people who are very, very active in one and not really in the other. And I think that was the big thing where like Max particularly was kind of always most active in the package manager itself. And I guess lately I've been sort of similar. I've kind of, you know,

had a reasonable number of contributions to the packages, but like not nearly as much as some other people. And in the last, the 1.0 release has been more of a thing around the package manager rather than the packages itself. And so that's where my focus has been the last, I guess, few months, certainly. to this, uh, meritocracy or voting based things. And you, you all found that it wasn't moving forward at the pace or the, you know, the desired, uh, pace that you guys wanted it to. And then because you were already kind of implicitly acting as a leader, or as you thought perhaps overstepping your bounds, but people actually appreciated it. Um, did you end up just kind of

like with this flat structure where it's, you know, Mike McQuaid and then everybody else, or is there underneath that structure, is there a group of core maintainers and then everybody else? How exactly does it structure now? So, I mean, we have what our kind of lingo is, and I realize it varies from project to project, is what we call a maintainer is basically anyone who has commit access. And historically, that's always been based on you get commit access to both repositories, you don't just get it to one.

That may be something that changes in the future if we have people who are very interested in just the package manager and not the packages or vice versa. And then we have contributors, which are anyone who's ever submitted a single commit to any project basically within the homebrew umbrella and then we have users obviously which goes without saying um so we've yeah so we've moved from a model of being all the maintainers are like at least on

paper kind of on an equal footing to being i'm i guess technically in charge. But then the way I've had a good manager in a workplace deal with this stuff in the past is that they basically only invoke their manager status when they have to. So they will always try and have a discussion and win the discussion on an equal fitting. Well, not win, but convince other people of their point of view and i i feel like it's the same thing with us now that the lead position is mainly just there to be able to have me be able to say sometimes like okay well we need someone to make a decision here we have two sides who are kind of equal or equally like there's some stuff that is important in the direction of the project and this is a feature that other people may not feel passionately about, but I feel that this has to go in. And it's important for us to have this feature, even if the bulk of other maintainers might disagree on that front.

And maybe part of that is because we started gathering analytics, which I don't want to get too much into but you know before that a big part of it would be i mean i i was the person who did the most i guess talks at conferences about homebrew and stuff like that and have kind of traveled around and met a lot of users and there's a certain amount of stuff that it doesn't it doesn't turn into mailing list post it doesn't turn into issue tracker but you you speak to the same sort of power users again and again and you hear the same complaints again again like in person and then some of that has sort of driven the kind of i guess product direction of homebrew maybe a bit more because you just realize like okay this isn't people are not filing issues because they're confused about this this is just something that they find annoying and people generally don't find like file issues about just things that are like annoyances they follow them about things that are

actively broken or whatever so let's touch real quick on github's relationship with homebrew with regard to you know employing you and you're the lead maintainer and is this this officially sanctioned work or is it are you still doing it like completely on the side and then we'll take our first break and on the other side we'll talk about uh the new stuff in homebrew specifically we'll probably start with the split repositories, but how does GitHub play into the mix? So I guess I've been at GitHub coming up to three years. So certainly the majority of my time working on Homebrew has not been at GitHub.

And GitHub, similarly with my previous employees, really like they have, I guess, paid me to work on Homebrew on occasion when I have had google summer of code students through github and stuff like that or homebrew google summer code students which have been blessed with github i've spent work time on that uh in terms of like day-to-day work like i i don't in theory at least work on it on github's time if i'm blocked waiting for something for like five minutes i'm waiting for a test run to finish i'll go and fire through my home emails triage give a little reply whatever

and then there's something that is going to or is currently blowing up and will affect github employees because we use homebrew fairly heavily internally and then i'll fix that but i don't generally do kind of the day-to-day kind of Homebrew work during GitHub time. So that's mainly my kind of evenings, weekends, spare time, etc. Very good. Well, I think that sets us up. Let's take a break. And on the other side, we'll talk about what is new with Homebrew 1.0.0.

We'll be right back. I talked to Daniel Reed, head of design at TopTow about their new new expansion into TopTow Designers, doing for designers what they've done for developers. We talked about why TopTow works for designers, and this is what she had to say. As a designer, or as any kind of creative person, the big overarching question is always, like, how can you find inspiration? And for me personally, and for a lot of creatives that I've spoken to, it's really about traveling, exploring, and being accountable for your own career. And I think as a top-tile designer or a remote designer in general,

the ability to be able to switch up your lifestyle, change contexts, meet new people, have new ideas sort of infiltrated into your life by having that freedom and flexibility is something that's absolutely fundamental to doing great work. For any designer that is wanting to pursue their skills, to be accountable for their life, to have new challenges, that's the real power of TopTel I feel. You're not just stuck with one product, one company or even one agency but you can choose to work on multiple occasionally

or a range of different clients. And I think that that keeps you fresh. It gets you involved in new technologies, different people, and is really fundamental for being sort of switched on as a designer. All right. That was Daniel Reed, head of design for TopTile. To learn more, go to toptile.com slash designers. That's T-O-P-T to toptile.com slash designers.

That's T-O-P-T-A-L dot com slash designers. Tell them Adam from the Changelog sent you. And now back to the show. All right, we are back celebrating, cheersing even, on Hover 1.0 with Lead Mediator Mike McQuade. See what I did there i like that and mike we like to hear all that's new fresh and new like we haven't covered homebrew for many years you don't have to go through the entire history of the source code but uh kind of just want to

camp out on what's new with the official 1.0 release and there's a lot of highlights we have the uh separate repos We have the community site. We have the move out of user local, user local homebrew. We have the software conservancy, software freedom conservancy thing. So we'll kind of work our way down through the list, but let's start with where we left off,

which was that you guys split the repositories up. And one thing about the original Homebrew repository, which, by the way, it's still out there. You guys have it under brew, under legacy-homebrew, is it was always one of the most forked and starred and watched and contributed to, probably has the most PRs, perhaps, of almost any repository on GitHub because of the reason

that not just, like you said, not just the package manager itself, the source code that makes up Homebrew is in there, but also all the different formulae, which is how, you know, the descriptions of how packages get installed and uninstalled. So when I first saw that you guys split up into different repos, I thought, oh no, they had this great star count. They had this great fork count. It's kind of this statistical legacy there that now is going to be broken. But that being said, y'all have set up analytics over the last year or so that gives you better stats than just the stars and the forks for actual usage. So start off with telling us the onus behind splitting the repositories,

and then perhaps give us some insight into the analytics that you guys have been tracking. Sure thing. So I guess the main onus is the problem with Homebrew before was if you wanted to get, say you wanted to get a new version of some package, you run brew update to kind of update homebrew's kind of definitions and that also updates the package manager the problem with that is if you want the new update of something and we have made some change on master which breaks something for you then there's no way you can get the new version of open ssl or whatever

and not get the broken thing as well. So we've kind of had that goal for a long time to be able to separate the package manager from the packages. And I mean, that's what every other package manager does, to separate those two things out so we can provide some degree of stability. So that was the first step in a process, which again is kind of noted in the release notes

that now we kind of jump between tags. And so you can, if you're kind of a homebrew maintainer, then you continue to track the master branch, but everyone else kind of jumps between 1.00, 1.01, et cetera. And that gives us time to be able to do more QA on the package manager itself while still having that rolling release approach for the formula. In terms of stars and all that type of stuff like yeah that still breaks my heart a little bit i still leap for the star count but you know it's it's slowly getting its way up on the new repository and stuff like that and it it is useful to be able to see stuff like github's kind of contributor graph and see how that varies on the package manager compared to the packages because that's interesting and another thing on there which is a wee while off probably still is we're trying to get the package manager

there's another thing called linux brew which is like running homebrew on linux and stuff like that and having the package manager be separate means that we can we can separate out our package definitions for but still have the package manager itself be cross-platform support all platforms stuff like that and it generally just provides it as a nice tool who knows maybe one day it might even be bundles of ruby gem you can use to kind of access your your stuff and but yeah nowadays we have as you mentioned the analytics that was introduced i think it was march or so and that basically provides us with the ability to see, we can't see any stuff about individual users.

If I wanted to see, okay, this particular user, what have they done? But that's not available to us because we kind of just use a random UUID that people can reset at any time. And so we track users just so we can get kind of user counts. And so I've got kind of the analytics dashboard open right now.'s you know it's kind of a slightly weird mapping from what it's normally

used for but it basically lets us see what commands people run like in proportion to each other what packages people are running what versions people are running and the really useful stuff for us is what is like the percentage breakdown on stuff like OSX versions? So then we can prioritize the support on different things. And also, what are the most popular packages that people install? And what options are they installing with? So again, we can prioritize options and things like that. So as a whole, it basically just provides what analytics tends to do for any piece of software, which is it lets us inform our future design and inform kind of what things we focus on based on the stuff our users actually

use, rather than our speculation on what the users use, which is something we didn't have before. GitHub stars and watchers are indicators, but they're not exactly, I don't think those things are for maintainers. I think they're more for the general public to show some, I mean, because I can't give you that deep of insight like knowing watchers and stars those are important but it's not giving you deep enough insights that you need as a maintainer these days yeah i agree like it's not you know you certainly can't have like oh well we did this we shipped this new feature and we got

you know five percent more stars that doesn't really that doesn't really help us whereas when we see we ship this new feature and our error count's gone up from you know 0.01 to 0.05 or whatever and stuff like that like that's more of the type of things we're concerned about and it's particularly useful when you know when we can go and see if something breaks like we periodically go through and you know do some porting or when a new version of osx is out or whatever and it's useful to be able to go through all of our packages and be like okay well this thing's broken on the new version of osx but no one has actually installed this since march so let's not go and spend like three hours trying to fix this piece of software that no one is actually using we can just remove it instead we call it sending it to the boneyard

which means the definition is still there if someone wants to pick that up at a later point and pull that through then they can do that that's it's a little bit easier than kind of navigating through the git history if you're not a git whiz and it lets us kind of push away the kind of maintenance burden of that for a wee while at least. Well, you wouldn't think twice when delivering an application that you do for work or whatever about installing error tracking or installing monitoring or something like that. So it's almost the same case for, you know, Homebrew is that you need something to track what's happening so that you can make good decisions for the future, right? You wouldn't

think twice. Yeah, exactly. And I think that's what it comes down to for me is i i have used a lot of these tools well i mean across i think every workplace i've been at i've used some sort of kind of metrics tracking and again people i guess people sometimes think that metrics tracking is just google analytics and like oh well they don't have google analytics installed so they're not tracking metrics and so well actually they're probably tracking metrics in the back end so they're not tracking metrics. And so, well, actually, they'll probably be tracking metrics in the backend. And they're not doing this because they're selling your personal information. Well, I mean, some companies are doing that

because they are selling your personal information. But in Homebrew's case, it was kind of disappointing to see one which, well, yeah, exactly, we're not. I mean, we've specifically designed it so that we couldn't, even if we wanted to, kind of get anything that would be commercially viable out of this.

So the thing is, is that it's kind of disappointing when you you release some stuff like the analytics because you get some people who go and express kind of obviously some sort of solidarity with like okay i understand why you're using this and most homebrews users are developers so there is that but then there's this very vocal minority who, you know, who escalates beyond that. And it becomes how dare you have this? How dare it be opt out rather than opt in? My reasoning, obviously, for it being opt out is because you can gather better data if you're tracking the majority of people and not just the subset of people who decide to opt in. They may well have different behavior and stuff like that, which means that you're not able to make as sound decisions but yeah so and that vocal minority you know that they got very upset on some of them on uh hacker news and reddit and stuff like that and then start sending me

personal emails telling me to you know do all sorts of things and it's not yeah it's it's not unpleasant and it is with hindsight it's funny and i i'm lucky enough to have a thick enough skin that it it didn't bother me too much but i mean it it is depressing that we still are in 2016 have to deal with stuff like this because i mean if there's any of those people who and i did say this to someone who um who emailed me i mean that that's what kills open source that's what drives open source maintainers away and kills successful open source projects like me and well i had moments but certainly some of our other kind of major maintainers had to be talked into staying in the project at all because they were you know and several of my we talk about diversity problems

sometimes in open source as well you know several of my co-workers who aren't just you know young white men who i talked to about the homebrew thing is they just said that sounds awful i would never want to be involved with a project where i would have that abuse for something i do in my spare time to try and help out other people and i think it is you know it does seem to be getting better and we do seem to be as a community recognizing that like this behavior is not acceptable and this behavior is not what we how we build software and but you know we don't necessarily have all the kind of toolings and institutions and everything quite figured out how to kind of stop stuff like that when as you say it's you're an email or a twitter message away from someone starting to be mean. Well, sorry that you had to go through all that, Mike.

In light of the change and the fact that you guys have had it running for a while, would you mind sharing some stats with us, like users or popular packages or what fruit have come from these analytics? Yeah, sure. So, I mean, I can see the kind of active users, which I guess is someone who's run a homebrew. So there's, I think, 2,000 people who've run a homebrew command in the last 30 seconds or so. Nice.

There may be more than that. And then I can see kind of the version breakdown. Interestingly, there's still a lot more people running on pre-1.0. The kind of active users right now, there like over a thousand on 0.99 and then 637 on 1.05 209 on like the kind of master the last kind of master commit and stuff like that and then i jumped through to kind of the most popular packages and somewhat unsurprisingly open ssl is the most popular package by far uh then followed by package config and which is used like it's one of those things where no one probably intentionally installs it but it's

right a dependency for a lot of things then lib png sqlite great piece of software node.js free type again probably something that not a lot of people are installing intentionally and then git and so yeah it's kind of it is valuable being able to see these things and and the the drop down is kind of quite impressive so i mean open ssl we have in homebrew itself and this tracks homebrew and our kind of third-party repositories so you know maybe 4 000 different packages so of that open ssl itself has like 3.5 of all installs of all software. And so it's quite interesting to see how quickly it drops off. And you get below kind of 0.1% within the first, you know, 170 packages. Curious, in light of transparency and open source, kind of the spirit of the community,

have you considered making the, I don't know if you can even do that with Google Analytics, but like an open dashboard where anybody can come and just see the usages yeah you can't unfortunately i mean what i i've been considering is doing a database dump every so often of like the stuff that i'm kind of most interested in um but yeah i mean it's again it's this doesn't seem to be a trivial way of automating that. So it needs to be me manually going in and like clicking through every time. So yeah, I'm still, that's still kind of on my list of things to try and do to try and improve the transparency of this. And then hopefully people can see that this is not, you know, there's nothing nefarious happening here. Yeah, because I mean, they can see the source code, at least of where the calls to track are happening in google analytics or calls off to google analytics

but it'd be really cool to have you know publicly available the results of that data because then you can have people draw other insights or just enjoy it but even yeah remove that fear of what what y'all are tracking and well and the thing that some people have asked already actually about that is um people who are scientists who've been asking you know if it would be really useful for me as i've you know worked on some piece of software as part of my phd to be able to put in a paper well this has actually been used this many times or installed this many times or whatever because that gives some i don't know i'm not a scientist but that gives i think some sort of weighting or a sense of importance to the kind of work they've been doing,

which I can understand. Or people who are putting the work in to maintain specific formulas or formulae, as you guys call them. Yeah. To know, like, is this worth my effort? Like, oh, me and six other people are using it and I got six complaints, you know, that's just the total. That's all the users as opposed to, oh, this has, you know, a lot of people are really drawing value from this.

I'm going to continue to maintain it. Yep. Yeah, exactly. Well, one thing you mentioned is updating in light of those stats, you know, not everybody's on 1.0, but just moving on to the, some of the other new features is you guys now have auto updating built in. Is that correct? Yeah, we do.

So now if you run brew install it will check for updates in the background i think by default once a minute um when i say in the background i don't actually mean in the background i mean before you run the command it will check for updates and that was actually that's one of my favorite features in there because it was a really fun exercise for me in kind of performance benchmarking like on kind of the full stack because um i this is something i had a while ago is i was like okay well i want to be able to run auto updates because a lot of the time when things break we tend to get a fairly long tail of people who haven't run the update who file the issue for something which is fixed you know a day a week sometimes even a month a

month earlier and i've always kind of wanted to have that but then the updater at that time took probably about 15 to 30 seconds depending on where you are in the world and stuff like that sort of minimum uh to do that and that always kind of frustrated me so in the end i kind of poured some time into that and tried to make it worked on a few things that made that really fast and one thing was kind of more reliable i guess so one thing was kind of moving some of the the auto update stuff uh from ruby into bash more just because ruby gets more upset when you modify its own code underneath it than bash does or at least it's easier to work around that in bash the other the other thing that was a kind of fun but completely overkill thing was with me being

lucky enough to work at github i noticed that the slowest thing by far was doing a git fetch on like a massive repository like homebrew that's had huge numbers of pull requests and stuff like that so that git fetch just did like a no op git fetch when there's nothing to fetch was actually pretty slow and so i was at that time on the github api team so in my kind of weekend i figured i'd go and see if i could play around and and figure out a way to make that faster and because we have like a a cache api layer and there's like an api call you can use to get the kind of latest state of a of a branch so i kind of tweaked that a little bit i made it so you can pass in the sha1 from git as the etag to that so you get three or four unmodified if

nothing has changed and therefore not use up your rate limit and allow us at github to kind of deliver that from the cache and basically yeah as a result like flip that git fetch operation to just being an http call and and that's like way way way faster and for both github to process and for homebrew to process so as a result was able to kind of play around with that and do some parallelization and stuff like that. And now it's generally kind of under a second or around about a second down from kind of 30 when you are kind of doing an auto update. So that seemed like a reasonable amount of time for people to kind of spend on every call, considering if you do a brew install, the compilation and extraction time are going

to be significantly longer than that anyway. Life is good when you control both sides of the APIi right yeah no it's it's much it's much much easier and when you have that like it's it's nice to be able to kind of jump in there and play around but i think even if i didn't control that side of things there there might have been ways i could have played around and made it a little bit faster. But no, it's certainly easier, as you say, when you have that. And when you have very smart co-workers who I can kind of bump it off and kind of actually work on Git itself as their day job and then be like, okay, am I being stupid here? Like why this is slow and all this type of thing? And then discussing an approach with them, that was kind of pretty fun.

So just one aspect of user experience, I think focusing on the speed is key there. And in fact, Adam and I were kind of lamenting a little bit before the call about certain bits of software that do auto update, but you don't run them enough for them to ever be updated. So my example, for me at least, is Firefox, which I don't use on a regular basis, but I do use if I'm doing browser testing or for one-off purposes. And it seems like, I think they may do it in the background now, but it used to be every time I launched Firefox, it would say, Hey, we have an update update. And it seems like brew for me, at least I use it all the time. So I don't have that issue,

but it could be the kind of thing where you don't launch it very often. And then it feels like every time you're running the brew command, it updating sometimes sometimes like i just got to get this thing installed i need this command so i can fix something that's on fire um so speed i think is important to fix that is if it happens real fast no big deal um but in light of there is a new update does it automatically run that for you or does it prompt you where you can say not right now? Have you thought through those kind of things? So we have, in terms of our commands, we have a separation between update and upgrade.

So update is basically get all the definitions in the package manager at the latest version and then upgrade is like, you know, install OpenSSL 1.1 instead of 1.0. So yeah, we don't auto-upgrade. Sure, but I'm referring to like, say I run

brew install jq because I need to parse some JSON on the command line real fast. And you don't want to wait a couple of seconds for the update. Yeah, I mean that's one of those things that we kind of considered, but in the end the kind of support burden

for that is, it's worth it for us like that you would not believe how many like annoying because again i don't think we mind that much about the the issue count or whatever or the number of issues people are filing but what's right the worst thing is when you get the same issue again and again and again and the the response to fix it is the same thing again and again and again and like my attitude is always try and automate myself out the job so like if it's the same command we're having to tell people to run like every single time and if people are still not running that command then it's like well we're gonna just run that command for you and i think it's definitely that i think the pain is alleviated because of the small payload size of updating homebrew.

Whereas in like, for example, with my Firefox example, you got to download like a 60 megabyte file or whatever it is. So it's more of like, OK, I'm going to sit and wait. But in this case, even when you do have I run brew installed JQ and I'm, you know, I'm a dot release behind. We're talking like seconds to get that thing upgraded. Is that right? That's the point where it's doing the, the auto updating is like when you're doing a brew install, not just brew update.

Yeah. Yeah. So we have to basically a brew install now does a brew update in the background. Okay. I'm, I'm tracking now. I heard you said before,

but I wasn't sure what, under which command it was doing in the background you said once per minute something like well if you do brew update yeah so if you do brew update then it will basically skip them or the next skip even looking for the next minute and then as I say it's optimized for the no op case where

if you don't actually have anything to update there then it will just ignore it and she said it's just definitions right so it's just definitions right so it's just pulling back like the latest things are available to brew install yep yep exactly and invariably that's i think the other thing that's kind of tricky from a package manager perspective is that you have this conflict between what people want and uh what people need where you know humans included, are lazy.

And if you can avoid upgrading something now, and if you can kind of put it off until tomorrow, like most people will, but then there's some of this stuff that it's like, well, actually, that's a really big deal with security. So you need to update this now. And if you don't want to update this now, then we've got to sort of like nudge you

in the right direction so that you do that so that your machine doesn't get earned and then it's we're at least partly responsible and as i say it's that kind of weird conflict that you have where sometimes you've got to just force people to do things or not implement things that they want you to like a recent thing that could have made the 1.0 release notes but actually it i kind of pruned it from there is we don't we used to let you run homebrew as root um and like you know you would have to completely change all the ownership so it was root and everything like that to almost emphasize that look i'm really sure but in the end we're just like you know what there's a use case for this but it's just a really bad idea because if you run

homebrews root like we don't like other package managers that run as root they drop privileges because that's what they're designed so they'll run as root and then when it actually comes to doing installation or whatever they'll go and just be like okay i'm a user now with no privileges so i can't do stuff whereas in homebrew because the vast majority of our users are not running as root we haven't implemented that. And we don't have the motivation to implement that. So if you run Homebrew as root, a makefile can now literally change any file in your entire system. So that's bad.

And we added a sandbox that means that obviously you're running as the same user. And then we stopped the build process from being able to write to arbitrary locations in your system. But again, to make it even worse, sandbox broke when you were the root user. So we had to disable the sandbox for the root user. And at that point, we were like, okay, this is just way too dangerous.

And unfortunately, we need to make the call that we know better than other people do at assessing the risk in this situation because we've seen what happens when there's a make-bar log that starts trying to just delete random files off your system and users maybe haven't seen that.

And when that happens and they destroy everything and they don't have any backups, they may not hold us responsible, but they kind of should if we have seen that coming and we've not addressed it properly. So yeah, fun times.

Well, while we're talking about technical changes, well, let's hit on one more and then we'll take our next break, which is you've changed the default location of the Homebrew repository. In fact, I believe as you upgrade it, it will move it for you from user local to subdirectory user local Homebrew. Can you speak to that change and then the implications of what all it entails? from user local to a subdirectory user local homebrew. Yeah. Can you speak to that change and then the implications of what all entails?

So there's always been a bit, people have had a bit of a love-hate relationship with homebrew being installed in user local. And the main reason the homebrew is there is because originally at least was because that's in your compiler and a bunch of other Unix-y tools, they look there by

default so that basically means with ruby gems and various other things if you have a library in there and use your local lib use your local bin then they will look in there and you don't need to like manually specify your location so that works kind of quite nicely for most people and again when hubru kind of got started that's something that helped is again like adding to this sort of zero configuration approach that Homebrew was taking on things. So the problem with this is time goes on

and we say in our repo, like, oh yeah, we want to add a readme, we want to add a code of conduct, we want to, you know, add a bunch of stuff in our repository. The problem with that is

all that stuff ends up then getting dumped in user local. And then people are like, okay, well, user local bin wget. Okay, I'm fine with that is all that stuff ends up then getting dumped in user local and then people like okay well user local bin w get okay i'm fine with that user local like readme.md that feels kind of weird to me when there's other stuff in user local and people people were getting annoyed with that and i kind of understand that so it was actually one of our users came out with something which was kind of, I mean, frankly, a hack that had never really been patched, which was that Homebrews, by default, Homebrews, what we call the prefix, which is user local. And that's where all your files get symlinked into like user local bin, etc., as I was saying before. And that has actually remained unchanged.

And that was the same as where we had the repository previously but there was a hack you could do where you could install the repository in a different case in a different place and symlink it funnily and then it would put the repositories files or the readme file code of conduct documentation whatever in a different path that you specify if you're choosing and then user local would contain just the kind of symlinks and the install packages. And the nice thing about that is that user local, you may have seen the user local seller directory.

Now that's where all the binaries are actually stored, and then there's symlinks into various different locations. The problem is if we decided to move that, we would have to rebuild all our binary packages for all of our OSX versions. And that's basically a massive pain that we don't want to have to go through. So this hack that this person suggested, I tried it out on my own machine for a few weeks,

and it was completely flawless. Everything just worked absolutely perfectly. And that allows us now, after the move, to have all our binary packages be the same, still have all the kind of the compiler search paths and stuff like that be fine. But now we can move stuff around in our repository on GitHub. You know, if we want to put a readme.md file or contributing.md file or change those file names or whatever, they can all now live inside user local homebrew instead. And we don't need to worry about kind of junking up people's user local another final benefit from that is so we always we would tell people to take ownership

of user local and just recursively churn that so you can always write anywhere in there the problem is is apple's osx installers various various other tools, would reset that. Yeah, every time. So every time there's a new version of OSX that comes out, there would be that kind of reset process, and it was a massive pain for a lot of people. So now what we do instead is we create the root-level directories in user-local, get people to CHR them instead,

which our installer does by default, and then you just have those root root level directories which kind of stick there. And anything else can dump files in user local, can change the ownership of user local, and all that good stuff. And that doesn't affect us anymore. So again, that's another example of somewhere where it's

massively cut down on a bunch of these issues we would just see again and again on every AeroSense release. So yeah, it's been great. Or MacOS os i should say i've actually been bit by that bug once before yeah yeah i've been bit by that one several times before i forget that it happens and then it happens and then everything explodes i just upgraded at 1.0 yesterday and as part of the upgrade because i i upgraded to sierra last week and i just did the upgrade to Homebrew 1.0 yesterday and I had to change ownership on user local

because Homebrew had set it back to was it root and wheel or something like that. So yeah, I can see that happening to everybody. Yeah, exactly. And then nicely now we after the migration,

we then tell people, OK, you can actually now change this back. And then that's now the last time. So when Sierra plus one, I'm still hoping for Mac OS Sea Lion to come out but when that comes out or whatever and then yeah hopefully these permission issues will just be gone for good

at that point which will be lovely that's funny as we're talking through all this the details I'm I'm just reflecting back on earlier in the show when you said that you that you do this homebrew stuff as you said in the times whenever like you that you uh that you do this homebrew stuff as you said in the times whenever like you're running a test suite and it takes five minutes or something like that like i'm just reflecting on all this detail and all this complexity and all this community and all this you know how important homebrew is to so many developers out there how you and others do this in your spare time and that's just crazy to me i mean yeah so i mean i'd say kind of here in the air time but yeah i mean in the run up to 1.0 i'd sort of decided i wanted to ship it all around about the sierra release um so yeah so

in the two weeks before that like i was just like doing pretty much every every evening and weekend like pretty much all evening and weekend like i i think there was you know we were getting to the point where my uh my dog and wife, like, not tolerated any further. As we know, you're a dog lover, too. We can hear your pups in the background there for a second or two. Still got a little cameo on the show. Yeah, yeah. I do love my dog.

She's pretty great. And she's in my GitHub profile picture as well. Well, cool. Let's pause there, then. When we come back, we've got lots of other things to talk about. Software Freedom Conservancy, the new community site, several other things happening, more community growth, and maybe even more ways that the community can step in and support Homebrew and ship their own formula or formulae, as you might say, or have changed the way you say it. So let's pause here. We'll be right back. One of the fastest, most efficient SSD cloud servers is what we're building our new CMS on. We love Linode. We think you'll love them too.

Again, use the code CHANGELOG20 for $20 credit. Head to linode.com slash changelog to get started. We're back with Mike McQuade talking about Homebrew. And Mike, around Homebrew, there's several terminologies used. You've got cast, you've got tap, you've got brew, you've got several things. You've got formula or formulae. I think that's changed, if I'm correct. It's plural form.

It's plural form. Okay. Walk us through some of the terminology. Do you tap a cast? Do you tap a keg? What is it? How does this work? Yeah, so I think the terminology is a bit

sometimes tenuous in places and it's not quite um all adding up but a tap is effectively what we call a third-party repository basically so that that was initially created that was one of kind of max's last big features he worked on and a tap basically allows anyone to be able to have a git repository which well it doesn't be able to have a git repository which well it doesn't actually have to be a git repository anymore but a directory with a collection of formulae or homebrew extension commands that they can go and say to anyone okay like here's this one command you can use to install a tap on your machine and then brew update will then keep that up to date and brew install will then

let you install from any of those taps as well so actually as part a fun little fact is as when we split out homebrew into the two repositories the formulae became their own tap so previously you had all the kind of central formulae and then you had taps but then now actually everywhere that contains formulae is always in some sort of tap seem like that's a promotion of the tap idea because back when i first started using homebrew like using a third-party uh repository for formulae was kind of like sketch and you're like well if you really have to do this but now it seems like that's very commonplace is that a fair characterization? Yeah, definitely. I think there's a recognition in that,

that A, that people are going to want to do stuff that we don't have. If you work at a company, you may well want to have internal tools which are installed by Homebrew through a tap. But also it's helped us with some of the really long tail stuff because now we can say to people,

if you're the only person interested in this then you can just create your own tap and you can keep that up to date and then if more and more people particularly now we have analytics for some of this stuff and if more and more people use that then we can consider kind of bringing that into homebrew itself and before that we couldn't not that kind of private taps are revealed by analytics we're careful to not do that. But within the Homebrew organization, we have several taps for different things. And it lets us as well subdivide maintainers

based on things that are interested in. So we have a science tap, a PHP tap, a Python tap. And those are not... To install Python, you don't have to tap Python tap. But it provides some sort of stuff which is deeper into that ecosystem and stuff which we wouldn't include in our main repository and can kind of find a home in some of these taps instead and these taps can be run independently and a little

bit looser on some of the restrictions that we kind of have to have to kind of keep the core working effectively tell us about cask what's? So yeah, so that was quite exciting. So brew Cask was originally a thing made, I can't remember what year it was originally, but someone basically really liked homebrew, but they hated the fact that when you install Mac applications, you have to download the zip or the package file, the.mg or whatever, and move the file there. And it's almost always the same process every time. And it's like, and I think's almost always the same process every time.

And it's like, and I think they were just like, well, why do I have to, why can I install my command line software beautifully? But then I have to like physically drag and drop a thing with my mouse. That's the sound I make when I do it. Exactly. I actually quite like drag and drop.

I kind of miss that a little bit in some ways, like the little drag and the icon into the applications folder and it's all nice and pretty. You can of missed that a little bit in some ways, like the little drag and the icon into the applications folder and it's all nice and pretty. You can still do it, Mike. No one's stopping you, man. Yeah, my obsessive desire to script everything is stopping me, unfortunately.

But yeah, so they made this brewcast command so you could do that. You could do brewcast install and Google Chrome, whatever. And we had a cask command so you could do that you could do brew cask install and you know google chrome whatever and and we had a summer code student this summer anastasia who is a very very smart russian student who worked on basically trying to unify the two projects so homebrew cask they originally were kind of a little almost extension i think in just a tap and we kept because we

didn't provide any sort of official api for them they kept and they're being broken by our changes so in the end they ended up vendoring a lot of homebrew code homebrews code so in google summer of code this summer the student worked on basically de-vendoring all this stuff so that they could kind of we could share a lot more code between the two projects and de-vendoring all this stuff so that we could share a lot more code between the two projects, de-duplicating between the two projects so stuff which didn't make sense to have in both wasn't in both,

both in terms of source code, but also in terms of things that are installed. When they both installed identical software, there wasn't a need to have them both. And then finally, actually moving all of homebrew casks kind of package manager codes into the homebrew package manager itself and so now we have homebrew cask living within homebrew itself so when you run brew cask

now that's part of the homebrew package manager and part of the homebrew's release process and stuff like that and we're able to do stuff like share a lot more code, share maintainers, share testing. And that kind of provides some guarantee as well that we're never going to break Homebrew Cask stuff because our package manager tests are now running all of Homebrew Cask's tests as well. I just did a Brew Cask list on my machine. And it turns out, even though I don't know what Cask is, I have used it to install Screen Hero.

So I believe someone said yeah just type this and i thought oh that's really cool you just type brew cask install screen hero or whatever the application is and magic happens and then you forget that you did it and all as well so and the cool thing that comes on top of uh brew tap and brew cask as well is which not many people know about and i think partly because i've not done a good job at describing it is the thing brew bundle so that lets you have a brew file kind of like a gem file or whatever and in which you specify a list of homebrew packages cast packages and actually like taps and eventually even like mac app store packages as well and then it will automatically you can run brew bundle and it will go through that list and install any of the ones that aren't installed. And you can also do the reverse where you can kind

of dump to a file and then have that as kind of almost like a backup of everything you've got installed and all the options they're installed with and stuff like that. So that's been really useful for letting people kind of almost import and export their configuration, but also for having like a system wide like installation so you can have one script which then installs all of your software but then we've been leaning on that heavily inside of github as well and to have that per project so you can specify a definition of this project requires my sql and nginx and stuff like that and there hasn't really been a good way before that of kind of defining that.

Like often that's just in the documentation, but we can actually have now in the brew file. So we'll install the correct version of MySQL and then start up a daemon in the background on the system if it's not already running. And then that'd be a no-op if that stuff is already installed and the daemon's already running.

That brew file is really handy for descriptors. I've seen that actually, I think, in maybe earlier versions of ThoughtBot's laptop project where they're doing lots of interesting things around. They actually used to support Linux and Mac, and now it's just Mac, but it's kind of like their way of setting up a development machine. And I'm pretty sure I recall seeing a brew file in that, and that's kind of where I actually stumbled upon that and thought that's kind of interesting to see. Like, here's a way you can just run a lot of brew commands, basically.

Yeah, yeah, exactly. And so it's pretty neat for that. And again, being able to standardize on these things, I self-plug have like a little project called Strap that we, again, use inside of GitHub. That is kind of a system bootstrap type thing and and that rather than it's a different approach to thoughtbot laptop because it's not opinionated at all about what stuff should be installed so if you have a brew file in your dot files directory it will check out your dot files directory and run the brew file in there so every person can have their own almost custom system bootstrap script and from that perspective

and still yet have like a sort of centralized way of running that for everyone so it's been quite neat and but yeah my long-term dream if i ever get around to it which i probably never will is to try and work with a few other people and see if we can get some sort of uh brew file definition format which um a bunch of package managers support so that we can have a way of you can declare in a project that okay i i want to install my this project needs my sql installed libxml2 whatever like the kind of native package manager dependencies and that file can then be read by you know whether you're on fedora or NuGet on Windows, maybe even, or Homebrew or Mac ports and have a single file, which could be used to kind of as shared metadata

across all these package managers. That's kind of a little dream of mine that may or may not happen one day. That would be cool. I think RBM had a similar dream. Isn't that right, Adam? Or RBM3? I'm not sure if you ever got there, but it was kind of like beyond Ruby versioning. It was like versioning for everything you could just list all your you know this requires postgres this requires

uh redis for instance but definitely a dream to get everybody involved because that's a lot of different uh software projects that would need to come on board and if i couldn't call it brew file it'd have to be like oh yeah yeah yeah obviously yeah i'll submit term you should call it dependencies yeah yeah that seems fine when people tend to like that one might have to have some slight pun on the name just because i'm british and that's you know that's what happens to us so tell us about keg so kegs are when so that's one of the hardest metaphors in that even the homebrew maintainers probably disagree on what a keg actually is um but a keg is technically that's the directory when you install homebrew a package in it the directory is used as the

prefix so this is going to get a bit package manager navel gazey but the way most package managers work is they have a unified prefix and what i mean by that is when you run configure or make make install or whatever say on two pieces of software the prefix you set is say user local and then what it does is it chucks binaries in user-local bin, it chucks libraries in user-local lib, et cetera. And that's the general way most package managers work. What Homebrew does, which was actually aped off

by Max's own omission off another package manager whose name escapes me off the top of my head at the moment, but basically having every single package be in its own prefix by package and by version. So if you go into user local seller, you'll see you have user local seller and then the names of all your packages. So user local seller and then a subdirectory called wget and then a subdirectory of whatever version of wget is installed. And then within that, then you have bin, lib, all these other directories. And then what Homebrew does is we then symlink the contents of those subdirectories

back into the user local bin. So in user local bin wget, that's not actually the wget binary. That's a symlink to user local seller wget version bin wget. And basically the benefit for that is it lets you stop software from stomping on each other. So you can have software installed side by side, which installs conflicting things, but they just both can't be linked at the same time. Rather than being like, okay, we actually just can't install these two things in the package manager at the same time.

I might actually suggest after this that there actually be some sort of glossary for homebrew, because you'll have so many terms, and I'd forgotten about cellar, and we actually asked about keg as a joke, because I didn't think it was a real thing. I was hoping you'd laugh, but it's actually real. And so our next one is like, tell us about pints. Yeah, pints are not real. Well, I mean, they are real, but not in homebrew. They're real to me.

Yeah, yeah.'m so yeah no i mean we definitely could do with having a glossary i mean why i mean if anything it could be an attractor to contributors because it's funny it's just a new way to like talk about your project and just have fun with what it is you know yeah exactly i mean so my the reason why i i didn't do that originally is my whole thing was I wanted to rename everything. So we wouldn't call kegs kegs anymore. Careful now. Why? Exactly. Exactly. And that was an example. You were concerned about the analytics people getting you.

This is the real reason he wanted to be lead maintainer, so he could rename all of the ads. Would you come up with a brand new analogy or would you just remove all analogies i mean i think yeah we just call things packages if there's an established name already call them that packages prefix whatever but i mean i think the argument which i i probably mostly agree with at this point that pretty much every other person in the world said is that okay you might make things slightly easier for new users but at this point homebrew is at the point where you're probably going to confuse a lot of people who've learned the existing terminology more than you're going to help, you know, a new user at Code Academy or whatever, understand this stuff. And yeah, and as you say, probably the best middle ground is just have a glossary and just define these things. I guess it depends though on this change stuff. Now, the Nayserami says

don't do that, but I think if the plan was wider adoption and a greater invitation and if the normalizing of the puns, while we all love puns and just the play on words kind of gets played out, so to speak,

if reducing that helped invite people and actually contributed to a greater project that might be for it but it would hurt along the way i'd cry a little bit yeah yeah no i i do agree and i mean it's it's maybe whether we can change some of these things whilst maintaining other things or whatever like you know we can certainly maintain the kind of beer theme and the little nice cute emojis we have and stuff like that whilst maybe renaming some of these things so yeah it's it's it's still a source of debate and torment for us all adam sounds like he's for it i'm against it so there you go you split us down the middle i'm not exactly for it embrace the analogy and just it's it gives homebrew has

personality it has a theme it's it's actually worked out better than most names in terms of like they have kegs and casks and taps and i mean those are things that actually have make some sense now once you get outside of it like would you say boneyard or graveyard or something but some things just don't match then you get mad you're like oh we can't think of a beer themed boneyard but along the way i think it's helped massively and i think it makes it kind of a joy in certain ways yeah yeah and i i think that's you know i redesigned the website for with a help from an australian designer danielle uh whose full name is actually on the website but uh yeah so i i think that was part of what i was going for a little bit with the redesign as well

because she came up with these great new icons you may have seen which it just they feel a lot more playful and kind of fun and like it's i i feel like that i i love them when i i set upon them at first because it it just feels like that's the vibe of our project is we're trying to have that sort of fun slightly kind of jovial slightly silly like you know part of that is the fact that you know we have prose guidelines and in our prose guidelines we favor british english just because you know max was british i was i and partly just because i mean a little part of me and i think this is more Scottish thing than a British thing is I kind of just like being difficult you know I'm one of those

people when I worked with cute back then as well when you define colors that was a cue color and I would regularly name my cue colors variables color with a C-O-L-O-U-R just because you know

because I'm a crotchety Britishish person and i right i find it funny to do those type of things so i think part of that kind of creeps into homebrew and we do try and we kind of have to remind people sometimes that like we know some of this stuff's a little bit silly but that's that's the project we're not a company we're not a serious business and we can afford to be a little bit more silly even when maybe sometimes it's a little bit self-destructive because that fun is what keeps us working on it i guess right well now that you're getting kind of beyond yourself and talking about the community and the group of people that are all involved with it let's let's change focus we're getting a little

bit low on time here but let's talk about the social side of things in 1.0 and you have two what i would call kind of social announcements or things that have happened at least in light of 1.0. And one is the joining of the software freedom conservancy. And the other is a setting up of the community discourse. I'm not sure exactly when those things happen, but let's start with the software freedom conservancy. Homebrew has joined that. What does that mean for the project? Sure. It's one of those things that for open source that you don't really understand until you run a big project for a while. But when your project has no possession effectively, then there's not really a need as much for a thing like software freedom conservancy.

The problem is when you have... We had a Kickstarter a few years ago, which was really great. It let us buy some Mac minis, which we for our ci and as i get older thankfully not that old and i'm a bit of a paranoid person anyway part of me is like okay well these cis are in a data center like a friend of mine runs an isp in the uk uh and we have a bunch of money in a bank account which again i have access to but i've given other people the credentials to and stuff like that what happens if i get hit by a car to those servers what happens when they go down what happens to the money in that bank account uh and i just you know that stuff gets a little bit more worrying and it becomes one of these things where you think well it's actually not very responsible of me just assuming that this project will survive my

health and it also means that if i ever did want to or i have to step away from the project then the the unwrangling of me from the project would be a lot more difficult and what the software freedom conservancy provides is a legal entity to own these things and and a legal entity to if whoever got sued for whatever reason then the software freedom conservancy would defend us and also on top of that as well they are a 501c3 or for non-americans and a non-profit in the u.s which makes it a lot easier to accept donations basically which are tax deductible for individuals and corporations to provide so that is not something we've we've not managed to do a massive amount of fundraising yet that's

probably my next big project to try and like lean in on that a bit more and because our recurring monthly revenue is zero but basically just all those things that kind of help provide some more kind of infrastructure and architecture around the kind of the governance and running of the project. I'm surprised to see or to hear that, uh, that it's zero, like there's no contributions, there's no donations. I mean, I mean, that's, we're running low on time, so this is harder to, to kind of like tap into, to keep using our terms, but, our terms. But it just surprises me that Homebrew is used by so many

and depended upon by so many. I mean, I don't know a developer, that many developers out there that aren't developing, at least on a Mac, more often Linux, but not as often on Windows, although it's becoming more and more popular with Ubuntu's announcement of Bash and Microsoft and all all that good stuff but i'm just surprised wow yeah yeah so i mean part of that you know we're coming to personal beliefs and stuff but you know my whole thing is i i don't feel happy spending money on a recurring basis until i have money coming in on a recurring

basis in both my personal life and with homebrew. So it restricts the stuff we can do. There's certain things that it's like, I would love to just be able to spin up an AWS instance to run that, but we don't have the money. So we can't afford to do that. And yeah, it is a bit of a pain and it's not hit as that adversely yet. But as I say, on the flip side,

we've not ever really beyond the Kickstarter tried to do decent fundraising for that and that's something i do want to you know personally do in future well that's somewhere we can help you play a role a little bit i mean i know that jared and i we both uh have some passions around that and you know we can always talk to you outside of this the context of this show to to help you on that front, to give you, you know, collaborate in that front a little bit. And that's something I think we have some future ideas around,

nothing that's exactly solid, but definitely some passion. And anytime we hear of something like homebrew, having zero recurring revenue to do even stickers, you know, anything that's like community outreach, not so much like just have money, you know,

that to have money, but you know, to have money to do things that are community related or growth related or, you know, outreach or anything, anything whatsoever. You can't sponsor one of the maintainers going to a talk because you just have, you know, you have no funds to do that stuff. It's very limiting. And I think that there's so many people out there using it. There's got to be some way you can bring in at least a bucket user and that'd be a lot. And I mean... Yep.

Well, let's cover real quick, even though we're real short on time. So give us the information on the community discourse site and the purpose and the setup of that. Yeah, so that's something we shipped I think on the same day as 1.0. And it's basically just another way of communicating on Homebrew.

It's something that the mailing list, we've got a mailing list, we've got an IRC channel, we've got the issue tracker, and none of them are quite, you know, they all feel slightly formal in their own ways. And I think that the discourse has been kind of great since it started, actually, of just allowing people a little bit more of a kind of free-form place to talk, to kind of post about issues in a little bit of a looser way and people to be able to help each other as well that's the nice it seems to be building an expectation there

which is nice which is that it's not just the maintainers who are kind of jumping in and kind of helping people there and a bit more of a kind of discussion and stuff like that and yeah it's been good one more thing i I heard you mention earlier, but I'm just curious what the tie-in is together. Because I see in the footer, it's Linux brew is maintained by Linux brew. But earlier you mentioned Linux brew. It also says it's the homebrew package manager for Linux.

Is there an affiliation there? Is there, I know one of the maintainers crosses over, at least. What's the relationship there? Just curious and closing. So I think originally linux brew was like just a fork um and then we we kind of created that and they they just kind of had a bunch of patches on top of homebrew and but then with 1.0 like we have a kind of what i call a generic

back-end which is a back-end that doesn't assume anything OSX or Linux centric and kind of run the tests and run an install on Linux and Mac. So now that we have that backend, we're trying to do more porting to try and get things into from Linux Brew's Brew kind of package manager fork into Humber itself. And then hopefully maybe a 1.1 or whatever will have a point where Linux brew can go away entirely.

And we can run that entirely off Homebrew's brew. And we can have a unified package manager that works on OS X and on Linux. Nice. Good stuff. Is there anything we missed in this call? I know Jared and I had quite a list to talk through pretty much just based around your 1.0 announcement. but is there anything we missed that you wanted to make sure we talked about?

I don't think so. I think that was everything I wanted to talk about. I looked at your little notes about the common questions at the end of the show. I'm not sure if we were doing them or not, but I think we've touched on almost all of them anyway. There's one we want to camp out on, which is essentially

a great invitation from you and the other maintainers of Homebrew to the community. So there's lots of listeners to this show from all walks of open source, all walks of developer life. So if you were putting out a widespread invitation to those who could step into Homebrew and help out in various ways, what would those ways be? Yeah, that's a great question.

I think basically just getting involved at all it's great we have a thing in our homebrew brew read me about the easiest ways to get involved which is basically we have a an audit tool for kind of running through things and seeing if there's any little violations and of our kind of style and that's a great way to get started and get kind of familiar with our workflow. But I think the main thing I would just say is anyone who's sort of in the wider homebrew community is just be nice to each other. I think open source, as I kind of touched upon a little bit earlier, has a problem with retaining and welcoming people, particularly people from more diverse backgrounds than it's historically been. And that's something I feel like everyone can do, whether it's on Homebrew or on any project to kind of make the open source ecosystem a better place is try and just be nice, be friendly, be helpful, be kind to people in Homebrew and on any open source project,

because that's the way we're going to grow this community. And that's the way we're all going to make better software together. Because when you don't have those things, people stop working on things like Homebrew. When you don't have those things people stop working on things like homebrew when you don't have those things people don't want to work on open source and that hurts us all really i need kind of like a a universal mini so or mini song what is it jared for uh matt's is nice we are nice can almost be like maintain our maintainers are nice we are nice kind of thing you know it's just universal mini swan that's what it is yeah no i like that that's nice you know i mean i think that uh every you know sure everyone says they're nice and it's a variation of nice but uh you know maybe maybe they're not nice i don't know maybe there's a project out there that's just like led by somebody who's a complete jerk or not a very

nice person and so therefore their community is not very nice. But I think when you look at the leadership of homebrew over the years, you know, starting out with Max and the leadership that stepped up over these years, you've all been very nice and, and there's no reason not to be nice back. Yeah. Well, we do try to be. And I think that the thing that I think that's important to remember is people, again, when you were saying everyone kind of thinks they're nice is you're you're as nice as the way you treat the person you're angriest with the person you're most disgusted with whatever like it's not when it's dealing your day-to-day it's when you're really angry or frustrated or disappointed or confused or whatever like that your behavior in that situation is what like we're asking you as

like open source people and and equally myself as well i've got as much to learn from this as anyone does like that's the stuff we need to kind of work on because it's very easy to be kind of nice in the times where you think things are great but it's harder in the times where everything is broken and your house is on fire that is true's a, it's actually a good example of when people are actually nice is when they're angry or should be angry or could be angry or whatever. That's totally true. So, um, Mike, you know, one thing I want to mention to the listeners before we close out is that we have this email called change law weekly. I don't know, Mike, if you subscribe to it or not, but, uh, uh, every week on Saturday and Jared, now it seems like Sundays

because Sundays have kind of been a better day for us. We've just had such business going on between the new site going out, three shows, lots of stuff happening around the business. I've been changing our verbiage to every weekend. Every weekend. Yeah. I mean, I think Saturday has been a great day traditionally for us, but Sunday has turned

out to be the day we actually end up shipping this email. But in that email. The most recent one. Issue 124. We mentioned Hobrew 1.0.0. And many other awesome things. So if you're not subscribed to that. Go to changelog.com. Subscribe.

All we ask for is your email. But if you put your name in there. We greet you nicely in the email. So the name is optional. So don't feel like you have to. But a lot of people in the email. So the name is optional. So don't feel like you have to, but a lot of people listen to that or sorry. A lot of people read that email, include our latest episodes,

everything that hits the, you know, our radar in terms of open source, software development, encouragement, things like Mike's talking about here with being nice and stuff like that. So a lot of stuff around software development. So if you don't subscribe to that, you know,

Jerry, what have we got? Sad faces or happy faces? Emoji sad face. Emoji sad face. And Mike, so do you subscribe to this? Just curious. Yeah, I do.

As of three seconds ago. Three seconds ago. What's your favorite issue? That's all we ask. That's all we ask. Just because you're subscribed. My favorite issue is the next one. 125.

Nice. You're going to love it. You're going to love favorite issue is the next one. 125. Nice. You're going to love it. You're going to love it. You're going to love it. Now we get a lot of pressure on us to please Mike, which is hard. I don't want to see you non-subscribe on Sunday. I'm going to email you nasty things. That's right.

Yes, that's the way we do it. But that's what I want to mention in closing, just because we mentioned Homebrew's 1.0 announcement recently in that email, a great place to mention that. And if you listen to the show and you don't subscribe to that email, it's just, you're just missing out. That's all I can say.

So do that now, take our direction. And that's it for this show, fellas. So let's say goodbye. Bye. Bye. you