Why Heavy Codes of Conduct are Unnecessary for Most Open Source Projects Author: Shuji Sado Published: September 30, 2025 Source: Open Source Guy --- Overview This article critically examines the current trend of adopting heavy, detailed Codes of Conduct (CoC) in Open Source projects. Triggered by controversies in RubyGems governance and critiques by prominent figures like David Heinemeier Hansson (DHH) and Eric S. Raymond (ESR), it argues that strict CoCs often introduce more problems than they solve and that many projects benefit more from simple, principle-based guidelines. --- Historical Context and Evolution of Codes of Conduct in Open Source Origins: Collaborative Productivity Tool Early 2000s Debian project suffered stagnation due to technical conflicts escalating into personal disputes. Debian 3.1 ("sarge") was delayed nearly three years, illustrating community dysfunction. Ubuntu, launched in 2004 by Mark Shuttleworth, adopted a CoC from inception, drafted by Benjamin Mako Hill, to foster healthy collaboration and maintain a regular six-month release cycle. This practical CoC improved developer interactions and project productivity, leading many to migrate from Debian to Ubuntu. Shift to Safety at Conferences By the 2010s, CoCs expanded from online communities to technical conferences. The Ada Initiative (2011-2015) pushed for anti-harassment policies at conferences. The 2013 "Donglegate" incident at PyCon made the need for formal CoC enforcement widely apparent. This broadened CoC purpose from collaboration to ensuring safety and professional behavior. Standardization: The Contributor Covenant Created in 2014 by Coraline Ada Ehmke, the Contributor Covenant combined collaboration and safety purposes. It includes lists of protected attributes and defines unacceptable behaviors, with legalistic enforcement guidelines. Adopted by tens of thousands of open-source projects and major companies. In 2018, Linux kernel replaced its "Code of Conflict" with the Contributor Covenant, marking broad acceptance of this heavyweight model. --- Problems with Heavy Codes of Conduct Complex Governance Issues Complex CoCs often lead to bureaucratic overhead and internal political conflicts. Rust moderation team mass resignation (2021): Due to inability to enforce CoC impartially, caused by governance structure problems (moderators appointed by project leaders). Demonstrates that without independent enforcement, a CoC is ineffective or weaponized. Politicization and Power Struggles The RubyGems incident: Ruby Central, backed by a major sponsor, took control from unpaid maintainers under the guise of governance strengthening. Shows how CoC and governance rhetoric may be manipulated as tools for corporate takeover or power grabs, not protection. Risk of Weaponization Detailed CoCs can be exploited by "troublemakers" to create disputes. Complex enforcement bodies become new power centers vulnerable to political influence. Creates a paradox: powerful enough CoC to curb leaders can also be seized by those leaders or outsiders. --- Critiques by ESR and DHH Eric S. Raymond (ESR) Advocates removing CoCs entirely or replacing them with a simple policy: "If you are more annoying to work with than your contributions justify, you’ll be ejected." Rejects detailed rules as manipulable tools that undermine meritocracy and community health. Supports a utilitarian merit-based evaluation trusted to project leaders. David Heinemeier Hansson (DHH) Criticizes the Contributor Covenant as a "trojan horse." Praises Ruby’s simple CoC, which includes four core principles: Tolerance for opposing views. No personal attacks or disparagement. Assume good intentions when interpreting others. No toleration of harassment. Ruby's CoC relies on community trust and simple