Hacker Newsnew | past | comments | ask | show | jobs | submit | mikemcquaid's commentslogin

If multiple people are assuming bad faith: perhaps you should adjust your communication in future rather than trying to change their mind. An apology wouldn’t hurt, either.


> If multiple people are assuming bad faith

It’s not “multiple people”, I asked that of one person multiple times.

And respectfully Mike, you’re not the person to be schooling others on respectful communication and requesting apologies. You are incredibly abrasive, often rude, and the reason many people avoid Homebrew altogether. You’re repeatedly criticised for “being a dick” or an “asshole” (I personally would use neither), including on HN submissions. You are very far from the paragon you are exalting.

I used to defend you when I contributed more regularly to Homebrew, but as time went on I now only ever find you in contexts of trading insults and never giving an inch or admitting wrongdoing. Even when it seems you are, you always find a way to end with some subtle jab at the other person.

For sure I could do better. I try and often fail, and that’s how we grow. But it is profoundly hypocritical of you to act like you are an example.

No shade on most other Homebrew maintainers, though, and thank you nonetheless for all the work you do.


You will find many examples of me apologising and changing on Homebrew’s issue tracker, they just tend to not be the cases that people decide to bring up here. It’s unsurprising to me that 16 years of working on Homebrew most days has a bunch of suboptimal communication in that time. I am not perfect but also never claimed to be.

Attacking my communication here doesn’t help you. I got involved in this thread after seeing someone saying they regret sharing this (interesting) project from your reaction and feeling the same way after your reaction to something I’ve shared. Feel free to ignore me as is your right.


Ignoring the specifics, your first paragraph applies to me. You simply decided to assume it doesn’t and stoke a fire which, as far as I was concerned, was already out.

https://news.ycombinator.com/item?id=46079583

https://news.ycombinator.com/item?id=43092745

> Feel free to ignore me as is your right.

Please don’t do that. It’s not the first time I see it. You come in, say what you want, then leave and say “you can ignore it”. So can you! You could’ve ignored it. I guarantee you that the overwhelming majority of times you do that, you’ll just make the other person mad and the situation worse. If you want to do better, and I believe you do, those backhanded dismissals need to stop.


I did not reread the whole thread before replying and should have done that at which point I would have seen your apology. I apologise for not doing that. Good on you for apologising. I will ignore more in future.


Don’t. It’s a cool idea and vibe coding it doesn’t make it less interesting. You don’t owe anyone anything and the mean behaviour you’re in receipt of says more about them than you.


With how Homebrew manages issues: debates about this belong in Homebrew/discussions, not on the issue tracker. That's why they get locked.


There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way.

In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.

As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.

Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.


Thanks for the response. Yes, I think some clarity about the purpose of the issue tracker would help someone unfamiliar with the project's maintenance better understand the conduct of the maintainers. If it is only for coordination of work tasks and not discussion of whether the work should be done, it would seem natural to have somewhere else where the discussion of the merits occurs.

> drive-by negativity by non-code-contributor users is the biggest existential threat

I do believe this, and it's what I was getting at with my "conditions a knee-jerk asshole response" comment. From the outside, I saw someone who wasn't being negative, but just seemed to have unaddressed concerns about the impact of the change. You, however, have been conditioned by hostile users over your many years of work to interpret this as negativity, because other, ruder people pile on to the valid concern in unhelpful ways, or the person with the concern wasn't willing to listen at all and just used a veneer of calm rationality to be a stick in the mud.

The point is, I get why you would be this way, but also that it doesn't look very good from the outside looking in. I know that you are doing unpaid labor and so nothing is owed, but still, both can be true.

I know some people don't like it, but I've always found discussions that are locked to collaborators only to be totally understandable for this reason. If you find yourself making "I know more about x than you ever will" comments to a person, you should probably instead just disregard them and carry on. Likewise, you do know more about x than I ever will, so you should probably just disregard me and carry on.


> There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.

You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.

> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.

If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.


> You could have just said this

Yup, you're right, I should have. We will adjust the CONTRIBUTING.md accordingly.

> If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.

I didn't say every OSS project, I said projects like Homebrew. I know that Homebrew would be dead without many of my personal interventions. You can believe me or not but, unless you're a Homebrew maintainer, it's unlikely your opinion about what happens behind the scenes is informed.


> As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.

your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.


I don't think I am a dick, I guess that went without saying.

I'll take critique from other maintainers who have done as much or more open source work for similar returns over similar time periods. Funnily enough, I'm friends with many, and they are supportive the vast majority of the time instead of critical. Maybe that's because they can relate and you cannot.


No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.

The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)


If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.


Your users don't owe you anything. Act "nice" and you'll get "nice" back. Act "blunt" and you'll get "blunt" back.


This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.


> Maybe that's because they can relate and you cannot.

Now you're deflecting. I passed no judgement i made an observation of your statement and you took it personally.


Homebrew Project Leader here.

Yes, this only affects casks, not formulae, whether formulae are built from source or use Homebrew's bottles (binary packages) or bottles from taps.


As an open-source developer, is there a way to have my apps pass Gatekeeper without paying the $100/year Apple ransom and notarizing them? I think it’s the crux of the problem.

As I’m writing these lines, Homebrew has 7656 casks in the official cask tap[1]. I’m not sure exactly how many of those are unsigned but if we assume 4000 then signing them all would be an additional $400,000/year extorted by Apple from the open-source community.

Defining HOMEBREW_CASK_OPTS=--no-quarantine in my shell configuration was a good way to avoid this issue without having to manually run dozens of xattr -d every time I run brew upgrade.

Now my only option left is to pull the trigger and make my system globally less secure: sudo spctl --master-disable

Unfortunately, disabling Gatekeeper doesn’t just allow unsigned apps to run: it also completely disable all verifications for signed apps: notarization checks, revocation checks, trust evaluation checks.

[1] curl https://formulae.brew.sh/api/cask.json | jq 'length'


You can make your own tap (which is just a GitHub repo) and manually clear the quarantine flag in a postflight step. E.g., see https://github.com/alacritty/alacritty/issues/8749

Users will need to `brew install myorg/mytap/appname` instead of just `brew install appname`, but I think that's the only real option at this point.


I’m worried app maintainers will start to indiscriminately run xattr -d no matter if the user actually wants that or not. There will not be any kind of standard way to do that so the experience will be very inconsistent between casks…

I hope Homebrew will start supporting hooks at a later point because it would allow users to automatically de-quarantine instead of having all maintainers add xattr -d garbage commands to all their casks.


Yes, active support dropped for macOS Intel September 26, won’t work at all on macOS Intel September 27.

We’d love to support everything indefinitely but lack the resources as a volunteer run open source project to do so, particularly when GitHub Actions and macOS itself will be stopping elements of their support for macOS Intel on similar timescales.


Homebrew Project Leader here. Happy to answer any questions.


Is the internal API mentioned something that can be used for a private tap?


No(t yet). It's a slimmer version of the existing JSON API that's similarly only used by homebrew/core and homebrew/cask for now, mainly because they are so huge that using Git for this had very poor performance.


Sort of?

The Glaswegian taxi driver may not consider themself to be speaking a different language but, if speaking to another local and leaving aside pronunciation, they’d use words, phrases and even grammar that’s incomprehensible to someone with no experience with Scots.

I’m a “posh Scot”, raised middle class in Edinburgh so my accent is minimal and thickens up or softens depending on who I’m speaking to. Even for me, there’s a lot of words, phrases and ways of speaking I’ve had to adjust to be consistently understood by American coworkers when over the last 10+ years.


Brits do the same. At best it is a dialect at worst an accent. A lot of (most of) Scots is still English but spoken with different grammar or unfamiliar phrases and unfamiliar pronunciation.

Sort of like extreme cockney rhyming slang or for a more modern example thick BME* full of slang.

* = British Multicultural English, think fam n blud, lots of Jamaican english influence plus south east asian influence.


As someone who spent a bunch of time talking before and after this all went down with current and past RubyGems maintainers, RubyCentral employees, Gem.coop maintainers and Ruby Core folks: this seems like the best outcome that was actually attainable.

I've been working on Homebrew for 16 years and leading it for some proportion of that and this all "smells" like a more sustainable long-term solution than anything we've seen happen in the last year. Some proposals sounded nicer but were not going to be acceptable to one or more sides.

Ruby already provides a vendored version of RubyGems and (more recently) Bundler so this seems appropriate. It also separates the "running a web service" which has guaranteed hosting costs, requires on-call, etc. from "running an open source CLI/library" which has no guaranteed costs.

It will be interesting to see what the Gem.coop folks do now (disclaimer: I helped them with their governance process). If there's some competition for rubygems.org as a server implementation that feels like a good thing for the community overall.

Good luck to all involved on all sides.


Thank you for your work in this arena and trying to add clarity. As a business owner and longtime rubyist, I'm very happy Ruby Core is taking stewardship here and that maybe we can put this tempest in a teapot behind us.


Lots of RubyGems chat recently, very little data. I've used Homebrew's tooling to analyse RubyGems public GitHub data and posted it here.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: