Episode 106
· 47:12
Today's guests are Mike McQuade and John Britton. They met while working together at GitHub. Mike and John are the founders of Workbrew, a start up built to provide the missing enterprise features for managing homebrew. Mike is the project lead and longest serving maintainer of homebrew, applause, the package manager for Mac that almost every one of you will have used. I used it today to install Docker.
Jack Bridger:We get the inside story on homebrew including its London pub origins.
Jack Bridger:I would never have imagined that it began in a pub in London with a random chat.
Mike McQuaid:I mean, I guess the naming and the beer theme might have, led one slightly more to in that direction.
Jack Bridger:We learn what it's been like to work with the biggest company in the world, Apple.
Mike McQuaid:He's based in the Shetland Islands of Scotland. If you look at a map, Shetland is far away, essentially. That's the the the short version. Someone in Apple being like, oh, we have to get this thing here. Like, can it not just go to an office or a bigger city or whatever?
Mike McQuaid:And it's like, like, we can't. Like, if you want this to happen, this is what you need to throw out. Right?
Jack Bridger:We learn how Mike and John think about open source sustainability.
Mike McQuaid:You will find various parts of the Internet that don't like me very much for this viewpoint. But in the end, to me, the the only way you are able to successfully scale that is to say some of these features go away.
Jack Bridger:And how Mike and John are taking these lessons forward
Jack Bridger:to build Workbrew with a very unique approach. Enjoy.
Jack Bridger:Probably everyone listening has used brew, homebrew, to manage their packages on Mac unless they're, like, you know, really hardcore on Linux or Windows. Do you wanna talk a bit about the actual, like, story of homebrew? Because this is a tool that we all use.
John Britton:So I just wanna say something about the hardcore Linux users is that I would say that, like, both Mike and I kind of came to be as hardcore Linux users and ended up in this situation of working on a Mac because of its similarity to Unix operating systems. But there was something huge missing there. And I think that the story of Homer's origin and whatnot that Mike will tell is definitely, like, going to encompass that as well.
Mike McQuaid:Yeah. So, I mean, I guess, as John said, I I almost mentioned this earlier, but, yeah, for me, I realized recently, I think I was a, you know, Linux user for, I don't know, like, 5 or 6 years primarily. And at less than a year after moving from Linux to macOS, I ended up maintaining homebrew. So that's, you know, how I ended up over there. I've my my occasionally, when Linux people give me trouble, I point out I have, like, one commit in the Linux kernel from back in back in the day, like, 2,000 and whatever year it was.
Mike McQuaid:So, yeah, that's my nice little Linux fight back thing that I have.
John Britton:Linux credibility.
Mike McQuaid:Yeah. Exactly. Also, a fun fact, Kombru itself runs on Linux nowadays as well, so we might talk about that later because it's sometimes a little bit confusing why you would want to do that. But, anyway, so, right, we're back in 2009. I'm working in London for a stock called Mendeley.
Mike McQuaid:There's a guy called Max Howell also working in London for another stock called Blast FM. He has irritations with the way package management is currently working on Mac. He's been playing around with Mac ports and thing can come right. There was one other option that, like, leaves my mind right now. And I think he was whining about it in the pub one day, and, basically, someone said to him, hey.
Mike McQuaid:If you hate package management, you know all this stuff so much, why don't you make your own package manager? I think mainly intending him to just show up, but he went off and started work on Homebrew. It was it's interesting. You can kind of go back and look through the Git logs. It's like one of the kind of few examples, I guess, of a big open source projects that was started with kind of driven development.
Mike McQuaid:So the first project commit in Homebrew itself is like a description of how Homebrew is gonna work, and Max wrote all that down before he wrote the codes. And I often think, like, that's a sign when things are gonna be optimized for usability and developer happiness as you think from the outside in. Think, like, how should people be interacting with this rather than just, like, writing code and then being, like, well, they interact with it how I tell them to. Anyway, so he'd been working on this for a little while. He open sourced it.
Mike McQuaid:It started to get picked up by a few more people. I discovered it because I've been trying to I basically, like, built a sort of hack on top of Mac ports to make it make it work in the way I didn't know at the time, but this Homebrew tool worked, like, to use a lot more stuff from the system so it'd be kinda faster to build various tools. I discovered Homebrew. I was like, this is cool and sort of just started getting involved. And, yeah, I guess, like, I think one other non max person had kind of been, like, getting involved as a maintainer at that time.
Mike McQuaid:And, yeah, like, I guess, fast forward 15 years, we've got kind of gone from, you know, a few contributors, a few maintainers to we've got about 30 maintainers. We've got about, I think, 15,000 or something contributors, maybe more than that, and 20,000 packages kind of in our, like, officially supported ecosystem and then probably tens of thousands more than the kind of wider ecosystem.
Jack Bridger:That's that's so cool. I I would never have imagined that it began in a pub in London with a random chat.
Mike McQuaid:I I mean, I guess the naming and the beer theme might have, led one slightly more to in that direction if if you pondered it sufficiently.
Jack Bridger:Yeah. That makes more sense now. Wow. So, Mike, could you just tell me what you just told me about WorkOS? Because we I just told Mike that WorkOS is the sponsor, and this is what Mike said.
Mike McQuaid:Yeah. So WorkOS isn't paying me any money for this. I I pay WorkOS money for this, but WorkOS is, like, one of the best developer tools I've, like, ever used. It's it's the documentation and the experience with building with them is so, so good. Like, I initially was almost like, okay.
Mike McQuaid:This seems expensive. But then, like, it I built an integration with them in about 20 minutes. Though I had spent 2 hours sorry, 2 days banging my head off the wall trying to build it directly with Okta. And then with OS, I then have, like, many, many SSO providers, like, supported instead of just one. So yeah.
Mike McQuaid:Like, for me, work OS is one of the nicest developer experiences I've encountered in the last, like, 5 years probably. And it's so surprising because a bunch of the developer team are execute help and therefore very good at the job.
Jack Bridger:Amazing. Thank you, Mike. And was it a case of, like, build a, and they will come?
Mike McQuaid:I I don't think so. I mean, the funny thing in open source land, back then, we used to talk a lot more about this than we do now when it's you know, there's a bit more of, like, oh, clout, and you should get some GitHub stuff on your resume or CV or whatever. Like, back then, I remember people said a lot of, like, a lot of open source is just scratching your own itch, right, where, essentially, Max had a problem himself that he wanted to solve primarily for himself, and then he was like, okay. Well, I'll put this on. At the time, also quite new, this thing called GitHub.
Mike McQuaid:And I guess that was the other sort of interesting thing, and it's been interesting for me to kind of be on both sides of that is, like, Hubroom is also one of the first software projects, certainly the first package managers, to kinda really lean in heavily on the kind of GitHub way of doing things. Right? So Max from the outset, I guess, he would say that he was being lazy. I guess, you know, maybe he was being lazy, but he's also being smart. The smart the best engineers, in my opinion, are often fairly lazy because he had the attitude of like, hey.
Mike McQuaid:I don't wanna maintain this all myself. I wanna have the community maintain this. And if you want the community to maintain it, you need to make getting involved, contributing, merchant pull request, all this type of stuff, like, as easy as possible. So that was a big focus of his in the early days, and that was, I guess, a big focus of mine increasingly with Homebrew and GitHub and things like that is that, generally, you want to take the behaviors that you want people to do in a developer tool and make them as easy as possible. And if the stuff you don't want people to do, you want to make that either impossible or harder for them to do than the easy thing than the right
Jack Bridger:thing. That makes sense. And what does that, like, functionally kinda look like?
Mike McQuaid:To me in something like ChromeBrew, it looks like I guess it depends on what layer you look at. Right? So part of it is essentially, we we're really trying to optimize the friction of, like, onboarding, I guess, both from a user level and a contributor level and a maintainer level. So for a user, Huburu was, I think, maybe one of the first projects, maybe the first to the the now infamous, like, get bash script and pipe it into curl that some people didn't like very much. And if you don't like that for Homebrew, then you might wanna hear more about Workbrew later.
Mike McQuaid:We'll talk about that. But, I guess, from that perspective, it was like, well, all these a lot of these tools have installers. You have to directly go over having something where you can, like, get installed with, like, a single command, no dependencies, everything gets done for you. Like, that was very heavily optimizing for the user. Similarly for contributors, we try and have the docs, the automation, the tooling, everything like that, such that the the flow is as optimal as possible for that person getting started with the project.
Mike McQuaid:And when we see people bump into the same problem multiple times, we're quite aggressive about jumping on them and really prioritizing fixing that stuff because that's how the project scales, basically. And we have still very, very many more contributors than we have maintainers. And then the last thing for maintainers is similarly doing that for the maintainer approach, and they're making it easy for us to add new maintainers, but also making it easy for maintainers to do their job, trying to automate the absolute living hell out of everything we could possibly can, try to lean into, like, robots, automation, whatever, CI all over the place, linting all over the place to try and essentially just remove the amount of manual work that a human has to do that can be done by a robot or a CI or a GitHub action or whatever it may be.
John Britton:I mean, this is really what makes it possible, for such a relatively small team of volunteers to run a huge part of the infrastructure of Mac development. It's, like, unbelievable to me, like, how, like, small but mighty that group of people is, and they deserve, like, all the accolades and all the support for you know? As a developer myself, I'm a user of Homebrew. I use it every day. I couldn't imagine living without it, and it's just, like, unbelievable that, you know, that's it's possible, to do something like that with such a, you know, small dedicated crew.
Jack Bridger:Yeah. I mean, honestly, it almost feels like I I don't know if I ever really thought about, like, oh, where did Brew come from? It's like such a, like, inherent part of, like, using like, developing with Macs. It's, like, such a did did, like, Apple get involved in it at all?
Mike McQuaid:Not really. Like so they've they've helped us out periodically. So we have contacts at Apple who we can kinda escalate stuff to and help us out there and ask questions all and stuff like that. I guess the most notable case of Apple helping us out, because, obviously, they realized that it was very much in their self interest in that case to do it, was when there was the Apple Silicon transition. You know, pretty much as soon as they announced, like, they were gonna move to Apple Silicon and there was these developer kits and stuff like that, they got in contact with us straight away, and we're basically, hey.
Mike McQuaid:Like, we wanna get a bunch of these kits in the hands of your maintainers, and we also want to, like, get these kits in data centers so you can start building building stuff in CI and automating things and packaging things and integrate that into your workflow, and you're not having to, like, pay out the nose for a lot of this stuff. Even that process was kind of an interesting case of, like, worlds colliding because, you know, it was there was conversation with some of the Apple folks. Some of them knew already. Some of them would go like, okay. So where's the Hubri office?
Mike McQuaid:It's like, there is no Hubri office.
John Britton:Okay. There is no
Mike McQuaid:So what what country are your main terrorists based in? Like, every like, 30 meters. Maybe, like, 20 countries. Right? And I remember, like, one of the folks who was very early with, like, getting a lot of our stuff sorted out, and he's a Workgroup employee nowadays as well.
Mike McQuaid:And, he's based in the Shelton violence of Scotland. So, like, if you look at a map, Shelton is far away, essentially. That's the the the short version. And, yeah, basically, like, someone in Apple being like, oh, like, how like, we have to get this thing here. Like, can it not just go to an office or a bigger city or whatever?
Mike McQuaid:And it's like, no. We can't. The this is like, if you want this to happen, this is what you need to sort out. Right? And and it it did all get sorted out, and it it was all fine.
Mike McQuaid:But it's, yeah, it's definitely an interesting cultural thing. And I think Apple, like, you know, I'm I'm a massive Apple fanboy. I I basically own essentially almost everything they've ever made with the exception of the Apple Vision Pro, and I'll take one if anyone wants to give one to me for free, but
Jack Bridger:anyone's listening.
Mike McQuaid:Bit too expensive, my startup lifestyle right now. But, yeah, but, like, you know, I I think they're great, but they they definitely, like, don't quite get open source. Right? Like, it's there's there's certain teams and individuals in the organization who have that background or relationships or whatever. But, like, organizationally is, like, a high level.
Mike McQuaid:Like, they're not, like, super tuned in on to almost, like, how to partner with a bunch of volunteers with no legal entities scattered around the world.
Jack Bridger:Yeah. It's actually really surprising that they're not just, like, giving bucketloads of money to you guys. I don't know.
John Britton:Well, I
Mike McQuaid:mean, this is this is a lot of the discussions around open source right now, really, where it's like, well, why I'm actually not being too facetious here, hopefully, but, like, why should they? They they don't have to. Like, they they Yeah. Chimbor is operating fine without getting buckets full of money from Apple. And from both parties' perspective, it would be hard to justify going from nothing to buckets without some sort of, like, understanding of what that relationship is, some sort of quid pro quo.
Mike McQuaid:And, you know, that's when you have a volunteer nonprofit scattered around the world and, you know, maybe the world I haven't checked
John Britton:right now. Largest company in the world.
Mike McQuaid:Biggest company in the world. Right? Like, there's there's a an imbalance there. And, you know, also, maybe it's pertinent to maybe the way things are going right now where there's an awful lot of debates in and around open source right now, and I'm maybe one of the old school open source, maybe even free software people where I'm like, well, kind of the point is they don't have to give you anything. Like, no.
Mike McQuaid:I don't feel like any company who uses Homebrew or relies on Homebrew is obliged to give any money to Homebrew. Like, a bunch of them do, and that's great when they do, and we really appreciate that, and it's really useful for us. But I I if the license if we if we demanded that every company of a certain size gave us money, then in my mind, we're not open source software anymore. We're a different thing. We're a proprietary product with a free tier.
Mike McQuaid:Right?
John Britton:My message would be, like, don't try to use open source as a playbook. You know? Build your product, get people to use it. Like, the idea that, you know, open source is a marketing strategy is something I just see, like, way too often.
Jack Bridger:Yeah. Yeah. Yeah.
Mike McQuaid:I I think it's it depends what you're optimizing for. Right? If you're if you're trying to maximize reach, then, yeah, sure. Make it open source. Put it under the most liberal open source license possible, the MIT license or whatever.
Mike McQuaid:Let everyone in the world use it. Right? But then converting those people into paying customers later is not something that you have built your relationship on the back of. Right? And it's it's funny because I guess the open source is not a business model.
Mike McQuaid:Like, in in some ways, I think, like, open source is a short term business model. It's not a long term profit making business model, and it's one that when these companies get bigger and the zero interest rates and investor pressure and all these types of things happen and you get squeezed more, then it's like, well, you know, to what are you able to go back to your, like, whoever, maybe your community, your investors, your customers, your employees, or whatever and say, hey. Well, this open source thing we did, like, turns out changed our mind.
John Britton:That yeah.
Mike McQuaid:I don't have to do that anymore. Like, I'm yeah. And I think John and I share a similarly bad taste in our mouth from places that have done that, where it's not even that they're necessarily doing the wrong thing. It's just, you know, you cause a lot of agro when you do that that you don't and that agro ends up feeling like it is open source's fault, whereas I I think it's the exact opposite of that. It's when you expect open source to be something that it's not.
Jack Bridger:That makes sense. And, yeah, it's like it's it definitely is, like, one of the biggest conversations right now. I think even even, like, the whole WordPress stuff is, like, largely, this kind of, like, whether you should pay things that you're not obligated to, whether you should contribute things that you're not obligated to. And I
John Britton:mean, I think this comes back to, like, looking at the origins and looking at the licensing. You know, for me, it's like we have this internal company value that we talk about all the time, which is don't give what you'll later have to take away. And when you think about open source, like, what you're really doing is if you if you come from, like, the free software background, even it's like the freedoms and the freedom to copy, the freedom to change, the freedom to distribute, you know, all all of those, like, core tenants. It's like, if you're starting from a place where you're telling everybody this is what you're giving them, then, of course, the Internet is going to be mad at you when you change that. Whereas, like, from our perspective, the idea of, you know, building a business around open source is that this is an open source project.
John Britton:It's open to for anybody to do what they want with it. Right? And that doesn't have to change. You can come along and and build a business related to it or try to solve more problems related to the same problem space and not put yourself in the position where your entire business model is, like, hinging on the fact that you need to change something about the way your open source project works. Right?
John Britton:Like, I think I'm not actually familiar with the the situation with WordPress. I've only, like like, read over it, like, very briefly. But there's definitely this case of open source projects where there's, like, a valuable service, and the business model is, like, provide support, or the business model is try to provide a hosted version. And to turn around and say, we're the only people that can provide the hosted version is a big challenge. Right?
John Britton:And that's what a lot of these, like, kinda come down to. It's like, hey. We invested all of this effort into building an open source project, and now we're going to, like, try to retain for ourselves the ability to be the only one to sell it as a as a hosted service. And that just seems very challenging to to operate and to to execute, and it doesn't really jive with the expectations of what people want out of open source. And so, I just think that that's like a flawed logic.
John Britton:I think it's a much better idea to say there's a a huge infrastructure. People make get a lot of value out of out of it as it is. And if there are missing bits, why not go build those bits and sell those additional bits to people that are not that are, you know, kinda complimentary. And that's you know, I think this brings us really easily into the concept of Workbrew and how we're building this is that, you know, it's it's the missing pieces. Mike uses this analogy of, like, the Lego set.
John Britton:If you think about open source and you think about, you know, the code and the available modules as, like, the standard bricks. Right? You can go and build whatever you want with the standard bricks. But when you buy that set, that's the Millennium Falcon. It's got, you know, all these pieces that are super custom to your exact, you know, use case, and those are the bits that we build and sell.
John Britton:Right?
Jack Bridger:You're you've got Chewbacca's.
John Britton:Right. Yeah. Exactly.
Jack Bridger:Yeah. They're they're not the Chewbacca is too specific to, like, your company. You
John Britton:know? Like Mhmm.
Jack Bridger:That makes total sense. And I guess there's, like it's also reassuring in the sense of, like, the open source part. Like, you you couldn't if even if you wanted to do, like, a massive rug pull and be like, hey. Homebrew, no longer open source, like or whatever. Like, we because you you're working on a project that I guess Homebrew is not part of Workbrew.
Jack Bridger:It's something that you're heavily affiliated to, but you're not. You don't own Homebrew. You're, like, building on top of Homebrew as well. Right?
John Britton:Yeah. I think Mike should talk about this, like, in a little more detail.
Mike McQuaid:I mean, for me, this sort of relates to, like, why Workbrew? Why now as well? Because various people over the years, including John, for the last, like, you know
John Britton:10 years.
Mike McQuaid:Maybe more than 10 years have been like, hey. You should go and make, like, a work a homebrew company. Right? And I've been like, nah. That's I don't I don't like that idea.
Mike McQuaid:Right? And I think, like, for for various reasons, but one of those reasons was the fact that HUMBRU was in a place that there was a risk that that would have happened 10 years ago. Right? That, like, if a big injection of VC happened to go into something around, you know, in the Homebrew ecosystem, that you could quite easily capture that project because everything was so nebulous. Right?
Mike McQuaid:Whereas now, Homebrew has its own governance structure. Like, I'm the project leader of Homebrew, as was mentioned, but I am literally elected to that position every year. Right? Like, it it just so happens no one has run against me, and no one has ever been elected to accept me since we've had that position, but that's not a guaranteed thing. And if I were to really annoy everyone involved in the Homebrew community and all the maintainers, like, I would not get reelected.
Mike McQuaid:Right? Like, someone else would run, and they would win, and they would be in charge from Brew, and I would not be. Right? So it's that structure means as well as boring licensing detailed stuff I won't get into. Essentially, it means that homebrew is its own thing.
Mike McQuaid:It's a community owned project, and it will remain that way essentially forever. Right? Work brew may or may not be, like, involved to some degree with Homebrew, like, past, present, future, whatever, but, like, the idea that Workbrew could somehow capture Homebrew and take over is is not possible. Right? It's it's set up in such a way that that is not a tangible option.
Mike McQuaid:In some ways, the model that I actually like the most, and I don't work through anymore, so I'm not obviously being paid to say this, but, like, the relationship Git and GitHub had, I thought was, like I I think that's the when we look at, like, the relationship, like, a big successful company has with a project, like, that's the one that internally we kinda jive with the most because it's like, was GitHub involved with the development of a bunch of features in Git? Sure. Like, did GitHub help the adoption of Git? Like, a 100%. But back in the day when, like, GitLab and Bitbucket and various other kind of relatively mainstream Git hosts were around, like, GitHub was not trying to, like, eliminate the competition or or fork Git or, like, find a way to basically be, like, everyone who uses Git on their own server needs to somehow pay us money.
Mike McQuaid:Right? Like, that was never a thing. But I also think the growth of Git and the growth of GitHub has gone hand in hand. And if you looked back and even just being a Git user, right, there's a bunch of, I guess, maybe because I knew some of the Git people at GitHub. Like, I know there's a bunch of features in modern Git that would not be there had it not been for GitHub employees working full time on building those features.
Mike McQuaid:Right? And and we can say the same thing about WorkBurn Homebrew. Like, in in some ways, the features are less substantial right now. We're still a a baby company. Right?
Mike McQuaid:But there's still stuff in there in Homebrew that you can use today, which was not there and would not be there were it not for the company that we have built in the Homebrew ecosystem. Right? And that's there for all the open source people to use however they want.
Jack Bridger:Yeah. That's actually really cool. And and I really love the, kind of, comparison. I don't think I've ever heard anyone even make the link between Git and GitHub in the sense of, like, like, this is you know, like, people do it with a lot of, like, I don't know. Like, people complain about, like, this project is too tied to this one company.
Jack Bridger:And you never hear that about Git GitHub, which is really cool as well.
Mike McQuaid:If anything, the thing you hear people periodically complaining about on
John Britton:It's the opposite.
Mike McQuaid:Your site is people being like, hey. People can think GitHub and GitHub are the same thing, and they're not, and isn't that bad? Right? Like and it's you know, I I don't think GitHub cares very much about about that, basically, about not being associated one to one with Git because they feel like that's not necessary for them. Right?
Mike McQuaid:They've they've grown a brand which is bigger than Git. Right? And that's you know, I I think the way that both parties handle that relationship is admirable, really.
John Britton:Other other ways to look at that too is that, like, similarities between Git and GitHub and between what we're doing with Workbrew and Homebrew is that, you know, Git is kind of the behind the scenes, like, technical enabler of the product. But, you know, the stuff that really made GitHub successful, it wasn't just about Git. Like, obviously, there was, like, timing with Git and decentralized version control and easy branching and merging all that stuff. But, like, you know, obviously, collaboration and the pull request were the big, you know, the big drivers of the success for them. And I think that it's similar, you know, for us too that it's like, there's this underlying architecture that brew is the best way to get software onto a machine.
John Britton:There's a huge opportunity to do more than, you know, just the the libraries that developers care about. There's a huge opportunity for teams to have shared environments and do things that don't make sense in a single player model and a multiplayer model. And so, you know, we look at that as the opportunity that we have to add a lot of complementary functionality and, you know, build a business on that. Another kinda company that I I really admire in the space of it's not quite open core. Like, GitHub is not open core.
John Britton:Right? Like, it's not they control Git, and that's their thing. It's this complimentary style. And, I'm not sure if you're familiar with the company called Tailscale, but they're a really amazing kind of I wanna call them like a VPN company, but it's not quite a VPN. It's a peer to peer tunneling, like, overlay network tool, but it's built off of this open source project called WireGuard.
John Britton:And, you know, people don't really make the correlation between Tailscale and WireGuard unless they're really nerdy about it. But it's this underlying enabling open source technology that they build kind of a multiplayer peer to peer administration layer on top of, and they run, you know, all these, like, web servers, and they do, like, stun tunneling, and they do, you know, NAT traversals. And they do all this complicated networking stuff that you could do yourself. But, really, there's a huge value in them doing it for you. And what's what's cool about it is it's, like, all of that additional functionality makes WireGuard feel like magic, and that's their product.
John Britton:And it's, like, WireGuard is the underlying enabling technology. And I think that, you know, for us, similarly, Brew is the underlying enabling technology that's really awesome, and we wanna bring a bunch of magic to teams. Right? Bring it to the companies that can say, you know, get your engineers up and running as fast as possible on day 1. Make sure that anybody who makes a change to, the developer environment, it works for everyone, so you're not repeating yourselves over and over again.
John Britton:When something goes out of date, you can patch it really easily. When there's a vulnerability, you can fix it right away. You know about it. You can, you know, remediate. You can look and have an audit history of what's going on.
John Britton:Like, all of this stuff is really, really bal valuable from a business perspective, and it's not something that, you know, the open source community is, like, eager to build. Like, I don't see a lot of, open source engineers in their free time saying, what does this $1,000,000,000 company need to make them successful with my open source project? Let me spend my time working on it for free. Right? So we can build some of those bits and sell it to them.
Mike McQuaid:And, I mean, that was, in some ways, the earliest motivation for for Workbrew, really, was, like, we're we sort of decided on this. We're gonna build a commercial layer around Kombu, before we nailed down the exact ideas. But the exact ideas came from people in the homebrew community, including one grumpy Scotsman who may or may not be a very I don't know. Whatever adjective you wanna use to describe me. Like, I I said no to a lot of these things over the years when people would come from a big company and say my compliance requirements mean that I need to a, b, c, d.
Mike McQuaid:And it would be a nontrivial lift for the homebrew folks. And I'd be like, no. We're not gonna do this. Right? And periodically, I would check-in with the other maintainers and be like, I'm just making sure that, like, no one's super passionate about doing this.
Mike McQuaid:Right? And they're all like, no. Don't wanna do this.
John Britton:How about Homebrew open source project receives a request from very large company to complete your security questionnaire?
Mike McQuaid:Yeah. Exactly. Classic example. Right? But, I mean, I I found this actually, like, at a previous job.
Mike McQuaid:So, like, back when I was a lay guy, I worked on kd, like, the Linux desktop environment. And and one of the things I was really excited about back then is I worked for a company called KDAB who are, like, a consultancy company around QT, the the tech that Katie was born. And I was really excited because they were, like, the the biggest contributor to Katie of any, like, company. Right? So I joined, and I was, oh, I'm gonna have to do all this open source work for free, and it's gonna be sorry, for money, and it's gonna be really exciting and whatever.
Mike McQuaid:And then I learned that, like, a lot of the open source work for money work around this stuff is the stuff that's less fun. Right? Because all the fun jobs, that's the stuff that they don't have any problems getting volunteers in their spare time to make sure that they do this. But, like, a essentially, when you have a spec and you need to regression test the hell up something to make sure that, like, you behave in the same way as some, you know, equivalent software on Windows or a bigger up and sourcing project or whatever, and you wanna just, like, nail that down such that you completely implement every part of the specification. Right?
Mike McQuaid:That's that's not so fun. Right? Like but it is something that is really valuable and important to big companies and that they will pay for people to do. Right? And in some ways, I'm also inspired by that model here, right, where it's previously with those organizations, it wasn't that I was saying, like, we don't that your problem is not a problem.
Mike McQuaid:Right? It's your they did have problems, and they wanted us to solve them, but it's like, we can't solve that for you. Right? Like, we're not the right people. We're not qualified well enough.
Mike McQuaid:And in some cases, when pea even when people would come along and make pull requests to kind of add some of this functionality, some of that functionality, it was like, well, now no one's using it, so it bit rots, and then a year later, someone tries to use it again. It doesn't work because Homebrew doesn't use it. Right? And 99.99% of Homebrew users don't use it. Whereas now, we have a world with Bug Brew with this functionality where it's like we have customers using this stuff every single day.
Mike McQuaid:Right? So if the open source project has an issue there, we jump on it and we fix it within minutes or hours, right, instead of it being, like, a year of this thing just being broken. Right? So, yeah, I I think I think it's a different way of doing this stuff and thinking about this stuff, and I think it's where people are best aligned. Like, we in Workbrew are best aligned to solve these problems for customers, and we do it with some up in source software, some proprietary software, and we do some stuff for free and some stuff for money.
Mike McQuaid:Right? Whereas Workbrew is sorry. Homebrew is best aligned to do what suits the majority of the community to kind of coalesce behind the stuff that works for 99% of people. Right? And if you're in some very niche use case or a point 1 percent or whatever, then it's, you know, it's probably not gonna be as good for you as some, like, work group might be.
John Britton:This is also the convention over configuration or or simple defaults or solving the case for the majority of people. You know, there are a lot of things in Homebrew. You know, I'm not a I'm not a maintainer, but I'm a contributor to Homebrew, and I'm a heavy user. And there are some things in Homebrew that don't work the way I want them to. But kind of the consensus is, like, this is the way it is because we need to make life manageable for the maintainers.
John Britton:If we changed it, the support load or the burden of maintain maintenance would be much higher. So we've optimized for, you know, the homebrew project has optimized some things for maintainers rather than for users in the sense that, like, this always works. It never has a problem. We're never having to support it. And so kind of the the idea of the project, the open source project is kind of the one true way to use the thing that applies to the most people and is the most reliable and the most robust and the easiest to maintain and keep up to date.
John Britton:You know, every time a new macOS version gets released, Homebrew is ready and ready and waiting. Right? Like, that's an impressive an impressive accomplishment for the project. But when it comes to, you know, big companies, something that we we learned at at our time at GitHub was that, you know, a small company of a 100 employees telling a company of a 100000 engineers how to build software is kind of laughable. The idea that the 100 person company knows how a 100000 person company should be running their software teams and that, you know, controls aren't necessary.
John Britton:Right? Like, these these kind of, like, very, I don't know, very basic ideas. Right? And the reality is that those really big companies or or, you know, the companies that have these kind of requirements, they get a lot of value out of the ability to customize things, to have check boxes and have options, and to be able to say, this is the way we work. How can we make this tool, you know, fit our working style rather than having to conform to what's there?
John Britton:And so another thing that we kind of took away from our time at GitHub and what we kind of emphasize with work brew is that, you know, the idea of configurability is kind of a debt that you have to maintain and a burden. And, you know, the open source project is not really willing to do that in in some cases. But for us, that's something that we're willing to sell. We're willing to take the time to maintain to make this thing work for, you know, various sizes of companies with different controls and or security and and compliance requirements and all that kind of stuff, and make that our value add to make it fit your needs. And so I think it's just like a great opportunity to work with a you know, work on an open source project, but also have a for profit model.
John Britton:And it's not really open core. It's not really, like, an open source company. It's more of, like, a complimentary business to an existing open source company or existing open source prod project.
Mike McQuaid:I mean, yes, to me, that comes back in some ways to the title of the the podcast. Right? And this is scaling dev tools. Right? And in some ways, there is the the open source way, and there is the, the business way.
Mike McQuaid:And I think where it gets messy or people get confused is when they try and combine the 2. So there's a lot of talk about sustainability and open source nowadays. Right? And I've been, you know, moderately critical on the Internet and more loudly critical in person at conferences and stuff like that about the idea that, essentially, the way you fix open source sustainability is just throw money at every open source project, and that fixes all the problems. Right?
Mike McQuaid:It doesn't. It doesn't. I've I've seen it in Hubbrew, and I've seen it in many other projects and many other maintainers who are in my inbox, like, trying to figure out how stuff's done. But the way in my experience, the way you fix open source sustainability is by figuring out what sustainability looks like for that particular open source project. Right?
Mike McQuaid:And some of that comes from personal boundaries of the maintainers with each other, with the community, personal boundaries of maintainers in terms of, like, what what are we doing here? What are we trying to build? Right? Are we gonna do the the Jamie Zawinski rule of, like, every all software grows until it has an email client? Right?
Mike McQuaid:Or are we gonna say, no. This is the line beyond which we don't we don't go. We're not interested. That's out of scope. Use this sort of project, whatever it may be.
Mike McQuaid:And that's how you have to do this because in, you know, 10 years ago, Homebrew had probably, like, half the number of maintainers, maybe a third, but we had, like, maybe 1, like, 1 tenth, if not much less than that, of the users. Right? And the way you scale doing that, as John kind of mentioned and alluded to as well, is you do that by falling off the rough edges. Right? And if you have a feature that blows up for users 10% of the time, right, there might be a bunch of used power users who love that feature and it makes their life really happy and their workflows are great.
Mike McQuaid:But, like, if 10% of users we bump into that, even if, like, 0.1% of those users go and complain on our discussions or, like, in the past when we had IRC channels or in our issue tracker or whatever, that gets very, very hard for 30 people to manage. Right? And the only way in the end, like, I've been you know, some you will find various parts of the Internet that don't like me very much for this viewpoint, but in the end, to me, the the only way you are able to successfully scale that is to say some of these features go away. Right? If you want to build a plug in or support your own way of doing things over here, that's fine.
Mike McQuaid:But in the open source project, we do not have the infrastructure to do this stuff. Like, we we can't do it. And if you just gave us more money, there's that doesn't solve the problem either because you end up in this I should probably come up with a better name for it, but, like, this sort of open source sustainability money wise gulf of, like, too much money for stickers, not enough money to pay anyone. Right? Where, like, if you don't have a quite even one person's full time salary coming in reliably, but you've got way too much, like, what what do you do with that?
Mike McQuaid:And how do you use that to somehow magically scale the project so that everyone is able to do more with less or the same amount. Right? But I think on the business side, that's when it gets interesting because you can go and build a business where if you most businesses well, not most businesses, certainly, our business, you start from the outset with a model of looking at being like, well, ultimately, we are going to have to build something and we're going to have to charge people money for a product. In exchange for that product, like, they are going to get a great user experience that they don't otherwise get. Right?
Mike McQuaid:And to me, like, that's another way that you build sustainability, both for open source and for dev tools in general. Like like GitHub as a, you know if you look at GitHub, the offering on GitHub nowadays and how many billions of features they have and CI runners and all those type of thing, you couldn't do that with a bunch of volunteers. Like, you can do that with 30 volunteers working evenings and weekends. Like, maybe their initial offering in 2007 or 8 or whatever it was, you could have done that. You maybe could have sustained that indefinitely with, like, a small number of people just doing things in their best effort.
Mike McQuaid:But you wouldn't scale that to, you know, like, 100 of millions of users for sure. Like, that's all of that stuff requires many, many people being having a level of dedication that is not really compatible with them having a full time job doing something else.
Jack Bridger:Yeah. It may it makes, it makes sense what you're saying there about, like, you know, how you unless you're paying people the full salary, like, money is not really gonna help, like, do that and that you do need a company to go and, like, give those, like, those extra features that maybe not so many people need that cause a lot of problems. And, you know, you're, you're willing to do all the boring, fiddly things that big companies need. And that is not fitting for open source. It makes so much sense.
Jack Bridger:This is very cool. I honestly, like, I hadn't really seen this sort of model or, like, really thought about this maybe. It's probably the right way. I'd seen it, I guess, but not thought about it. It's very cool.
Jack Bridger:And it seems like you're not gonna have to worry about really any of the kind of issues that a lot of open source companies have with, like monetizing, the the project. It's very cool. And I we're kind of running out of time, but I just wanted to ask, like, who who are you, like, kinda selling to? It's like IT departments or how
John Britton:Yeah. So there there are really 3, you know, types of people that are interested in in work brew. Obviously, 1st and foremost, it's a developer. Homebrew is incredibly popular with developers on Macs. And at the minimum, there are developers out there that work at companies where they have security and compliance requirements that prevent them from using Homebrew.
John Britton:You know, imagine trying to do your work without access to Homebrew, how much less productive you would be. So, really, one of the core, you know, values that we provide is just the ability for engineers that work in companies with these security and compliance requirements to have access to the tools that they already know and love and use. In addition for engineers, we aim to, you know, make the collaborative development process better, help them get up and running faster, and really make it so that it's a treat your local developer developer environment like its infrastructure. And the idea being that, you know, I have worked in VMs. I've worked in Docker containers.
John Britton:I've worked in cloud IDEs, and they all have a trade off in that you get consistency, speed of startup, all those types of things in exchange for worse ergonomics. I love working on my local machine with my local editor, on my local file system, with my local network, with all the things that are ergonomic and the way that I like them. And anytime I introduce a Docker or VM or a cloud ID or anything like that, either my workflow, it drains me. It makes me less productive. In addition, all of those options cost more.
John Britton:They're either you're paying for VMs, you're using more battery life, using more processor, you're doing whatever. You have these really amazing Apple Silicon devices that you're paying $5,000 a pop for, and then you're shelling out into a cloud environment. Like, what are what are we even doing? Right? It doesn't make any sense.
John Britton:So that's the story for the developers. It's like, have access and have really great ergonomics. The next big category of people is the IT managers. So these are the folks who, in your company, they're responsible for issuing you a laptop and making sure that you're up and running. And for engineers, oftentimes these people, you don't need to interact with them that much because you can self serve.
John Britton:You can fix your own problems. I remember the IT department at GitHub was amazing. The people on that team, you know, were there to support you when you needed them. They helped you with the inventory situation. They helped you with getting access to things.
John Britton:But at the end of the day, like, we had the situation where we had a lot of talented engineers who knew what they were doing. So it was kind of a situation where they had a lot of trust and there was kind of a backup team to make sure things that were necessary got done. And so as IT managers, we wanna give them away to lighten their workload and be able to get Brew into the hands of their team in a reliable, repeatable, really easy way. And then once it's out there, know what's going on. Have visibility into how are people using this thing.
John Britton:Do I need to be worried that they're installing some software that could have a supply chain to hack or or things like that? And then the last kinda category of people that were, you know, trying to serve are security professionals, whether it's a CSO or, you know, kinda somebody who's on the AppSec side, but they're they're interested in making sure their company is secure. We're building a bunch of of functionality around making sure that you can meet your compliance standards. So, you know, there's SOC 2, there's ISO 27,001, there's, you know, all the different kind of credit card compliant. Like, there's there's all different industries have their compliance standards, and inevitably, they intersect with the way people are using Groove.
John Britton:Whether it means, you know, the people on their devices are using admin accounts rather than the standard users, and what what's entailed with that, and how Blue interacts with that. Or if it's about what pieces of software are being integrated into their workflows. So, you know, we're serving those people by saying, hey. Look. You can get a high level overview of everything that's happening.
John Britton:You can get alerts about when there are vulnerabilities. You can respond to those vulnerabilities. You can set policies and guidelines to make sure that the usage of these tools are contained. One of the really powerful features of Homebrew is that it's not tied to one library of packages. They're the official packages in Homebrew core and Homebrew Cask, but you can actually add a third party library called a TAP and install any software with Homebrew.
John Britton:You can create your own TAPs. You can use TAPs by by third party vendors. And that represents, for security folks, a really, really big issue. They're like, oh, my god. Literally, anything could be installed in the machines.
John Britton:I have no idea about it. And so, you know, for them, we're making it so you can see. Are people using third party libraries, third party taps? Which which ones are they using? Do you have a control policy that you need to implement?
John Britton:So there's all kinds of stuff around there that's really valuable. And so, you know, those are the people we're trying to serve. And I think that kind of the last thing I'll say about this is kind of the business model and, like, how we're trying to sell this. So we have pretty much, 22 stories. 1 is there's a free version, and 1 there's a paid version.
John Britton:So Workbrew is available for free for unlimited users, unlimited devices. It's the best way to install Brew on a fleet. Whether you have 10 or 10000 devices, you can go to work Brew. You can install Brew on every device, have it be consistent, get it ready up and running in minutes, and have full visibility into everything that's being done on there. This is kind of like table stakes for any company that's doing any kind of SOC 2 compliance or any kind of, you know, good security practices, and we made that totally free.
John Britton:Then beyond that, if you wanna add, you know, security controls or if you wanna add remote management or if you wanna have any kind of interaction around automation and default packages and kind of environment set up, then we have a paid paid plan that you can get additional features from. But it's really targeted at those those three use cases.
Jack Bridger:Very cool. Very cool. Kind of reminds me of, like, sneak in the sense of, like, the kind of model that Mhmm.
John Britton:I don't
Jack Bridger:know if you've thought about it that way, but, like, I can totally imagine, like I've I've had to use, sneak, at work because we went through SOC 2 compliance, and it was like, just like my manager loves it because, you know, you can just everything is, like, you know, compliant, fits in with banter and stuff like that. And then for me, it was, like, gem generally good because, you know, a lot of the time you just press a button, upgrade and stuff rather than, like, solving it yourself. Mhmm. But, yeah, that's very cool. It's very, very exciting.
Jack Bridger:Yeah. And thank you so much for sharing the journey. And, yeah. And thanks, thanks, Mike, for helping us download all the stuff we need onto our Macs. So, yeah, thank you, John and Mike, and thanks everyone for listening.
Jack Bridger:So workbrew.com if people wanna learn more.
John Britton:Yep. Check out workbrew.com, and, you know, thank you so much for having us on the podcast. We're really grateful to be here and have this conversation. You know, look forward to coming back at some point in the future and giving an update. Amazing.
Mike McQuaid:Yep. Thanks, Chuck, and thanks everyone for listening.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.
