Genuine question: in what ways have they been hostile to their users? I use it all the time and haven’t noticed anything (which isn’t to say you’re wrong, I just haven’t seen it).
They caused a huge commotion some years back when they removed the entire concept of variants from ports/formulas, removing the ability to set any build time options whatsoever, breaking all patches for older platforms, etc. maintainer was quite rude about it when asked to reconsider by huge numbers of users that could no longer use the software.
The entitlement of users calling open source maintainers that try to limit the surface area of support tickets to the systems that provably 95% of users are on “user hostile” is always sad to see.
The sociopathy of people who pretend "it's user-hostile to be told you can never speak of running this on an OS version > 2 years old. Ever. All attempts will be deleted" is "expecting endless support for free products that I'm not paying for or contributing to."
I reject your name-calling via a strawman, though I support the message.
I remember when they renamed python to python3 or something similar. A lot of people were unhappy, and the maintainer's response was a very rude deal-with-it. It's apparently how he behaves toward people in general.
At the time it felt pointlessly rude but now I realise that the man works for free, and gets to be the king of his own turf. Not all software projects need to be a direct democracy. He doesn't owe us anything.
Wasn’t python3 a breaking change that pedantically replaced print with print() breaking every pre-existing python file requiring it to be reworked before it would function? Seems like calling python 2.x python and 3.x python3 was the correct decision and saying “this is final” is also correct.
Your point about project owners having final word is well taken, but in this case possibly also objectively correct.
I don't remember the exact details, but it was a breaking change that got people upset. It's not really about who was right or wrong, but how it was communicated.
That person has repeatedly been very curt with people as a matter of policy.
Try interacting with them and you’ll know. If you just use it, (and your OS isn’t too old) then you wouldn’t feel it. And also good luck if they make some changes that affect you.
A better way to describe it might be contributor-hostile than user hostile. In a typical open source project, opening an issue is considered to be a contribution, a pull request is even better. Try doing any of these and be prepared to be harassed.
It is a very toxic open source project. Sadly homebrew cask is irreplaceable.
The last time I used MacPorts it fell out of popularity and did not have nearly as many packages as Homebrew had. It's unfortunate. Homebrew is dogshit slow.
homebrew the package manager that is literally built on git yet still doesn't have version pinning or versioning for most packages so that you have to host your own copies of public packages to use the old one?
And when they do support multiple versions, like MySQL, have fun with your data. All versions hardcode the same path in the service file. Your data is now accidentally upgraded and/or corrupted.
When I maintained an app that used homebrew for the Mac users, I kept my homebrew in a different, self contained path off the user’s path, and maintained my own repo of every package so I could pin versions and not break the user’s install.
Codifying this crap UX, always deploying head to a dev’s machine, setting packages on a dev’s computer and path in some privileged manner that I as a dev using the machine can’t control… it’s terrible.
I should have full control over the development packages on my machine, the environment, etc. fine, put some memory hog scanning crapware on there if it makes IT feel like they are doing something… but don’t touch my path and my dev environment
I used to like using homebrew on personal machines. But then as the person in charge of the dev environments at my company, I tried using homebrew packages for our devs but it just went horribly because homebrew don't have old versions.
- Different folks ran `brew install <foo>` at a different time? They may see different behavior
- I ran `brew install <foo>` after a coworker did? I may not be able to replicate whatever issues they are facing
- Someone new ran `brew install <foo>` on their new laptop? They may have an entirely separate major version of that library with breaking changes.
- Do I know if folks are using vulnerable, old packages? Nope!
- Does production use some database with version X, but homebrew only supports a client for version Y? Eh whatever, just have folks locally use version Y. What could possibly go wrong with using a different version locally vs in production.
I kept our own homebrew tap for a while and pinned versions. That was fine. But then I had to maintain that tap, and there wasn't any easy way I found for checking if the versions we kept in that tap had any vulnerabilities on any registry I could find.
Then I found Github Codespaces / devcontainers, switched everyone to use Linux inside Docker, used linux package managers to install pinned versions of everything we needed (using the same exact packages as we bundle into production), and scan my containers using a container vulnerability scanner nightly.
Instantly, 10+ hours of work per week for me vanished and I can now at least reproduce problems and fix them for everyone when they come up.
Because of docker performance issues on osx, I’m not looking to do that same for my engineering team and instead am looking at using nix.
I’m already using it for my personal work laptop and it is working well. Also nix allows me to configure host/user level tools such as shells or AWS-sso where docker would not. Building modules allows users to customize there configuration without blocking our tooling team from making changes to configs as Nix will just merge it all together.
