In fact, it's very different. You, as a single person might not care about a patch you contributed, or a small utility you have written. However, not everyone thinks like you (e.g.: Me, as Fig. 1a).
When you put all this spectrum of views under a project, it becomes another thing to manage these expectations and what people want from the project in the end. When big shifts start to occur, people will react differently.
When it's a project people love and contribute with the expectation of keeping things the way it's, and the things change, people won't be happy. See: Go's opt-out by default telemetry proposal, HashiCorp's and Docker's license changes, Google's persistent push to block ad-blockers, Microsoft's breaking of VSCodium in subtle ways, etc.
So it's much more than you and your code, esp. in projects like these. I think licensing them with licenses allowing rug-pulls (esp. under community itself), is a red-flag in many cases.
I also put the code I develop myself out there for the betterment of all, but it's licensed with GPL, because I don't want someone take and run away with it for "betterment of themselves rather than everyone". Now, you might not agree with me, and I respect that, but that's the terms I put on my code. As I always say. If you like it that much, reimplement it. I don't care.
Conversely, I contribute to a project which allows no GPL code, because it's designed to be both open, and be customized and closed at the same time. We put it out very openly in the beginning, because that license is a requirement for the use case we (as in ~10 countries) have, and MIT is the best one for our use case.
...but, Ladybird is not that. The project tries to build an important, foundational commodity item. Allowing it to be taken private is a mistake, IMO.