The debate surrounding the Codes of Conduct (CoC) adopted by Open Source projects may be reaching a turning point. In September 2025, a controversy erupted over the governance of RubyGems, a cornerstone of the Ruby ecosystem, sending significant ripples through the community. While not directly related, this turmoil served as a catalyst for two prominent figures, David Heinemeier Hansson (DHH), the creator of Ruby on Rails, and Eric S. Raymond (ESR), a former Open Source evangelist, to launch scathing critiques of modern CoC–particularly the Contributor Covenant–on X.
DHH condemned detailed and strict CoC like the Contributor Covenant as a “trojan horse” that should be purged from projects. ESR went even further, asserting that CoC are nothing more than a “tool for troublemakers” and that the best course of action is to delete them entirely from projects. While both individuals are often seen as controversial figures in the community, their views on this matter align closely with my own.
How did the CoC, once considered a tool to foster collaboration and maintain a healthy community, become the subject of such intense controversy? This article will historically trace the journey of CoC in open source, from their early days through their proliferation and transformation, to the adverse effects seen today, arguing why an excessive CoC is unnecessary for many Open Source projects. In conclusion, it will show that a return to the CoC’s origins–adopting norms that are right-sized for the scale and culture of individual projects–is the true foundation for a sustainable development community.
Note: This article is an English translation of a post originally written in Japanese. While it assumes a Japanese reader, I believe it may also be useful for an English-speaking audience.
The Code of Conduct was not something suddenly introduced from the outside for ideological purposes. It emerged as a practical solution to a tangible problem within Open Source communities: the tendency for technical disagreements to devolve into personal attacks, severely damaging a project’s overall productivity.
One of the first large-scale demonstrations of a CoC’s effectiveness can be traced back to the state of the Debian project in the early 2000s. At the time, Debian had a culture that maximized developer autonomy and lacked a strong, centralized decision-making body. As a result, maintainers of individual packages and features often adhered so rigidly to their own technical beliefs that it frequently led to stagnation in the project’s overall release schedule.
This structural problem was most evident in the long and troubled development of Debian 3.1, codenamed “sarge,” which was released in June 2005. Its predecessor, “woody,” had been released in July 2002, meaning nearly three years were spent on the sarge release. This prolonged delay symbolized the exhaustion from constant flame wars and the paralysis of the decision-making process within the Debian community.
Ubuntu, launched by Mark Shuttleworth in 2004, emerged as a direct answer to Debian’s stagnation and disarray. In addition to its technical promise of a “six-month release cycle,” Ubuntu adopted a CoC from its very inception to ensure the healthy operation of its community. Benjamin Mako Hill, who was deeply involved in the Debian project, played a central role in drafting this CoC. In his own words, the Ubuntu CoC was intentionally codified as a response to the “prickly interactions” he had experienced in other projects (presumably Debian). In short, Ubuntu’s CoC was born from a practical need: to maintain healthy project collaboration in order to maximize technical productivity. This fostered an atmosphere where many felt that “it’s easier to get things done in Ubuntu,” leading numerous developers to shift their activities from Debian to Ubuntu.
While the effectiveness of the CoC demonstrated by Ubuntu had spread to a few other projects, by the 2010s, the stage for this discussion shifted from online development mailing lists to offline technical conferences, from where it expanded rapidly. It was here that the purpose of the CoC began to pivot significantly, from improving overall “collaborative productivity” to encompassing “participant safety”.
The catalyst for this transformation was the Ada Initiative, a non-profit organization active from 2011 to 2015. The Ada Initiative highlighted harassment at technical conferences as a serious problem and strongly advocated for the adoption of anti-harassment policies, publishing a template to facilitate this. Conference codes of conduct, which had been nearly non-existent in most communities, quickly became standard industry practice thanks to the Ada Initiative’s efforts.
Then, in 2013, the “Donglegate” incident at PyCon, Python’s annual conference, decisively visualized the need for CoC. The incident began when a female attendee felt uncomfortable with what she perceived as a sexual joke involving the word “dongle” made by men sitting near her and posted their photo on Twitter. The affair culminated in both one of the men who made the joke and the woman who reported it losing their jobs, laying bare the reality that community conflicts could inflict serious, real-world damage on careers and that informal norms alone were insufficient to resolve such situations. In the aftermath, PyCon updated its policy to include the statement that “Public shaming can be counter-productive to building a strong community,” and the importance of CoC and their enforcement procedures became widely recognized.
Standardization and Mainstreaming via the Contributor Covenant
The two currents–the “CoC for collaborative productivity” pioneered by Ubuntu and the “CoC for safety” promoted by the Ada Initiative–converged and found their ultimate expression in the “Contributor Covenant,” created by Coraline Ada Ehmke in 2014. The Contributor Covenant was designed as a universal CoC template, not limited to any specific project or event. Its text explicitly lists protected attributes such as age, gender identity, ethnicity, and experience level, and encourages the use of “welcoming and inclusive language” while specifically defining unacceptable behaviors like “personal or political attacks” and “public or private harassment”. Furthermore, it includes detailed enforcement guidelines for investigating and rectifying reported violations, establishing a framework that resembles a legal document rather than a mere statement of principles.
Thanks to its comprehensiveness and ease of adoption, the Contributor Covenant spread like wildfire, eventually being adopted by tens of thousands of projects, including many IT companies and major open source initiatives. In 2018, Linus Torvalds himself apologized for his past aggressive behavior as the Linux kernel retired its traditional Code of Conflict in favor of the Contributor Covenant. This marked a symbolic turning point, and this heavyweight, standardized CoC has remained the mainstream model to this day.
Looking back at the history of the CoC, it is clear that its purpose has evolved in stages. It began as a “tool for collaborative productivity” to solve Debian’s dysfunction. Next, spurred by incidents at conferences, it evolved to include a “mechanism for ensuring safety” to protect participants. Finally, with the Contributor Covenant, it morphed into a “standard framework of ethical norms” that defines how a community should be and possesses a stronger legalistic force to compel it. The object of ESR’s and DHH’s criticism is not the practical tool of 2004, but this ethically and legally charged CoC that became dominant after 2014.
Though born from good intentions, the proliferation of strict CoC has introduced new and more severe problems into Open Source governance. The CoC, at times, has transformed from a shield that protects the community into a weapon that fuels internal power struggles and exhausts contributors. While a detailed and strictly enforced CoC may seem to guarantee fair community management in theory, in reality, its complexity can expose structural flaws in governance or create vulnerabilities that can be exploited by malicious actors. The adoption of the Contributor Covenant by the Linux kernel, for instance, was met with both praise and criticism and sparked political conflict in many projects.
Perhaps the most symbolic case is the shocking incident in November 2021, when the entire moderation team for the programming language Rust resigned. In their public statement, they cited the reason for their resignation as being “in protest of the Core Team placing themselves unaccountable to anyone but themselves,” which resulted in a situation where they were “unable to enforce the Rust Code of Conduct to the standards the community expects of us and to the standards we hold ourselves to”.
The heart of the problem lay in the governance structure. In the Rust project, members of the moderation team, responsible for enforcing the CoC, were appointed by the Core Team, the project’s highest decision-making body. This meant that the body enforcing the CoC was subordinate to the body that could potentially be judged by it. Under this structure, it was virtually impossible to conduct an independent and impartial investigation or ruling on an alleged violation involving a Core Team member. This incident starkly illustrates that no matter how noble a CoC may be, it becomes a hollow document that only creates friction if there is no independent governance structure capable of applying it fairly, even to the highest levels of project leadership. It stands as a classic example of a CoC failing as a check on power.
If the Rust case demonstrated the “powerlessness” of a CoC, the ongoing RubyGems incident–the very trigger for this debate–may illustrate how the discourse of governance, including CoC, can be abused as a “tool for seizing power.”
In this case, the non-profit organization Ruby Central, which operates the Ruby community’s infrastructure, is accused of seizing control of the RubyGems and Bundler GitHub organizations from long-time, unpaid maintainers without their consent, allegedly due to pressure from a major sponsor. The official reason cited by Ruby Central was the need to “safeguard the supply chain” and “strengthening our governance processes”–a legitimate and hard-to-oppose justification that carries a certain weight. However, the ousted maintainers claim that the move was, in reality, a centralized takeover driven by the interests of a corporate sponsor, a hostile takeover of the community. While an outsider like myself lacks sufficient evidence to definitively blame one side, if we consider the maintainers’ testimony, this case exposes a more malicious failure pattern: the rhetoric of strengthening governance, such as CoC enforcement or security assurance, can be used not to protect the community, but to strip it of its authority for the benefit of corporations or a select few in power.
The Rust and RubyGems cases reveal a paradox in CoC governance. A CoC that is powerful enough to curb the overreach of leadership is also powerful enough to be captured by that leadership (or external forces) and used as a tool to dominate the community. The very mechanism designed to protect the community can become the means to usurp its rights. A strict and powerful CoC inevitably requires a complex enforcement body. This body creates a new center of power within the project, and that power becomes exposed to political dynamics and the risk of a takeover. Consequently, making a CoC more complex can unintentionally expand the project’s political “attack surface.” Although this incident is about governance rather than the CoC itself, it suggests the danger of how the weight of norms and governance can become entangled with community division and corporate politics.
In response to this dysfunction, ESR and DHH have mounted a fundamental critique of the modern CoC paradigm. Though their approaches differ, they share the view that complex, bureaucratic CoC undermine the essence of open source.
ESR’s argument is clear, if somewhat radical. His advice comes in three parts: (1) Refuse to have a CoC. If you have one, delete it. (2) If you must have one for bureaucratic reasons, replace it with this one sentence: “If you are more annoying to work with than your contributions justify, you’ll be ejected.” (3) Attempts to get more specific than this will not work. They will only provide a control surface for troublemakers to manipulate. This position is based on pure meritocracy and consequentialism. The sole metric for evaluation is the net balance between the technical value a contributor brings and the social friction they cause. This is a model that entrusts project leaders with absolute authority to make the final judgment.
DHH’s critique, while appearing similarly strong at first glance, is more balanced. He calls the Contributor Covenant a “trojan horse” and, as an alternative, praises the “beautiful replacement that Matz put in place for Ruby”. The official Ruby CoC, which DHH describes as “beautiful,” is remarkably simple and consists of the following four basic principles:
- Participants are expected to be tolerant of opposing views.
- Participants must ensure that their language and actions are free from personal attacks and disparaging remarks.
- When interpreting the words and actions of others, participants should always assume good intentions.
- Behavior that could reasonably be considered harassment will not be tolerated.
The effectiveness of the Ruby CoC lies not just in what it says, but in what it does not say. There is no long list of protected attributes, no detailed regulations for a multi-stage enforcement process, and no legalistic terminology. In other words, the Ruby CoC is a statement of principles, not a legal statute. This approach is founded on a high degree of trust in the community, assuming that participants are well-intentioned adults and intervening only in cases of clear misconduct (harassment or personal attacks).
Strict CoC like the Contributor Covenant can be “weaponized” for political purposes or treated like a legal battle. Vague terms such as “political attacks” create significant room for interpretation, which in turn creates vulnerabilities. Furthermore, enforcement that presupposes official committees, investigation processes, and detailed record-keeping places an unwanted burden on the community. In contrast, the Ruby CoC relies heavily on community consensus to determine what constitutes a violation and depends on existing project leadership without bureaucratic processes.
In the international Ruby community, there is a guiding spirit known as MINASWAN (“Matz is nice and so we are nice”), which encourages participants to treat each other with consideration and dignity for the mutual well-being of developers and the community. Simply upholding a shared ideal can be sufficient to foster a culture of respect, without the need to explicitly codify detailed clauses or political ideologies, while remaining easy to administer.
As detailed in this article, the history of Debian and Ubuntu demonstrates that a basic code of conduct is, of course, necessary for large-scale collaboration. However, the subsequent evolution of the CoC has, in some respects, lost sight of its original purpose and introduced new problems to the Open Source community.
The proliferation of CoC like the Contributor Covenant may have been a historical inevitability, but has the pendulum swung too far from one extreme to the other? The widespread adoption of generic, heavyweight frameworks, typified by the Contributor Covenant, has arguably produced severe pathologies: an increase in bureaucratic operational costs, governance crises like the one seen in Rust, and a vulnerability to takeovers by corporations or special interest groups. These frameworks are designed on a premise of low trust in participants and carry the risk of stifling the vibrant, sometimes even sharp, technical debate that is the lifeblood of open source.
What is needed now is not the unthinking adoption of a one-size-fits-all template, but a “right-sized” approach tailored to the scale, culture, and goals of each individual project. There is no point in mimicking a massive project like the Linux kernel, which involves developers and large corporations from around the world. For most projects, the Ruby CoC is likely the ideal model. It is short, easy to understand, and principle-based. It focuses on prohibiting clear misconduct like harassment and personal attacks, while trusting the community’s self-correcting mechanisms to handle technical disagreements. This balance is the optimal solution for many projects. It may seem old-fashioned, but in the end, this is the most robust form of a norm.
Open Source projects should reclaim their autonomy regarding CoC. A CoC should be a simple “shield” to protect the community’s core function of building software, not a complex “weapon” that can be turned against the community itself. For the vast majority of Open Source projects, a CoC that fits into just a few lines is not merely sufficient–it is superior. For the longer it is, the more it suggests a past where such things were necessary.
