> Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed.
Not really. Just like shoplifting isn't a motivator for putting everything behind the counter in a store. The cure could be worse than the disease.
> For distributed software development processes, the only thing that works are hard boundaries.
Definitely not true. Opensource has existed for a really long time without a two-key system. Many projects (besides this one) still have big sets of people with commit bits. I'd go so far as to say that almost all projects with a core team size greater than one has some amount of this, with very very few exceptions.
Not everyone needs protections as if they are covered by Sarbanes-Oxley (SOX).
And these projects work just fine.
In fact, it's not even desirable in most cases. You have to take development velocity into account, too. "It must never be possible to unilaterally commit to the main repo" is not the value the project brings to the world. It's a means to deliver the actual value. And it's not the only one. So there are always tradeoffs.
Having worked under mandated requirements (legal and contractual) such as this, I can tell you that it's not without big costs, costs that opensource projects would rather spend on other things. Especially since it's detectable. Preventable is usually not worth the extra costs.
> No hard boundary -> implicitly tolerated.
Of course that's not true. Not in any context. You don't go to someone's house and flip their furniture, and say that not only was the furniture not nailed down, it wasn't even part of the ToS for entering your house, and in any case the door was unlocked.
A project without a CoC is obviously not implying that you can be a nazi or sexually harass.
"What is not prevented is permitted" has never been true in the whole history of humanity, and there have always been repercussions for what you did.
I've been a sysadmin with root access. That doesn't in any way make it implicitly tolerated that I read people's emails and home directories.
> Merging changes without review shouldn't be possible.
Ideally yes. But it's more convenience than security. E.g. your example about having pre-merge testing decreases the toil of maintainers having to deal with test-breaking code being merged. I.e. having to roll it back, and deal with any merge conflicts during rollbacks.
But by your logic of "no hard boundary -> implicitly tolerated" this means I could change the code to detect if it's running in a test, and do something else. There's no hard boundary, but will obviously not be tolerated.