Riding the Homebrew Wave

28 May 2024

Interviewed by Open Source Startup Podcast

John Britton & Mike McQuaid are Co-Founders of Workbrew, the company that provides additional features and support for companies using Homebrew. Homebrew’s main project, brew, is a wildly popular open source project with 40K GitHub stars and provides the missing package manager for macOS (or Linux). In this episode, we dig into John & Mike’s history with Homebrew and their time together at GitHub, how Homebrew has kept projects simple over time and avoided feature creep, how Homebrew has managed to get a lot of value from contributors, how their ICP has shifted from mac admins to dev and security teams & more!

Show transcript

0:00 Welcome back to the Open Source Startup Podcast. I'm Robbie, one of your co-hosts and joined
0:09 as always by Tim Chen, my awesome co-host from Essence VC. And today we are super excited
0:15 to not have one but two guests with us. We have John and Mike here who are the co-founders
0:20 of Workbrew, which is a company that provides missing features and support for companies
0:24 using Homebrew. And I'm sure many folks in our audience are going to know what Homebrew
0:29 is. It's a very, very widely adopted package manager, but we're thrilled to have them on
0:34 and hear about the Homebrew and Workbrew story. So welcome, Mike. Welcome, John.
0:37 Thanks for having us.
0:38 Awesome. So Mike, we're going to start with you and go all the way back to the founding and
0:43 creation of Homebrew. So why don't you talk to us a bit about where that idea for a project
0:48 Yeah. So I think Homebrew started kind of early-ish 2009. There was a guy called Max Howell working
0:56 for Last.fm. It's a nice blast from the past reference. I don't know how many Last.fm users
1:01 there are out there anymore. So he was working Last.fm doing kind of package management stuff
1:06 on Mac, played around with various tools, wasn't really happy with any of them. And yeah, he
1:11 decided one night to kind of just try and build his own thing. So he kind of wrote a sort of
1:17 manifesto. I think the first commit to the repo was like the readme about like what he was
1:22 making and why he was making it and what the idea was behind it. And then he just started
1:27 kind of building away by himself on GitHub. One of the, I guess, the interesting early
1:31 approaches that Homebrew did that was a little bit different was most package managers were
1:35 like, you know, get a bunch of people together and we'll kind of split up and divide the
1:39 responsibility. Cause you know, this is like maybe two years after GitHub was founded and
1:44 Max was a GitHub user. So he was like, okay, well let's get the community to get involved
1:48 from day one. Right. So I can be a bit more his words, but we don't mind lazy about having
1:53 to do everything himself. So maybe like six months later, I I'd been kind of dabbling
1:58 around with my own package management problems and kind of hacked some stuff around with existing
2:05 stuff. And I couldn't really equally find anything that worked the way I wanted it to.
2:08 And I heard about this Homebrew thing, like Max was a friend of friends in London where I
2:13 was working at the time as well for another startup over there. And yeah, I basically just
2:17 started kind of adding some stuff to Homebrew and just never really stopped. And yeah,
2:22 the project's kind of grown over that time. I guess I was the third person to kind of get
2:26 involved as a maintainer. I'm the only one left of that kind of early crew. And yeah,
2:31 we've now got like 30 maintainers and many thousands of packages and thousands of contributors
2:37 and all that good stuff.
2:38 Yeah. That's amazing. I think Max was actually on our podcast before talking about tea.
2:42 So we definitely had our own fun talking about Homebrew. So you joined a little later as
2:48 contributor and now become a maintainer, right?
2:51 I don't think people understand what is maintaining a package manager really feels like. What do
2:56 you do? Because I'm actually, I'm personally curious, like, what do you do that much these
3:00 days? Because there's going to be the packages and a bunch of vendors or users contributing
3:05 side. And there's also the core system side, right? Like, what do you spend most of your time on these
3:10 days to maintain Homebrew?
3:11 Yeah. I mean, me personally, nowadays, I mainly spend my time on the code side, I guess, on
3:17 everything except the packages themselves. Like I get pulled in sometimes when there's some
3:22 something contentious or whatever. But day to day, like most of the packaging stuff gets handled by
3:26 other people. In my earlier days, I did a bit of everything. And it's kind of, if anyone's interested
3:31 in getting involved with a package manager, the fun thing about it is you can go from writing like
3:35 a couple of lines of C++ to a couple lines of Haskell to a couple lines of Go, like all within a few
3:39 hours of each other, because you're just having to kind of dip your toe into many different pools.
3:43 But yeah, but for me, like nowadays, a lot of it is just code review and investigating kind of what
3:50 the other maintainers, what some kind of new contributors or whoever are wanting to do in
3:54 Homebrew, any new bugs in Homebrew, like triaging those, like trying to figure out what do we want to
4:00 be building in the next one, six, 12 months, and then like talking with a bunch of the maintainers
4:04 in Slack. I guess I feel like I sort of wear that out of, if Homebrew was a company,
4:09 which is not of like sort of a combo between CEO, CTO, head of product, and security guards.
4:17 And so, you know, whenever we're looking at a very widely adopted popular open source projects,
4:23 I'm always curious, like now we can look back why Homebrew is actually that popular, right?
4:28 You know, back in the day, I probably have no clue. But in your opinion, what made Homebrew
4:33 the default thing? Because there's a Mac force before, there are some other things happen,
4:37 come here and goes, but Homebrew definitely is the one that stays. And everybody has no mistake now,
4:42 brew install is by default there, which is truly amazing. It's not an Apple thing at all, right?
4:48 This is pretty much a community contributed project that made it become like the standard.
4:52 What do you think is like the secret of Homebrew or things that got right that made it become
4:58 the default thing?
4:59 Yeah, I mean, that's a great question. I think, as you say, like this stuff is often
5:03 more obvious in hindsight, I think, than it was at the time. So one big thing, I think I sort of
5:10 alluded to a little bit before, which was like going all in on GitHub. And we've still continued to do
5:14 that to this day. We use a lot of GitHub infrastructure. You know, John and I used to
5:18 work there. Like it's definitely something where even if I didn't work there and before I worked
5:23 there, I was still very much like, okay, like it makes sense to kind of do this. And I guess really
5:27 leading into the idea of, which was very innovative in 2009, seems less so now, but the idea that
5:33 the best way of maintaining something at really high scale is not to have a small number of people
5:40 doing a lot of work, but an awful lot of people doing small amounts of work and that things work
5:45 well. That way you can kind of fan things out and have a contribution model. And the maintainers are
5:50 operating more like kind of shepherds than the people who are expected to do the bulk of work by
5:55 themselves. And I think the other thing is just like usability. I think there's, you know, Mac ports,
6:01 and I don't want to talk ill of the other projects, but I think I definitely feel like with Homebrew,
6:08 it has always tried to embody that Apple ethos of trying to be really, really usable and try to
6:15 really care about what the interface looks like. Don't support things if you can't support them well,
6:20 make error messages really clear for people, make it really clear what needs to be done if rather than
6:26 telling a user to do something, if you can just do it for them automatically, sensible defaults, like
6:31 all this type of stuff. I think like that's what has contributed most to Homebrew success. And in many
6:37 of those cases, those changes to get things more usable or a little bit nicer or trimming down options
6:43 have been, there's been a vocal minority who've been very unhappy about them along the way. But I
6:47 actually think like, that's partly why it's been successful is being willing to embrace usability over
6:52 necessarily making the maybe very loud power users sometimes the happiest.
6:57 Yeah, I think adding on to the like choosing to do a lot of things, you know, fully embrace GitHub.
7:01 Also, Homebrew is a project, I'm a contributor, you know, I've been using Homebrew since the very early
7:06 days. And whenever something I don't like doesn't work correctly, or there's not a package that I need,
7:11 the ease of contributing is just like, so, so easy. And the way that the project is managed,
7:17 as a newcomer to the project, getting up to speed, everything is super well documented,
7:22 there's kind of guardrails in place that are automated, things like telling you that you're
7:27 doing something wrong, and enforcing a rule is done by a bot rather than by a human, right? So the
7:31 human comes along and tells you, hey, let me help you out. But the bot saying, sorry, you can't do it
7:35 that way, figure out a new way. And I just think from a contribution perspective, the project,
7:39 the fact that it's like formula are written, you know, the packages are written in like a DSL,
7:43 it's really easy to understand, it just makes it way more approachable than, you know, other really
7:48 complicated projects.
7:49 And it's amazing that the project's been around for so long, and still has that usability, because
7:54 usually over time, things complicate themselves. And it's hard to remain, you know, simple and very
8:00 user friendly. I'm curious, so this is a question for either or both of you, the project's been around for
8:06 so long. Company is quite new. Why start Workbrew when you did? Like, what were kind of the signals
8:12 that said, okay, like now is when we should start this company?
8:14 So I think that the first time we had an idea for doing something like this was back in like 2012.
8:20 So Mike and I worked together at GitHub for a number of years. And I always said, like, you know,
8:27 Homebrew is a great project. I think there's a really big opportunity here. But just the timing
8:30 wasn't right among the people who were involved. You know, we were working at GitHub during a really
8:35 high growth phase, doing a lot of really interesting stuff. And in 2019, after I left the company,
8:40 I knew I wanted to be an entrepreneur and start a new company and had been working. And as soon
8:46 as I left, I kind of reached out to Mike and was like, hey, Mike, you should come join me and we
8:50 should start a company together. And that took a few years, but eventually it came through to him.
8:53 He decided, you know, to leave GitHub. And when we started working together, we weren't actually
8:58 working on Workbrew. And we had this really, like, very pivotal conversation where Mike said to me,
9:05 he's like, you know, we should really be focused on things that we're good at and play to our
9:08 strengths. And I just reminded him, I said, you know, we could always do, you know, features for
9:13 Homebrew for this open source project for the enterprise, like we should work on that. And that's
9:17 when we decided to start. So that wasn't all that long ago, but it's been an idea kind of in the back
9:21 of our minds for a very long time. And I think that the other story that relates to our experience,
9:28 both having worked at GitHub in the past and kind of what we're doing with Workbrew is there was an
9:33 internal kind of meme at GitHub called Remember Chatboxes. And it's basically this idea that over
9:40 time, software gets more complicated. People ask for more features. And you kind of alluded to this
9:44 with Homebrew being really simple and easy to use. And that's because in Homebrew world, they're
9:48 really, really focused on the most common standard experience, making sure that people have a really
9:53 good out-of-the-box experience. But when it comes to enterprise software, it's not our job to tell a
9:58 big company with 20,000, 100,000 employees how they should run their development and run their stuff.
10:03 And they need checkboxes. They need customization. They need different kinds of compliance, all kinds of
10:08 features like that. And so it kind of like fits really well in saying like, yeah, there's this thing out
10:13 there. Everybody loves it. But there are some situations where big companies need something a
10:18 little more customized, a little more flexible for them. And that's where we come in with the
10:22 business. You know, that's the fun thing about starting a company is that I think John was
10:26 convinced this was a good idea, as he said, back from 2012. Like, whereas I wasn't convinced this
10:31 was a good idea, even when he eventually said that. And then I went and had dinner with my kids.
10:36 And I was like, the only reason that convinced me it was a good idea is I was like, yeah, we should be
10:39 playing to our strengths. And I was like, yeah. I mean, based on what I said to John,
10:43 if I actually believe what I said, he's completely right. Right. But even if, you know, before I came
10:49 and joined him, he was like, hey, Mike, let's go and do the homebrew. It's almost, it's the funny
10:53 thing that like, sometimes you have to be like in the right place to like hear that stuff. And I think
10:58 also for me, it was the, I guess I always wanted homebrew to be in the right place as well. Like
11:03 there was some kind of minor controversy a few years ago about people feeling like I had too much power
11:08 in the project. And I was maybe approaching sort of BFDL sort of status and that. And then now we have
11:14 like a kind of governance model and leadership committee and elections and all this type of
11:19 stuff. And I feel much more comfortable kind of starting a company around homebrew now than I did
11:24 before, because, you know, even if I decided tomorrow, like my evil master plan is to somehow try and
11:30 take homebrew away and make everyone pay for homebrew. I don't have the power to do that,
11:35 you know? And there was a point where I maybe did. And in some ways like that kind of scared me a bit
11:40 because like I, it would make some things easier, but it would make the homebrew project much more
11:45 at risk. And I guess we've seen a lot of stuff with open source recently where you have had that more,
11:50 I guess, blurred line between the commercial organization and the open source project. And there's been a few
11:56 stories in the news recently about maybe the community, not always being terribly happy about how that
12:00 ends up. Yeah. Just given the nature of the project, you are very, I guess, dependent and also you want
12:06 to almost mass contribution to your project. So I think there's definitely sensitivity when it comes
12:12 to like, hey, here's a company behind it, right? But I guess you're not even saying this is behind it.
12:16 This is almost like a company that's working primarily with it, right? That's probably almost
12:22 like one way to kind of key it. I think that's really an interesting perspective to take is it's not
12:26 that we're behind it. I mean, we fully support homebrew and want to do everything we can
12:30 to make the project better for everybody that uses it. But I like to think of it as we're
12:34 complimentary to the project. All of these situations with like other companies doing
12:37 open source and then you see like maybe they change their open source licensing or they like
12:42 none of that stuff is possible in our situation. And we have no interest in that, but we sell
12:46 a product. You know, we make enterprise software and we sell it for money and it's complimentary
12:51 to homebrew. It's not part of homebrew. It's not a fork of homebrew. All of our customers use the
12:56 exact same open source homebrew that everybody else does. And if we have something that needs to get
13:00 support in homebrew, you know, we make an open source contribution to homebrew and it will get
13:04 accepted if it's something that's beneficial to the entire community. Right. And so that's,
13:08 it's really like a complimentary situation rather than a fork or any, any other kind of model.
13:13 Yeah. So there was a nice example in the last week, in fact, where there was some stuff where
13:17 like some parts of homebrew that workbrew relies on more heavily than your typical user might.
13:23 And some stuff was really slow and that was really annoying me. So I made it like, you know,
13:28 like 50 times faster because it was annoying me how slow it was. But the thing is, is that's
13:33 something where everyone who uses homebrew now, who uses that command and that flow can benefit from
13:39 that thing being 50 times faster. And so I think there's this nice kind of symbiotic relationship
13:44 where as workbrew gets better and as workbrew has to make homebrew better for our own benefit,
13:49 then it also makes homebrew better for everyone. And in some ways, again, I feel like I kind of got
13:54 good practice at this at GitHub, where there was times where, you know, homebrew was very widely
13:59 used inside of GitHub right from the very early days and homebrew relied very heavily on GitHub itself.
14:04 So there was this nice kind of balance where there's a few API calls in the GitHub API and
14:09 features on GitHub that were added primarily for homebrew and are now used by many other places.
14:14 But then also vice versa, there's various times where like GitHub was migrating to rely on homebrew
14:20 more heavily. And I would spend a bit of my time at work kind of making homebrew kind of work better
14:26 in a way that worked for GitHub, but then worked for other places. So I don't know. I feel like
14:29 there's always a little bit of this kind of balancing act that you have to be kind of careful,
14:33 but I feel like I'm used to that by now from kind of having that had this split for a fairly while.
14:39 So I want to talk a bit about who workbrew is built for and how you made that decision,
14:43 because I imagine just with the number of homebrew users, there are different product
14:47 directions you could go into. And it sounds like you landed on enterprise, but even the
14:51 definition of enterprise is kind of all over the place these days. So how did you determine who the
14:56 user was going to be for workbrew? And like, what was kind of the iteration process? Like,
15:02 was it always kind of the direction you're on now? Or did you try a few different things?
15:05 We did a lot of research. We looked at all kinds of issues in the homebrew issue tracker. We talked to
15:09 people, we looked for problems. And one of the problems that came up over and over again was
15:15 homebrew is widely used. And it's often used in companies where they're engineers on Macs,
15:21 and they use it for their developer environments. They use it for consistent setup process,
15:26 getting people onboarded more quickly. There's a lot of different use cases why companies are using
15:29 homebrew. But as you add more endpoints, more end user devices into the system, the problem becomes
15:36 more multifaceted and there are more considerations. And so what we found was that in environments where
15:43 there's maybe a dozen or so Macs with homebrew, it's pretty easy to just manage that individually.
15:48 But in environments where you have hundreds to thousands or tens of thousands of devices,
15:53 sure, each end user can manage those things. But those types of organizations are often regulated.
15:58 They might have security requirements, you know, have to be compliant with like SOC 2 or ISO.
16:03 They might have additional kind of regulation around the type of industry they're in, whether it's
16:08 healthcare or financial. And they might have some kind of restrictions on the way that end users
16:14 can use their devices. And so we found that the people who are responsible for solving those problems
16:19 tend to be IT managers. You know, people who are in the IT department who often will be dealing with
16:25 things like MDM tooling or other kind of on-device security detection, things like that.
16:31 And so when we set out to build Workbrew, we really set out to try to solve some of their problems.
16:36 And we talked about this a little bit before the recording, but the idea of there's kind of like
16:41 deployment, getting Homebrew onto the devices. There's like analytics and management, and then there's also
16:46 like a security component to this. And so the main kind of key person in that whole situation is the
16:52 IT manager. They're the ones who kind of like choose the tool, deploy the tool into production,
16:56 are responsible for running it. And they have stakeholders in both engineering and the security
17:00 departments. So that's how we kind of got to this customer profile. But I think that over time,
17:07 like you were saying, there are a lot of different paths we could go with a lot of, you know,
17:10 different values we can add for the different kind of personas. It's just that this IT management
17:17 situation is very, very urgent for people. It's something we hear over and over again. There's no
17:21 solution on the market for them right now. And what it means is that big companies, you know,
17:26 like Fortune 500 companies are out there building their own tooling that's in the direction of what we're
17:31 building at Workbrew, but it's far inferior. They don't have the staff to maintain it. And it
17:37 doesn't have the same kind of synergy with the Homebrew open source project where we can
17:42 lean on all the experience that Mike has from being a maintainer and a contributor for such a long time.
17:46 So that's how we ended up where we are now.
17:48 So I'm curious because Homebrew, given it's like a 2009 project, I know it's been maintained over time,
17:53 but definitely has like a long history at this point. Now you're trying to build a product around it.
17:59 I would imagine it may not be the easiest thing on earth. You can just stick one project, you know,
18:05 controls our Homebrew. So let me talk about what does the product do today? And then very curious
18:11 about what kind of things you have to do to make sure a product can work on top of Homebrew. Because
18:15 that doesn't seem like the most obvious thing right now. Did you have to fork Homebrew, for example?
18:21 Or did you have to do some kind of crazy modifications to it to be able to support anything? Like,
18:25 maybe talk about some of that. Yeah.
18:26 I think that like a good way to answer this is just to kind of talk about the architecture
18:30 of Workbrew and like how it actually works. We talked a little bit before about the idea of
18:34 it being complimentary to Homebrew. So what we've built is essentially a control center. You know,
18:40 I hear this phrasing all the time from people when I'm talking to them about, you know,
18:43 the problems they're facing with Homebrew. And they say they're trying to get their hands around
18:46 Homebrew at their organization. What does that mean? That means they have no idea who has it installed.
18:50 They have no idea what packages are installed on their machines. They have no idea what's out of
18:54 date. What might be a security vulnerability? Are they compliant with the certifications that they
18:58 need? That's kind of the idea of like, I need to get my hands around this. And so what we've built is
19:03 effectively an installer, a way to deploy Homebrew at scale zero touch. So if you're in an organization
19:10 where you use something like Apple Business Manager and an MDM tool, you can now take a brand new Mac out of
19:15 the box, turn it on for the first time. When it connects to the network, it will have Workbrew installed,
19:19 right? Then kind of the next thing is analytics and, you know, observability, knowing what's
19:26 installed across your fleet, having some kind of way to make sure that that's within, you know,
19:31 whatever your operating guidelines are. And then getting alerts around security vulnerabilities. We had
19:36 just a couple of weeks ago, a month ago, the XZ vulnerability. We had tons of people reach out
19:41 to us and say, we've got 10,000 Macs with Homebrew installed. How do I make sure that XZ is up to
19:45 date on all of those machines? So this is definitely a problem that's related to a wide scale issue.
19:51 So anyways, we have this kind of installer that makes the deployment much easier.
19:55 The next thing is kind of an agent. The installer puts this on the machine,
19:59 lets your machine kind of check in with Workbrew and provide, you know, diagnostics, analytics,
20:04 but it also provides for the IT manager to help keep your machine up to date. Install packages
20:10 that might be important for a team so they have an environment ready to go on day one. And then
20:14 lastly, there's the console, which is kind of a dashboard where you can log in, view your entire
20:18 fleet, manage it in groups and things like that. But what's interesting, you asked, is this a fork
20:23 of Homebrew? And like, that's decidedly no, right? We are not a fork of Homebrew. You're using exactly the
20:29 same open source project as everyone else. And another question I get a lot is, what if we have
20:33 a fleet, you know, we have 10,000 devices with Homebrew already installed and each of those people
20:37 has a bunch of packages installed and we want to get Workbrew, what happens to those existing
20:41 Homebrew installations? Well, because they're literally the exact same Homebrew that we use,
20:45 upgrading is effectively installing Workbrew, flipping a couple of bits here and there, and then you're
20:51 able to keep all the packages you have on your machine installed, use the existing Homebrew
20:55 installation, but get all of the kind of enterprise like fleet level features right away.
21:00 When you talk about the product value for Workbrew really being around scale and around enterprise
21:05 use cases, so that's going to be applicable to some parts of the Homebrew community, not all.
21:11 How do you think about or how have you gone to market alongside Homebrew? Like, do you
21:16 leverage the community or like message to the community? Do you do independent product marketing?
21:21 Like, how do you kind of grow with the community and let folks know that there's kind of another
21:26 option here if they want to manage at scale? Like, how does that go to market work?
21:29 I mean, John talked earlier about the, I guess our initial persona we're going off to as the kind
21:34 of Mac admin, but definitely in the longer term, we're also looking at engineers and security teams
21:39 and stuff like that as well. And we've kind of had the principle for this stuff that any feature or
21:44 functionality we add in Workbrew makes life better for at least one of those three demographics,
21:50 and does not make life worse for any of the demographics. So I love the questions you had,
21:54 Tim, about, you know, are you running a forked version of Homebrew or do we need some crazy
21:58 modifications or whatever? And the nice thing about that is that using Workbrew feels exactly the same
22:04 as using Homebrew, essentially. There is some stuff going on under the hood that means it's actually,
22:09 even if you're just using it on your machine, it's a lot more secure than Homebrew. There's a much
22:14 smaller attack surface and much kind of better separation and stuff like that. And the performance
22:19 basically feels exactly the same. But yeah, we have ideas in the future, I guess, partly based on my
22:25 experiences of maintaining Homebrew, but also kind of working in many teams across places like GitHub of
22:30 Homebrew works really well as John used to talk about, like single player and multiplayer. So Homebrew works
22:36 really well as a single player tool. If you're just installing stuff in your machine and you pull
22:40 down a version of a package and you want to upgrade it or whatever, then that works fine. But as soon
22:45 as you start to work on developer teams of, you know, maybe even five to ten people, let alone a kind of
22:50 developer orgs of 100, 1000, 10,000 people, you know, you get everyone to install something using
22:55 Homebrew and run a command. And it turns out those people now have, because they installed at different
23:01 times, five different versions of the thing installed. And when they run the command, they will get five
23:06 different behaviors. So like, this is the type of thing that for your average Homebrew user, if you're
23:10 just like a hobbyist and you're playing around in your evening and you don't really care what versions
23:13 things are, that doesn't matter. But if you're doing like serious professional software development,
23:17 like that really matters. Like it matters if your team cannot get mapped on a single kind of locked in
23:24 version of the software they're using. And even just, I have to hat tip to John, like the name,
23:29 the conversation we had where John pitched the idea, he pitched the name Workbrew at almost exactly the
23:35 same time. And I think for me, I like the kind of differentiation where this, we don't see Workbrew as
23:41 almost like a competitor to Homebrew, but it's more like one is single player, the other is multiplayer.
23:46 One is free software, the other is paid software. One is for use at home, the other is for use at work.
23:51 Right. And over time, I think as we keep adding offerings for IT people, for engineers, for security
23:59 people, like I think Workbrew is going to become the dominant way of using Homebrew at work, because
24:04 our offering is just going to be so much more, I guess, easy for teams to use in a more consistent way than
24:10 Homebrew is today. Yeah. And on the second part, regarding like go to market and what we've done
24:14 so far, part of it has been just engaging with community about the problems that they face.
24:19 We could come up with a list of, you know, 15 or 20 different problems that these type of IT admins
24:25 are trying to solve with Homebrew. Things like, you know, I have a fleet of a thousand machines,
24:29 how do I make sure all the right packages are installed on day one? In order to do that,
24:33 they have to write a bunch of custom scripts, deploy them through the MDM tool, or use another open source
24:38 project like one of Mike's projects called Strap to set the machine up on the first run.
24:42 But doing that is labor intensive. They have a lot of custom code and there's no kind of standardized
24:48 way to do it. And what we've done is just kind of talk to people about these various problems and,
24:53 you know, give them solutions. We had a kind of a online like webinar conversation with a handful
24:58 of potential customers. And we went through all these different problems and just gave them the solution.
25:02 You know, here's, here's a way to solve the problem. Like we had one problem that comes up a lot,
25:06 which is we work in a regulated industry, let's say a bank, and our end users are not
25:11 allowed to have admin privileges on their device. As a developer, that sounds terrible to me. I want
25:15 admin privileges on my device, but like when you work at a bank, you're not allowed, right?
25:19 And so the way to solve that problem, when it comes to using Homebrew, it's like,
25:22 you need to have admin privileges to run Homebrew. When it comes to solving that problem,
25:25 there is a way to do it. And there are a bunch of different privilege escalation tools. So what you can do is
25:31 have Homebrew installed, your end user doesn't have admin privileges, they click a button in this
25:36 privilege escalation tool, and they ask for admin privileges, it gets approved. And for a temporary
25:40 period, they can install stuff with Homebrew, and then they get removed from the admin group,
25:44 like after the time limits up, and they have to have an audit log for each one of these things.
25:48 And that's kind of a painful experience, but it's a workaround and you can do it. And so what we've
25:52 been doing in terms of like go to market is just showing people what the solutions out there are
25:55 for those things, but then also giving them a much better alternative, which is to use Workbrew,
25:59 which out of the box works in that situation. You know, you can have end users installing
26:04 packages on their machines without having admin privileges on the device. You know,
26:07 you can have zero touch deployment without having to write any custom code. And so that's really been
26:13 the main activity we've been doing. And then there's also a relatively established community of people
26:20 that self identify as they're called themselves Mac admins. So IT administrators who work on predominantly
26:26 Mac fleets. And, you know, there's like a conference, there's a podcast, there's, you know,
26:31 an open source foundation, there's a Slack channel. And we just try to, you know, participate in those
26:35 kinds of events and those kinds of communities in a really genuine way and answer questions about
26:40 Homebrew. When they ask about how to solve something that's not in scope for Homebrew, we give them
26:45 alternatives and then, you know, show them the way with Workbrew.
26:47 Maybe going back a little bit. I'm very curious how you landed to this product because
26:52 Homebrew has such a massive user base. You can spend your whole lifetime talking to everybody
26:58 and figure out what they need. And I'm sure it's not going to be easy. There's too many signals,
27:03 potentially. What are the kind of the areas you was contemplating about what to start with? And what
27:09 was the process for you to even talk to? Like, did you have to segment into like small, large companies
27:14 and Mac admins, non-Mac admins? Like, what are the possibilities here? And then say, okay,
27:19 this might be a better route to take. I'm just curious how that process went for you guys.
27:23 Well, so the nice thing with Homebrew is because it's a still essentially entirely volunteer run
27:29 project. You know, there's like a small stipend, but like that doesn't go about covering anyone
27:34 anywhere approaching like market level wages. I mean, probably not even market level wages to,
27:39 you know, work in a grocery store, to be honest, but you know, it gives people some compensation,
27:43 but as a result, things only get done if a maintainer or contributor want them to get done.
27:47 So we've had a long tail of, I guess, particularly maybe over the last, maybe more of the last five
27:53 or 10 years than the whole 15 years of the project where Homebrew is being used super widely in a lot
27:58 of big companies. And, you know, every so often you get someone in one of those big companies
28:03 who Homebrew doesn't play nicely with the way they do things. I guess John sort of alluded to that
28:08 earlier. And they come to Homebrew and they say, "Hey, Homebrew, like we're a big, serious,
28:13 important company, right? So you have to change the way you're doing things because, you know,
28:18 we're doing it the right way and you're doing the wrong way and go about that." And previously,
28:22 people would, you know, there was one particularly grumpy Homebrew retainer, I think he was called
28:27 Mike McQuaid or something, who would regularly tell people like, "No, you can't have this and you can't
28:32 tell us what to do. We're all volunteers. Nah, nah, nah, nah." So the nice thing is when we kind of went to
28:37 looking at this stuff, we had a very long tail of lots of almost entirely public conversations where
28:44 often myself or other Homebrew maintainers had said, "Hey, like we don't have the time or energy or
28:50 inclination or whatever to build this stuff." And we had people in big companies often citing the names of
28:56 their companies to try and get these features developed saying like, "Hey, we need this thing.
29:01 Like, why wouldn't you do this thing?" So that kind of gave us a really nice opportunity to begin with
29:05 for painstorming. And I remember the first few weeks after us having this idea, me just like trolling
29:10 through the Homebrew issue tracker and discussion boards and stuff like that, and just generating lists
29:15 upon lists of like, here's people asking for stuff, right? And what are the themes that are coming out
29:21 of this? And what seems like the sort of lowest hanging fruit that could be like a viable MVP
29:26 that solves an actual real problem for real people today, that there's no real good solution out
29:32 there, right? And in some cases as well, like there's some parts of what we built with Workbrew where
29:37 if you go searching around GitHub, like there's abandoned projects that haven't been touched in eight
29:42 years that tried to solve some of these problems. But the problem is partly in the macOS ecosystem as
29:47 well, that things are forever changing. So if you sign up to do one of these things,
29:52 you're sort of signing up to do it forever. So it's very hard to keep something that works
29:58 well on Macs, works well with Homebrew, and keep that going indefinitely without being sufficiently
30:05 plugged into either Apple or Homebrew itself. And we are lucky enough to be plugged into Homebrew itself.
30:11 Yeah. So I think that's what helped from the beginning with us not having to just guess or
30:16 interview thousands of Homebrew users on what they need because we could see this stuff. And again,
30:22 even with that, like the kind of interview process, I think the thing that I've learned through,
30:26 I guess, doing essentially product management on Homebrew for an awfully long time is I have,
30:31 I guess, a line on product management in the, it doesn't sound very nice, but humor me,
30:35 users are like babies and they can tell you that there's something wrong, but they can't tell you
30:40 what they need. And I find that's often the case, again, with these problems where you go and read
30:45 what people ask for, that we're not building exactly what they said they wanted implemented. Because
30:50 often if you ask engineering centric people, they jump straight to a solution, but we're being like,
30:55 okay, what is the shared problem all of these people have? And what's the best solution to their
31:00 problem? Even if they don't know about it yet. So yeah, I feel like that's how we've got to where
31:04 we are with what we built. Yeah. Another like kind of component of that, Mike said the low-hanging
31:09 fruit, you know, when we look at those lists of possible things we could build, everything we've
31:12 built so far as a prerequisite, you know, no matter which direction we go on any of those, you know,
31:17 many, many opportunities of features or potential products we could build fundamentally having a fleet
31:24 management idea of all of the devices within your organization is kind of a prerequisite to any of those
31:29 things. And so that combined with the fact that people are asking for automate deployment,
31:36 do things like have default packages installed, make sure that I know about security vulnerabilities.
31:41 I mean, they're all like pretty straightforward in a lot of ways.
31:44 So I'm curious because we have a lot of founders on this podcast that for the most part have only had
31:50 projects that have been around for a couple of years. This is probably one of the longest standing
31:55 projects that a company is built around. And I'm curious, what's hard about that? Because I
32:01 mentioned on like the plus side, you have a lot of like users already, you have kind of this like
32:07 group that you can build products for. But on the flip side, like there might already be like set
32:11 user expectations or competitors. Like what's hard about building the kind of company that you're
32:15 building right now? I think probably like a sense of momentum or inertia, right? As you, I guess you
32:21 touched upon a few things there where I think people have a certain idea of how homebrew is and how
32:27 homebrew works. And I think with the problems as well, like it's funny, John will probably remember,
32:32 we've had a few discovery calls where we've said to people, okay, so like what problems are you
32:37 experiencing in your business with homebrew? And they say, no, but it turns out what they actually mean
32:42 when you dig in, because there's been times we've had those and you can see like John starts sweating,
32:47 whatever. And I say like, we've come to terms. Yeah. Have you ever had this thing happen? And
32:52 they're like, yeah, you know, like, so I guess like a classic example might be like, have you
32:57 ever had the situation where like, you know, homebrew pushes the version upgrade, a bunch of your team
33:01 upgrades, and then it breaks all your libraries? Like they're like, yeah, like they're like, yeah,
33:05 that happens at least three or four times a year. And it's like, how much engineer time would you say
33:09 that cost you? And it's like, well, probably like about a week to two weeks per engineer per year.
33:14 And it's like, that sounds like, and how many engineers you have using homebrew? Like, oh,
33:17 a thousand. That sounds like quite a big problem. But like in their head, because homebrew has been
33:23 around for so long, because homebrew works the way it's always worked in their head, they're just like,
33:27 this is just a thing. This is like a tax you pay for using an open source project like homebrew,
33:32 and you just have to deal with this forever. And maybe they tried Nix or Mac ports or something
33:37 like that, and that just had its own problems. And then they came back to homebrew. So like the idea
33:41 that like someone could actually fix this so that it never happens again, and those week or two weeks
33:47 of engineering time of year don't happen, that's much harder for them to like come up with by themselves.
33:53 And sometimes people really need poked and be, and the funny thing is like, there's some stuff on our
33:58 roadmap where if we shared it publicly today, we'd probably get like laughed out the room because
34:03 people are like, there's no way you're ever going to do that. That's way too hard. Right. And I guess
34:07 I actually know, like, it's actually not that hard. This is doable stuff, but sometimes people's like
34:13 imagination is, does not stretch big enough to encompass like, what are the easy things and what are the
34:18 hard things. And I guess another strength that you sort of alluded to Robbie is, you know, we've hired
34:23 some people already from the homebrew community who are like staggeringly intelligent, talented
34:29 engineers and know like macOS and like Apple internals and how to make macOS do absurd things that I had
34:38 no idea it could do that open all these doors for us to do things. And actually, you know, like a lot of the
34:45 stuff that they maybe don't know as well, like, you know, we're built on a rail stack and they're the
34:49 people we've heard so far, like new to rails, but it's like, but that's kind of the easy bit, right?
34:53 Like doing kind of crud logic is easy, but like doing all the kind of complicated wrangling across
34:59 OSs and like POSIX layers and whatever is all the kind of gnarly hard stuff. So yeah, hopefully that
35:06 answers your question.
35:07 Yeah. And when it comes to that tax too, you know, another one of the reasons why the people,
35:11 you know, the users kind of like have come to terms with it is like the alternative of not
35:15 using homebrew at all is like just a non-starter, right? I've talked to a number of customers where
35:19 they're like, yeah, we have an ISO security requirement, but if we actually enforce the
35:24 ISO security requirement, that means our engineers can't use homebrew. And that's just not an option.
35:28 We won't do that. So it ends up with them either talking to us or saying we're going to devote an
35:34 entire engineering team to this for the next year and a half to like make our own internal solution,
35:38 which I know of a handful of companies that have done that. So yeah, it's, it's definitely a
35:43 mindset shift of like, you know, homebrew has been around for a long time. It's kind of like,
35:48 it's part of the ecosystem. People know it and are used to it and that's a benefit,
35:52 but it also has this kind of, well, they know it for what it is, not for what else you could do with
35:56 it or, you know, what we might be able to add as well.
35:59 Cool. So jumping to another side of questions here, you've been working at homebrew for so long
36:03 and joining me working at GitHub, you've seen a lot of developers in this ecosystem pretty familiar
36:07 with. What are biggest challenges you didn't anticipate? And now you learn almost like surprises,
36:14 like, oh wow, this is actually harder than I thought, or I didn't even think of this will be
36:18 a big problem. What are those kinds of challenges you face, you know, starting this company so far?
36:23 I mean, one of the reasons I left GitHub in the end and, you know, I joined when we were like
36:28 200-ish people and left. And even then that was the second biggest company I'd ever worked for.
36:33 So for me at workbrew, it's when I came, we're doing a completely greenfield code base,
36:39 all this type of thing. And, you know, between that and co-pilot and all these tools we have
36:43 nowadays, I can move so fast and I can get things done like staggeringly quickly. But then every so
36:49 often you run into a wall of like, oh, I have to like get verified with like Apple Business Manager
36:56 or like DUNS or some MVM tool or whatever. And it's like, it's so hard to have something where like,
37:03 I guess there was, you know, some products that we've integrated in and building the integration
37:07 entirely took two hours, but getting like all the paperwork done so that I could play with the
37:13 integration took like two months. Yeah. This is like, it's maybe not even hard as a founder. It's
37:18 just hard for my soul having to deal with things that just take so long. And it just feels so
37:24 unnecessary that it must take so long, but I get it. These big boy and girl companies can't be
37:29 startups forever. Yeah. From my perspective, the biggest challenge is like doing things you've never
37:34 done before. I'm an engineer by background. And I'm also, I've done like a lot of like go to market
37:39 on developer tools. But as far as a founder goes, you know, I've not really done sales and being an
37:45 enterprise product, I have a lot of sales conversations. And so I mostly take them from
37:50 kind of the founder sales approach of just being helpful, trying to understand their problems.
37:54 And what I found really interesting about that is this is an entire career path that tons of people
38:00 are very, very talented in and spend many, many years, more years than I've spent as an engineer
38:05 or as a marketer, you know, honing those skills. And as a new founder, it's like, you have to do it.
38:10 So one of the things that's been really valuable for me is working with, you know, a former salesperson
38:15 from GitHub, who I knew really well, and who can kind of like go through the deal process with me,
38:19 talk to me about like, kind of this particular company that you're talking to, I've sold to,
38:24 you know, a multimillion dollar deal before, these are the people you need to talk to how to do it.
38:29 And it's like, there's just a ton and ton of new stuff that we have to learn all the time.
38:33 And I think that's true for all three of us doing things that are outside of our comfort zone.
38:37 I actually have an addition there as well, where I think it's the sense of responsibility.
38:41 Like I had a conversation, I'm hopefully she wouldn't mind me sharing this with my wife a while ago.
38:45 And she was like, hey, like, are you actually happy at work through?
38:48 Because you seem to kind of come to me with like so many more problems than when you were at GitHub.
38:53 And I realized like, yeah, I am happier, but the difference is every problem I had at GitHub,
38:57 like particularly by the end, it's like 99% of those are outside of my control.
39:01 Some, my bosses, bosses, bosses, bosses, boss, or someone at Microsoft decided that like,
39:06 this thing is not happening anymore.
39:08 And I can't talk to them.
39:10 I can't influence them.
39:11 Whereas with the start, with, you know, the three of us are now with employees or whatever.
39:15 It's like, everything is my problem, right?
39:18 Like everything is, it might not be on my plate necessarily to solve every problem,
39:23 but like I have influence over everything.
39:25 And like that's simultaneously liberating and incredibly terrifying at the same time.
39:31 And it means that, you know, there's a lot more conversation with my wife where I'm like,
39:34 what should I do?
39:35 And she's like, I don't know.
39:36 And I'm like, well, I don't know.
39:37 I kind of have to decide because I don't have any adults anymore to decide for me.
39:42 I feel similarly.
39:44 So final question for each of you, what's one piece of advice you'd have for an open source
39:50 founder that is earlier on than you?
39:53 I guess from my perspective, you know, I'll go back actually to when I started the company.
39:58 So I started this company in 2019 when I left GitHub shortly thereafter.
40:02 And I was a solo founder doing something totally different.
40:06 And I've been through, you know, a number of different pivots.
40:08 It wasn't necessarily open source, but it was always kind of engineering related.
40:12 And I think my biggest lesson was like, don't go it alone.
40:15 Ever since having Vanessa and Mike join, I feel like I've been much happier, had a lot more clarity.
40:20 You know, when things are confusing or I don't know what to do,
40:24 it's very easy to just like, you know, talk to my co-founders and work with them.
40:28 And so I think it's like a very, very special kind of person who could be a solo founder.
40:31 I thought I was one of them, but I'm definitely not.
40:33 I would recommend, you know, don't go it alone, whether it's having co-founders
40:36 or just like a really good network of advisors, people like deeply involved in your business,
40:41 having other people involved in your open source project, obviously, as well.
40:44 But, you know, that was like the single biggest inflection point for me and being a founder.
40:49 I'm going to focus on the open source side of the open source founder, I guess.
40:53 And I think it's particularly relevant right now.
40:56 As I said, there's been all this stuff in the news, but I think it's worth paying attention to that stuff.
41:02 Not necessarily worth paying attention to the naysayers and, you know,
41:06 the Hacker News crowd who are not always the most positive bunch.
41:10 But the thing that is worth paying attention to is I think we're all, when you start a company,
41:15 a product of the moment you're in, right?
41:18 And you can't look at what worked five years ago or 10 years ago or sometimes even one year ago
41:23 and try and replicate that model and get the same success.
41:26 You have to be influenced by them and learn the lessons from the greats and your kind of peers
41:31 in the industry.
41:32 But it doesn't work to go and say, well, this model worked for Red Hat or GitHub or whoever,
41:39 and I'm going to just follow this model with a letter and do things that way.
41:42 Because we're in a different world now.
41:44 And like some of these places paved the path in a good way.
41:47 And some of them, I don't know what the opposite of paving the path is,
41:50 but, you know, maybe blew up the path along the way and you can't go that way anymore.
41:54 So, yeah, I guess for me, it's been really helpful to kind of read and learn and soak
42:01 up as much information as I can about what other open source companies have done and are doing
42:07 and are planning on doing and just kind of learn from that and combine that with what my co-founders
42:13 think, what my peers think, and try and pave our own way.
42:16 And hopefully it works.
42:17 Awesome.
42:19 Well, this conversation has been fantastic.
42:21 We so appreciate both of you joining us.
42:23 I think our audience is going to take a lot away from this.
42:25 Thanks for having us.
42:26 Yeah, it's been great.