I'm not saying he must go; there are alternatives. More like he should be insulated from managerial decisions until he actually has the credentials and social skills that the job requires.
This is a cultural flaw that exists in pretty much every CS department, big and small. There is a default assumption among computer scientists that we do not need bureaucracy or HR. This comes from several sources: the hacker culture around MIT, CMU, and Berkeley was deeply entrenched in the hippie counter-culture of the 1970s; the general absence of women in the field (especially declining during the early decades of the open source movement) somewhat averts one of the most common categories of HR problems; and the paperwork required by external offices and departments tends to be a matter of "following instructions" in a very programming-like way, which goes miles to reinforcing the belief that bureaucracy is merely a kind of programming for non-programmers. (Relatedly, the US banned freelance programming contractors because it feared they would cheat on their taxes, because of a general paranoia about hackers finding loopholes. The actual data suggests programmers have an above-average rate of honesty and obedience when filing.)
So we pretty much universally skip over all the hard-earned lessons from other organizations about the value of managers as diplomats and intermediaries. Fred Brooks made this worse; the Mythical Man-Month demonstrates that traditional corporate structures are inefficient for programming, which we take as validation that we should not wear any yoke that chafes. But it doesn't do or say anything about the baby in that bathwater; it assumes that all programmers are perfectly rational agents with no interpersonal difficulties or competing agendas, working toward the same ends.
The reality is that humans, being humans, are always flawed people, and often need various forms of managing, whether it's encouragement, a sounding board, or policing. Without managers to act as referees, all large open source projects are basically voluntary treadmills: work until you burn out, but only when you feel like it. Some of these duties end up on the shoulders of founders and project leads, but since those people are just programmers themselves, they will invariably be mismatched to the job, and will themselves encounter burnout as they must struggle with the burdens of pretending to be extraverts for the good of the rest of the team.
I don't think codes of conduct are the answer, not really. A code of conduct cannot provide any of the positive benefits of management, nor can it respect the nuances of context. I admit that I think they are well-intentioned, but they're also a half-assed libertarian band-aid for a deep part of the human condition that requires real talent to treat properly.