That’s not fair. Homebrew has been fantastic. It’s also open source, did they not accept your pull requests for these “improvements”?
(Beyond anything else, Homebrew's biggest "win" over MacPorts was and probably is still UX and DX. The core technology of a packaging ecosystem is rarely itself the differentiator.)
Homebrew is by far the worst package manager I have ever used. I’m still sour it somehow dragged away packagers from solutions which were better in every way by being promoted as the "default" solution.
I can't find these anywhere on the official blog, which goes back to the first 1.0 release of Homebrew. Links would be helpful.
Here are the comparisons to other package managers:
> Packages are brewed in individual, versioned kegs. Then symlinks are created to give a normal POSIX tree. This way the filesystem is the package database. Everything else is now easy. We are made of win.
vs MacPorts registry which used its own homebrewed (lol) Receipts files in 2009, and now uses a SQLite DB: https://guide.macports.org/chunked/internals.registry.html#i...
> I wouldn't worry about it not being root. We don't install anything base enough for it to be a concern (unlike MacPorts or Fink).
vs MacPorts installs to `/opt/local` as root.
> Why Not MacPorts?
> =================
> 1. MacPorts installs its own libz, its own openssl, etc. It is an autarky.
> This makes no sense to me. OS X comes with all that shit.
> 2. MacPorts support Tiger, and PPC. We don't, so things are better optimised.
There is no “Why Not Fink?” section.
And because I didn't know the word autarky: https://en.wiktionary.org/wiki/autarky
It was frustrating in the beginning to see so much marketing-driven shade being thrown from an ill-informed position.
Obviously that wasn’t you or the current maintainers of homebrew, and things have improved tremendously, but that’s the era from which frustration like the grandparent post originates.
The worst part is that MacPorts already did the same thing, but used hardlinks to avoid the kinds of problems that emerge when (for example) `realpath` resolves a symlink to an unexpected versioned directory that’s supposed to be an implementation detail.
There was a lot of FUD, dishonesty, and shallow understanding from the homebrew creators in the beginning.
I don’t think you are being fair. This question presupposes that the supposed problems can be solved by iterative changes, rather than being inherent in the chosen design/architecture of the software, which usually requires complete replacement thereof (as well as the leadership thereof, as people who choose poor solutions to problems often can’t appreciate arguments for superior solutions).
(Not that I’m trying to suggest that I agree that homebrew in particular is bad — just speaking generally.)
And, I’ll point out the irony in your directive: you take issue with people expressing criticism without taking action to completely resolve the respective issue, and then you come along to express criticism by tell people to not complain but instead offer up free labor, when you could go and solve the problem that resulted in the original complaint.