CoCs like all codes of law, exist to have something to point to when it is decided that you did something wrong. They also exist as a signal, both to attract people who agree with it and to deter those who oppose it.
Ideally a community should not need this. But most so-called communities are not communities. Membership and participation can be fleeting so there will be a constant influx and loss of members and participants, all of whom hold different values and some of whom the original founders would have never invited in the first place.
So the risk is that a project built by people sharing a common set of values may be recuperated by people diametrically opposed to those values. Defining those values helps with that. For the primary demographic of HN, usually "don't be a dick" suffices for this. The problem is that lists of values don't provide an enforcement mechanism.
This means you likely end up with one of two situations after a preexisting project adopts a CoC: either nothing changes because the code of conduct is not enforced (or only inconsistently), or nothing changes because everybody already involved in the project agrees with it and those e.g. throwing slurs at existing members or otherwise harrassing them would have been kicked out anyway.
The problem is when projects that don't have a strong ideological/emotional investment in codifying a set of shared values (or lack a consistently shared set of values altogether) treat a CoC like a DEI program and just bolt it onto their project to tick a box and stop people from complaining. This misleads those who treat CoCs seriously into joining while also weakening the signalling effect of CoCs for other projects. In my experience this is the case for most OSS projects and in the worst cases it leads to overeager admins enforcing the letter of the law because there really was no spirit of the law to begin with, going through the authoritarian motions of enforcement without any ulterior purpose - and of course these projects will still selectively spare particularly influential individuals regardless of their misdeeds.
Ideally a community should not need this. But most so-called communities are not communities. Membership and participation can be fleeting so there will be a constant influx and loss of members and participants, all of whom hold different values and some of whom the original founders would have never invited in the first place.
So the risk is that a project built by people sharing a common set of values may be recuperated by people diametrically opposed to those values. Defining those values helps with that. For the primary demographic of HN, usually "don't be a dick" suffices for this. The problem is that lists of values don't provide an enforcement mechanism.
This means you likely end up with one of two situations after a preexisting project adopts a CoC: either nothing changes because the code of conduct is not enforced (or only inconsistently), or nothing changes because everybody already involved in the project agrees with it and those e.g. throwing slurs at existing members or otherwise harrassing them would have been kicked out anyway.
The problem is when projects that don't have a strong ideological/emotional investment in codifying a set of shared values (or lack a consistently shared set of values altogether) treat a CoC like a DEI program and just bolt it onto their project to tick a box and stop people from complaining. This misleads those who treat CoCs seriously into joining while also weakening the signalling effect of CoCs for other projects. In my experience this is the case for most OSS projects and in the worst cases it leads to overeager admins enforcing the letter of the law because there really was no spirit of the law to begin with, going through the authoritarian motions of enforcement without any ulterior purpose - and of course these projects will still selectively spare particularly influential individuals regardless of their misdeeds.