This document is largely taken from/inspired by John A. De Goes. More specifically, the articles, “ZIO Professionalism”, “Big Tent”, and “Travis Brown, Abuser”. Without his insight, this guideline would not be where it is today.
Manifold Finance (and by extension, OpenMEV) supports the right of every OSS engineer/developer to contribute on their terms, whatever those terms may be. Non-paying users of free software should not get to dictate these terms.
Moreover, OpenMEV’s stated objective of being a credible neutral org means that we must explicitly codify and formalize our ideals so that as it ‘expands’, there is a codified expectation of behavior from all contributors. See ‘Conquest’s Second Law’
There is an ongoing effort to corrupt effort the fundamental premises of the open-source culture. Instead of meritocracy and “show me the code”; we are now urged to behave so that no one will ever feel uncomfortable.
The effect – the intended effect – is to diminish the prestige and autonomy of people who do the work – write the code – in favor of self-appointed tone-policers. In the process, the freedom to speak necessary truths even when how they are expressed is unpleasant is being gradually strangled.
This is undesirable as it both directly damages our self-correction process – and in its second-order effects. The habit of institutional tone policing, even when well-intentioned, too easily slides into the active censorship of disfavored views. –The Right to be Rude
The cost of a culture in which avoiding offense trumps the liberty to speak is that subverters control the discourse. As such we must not internalize anticipatory surrender to these subverters.
Everyone is conservative about what he knows best.
Any organization not explicitly right-wing sooner or later becomes left-wing.
The simplest way to explain the behavior of any bureaucratic organization is to assume that it is controlled by a cabal of its enemies.
We can take this ‘Second Law’ in the contrapositive argument to mean:
Any organization that does not wish to end up left-wing must become explicitly and constitutionally right-wing.
Which we can reduce to the following principle:
Any organization that does not wish to end up corrupted by ideological malcontents must explicitly codify and aggressively enforce its ideals.
Any organization that does not wish to end up corrupted by ideological malcontents must explicitly codify and aggressively enforce its ideals. As an organization grows and becomes more complex, it ends up acting primarily to ensure its perpetuation. The purpose for which it was founded becomes secondary to its survival. In fact, for many in the organization, possibly the vast majority, its continued survival becomes confused with the purpose it was originally founded to deliver. This can lead to behaviors that seem rational when viewed from the perspective of perpetuating the organization but look counter-intuitive when considered from the perspective of what the organization ostensibly exists to do. [^3, Tracking down conquests’ law on organizations](Tracking down Conquest’s law on organisations – Vogel Wakefield)
We must recognize that the actions of other organizations, protocols, etc. may have undesirable side effects on the OpenMEV community (and Ethereum at large):
- They undermine the trust that end-users and companies place in Ethereum
- They increase the risk involved in deploying solutions based on Ethereum
- They decrease the network value of Ethereum
- They make OpenMEV look unprofessional to many developers, especially compared to the Ethereum/other ecosystems where major OSS projects would never behave in such a fashion
Effective immediately, OpenMEV shall codify and will support the following:
Pro-Community. All OpenMEV projects will gladly accept and host integrations for Flashbots, Eden Network, and other MEV or EVM ecosystems, without consideration of the relationships, dispositions, or politics between these projects and those ecosystems, and they will provide non-discriminatory support for end-users, regardless of their disposition to or affiliation or association with other OpenMEV community members or ecosystems.
pro-community, as OpenMEV hosts integrations for Sushiswap projects swaps and bentobox, and hosts integrations for OlympusDAO,LayerZero to date. Conflicting incentives should be considered and debated if it is possible that adding support for another project would conflict with existing integrations. However, I believe that making this behavior official will further increase trust and expand integrations, and also clearly set expectations for new projects being integrated into the OpenMEV solution sets.
Pro-Professionalism. Although behavior within the OpenMEV organization projects is already governed by the OpenMEV Code of Conduct, I want to strengthen this code of conduct by making it clear that ad hominem and career sabotage have no place within the community. Projects in the OpenMEV organization exist only to help engineers and developers solve problems, regardless of their religion, political affiliation, race, or disposition to or affiliation or association with other OpenMEV community members or ecosystems.
pro-professionalism, within OpenMEV official spaces (GitHub, Discourse, etc.), I have only ever seen welcoming, inclusive, and non-discriminatory behavior, without ad hominem or career sabotage. But explicitly committing to this high standard of professionalism can only help to set expectations and provide guidance for everyone as the organization continues to grow.
It is not necessary that open source contributors have the same views or even like each other. We must put Ethereum first, and by being pro-community and pro-professionalism, we can find a way to co-exist peacefully inside this big tent, and together, we can, in different ways and with different audiences, show the world that Ethereum is a force to reckon with.
- No well-actually’s
- No feigning surprise
- No back-seat driving
- No subtle -isms
- Remember that everyone was new to Ethereum at some point.
These rules are designed to help all of us build a pleasant, productive, and robust community. Part of being a credible neutral environment is having a baseline of interactions so that the environment does not introduce undesirable effects (social, political, drama, etc.)
Warn the users about what’s buggy and unstable in your release notes and the rest of your documentation.
Document your assumptions where the user can see them.
ENGINEERING NOTESsomewhere accessible.
Make your build reproducible, or offer a packaged distribution of your code. Consider using nix.
This document is distributed under a Creative Commons Attribution-ShareAlike license.
Citations and Attributions
The Scala Community, The Scala Code of Conduct | The Scala Programming Language; 2022 June 10
The ZIO Community, ZIO · GitHub; 2022 June 10
The Rust Code of Conduct, Code of conduct - Rust Programming Language 2022 June 10
The Node.js Policy on Trolling, Policy on Trolling
“ZIO Professionalism”, 2022 June 10
“Big Tent”. 2022 June 10
“Travis Brown, Abuser”. 2022 June 10
“The Right to be Rude”, 2022 July 01
“Tracking down Conquest’s law on organisations”, Martin Vogel, 2022 July 01
DerbyCon2019 - Every Beginning has an End, DerbyCon Team.