Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Open Source Security

Mike McQuaid on 15 Years of Homebrew and Protecting Open-Source Maintainers (thenextweb.com) 37

Despite multiple methods available across major operating systems for installing and updating applications, there remains "no real clear answer to 'which is best,'" reports The Next Web. Each system faces unique challenges such as outdated packages, high fees, and policy restrictions.

Enter Homebrew.

"Initially created as an option for developers to keep the dependencies they often need for developing, testing, and running their work, Homebrew has grown to be so much more in its 15-year history." Created in 2009, Homebrew has become a leading solution for macOS, integrating with MDM tools through its enterprise-focused extension, Workbrew, to balance user freedom with corporate security needs, while maintaining its open-source roots under the guidance of Mike McQuaid. In an interview with The Next Web's Chris Chinchilla, project leader Mike McQuaid talks about the challenges and responsibilities of maintaining one of the world's largest open-source projects: As with anything that attracts plenty of use and attention, Homebrew also attracts a lot of mixed and extreme opinions, and processing and filtering those requires a tough outlook, something that Mike has spoken about in numerous interviews and at conferences. "As a large project, you get a lot of hate from people. Either people are just frustrated because they hit a bug or because you changed something, and they didn't read the release notes, and now something's broken," Mike says when I ask him about how he copes with the constant influx of communication. "There are a lot of entitled, noisy users in open source who contribute very little and like to shout at people and make them feel bad. One of my strengths is that I have very little time for those people, and I just insta-block them or close their issues."

More crucially, an open-source project is often managed and maintained by a group of people. Homebrew has several dozen maintainers and nearly one thousand total contributors. Mike explains that all of these people also deserve to be treated with respect by users, "I'm also super protective of my maintainers, and I don't want them to be treated that way either." But despite these features and its widespread use, one area Homebrew has always lacked is the ability to work well with teams of users. This is where Workbrew, a company Mike founded with two other Homebrew maintainers, steps in. [...] Workbrew ties together various Homebrew features with custom glue to create a workflow for setting up and maintaining Mac machines. It adds new features that core Homebrew maintainers had no interest in adding, such as admin and reporting dashboards for a computing fleet, while bringing more general improvements to the core project.

Bearing in mind Mike's motivation to keep Homebrew in the "traditional open source" model, I asked him how he intended to keep the needs of the project and the business separated and satisfied. "We've seen a lot of churn in the last few years from companies that made licensing decisions five or ten years ago, which have now changed quite dramatically and have generated quite a lot of community backlash," Mike said. "I'm very sensitive to that, and I am a little bit of an open-source purist in that I still consider the open-source initiative's definition of open source to be what open source means. If you don't comply with that, then you can be another thing, but I think you're probably not open source."

And regarding keeping his and his co-founder's dual roles separated, Mike states, "I'm the CTO and co-founder of Workbrew, and I'm the project leader of Homebrew. The project leader with Homebrew is an elected position." Every year, the maintainers and the community elect a candidate. "But then, with the Homebrew maintainers working with us on Workbrew, one of the things I say is that when we're working on Workbrew, I'm your boss now, but when we work on Homebrew, I'm not your boss," Mike adds. "If you think I'm saying something and it's a bad idea, you tell me it's a bad idea, right?" The company is keeping its early progress in a private beta for now, but you can expect an announcement soon. As for what's happening for Homebrew? Well, in the best "open source" way, that's up to the community and always will be.

This discussion has been archived. No new comments can be posted.

Mike McQuaid on 15 Years of Homebrew and Protecting Open-Source Maintainers

Comments Filter:
  • "One of my strengths is that I have very little time for those people, and I just insta-block them or close their issues."

    So, a narcissistic douchebag.

    Seriously, who brags about closing issues out of spite?

    • Quite obviously from the quoted context, he doesn't close issues out of spite.

      • Maybe, but bragging about it is really not necessary.
        He could have answered "One of my strengths is that I have very little time for those people, and I just prioritize well-written bugs". Which is the same thing, but doesn't raise giant red flags.

    • by rta ( 559125 ) on Monday July 29, 2024 @09:11PM (#64665646)

      "One of my strengths is that I have very little time for those people, and I just insta-block them or close their issues."

      That sentence exactly was a red-flag for me... yes open source users can be entitled aholes, but otoh i absolutely hate coming across a bug that eventually i find mentioned as an issue/ticket from like 3 years ago that was closed by a highhanded dev who didn't understand the issue or couldn't repro it. Or by those damned auto-aging scripts. (i understand the problem they're trying to fix, but i think the cure is worse than the disease... though i don't _really_ have a solution for what to do with a 1000+ item backlog)

      Anyway, back to this guy... i've hit his website, https://mikemcquaid.com/ [mikemcquaid.com], and i still can't tell what i think. Of his posts i've read so far i don't disagree with his assertions / takes. But still can't shake the feeling that i'd think he's a jerk.
      Time to check YT...

      • He is a really fun guy and he knows what he is doing. Part of the insta-close comment comes from his time at GitHub where people would open issues to pontificate but not actually resolve issues. Mike was the one who came in and closed those issues with wontfix. I am glad to see him come into his own, reach out to him he is far more friendly than he lets on :)

    • by BoogieChile ( 517082 ) on Monday July 29, 2024 @10:03PM (#64665682)

      It's funny how a lot of entitled, noisy users in open source who contribute very little and like to shout at people and make them feel bad always think it's the person who refuses to put up with their shitty behaviour that's being the jerk.

      • > that's being the jerk.
        There's a lot of open source developer who get given bug reports in a courteous, well documented manner that blow up on you and block you because they think their software has no issues and that the user is the problem.

        For example a while back I gave a very exact bug report (without blaming anyone and suggested a fix for the issue) about how an open source firewall application (for Windows) was blocking access to Windows Update and the developer of the said application on Github

    • by piojo ( 995934 )

      "One of my strengths is that I have very little time for those people, and I just insta-block them or close their issues."

      So, a narcissistic douchebag.

      Seriously, who brags about closing issues out of spite?

      Someone that uses cutesy euphemisms for serious measures responsibilities may be an asshole, but the same can be said for someone that posts damning quotes without the context.

    • by hey! ( 33014 )

      It's not bragging. It's sharing wisdom he got from experience. One hard lesson I learned in business is that the corollary to the customer always being right is that you need to choose your customers very carefully. And let me tell you, if you're a small business it takes a lot of discipline to turn down customers who want to pay you good money for the privilege of shitting on your people.

      I'd go so far as to say I've never seen an abusive customer that was worth keeping. Even if you structure your contract

  • Does it still require that gosh-awful hack where /usr/local gets chown'ed to your user account?

    • I don't know, but that was the thing that put me off about Homebrew also. Well, that and the fact that it wants to put anything in /usr/local in the first place instead of the more appropriate /opt/local. The latter is where I expect a 3rd party package manager to put stuff; the former is where I want to put my own stuff that either isn't available via the package manager or that I want to build myself for whatever reason.
    • On Apple Silicon, it winds up in /opt/homebrew. I think this has to be done in order for it to work without having to kill SIP. However, it would be nice if there were a way that it can install as its own user, and not as one user, perhaps with an update process started and running, so it can update itself when a non admin user uses it, or even better, have the option to auto update, saving a backup of the old items just in case, so the update is as close to atomic and reversible as possible.

      There are thi

  • Hostile devs. (Score:4, Interesting)

    by sg_oneill ( 159032 ) on Monday July 29, 2024 @08:46PM (#64665610)

    I strongly dislike Homebrew on the mac. They've got a *long* history of blowing away python installs, and when asked if they could ammend that policy, they'll get super hostile and berate the user for not using a virtual env manager. Which everyone already does, but the virtual env managers symlink to pythons which get blown away by homebrew creating chaos, leading me to suspect they dont actually test their packages.

    Easily the most hostile devs I've ever encountered.

    • by cstacy ( 534252 )

      Whenever I do a brew upgrade python on the Mac, it doesn't blow away anything native. It gives a code of instructions on how to link it to /usr/local/bin and so forth, if that's what you want.

      Is it older versions of python, from Homebrew, that are getting nuked for you? I think there's a way to "pin" things like that so they don't get molested.

      brew is my goto solution for most development environment and random tools, but sometimes I have to go back to the old un-managed way of downloading and compiling fro

      • Yeah thats true. I think the thing would be more easily resolved if it warned that updating a package would have that effect and how to remediate it. Still, I do not think its wise to package a python in a way thats exposes itself to user environs without making them pinned by default.

    • by Anonymous Coward
      I don't know why the richest company in the world doesn't dedicate one or two engineers to a package management system seeing as one of the great appeals of macos is having a Unix command line. They don't need all zillion packages just the most in-demand ones. I guess GPL3 is a big problem but they could easily solve that by having a separate company owned by some trust that does the work and just contribute money to that trust every year.
      • by Darinbob ( 1142669 ) on Tuesday July 30, 2024 @01:58PM (#64667472)

        Apple has steadily been turning the Mac into an iOS development platform, while diminishing its value as a general purpose development tool, or as a tool for doing cross compiles for embedded systems. Every release it becomes harder and harder to get Mac Ports or Homebrew up and running properly. MacOS used to ship with a set of regular commond line tools that you could start with - a native compiler, make, etc. Then those were repackaged into a package to download instead; then that package got hidden unless you knew the URL; then there was no alternative but to first install ALL of xcode.

        It's like Apple no longer wants customers to do basic command line builds. The original selling point to many people was that you got a very familar unix command line and tools out of the box, so you could do normal developer stuff but still have a very nice desktop running those pesky mandatory enterprise apps (Office).

        At this point in time, we've just dumped the Mac completely as a development machine, instead using WSL under windows. Getting WSL installed is less than 5 minutes, another 5 minutes to install the packages you want, and you're done. Mac Ports or Homebrew always took hours to get set up.

    • by sodul ( 833177 )

      We fixed the python issues by using https://github.com/pyenv/pyenv [github.com]. It will install a local python under `~/.pyenv` and can even install multiple virtualenv versions.

      We still need HomeBrew to install a small list of C libraries such as readline, xz, zlib, etc... but this has significantly improved the consistency of our python toolchain.

      Initially we used `brew install pyenv` but we now install pyenv directly since the brew versions can be behind when a security fix is released.

    • I have not encountered this, but I've only done a few things in Python. However, on Macs one thing that does work well enough is using Docker, just to ensure something runs in isolation. This not just keeps Homebrew out of what is being done, but if whatever is being worked with craps over the environment, it isn't hard to kill the container and restart, with the only damage being the shared filesystem. I used to use VMWare Fusion and Vagrant for everything, but switched to Docker, or Vagrant as a Docker

    • Re:Hostile devs. (Score:5, Insightful)

      by gullevek ( 174152 ) on Tuesday July 30, 2024 @02:36AM (#64666016) Homepage Journal

      Main reason why I have MacPorts and Homebrew. macPorts for stuff where I want to be sure that an update doesn't kill everything and Homebrew for the stuff where there is no MacPorts package :D

    • I dislike it also, it's got a weird model using lots of symlinks that can be very confusing. Our set up was based on Mac Ports, and I wrote up detailed instructions on how to install it and create a build environment, etc. Then Homebrew got popular for some reason. I would tell contractors to use Mac Ports, but they'd look at the web and decide to go wtih Homebrew, then they'd be stuck and ask me for help and be upset that I refused to be their personal computer assistant for free. (If my instructions do

  • by EMB Numbers ( 934125 ) on Monday July 29, 2024 @10:13PM (#64665700)

    Homebrew is superior to *yum* and *apt* in my humble opinion. Homebrew emphasizes NOT needing administrative permissions and NOT replacing the distributions' default versions. Even Homebrew itself may be installed without sudo.

    Homebrew also works with the Linux subsystem for Windows and with Linux.

    I am very grateful for the existence of Homebrew.

    • Has something changed recently with Homebrew? When I last used it, all of the packages it installs require either sudo access, or setting /usr directory permissions to be owned by a single user, which is absolutely ridiculous for any system that is used by multiple users. It's also highly insecure.

  • His Tweet "Google: 90% of our engineers use the software you wrote (Homebrew), but you canâ(TM)t invert a binary tree on a whiteboard so fuck off." convinced me to turn down an interview with Google

  • Wait, there's a MacOS thing that nobody's aared about for years.

    QUICK post on slashdot.

    News in the IT wolrd? Nagh, we're busy with MacOS crap.

    Good job Slashdot. The five Mac users reading this are teeming with pride.

  • Collaborating with a company running the largest GPL hostile ecosystem, iOS, which has explicitly said they now think it's a mistake they don't run MacOS the same way.

    What is Asahi Linux going to do When to do when all code runs encrypted from memory and there is no more reverse engineering? What is McQuaid going to do when all MacOS applications have to be signed by Apple with the same restrictions as on iOS?

    Their contribution is but a drop in the ocean, but for an "open source purist" it still seems a str

  • I started by using Fink but gave up the for MacPorts. Don't remember why (more packages?). But I never understood why Homebrew suddenly became all the rage. Why do people prefer that to MacPorts? I don't miss anything in MacPorts or have any other issues. It is stable and safe.

    • I started by using Fink but gave up the for MacPorts. Don't remember why (more packages?).

      After a decade + with Fink, I made the same migration. In my case it was because MacPorts consistently had more up-to-date packages than Fink did - which is too bad, because overall I preferred how Fink worked.

      But I never understood why Homebrew suddenly became all the rage. Why do people prefer that to MacPorts? I don't miss anything in MacPorts or have any other issues. It is stable and safe.

      I think Homebrew is easier for non-Unix-experienced users to implement. And of course those users have no idea they might be compromising their machine's security - although, from what I've read above, now that Apple is basically forcing Homebrew to do things a more correct way (installing under /opt/

    • I think it got more stories about it, and then ended up at the top of the search results. At that point it's the first thing people try. It's even what they try when I tell them not to use it, and instead follow the detailed instructions that work, and that I will support if it doesn't work. But no, they try Homebrew and get stuck because "that's what the internet told me to use, so can you help me understand how to use it?"

    • by j-beda ( 85386 )

      I've seen a few discussions about the potential security implications of homebrew's default setup, with limited need for sudo and the default installation locations conflicting with existing Apple supplied software. I currently use MacPorts for the command line stuff I support.

      I think the appeal of homebrew is mostly a matter of luck - it got the developers and press that put it in "the lead" in terms of support and exposure.

10 to the minus 6th power Movie = 1 Microfilm

Working...