The Changelog: Software Development, Open Source - Homebrew! Part Deux (Interview)

Episode Date: March 6, 2019

We're talking with Mike McQuaid about Homebew 2.0.0, supporting Linux and Windows 10, the backstory and details surrounding the security issue they had in 2018, their new governance model, Mike’s new role, the core team meeting in-person at FOSDEM this year, and what’s coming next for Homebrew.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by DigitalOcean. DigitalOcean is the simplest cloud platform for developers and teams

with products like Droplets, Sp droplets spaces kubernetes load balancers block storage and pre-built one-click apps you can deploy manage and scale cloud applications faster and more efficiently on digital ocean whether you're running one virtual machine or 10 000 digital ocean makes managing your infrastructure way too easy get started for free with a hundred dollar credit head to do.co100 credit. Head to do.co slash changelog. Again, do.co slash changelog. All right, welcome back, everyone. This is the changelog, a podcast featuring the hackers, the leaders, and the innovators of software development.

I'm Alex Dekowiak, Editor-in-Chief here at Changelog. Mike McQuaid is back talking about Homebrew 2, supporting Linux and Windows 10, the backstory and details surrounding the security issue they faced last year in 2018, their new governance model, Mike's new role, the core team meeting in person at FOSDEM this year, and what's coming next for Homebrew. Mike, we're back again, man, and it's been a while, right? Yeah, yeah, it's been a few years, right? Time flies. You got Homebrew 2 out, you got some new governance stuff happening. We actually almost caught up with you, I think, July of last year around the security thing. So there's lots to cover, but where do you think we should begin?

Should we begin with the security thing or should we begin with the latest updates to Homebrew? Yeah, let's start on the downer and then finish with the upper. Gotcha. Let's go there then. So we actually wanted to kind of news hack it, but just didn't work out to get both you and the security researcher on the show. But you're here instead. So tell us what happened. Yeah. So basically we got a security disclosure through our HackerOne. It's actually been a really nice setup since we kind of moved to that. Previously, we had just, you know, oh, we'll create an issue or send us an email or whatever.

And people suggest that we kind of get set up on HackerOne and it's kind of a responsible disclosure platform thing and it's free for open source. And that's kind of worked pretty well for us. So yeah, basically late July last year, a researcher identified that Jenkins, which is what we've used for Homebrew CI and building our binary packages, had been leaking a token. Unfortunately, that token actually gave him push access to some repos. So that was obviously relatively terrifying. We managed to, obviously, the bonuses of good disclosure is that within a few hours, we were able to revoke the creds.

We were able to replace them and sanitize anything in Jenkins, so this shouldn't happen in future. And also basically check to see with the old credentials what was possible and what wasn't. And thankfully, it actually wasn't as bad as initially feared because although it has to have kind of write access, that particular credential, it didn't have actual like push access to the given repos.

And we were also able to verify with GitHub's support help and some auditing ourselves that it hadn't been used by anyone during the period in which the scopes were elevated in which it had write access. So basically one of those ones were you know scary times but thankfully kind of all resolved so we kind of wrote it all up on our blog uh tried to let people know what happened what the implications were and like what we were going to do moving forward and try to move on since then and haven't had any other big slip up similarly since then which has been good the fellow's name was Eric Holmes, right?

That's the one, yeah. That's the one. We linked this up around the time of happening to ChangeLog News. And the last question I think is kind of interesting, and I'm kind of curious what you think about this. He says, if I can gain access to Commit in 30 minutes, what could a nation state with dedicated resources

achieve against a team of 17 volunteers? Yeah, I mean, it's a great question, to be honest. And, you know, I don't mean to scare people with this stuff. But I mean, I'm very much of the belief that unless you are a very high level security professional who has deep knowledge in this stuff, if you're going against a nation state, like it's more or less, you know, as they say, game over, man. I'm yeah, it's that side of things it's is scary yeah but i think the thing with homebrew at least is that it has been designed such that um and we kind of said this even at the time when we were kind of debating it as maintainers is that with stuff like this you can there is vulnerabilities which can be introduced silently and then you'd never really notice them and never really catch them and then there's vulnerabilities that you would notice and because

we have everything built on top of git and because our cdn is immutable after 30 days and because we have like i guess a two-level kind of hashing structure even with our binary packages where we maintain the hashes for those packages and the packages are maintained elsewhere on separate infrastructure. It means that the chances of someone like a nation state being able to compromise homebrew, I'm not basically, if you have one of the relatively big superpowers trying to do something like that, the chance that they could compromise homebrew, I feel it would be relatively high if they put their mind to it. But the chance that they could compromise homebrew i feel it would be relatively high if they put their mind to it but the chance that they could do so without

any maintainers or the community noticing that's something i'm not convinced about and i feel like we would notice and we would be able to kind of spot that that had happened and disclose that information and stuff like that because i guess the other flip side of the open source community with stuff like this is because we don't have you know a relationship as volunteers with the government of countries that may want to do things like this we would not have any qualms in going posting on our blog and pointing fingers at directly whom we believe has done something and when they did it and why we think they did it and all that type of thing and i guess companies sometimes have a little bit more conflict there because obviously there's commercial interests involved and blah, blah, blah.

It's an interesting thought experiment. And you just kind of wonder, you know, with open source software, it's the gift and the curse, right? On the gift side, well, there's a lot more eyes on it. The code is there. You know, we use modern SCMs. And so, like you said, any sort of things going into the software coming out, they're all in version control. They're all publicly there. There's lots of them.

There's 17 maintainers. And there's your GIF. But the curse is that it's all open source, right? And so, as a bad actor, there's a whole lot less poking at a black box that you have to do because you aren't dealing with the final product. You're dealing with the source code, depending on what the project is. And so it's just one of these things where, yeah, I mean, he got it done in 30 minutes. That was really the thing that I think made this particular incident just more interesting than other ones is because it was like, wow, he set out to do it and 30 minutes later he

had it. And that's not much effort, right? Yeah. And I think the interesting thing from our perspective is that others may well draw different conclusions but our perspective would probably be that it was an example of our weakness being exploited which is that i guess like other open source projects most of us would rather be writing code than doing system administration so as a result like we have a Jenkins instance. And I mean, shout out to anyone working on Jenkins here.

It's great software that we've used for a very long time. But compared to what we're increasingly used to with, say, Travis CI and Azure Pipelines, which is what we use now, and a lot of these cloud tools where effectively keeping everything up to date and keeping the configuration sane is not something you need to worry about yourself. Whereas any of these open source projects where you're installing the software yourself, you're maintaining it on that system. Getting the balance right between applying all the security updates in Jenkins and then all the plugins, which then change behavior between versions.

So this was one of these annoying cases where it was an intersection between plugins where one plugin which had previously filtered out the tokens was updated and then that responsibility was delegated to another plugin which hadn't been configured to do it correctly and all this type of thing. And it's kind of tricky because it slips through the cracks. And our longer term solution that we're kind of working towards now is basically just get rid of any infrastructure we have to maintain ourselves. mean in an ideal world we would all be on you know travis and ec2 and azure pipelines and that would be the end of the day but unfortunately again the the complexity of our project is that we have to build binary packages on mac os and there is not a freely available mac os hosting platform for building stuff at the scale that we

need yet we're getting optimistic that there will be in future we've had some really good conversations with microsoft um about azure pipelines but right now as of today you know we still need to maintain our infrastructure which is in this case you know the configuration of that infrastructure is the weak point. So that's my number one goal on my list of stuff to do this year is to get us entirely onto other people's infrastructure for this stuff. But again, I guess like,

it's one of those ones where I will do it by the end of the year. I'm fairly confident, but I can't really be bothered. And one of the tricky ones in Homebrew where if I don't do it, chances are pretty low that anyone else is going to step up and do this work. But, you know.

In a more general sense, taking Homebrew specifically off the table and just thinking about open source security. The trouble is, and we say it a lot on the show, and by no means, a lot of people say that it's true, but it's like from the security standpoint, you have to bet a thousand, pretty much. Let me say it this way, you only have to mess up one thing in order to have a threat vector. Then that thing has to just be found.

It's easier to find one hole in an armor than it is to make an armor that's completely indestructible, has no holes. And for open source, like you said, we'd rather be writing code than doing infrastructure. It also can be not your area of expertise. And maybe you're good at this thing, which made Homebrew successful. Maybe you're not so good at that thing.

Maybe somebody else has more experience. But even with the experience, people, mistakes are made. So for example, we've been cutting over some of our infrastructure here at Change.com, and all of our source code is open source. And we're on concourse ci and we're switching over circle ci i won't tell all the details of of that experience but i'll just tell you that we've rotated all of our keys right lately because mistakes you know are made yep and it's just kind of the unfortunate state of the world but the question becomes like on the large

you know how do we how do we engage in a battle as a community against bad actors, whether it's nation states or security researchers? What do we do that's sustainable? I know we've been working on lots of tooling, building and auditing into our package managers, for instance, that kind of thing. But do you put any thought into this

beyond homebrews uh yard of like yeah i mean i i think so i think there's been a few things through homebrew that i've kind of learned that i think are more widely applicable i guess the first one is back to this you know the security disclosure on our blog um and on tackle one and kind of working with the researcher to kind of have him publish his results i mean of course you know one of the first things you try and learn when you're getting more senior as an engineer is you know you are not your code and if your code has problems that doesn't mean you your worth as an individual goes down but you know but the first thing when you get a vulnerability like this is you want to you want it to not be true and you want you know despite everything that you know

and believe about responsible disclosure you just want to hide the problem and have it go away, you know? It's like an ego thing. And again, I don't think there's anything wrong with people admitting that that's, you know, it's a pretty natural reaction for you to have, you know, if you met. Yeah, shameful. You don't want that to be the case. Yeah, exactly. But I think, again, like that's one of the big things I think the open source community in general is good at, is stepping up and being

responsible and disclosing this stuff. Because in this case, the level of this vulnerability here, I'm sure that happened to a hundred companies around the world this year, almost an identical problem. And are they going to write on their company blog that they disclosed this? Well, some companies will and hat tip to them to them but most won't and that's that's a problem yeah i guess the other thing is that kind of somewhat ties on to what you were saying earlier is that you know you need to just accept with some of the stuff that you're not going to have the time and the resources for the open source projects that you would like to um you know again if homeroom was a commercial company company, I wouldn't hire me to do half the stuff that I'm doing

because I'm not qualified. And I know there's better people to do that. And even on the coding end, if me at work was to review my code quality that I have on Homebrew, then I would probably be leaving lots of requested changes all over the place because at the end of the day, i don't have the time and the resources to do things to as high a standard in open source always as i do when you know when when we're getting issues that are

affecting you know whatever like millions of people potentially the onus is on fixing it right now and when you don't have lots of very smart co-workers around you who can help bounce ideas off and it's just down to you then it's like well you're not going to do it as well and i guess the final thing i thought which again was a side effect in this case but um is sometimes you can avoid some security issues by just not having all your eggs in one basket like it's for example if github we have our binary packages hosted on bintray um and we also download source packages from the original like sources that they you know whatever the hosting company is for the original software um and it would have been and was tempting in the earlier days to say right

let's just double down on github use all of their hosting options and everything like that and if we'd done that in this case then that's when you lose one token and all of a sudden they have the keys to everything in your castle whereas in this case you know they you know even if you got into jenkins you wouldn't have access to publish binary packages you wouldn't have access to push to various repos like you know things are separated between individuals and then there's actually even between individuals within the project, you would have to compromise a handful of specific maintainers

to be able to get access to everything because most maintainers are not granted access that they don't need. I guess that would be a security thing that we've done for a while, which I guess I would encourage other open source projects to do, is that it's tough,

but when someone doesn't need, if you've got someone in your project who maybe was a big figurehead in the early days or whatever and they haven't worked on the project for several years they should not have access to push to your repositories in my opinion yeah and it it really stings again both sides to go and have to have that conversation about like maybe you don't need the access here but again i feel like that's the kind of responsibility side of things where if you're not willing to revoke people's tokens, then you're increasing the number of laptops that need to be increasing or decreasing, one or the other.

Basically, you have a bunch of laptops in the wild. If someone steals that and it's not encrypted, then you are giving people access to push to those repos. And again, it depends on your release model and your verification model and things like that, like how big a deal that would be. But certainly for some projects, that would be a big deal. Well, the good thing about this security incident, though,

is it was a best case scenario, right? It was a security researcher. White hat hacker. Yeah, exactly. And you were able to, even though it was shameful, you were able to disclose it quite well because in the end, no packages were compromised and no actions actually required by the incident. So it was a researcher and not a bad actor. Yep, exactly.

That's at least one, whew, you know, wipe the brow because it could have been bad. I think that's a nice thing with the open source community in general as well is that we, you know, if you go out your way to do things properly on the security side then you generally you know even the kind of gray hats in the middle are not going to get a lot of kudos from going and really making idiots of an open source project who are trying to do the right thing with this stuff you know whereas all of a sudden they've this is a case where again get the ego involved and all of a sudden if we try and make out to the security researcher that he made a mistake and we changed things from underneath him and he writes a blog post and we get into a he said, she said type thing on Twitter

about calling each other names, then all of a sudden that's when you can see potentially in future security researchers being like, well, these folks at Homebrew think they're so great, we're going to take them down a peg or two so i think you know there's a certain amount of humility that needs to be involved there when you're dealing with people who know a lot more about a subject area in this case you know security than you do you know and being kind of grateful that those people are willing to kind of go the right way and and help you out there rather than try and you know make fools of you did you end up having like a personal conversation with this person or did you end up just like black and white email, texting?

Like what was the kind of crossover there? Yeah, no, it was just through, so we just chatted with them through HackerOne, through our kind of security disclosure tool. And that's kind of the main way we had the conversation there. And I think it maybe went to kind of our personal emails kind of chatting there as well because we wanted to kind of security disclosure tool um and that's kind of the main way we have the conversation there and i think it maybe went to kind of our personal emails kind of chatting there as well because we wanted to kind of coordinate the blog posts and all that type of thing so uh the other fun i guess aside with open source as well is that like this this all happened during uh my um paternity leave github is very generous in that you get five months paid paternity leave and so i was off and my wife had gone back to work and i was with my off with my first and uh i was his kind of sole care provider at that time for a three-month period and yeah and

this happened more or less slap bang in the middle of it so like i put him down for a nap and was like frantically trying to sort of write this stuff up stuff up and sort those things out and being like, please, please, wee man, just stay asleep. That's funny. But yeah, and I guess that's again... Congrats, by the way. That's terrible, though. Yeah, thank you very much.

Congrats, that's terrible. Congrats on the kid, of course, and that's terrible to have to deal with that during paternity leave. Well, the question is, did he stay asleep the whole time? Yeah, I mean, he's a good sleep sleeper we've been very lucky on that front but yeah but like um yeah it's it's kind of again it's it's nice because the security researcher i feel like with the kind of delays around the blog post and stuff like that um you

know we didn't publish the blog post quite as quickly as we would have liked to because of stuff like this and I feel like he was fairly understanding when I was like yo I'm on paternity leave please give me a chance to write this up and stuff but yeah but again that's the flip side of open source projects you know is that people who are involved with

this is the 10th calendar year I've been involved with Homebrew you know and people go from being you know young singletons living by themselves with plenty of free time to you know balancing kind of family life and multiple children and all that type of stuff and you know it's good because you know you get new people on board who are younger and more energetic and have more free time than you do but at the same time it's the flip side of well that's why you don't maybe have the time to do everything as well as you could and

that's why in my opinion as well like i'm even more increasingly now like pushing on no we can't kind of have more systems and more apps that we're going to have to maintain we want to be able to use other people's infrastructure so we're not worrying about having to manually run anything you know to keep keep the lights on and in homebrew's case. This HackerOne site is cool, and I think it's a necessary thing to really bring together two disparate communities. I mean, when you talk about security researchers and open source developers, in my experience, and you guys can tell me yours, there doesn't seem to be too much overlap. There's a few people who kind of play in

both pools, but it seems like there's a somewhat strict divide there in those two communities, and really to all of our disbenefit, that's not even a word, but to our harm, I guess I should say, because there's a lot that we have to offer

in terms of open source developers to security researchers and vice versa. And so anywhere that we can create places that we can come together and collaborate, and they can, you know, hack on our code, and we can fix things as they find problems, those are things that are necessary. Just thinking about some of the stuff you're saying, what happens at GitHub, there's a lot of best practices. You know, you're mentioning principle of least power and defense in depth.

There's a lot of things that we can do as developers that really mitigates the problem, you know, similar to like, well, if I get hacked, at least they don't have root access. Like there's no, you know, God mode immediately. So we can do things that help mitigate when there are breaches. But if we don't have those things taught to us or explained to us or reiterated or example to us, you know, we just don't know what to do, how to do it well. It's cool that they offer this free for open source. Maybe think of

proprietary companies and the advantage that they have is that they can actually offer cash for bugs or cash for vulnerabilities. As open source people, it's like, well, we can't even get any cash to buy a sandwich, let alone to fund some security audits yeah no i mean that's very true i completely agree uh and the other tricky thing which you know doesn't come across on the public side is you know the the

signal to noise ratio on this stuff is you know it makes github issues look bad in some ways because you get so many people who are going in more or less presumably copying and pasting the same report onto 20 projects just you know you find you you find a project that uses jenkins and then you you know copy and do the same sort of inverted commas exploit whatever about something that's not actually an issue and you know there's various people saying that they've like you know owned or get hub pages site and stuff like that it's like well it's a static site so i'm not convinced you have actually because there's nothing dynamic on that page whatsoever so unless you know you've somehow got access to github servers in which case they

will probably pay you for that bounty so yeah so it's it's tricky kind of wading through all that stuff it's a lot of noise yeah yeah just for the times where you know someone discloses something and you're like oh this is actually you actually a legitimate problem and we should deal with this now. But yeah, but again, that's... That's a hard problem to solve, yeah. It is. To be fair, HackerOne seems to have a good sort of reputational system underlying it. So you definitely don't see the same kind of bad reports more than one. And you can actually, I guess, to your your dark side showing if you get a really

kind of crappy report from someone then you can kind of flag it as basically being sufficiently negative that they take kind of a reputational hit in the system and stuff like that but you know you still feel like you're kind of i guess doing moderation slash being a recaptcha type situation so what's the advice then for maintainers out there that might find themselves in a similar situation? Should they go to HackerOne and get an account? What's your recommendation here? Yeah, I think so.

Yeah, I think I would still recommend going to HackerOne and getting an account because it's a workflow that I think makes more sense to security professionals. I guess it's in the same respect as like people might say, where should I create my open source project now? And I would say GitHub. And they might say, oh, well, I hear you get a lot of issues or drive-bys or whatever.

And it's like, yeah, that's the case. But at the same time, it's still the place where it's happening and the place that makes the most sense. And as far as I can tell, like HackerOne is the same sort of deal where it's not all rosy but it's definitely better than anything else I've found out there and it seems to be in our case at least it seems to have really encouraged

really responsible disclosure from people who know what they're doing who as you said wouldn't perhaps otherwise get involved so I feel like that's a sunny upland for us. I just want to highlight this note on your HackerOne page we'll link in the show notes hacker one.com slash homebrew in the exclusion section this just made me chuckle

uh while researching we ask that you refrain from and one of them is social engineering including phishing of homebrew maintainers or contributors it's just hilarious that you have to actually say that yeah so i well i think that was actually one of their templates is they have like a template of okay of suggested exclusions um yeah but no like or i copied and pasted that from other servers or whatever but yeah like i guess it's it's it's the same thing and i guess that's that's definitely one where i i feel like open source projects kind of maybe do warrant a little bit more sympathy. Like, you know, if you get in a situation where you're calling up open source maintainers at home for a social engineering attack, it's like, come on, just no break. Let

them have their evenings. Hack our code. Don't hack us. Yeah. Or at least socially engineer them this episode is brought to you by get prime they just released a 52 page beautiful field guide called 20 patterns this field guide is a collection of work patterns get problems observed while working with hundreds of software teams and their hope is that you'll use this field guide to get a better feel for how your team works to recognize recognize achievement, to spot bottlenecks, and also to debug your development processes with data. You'll learn about long running PRs, flaky product ownership, scope creep, knowledge silos, and so much more. Check the show notes for a link to download this field guide or learn more at getprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog. So, Mike, the big homebrew 2.0 started this month.

Shot up the charts of changelog News to number one quickly. Everybody was super excited. Of course, the huge announcement is the official support for Linux and Windows 10. A little bit of an asterisk by the Windows support. We'll talk about that. But tell us about Homebrew 2 and the big release. How was it received? Yeah, so it's been really exciting. it seems to be been received really well people have been really positive about it and it's a nice kind of like buzz in the community uh since doing so as well um it's been a kind of funny thing it's been you know the difference the distance between 1.0 and 2.0 has been i think it was two and a half years or something and then like 1.0 and original homebrew

was about you know seven years so it's definitely a slightly faster iteration but it feels like it's a kind of good balance between there was some kind of deprecations and big changes we wanted to make that we've been kind of holding off on for a while but then also some kind of big kind of features in there at the same time which like you mentioned, the kind of Linux stuff being a notable example. So yeah, so that's been quite cool. So there's been another project that's been running for quite a while now that was called Linux Brew,

that was basically just a full-on fork of Homebrew to run on Linux. And we have, like, the Homebrew project is sort of, you know, we've kind of had a little bit of back and forth and been kind of collaborating with those folks a little bit for a while, but maintaining our own independent folks. And it's maybe about a year ago we sort of started thinking, like, well, maybe we can actually bring these projects together

because the code's getting more similar and things like that. And I'd kind of started working a few years ago about trying to almost do a kind of proper cross-platform port based on, I guess, cross-platform work I've kind of done previously in my career and things like that to try and build nice abstraction layers so you don't just end up with like if OS Linux, if OS Mac, like all of your code. And so, yeah, so basically we did that and we kind of got all the Linux code back into Homebrew kind kind of done in a nice, kind of properly abstracted fashion. And we'd actually been using, running Homebrew on Linux for some of our CI stuff, you know, stuff like uploading packages and generating our kind of package browser data

and stuff like that for a little while now. So yeah, it kind of segued in nicely and it was fairly smooth and it's been a nice kind of transition and selling point for Homebrew, I think. Yeah. so if you were on a recent version of homebrew would it auto upgrade you to 2.0 because i saw the news and like oh i want to go get it and then i did a i don't know what i did brew dash b or i already had it was the long story short yeah so that's the sad thing that people end up with is that homebrew... So our version

numbers in some ways are just like notifying people of what has changed underneath you while you haven't been paying attention. Because it's already there. Yeah, exactly. So when you run like there's the brew update command which will put you on the newer version anyway, but since 1.0 actually

we've been running that automatically when you run various commands like brew install, brew upgrade, and things like that. So you just get put on the newest version. So I guess the slight downside to that is when people see, they're like, oh, I don't like the look of some of this stuff on 2.0.

I'll stick on 1.9. It's like, well, sorry, you can't. You're already on 2.0. There's no going back. So yeah, I mean- There's no consumer choice here. We know what's best for you. Exactly.

That's not the case for me at all. I'm actually... I don't know if this says something about me or not, but I'm on Homebrew 1.8.6. Oh, really? Oh, this says a lot about you. Well, yeah, you might have disabled the auto-update at some point.

That's a thing you can do. Is that in the config then to do that? Yeah. So you set an environment variable and it's documented in the man page and then you have to run brute updates manually. I guess that sort of segues

nicely that a lot of the things that some of the changes we've made now and a lot of the things that we've changed in the last few years have been things which you could do before but were always just a bit clunky. So another big thing we made in 2.0, which people have been kind of asking slash complaining slash begging for years, is we run kind of brew cleanup automatically.

So that was basically a command that goes and like cleans out like old versions that you're not using anymore and kind of your cache and stuff like that. And, you know, every like literally it felt like every week we would have someone post on Twitter and be like, oh yeah, I discovered this new command and it freed up like 25 gig of space on my disk. And every time I read that

I kind of winced a bit because I feel like there's not a lot of software or at least a lot of software that I think is great where you need to discover some hidden little setting to make it not slowly

eat up your entire disk. So, yeah, we've kind of changed that now and i guess like the up the update stuff you know by default now we just do that for you automatically we run it every 30 days we do like a full cleanup and then we do like the the package that you've installed at install time but again you can turn that off as well and so whenever we kind of change stuff like that we do try and make it so it's still possible to kind of sit and maintain the kind of previous workflow you had but I'm a big believer in

I guess being on an Apple Apple platform in general I'm a big believer that the defaults should be really good you should focus the defaults on the most sensible behavior for the majority and if that means occasionally having to break or

alter backwards compatibility then that's worth it for the silent majority of people who do not want to have to read the documentation to have the tool work the way they expect it should work. And as I say, provide opt-out so the people who would rather it stuck around

the old way, they can go and read the man page, set a little setting, read the release notes, whatever, and then they get that. But yeah, people don't always necessarily see it that way. I think that's definitely the sensible way of doing it. I appreciate the opt-out

because as somebody who enjoys running brew cleanup every once in a while and just clearing up space, it feels like you just cleaned your room or something. You know, having it not have such an impact might, you know, hurt my psyche. So I might go and turn that off so I can run it myself. But I'm starting to have flashbacks of our previous conversation. So I think we actually talked about brew update running automatically on our last call with you a couple years back. And I feel like maybe, Adam, we should go back and listen to that

because you might have actually turned it off while we were talking about it on that call because I think you remember talking about being able to opt out of that back then. I was Googling while we were talking here, too. I'm going to read something that Mike had actually said. It looks like October 2016 is documented in the man page. Instead of opting out, he recommends, Mike, you might remember saying this, you recommend setting the time period between checks

to a higher value instead of opting out. Yep, so I do that myself. So by default, if you basically run brew install, it'll run brew update every 60 seconds effectively. And that doesn't mean it will do updates. It means that it will check and see if there's any updates on GitHub. And obviously some people find that that can slow things down

or whatever. But again, we want to have the default for the people who don't read the docs and don't want to tweak things really, really low, because that brew update change, for example, back in 1.0 dramatically reduced the number of support requests we would get where the response is, we fixed that 10 minutes ago, run brew update. back in 1.0 like dramatically reduced the number of support requests we would get oh yeah where

the risk where the response is we fixed that 10 minutes ago run brew update and so now we don't get those issues anymore basically and the people who want to disable it can still disable it but yeah but i personally have that set to i can't remember what it is it's like you know a few hours or something like that so it's not running all the time and it just runs kind of periodically but that's kind of enough for me and then i still if i'm doing development sometimes i'll just you know set the environment variable temporarily in a shell and then i can go and know that it's never going to run let me just heap a little praise on you in the homebrew community because as we talk about this i'm just now thinking about it in time spans and i have been a happy homebrew user for years now.

I don't even know how many years. And I will just say that it's one of the only tools that I rarely think about in terms of, I don't know, effort. It's just like, I use it, it works. I enjoy running BrewCleanup. It updates itself. It's been like a rock in my life. I just haven't had any,

I don't know, homebrew is acting up again. I can't even think of a time. I have some issues once in a while with upgrading Postgres specifically, but that's a Postgres thing and not really a homebrew thing. And in fact,

whoever's working on that formula has improved it lately so that they help you, they hold your hand through the data migration more than they used to, which I appreciate because I don't do those migrations often enough to have those things memorized. But aside from

that, which again is a Postgres thing, it pretty much just works. Is that your experience, Adam? I feel like a lot of people have that experience and it's nice having some software that just works because a lot of software just doesn't work that well. I want to echo what you're saying too because I feel the same way. I mean, so much so that whenever I start a new machine, I'm using a version, my own forked version of ThoughtBot's laptop project on GitHub. And just because I have different needs than they do.

But I mean, it's basically just brew installs, some versions of homebrew being involved. And if it weren't for that, then it'd be a lot of manual bash. Especially with Cask, right? Yeah. You do all your installs, all your apps install through Cask now. Yeah, there's a couple of apps

that I for sure install every single machine. So I just do that between the Mac Apple Store. I think it's Mass, I believe is the command. Mac App Store, yeah. Yeah. So I mean, between Homebrew itself, Cask, and Mass,

it's pretty seamless to just start a new machine up. And literally, I just run a command and minutes later, the machine's ready. Yeah. Well, I may make your life

even better now because I'm going to do a shout-out to another project that I created, which was, it's a little project called Strap that replaced the Boxen project at GitHub. So basically

it's the same sort of thing you were talking about there for setting up your machine. So it's really kind of minimal, I guess like the kind of laptop script. It's like basically just a small bash script. But it will generate your GitHub tokens for you and stuff as well. But the cool thing about strap

i guess in comparison to the the laptop script or kind of box and stuff like that is that it doesn't actually install really any software for you it just installs stuff that you can use to install other software so it installs like um homebrew for you and the xcode command line tools and kind of enables like full disk encryption. But then I was thinking about it and I was like, okay, well, I want to have some level of user customization. And what's a cool way of doing that? So the next step beyond that is because it sets up your GitHub tokens and you kind of

get it going through GitHub, it goes and looks for, if you have a repo called, say, github.com slash mikemcquade slash dot files, then it will clone that automatically for you. And then if you have a script slash setup file in that repo, it will run that automatically for you. And then if you have a, have you guys come across homebrew bundle as well? That's the other thing that kind of ties into this ecosystem. So that's the other effectively that kind of ties into this ecosystem so so that's the other effectively half of this system so it will then if you have a brew file in your dot files repository or a homebrew

brew file repository then it will run homebrew bundle on your brew file as well and what does homebrew bundle do so that you can use that independently of strap this is a separate project that's kind of part of the kind of homeb. And what that lets you do, it's basically a rip-off of a gem file and Bundler, which was originally created by Andrew Nesbitt, this thing. Homebrew Bundle. It was called Broodler, originally.

But basically what it lets you do is specify a gem file-like syntax, kind of Ruby, but without the versions, basically, because we can't kind of pin everything to versions. And you can have it automatically install all your Homebrew taps, which is kind of third party repositories, all your Homebrew packages.

It can set start services for you if you want them to as well. It can also install all your Homebrew casks. So things like Google Chrome, Java, Firefox, et cetera. And it can also install everything from the Mac app store for you. So say you're kind of one password and things like that. So for me, when I have this kind of setup in my.files repo on GitHub, so I can just

run a single like strap script and it will go and do all this stuff for me automatically on my laptop when I run a single script basically. And the nice thing is that stuff is all, I'm able to kind of share the files I use and it's all kind of open source as well so people can see like what my

what my setup is and my brew file and things like that and because I'm incredibly sorry in fact this is a good kind of geek cred extension to that right so I was kind of looking forward to running this again because I had some issues with my MacBook Pro and Apple were

replacing the keyboard. So they gave me a lunar laptop and they said, when you get your laptop back, it's going to be wiped. And they gave it back to me and it wasn't wiped. And I was actually like so disappointed that I wasn't going to do this again. I voluntarily wiped my work laptop just to kind of go through the whole,

I was like, right, I'll do my, you know, like back in the days of Windows where you had to wipe your machine every few years. Yeah, yeah. I was like, yeah, I'm just going to have a fresh install and have a clean run because I'd gone and like tweaked all my scripts to be even more kind of smooth and polished. And so I made a little script as well that like pulls all my, so it'll pull like my SSH keys out of 1Password and stuff and then like dump them in the right place on disk and stuff like that.

So I need to enter my 1Password once and then it pulls out all my SSH keys and my GPG keys and my bin tray and GitHub tokens and things like that. And it's cool because, again, the script is all open source, but it's all pulling private encrypted credentials. It doesn't matter if you have access to everything in the script. So that's my happy place, is just automating things completely unnecessarily i definitely spend more time on the script well i was gonna just say that because i first of all

this is super cool and i'm a total geek cred on this but the reason why i've never used this even because adam's talked about thought bots what's What's it called? Bootstrap or laptop? Laptop. Yeah, laptop. And I looked at Box and I just feel like it's kind of a Yagney thing where it's like you're basically putting a lot of work into automating something that you do maybe once every few years. I'll tell you what, though. I thought the same thing, though, until you have a few machines

or you get a new machine you know not long after you prepare to do this again so when you go on the you go on the annual update scheme with no i mean i think i've probably had three laptops in the last six years i don't know maybe it's maybe it's less than that i feel like it's not that much not that often of a new machine but i've gone from laptop to desktop though because i have slightly different needs than you do so you know where i have to do more audio stuff and video stuff so i tend to need a more higher power machine so having this imac and then also laptop makes me need to set up more often than i would say you know twice as much you know twice as much as you did twice as much that's true so mike tell us why I'm looking at Strap, and we'll

definitely link this up, we'll probably log this on Change.News now that we found it. I'm already doing it, just kidding. You're logging it right now? No, I'm not, I'm just kidding. Why is there a deploy to Heroku button for a command line script? I haven't, I'm just perusing the readme, so clue me in here. Can you just run this from a website kind of thing?

Yeah, so basically the Heroku thing works for remember I said earlier that it will set up your GitHub tokens for you? So that's basically so it can do that. So the script, it's just a script, but this is something I stole from Boxen, which is the

when you download that bootstrap script, it gets you to log into GitHub, so it can then generate tokens, so it can set up all your GitHub access for you. So basically when you run that script, it gets you to log into GitHub so it can then generate tokens so it can set up all your GitHub access for you. So basically when you run that script, that gives the script the ability to talk to GitHub. And it also means that you don't need to do the whole initial, like basically you log into GitHub once through your browser and then it sets up all your kind of, after that, you can do a Git clone of a private repo and it will kind of work as long as the strap application kind of has access so that's i guess to answer the question of like why you

i mean i i love i i'm one of those people who i i love spending an hour writing a script to yeah do make a five minute task less boring right but like the flip side well this was it was actually i ended up kind of maintaining some of the internal software they use at GitHub to go and set up new developers' machines. Right. And this was basically- Which makes way more sense. Yeah. Yeah.

So this was the motivation for this. And since we've moved to this kind of new system, it seems to be saving a lot of people time. And again, the Homebrew bundle thing, it's actually got a few different use cases. So one is the, I want to set up all the software on my machine, but then there's also the, the kind of classic one that always bugged me was, uh, in the readme of a project that says, okay, so before you try and set up the server, you need to brew, install X, Y, and Z. And I always thought that that was kind of, I kind of, my attitude is like put stuff into code if you can rather than documentation.

So instead of that, now the little bootstrap script, instead of saying run brew install whatever, you can run brew bundle in that repository once you've checked it out, and then it will know to set up, say, MySQL, Elasticsearch, start those services if they're not already running. And if they are running, then it verifies that they are and stuff like that.

So I guess I see it as well as being like a project bootstrap tool as well for dependencies that are on the Mac App Store or in Homebrew Cask or in Homebrew itself. Yeah, we could definitely use that. The laptop project uses the bundle command as well. It uses brew bundle dash dash file, and this is all in a bash script. Oh, yeah, yeah, and then it embeds it in it.

Yep. So it's still using that same kind of concept that you're talking about, Mike. And that's the thing that makes me happy about this, because, again, that's when I worked on, when I was working on Box, and Boxing was very much kind of more of a kind of monolithic system.

And the thing that makes me happy with the way that we kind of built this solution that replaced this at GitHub is you know it is kind of in my opinion the more Unix-y way of doing things in that you build a bunch of tools which will interoperate nicely and you create a system from combining those tools but it means if anyone says like the laptop project, well, one part of this tool chain looks useful to us and the other parts don't, then they can still get all the benefits of that one part of the tool chain, and they can still kind of be part of that ecosystem.

And I feel like that, you know, makes things better for everyone, really, when you have kind of segmentable tools that combine together, rather than having, like, one big monolithic system that you can't really swap bits in and out of. This episode is brought to you by Raygun. Raygun recently launched their application performance monitoring service, APM as it's called.

It was built with a developer and DevOps in mind, and they are leading with first-class support for.NET apps and also available as an Azure app service. They have plans to support.NET Core, followed by Java and Ruby in the very near future. And they've done a ton of competitive research between the current APM providers out there. And where they excel is the level of detail they're surfacing. New Relic and AppDynamics, for example, are more business oriented,

where Raygun has been built with developers and DevOps in mind. The level of detail they're providing in traces allows you to actively solve problems and dramatically boost your team's efficiency when diagnosing problems. Deep dive into root cause with automatic link backs to source for an unbeatable issue resolution workflow. This is awesome. Check it out. Learn more and get started at Raygun.com. So Mike, we mentioned the support for Windows and Linux, and I said there was an asterisk by the Windows support, mostly because you had a few people out there saying, this isn't real Windows support because it's Windows subsystem for Linux.

Can you tell us what that means? Are there things missing? Do you consider it official Windows support, or what's your perspective on that? So that kind of came from the Linux booth folks, basically, who did a bit of work to kind of get that stuff working. But it mostly kind of worked out of the box. So if you're unfamiliar, Windows 10 chips with a thing that's called Windows Subsystem for Linux.

I don't believe it's a software by default. You can enable it. It's kind of a developer tool thing. And basically, it gives you a full Ubuntu environment on your Windows machine. And the really cool thing about it is it's not like you know transparently running a vm in the background but it's actually running native linux binaries through uh i can't remember exactly how it works under the hood but it's some sort of like kernel syscall uh mapping um i guess in in a vague way it seems to be a little bit like wine, if any of you are familiar with that.

But in reverse and at the kernel level, I believe. And it's easier for Microsoft to do that, obviously, because they can see what the Linux Cisco interface is because it's all open source. And they've been involved with Linux development in the last few years and stuff like that. So yeah, it's basically a way of running native Linux stuff on your Windows machine.

So as a result, you can run Linux brew under that. And then when Linux brew joined Homebrew, then you can run Homebrew under that as well. So it's one of our officially supported platforms, more or less because it's just a relatively simple way of being able to run Homebrew on a Windows system. And in terms of, yeah, I would agree it's not, I used to do kind of proper native Windows development in the past, and it's certainly not that. It's not a native Windows package manager. For that you have kind of things like

NuGet and Chocolaty and things like that. But if you kind of want to be able to kind of dabble in things that are in the Homebrew ecosystem and try them out on a Windows machine without having to spin up a Linux VM or a Mac VM or whatever, then it's a way of doing that. So does it have a completely separate formula?

I assume the formula have to work differently. Yeah, so the formula are separate between Linux and Mac for Homebrew anyway. So there's a repository Homebrew Homebrew Core which is all the Homebrew packages and then there's a repository Homebrew Linux Homebrew Core now as of I think two days ago. It used to be Linux

Homebrew Core. Flip some stuff around. That basically has all the Linux packages separately and the reasoning for that is that basically has all the Linux packages separately. And the reasoning for that is that it's on the formula level, which is our name for the package description files, it's a lot harder to do that stuff I talked about earlier with making things nice and clean and having separation.

You end up with having a lot of if Mac, if Linux. And basically, as a result, those have evolved a little bit more separately. So on Windows Windows it ends up using the Linux under the Windows subsystem for Linux, it ends up using the Linux versions of the

formula for a package. So there's effectively two pieces of software. There's not separate Windows ones. There's Homebrew and Linuxbrew but they're all under one parent at this point but there aren't three it's not as if you separately went out and implemented windows it just is coming along quote unquote for free because of the windows subsystem for linux exactly

and i think there were a few tweaks to kind of make it run a little bit better but yeah it more or less came for free so have you seen a lot of pickup from the Linux and the Windows side? Are there issues and bug reports coming in that are new to Homebrew 2? Or was it already happening with Linux Brew and so just kind of a merging of these two projects? Yeah, so I guess I noticed a few more Linux issues than I used to because it used to be separate repositories. And now for the package manager part, at least it's all the same repository now. But yeah, I mean, their analytics on the Linux side of things, they've seen a big uptick since Homebrew

and LinuxBrew joined together in that way. So that's kind of been cool. And it's been interesting in general, just seeing and people kind of learning, why would you use LinuxBrew and stuff like that? Which is, in some ways, that's a question where that's the one you tend to get the most with the Linux support is, well, why do you do this?

You know, why would you not just use AppGat? Which is a valid question, because I still, despite being the Homebrew project leader, consider AppGat to be a superior package manager in very many ways. And basically, the reasoning is, the original motivation of a lot of the people who work on linux actually is because they if you have access to the package manager on the linux system then great and a lot of people are thinking kind of

from the developer perspective of you know i'm a dev i have my own system i set out myself i'm running linux on my system you know like I don't have a workplace who is not letting me install things through the package manager. But some people do have that. And a noticeable group is people who are running on big Linux supercomputing clusters. They have access to run stuff on that system, but they often do not have access to root on that system or the package manager on that system. So the way they generally have to build their own software is they just build stuff in their home directory by themselves

and without really any support and linux brew has allowed some of those folks to be able to have an actual package manager that they can use and they can just install stuff in their home directory or if they want to use linux brew's binary packages then they can i've been informed this is an a lot easier ask they can say hey can you set up a new user on that system it doesn't need to be root a new user called Linux brew and then all the binary packages are kind of built um so that they can be used on their home Linux brew and and then the system administrator can kind of set that up and they can go and then benefit from some of the binary packages as well

what about the brew file with the bundle is that something that's only on the mac side i assume there's definitely like the cask stuff and the the other stuff wouldn't be available on the linux side but would you at least be able to have a project with a brew file that's you know lowest common denominator so that somebody on linux and somebody on mac could both use the same brew file and get their setups going yeah i mean i think you As you say, it would have to be lowest common denominator because there's some stuff that doesn't work. On the Linux side, it would effectively be just setting up Homebrew third-party repositories, taps, and installing Homebrew packages formula. But yeah, it's not officially supported by us in Homebrew Bundle, but I would imagine it probably works,

I guess, thinking of the way the code behaves okay so what about the team so this linux brew seemed like it was its own deal and now it's part of homebrew so is there a merging of teams and communities or are these people that were already involved with the homebrew community in the first place yeah so i mean there's i guess two linux brew maintainers came across specifically to homebrew as kind of part of the well i guess somewhat pre the merge there's two people who are like our main maintainers mishka popov and sean jackman but then we we have a few other kind of maintainers who are kind of are in and out of linux land and stuff as well um so yeah so it's been good actually i feel like it's injected a

lot of energy into the project because lin Linux Brew probably has a disproportionate number of, I guess, like the Linux ecosystem in general, I would say, a disproportionate number of in LinuxBrew's case for quite a few years in the Homebrew wider ecosystem. So they kind of come into Homebrew with the understanding of what it's like to run a project and triage issues and interact with other maintainers and stuff like that. So yeah, no, they've been invaluable. Well, going a little further, there's been some changes to governance. There's been a first ever in-person meetup paid by Patreon donations. Take us down the road of this very first in-person meetup and what's kind of govern the project so i guess in a brief kind of history through it was originally kind of max how the original kind of creator and he got some other maintainers on board such as myself and then he dropped away from the project and then there was kind of a goal to sort of just run it all like i guess as a complete flat hierarchy for

a while but as is the case with companies as well like generally you kind of need a little bit more structure than that we found so i sort of um somewhat unilaterally declared myself lead maintainer after checking with other people that would be fine a few years ago and then kind of we've you know there's been a few and if you kind of troll through the homebrew issue trackers you can kind of see some of it there's been a little bit of tension with that on occasion because you know people don't necessarily agree with you know understandably that you have someone who's in a position of authority with no clear way of removing them if they stop working on the project in future or start to abuse their authority or whatever so we kind of talked for a while about you know in future trying to have some better sort of governance model and maybe looking at some of the the older more senior open source projects than us and seeing how they do some of this stuff um and then i guess as a result of that again as you

mentioned we've kind of had a reasonable amount of money coming in through patreon now and we're part of software freedom conservancy and i've had some donations through there so we kind of thought well like something which we can do with that money uh is that would be kind of valuable is have a bunch of homebrew maintainers kind of come together and meet up so we had uh 14 of us kind of all came to brussels around the time of fosdem because it's a kind of big open source conference uh that is free to attend as well uh so we got there and then we had the day after post-dem was over, we basically just rented a meeting room in a hotel and all kind of got together and, you know,

had lunch and dinner and had a basically, I can't remember what you guys called it, not to be too grandiose, when the founding fathers all met together to- The convening. Yeah, yeah. So, yeah. So we ended up not necessarily knowing what we were going to talk about before,

but it ended up being mostly about governance of the project. And it was super valuable, I think. We managed to etch out in that meeting the outlinings of a structure for the project. Shout out to John Chang specifically, who had kind of written up a lot of stuff and kind of come into the meeting with, you know, a really, really decent draft of what to do. And then we kind of iterated on that a little bit during the day

and then iterated on it more kind of in private. And then we opened a pull request on Homebrew, on our kind of main repository to kind of solicit contributions on that as well. And then, yeah, after a week of that being open we can emerge that through so what that actually means is that we now have um a bit more structure than we had before we have a lead maintainer role has gone away and been replaced with a project leader uh which maybe sounds a little bit like um two things that are exactly the same but the difference is the project leader role I was

elected into that position and stood for election and I will be if I want to I will stand again next year and then there will be another election and anyone else who stands will have a platform if they want to do and then we can see effectively who gets elected by basically by the members to to be in that position so we have a governance document that explains kind of how this all works now we have a project leadership committee and a technical steering committee of which i'm currently on all three but again the nice thing is in in future uh that's changing so i cannot be on all three and so not me specifically but uh you basically cannot have a role that is on all three places.

And we're also having this idea of members to Homebrew as well, where if you have someone who isn't a maintainer, maybe isn't involved as much with the code side of Homebrew, or has been involved with Homebrew for quite a few years, then they can get nominated and join as a member. And then they can vote on some of these elections in the future and get involved with the project on the administrative side without necessarily needing to or wanting to get involved with it on the technical side have you laid any of this out in documentation by any means i know i i've seen the latest two documents so there is governance yeah so if you check out the docs.brew.sh site then right at the bottom that page there's a homebrew governance document which kind of lays all this out it's kind of vaguely legalese language it's fairly readable but it's not you know it's not great kind of super fun reading but it does explain kind of how this stuff all works and how people are elected and and not and how often these meetings happen and stuff like that so that's kind of worth a read if you're interested in this stuff.

And it's nice as well because it's as well as being like bringing some elections into things and policy and stuff, which is, again, nice for me kind of to be, you know, I think it's nice for me and it's nice for the community to have me actually be

kind of elect the role kind of and have the majority of people agree that, you know, obviously they think that I'm doing a good job and that they kind of support me doing that for the next year. But it's also kind of, as I said, with putting limitations on what people can do, it's going to end up reducing our bus factor as well.

Sorry, or increasing our bus factor. I can never remember which way around that is. But basically, it's going to make it much easier for us in future to have things not be too centralized on an individual because we have these committees we have a leadership position and it's clearly defined what the roles of each of them are and the responsibilities are and that you can't basically be responsible for everything and i feel that that's going to be a really positive thing in future and it's also as we mentioned earlier i think this happening at the same time as the kind of linux merge it's brought in a bunch more people who have kind of been enthusiastic and have been helped and got

involved with that process so we have people on the technical committee and the project leadership committee who have come from that linux brew merger and so that's kind of been a nice positive thing from that as well maybe an interesting takeaway here too is i guess now having an annual general meeting which puts a little bit more pressure on the need for i guess finances which is good for patreon that you've got that but then you also mentioned software freedom conservancy um i'm just kind of curious what your thoughts are on funding this project and how you got, how you all look at, you know, attaining funding and maintaining that and the,

the needs for, for funds to do things like this. Yeah, that's a good question. And I think this has been, you know, our funding has got to the level that we've been able to afford to pay for flights for people to kind of come to stuff like this.

So, you know, we have people coming from Canada, people come from India to this meeting and that's been really, really great. But then obviously the amount of funds we get limits or permits

what we're able to do with the project. So it would be great to have a future where we could hire potentially people to work on aspects of Homebrew, maybe the infrastructure stuff we mentioned before, full or part-time. But at the moment, we still very much have an amount of money that pays for flights once a year, but we don't have an amount of money that pays anywhere near a reasonable salary for someone with money left over as well. So yeah, so increasing our funding

is a goal for future. And hopefully as well, the more we're able to be transparent about what we've spent the money on and how that's all broken down, the more we'll be able to solicit more funds and know that people know that it's not just going to a black hole, it's going to be a blog post incoming at some point in the future where we'll write up um what we did at this meeting who met who was there what we talked about we've got all the minutes and stuff like that and i also want to detail in that blog post like how much we spent and why we felt that that was a good use of money as well because we don't we don't have the exact breakdown of everything now so we're kind of still waiting and kind of working with software from conservancy to kind of get that and kind of working with Software Freedom Conservancy to kind of get that information. But again, that's the nice thing about open source is you can afford to be more transparent about this stuff

than you would be as a business. And also it might be in future that there's opportunities where, I've spoken to people at large tech companies before who've said, you know, if you just want us to give you X amount of money, particularly in something like Patreon, that's very hard for us to to do whereas if you want us to kind of pay for flights for 10 people that's actually really easy for us to do so this stuff may also open doors in future for

us being able to ask for more specific financial commitments or uh donations from companies in a way that makes it easier for them to give money to us rather than just you know something like um you know i know if you're as i say if you're a massive tech company getting a a line item approved from finance or whatever to sign up to patreon with a corporate credit card and give a certain amount every month is you know it's not easy that's that's a system that is built around the assumption that most of the donations will come from individuals from the goodness of their own heart and while that is is great, and I'm all for that, I think we need to, with open source sustainability stuff, we need to try and figure out ways of making it easy

for the big tech companies to give to you. Because they get villainized to a certain extent, and some of that is legitimate, I think. But then some of it is just like, you're not making it easy for them to give you money. And you need to figure out, as I guess the charitable sector has kind it is just like, you know, you're not making it easy for them to give you money and you need to figure out as I guess the charitable sector has kind of worked out for quite a while that,

you know, it's as much about meeting them where they're at and making it as easy as physically possible for them to give you what you want rather than saying, you know, this is how I accept money and you need to kind of meet me where I am. How's that play out then for an entity? Does homebrew have a legal entity? You know, is this Patreon connected to a person? What's the state of things there? in the u.s um which to those of us who aren't in the u.s that basically is a u.s charitable organization that means organizations can donate to them tax-free they also provide legal services

were homebrew to get sued as an organization say um and they provide a certain amount of kind of just being a legal entity that can own things and have bank accounts and such like so that's basically our patreon money and all our previous kind of money from our kickstarter and stuff that has gone to homebrew freedom conservancy who goes and kind of manages all our funds on our behalf and in some ways they work like a little company for us which is great so for example with the way we have all the kind of homebrew money in a bank account and we have a sum of how much we have, and people are able to donate to the Southern Freedom Conservancy, and that goes straight to us if they kind of say that that's for homebrew.

But at the same time, when we book flights, we don't just book all the flights on homebrews credit card. They have kind of an expense policy, and you go and reimburse that way. And it sounds like it would be nicer to put things on a credit card but as the person who would probably be having to book that i'm glad that there is more kind of responsible oversight with this stuff and the nice thing with this freedom conservancy is that they don't really specify anything about the technical running of your project beyond the fact that you need to have some sort of leadership committee so they they basically let you run the project how you like and then they

focus more on the kind of legal and financial side which is great for us and for me because that's the side of things that we're you still own the copyright and stuff like that then um yeah so we don't yeah we don't do copyright assignment or anything like that in homeroom um because yeah i i don't know uh why we don't know why we don't or why we do, but that shit, I don't know, I've said it a long time ago. Switching gears slightly, I'm recalling the last time you were here

a couple years back, we were talking about you'd recently added analytic tracking to Homebrew with Opt-Out, and it was a bit of a controversy, so we discussed that last time, and I remember on that call us saying it would be cool if you opened up the data for the community to see, since it's our data, I guess, in the first place.

And since then, you've done that, which is awesome. We'll link up some of the analytics in the show notes. I thought it would be fun here. Have either of you looked at the uh install stats recently in terms of formula installed adam or mike yes i i look at them pretty recently yeah oh you're killing me y'all like adam you just looked at it uh before the call i guess prep yeah it's part of this all right it ruins my game i was gonna have us guess why you said i can still guess come on let's play the game okay let's play the game so uh 90 day install events okay so we'll take turns mike and then adam mike might have these memorized maybe this is like on a dashboard above your bed or something

at home but hopefully not uh top installed formula and over the last 90 days try to hit in the top 20 but try to hit number one. What do you think? What's the most installed packages? I'm going to be pedantic because I know how the analytics work to start with. So are we going for install events or install on request events?

Install events. What's the difference? So the difference between them- Should I go the other way? No, no, I guess it's interesting the difference because if people are looking at these, it might help to explain. So the install events is if I install a package

and it pulls in a dependency, then the package and the dependency are both install events, whereas only the package I specifically request is an install and request event. Oh, okay. Let's do them both. We got time. So let's start with the overall install formula,

install overall install events. So this means either you asked for it or it's a dependency, which means it's infrastructure. So that will change the results for sure. But what do you think? Some of the top packages here, or formula. You get to guess one and then Adam gets to guess one. We'll do a family feud style. Okay. Well, I'll

guess the easiest one first, which is... Survey says? Open SSL. Open SSL. So you got number one. So sorry, Adam, but you already lost. Not fair. He runs this project. Okay. But you can still hit up there, number high.

So what do you think, Adam? I'm going to base mine based on our most popular page on changelog.com. I think you know what that is. The changelog. Installing Node. So I would assume that Node is probably in the top somewhere. Oh, that's right. Yes, Node is number five.

So very good. Let's go one more time each, and then we'll switch to the other events. So Mike, give us another one. Try to hit in the top five. Try to hit number two. Python. Python, close. That's number three.

Number two still on the board. So we have OpenSSL first, Python third, Node fifth. So Adam, you could squeeze in there at number two if you can think of this. I'm going with Git. I gotta scroll way down to 15. The correct answer was, as you should know, SQLite. Number two.

With 1.35 million install events in the last 90 days. Now let's go to formula install on request events, and we might have very similar responses. In fact, I won't make you guys guess. I will tell you that it's the same packages, but they've kind of been moved around.

So node is number one. Python number two. Sneaking up there, number three, wget, followed by git, and then fifth is yarn. So we see these are user-facing tools. Something that sells a little further, yeah. Yeah, trickles down to nine because most people are using that as a dependency,

but not most, but often. All right, fun game. Very cool. Check those out. I didn't know this was out here until recently. Has this been out and available for a long time, Mike? Yeah, it's been available for, I don't know, maybe. In fact, I know how long it's been

because I remember building it when my wife was heavily pregnant and we were on our last vacation before my son was born and i felt you know i have to do this now because this is my last chance ever um yeah so that was about so you know exactly how old it is there yeah exactly uh yeah no so about about a year um in any form and probably about you know half a year and it's about a year in its current form probably but yeah no so it's great actually it's been nice to kind of get that done because and probably about half a year in its current form, probably. But yeah, no, so it's great, actually. It's been nice to kind of get that done because, as you said, you know,

and that's what I hope for is make this stuff open. And we sort of live by that as well. So because this is pulling data from Google Analytics, you need an Analytics API key to access that data. And me and the other maintainers don't even have an API key on our machines anymore. So when we're consuming analytics data, we're consuming entirely the same public data that everyone else does. And there's actually APIs on that site as well that you can pull this data programmatically,

which has been handy for people because both the analytics data, I don't know if the APIs are used so much for that, but for the formula data, for example, you can query information about a formula without having access to a Mac system, say. And the worst slash best part of this all is it's actually all on GitHub pages. So you can hammer it as much as you like, and you're not going to cost us any money.

And if you want to see pain in the world of code, if you look at what it looks like to build a JSON API on top of GitHub pages then you will know great sadness I might go read that later because I like to know great sadness every once in a while especially when I don't have to write the great sadness I just enjoy the results

we know Homebrew 2 is fresh and it's new but we have to ask you what's in the future is anything anything that's not out so far anything that's uh fun planned that's coming up that you can tease or mention yeah it's funny so that there's no really big things that i can think of like homebrew 2 for me was a funny experience because that was kind of the end of my my list of like things that i thought were really important that i wanted to kind of get built before uh so from my perspective there's not the stuff i would like to see but again this is kind of a bit more fun because it's dependent on the kind of community stepping up it has been talks for a few years about

uh being able to show licensing information for homebrew packages so you can query what license each individual package is you could maybe say i deliberately don't want to install i know this some commercial uh organizations would find it useful to say i just don't want to allow say a gplv3 stuff to be installed at all and so yeah we have someone who's sort of started finally a community effort to kind of build up a groupings of all that kind of licensing information for packages and then when that reaches um kind of complete enough state then we're going to go and we'll merge that back into homebrew itself and this was the process that we kind of took for descriptions adding them to packages back when we did that where we said okay if someone

can go and effectively build up all the metadata when that's done we'll then merge it back into the project um and, so we've got a guy who we tweeted about this the other day and you can go and see there's an open help wanted issue in the Homebrew Brie repository as well. He's building this stuff up so that would be a cool thing both to watch

and also to get involved with. We'll make sure we get that link for the show notes then so listeners can check that out. Mike, you know what? It's always good catching up with you and and uh i think it's funny too how you can earmark when things happened with homebrew based on life events i think that's a true sign of you know the life of a maintainer you know and so as someone who uses the code that you've worked so hard to to slave over all these years and put this much effort into and all this stuff. I'm just so appreciative of that because you make my life so much easier as a Mac user

and getting my system up and running as we talked about in the show. So I appreciate that and I'm glad that even though you're on vacation, you can still put out a good feature, which is appreciated. Well, thank you very much and the nice thing about it for me is that you know believe it or not it's still fun for me to work on homebrew and that's that's the thing is that it's still something in my free time that you know maybe not as much as i used to both because of maybe homebrew growing up a little bit but also because my life getting busier but you know there's definitely times where i'm at a weekend and you know my wife's out with my kid for a little while

and i've got free time to myself and i'm like what do i feel like doing the most right now well i feel like you know working on homebrew and that's the nice thing that i'm able to do that and it's fun for me and get to kind of give back and have other people have something useful at the end of it as well well mike we thank you very much for Homebrew and the rest of the team that makes it happen. And also for your time. Thank you. Yeah, thank you guys. Great job.

All right. Thank you for tuning into this episode of The Change Log. Hey, guess what? We have discussions on every single episode now. So head to changelog.com to discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts.

If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. And of course, thank you to our sponsors, DigitalOcean, GetPrime, and Raygun. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master or go into your podcast app and search for changelog master. You'll find it.

Thank you for tuning in this week. We'll see you again soon. Practical AI is a show hosted by Daniel Whitenack and Chris Benson about making artificial intelligence practical, productive, and accessible to everyone. You'll hear from AI influencers and practitioners, and they'll keep you up to date with the latest news and resources so you can cut through all the hype. As you were at the Thanksgiving table with your friends and family, were you talking about the fear of AI? Well, I wasn't at the Thanksgiving table because my wife has

forbidden me from doing so. It's off limits for me, lest I drive her insane because I never stop. New episodes premiere every Monday. Find this show at changelog.com slash practically AI or wherever you listen to podcasts. The only other thing I would want to pull into the show or not even the show, maybe just an after show. I almost thought about this during, but I forgot until just like right there at the end was what keeps you motivated? You know, like, yeah, there's so much work that goes into this. Like, you know, you're on paternity leave having to write up this incident report. I mean, that's sort of like one variation of motivation

because you kind of have to at that point. You've got some responsibility, but no one's making you make homebrew better. And it's not like you're getting paid to do it. You know what I mean? Yeah, I guess that's... He enjoys it. I mean, I think the thing for me is that

it's actually kind of the opposite from what you said, bizarrely, where I wrote a blog post about this a little while ago. Unfortunately, it's got a slightly flame baity title because my my brief stint in kind of the marketing organization at my company pointed me out pointed out to me that you know flame bait is a good way of getting your links shared more and it was called open source maintainers owe you nothing and basically that was like that's what keeps me motivated really is the fact that like i don't act i know and i have strongly internalized the fact that like i don't act i know and i have strongly internalized the fact that i don't own anyone anything you know and the licenses

that open source software is under state that quite clearly that um if i release buggy code which destroys your computer blows up your house whatever like that's you've disclaimed all warranties on that and And you've basically said that that's not in any way my fault or my obligation to deal with that in the license that you agree to when you use any open source software. So I think that kind of helps me a lot, actually, because most of the time people are decent, but there have been times in Homebrew's history where I've closed a legitimate bug because the person who has reported it is unable to maintain a conversation in a way that isn't extremely rude and extremely toxic. And I can't do that at work. Thankfully, I don't have a deal with customers type role at my work

anyway. But if you're in a workplace and you're being paid by someone, you can't just decide, well, no, actually, I'm going to stop talking to this paying customer anymore, unless you're the one running the business which I am not whereas in open source I can decide to do that I can decide at any point right well I just opt out of this conversation I'm done here I'm moving on

I'm going to do something else and I think particularly nowadays it's kind of helpful to be I think that's really been brought home with like having a family and kind of being aware of like my mood and things like that's really been brought home with like having a family and kind of being aware of like my mood and things like that and my wife's really good at kind of pointing out if I'm particularly kind of happy or sad or whatever and I try and sort of like double down on that but I think it's been helpful with that because I have homebrew issues which kind of need to be fixed you

know they're not urgent priority but they're relatively high priority that have sat unfixed for three or four months because I don't want to fix them. And if someone else thinks that they're a big enough problem, then they'll fix them and I'll happily help them figure out how to fix them, but I don't have to. And they don't affect me, so I'm not going to. And again, that's for me, in some ways, the interesting thing about introducing more money into open source is again, if homebrew was my full-time gig and I was being paid full time to do that then all of a sudden that would change and i would feel a sense of obligation that i would have to work on those things i would have to fix these things and particularly if the people who were individuals or companies who were paying me were pointing out that these were the

problems that they were experiencing whereas the nice thing is i can say well actually that one doesn't look very fun so i'm not going to bother