It feels very close to “right to repair”. The coffee grinder you bought came as a single package but it has burrs, gears, machine screws, a motor, etc. If one of those components fails, we should be able to replace it ourselves and as such they should be documented.

The laptop has various pieces of hardware in it and corresponding drivers in macOS to make them tick. Did we buy the hardware and the drivers as an inseparable package, or should we be provided with the manual to make one component work when the other breaks, be that either third party trackpads or third party (Linux) drivers.

Apple might argue that drivers, unlike gears or motors, will never wear down and fail. They won’t need repairing so you don’t get to know how they work. Does right to repair only apply to products that could ever need repairing? Does it also extend to knowing how your purchased product is built so that you could repair it?

Maybe we’ll see a test case some day when a cosmic ray blows out /System/Trackpad.kext and a litigant applies to a court for the documentation to repair their laptop — to write their own driver!

(Or vice versa: a manufacturer of coffee grinders arguing in court that they are exempt from right-to-repair because they repair their machines for free at their Genius Espresso Bar.)

The real answer is probably simpler than anyone here is making it. Apple hardware margins are healthy enough that selling macbooks to linux users is pure profit, so no services lock-in needed. However, the moment they officially acknowledge Linux support, then it becomes a support surface. Every kernel panic becomes a genius bar visit. Every driver bug becomes a tweet at @AppleSupport. It's the value of plausible deniability. The Asahi team being unofficial is actually the best possible outcome for Apple in that they get hardware sales to Linux enthusiasts without any support burden.

Little to no monetary benefit, hardware changes now need to be documented for Linux, loudest and most critical users but smallest volume.

One of the reasons I can see is it’s much easier to say “we don’t play this game” than get a lot of negative press for selective openness and breaking compatibility of non-public interfaces. Maybe it’s even more important internally, as it enables new kind of internal discussions distracting from priority work.

> Focus is about saying no to 100 good ideas so you can pursue one great idea.

Important context to understand why.

I was trying to come up with a response but you're right. It would be easy for Apple and Apple would get so much goodwill from the community in return.

I imagine the real reason is that if they change things they now have an obligation to promptly share technical docs and if they're slow people will whine and bitch online about them. Not worth it. They have zero to gain (and I say this as someone who would love to dual boot Linux on my M4).

The cynical take is that they make a shit ton of money from services and Linux running on a MacBook won’t help them do that.

> I don't understand

We really need to retire this phrase, it’s become a humblebrag way of calling the other party delusional without even trying to understand.

The list here though is long: priorities, accuracy concerns, blurring the line on official support, IP restrictions with third parties (even Apple uses plenty of licensed cores), etc.