Time will tell how the maintainers of the fork will react to similar criticism. It's very easy to stand by the sidelines as a community member and to piss on the leadership, it's an entirely different thing to be in that position yourself. Ask GvR what it feels like to herd a band of cats over a period of decades. You need to be in it for the long run and you need to be utterly dedicated to make this really work.

> You need to be in it for the long run and you need to be utterly dedicated to make this really work.

There also has to be an escape hatch to make this work.

E.g., Linus can say that the __is_constexpr preprocessor hack is the product of a demented mind, and he'll merge that absolute monstrosity thanking the contributor.

As a leader you get the contributor community that you get. You can either make the development process workable for them, or you can risk the project languishing/forking.

Put another way: if a leader's concept of what their project ought to be/become veers too far from what the community is actively coding up to be merged, it's not going to go well.

No idea if this applies to D. But I'm absolutely certain Python's dev process has had plenty of escape hatches for resolving development issues. (And I'd guess there are also projects that have too many escape hatches, but I'm guessing that probably doesn't apply to D.)

I haven't seen any of that tbh, I have seen a lot of disrespect come in direction of Walter and him responding in a gracious way actually. Criticism existence means it is allowed and thus is "open".

I would never fault Walters graciousness, rather that I and others just find it difficult to establish a common ground quite often. You can see this very clearly in the discussion of the SQL applications of the string interpolation proposals.