One thing I haven't seen mentioned here is that Homebrew forced people use Ruby to write formulas (ie packages), whereas MacPorts forced people to use Tcl. This one decision, plus hosting formulas on Github, was a major contributor to their present success.
As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebrew took the field purely through sneaky marketing or n00b decisions alone. They leveraged the momentum of a lot of new devs coming to OS X and provided an easier path for people wanting to help out.
I hate to say it, but if this was a race (?), Homebrew won. Thankfully we all still have the choice to use MacPorts if we want, but there's no point in being mean about Homebrew at this point either.
It reminds me about this answer from Homebrew's creator, Max Howell, on Quora[1]:
> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly.
> Is it any surprise I couldn’t answer their heavily computer-science questions well?
> On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user.
Yes, Homebrew's approach on package management is a bad smell to me. It gets broken by every other major OS update, it messes up your Python PATH for no good reason, it forces a lot of opinionated decisions on users if the maintainers think it benefits the majority(and ignores voice from minority)... But Homwbrew still wins because users really like it. It is that simple. With its popularity and the strong community, it will continue to be the top choice for most of the mac users. Max Howell may not be a rock star programmer in my mind, but I have no doubt that he could've been a very successful product manager.
Personally I don't plan to switch from macports to homebrew any time soon, but I stopped grumbling about how bad it is years ago.
I am using brew because it works, as simple as that. If in 99% of cases I can type "brew install stuff" and it installs stuff, I am happy. Does it have outliers? Sure, as pretty much any other software, sometimes it breaks. But it delivers environment where I can install stuff without wasting my time on boring crap like figuring out how to build it and resolve conflicts with other crap - it's enough for me. Even if it only does that in 99% of cases, still much better than not having it.
As I see it, a major problem in software is that when you have a problem, it's often not clear who or what is at fault. Let's say my laptop is slow, particularly when I have lots of browser tabs open. Should I blame:
1. My hardware?
2. My OS?
3. My web browser?
4. My browser extensions?
5. Websites?
6. The chat app I keep open in the background?
7. The Electron settings app for my RGB Keyboard?
8. My internet connection?
9. A virus?
10. "Technology", presumably alongside some wistful thoughts of "the good old days"?
Most users, even non-technical ones, are going to blame one of these things. And, more often than not, their conclusions will have more to do with marketing and happenstance than the actual cause
All of which is to say, that quote kind of bothers me. You cannot actually be focused on user experience while skimping on technical details. You may have created an experience in which users feel inclined to blame someone else, but that's not the same thing. You are the knowledgable developer, and your users are not.
Have you tried uninstalling Chrome? I hear it can make your WindowServer go wild :P
More seriously, though, this is why I hate people who use software like Electron and claim their users can't notice: of course they can, they just complain that their computer is slow because they can't pinpoint it on your app. As a developer who knows better, your entire charade depends on ignorant users being unable to point the blame at you for what you have done to them. Combine this with the lock-in typical of today where users are resigned to use your software even if they don't particularly want to and now the people who do know what you're doing can't do anything about it either.
Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg.
MacPorts these days behaves similar to Homebrew by installing from binary archives by default and only build from source when binary archive is not available. This vastly improved the experience, but the old impression remains for those who got burned (literally for some) by MacPorts. 10 years is a long time, and MacPorts has improved a lot since then.
MacPorts does also still drop to compiling from source more often than Homebrew. But that’s mostly because they take a more conservative legal approach towards the GPL—for instance, they won't distribute binaries of any GPL software that links with OpenSSL.
Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparison.
(As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)
> Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair point of comparison.
On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.
We don’t support any scenario where things are built from source (i. e. we won’t help you if things break) so technically support has indeed been dropped.
Is there no way to enable downloads of builds in homebrew on those systems with the caveat that perhaps it'd have to go back to compiling if there aren't any?
Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).
Ah, you're right. Now thinking back, I think it was how Homebrew reuse system libraries that make it a better experience than MacPorts at the time since it could cut over half of the building time (it prevent the situation where `port install sl` ended up having to build the entire gcc toolchain). This was actually why "reuse system library" were such a big deal back then. Bottle come much later than that.
The other downside to MacPorts' original way of building everything is that sometimes, for whatever reason, things just wouldn't build and getting help with that was thorny, particularly for those who'd just started dabbling in software development or CLI usage. Where a vet or moderately seasoned user might find the thrown error actionable, the new user would google the error, find a couple of semi-related but ultimately unhelpful archived mailing list threads from n years ago, and probably give up and find some other way to get the package they need.
Just today my new config for Emacs refused to build libgit. I could see the CMake error, but rather than figuring out how to fix it I just commented out that part of my config (resulting in slightly more overhead in magic). Even with many years of serious software development, I really don't like debugging build problems.
I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.
This is one reason why using Rust crates in cargo's current form irritates me, if I wanted that kind of experience I would be using Gentoo as daily driver.
All the other languages I use support binary libraries on their package managers.
I find it unfortunate that those two occupy the 1-2 in Mac packaging options. It never really got much attention, but I've always liked Rudix [0] better. The package selection is much worse and not really kept as up-to-date, but the installation mechanism is far superior to Homebrew and MacPorts (and even Fink). It uses actual packages (the kind that Installer.app understands) so it integrates much more cleanly with the Mac ecosystem and packages installed without using the package manager. Compared to the other options, it's an administrator's dream in a managed environment since all the first-party Apple tools for managing a fleet of Macs just work. Also, users who don't want to install the actual rudix tool can simply download the packages and install using using Installer.app (which they may never even realize they're running because it opens automatically when opening a .pkg file).
Unfortunately, most Mac users have never even heard of it and it doesn't really have the momentum or mindshare necessary to have a complete, up-to-date list of packages.
Why leave out nix? It's been a good alternative that works similarly on Linux too for unified environment.
I hate Linuxbrew when it tries to install stuff in a weird place that is /home/linuxbrew/.linuxbrew/ and as soon as you try to change the installation path, half of your packages starts compiling and since it's not the major way to do things, it often breaks and can't even compile.
I don't like scaring other users on the same server creating stuff at some bizarre location.
No idea how they didn't just settle in /use/local/ as it does on Mac or just use /opt/brew/ like a sane choice would be.
Rudix seems interesting, so I just installed the nasm .pkg as an experiment. There are several things I don't understand yet. How is a package uninstalled? If there is an updated package, does the whole process of downloading and clicking through Installer.app have to be repeated? Also, is there an automated way to install a large selection of packages at once?
There is an actual rudix package that has install/uninstall, including for itself.
Otherwise you’re using the somewhat cumbersome process of backing out a package based on the receipt. It’s doable, but mostly requires some googling to find the correct incantation.
Can't upvote enough. Rudix is the only package manager that really meshes with the platform, instead of trying to create its own weird linux (or bsd) hybrid ecosystem. I used it heavily a decade ago, but sadly it never really took off.
> I hate to say it, but if this was a race (?), Homebrew won. Thankfully we all still have the choice to use MacPorts if we want, but there's no point in being mean about Homebrew at this point either.
Definitely, plus there's also Nix and pkgsrc now, it's not like there's no alternative. And that's one race I lost trying to take the matter in my own hands with ArchMac[0] out of frustration with the limitations I faced with MacPorts and Fink, then Homebrew, so I pulled the plug[1] and trim the bills.
I still prefer MacPorts over Homebrew. However, like you said, Homebrew's marketing in the form of embedded into tutorials and setup's helped push them to where they are now.
Almost every Ruby on Rails tutorial I've seen in the last decade used Homebrew over MacPorts.
I found MacPorts just before Homebrew was a thing. I figure since Mac OS was BSD based, why not go with the traditional portage way.
I preferred my optional packages to be installed in /opt.
I preferred MacPorts.
Sadly, in the last 3-4 years, Homebrew has been leading the charge, adding more bleeding edge package versions and just doing a better job of maintaining the formulas for install.
Happy to see it. I think for python/go/ruby devs they will continue to prefer Homebrew simply because the tutorials they learned from prefer it. It's a feedback loop.
MacPorts seem to be very “user” friendly for people with Unix and/or Gentoo (maybe a bit Arch too) background. I have experience with all three and when I needed to decide in between HomeBrew and MacPorts, it was very simple choice. I tried both to get the actual experience and stuck with MacPorts.
All the naming in HomeBrew was just too confusing too me.
Gentoo is probably the most user hostile Linux distribution I can think of other than ones purposely austere for learning (LFS) or parody (Suicide Linux).
If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.
If Gentoo makes your particular computer goal easier to achieve, I don't think it's "hostile".
Most people will never need Gentoo or want to use it, but for those with either a need or a desire for a meta-distribution, Gentoo does a pretty good job. I don't think calling it "user hostile" is quite right.
I think it's been partially supplanted by other package managers now like Nix/NixOS and even (IMO) XBPS/Void, but Portage does an alright job.
I used Gentoo for a while and mostly liked it. There was one reason I stopped using it -- dependency conflicts. Every time you update, there's a new set of conflicts that you have to personally untangle.
By any other metric, I would consider it more user-friendly than average. For example, I was very favorably impressed when (not knowing what I was doing), I gave the command to uninstall libc, and after confirming that I really wanted to do that, I was allowed to.
Ha, what was it, emerge -e world ? Or something like that. It’s been like 15 years since I did that.
The community feel was pretty good. Excellent documentation/wiki. And it was by far the best Linux education I could have ask for back in those days. I’m happy ...
I used gentoo for a few years and found it to be very pleasant, with a great wiki. The only reason I ever stopped using it is because I realized how senseless it was to build everything from source on a laptop with questionable thermal characteristics. Running laptop fans full tilt for hours on end a few times a week evidently exceeds their expected duty cycle, who'd have thunk, but I had to replace the fan in my T60p twice before I learned this lesson. Building everything with Macports would have the same problem, except worse because mac laptops were never as easy to repair as thinkpads, particularly not in recent years.
No, it doesn’t need more knowledge. It’s pretty simple to use. I was just pointing out similarity in concept. Something other users may have experienced in the past.
I don’t agree with Gentoo being hostile :). Complex and educational, sure. But if anything, you can shape it exactly you want it!
If you meant the community, wait until you meet the wrath of ArchLinux forums LOL
It was my first experience with linux in 2003, going through some 80 page wiki to get things configured and built. Learning how to configure an fstab file.
Hostile as in everything requires following a multipage guide of commands and manual configuration that often didn't quite work. Also when I asked on the forum I was told they didn't want more users, but more skilled users (I was 12).
So not really mouse clicky, more that basic functionality takes enormous effort to get working and the community at the time wasn't great.
I've never used MacPorts. Go figure, I just realized that "MacPorts" means "bsd ports for mac". I'll have to try it sometime and see if I prefer the look and feel of MacPorts.
I've found it rather easy to use, I've only been a mac user for a couple of years. I've not had any problems with updates either. I switched from brew fairly quickly when brew told me I couldn't install packages because they weren't "safe" even though I knew they were in fact fine because I've used them for years on linux.
If you liked bsd ports, you are probably going to like MacPorts too. I only wish they better advertise how to set up MacPorts without sudo/within users homedir. I have been using it like that for 4 years and it works great. No worries about affecting mac core bins. Highly recommend if you want to just test it out
I don't recall how I came across it but remember well the relief after using it the first time. It was the first package manager on MacOS that worked and made installing common tools painless. With MacPorts, fink etc it felt like it would have been better to built from source yourself.
I agree with this (other than maybe hating to see Homebrew “win”). And I’ll add:
And although I’m not arguing Homebrew is above reproach or critique, some of the criticism here seems both a little unfounded and a little bit ignorant (either willfully or because people just don’t know/remember) about the state of package managers BEFORE Homebrew. Like you, I used MacPorts/Darwinports and Fink for years before Homebrew was a thing and have immense respect for all three of those projects (even though DP merged with MP over a decade ago, my mind still sees them as separate things) and the massive role they played in my own life and development as a developer, but Homebrew didn’t just pop-up and supplant the existing options and through nefarious means.
At the time that it came to existence, despite the very good existing options, those communities and their progress had stagnated — at least from the perspective of the end user. There was a wealth of older packages, but newer stuff wasn’t there. And the death of PPC with Snow Leopard hit subsets of that community hard. It wasn’t just that Homebrew was easier to use and install (though it was, a bit), it was that it had more modern and more frequently updated packages.
I distinctly remember when Homebrew first arrived, my initial reaction was, “why do I need this, I already have MacPorts?” But then I used it and found that people were bottling up newer stuff at a much more rapid pace and the tools embraced by that community were modern and frankly, to an outsider, much more accessible. As you said, choosing GitHub over MacForge or whatever was a great choice too.
MP has had a renaissance of sorts over the years which has been amazing to see. I think having options is awesome. But Homebrew was very much filling a void for some beloved projects that had fallen behind. It’s hard to win that momentum back, once the community (including a whole generation of new users) goes to the new thing.
We’ve seen that with Mac text editors too. TextMate, to me, is still one of the best editors I’ve ever used and I would argue is one of the most influential software applications of the aughts. But as it faced all of its challenges to move to 2.0 (the feature creep, the technical challenges, the scope changes), it created a window for Sublime to come in and take the the extension community (which was really pioneered in the way that it worked by TextMate), and thus the userbase with it. And when Sublime faced similar challenges in its own troubled releases (for some of the same but also different reasons that TextMate had), we again saw momentum shift to VS Code.
> I don't think Homebrew took the field purely through sneaky marketing or n00b decisions alone.
The Homebrew team was using a lot of FUD regarding MacPorts when Homebrew started. It's actually funny because they were criticizing some of MacPorts decisions which they then had to implement when they finally realized they were the correct engineering decisions years later.
I used both MacPorts and Fink prior to Homebrew being released. The fact that it was able to do binary archive installs, and then later Homebrew Cask just made it a far friendlier package manager. I've added a few formulas over the years and am happy to see it continue!
i honestly don't know the backstory on why you "hate to say it", and personally was a NeXT developer 25 years ago which I mention for context that I feel I missed out on something preferable in MacPorts, having found homebrew adequate.
No real backstory I guess. I found Homebrew unpleasant to use for a lot of the reasons gone through in this thread -- mostly just the "rolling distro" nature of it -- so I was a dedicated user of MacPorts. My experience is probably further biased by the fact that I was using the package manager on OS X to deal with Python stuff at the time, so the versioning issues definitely bit me. But at some point, using MacPorts just started to feel like swimming against the tide.
As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebrew took the field purely through sneaky marketing or n00b decisions alone. They leveraged the momentum of a lot of new devs coming to OS X and provided an easier path for people wanting to help out.
I hate to say it, but if this was a race (?), Homebrew won. Thankfully we all still have the choice to use MacPorts if we want, but there's no point in being mean about Homebrew at this point either.