Homebrew and Package Management

07 October 2016

Interviewed by The Changelog

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.

Show transcript

0:00 I'm Mike McQuaid, and you're listening to The Changelog.
0:03 Welcome back, everyone. This is The Changelog, and I'm your host, Adam Stachowiak. This is
0:16 episode 223, and today, Jared and I are joined by Mike McQuaid, the maintainer of Homebrew.
0:21 We talked about Homebrew's 1.0 release recently. We talked about a lot of the changes happening.
0:27 There's no more user local. Homebrew now lives at user local Homebrew to keep user local cleaner.
0:33 Homebrew also auto-updates now, and in the seven years of Homebrew, the community has grown to nearly
0:39 6,000 unique contributors. There's also talks of Linux Brew, which is a fork of Homebrew joining in
0:46 lots of fun stuff happening in this package manager space for the operating systems.
0:51 We have three sponsors on today's show. Rollbar, TopTile, and Linode. First sponsor of the show is
0:59 our friends at Rollbar. Rollbar puts errors in their place. Head to rollbar.com slash changelog,
1:05 get the bootstrap plan for free for 90 days. And today, I'm sharing a conversation with you that
1:09 I had with Paul Bigger, the founder of CircleCI, and he talked deeply about how they use Rollbar
1:15 and how important that tool is to their developers. Take a listen.
1:20 One of the key parts about doing continuous delivery, you don't just have to test your software,
1:25 but you have to constantly keep track of it. You're going to be doing deploys 10 times a day or 20
1:29 times a day, and you have to know that each deploy works. And the way to do that is to have really good
1:34 monitoring. And Rollbar is literally the thing that you need to do that monitoring. You need to make
1:42 sure that every time you deploy, you're going to get an alert if something goes wrong. And that's
1:47 exactly what Rollbar does for CircleCI.
1:49 Oh, that's awesome. Thanks, Paul. I appreciate your time. So listeners, we have a special offer for
1:54 you. Go to rollbar.com slash changelog, sign up, get the bootstrap plan for free for 90 days.
2:01 That's 300,000 errors tracked, totally for free. Get Rollbar trying today. Head over to rollbar.com
2:09 slash changelog.
2:19 We're back. We got a fun show lined up. Got Mike McQuaid here from Homebrew, Homebrew fame.
2:25 Obviously, Homebrew 1.0. Jerry, what do you think about that, man?
2:28 I was excited. I think our whole community was excited. It's a big announcement from a big
2:35 project that many of us have relied upon for years and years. And it's awesome to see anything
2:41 hit that 1.0 milestone. So Mike, congratulations on the big release and welcome to the changelog.
2:46 Thank you very much. Thanks for having me, guys.
2:49 Yeah, no, it's an exciting time, I think, for most of the Homebrew team as well, because
2:55 we've been sort of a bit haphazard with the version numbers. If you look at, I went through
3:00 and actually took the time before the release to go and tag all the old versions through
3:04 there. And some of them are, you know, multiple versions in the space of a week. And then you
3:09 have years, I think, between some versions and they're all a little bit arbitrary. And
3:13 now it's kind of giving us this chance to sort of become a more real software project and
3:18 start doing semantic versioning and start kind of thinking about how we're doing our release
3:22 process and try and have that stable base for people to be able to rely on.
3:25 Now, Adam, you had a homebrew show back before I was a co-host of the changelog, all the
3:30 way back in 2010, episode 35. You want to give us a little bit of background on that?
3:35 I wish I could, man. I wish I could remember six years back. I can barely remember last week
3:40 or last month. But just based on our own show notes, me and Wynn, when Wynn was part of the
3:44 show and it's kind of funny because now Wynn works with Mike as manager, manager of somebody's
3:50 manager or something like that at GitHub. But, you know, we caught up with Max Howell,
3:54 talked about homebrew. I think the show was a lot more loose then. I don't think we were
3:58 quite as standardized as we are now where we kind of go into the history and kind of go
4:02 deep like this. It was a bit just more, a bit more of a wing it kind of show, I guess
4:06 then. But fun talking to Max. I can't remember a single thing we talked about. I know we
4:09 talked about at least Mac, beer and scrabbling because that's what the notes say. So there
4:16 you go. But you can check that out at changelaw.com slash 35 or scroll all the way back or pretty
4:22 far back in the list of podcasts that you have there in your listener.
4:27 Yeah. So it's been a long time and definitely kind of a catch up show, but a new show, an
4:32 introduction, an introduction to Mike. Mike, we like to get backgrounds, origin stories, kind
4:37 of the roots of where you began in the programming trades. So can you tell us how you got started and
4:43 what got you to where you are now?
4:45 Sure thing. So I guess I first got sort of interested in computers and computer things being
4:52 young and when my parents brought our PC home. And it was always like, I guess my parents learned
4:58 that they could pretty much get me to do any chore, including like mind numbing spreadsheet
5:03 entry if it was on the computer. And, and I was just, I don't know, I was always fascinated
5:08 with the things. So when the time came to go off to college, I went and studied computer
5:13 science. And yeah, and basically just got more into, I guess, open source while I was doing
5:19 that. There was our curriculum was quite kind of Unix focused. So I ended up kind of using
5:24 Linux on my desktop and all the fun that, that, that produced, uh, back in 2007, using Gen2 to compile
5:32 everything from source. So it would take like days to get my system ready in 24 hours.
5:36 You were hardcore.
5:37 Well, I mean, I don't know if it was so much hardcore as just masochistic, but it was certainly,
5:43 I certainly learned a wee bit along the way about, you know, how, how software gets put together
5:49 and how things kind of build and how they fail and stuff like that. So, um, yeah, I kind
5:54 of dabbled with that through uni, started doing little bits of open source programming kind
5:57 of by myself, like publishing stuff on my website or whatever, but not really collaborating with
6:03 anyone and beyond kind of university group projects. Um, until after, I guess I was sort
6:09 of got a bit involved with the Gen2 kind of bug tracker and stuff like that. And then my summer
6:14 after graduating, I did Google summer of code on the KDE project, uh, which is the Linux
6:20 like, I guess a desktop environment or like the kind of GUI and stuff like that. Um, and yeah,
6:26 and I kind of worked on that for a few years and that, that was great fun. Um, and then in the
6:30 end, I remember the very, so I had a job, um, where I was doing like cute, the kind of toolkit
6:38 it's based on, which everyone thinks is cutie, but it's actually cute, which is always interesting
6:42 when you refer to someone who doesn't know this as, oh, they are also a cute developer
6:47 and then, yeah. So there you go. Um, but yeah, so I was doing that. So part of the job, a lot
6:55 of clients back then, at least were wanting stuff that would run on at least two out of three
7:00 platforms, Windows, Mac, and Linux. So I would, I had like an environment for each of those platforms.
7:05 Um, so I had kind of a Mac that I kind of picked up because of that. Um, and I didn't really use it
7:11 for much. And then I remember one day I had some friends around and we were trying to watch a dual
7:15 monitor set up and I was trying to watch a DVD without tearing on my new NVIDIA card or whatever.
7:20 Um, and I couldn't get a DVD to play. And this was in 2008, I think, uh, you know, 2008,
7:27 2009 and I couldn't get a DVD to play properly. And I was just like, that was the day I realized
7:32 that my, my days with desktop Linux were done. And so I, I pulled out the Mac, plugged it in
7:38 and then that all worked perfectly. And then sort of slightly moved my approach over to the Mac,
7:42 was doing some KDE on Mac stuff before I kind of gave up. Um, and then kind of used Mac ports
7:48 a bit. And then I ended up creating this while working on this thing called Mac porch dummies,
7:52 which kind of sort of led me a little bit into homebrew. Mac porch dummies was a way of like,
7:57 sort of pretending that a bunch of stuff was installed that was provided by OSX.
8:01 And then I kind of knew Max, he was a friend of a friend. Um, and we ended up kind of meeting up
8:07 and going for a beer and stuff like that. And he was like, Oh yeah, you know, there's this
8:09 homebrew thing I've kind of made. You should check it out. It sounds like it's sort of
8:13 in keeping with your interest. So I guess that was about 2009. I started working on homebrew.
8:18 And I guess since then I've been kind of working as a maintainer and yeah, just never really stopped.
8:23 So that's an interesting way to go to the Mac. I guess my story was a little different. I was on
8:30 windows and it just was a better machine. So I just kind of went to the Mac and didn't look back,
8:36 but, uh, you know, moving to the Mac is that's kind of interesting story to kind of get to the Mac
8:40 basically.
8:41 Yeah. It's, it's weird, I guess, because when I talk to a lot of people who, I guess being involved
8:47 with the project like homebrew, and I'm also kind of really obsessive about like OSX styling. Like I,
8:52 I still use text mate as my main editor just because I mean, as much as I love things like
8:57 Atom and sublime, they don't look like quite right.
9:00 Right.
9:01 And so everyone assumes I'd be one of those people who's been on a Mac since I was,
9:04 you know,
9:05 Yeah, exactly. Like since you, what year was that? Cause I mean, you might be a purist.
9:10 Well, so I guess that was 2000 and yeah, 2008 or nine. I kind of,
9:15 so the first Mac I had was on leopard on 10.5. Also the first version of OSX that homebrew
9:21 supported. So yeah, I've, I've been on a wee while at this time, but like, yeah, I feel like I've,
9:27 you know, the really hardcore folks are the people who had the, the OS nine machine at home.
9:32 Right. A little bit, a little bit sooner to the party than you, but not much. In fact,
9:36 my path is very similar. Only I was on Ubuntu in college, started off in windows and high school,
9:41 Ubuntu in college, and just got sick of, of having to deal with mostly device drivers and wifi back
9:48 then. Um, and the Mac was tantalizing, uh, I think it was probably 2007 and leopard was also my first
9:54 version. That being said, man, I'm far moved away from text mate at this point. Are you at least on
9:58 text mate too, or are you like real old school? Yeah, I'm on text mate too. And I'm, I'm kind of
10:03 scratching my own itches quite a bit more like, you know, I've, I've made a few bundles for it and
10:08 all this type of thing, but it just fits pretty well with, with my workflow. So as I say, I try
10:14 other things, but then I just, there's tiny little things that annoy me and I might just be too old
10:19 and far gone at this point to stuck in my ways. So give us a little bit of the context around,
10:24 uh, you gave us how you met Max and you started contributing to homebrew and using it a lot.
10:29 Um, give us the, the timeframe around Max's kind of transition out. You're now lead maintainer. Of
10:36 course, it's huge project with thousands of contributors. And, um, many of that is because
10:42 of the way that you can use to contribute formula, which has recently changed. We'll talk about that
10:46 soon, but help us out with the transition where you, you became the man when it comes to the homebrew
10:51 community and project. Well, I mean, I guess, so the lead maintainer thing is quite recent. Like the,
10:57 that title at least is literally just something we sort of decided shortly before homebrew 1.0. Um,
11:05 so Max, I guess like, like any open source project, and we try and build this into the way we kind of
11:12 run homebrew there's the expectation that people will kind of come in and come out and stuff like
11:16 that. And I think Max just ended up having a different job and was spending less time on homebrew
11:22 and some other people stepped up and were spending more time on homebrew. And, you know, in the end,
11:27 I think he just ended up sort of drifting out and other people ended up drifting in. And when Max left,
11:32 so he was the kind of, you know, the lead at that point. And when he left, we kind of agreed that we'd
11:39 sort of have a sort of democratic situation where, you know, we would decide things more or less by
11:46 committee and stuff like that. And I think that, and there's definitely a lot of open source projects
11:52 where that goes pretty far. I think where we struggled and where we felt the kind of pain of that coming up
11:57 recently was when, well, I was kind of contributing a lot more than other people were. And when you have
12:05 the idea that almost it's a democracy and everyone gets a vote, like it doesn't with the way, I guess I
12:12 read a thing about the governance models and the best one, you know, that meritocratic is a really loaded
12:18 term. And it's not, I don't think it applies in open source, but that what people have described as
12:25 the meritocratic governance model is almost like you have more decision-making power based on doing
12:31 more work basically. So, you know, and that's not commit counts or lines of code changed or whatever,
12:36 but basically if you're more involved, if you're spending more time in the project
12:40 and you're kind of leading the direction a bit more, then you probably have a bit more say.
12:45 So I think the lead maintainer thing came about because I was essentially kind of filling that role
12:50 and, you know, to validate some other kind of complaints, I think that were made,
12:55 like I was maybe sort of overruling or pushing through some things and not really operating by
13:01 the committee side of things. And my understanding was that people were annoyed that I was doing that,
13:07 whereas I think actually, like having talked about it more and come to the lead maintainer thing,
13:12 what was annoying people more was actually this disconnect between the reality of like me kind
13:19 of basically leading and other people feeling like they couldn't overrule me on things.
13:24 And yeah, and I guess, you know, I'm sure you've all read and heard about, you know,
13:31 all the stuff about implicit and explicit power structures and githubs as a company has had its
13:36 movement through there as well. And I think that's basically what the move has been is that it's
13:41 moved from being an implicit to an explicit thing. And it's just, as a result, it's made a few
13:47 little things a little bit easier.
13:48 So there was an explicit transition then from max to you or?
13:52 Well, no, I guess so. The transition was from max to, I guess, every, to all of the maintainers,
13:59 I think it was five or six of us at that point. And then that we grew up to, I think, 13 maintainers.
14:06 And then the transition from that model to being me with, with the kind of majority agreeing that
14:12 that that was a good move.
14:13 I'm sitting here on the contributors tab, man. It's funny you say that too, that it wasn't just
14:19 you know, contributors in terms of code, but contributors in terms of effort across the
14:23 project, whether it's thought leadership, governance, whatever. I think that that's something that
14:29 the contributors tab doesn't really reflect very well. But one thing that I was thinking
14:33 about on the contributors tab is I'm looking at Jack Nagel. I'm looking at you. I'm looking at Adam V.
14:37 I'm looking at Max and several others that kind of line up there. I kind of wish we can overlap,
14:42 you know, see Mike and you and Max and Adam, see all of your graphs kind of in the same timeline,
14:49 because just kind of like looking at them, I can see where Max was having fits and starts during a
14:54 couple during 2012. And you seem to like start to get more involved in terms of contributions.
15:01 And then it seems like when Max dipped away and stepped off to do his own thing or go to Apple or
15:06 wherever his path has taken him is when you got more involved in the same thing with Jack and a little bit
15:12 the same thing with Adam as well. So it's kind of interesting to look at the contributor graph that way.
15:16 Yeah. And it's interesting as well, because as I think you were, I suspected you were going to
15:21 mention later on anyway, there's the, we've split into two repositories now. So you've got Homebrew Brew,
15:27 which is the package manager, and Homebrew Homebrew Core, which is the formulae. And we kind of split
15:34 the history between them as well. So you can kind of see the kind of this quite a difference in
15:40 contribution patterns between the two. And there's the same sort of faces in there. But you know,
15:44 there's someone who, and people who are very, very active in one and not really in the other. And I
15:50 think that was the big thing where like Max particularly was kind of always most active in
15:56 the package manager itself. And I guess lately I've been sort of similar. I've kind of, you know,
16:01 had a reasonable number of contributions to the packages, but like not nearly as much as some other
16:06 people. And in the last, the 1.0 release has been more of a thing around the package manager rather
16:12 than the packages itself. And so that's where my focus has been the last, I guess, few months, certainly.
16:18 So when you went into this meritocracy or voting based things, and you, you all found that it
16:26 wasn't moving forward at the pace or the, you know, the desired pace that you guys wanted it to. And
16:32 then because you were already kind of implicitly acting as a leader, or as you thought, perhaps
16:38 overstepping your bounds, but people actually appreciated it. Did you end up just kind of like with this flat
16:44 structure where it's, you know, Mike McQuaid and then everybody else, or is there underneath that
16:50 structure? Is there a group of core maintainers and then everybody else? How exactly does it structure
16:55 it now?
16:56 So, I mean, we have what our kind of lingo is, and I realize it varies from project to project is
17:02 what we call a maintainer is basically anyone who has commit access. And historically, that's always
17:08 been based on, you get commit access to both repositories, you don't just get it to one. That,
17:13 that may be something that changes in the future. We have people who are very interested in just the
17:16 package manager and not the packages or vice versa. And then we have contributors, which are anyone who's
17:22 ever submitted a single commit, um, to any project, basically within the homebrew umbrella. And then we
17:28 have users, obviously, which goes without saying. Um, so we've, yeah, so we've moved from a model of
17:34 being all the maintainers are like, at least on paper, kind of on an equal footing to being, I'm, I guess,
17:41 technically in charge, but then it, the way I've had a good manager in a workplace deal with this stuff in the past is that
17:49 they basically only invoke their manager status when they have to, when, so they will always try
17:55 and like have a discussion and win the discussion on an equal fitting. Well, not win, but you know,
18:02 convince other people of their point. And I feel like it's the same thing with us now that the lead
18:08 position is mainly just there to be able to have me be able to say sometimes like, okay, well, we need
18:14 someone to make a decision here. We have two sides who are kind of equal or equally like there's some
18:20 stuff that is important in the direction of the project. And this is a feature that other people
18:25 may not feel passionately about, but I feel that this has to go in and it's important for us to have
18:29 this feature, even if the bulk of other maintainers might disagree on that front. And, and maybe part of
18:36 that is because, you know, we, we do, we started gathering analytics, which I don't want to get
18:41 too much into, but you know, before that, a big part of it would be, I mean, I, I was the person who
18:47 did the most, I guess, talks at conferences about homebrew and stuff like that, and have kind of
18:51 traveled around and met a lot of users. And there's a certain amount of stuff that it doesn't, it doesn't
18:56 turn into mailing list posts. It doesn't turn into issue tracker, but you, you speak to the same sort of
19:00 power users again and again, and you hear the same complaints again and again, like in person.
19:04 And then some of that has sort of driven the kind of, I guess, product direction of homebrew maybe a
19:10 bit more because you just realize like, okay, this isn't, people are not filing issues because they're
19:15 confused about this. This is just something that they find annoying. And people generally don't find
19:18 like file issues about just things that are like annoyances. They file them about things that are
19:24 actively broken or whatever.
19:25 So let's touch real quick on GitHub's relationship with homebrew with regard to,
19:30 you know, employing you and you're the lead maintainer. And is this this officially sanctioned
19:34 work or is it, are you still doing it like completely on the side? And then we'll take our first break.
19:38 And on the other side, we'll talk about, uh, the new stuff in homebrew specifically,
19:42 I will probably start with the split repositories, but how does GitHub play into the mix?
19:46 Um, so I guess I've been at GitHub coming up to three years. So certainly the majority of my time
19:53 working on homebrew has not been at GitHub. Um, and GitHub, similarly with my previous employees,
19:58 really like they, they have, I guess, paid me to work on homebrew on occasion in the, when I have
20:05 had Google summer of code students through GitHub and stuff like that, or homebrew Google summer code
20:10 students, which have been blessed with GitHub. I've spent work time on that, uh, in terms of like day
20:15 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
20:22 something for like five minutes, I'm waiting for a test run to finish. I'll go and fire through my homebrew
20:27 emails, triage, give a little reply, whatever. And then equally, there's something that is going to,
20:33 or it's currently blowing up and will affect GitHub employees because we use homebrew fairly heavily internally.
20:39 And then I'll fix that. But I don't generally do kind of the day to day kind of homebrew work during
20:45 GitHub time. So that's mainly my kind of evenings, weekends, spare time, et cetera.
20:49 Very good. Well, I think that sets us up. Let's take a break. And on the other side,
20:54 we'll talk about what is new with Homebrew 1.0.0. We'll be right back.
20:58 I talked to Daniel Reed, head of design at TopTile about their new expansion into TopTile designers,
21:07 doing for designers what they've done for developers. We talked about why TopTile works for designers.
21:12 And this is what she had to say.
21:13 As a designer, the big, or as any kind of creative person, the big overarching question is always like,
21:19 how can you find inspiration? And for me personally, and for a lot of creatives that I've spoken to,
21:26 it's really about traveling, exploring, and being accountable for your own career. And I think as
21:31 a TopTile designer or a remote designer in general, the ability to be able to switch up your lifestyle,
21:38 change contexts, meet new people, have new ideas sort of infiltrated into your life by
21:44 having that freedom and flexibility is something that's absolutely fundamental to doing great work.
21:48 For any designer that is wanting to pursue their skills, to be accountable for their life,
21:54 to have new challenges, that's the real power of TopTile, I feel. You're not just stuck with one
22:00 product, one company, or even one agency, but you can choose to work on multiple occasionally,
22:06 or a range of different clients. And I think that that keeps you fresh. It gets you
22:11 involved in new technologies, different people, and is really fundamental for being sort of switched
22:17 on as a designer. All right, that was Daniel Reed, head of design for TopTile. To learn more,
22:22 go to toptile.com/designers. That's t-o-p-t-a-l.com/designers. Tell them Adam from
22:29 the changelog sent you, and now back to the show.
22:34 All right, we are back celebrating, cheersing even, on Homebrew 1.0 with a lead maintainer,
22:43 Mike McQuaid. See what I did there? I like that.
22:45 And Mike, we like to hear all that's fresh and new. We haven't covered Homebrew for many years,
22:51 you don't have to go through the entire history of the source code, but I just want to camp out on
22:57 what's new with the official 1.0 release. And there's a lot of highlights. We have the separate
23:03 repos, we have the community site, we have the move out of user local, user local homebrew, we have
23:10 the software conservancy, the software freedom conservancy thing. So we'll kind of work our way
23:17 down through the list. But let's start with where we left off, which was that you guys split the
23:22 repositories up. And one thing about the original Homebrew repository, which by the way, it's still
23:29 out there, you guys have it under Brew, under legacy dash Homebrew, is it was always one of the most
23:35 forked and starred and watched and contributed to, probably has the most PRs perhaps of almost any
23:44 repository on GitHub, because of the reason that not just, like you said, not just the package manager
23:50 itself, the source code that makes up Homebrew is in there, but also all the different formulae,
23:56 which is how you, you know, the descriptions of how packages get installed and uninstalled.
24:02 So when I first saw that you guys split up into different repos, I thought, oh no, they had this
24:06 great star count, they had this great fork count, you know, this is kind of this statistical legacy
24:11 there that now is going to be broken. But that being said, you all have set up analytics over the
24:18 last year or so, that gives you better stats than just the stars and the forks for actual usage.
24:24 So start off with telling us the onus behind splitting the repositories, and then perhaps
24:30 give us some insight into the analytics that you guys have been tracking.
24:33 Sure thing. So I guess the main onus is, the problem with Homebrew before was,
24:39 if you wanted to get, say you wanted to get a new version of some package, you run brew update to kind of
24:45 update Homebrew's kind of definitions. And that also updates the package manager.
24:49 The problem with that is, if you want the new update of something,
24:52 and we have made some change on master, which breaks something for you, then there's no way you
24:59 can get the new version of OpenSSL or whatever, and not get the broken thing as well.
25:04 So we've kind of had that goal for a long time to be able to separate the package manager from the
25:09 packages. And I mean, that's, that's what every other package manager does. And to separate those
25:14 two things out, so we can provide some degree of stability. So that was the first step in the
25:20 process, which again, is kind of noted in the release notes that now we kind of jump between tags.
25:25 And so you can, if you're kind of a homebrew maintainer, then you, you continue to track
25:30 the master branch, but everyone else kind of jumps between 1.00, 1.01, et cetera. And that gives us
25:36 time to be able to do more QA on the package manager itself, while still having that rolling release
25:40 approach for the formulae. And in terms of stars and all that type of stuff, like, yeah, that still
25:46 breaks my heart a little bit. I still weep for the star count, but you know, it's, it's slowly getting
25:53 its way up on the new repository and stuff like that. And it is useful to be able to see stuff
25:57 like GitHub's kind of contributor graph and see how that varies on the package manager compared to the
26:01 packages. Cause that's interesting. And another thing on there, which is a wee while off probably
26:07 still, but is we're trying to get the package manager. There's another thing called Linux brew,
26:11 which is like running homebrew on Linux and stuff like that. And having the package manager be
26:15 separate means that we can, we can separate out our package definitions for, but still have the
26:22 package manager itself be cross platform support platforms, stuff like that. And it, it generally
26:28 just provides it as a nice tool. Who knows? Maybe one day it might even be bundles of Ruby gem
26:32 you can use to kind of access your, your stuff. Um, but yeah, nowadays we have, as you mentioned,
26:38 the analytics that was introduced, I think it was March or so. And that basically provides us with the
26:45 ability to see, we can't see any stuff about individual users. If I wanted to see, okay,
26:51 this particular user, what have they done? But that's not available to us because we kind of just
26:55 use it, a random UUID that people can reset at any time. Um, so we track users just so we can get kind
27:01 of user accounts. Um, so I've got kind of the analytics dashboard open right now. It's, you know,
27:06 it's kind of a slightly weird mapping from what it's normally used for, but it basically lets us see
27:11 what commands people run like in proportion to each other, what packages people are running,
27:15 what versions people are running. And the really useful stuff for us is what is like the percentage
27:21 breakdown on stuff like OSX versions. So then we can prioritize the support on different things. And also
27:27 what are the most popular packages that people install and what options do they install them with?
27:31 So again, we can kind of prioritize options and things like that. So as a whole, it basically just
27:36 provides what analytics tends to do for, for any, um, piece of software, which is, it lets us inform our
27:43 future design and inform kind of what things we focus on based on the stuff our users actually use,
27:49 rather than our speculation on what the users use, which is something we didn't have before.
27:52 Well, GitHub stars and watchers are indicators, but they're not exactly,
27:57 I don't think, uh, those things are for maintainers. I think they're more for the general public
28:02 to show some, I mean, cause I can't give you that deep of insight, like knowing watchers and stars,
28:08 those are important, but it's not giving you deep enough insights that you need as a maintainer these
28:12 days. Yeah, I agree. Like it's not, you know, you certainly can't have like, oh, well,
28:17 we did this, we ship this new feature and we got, you know, 5% more stars. That doesn't really,
28:22 that doesn't really help us. Whereas when we see, we ship this new feature and our error
28:26 counts gone up from, you know, 0.01% to 0.05 or whatever, and stuff like that. Like that's
28:32 more of the type of things we're concerned about. And it's particularly useful when,
28:37 you know, when we can go and see if something breaks, like we, we periodically go through and,
28:42 you know, do some porting or when a new version of OS X is out or whatever. And it's useful to
28:47 be able to go through all of our packages and be like, okay, well, this thing's broken on the new
28:52 version of OS X, but no one has actually installed this since March. So let's not go and spend like
28:56 three hours trying to fix this piece of software that no one is actually using. We can just remove
29:01 it instead. We call it sending it to the boneyard, which means the definition is still there. If
29:07 someone wants to pick that up at a later point and pull that through, then they can do that.
29:11 That's, it's a little bit easier than kind of navigating through the Git history if you're not
29:14 a Git whiz. And it lets us kind of push away the kind of maintenance burden of that for a wee while at
29:22 least. Well, you wouldn't think twice when delivering an application that you do for work or
29:27 whatever about installing error tracking or installing monitoring or something like that. So
29:31 it's almost the same case for, you know, homebrew is that you need something to track
29:36 what's happening so that you can make good decisions for the future, right? You wouldn't think twice.
29:41 Yeah, exactly. And I think that's, that's what it comes down to for me is I have used a lot of
29:47 these tools. Well, I mean, across, I think every workplace I've been at, I've used some sort of
29:52 kind of metric tracking. And again, people, I guess people sometimes think that metric tracking is just
29:57 Google Analytics and like, oh, well, they don't have Google Analytics installed, so they're not
30:02 tracking metrics. And so, well, actually they're probably tracking metrics on the back end. And
30:06 they're not doing this because they're selling your personal information. Well, I mean, some companies
30:10 are doing that because they are selling your personal information. But in homebrew's case,
30:13 it was kind of disappointing to see where exactly we're not. I mean, we've specifically designed it
30:19 so that we couldn't, even if we wanted to kind of get anything that would be commercially viable out of
30:24 this. So the thing is, is that it's kind of disappointing when you release some stuff like
30:29 the analytics, because you get some people who go and express kind of obviously some sort of
30:34 solidarity with like, well, okay, I understand why you're using this. And most homebrew's users are
30:38 developers. So there is that, but then there's this very vocal minority who, you know, who escalates
30:45 beyond that. And it becomes, how dare you have this, how dare it be opt out rather than opt in.
30:51 My reasoning, obviously for it being opt out is because you can gather better data if you're
30:55 tracking the majority of people and not just the subset of people who decide to opt in. They may
31:00 well have different behavior and stuff like that, which means that you're not able to make as sound
31:05 decisions. But yeah. So, and that vocal minority, you know, that they got very upset on some of them on
31:10 hacker news and Reddit and stuff like that, and then start sending me personal emails telling me to
31:16 you know, do all sorts of things. And it's not, yeah, it's, it's not unpleasant. And it is with
31:22 hindsight, it's funny. And I'm lucky enough to have a thick enough skin that it, it didn't bother me too
31:28 much. But I mean, it is depressing that we still are in 2016 and have to deal with stuff like this,
31:35 because I mean, if there's any of those people who, and I did say this to someone who, um, who
31:40 emailed me, I mean, that, that's what kills open source. That's what drives open source maintainers away
31:45 and kills successful open source projects like me. And well, I had moments, but certainly some of our
31:52 other kind of major maintainers had to be talked into staying in the project at all because they were,
31:57 you know, and several of my, we talk about diversity problems sometimes in open source as well,
32:01 you know, several of my coworkers who aren't just, you know, young white men who I talk to about the
32:07 homebrew thing is they just said, that sounds awful. I would never want to be involved with a project
32:13 where I would have that abuse for something I do in my spare time to try and help out other people.
32:18 And I think it is, you know, it does seem to be getting better. And we do seem to be as a community
32:23 recognizing that like this behavior is not acceptable and this behavior is not what we,
32:28 how we build software. Um, but you know, we don't necessarily have all the kind of
32:35 toolings and institutions and everything quite figured out how to kind of stop stuff like that.
32:39 When, as you say, it's you're an email or a Twitter message away from someone starting to be mean.
32:45 Well, sorry that you had to go through all that, Mike. Um, in light of the change and
32:50 the fact that you guys have had it running for a while, could you, would you mind sharing some
32:53 stats with us like, uh, users or popular packages or what, what fruit have come from these analytics?
32:59 Yeah, sure. So, I mean, I can see the kind of active users, which I guess is someone who's
33:04 run a homebrew. Like, so there's, I think 2000 people who've run a homebrew command in the last
33:09 30 seconds or so. Um, there may be more than that. And then I can see kind of the version
33:15 breakdown. Interestingly, there's still a lot more people running on pre 1.0 and the kind of active
33:21 users right now. There's like over a thousand on 0.99 and then 637 on 1.05, 209 on like the kind of
33:31 master, the last kind of master commit and stuff like that. And then I jumped through to kind of
33:36 the most popular packages and somewhat unsurprisingly open SSL is the most popular package by
33:42 far, uh, then followed by package config and which is used like, and it's one of those things where no
33:47 one probably intentionally installs it, but it's a dependency for a lot of things. Then libpng,
33:53 SQLite, great piece of software, node.js, free type, again, probably something that not a lot of
33:58 people are installing intentionally and then git. And so, yeah, it's kind of, it is valuable being
34:04 able to see these things and, and the, the dropdown is kind of quite impressive. So, I mean, open SSL,
34:10 we have in homebrew itself and this tracks homebrew and our kind of third-party repositories.
34:15 So, you know, maybe 4,000 different packages. So of that open SSL itself has like 3.5% of all
34:22 installs of all software. And so it's quite interesting to see how quickly it drops off
34:28 and, and you get below kind of 0.1% within the first, you know, 170 packages.
34:37 Yes. In light of transparency and open source, kind of the spirit of the community, have you considered
34:42 making the, I don't know if you can even do that with Google Analytics, but like an open dashboard
34:46 where anybody can come and just see the usages?
34:48 Yeah, you can't, unfortunately. I mean, what I have been considering is doing a database dump every so
34:56 often of like the stuff that I'm kind of most interested in. Um, but yeah, I mean, it's,
35:02 again, it's, this doesn't seem to be a trivial way of automating that. So it needs to be me manually
35:08 going in and like clicking through every time. So yeah, I'm still, that's still kind of on my list
35:13 of things to try and do to try and improve the transparency of this. And then hopefully people
35:17 can see that this is not, you know, there's nothing nefarious happening here.
35:21 Yeah. Because I mean, they can see the source code at least of where the calls to track are
35:26 happening in Google Analytics or calls off to Google Analytics, but it'd be really cool to have,
35:30 you know, publicly available the results of that data, because then you can have people draw other
35:35 insights or, uh, just enjoy it, but even yeah, remove that fear of what, what y'all are tracking.
35:41 And well, and the thing that some people have asked already actually about that is, um,
35:45 people who are scientists who've been asking, you know, if it would be really useful for me as I've,
35:51 you know, worked on some piece of software as part of my PhD to be able to put in a paper,
35:55 well, this has actually been used this many times or installed this many times or whatever,
35:59 because that gives some, I don't know, I'm not a scientist, but that gives, I think,
36:03 some sort of waiting or a sense of importance to the kind of work they've been doing, which I can
36:09 understand. Or people who are putting the work in to maintain specific, uh,
36:13 formulas or formulae as you guys like to call them to know, like, is this worth my effort? Like,
36:19 oh, I, me and six other people are using it. Uh, and I got six complaints, you know, that's,
36:23 that's just the total, that's all the users as opposed to, oh, this has, you know,
36:27 a lot of people are really drawing value from this. I'm going to continue to maintain it.
36:30 Yeah. Yeah, exactly.
36:31 Well, one thing you mentioned is, um, updating in light of those stats, you know,
36:35 not everybody's on 1.0, but, uh, just moving on to the, some of the other new features
36:40 is you guys now have auto updating built in. Is that correct?
36:43 Yeah, we do. So now if you run through install, it will check for updates in the background,
36:49 I think by default, once a minute. Um, when I say in the background, I don't actually mean in the
36:53 background. I mean, before you run the command, it will check for updates. Um, and that was actually,
36:58 that's one of my favorite features in there because it was a really fun exercise for me in kind of
37:02 performance benchmarking, like on kind of the full stack, because, um, I, this is something I had a
37:09 while ago is I was like, okay, well, I want to be able to run auto updates because a lot of the time
37:14 when things break, we tend to get a fairly long tail of people who haven't run the update, who file
37:20 the issue for something which is fixed, you know, a day, a week, sometimes even a month, a month earlier.
37:26 And I've always kind of wanted to have that. But then the updater at that time took probably about
37:31 15 to 30 seconds, depending on where you are in the world and stuff like that sort of minimum
37:36 to do that. And that always kind of frustrated me. So in the end, I kind of poured some time into that
37:42 and tried to make it worked on a few things that made that really fast. And one thing was kind of
37:49 more reliable, I guess. So one thing was kind of moving some of the auto update stuff from Ruby into
37:55 bash, more just because Ruby gets more upset when you modify its own code underneath it than bash does,
38:02 or at least it's easier to work around that in bash. The other thing that was a kind of fun, but
38:08 completely overkill thing was with me being lucky enough to work GitHub. I noticed that the slowest thing
38:14 thing by far was doing a git fetch on like a massive repository like Homebrew that's had huge numbers
38:19 of pull requests and stuff like that. So that git fetch, just like a no-op git fetch when there's
38:25 nothing to fetch was actually pretty slow. And so I was at that time on the GitHub API team. So in my
38:34 kind of weekend, I figured I'd go and see if I could play around and figure out a way to make that faster.
38:40 And because we have like a cache API layer and there's like an API code you can use to get the
38:47 kind of latest state of a branch. So I kind of tweaked that a little bit. I made it so you can
38:52 pass in the SHA one from git as the e-tag to that. So you get three or four unmodified if nothing has
38:58 changed and therefore not use up your rate limit and allow us at GitHub to kind of deliver that from
39:03 the cache. And basically, yeah, as a result, like flip that git fetch operation to just being an HTTP
39:09 call. And that's like way, way, way faster and for both GitHub to process and for Homebrew to process.
39:17 So as a result, I was able to kind of play around with that and do some parallelization and stuff like
39:22 that. And now it's generally kind of under a second or around about a second and down from kind of 30 when
39:30 you are kind of doing an auto update. So that seemed like a reasonable amount of time for people to kind
39:36 of spend on every call, considering, you know, if you do a brew install, the compilation and
39:41 extraction time are going to be significantly longer than that anyway.
39:44 Life is good when you control both sides of the API, right?
39:47 Yeah, no, it's much, much easier when you have that. It's nice to be able to kind of jump in there and
39:56 play around. But I think even if I didn't control that side of things, there might have been ways I
40:01 could have played around and made it a little bit faster. But no, it's certainly easier, as you say,
40:05 when you have that. And when you have very smart co-workers who I can kind of bump it off,
40:09 who kind of actually work on Git itself as their day job and then be like, okay, am I being stupid here?
40:15 Like why this is slow and all this type of thing. And then discussing an approach with
40:19 them. That was kind of pretty fun.
40:21 So just one aspect of user experience, I think focusing on the speed is key there. And in fact,
40:28 Adam and I were kind of lamenting a little bit before the call about certain bits of software
40:33 that do auto update, but you don't run them enough for them to ever be updated. So my example,
40:39 for me, at least is Firefox, which I don't use on a regular basis, but I do use if I'm doing browser
40:45 testing or for one off purposes. And it seems like I think they may do it in the background now,
40:49 but it used to be every time I launched Firefox, it would say, hey, we have an update update.
40:53 And it seems like brew for me, at least I use it all the time. So I don't have that issue,
40:58 but it could be the kind of thing where you don't launch it very often. And then it feels like every
41:01 time you're running the brew command is updating. Sometimes, sometimes, like, I just got to get
41:08 this thing installed. I need this command so I can fix something that's on fire. So speed,
41:14 I think is important to fix that is if it happens real fast, no big deal. But in light of there is
41:20 a new update, does it automatically run that for you? Or does it prompt you where you can say not
41:24 right now? Have you thought through those kinds of things?
41:26 Well, so we have, in terms of our commands, we have a separation between update and upgrade.
41:32 So update is basically get all the definitions in the package manager,
41:35 have the latest version, and then upgrade is like, you know, install open SSL 1.1 instead of 1.0.
41:42 And so yeah, so we don't auto upgrade.
41:45 Sure. But I'm referring to like, say I run brew install jq, because I need to parse some
41:51 some JSON on command line real fast.
41:53 Yeah. And you don't want to wait a couple of seconds for the update.
41:56 Yeah. I mean, that's one of those things that we, like we kind of considered, but in the end,
42:02 the kind of support burden for that is, it's worth it for us. Like you would not believe how many,
42:09 like annoying, because again, I don't think we mind that much about the issue count or whatever,
42:16 or the number of issues people are filing. But what's the worst thing is when you get the same
42:20 issue again and again and again, and the response to fix it is the same thing again and again and again.
42:25 And like my attitude is always try and automate myself out the job.
42:29 So like if it's the same command, we're having to tell people to run like every single time.
42:34 And if people are still not running that command, then it's like, well,
42:37 we're going to just run that command for you.
42:40 I think it's definitely that I think the pain is alleviated because of the small payload size of
42:45 right of updating homebrew. Whereas in the, like, for example, with my Firefox example, you got to
42:51 download like a 60 megabyte file or whatever it is. Um, so it's more of like, okay, I'm gonna sit and
42:56 wait. But in this case, even when you do have, I run brew installed JQ and I'm, you know, I'm a dot
43:03 release behind. We're talking like seconds to get that thing upgraded. Is that right?
43:07 So that's the point where it's doing the, the auto updating is like when you're doing a brew
43:10 install, not just brew update.
43:12 Yeah. Yeah. So, uh, we have, so basically a brew install now does a brew update in the background.
43:19 Okay. I'm, I'm tracking now. I heard you said before, but I wasn't sure what under which command
43:24 it was doing in the background. You said once per minute, something like, well, if you do brew update.
43:29 Yeah. So if you do brew update, then it will basically skip them or the next skip even looking
43:34 for the next minute. And then I, as I say, it's optimized for the no op case where if you don't
43:39 actually have anything to update there, then it will just ignore it.
43:43 And as you said, it's just definitions, right? So it's just pulling back like the
43:46 latest things are available to brew install.
43:48 Yeah. Yeah, exactly. Uh, and invariably that's, I think the other thing that's kind of tricky
43:55 from a package manager perspective is that you have this conflict between what people want and, uh,
44:01 what people need where, you know, humans myself included are lazy. And if you can avoid upgrading
44:08 something now, and if you can kind of put it off until tomorrow, like most people will,
44:12 but then there's some of this stuff that it's like, well, actually that's a really big deal with
44:16 security. So you need to update this now. And if you don't want to update it now, then we've got to
44:23 sort of like nudge you in the right direction so that you do that so that your machine doesn't get
44:27 owned. And then it's, we're at least partly responsible. And as I say, it's that kind of weird
44:33 conflict that you have where sometimes you've got to just force people to do things or not
44:38 implement things that they want you to like a recent thing that could have made the 1.0 release
44:43 notes, but actually it, I kind of pruned it from there is we don't, we used to let you run homebrew
44:47 as root. Um, and like, you know, you would have to completely change all the ownership. So it was
44:54 root and everything like that to almost emphasize that, look, I'm really sure. But in the end,
44:58 we're just like, you know what, there's a use case for this, but it's just a really bad idea.
45:03 Because if you run homebrew as root, but we don't, like other package managers that run as root,
45:09 they drop privileges because that's what they're designed. So they will run as root. And then when
45:13 it actually comes to doing installation or whatever, they'll go and just be like, okay, I'm a user now
45:18 with no privileges, so I can't do stuff. Whereas in homebrew, because the vast majority of our users
45:23 are not running as root, we haven't implemented that. And we don't have the motivation to implement that.
45:27 So if you run homebrew as root, like a make file can now literally change any file on your entire
45:32 system. And so like, that's bad. And we added a sandbox that means that obviously you're running
45:41 as the same user. And then we stopped the build process from being able to write to arbitrary
45:46 locations in your system. But again, to make it even worse, sandbox broke when you were the root user.
45:51 So we had to disable the sandbox for the root user. And at that point, we were like, okay,
45:55 this is just way too dangerous. And unfortunately, we need to make the call that we know better than
46:01 other people do by assessing the risk in this situation. Because we've seen what happens when
46:07 there's a make bar log that starts trying to just delete random files of your system. And users maybe
46:11 haven't seen that. And when that happens and they destroy everything and they don't have any backups,
46:17 they may not hold us responsible, but they kind of should if we have seen that coming and we've not
46:22 addressed it properly. So yeah, fun times.
46:26 Well, while we're talking about technical changes, well, let's hit on one more. And then we'll take
46:31 our next break, which is you've changed the default location of the homebrew repository. In fact,
46:37 I believe as you upgrade it, we'll move it for you from user local to subdirectory user local homebrew.
46:44 Yeah, can you speak to that change? And then the implications of what all what all entails?
46:49 So there's always been a bit people have had a bit of a love hate relationship with homebrew being
46:53 installed in user local. And the main reason homebrew is there is because originally, at least,
47:00 was because that's in your compiler and a bunch of other Unixy tools, they look there by default.
47:05 So that basically means with Ruby gems and various other things, if you have a library in there and
47:10 user local lib, user local bin, then they will look in there. And you don't need to like manually
47:15 specify your location. So that works kind of quite nicely for most people. And again, when homebrew
47:20 kind of got started, that's something that helped is, again, like adding to this sort of zero
47:24 configuration approach that homebrew is taking on things. So the problem with this, as time goes on,
47:29 and we say in our repo, like, oh, yeah, we want to add a readme, we want to add a code of conduct,
47:34 we want to, you know, add a bunch of stuff in our repository route. The problem with that is
47:42 all that stuff ends up then getting dumped in user local. And then people like, okay, well,
47:46 user local bin wget, okay, I'm fine with that. User local, like, readme.md, that feels kind of
47:54 weird to me when there's other stuff in user local and people, people were getting annoyed with that.
47:58 And I kind of understand that. So it was actually one of our users came out with something which was
48:04 kind of, I mean, frankly, a hack that had never really been patched, which was
48:09 the homebrews, by default, homebrews what we call the prefix, which is user local. And that's where
48:15 all your files get sim linked into, like user local bin, et cetera, as I was saying before.
48:20 And that has actually remained unchanged. And that was the same as where we had the repository
48:25 previously. But there was a hack you could do where you could install the repository in a different
48:30 case, in a different place and sim link it funnily. And then it would put the repositories files,
48:35 all the readme file, code of conduct, documentation, whatever, in a different path that you specify
48:41 if you're choosing. And then user local would contain just the kind of sim links and the installed
48:46 packages. And the nice thing about that is that user local, you may have seen the user local seller
48:52 directory. Now that's where all the binaries are actually stored. And then there's sim linked into
48:56 various different locations. The problem is, if we decided to move that, we would have to rebuild all our
49:01 binary packages for all of our OSX versions. And that's basically a massive pain that we don't
49:07 want to kind of have to go through. And so this kind of was this hack that like this person suggested,
49:13 I kind of tried out on my own machine for a few weeks, and it was completely flawless. Everything
49:17 just worked absolutely perfectly. And that allows us now, after the move, to have all our binary
49:24 packages be the same, still have all the kind of the compiler search paths and stuff like that be fine.
49:29 But now we can move stuff around in our repository on GitHub. You know, if we want to put a readme.md
49:34 file or contributing.md file or change those file names or whatever, they can all now live
49:39 inside user local homebrew instead. And we don't need to worry about kind of junking up people's
49:46 user local. Another final benefit from that is, so we always, we would tell people to take ownership of
49:53 user local and just recursively CHN that so you can always write anywhere in there. The problem is,
50:00 is Apple's OSX installers, various other tools would reset that. Yeah, every time. So every time there's
50:08 a new version of OSX that comes out, it would be that kind of reset process. And it was a massive
50:13 pain for a lot of people. So now what we do instead is we create the root level directories and user local,
50:18 get people to CHN them instead, which our installer does by default. And then you just have those root
50:24 level directories, which kind of stick there. And anything else can dump files and user local and
50:29 change the ownership of user local and, and all that good stuff. And that doesn't affect us anymore.
50:34 So again, that's another example of somewhere where it's massively cut down on a bunch of these issues
50:40 we would just see again and again on every error sex release. So yeah, it's been great. Or macOS.
50:46 You've actually been bit by that bug once before.
50:48 Yeah. Yeah. I've been bit by that one several times before. I forget that it happens and then
50:53 it happens and then everything explodes.
50:55 I just upgraded at 1.0 yesterday. And as part of the upgrade, because I, I upgraded to Sierra
51:00 last week and I just did the upgrade to homebrew 1.0 yesterday. And I had to change ownership
51:06 on a user local because homebrew had set it back to, was it root and wheel or something like that?
51:11 So yeah, I could see that happening to everybody.
51:13 Yeah, exactly. And then nicely. Now we, after the migration, we then tell people, okay,
51:17 you can actually now change this back. And then that's now the last time. So when
51:21 Sierra plus one, I'm still hoping for macOS Sea Lion to come out, but when that comes out or whatever,
51:28 uh, then yeah, hopefully these permission issues will just be gone for good at that point,
51:32 which will be lovely. That's funny. Uh, as we're talking through all this, the details, I'm, uh,
51:39 I'm just reflecting back on earlier in the show when you said that you, uh, that you do this homebrew
51:44 stuff, as you said in the times whenever like you're running a test suite and it takes five minutes
51:48 or something like that. Like, I'm just reflecting on all this detail and all this
51:51 complexity and all this community and all this, you know, how important homebrew is to so many
51:56 developers out there, how you and others do this in your spare time. And that's just crazy to me.
52:00 I mean, yeah. So, I mean, I'd say kind of here and there time, but yeah, I mean,
52:03 in the run up to 1.0, I'd sort of decided I want to ship it all in around about the Sierra release.
52:09 Um, so yeah, so in the two weeks before that, like I was just like doing pretty much every,
52:15 every evening and weekend, like pretty much all evening and weekend. Like I, I think there was,
52:21 we were getting to the point where my, uh, my dog and wife would have like not tolerated any further.
52:28 As we know, you're a dog lover too. We can hear your pups in the background there for
52:32 a second or two. So you got a little cameo on the show.
52:34 Yeah. Yeah. No, I, I do love my dog. She's pretty great. And she's in my
52:38 GitHub profile picture as well. So.
52:40 Well, cool. Let's, uh, let's pause there then when we come back, we got lots of,
52:43 lots of other things to talk about. Software Freedom Conservancy, uh, the new community site,
52:47 some of other things happening, uh, more community growth, and maybe even
52:50 more ways that the community can step in and support homebrew and, uh, ship their own formula
52:55 or formulae as they, as you might say, or have changed the way you say it.
52:58 So let's pause here. We'll be right back.
53:00 Linode is our cloud server of choice. Get up and running in seconds with your choice of
53:08 Linux distro resources and node location, SSD storage, 40 gigabit network, Intel E5 processors,
53:15 use the promo code change log, 20 grade, $20 credit, two months free. One of the fastest,
53:21 most efficient SSD cloud servers is what we're building our new CMS on. We love Linode. We think
53:27 you love them too. Again, use the code change log 20 for $20 credit. Head to linode.com/changelode to get started.
53:33 We're back with Mike McQuade talking about homebrew and, and Mike around homebrew, there's several,
53:44 uh, terminologies used. You got cast, you got tap, you got brew, you've got several things. You got
53:50 formula or formulae. I think that's changed if I'm correct. It's plural form. It's plural form. Okay.
53:56 Um, walk us through some of the terminology, you know, do you tap a cast? Do you tap a keg? What,
54:01 what is it? How does this work? Yeah. So I think the terminology is a bit sometimes tenuous in places
54:07 and it's not quite, um, all adding up, but a tap is effectively what we call it. A
54:14 a third party repository basically. So that, that was initially created. That was one of kind
54:18 of Max's last big features he worked on. And a tap basically allows anyone to be able to have
54:25 a git repository, which, well, it doesn't actually have to be a git repository anymore, but a directory
54:30 with a collection of formulae or homebrew extension commands that they can go and say to anyone, okay,
54:36 like here's this one command you can use to install a tap on your machine and then brew update will then
54:42 keep that up to date and brew install will then let you install from any of those taps as well.
54:47 So actually as part, a fun little fact is as when we split out homebrew into the two repositories,
54:54 the formulae became their own tap. So previously you had all the kind of central formulae and then you had
55:01 taps, but then now actually everywhere that contains formulae is always in some sort of tap.
55:06 It seems like that's a promotion of the tap idea because back when I first started using homebrew,
55:11 like using a third party, uh, repository for formulae was kind of like sketch. And you're like, well,
55:17 if you really have to do this, but now it seems like that's very commonplace. Is that a fair characterization?
55:24 Yeah, definitely. I think there's a recognition in that that a, that people are going to want to do
55:29 stuff that we, you know, we don't have the, you know, if you work at a company, you may well want
55:34 to have internal tools, which are installed, um, by homebrew through a tap. But also there's,
55:39 it's helped us with some of the really long tail stuff because now we can say to people if, you know,
55:45 if you're the only person interested in this, then you can just create your own tap and you can keep
55:49 that up to date. And then if more and more people, particularly now we have analytics for some of
55:53 this stuff, um, if more and more people use that, then we can consider kind of bringing that into
55:58 homebrew itself. And before that we couldn't, not that kind of private taps are revealed by analytics.
56:04 We're careful to not do that. But within, within the homebrew organization, we have several kind of
56:08 taps and for different things. And it lets us as well kind of subdivide maintainers based on
56:13 things that are interested in. So we have a science tap, a PHP tap, a Python tap.
56:18 And, and those are not, you know, to install Python, you don't have to tap Python tap,
56:23 but it provides some sort of stuff, which is deeper into that ecosystem and stuff which we
56:27 wouldn't include in our main repository and can kind of find a home in some of these taps instead.
56:32 And these taps can be run independently and a little bit looser on some of the
56:36 restrictions that we kind of have to have to kind of keep the core working effectively.
56:40 Tell us about cask. What's cask?
56:43 Yeah. So that was quite exciting. So brew cask was originally a thing made, I can't remember what
56:48 year it was originally, but someone basically really liked homebrew, but they hated the fact
56:53 that, you know, when you install Mac applications, you know, you have to download the zip or the package
56:57 file, the Mg or whatever, and move the file there. And it's, you know, it's almost always the
57:03 same process every time. And it's like, and I think they were just like, well, why do I have to,
57:08 why can't I install my command line software beautifully? But then I had to like physically
57:12 drag and drop a thing with my mouse and to, that's the, that's the sound I make when I do it.
57:17 Exactly. I actually quite like drag and drop. I kind of missed that a little bit in some ways,
57:23 like the little dragging the icon into the applications folder and it's all nice and pretty.
57:27 You can still do it, Mike. No one's stopping you, man. You can still do it.
57:31 Yeah. My, my, my obsessive desire to script everything is stopping me, unfortunately.
57:37 But yeah, so like they made this brew cask command so that you could do that. You could
57:42 do brew cask install and, you know, Google Chrome, whatever. And, and we had a summer code student
57:49 this summer, Anastasia, who is a very, very smart Russian student who worked on basically
57:57 trying to unify the two projects. So homebrew cask, they originally were kind of almost extension,
58:03 I think in just a tap. And we kept, because we didn't provide any sort of official API
58:08 for them, they kept, ended up being broken by our changes. So in the end, they ended up vendoring
58:14 a lot of homebrew code, homebrew's code. So in Google's summer of code this summer,
58:18 the student worked on basically de-vendoring all this stuff so that they could kind of,
58:24 we could share a lot more code between the two projects and de-duplicating between the two projects.
58:29 So we kind of stuff which didn't make sense to have in both, wasn't in both. And both in terms
58:34 of like source codes, but also in terms of things that are installed when they both installed identical
58:40 software that there wasn't a need to have them both. And then finally, actually moving all of
58:45 homebrew cask's kind of package manager codes into the homebrew package manager itself.
58:49 And so now we have homebrew cask living within homebrew itself. So when you run brew cask,
58:56 now that's part of the homebrew package manager and part of the homebrew's release process and stuff
59:00 like that. And we're able to do stuff like share a lot more code, share maintainers, share testing,
59:06 and that kind of provides some guarantee as well that we're never going to break homebrew cask stuff
59:10 because our package manager tests are now running all of homebrew cask's tests as well.
59:15 I just did a brew cask list on my machine. And it turns out, even though I don't know what cask is,
59:20 I have used it to install Screen Hero. So I believe someone said, "Yeah, just type this." And I thought,
59:25 "Oh, that's really cool. You just type brew cask install Screen Hero," or whatever the application
59:30 is and magic happens. And then you forget that you did it and all is well.
59:34 So, and the cool thing that comes on top of a brew tap and brew cask as well is, which not many people
59:41 know about, and I think partly because I've not done a good job of describing it, is the thing brew bundle.
59:46 So that lets you have a brew file, kind of like a gem file or whatever, in which you specify
59:52 a list of homebrew packages, cask packages, and actually like taps and eventually even like Mac App Store
59:59 packages as well. And then it will automatically, you can run brew bundle and it will go through
1:00:04 that list and install any of the ones that aren't installed. And you can also do the reverse,
1:00:08 where you can kind of dump to a file and then add that as kind of almost like a backup of everything
1:00:14 you've got installed and all the options they're installed with and stuff like that.
1:00:17 So that's been really useful for letting people kind of almost import and export their configuration,
1:00:22 but also for having like a system-wide installation. So you can have one script,
1:00:27 which then installs all of your software. But then we've been leaning on that heavily inside of
1:00:31 GitHub as well. And to have that per project, so you can specify a definition of this project requires
1:00:38 MySQL and Nginx and stuff like that. And there hasn't really been a good way before that of kind
1:00:43 of defining that. Like often that's just in the documentation, but we can actually have now in
1:00:48 the brew file. So we'll install the correct version of MySQL and then start up a daemon in the background
1:00:54 on the system if it's not already running. And then that'd be a no-op if that stuff is already
1:00:58 installed in the daemon's already running. And that brew file is really handy for
1:01:02 descriptors. I've seen that actually, I think in maybe earlier versions of ThoughtBot's laptop
1:01:09 project where they're doing lots of interesting things around. They actually used to support Linux
1:01:13 and Mac and now it's just Mac, but it's kind of like their way of setting up a development machine.
1:01:20 And I'm pretty sure I recall seeing a brew file in that, and that's kind of where I actually
1:01:24 stumbled upon that and thought that's kind of interesting to see. Like, here's a way you can
1:01:28 like just run a lot of brew commands basically.
1:01:31 Yeah. Yeah, exactly. So it's pretty neat for that. And again, being able to standardize on these
1:01:36 things, I self-plug have like a little project called Strap that we, again, use inside of GitHub
1:01:43 that is kind of a, you know, system bootstrap type thing. And that rather than, it's a different
1:01:49 approach to ThoughtBot laptop because it's not opinionated at all about what stuff should be
1:01:53 installed. So if you have a brew file in your .files directory, it will check out your .files directory
1:01:58 and run the brew file in there. So every person can have their own almost custom system bootstrap
1:02:04 script from that perspective and still yet have like a sort of centralized way of running that for
1:02:09 everyone. So it's been quite neat. But yeah, my long-term dream, if I ever get around to it,
1:02:14 which I probably never will, is to try and work with a few other people and see if we can get some
1:02:19 sort of brew file definition format, which a bunch of package managers support so that we can have a
1:02:26 way of you can declare in a project that, okay, I want to install my, this project needs my SQL installed,
1:02:33 lib.xml2, whatever, like the kind of native package manager dependencies. And that file can then be
1:02:39 read by, you know, whether you're on Fedora or NuGet on Windows, maybe even, or Homebrew or Mac ports
1:02:46 and have a single file which could be used kind of as shared metadata across all these package managers.
1:02:51 That's kind of a little dream of mine that may or may not happen one day.
1:02:54 That would be cool. I think RVM had a similar dream. Isn't that right, Adam? For RVM3, I'm not sure
1:03:00 if you ever got there, but it was kind of like beyond Ruby versioning. It was like versioning for
1:03:05 everything. You could just list all your, you know, this requires Postgres, this requires Redis, for
1:03:11 instance. But definitely a dream to get everybody involved because that's a lot of different software
1:03:17 projects that would need to come on board. And if I couldn't call it brew file, it would have to be
1:03:21 like package file. Oh yeah, yeah. Yeah, obviously. Yeah. I'll submit the term, you should call it
1:03:26 dependencies. Yeah. Yeah. That seems fine. People tend to like that one. Might have to have some
1:03:34 slight pun on the name just because I'm British and that's, you know, that's what happens to us.
1:03:39 Tell us about keg. So kegs are when, so that's one of the hardest metaphors in that even the homebrew
1:03:49 maintainers probably disagree on what a keg actually is. But a keg is technically, that's the directory
1:03:57 when you install homebrew a package in it. The directory is used as the prefix. So this is going to get a bit
1:04:05 package manager, naval gazey. But the way most package managers work is they have a unified prefix. And what
1:04:11 I mean by that is when you run configure or make install or whatever, say on two pieces of software,
1:04:18 the prefix you set is say user local. And then what it does is it chucks binaries and user local bin,
1:04:25 it chucks libraries and user local lib, etc. And that's the general way most package managers work.
1:04:31 What homebrew does, which was actually aped off by Max's own admission off another package manager,
1:04:37 whose name escapes me off the top of my head at the moment. But basically having every single
1:04:41 package be in its own prefix by package and by version. So if you go into user local seller,
1:04:48 you'll see you have user local seller and then the names of all your packages. So user local seller,
1:04:52 and then a subdirectory called wget and then a subdirectory of whatever version of wget is installed.
1:04:57 And then within that, then you have bin, lib, all these other directories. And then what homebrew does
1:05:03 is we then symlink the contents of those subdirectories back into user local bin. So in user local bin wget,
1:05:10 that's not actually the wget binary. That's a symlink to user local seller wget version bin wget.
1:05:18 And basically the benefit for that is it lets you stop software from stomping on each other. So you can
1:05:26 have software installed side by side, which installs conflicting things, but they just both can't be
1:05:32 linked at the same time, rather than being like, "Okay, we actually just can't install these two
1:05:38 things in the package manager at the same time."
1:05:39 I might actually suggest after this that, uh, that there actually be some sort of like glossary
1:05:44 for homebrew because you'll have so many terms and I, I'd forgotten about seller and we actually
1:05:50 asked about keg as a joke because I, I didn't think it was a real thing. I was hoping you'd laugh,
1:05:54 but it's actually real. And so our next one is like, tell us about pints, but yeah, pints are not real.
1:06:01 Well, I mean, they are real, but not in homebrews.
1:06:03 Yeah. Yeah. Um, so yeah, no, I mean, we definitely could do with having a glossary. I mean, my...
1:06:09 I mean, if anything, it could be an attractor to contributors because it's funny. It's just
1:06:14 a new way to like talk about your project and just have fun with what it is, you know?
1:06:19 Yeah, exactly. I mean, so my, the reason why I, I, I didn't do that originally is my whole thing
1:06:26 was I wanted to rename everything. So we wouldn't call kegs kegs anymore. We wouldn't
1:06:30 be careful now.
1:06:31 Why? Exactly. Exactly. And, and that was an example.
1:06:34 You were concerned about the, uh, you know, the analytics people getting you.
1:06:37 This is the real reason he wanted to be lead maintainer. So he could rename all of the,
1:06:41 would you just, would you come up with a brand new analogy or would you just remove all analogies?
1:06:46 I mean, I think, yeah, we just call things packages. If there's an established name already,
1:06:51 call them that packages, prefix, whatever. But I mean, I think the argument, which I,
1:06:56 I probably mostly agree with at this point that pretty much every other person in the world
1:07:00 said is that, okay, you might make things slightly easier for new users. But at this
1:07:04 point, homebrew is at the point where you're probably going to confuse a lot of people who've
1:07:08 learned the existing terminology more than you're going to help, you know, a new user at a code
1:07:13 academy or whatever, understand this stuff. And yeah. And as you say, probably the best middle ground
1:07:18 is just have a glossary and just define these things.
1:07:20 I guess it depends though on this change stuff. Now, you know, the, the naysayer me says don't do that, but I think if, uh,
1:07:28 if the plan was wider adoption and, uh, a greater invitation and if the normalizing of the puns, while we all love puns and just the play on words
1:07:39 kind of gets played out, so to speak, if it was, if reducing that helped invite people and actually contributed to a greater project,
1:07:47 that might be for it, but it would hurt along the way. I'd cry a little bit.
1:07:51 Yeah. Yeah. No, 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.
1:08:16 Adam sounds like he's for it. I'm against it. So there you go. You split us down the middle.
1:08:20 I'm not exactly for it.
1:08:22 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 out of it, like, would you say boneyard or graveyard or something?
1:08:42 Like, some things just don't match. Then you get mad because 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.
1:08:54 Yeah. Yeah. And I think that's, you know, I redesigned the website for, with the help from an Australian designer, Danielle, whose full name is actually on the website. But yeah. So I think that was part of what I was going for a little bit with the redesign as well.
1:09:09 Cause 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.
1:09:16 And like, it's, I feel like that, I love them when 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.
1:09:34 And in our prose guidelines, we favor British English just because, you know, Max was British.
1:09:40 I was, 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.
1:09:46 You know, I'm one of those people when I worked with a cute back then as well, when you define colors, that was a cute color.
1:09:55 And I would regularly name my cute colors, variables, color with a C-O-L-O-U-R, just because, you know, because I'm a crotchety British person.
1:10:05 And I find it funny to do those type of things.
1:10:08 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.
1:10:18 We're not a company.
1:10:19 We're not a serious business.
1:10:20 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.
1:10:30 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.
1:10:38 We're getting a little bit low on time here, but let's talk about the social side of things in 1.0.
1:10:42 And you have two, what I would call kind of social announcements or things that have happened, at least in light of 1.0.
1:10:47 And one is the joining of the software Freedom Conservancy.
1:10:50 And the other is a setting up of the community discourse.
1:10:54 I'm not sure exactly when those things happen, but let's start with the software Freedom Conservancy.
1:11:00 Homebrew has joined that.
1:11:01 What does that mean for the project?
1:11:03 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.
1:11:09 But when your project has like no possession, effectively, then there's not really a need as much for a thing like software Freedom Conservancy.
1:11:18 The problem is when you have, we had a Kickstarter a few years ago, which was really great.
1:11:22 Let us buy some Mac minis, which we use for our CI.
1:11:25 And as I get older, thankfully not that old, and I'm a bit of a paranoid person anyway.
1:11:31 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.
1:11:38 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.
1:11:45 What happens if I get hit by a car to those servers?
1:11:48 What happens when they go down?
1:11:50 What happens to the money in that bank account?
1:11:52 And I just, you know, that stuff gets a little bit more worrying.
1:11:57 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.
1:12:06 And it also means that if I ever did want to or have to step away from the project, then the unwrangling of me from the project would be a lot more difficult.
1:12:15 And what the Software Freedom Conservancy provides is a legal entity to own these things and a legal entity to, if hope we ever got sued for whatever reason, then the Software Freedom Conservancy would defend us.
1:12:29 And also on top of that as well, they are a 501c3 or for non-Americans, a non-profit in the US, which makes it a lot easier to accept donations, basically, which are tax deductible for individuals and corporations to provide.
1:12:46 So that is not something we've not managed to do a massive amount of fundraising yet.
1:12:50 That's probably my next big project to try and lean in on that a bit more because our recurring monthly revenue is zero.
1:12:57 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.
1:13:10 I'm surprised to see or to hear that it's zero, like there's no contributions, there's no donations.
1:13:16 I mean, we're running low on time, so this is harder to kind of like tap into to keep using our terms.
1:13:23 But it just surprises me that Homebrew is used by so many and depended upon by so many.
1:13:30 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,
1:13:37 but not as often on Windows, although it's becoming more and more popular with Ubuntu's announcement of Bash and Microsoft and all that good stuff.
1:13:46 But I'm just surprised. Wow.
1:13:48 Yeah, yeah. So, I mean, part of that, you know, we're coming to personal beliefs and stuff.
1:13:54 But, you know, my whole thing is 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.
1:14:04 So it restricts the stuff we can do. There's certain things that it's like, you know, I would love to just be able to spin up an AWS instance to run that, but we don't have the money.
1:14:12 So we can't afford to do that.
1:14:14 And yeah, it is a bit of a pain and it's not hit us that adversely yet.
1:14:20 But as I say, on the flip side, we've not ever really, beyond the Kickstarter, tried to do decent fundraising for that.
1:14:27 And that's something I do want to, you know, personally do in future.
1:14:30 Well, that's somewhere we can help you play a role a little bit.
1:14:34 I mean, I know that Jared and I, we both have some passions around that.
1:14:38 And, you know, we can always talk to you outside of this, the context of the show to help you on that front, to give us some ideas, you know, collaborate in that front a little bit.
1:14:47 And that's something I think we have some future ideas around, nothing that's exactly solid, but definitely some passion.
1:14:53 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, you know, community related or growth related or, you know, outreach or anything, anything whatsoever.
1:15:12 You can't sponsor one of the maintainers going to a talk because you just have, you know, you have no funds to doing that stuff.
1:15:19 It's, it's very limiting.
1:15:20 And I think that there's so many people out there using it.
1:15:23 There's got to be some way you can bring in at least a buck a user and that'd be a lot.
1:15:27 And I mean, yeah, well, let's cover real quick, even though we're real short on time.
1:15:31 So give us the, uh, the information on the community discourse site and the purpose and the setting up for that.
1:15:37 So that's something we shipped, I think on the same day as 1.0.
1:15:42 And it's basically just another way of communicating on homebrew is something that the mailing list, we've got a mailing list, we've got an IRC channel, we've got the issue tracker and like none of them are quite, you know, they all feel slightly formal in their own ways.
1:15:56 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.
1:16:10 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.
1:16:18 And a bit more of a kind of discussion and stuff like that.
1:16:20 And yeah, no, it's been good.
1:16:22 One more thing I, I heard you mention earlier, but I'm just curious what the tie-in is together.
1:16:27 Cause I see in the footer, it's, uh, it's Linux brew is maintained by Linux brew, but earlier you mentioned Linux brew.
1:16:32 Yeah.
1:16:33 It also says as the homebrew package manager for Linux, is there an affiliation there?
1:16:37 Is there, I know one of the maintainers crosses over at least it was, what's the relationship there?
1:16:41 Just curious in closing.
1:16:43 So I think, uh, originally Linux brew was like just a fork.
1:16:47 Um, and then we, we kind of created that and they, they just kind of had a bunch of patches on top of homebrew.
1:16:54 Um, but then with 1.0, like we have a kind of what I call a generic backend, which is a backend that doesn't assume anything OSX or Linux centric and kind of, kind of run the tests and run and install on, on Linux and Mac.
1:17:10 Um, so now that we have that backend, we're trying to do more porting to try and get things into, um, from Linux brew's, uh, brew kind of package manager fork into homebrew itself.
1:17:22 And then hopefully maybe a 1.1 or whatever, we'll have a point where Linux brew brew, um, can go away entirely.
1:17:29 And we can run that entirely off homebrew's brew and we can have a unified package manager that works on, um, on OSX and on Linux.
1:17:37 Nice.
1:17:38 Good stuff.
1:17:39 Is there anything we missed in this condo?
1:17:41 Jared and I had a quite of a list to talk through pretty much just based around your 1.0 announcement, but is there anything we missed that you want to make sure we talked about?
1:17:47 Uh, I don't think so.
1:17:48 I think that that was kind of everything I wanted to talk about.
1:17:51 Um, and I, I looked at your little notes about the common questions at the end of the show.
1:17:56 I'm not sure if we were doing them or not, but I think we've touched on all of, almost all of them anyway.
1:18:00 So 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.
1:18:08 You know, so it, and there's lots of listeners of this show, uh, from all walks of open source, all walks of developer life.
1:18:14 Um, 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?
1:18:22 Yeah, that's a great question.
1:18:24 I think basically just getting involved at all is great.
1:18:27 We have a thing in our homebrew brew readme 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, um, of our kind of style.
1:18:40 And that's a great way to get started and get kind of familiar with our workflow.
1:18:43 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.
1:18:49 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.
1:19:00 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.
1:19:17 Because that's the way we're going to grow this community.
1:19:19 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 don't want to work on open source.
1:19:28 And that hurts us all, really.
1:19:30 I mean, it's kind of like a universal mini-so or mini-so.
1:19:34 What is it, Jared, for Matt's is nice, we are nice.
1:19:37 It can almost be like maintain, our maintainers are nice, we are nice kind of thing.
1:19:41 You know, it's just universal.
1:19:42 Mini-swan, that's what it is.
1:19:44 No, I like that.
1:19:45 That's nice.
1:19:46 I mean, I think that every, you know, sure, everyone says they're nice and it's a variation of nice, but, you know, maybe they're not nice.
1:19:55 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.
1:20:00 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 there's no reason not to be nice back.
1:20:16 Well, we do try to be.
1:20:18 And I think that the thing I think that's important to remember is people, again, when you're saying everyone kind of thinks they're nice, is you're as nice as the way you treat the person you're angriest with, the person you're most disgusted with, whatever.
1:20:33 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.
1:20:41 Like, that, your behavior in that situation is what, like, we're asking you as, like, open source people and equally myself as well.
1:20:50 I've got as much to learn from this as anyone does.
1:20:52 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.
1:21:01 That is true.
1:21:02 That'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.
1:21:11 That's totally true.
1:21:12 So, 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.
1:21:18 I don't know, Mike, if you subscribe to it or not, but every week on Saturday.
1:21:22 And, Jared, now it seems like Sundays because Sundays have kind of been a better day for us.
1:21:26 We've just had such business going on between the news site going out, three shows, lots of stuff happening around the business front.
1:21:33 I've been changing our verbiage to every weekend.
1:21:35 Every weekend, yeah.
1:21:37 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.
1:21:43 But in that email, the most recent one, issue 124, we mentioned Hobrew 1.0.0 and many other awesome things.
1:21:52 So if you're not subscribed to that, go to changelog.com slash weekly.
1:21:56 Subscribe.
1:21:57 All we ask for is your email.
1:21:58 But if you put your name in there, we greet you nicely in the email.
1:22:01 So the name is optional, so don't feel like you have to.
1:22:04 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.
1:22:19 So a lot of stuff around software development.
1:22:21 So if you don't subscribe to that, you know, Jared, what have we got?
1:22:25 Sad faces or happy faces?
1:22:27 Emoji sad face.
1:22:29 Emoji sad face.
1:22:30 Mike, so do you subscribe to this?
1:22:31 Just curious.
1:22:32 Yeah, I do.
1:22:33 As of three seconds ago.
1:22:36 What's your favorite issue?
1:22:38 That's all we ask.
1:22:39 That's all we ask.
1:22:40 Just because you just subscribed.
1:22:41 My favorite issue is the next one.
1:22:43 125.
1:22:44 Nice.
1:22:45 You're going to love it.
1:22:46 You're going to love it.
1:22:47 Now we get a lot of pressure on us to please Mike, which is hard.
1:22:51 I don't want to see an unsubscribe on Sunday.
1:22:53 I'm going to be, I'm going to email you.
1:22:55 I'm going to email you nasty things.
1:22:56 That's right.
1:22:57 Yes.
1:22:58 That's the way we do it.
1:22:59 but that's what I want to mention in closing,
1:23:01 just because we mentioned a homebrews 1.0 announcement recently in that
1:23:05 a great place to,
1:23:06 to mention that.
1:23:07 And if you listen to the show and you don't subscribe to that email,
1:23:09 it's just,
1:23:10 you're just missing out.
1:23:11 That's all I can say.
1:23:12 So do that now,
1:23:13 take our direction.
1:23:14 And that's it for the show,
1:23:16 fellas.
1:23:17 So let's say goodbye.
1:23:18 Bye.
1:23:29 Bye.