Ep. #14, The Workbrew Story with Mike McQuaid and John Britton

Brian Douglas: Welcome to another installment of Open Source Ready.

John McBride, you're back again as co-host. How you doing?

John McBride: Hey, I'm back. How you doing, Brian?

Brian: Yeah, thanks for never letting go. You're still holding on.

John McBride: I try.

Brian: This is episode 14 actually at this point.

John McBride: Wow.

Brian: We haven't pod faded as they say in the business. I think the number seven is where you quit.

John McBride: Okay, so we're over the peak, you would say?

Brian: Over the peak, but we're not here to talk about that. We actually have some pretty cool guests.

We got Mike McQuaid and John Britton from Workbrew. Mike, how you doing?

Mike McQuiad: Hello, very good. Thank you for having me today.

Brian: Yeah, and John? John, you're here as well?

John Britton: Yeah, thanks. It's good to be here.

Brian: Cool. So like let's do some intros.

Mike, you can go first. tell us like who are you, what do you do? Like why are you doing this?

Mike: Yeah, I am Mike McQuaid. I live in today actually truthfully sunny Edinburgh in Scotland. I have worked on developer tools for the last probably 20ish years.

Most recently, I guess we'll talk about that later, I'm working at Workbrew. That's a company I started with John.

For the last 16 years, I've worked on Homebrew, the Macs and Linux package manager, which I've been kind of leading for the last few while as well.

And I spent at a decade at GitHub building developer tools there as well.

Brian: Yeah, John, you've got a pretty extensive background, but like what do you do?

John Britton: So I've spent most of my career also in developer tools, but mostly on the go-to-market side. So I got my start as a developer advocate at Twilio.

I also worked at GitHub for a number of years on the education side and then later on kind of DevRel and then developer marketing until I came out and started working with Mike and started Workbrew a couple years ago now.

So yeah, been doing developer tools and kind of web development, that kind of stuff for 20 plus years.

Brian: Yeah, so honestly like we probably just want to like not bury the lead and like let's just describe what Workbrew is and where it fits today.

And so how you came to this conclusion that it needed to be in the world.

John Britton: I mean I think the best way to start is to start with Homebrew.

So Homebrew is an open source package manager, primarily targeted at macOS. It's got tens of millions of users, something like 15,000 packages available and it's pretty much the defacto app store for developers on Macs.

And you know, with Mike's extensive history as project leader of Homebrew, it was obvious to me as early as let's say 2013, that there was an opportunity here for a business.

It took us quite a long time to figure out what that was and after going out and talking to lots of companies, especially companies in regulated industries where they have kind of rules of things that they need to keep secure and whatnot, we found that there was a need for kind of a managed version of Brew.

So that's where we ended up going in and building Workbrew, essentially taking Homebrew from a single player experience on one developer's machine to a multiplayer team wide experience with kind of centralized management.

Our core value proposition is that you have one place to manage all of the software installed across your entire fleet of devices. You get full visibility, you get the ability to kind of remotely manage, patch, upgrade things and set kind of some compliance guardrails to make sure that your developers are happy but also safe and secure.

John McBride: Yeah, this is great and actually really resonates with me 'cause years ago I built, I mean it was really just a bunch of bash scripts for bootstrapping workstations at Pivotal.

And the way Pivotal worked was, you know, everybody just sat at a workstation to do pair programming together.

So ideally you could just like move around to any of these different computers, to do a bunch of this different stuff and it was constantly breaking.

So I can really appreciate this work and know that it's very, very valuable.

John Britton: Mike has an open-source project from GitHub times. Maybe you want to talk a little bit about Strap, Mike?

Mike: Yeah, we did the same sort of things like GitHub, where Homebrew is kind of fairly integral to the developer experience there.

So yeah, I built a thing called Strap that was basically just the delivery mechanism for the first thing you could run on your laptop to get kind of Homebrew set up in your machine.

And then on top of that you could have your personal like Brew file, which is a big, maybe the coolest part of Homebrew I feel like people don't know a lot about, which is basically like a decorative way that you can like list, I want all these packages on my machine.

And then you could keep that in your dotfiles repository and then basically you can get everything from Homebrew bootstrapped on your machine that way.

But also in GitHub we use them extensively across projects as well.

So rather than having a new ReadMe like, oh yeah, remember to install Postgres and set that up, you could have scripts that would call the brew file and the repo to make sure that everything was, that the projects needed had that installed in the right directory.

So yeah, that all worked pretty nicely. And as you say, John, like I think the goal for this stuff is always onboarding, making that speedy, turning documentation into code, making it consistent, all this good stuff.

Brian: Yeah, and John McBride, you mentioned Pivotal in passing, but like some people might not even know Pivotal's like engineering culture where it was like pair programming all the time every day.

At the pair programming station, which is like amazing that that was even a thing.

I don't know if that's still a thing at companies today, but like I've got like my personal keyboard that has like my touch and feel like I can't type without it.

It goes everywhere with me. I couldn't imagine having not only not having my keyboard but also not having my setup.

And like just before we got on this call I upgraded my Postgres to like 14.7 using Brew Upgrade.

John McBride: Nice.

Brian: So I was going to ask the question 'cause I've been... so John's been working on this like AI agent framework in Go and I've been like testing it out.

I don't feel like I'm a "Gopher" yet and I don't really know a lot about setups.

I just do, I used to be a copy and paster from Stack Overflow but I constantly run into like the problem of like I don't have the right versions, I don't have the right things set up my user bin, local, whatever, it's all messed up because I don't know how ZSH works.

So I guess the question is like is Workbrew today, is that solving that for like engineering teams?

Mike: Yeah, so I think basically like Workbrew has two main audiences in mind, right?

So one of them is Mac admins that we talked about before essentially like the people in your IT of security team who are making sure that all the Macs have the right software and are in compliance and stuff like that.

And historically that crowd has not been a huge fan of Homebrew because they don't have visibility. The tools they use like Jamf, Kandji MDM tools don't play nicely with Homebrew. So basically like that's the main first piece we've built right now.

And then we also care a lot about developers obviously like we are building a developer tool inside of Homebrew and the goal with Workbrew so far has essentially been to provide all of the compliance and security stuff that those folks want and an identical developer experience.

Basically a just as good you wouldn't know that you're using Workbrew instead of Homebrew. But we're not ready to announce anything just now.

But we definitely, we have stuff in the pipeline related to what you were talking about, Brian, where we have heard those concerns before about the issues around, say, reproducibility with Homebrew and being able to set up a new machine and then turns out everything that was working fine on the old machine is now not working in the new machine.

And basically like the only thing we could say there is we've heard that loud and clear and we at Workbrew are working on solving now. We just don't have the announcement for that type of stuff yet.

John Britton: Yeah and I think like just to add to that.

The idea behind Workbrew also is not just to give the same level of experience on the developer side but to make it better, right? How can we make things better for teams that are using Brew?

I've used Brew with lots of different teams and generally there's some patterns that people follow and find. Oftentimes it's like Mike said, like there's a read need with a bunch of packages you need to install.

Maybe there's a script that calls through Bundle, maybe there's different stuff but there's not a recommended path let's say.

And I think we can go a long way in giving companies more of a recommended path to make sure that their developer environments are consistent and reliable and easy to set up and smooth and also secure and have the latest things and free from vulnerabilities and whatnot.

So yeah, there's more to come on that front for sure.

John McBride: Yeah, so it seems like there's a very bright future for Workbrew and the brew ecosystem at large.

Mike, I did want to ask you about the past and like where we're coming from 'cause I mean for me Brew itself is almost table stakes even on like my Linux desktop.

Like there's just some packages I got to get off of Brew. But where has this like community gone?

You've been maintaining it for a long time. How do you handle all that pressure across basically every developer's MacBook in the world?

Mike: Yeah, it's pretty crazy.

Homebrew is unusual I think in terms of how much stuff goes on and how many packages we provide and how few people are involved day to day.

So we have like I think 30 something maintainers. In reality probably like 15 are pretty regular. And then on like a daily basis, you know you might have, you know, 10 or so who kind of are interacting with the project.

And yeah, I guess that seems pretty crazy in terms of how do you keep on top of version updates for like 20,000 packages.

And I guess the answer has been twofold and I'd like to take credit for at least some of that. One, is just being relentlessly obsessed with automation.

Anything we can automate, we try and automate while at the same time prioritizing the security side of things.

So for example, like John McBride, if you had a GitHub project or whatever and you release some new version and it's packaged in Homebrew, then basically we would have software that would essentially detect that on a very regular basis and then just go, okay, John's releasing more software, make a PR, build it, package it, test it, make sure everything looks fine.

But then we still have a human required to basically look at that, check the results, check the pull request, check the changes, essentially make sure the automation is going well and then merge that through.

So I guess I like to think that we were doing a human in the loop before it was the buzzword du jour.

John McBride: Yeah, honestly, huge mad respect to that because-

Mike: Yeah, thank you.

John McBride: 'Cause like, I mean just the vast amount of software that flows through Brew like pretty insane, you know, the stability and the secure aspect of that. So yeah, mad respect honestly.

Mike: Thanks. The other, I think piece of that, which I feel like doesn't get talked about that much in open-source really is like being pretty aggressive with our like interpersonal boundaries, right?

So I am a member of two simultaneous camps that I don't think are unrelated. One is someone who's actually been continually maintaining the same piece of software on a near daily basis for 15 years. And the second is being somewhat known as like a fairly brusque individual who has very strict interpersonal boundaries when it comes to open-source.

And like for me, like that's how I've been able to not burn out frankly is because I, and I encourage everyone on the project to behave the same way. Like I don't feel like I have to do things, right?

And if people are being very rude or entitled or their behavior is inappropriate when they're dealing with a volunteer or an open-source project like Homebrew, it's like well, essentially you're living off the goodwill of the maintainers who are working on that.

And actually in almost all cases they are just more important than you, right? If they burn out, many more people suffer than if your issue doesn't get responded to or fixed or whatever it may be.

So we've really fostered this culture of like prioritizing the mental health of the maintainers and stuff like that over necessarily trying to implement everything that everyone might want us to implement.

And in some cases that's meant like getting rid of features in Homebrew because lots of people like them but the support burden is just too high.

And that's the nice thing with Workbrew is that now finally like a, when it's actually a day job, you can not just have to rely on personal boundaries but you have an actual team and like contracts and all these nice beautiful things that we have.

Thanks capitalism. And also you have the ability to support people at a higher level, right? Like if you're doing evenings and weekend stuff, right?

If someone's like, Hey, I need help for two weeks building some integration with an MDM provider, like that's a no for me for my evenings and weekends and that's a yes from me on my nine-to-five Monday to Friday, right?

Like I'm more than happy to do that stuff and build something awesome that does what people need.

John McBride: Yeah, amen to that honestly.

I've been on the burnout track for a long time with some of my open source stuff, so yeah, that really resonates.

It's hard to not feel that burden. So it's amazing that you've been able to kind of separate yourself. I'm sure it's been like a big part of that sustainability.

Brian, have you like experienced that before like in some of your open source work?

Mike: Yeah, it's funny how, I can't remember, I mentioned this on recording or before the recording, but like I worked for John at GitHub and then I worked with Mike at GitHub as well and even like with Strap--

Actually the job before GitHub, I remember actually using a sort of carbon copy of what Strap was to get started in our environment.

But so much what Mike says, of what he just said really about maintaining open source, is like what I've also kind of thought through.

AA lot of my open source is like GitHub actions 'cause I happen to be the the face of that for a while, but I'm like totally fine with like never responding to a random issue in action and I just archived like three repos like just last week 'cause I'm like hey story change, like my goals have changed, priorities have changed, I can't support this anymore.

So like clone it, fork it, whatever it's in the ReadMe.

So yeah, it's hard because like there's a lot of folks who have main character energy when it comes to getting involved in open source and like, hey I found this cool thing and it's going to solve all my problems if you spend more time on this, but I've got three kids and I prefer to make myself available to them first, which means I can't-

Mike: Outrageous!

Brian: Yeah, right? I can't imagine like growing a human in this world and like not being on my laptop all the time.

Like that's a, it's crazy but I mean people pick your poison like there everyone's got their opportunities and their things that they want to get accomplished.

So I'm also 38 years old so like I don't have the energy to spend all that time maintaining software that was a cool like fever dream that I had like a few months ago.

Mike: Can I just say I'm delighted to hear that you are archiving repos 'cause fun fact, I actually built that feature. This is, it all gets beautifully connected.

I built that feature while on John's team, not in engineering at GitHub basically just because I was hearing again and again from open-source maintainers, they were like, yeah I'm just like done with this project and basically my options are either I delete it, in which case that feels like the nuclear option or I just get spammed with issues for the rest of eternity.

So yeah, there was some code in GitHub for like migrating repos to GitHub Enterprise or something and I was like yeah, but if you sort of put them in like migration modes and then just never take them out, then that's kind of like archiving, right?

Like we can just make it shut up and then no one could contact you. So it makes me very happy whenever I hear anyone being like, oh yeah, I archived the repo just 'cause I couldn't like handle it anymore.

I'm like, great, you did exactly what I hoped you would do.

John Britton: I think one of my favorite non-obvious sustainability options like that Homebrew employs is the idea of not supporting every feature that people ask for and just saying, you know, this is hard to support so we're not going to make it.

Or you know, kind of leaving the configuration available and telling the user, "This is officially an unsupported configuration. If you try to get support from us for this, we will not support you. But you know, proceed at your own risk, right?"

So if you have a team, and we know of many companies where they effectively take the open source version of Homebrew and they run an internal mirror of it with their own kind of security and compliance functionality baked in that's not officially supported by the open-source project.

And that's like, you know, some of those hooks are there and people can benefit from that stuff. But the maintainers of the project, it's not of their interests to build features that are custom tailored to like one giant corporation that has tons and tons of money for free.

And that also creates a great opportunity for us to come along with Workbrew and say, "Hey, you know, we'll build that stuff for you and we'll turn it into a product."

Brian: Yeah, that's a good point, John.

And I was going to, like, I wanted to ask about Docker in a moment, but actually I know Solomon Hykes co-creator of Docker, I actually sat down with him like a couple years ago and was like, Hey, why did Docker fail?

And this is like a public conversation, it's on the OpenSauced podcast and the thing he cited like immediately and I was like, this is bold, but also great that you realize this is that they, Docker got to the point where they said yes to everything.

And like the challenge of them trying to get profitability and have VC scale but also enterprise ready products, they just had too much bloat and the product and the company and what they were focused on.

And it got to a point where like it just couldn't really sustain itself. So like going back to this conversation around Homebrew, it's like, it is nice to hear that like yeah, there's things that actually we're going to delete eventually.

There's things that probably prolong in Workbrew and not at Homebrew, which I, it sounds like that seems like a very natural progression of like where people can get their questions answered and eventually hopefully pay for it.

But I want to ask the question of like the relation to Docker because like when I think about environments and like setups and now we've felt like these like agent environments where I can now have a runtime for my agent and like in the context of AI, like where does, Homebrew, Workbrew, where does that fit in that world?

Are we replacing Docker eventually?

John Britton: You know, I kind of want to like frame this as a, you know, how developers get their jobs done kind of positioning and why does Docker exist? Why do VMs exist? Why do cloud IDEs exist?

Ultimately what we're trying to do is we're trying to give developers environments to do their work that are repeatable, they're really easy to set up, they're smooth, they're fast, they're inexpensive, they're secure. There's all kinds of things that we want. But for me, one of the most important aspects of this is--Is the environment ergonomic?

And what I mean by ergonomic is like what you were saying before, I have my keyboard, I have my setup, I can use my tools, I can use my IDE, I can use my file system, I can use my network, you know, I don't have to configure various mappings and all this stuff.

And so ultimately all of these different tools, they're trying to solve a problem of like a great developer experience, a great developer environment and they solve them with all different methods, right?

You know, with a VM you have like a full copy of the operating system, a Docker, you have a more lightweight copy but you still have the drawbacks of high number usage, high battery usage, slow, lack of ergonomics, whatever.

With like cloud IDs and stuff like that, it's similar. Maybe there's an additional cost.

You buy a $5,000 MacBook Pro just to like remote into a cloud ID environment and pay Amazon or Google or Microsoft per minute of your developer environment. Like it just doesn't seem economical to do that kind of stuff.

And so, with Workbrew, our take on that is around like developers are already using Brew as part of their environment tool chain.

So how can we level up that tool chain to the point that it's like better for teams, better for collaboration, better for that kind of stuff?

And so I would like try to frame all of this stuff around the idea of, these are all related in the sense of we want to have a great experience, but they're doing it with different methods.

And I know Mike has like a bunch of opinions about this as well.

Mike: Yeah, I mean I would echo what John said but I guess to go back to something you said, Brian, like it's funny 'cause for me I guess Docker didn't fail, right?

Docker hasn't failed. I think Docker is great, but where I would agree is that like yeah Docker became overextended.

Like so the original intent of Docker of being like hey, particularly for servers, right?

The kind of container ship metaphor of you can just have like a fairly stupid host that basically just takes a Docker container, runs it, exposes some ports to the world, spins it up, spins it down, maybe you've got some Kubernetes in the background to go and do like auto scaling, whatever it may be.

Like that for me is wonderful, right? Like and we use that at Workbrew right now. We use Docker files for our deploying our Linux servers and I love that.

I think it's a really perfect fit for that particular job. Where I think things got messy is, and this is often what happens with Unix tools, is when people try to find every single hole that looked vaguely Docker shape and just like smash the Docker whale into the hole.

And the classic one for me was when, you know, when there was that wave of, there's not much of this anymore of like, oh yeah, everyone should go and run their developer environments inside a docker container, right?

And like sure, yeah, you get reproducibility and some other stuff from that but like at what cost, right? If you're someone who could just SSH in and Vim and clean your dark files inside the dock container, yeah it wasn't that bad.

If you're someone who really loves like native macOS-like graphical tools and that way of dealing with things, then yeah the developer experience sucks.

And it's somewhat the same way that if you use kind of some of the kind of cloud development environments, you know, say GitHub code spaces, which I kind of briefly worked on as well, like you know, it solves some problems but fundamentally the experience compared to just doing it on your local Mac is not good.

If you're on Linux, okay, things with Docker are a little bit less painful because you know you're not spinning up a full VM every time but it's still this, you know, you still have the separation issues of essentially spinning up a full OS to go and run somewhere else just so that you can kind of get your libraries versioned the right way for a project.

And it just, I know it just feels gratuitously overkill for me.

At the same time I understand why people do that because sometimes that reproducibility is not easy to find elsewhere and that's why they do it.

I certainly would never claim that we are out to completely replace Docker in every single way in every single circumstance.

Like to me that would be falling prey to the very thing that Docker itself did of realizing what's the right tool for the job.

But I definitely think there's some kind of say local development uses of Docker right now that I look at and I'm like yeah we shouldn't be doing that.

We have better systems and we're all paying... If you've got a Mac, you've paid a decent amount for some shiny piece of Apple silicon, right?

So you probably want to make use of that not by just firing up VMs, not by SSHing to some server that you're paying for by the minute.

John McBride: Yeah, it seems like one of the core kind of tenets of what you're really looking at is that good developer experience.

Something I've been thinking a lot about recently and I dunno maybe I get wax poet about this, but just like the developer experience at large seems kind of like it's converging or just kind of getting, you know, gravitationally all pulled together towards like one or two things.

You know, maybe this is you know, an age old question but do you see things kind of coming together to being like, "Oh, you're probably just going to be on a VS code fork and you're probably just going to use this like one package manager thing, you're probably going to be on a Mac" and like we could just expect that that's going to be what mostly everybody's going to be doing.

And like, "Is that okay? "maybe is the other question about that.

But yeah, do you see that convergence happening in your space like working in developer tooling or is it more like diverse than I'm assuming?

Mike: I think that convergence exists. I think where it gets tricky is again, like almost everything in software, right, is like going from 50% of people are using the same tooling to like 90% of people are using the same tooling.

Yeah, like we're probably seeing more of that. We're probably seeing more people using some sort of VS Code fork than we were previously.

You know, I used to be like a diehard TaskMate guy, like Atom and VS Code are too slow. And eventually I'm just like, yeah, like this is too easy to not do.

And then nowadays I'm a cursor guy 'cause you know, that works well for me but for me stuff like I'm sure you probably have had or will have like the Zed guys on the podcast at some point, but like you know you have things like Zed out there that are doing things in a radically different way.

I still have it and sold my machine 'cause it's just lightning fast for certain tasks.

And I think in some ways we've seen with browsers what happens when you get too much of a monoculture, right? There's problems that come from that.

So my like happy path is basically to be like hey, there's like a paved path for this stuff, right?

If you're a new developer, I feel like we're a lot better now being like do you have an editor of choice already? 'Cause if not it should probably be VS Code. You're probably going to have an easier time.

But like personally I would feel very uncomfortable ever being in a company where I'm like anyone who wants to use Vim, it is you know, forbidden, right?

You shall not use Vim, you shall use VS codes and the Vim plugin or whatever. And if that's not good enough for you then too late. We as an industry have standardized on VS Codes.

I worry about that type of thing and I, 'cause I think it leaves no room for innovation as well and things to get better.

We don't standardize on source forge and subversion 20 years ago, right? And it's probably a good thing that we didn't stay there.

John Britton:

It's a fine line because there's also the aspect of over customization when you sit down at your machine and you have like a million keyboard shortcuts and you sit down at a different computer and you are totally useless, you don't know what to do, you don't know how anything works. That's also got its drawbacks.

But you know, having like a good middle ground where there's like sensible defaults, it's mostly accepted and then the space for people to do things their own way is also quite nice.

John McBride: Yeah, that's an amazing perspective. I've definitely fallen prey to that other side where it's like, man, like I don't, I barely know how to do anything outside of Vim or I'm like, yeah, I got the Moonlander.

I mean it's, I was getting all this wrist pain with a normal keyboard. So you know, Brian, speaking of nice shiny keyboards, check out the Moonlander. Not sponsored.

Brian Douglas: Actually on my list. I'm going to pick up one. You know, I'm getting old.

I'm what a geriatric millennial at this point, so got to protect the wrist. And make sure the fingers and arthritis are not inflamed.

Mike: Dude, I'm older than you and I'm just rocking the standard Apple.

John McBride: Nice.

John Britton: The standard Apple wireless could work, but that's totally on brand for you, Mike. It's like default, just use the macOS defaults, use the Apple defaults, don't do anything special.

Mike: Yep, pretty much.

John McBride: Speaking of Apple defaults, I did ask this to some of the Foxx people when we last chatted with them, but you know, Apple and the Apple ecosystem, it just still just shocks me that they don't have a default package manager in macOS.

You know, maybe that's licensing reasons, maybe that's maintainability reasons.

But you know, from y'all's perspective, do you see a reason that macOS and Apple wouldn't want to do this?

Mike: Well, the Apple old school parent that I am would point out that they technically do have a package manager. It's just really bad.

So every time you install a .PKG file, technically you are using Apple's package manager to install things using package util and they have a big list of things.

It just doesn't support anything like versions or dependencies or anything that you or searching or any of that good stuff.

I dunno, it's funny 'cause again this sort of leads to the conversation from previously I think, where there was, I'm sure at some point there's been a conversation at Apple about like should we make, you know, initially Mac ports, 'cause they supplied a bunch of hosting and all this type of things.

Should we bake this into the us? Should this be a default package manager?

But I kind of think we've ended up in a better place from not having a default because again, it allows people to change in that way and also because the App Store is a wonderful thing, but there's a lot of things that you don't need to do because you're not in the App Store, right?

Like we had a package submit to Homebrew a couple of weeks ago, which was a manager for your porn and we had a discussion as a group and it's like there's nothing not safe for work about the software itself, the packaging process or the website.

It's just designed for a not safe for work thing and it's like Apple on the app store would've probably not allowed that, right?

But we're like, hey this is software, people want to install it. Like it's not malware, it's not doing anything sketchy, right? Like why wouldn't you let people?

And I think this as much as I love Apple, like I think they recognize that internally as well.

There's a certain amount of, if they were to bring one of these open-source projects into the fold and be like this is an Apple thing now, there's a bunch of stuff that those projects do that they probably wouldn't be able to keep doing anymore.

And I think that would be a shame.

Brian: Yeah, it'd be a shame if it wasn't called OnlyBrews as well. That package manage for your files. Sorry, I was sitting on that one.

But speaking of that, I did want to really, before we wind down this conversation, talk about the Workbrew business model 'cause I think with open-source and like Homebrew being a very strong community and open-source project, what's the business model for Workbrew?

Like what's the persona of the folks that are going to be reaching for this?

John Britton: It's a really simple business model. We write software and we sell it. You know, it's pretty straightforward.

Actually like, you know, there's all these different kind of open-source models.

I'm kind of tongue in cheek when I say this, but like, there's all kinds of different models, but like really what we're doing is we're building a separate piece of software that's complimentary to Homebrew and we're charging people money for that software.

So we're not putting functionality into the open source project and pay walling it or anything like that.

All of the existing Homebrew project, it's under MIT license or BSD-2. Mike, am I saying this correctly this time?

Yeah, so it's open source license. You can get it and do whatever you want with it according to the license. And we're doing the same thing.

We're helping our customers install Brew. So we give them, as part of our free plan, the best way to install Brew on tens or hundreds or tens of thousands of Macs.

We give a simple deployment process you can use with like an IT MDM tool. We give them visibility into everything that's going on and then give them a way to manage everything at scale.

And the way that they achieve that is by basically building a control plane. So all of the Workbrew software is how do we connect kind of these individual developer instances to a centralized place to have analytics and visibility and whatnot, management functionality but without really modifying how Brew works.

So it's all about putting a wrapper around how Homebrew works and giving you one package for a larger team or a larger company and then we just charge money for that and customers are willing to pay for it.

Brian: That's awesome. I mean you said it's simple but yeah, it makes sense and definitely appreciate the approach.

This week there was an announcement of FaunaDB shutting down, which is quite unfortunate, users of serverless databases.

And in the threads of folks on X chatting about, it's like someone asked a question years ago of like, what if Fauna shuts down?

What happens to my project? And today you've got 60 days to migrate it.

It sounds like whatever happens to work through in the future, like you could still have an experience that mirrors what's happening in open-source.

John Britton: Yeah, I mean kind of like the underlying architecture of Workbrew is the foundation is Homebrew.

So to the extent that something that our customers need lives in Homebrew, we get it into Homebrew using the normal Homebrew open-source process.

We'll make a pull request, somebody will go and send it and we make sure that it's valuable to every user, you know, as many users as possible if Homebrew.

And then with those kind of underlying functionalities, we can build on top of it. So for example of this, Homebrew has this functionality called taps.

Taps are libraries of collections of packages you can install. And there are two official taps in Homebrew, Homebrew Core and Homebrew Casks with about 15,000 packages.

When Mike was talking earlier about, you know, some human review going into each of these, you know, that's because the Homebrew project manages those taps, but anybody can create a tap.

And so, we built some functionality that lets companies create their own taps and distribute those taps without having to manage authentication, for example.

We also built some functionality around giving a company's visibility into what taps they're in use so they can find out if anybody's using an unofficial Homebrew tap.

Maybe there's some software that they're not happy that is being installed, they can check it out. And they can also split guardrails around the process for adding new taps.

So by default, the Homebrew Core and Homebrew Cast taps are enabled. And if you want to add additional taps that are through parties that might each go through a review process before they get added for everybody in your company.

And so all of that functionality, what's great about is that, is it lives in Homebrew as part of the Homebrew configuration.

You go to the Homebrew Man page, you can read about it, you can use it and you could build your own control plane for that stuff.

We at Workbrew have built a control plane that uses those things and you can buy it instead of build it yourself.

Brian Douglas: Cool. Thanks for the clarification. And at this point I want to wind the conversation down and move us in the Reads.

So a question for John and Mike, are you ready to read?

Mike: Of course.

John Britton: Let's do it.

Brian: Excellent. All right, well, John McBride, you've got some reads you want to walk us through those.

John McBride: Yeah, sure. I got two reads this week. GIMP 3.0 is finally released, which is kind of insane.

I think this thing has been in development like five some years or something.

But this is pretty big, especially for anybody on desktop Linux wanting to modify photos or you know, I'm sure anybody out there who wanted to avoid the belly of the beast doing Adobe Photoshop or something or Adobe Cloud now or whatever it is, has used this.

So more modern design. I'm just excited about it. I don't know, it's going to be great, especially when I reboot up my desktop Linux.

John, Mike, have you guys used GIMP in the past?

Mike: Of course.

John Britton: A little bit, not a ton, but I used to run desktop Linux back in I don't know, college. So ever since I got a Mac I stopped using desktop Linux.

John McBride: Yeah, that's fair. The other one I've been using recently is Pixelmator Pro, which actually was acquired by Apple.

John Britton: Oh, I used that quite a lot.

John McBride: Yeah, they were acquired by Apple, so good for that team. Really excellent piece of software. So yeah, excited to see this space moving forward and yeah, some cool stuff happening.

Brian: I was going to say, my GIMP experience is, my previous avatar in GitHub was like a cartoon of me.

I made that in GIMP in college 'cause my serial cracked Adobe Photoshop that I had back in the day no longer worked. And then I found out that GIMP was a thing.

So earliest version of GIMP, thought I was going to be a graphic designer and I was a heavy user.

John McBride: Interesting. Yeah, yeah, it's a good piece of software. It's one of those that I feel like, yeah, everybody touches at least once in their computing lifetime.

The other read I had this week was very interesting, especially from work I've done in infrastructure and Kubernetes as well as some of the AI stuff and AI engineering.

This piece is titled, "FOSS Infrastructure is Under Attack by AI Companies." And I thought this was especially interesting for John and Mike.

The TLDR of this is that a lot of these companies going and scraping data just across the internet, you know, this isn't new, but it seems at least from what a lot of these FOSS, free and open-source software sites, you know, they're like ignoring robots.txt and just like scraping and scraping and scraping and bringing down infrastructure that is probably just like somebody's home lab in their office.

So nothing that can really sustain a lot of scraping. I'm curious if you all have seen anything like this on, you know, things like getting scraped off of Homebrew taps or even sites that you maintain or Homebrew.org, you know, having anything like this happen.

Curious if you've seen anything like this.

Mike: So this is a nice, another maybe design principle of Homebrew is that Homebrew has no hosting basically anywhere, right? So everything that can be done for free in Homebrew and done on GitHub pages is done there.

The Homebrew, like JSON API is actually hosted on GitHub pages if you want to see using liquid rendering to create a JSON file and watch the parser crying while it does.

So I would recommend checking out the Homebrew site for that. But yeah, so as a result, like we're fairly unaffected by this stuff.

I guess as an anecdote in the other direction, like when our tooling gets flagged for this stuff, then we try and be very communicative with development project and if they're like, "Hey, please don't do this," then we're like, "Okay, well, we won't do this," or we'll change our rates or whatever.

Like yeah, it's, I dunno, it feels like a sad indictment of the modern internet that we've decided to just ignore these types of conventions, right?

John McBride: Yeah, I agree. It's, I don't know, I don't know what the future of this is going to be further down in the post they talk about embellishing robots.txt with ai.robots.txt and starting to build in some like more features.

And like some of the things that people have started doing basically is adding more of these like CAPTCHAs or like more obnoxious and difficult CAPTCHAs, which just kind of makes the internet worst to use as a person, right?

John Britton: That kills the experience for the end user. That's why we can't have nice things on the internet. Basically anytime anything is nice, it gets tragic. It's common people just take, take, take, take until it's not sustainable.

John McBride: Yeah, we'll put this in the show notes. Definitely give this one read.

Brian: Cool. I have a quick read which is kind of related to the GIMP thing. I was looking at X, it was a x.com thread of the Gemma 3 model is now taking out the Shutterstock watermark, which is like, again, going back to my college days, like this is a dream of mine to be like, "Hey, can I use this image for free?"

Folks listening, please pay for your content, please don't steal, but college Brian would've loved this experience.

John McBride: You also have cracked Photoshop. Is that what I heard?

Brian: Yeah, it was dark times. I was in college when scholarship didn't have a lot of money, so you had to yeah, it the wild, wild West. If you think it's bad now back in the day, like, let me show you some BearShare and LimeWire and Torrents.

John McBride: Yeah, this actually reminds me of a story I was listening to. It might have been on Hard Fork, but it was something about how Chegg the cheating website, they're like suing Google because now Google AI results can just give you a bunch of stuff that they scraped off of Chegg essentially, which is like, it's kind of hard to feel bad for them.

Like, okay, Chegg, like maybe that wasn't, I don't know. I say that now, but you know, I'm not deeply familiar with their business model. Is that kind of a similar thing, Brian?

Brian: Yeah, quick correction. I don't think Chegg's business model is specifically cheat on your test in your college work, but that's what people use it for.

John McBride: Okay, my bad, my bad.

Brian: Just saving ourselves from the legal blowback from the Chegg team.

John McBride: So is this Shutterstock thing kind of similar to that where, you know, there's an impending, I don't know, legal suit against, you know, AI use on these things?

Brian: I imagine like we saw with Reddit and also with Twitter slash X, they kind of put a block on like API usage and how much data you can take off the platform to then turn around and be like, no, we have our AI solution for Reddit and Twitter and Stack Overflow and et cetera.

So it makes sense 'cause like in the world of AI, like the data's the most expensive part, or sorry, the most valuable part, rather, and like we're going to have these guardrails and these weird GDPR cookie banners and stuff like that inside of our open-source projects to prevent things like this.

Like, I we're like, we're to be looking at the old times and like thinking very fondly. I don't know, this is a weird therapy session on this podcast, but I remember back in the day, like we'd had cable TV and you get this, I don't know if it was like this in the UK, Mike, but you get the scrambled pay-per-view channels.

So I remember like you can get the audio of like the Royal Rumble like WWE, but you couldn't actually see it. Y ou'd have to get a descrambler.

So then I'd be like on the forums and trying to find out how you can descramble your cable TV.

So again, like we're always going to find a way to work around things, so folks pay for your cable, pay for your whatever your streaming service is.

I'm like implicating myself. I'll need a pardon from Trump pretty soon.

John Britton: The thing that gets me about this is like, again, this is another case where like the end user like loses. So you mentioned the CAPTCHA's being added, API access going away.

Like, you know, I'm a Reddit user, I read a lot of stuff on Reddit and I used like a Reddit mobile app and when they had their whole kind of API change up happening and it took away all that access, all that died.

Luckily, I don't know how the app that I use managed to survive. I think I pay like a dollar on month to use it for just like Reddit's API access or something.

But ultimately what ends up happening is you take away those things and the engineers, you know, people building all these nice little apps like all the moderators, like Mike mentioned in Homebrew, like they automate everything.

These massive communities with hundreds of thousands, if not millions of subscribers on Reddit now lose access to all their moderation tools because they take away the API access to prevent data you know, going to the AI companies.

Like it has knock on effects for everybody.

Brian: Well, I appreciate both of you coming on chatting about Workbrew, Homebrew, open source, and even some banter in the Reads as well.

So, listeners, stay ready