Earlier this month, I asked whether the WordPress community should quit Russia by participating in corporate blackouts that were, at that time, just starting to take hold. Most for-profit companies have now made the decision to leave, with Visa and Mastercard forcing many companies’ hands, since it’s more or less impossible for Russian residents to make international transactions today.
Two weeks ago, some readers challenged whether this question was relevant to WordPress at all – and yesterday, we got our answer in the form of a troll-ish plugin that added a “Z” (a Russian pro-war symbol) to a website to “support” the Russian war effort. It was similar (and perhaps a response to) plugins that add a Ukrainian flag to a WordPress site, three of which have been added to the directory in the past few weeks.
The WordPress.org team, led by Executive Director Josepha Haden Chomphosy, removed the plugin within a few hours of it being brought to their attention by community members on both Twitter and Slack – a decision that I agree with, but also one that highlights the challenges of working in the open-source world when the actual world is at war.
This episode shows us that the assumptions we’ve become accustomed to as open-source software developers – assumptions that were almost entirely crafted during 30 years of relative peace and globalization – no longer work in the new world that we’ve all been thrust into by Russia’s invasion of Ukraine.
Open source was built for a post-war world
Open source was conceived as something close to a borderless, leaderless society, where free expression and widespread participation are the cornerstones of a successful project and community. Many organizations, including WordPress, are built on the idea that the starfish (a decentralized system) is stronger, more creative and more resilient than the spider (a centralized system). Part of being a successful starfish organization is giving everyone the freedom to contribute, and thus being relatively lenient in terms of policing community behavior. Open-source software communities are well positioned to be egalitarian and libertarian because openness is their secret sauce, and this is a stark contrast to most for-profit, hierarchical corporations, who (despite what their public-relations teams want us to think) tend to be quite strict about their employees’ behavior. This free spirit also runs through our Understrap theme framework community, which includes scores of contributors and more than 100,000 end users.
This skew toward an open, egalitarian community is one reason why the Code of Conduct and Plugin Guidelines that govern the WordPress.org directory are relatively vague – open source is built to encourage participation, not police the details. The Plugin Guidelines prohibit “morally offensive” behavior, but the section that includes that prohibition is clearly aimed more at things like black-hat SEO and phishing. The clause wasn’t written with people blowing up children’s hospitals in mind.
In fact, there’s nothing in the guidelines that clearly, explicitly prohibits a plugin from supporting a brutal invasion. Haden Chomphosy correctly describes the Z as “an emerging symbol of hate and violence,” but the words “hate” and “violence” do not appear in the guidelines (though abusive, harassing and discriminatory behavior are explicitly prohibited). Haden Chomphosy acknowledges that the guidelines don’t serve us well in this situation, and that the initial reviewers apparently considered the plugin’s support of Russia a “gray area” in the rules. The best the WordPress team could do was cite the request that everyone “be kind, helpful, and respectful” as their reasoning for removing the plugin.
This was a good solution in the moment, but it’s also a red flag that we need to rethink the community guidelines from the ground up.
Rewriting the rules
Shortly after we acquired the Understrap open-source theme framework, we embarked on a project to improve upon our community code of conduct. I found the popular templates, like the Contributor Covenant, to be a good start but so full of gray areas as to be almost useless in a really serious situation. By the same token, I think one of the big signs that the Plugin Guidelines failed us this week is that, ultimately, the boss had to make a judgement call. (I think it was the right call, but there are certainly many people in the community who think that’s debatable.)
A good Code of Conduct doesn’t leave important decisions up to in-the-moment judgement calls. Instead, it codifies almost everything, and constrains the boss in moments of crisis, forcing the person in charge to think about specifics in advance and win consensus before the crisis. Obviously, you can’t predict every future problem, but we could do a lot better than the sparse guidelines we have today.
We rewrote the Understrap Code of Conduct from scratch with this level of specificity and thoughtfulness as our main goal. I wanted to make sure that we removed as much gray area as possible, and provided reasonable guidelines on what to expect from the gray areas that we couldn’t eliminate. A gray area can be exploited by a bad actor, but usually when someone is being intentionally malicious, it’s obvious enough that reasonable people agree that bad actor should be banned or sanctioned in some way.
The real problem with gray area is that it makes good people look bad because they’re working with unclear and confusing rules. For example, I have no doubt that the WordPress contributors who initially reviewed the plugin are good people who were doing their best to make a smart decision in a challenging situation. It’s certainly not illegal in the United States to put a Z on your web site, and they may not even have been fully aware of the nascent meaning of the Z symbol. However, the vague and incomplete rules made it impossible for them to do their job, and eventually the buck had to be passed to the executive director for a judgement call that was made with minimal support from the written rules.
When we acquired Understrap, one of the gray area challenges we had was how much profanity should be allowed in our GitHub community. Things had been extremely lax before, and my opinion was that we should treat the public GitHub discussion as a “professional workplace,” which to me meant little to no swearing and certainly no personal attacks. However, the gray area stung me when I tried to enforce my new assumptions. Not only did we not all agree on what “professional” meant, but we had community members from all around the world (including many for whom English was a second language and who had different office norms), as well as neurodiverse community members who worried that they would struggle with situations where they had to strike the right balance in a joke or nuanced conversation, potentially running afoul of my new standards without even realizing it.
My vague idea of “professionalism” just didn’t work for the community, and the gray area put us at odds with each other for no good reason. Something similar happened in the WordPress and Post Status Slack channels where the plugin was discussed – gray area created anger between people who otherwise should really be on the same team.
Our solution was to get very specific about language boundaries in the Understrap GitHub discussions – more so than in any other Code of Conduct I’ve seen. Here’s an excerpt where we talk about what’s prohibited:
Any profanity that you couldn’t say on the radio in the United States. Please note that obscuring a letter or two with a symbol like an asterisk doesn’t make it any less readable, and thus it still counts as profanity for our purposes. We understand that there is a gray area here, including words that have different meanings in different cultures and contexts. We’ll be as clear as possible on our reasoning if we believe there has been a profanity violation in the community.
Notice that we are being very specific and also local. You may not be in the United States, but we are effectively using American FCC standards here. There may be people who don’t agree with that particular boundary, but now we have a very clear picture of what’s acceptable, as opposed to a gray area like the “morally offensive” language from the WordPress Plugin Guidelines. Specificity matters, and more-specific guidelines mean fewer difficult decisions for the higher-ups.
The end of a true global community
We’re only a month into the war, but I think as time goes on, the Russian invasion of Ukraine will mark a turning point in how tech organizations handle the global nature of our contributor and user bases. For decades, tech companies have been able to operate in places with reprehensible governments (Russia and China, for example) under the banner of global openness. “Sure, China may be doing horrible things in Xinjiang and Hong Kong,” they say, “but isn’t it great that we have this billion-person market for smartphones and slightly modified Disney movies?” Even today, this is the prevailing wisdom in Silicon Valley when it comes to China, and only in the past month have those companies exited Russia, despite decades of undemocratic and authoritarian rule.
To be clear, the individual people in authoritarian countries deserve our kindness, respect and to be given the benefit of the doubt. It’s very difficult for someone who’s spent their life in a healthy democracy (myself included) to imagine life in a place where you can’t speak or move freely. Even the creator of the Z plugin seems like he was a pretty normal WordPress open-source community member as recently as two years ago, and many Russians simply don’t have access to accurate information (many even don’t think the war is real). Many others, perhaps especially the young and connected tech professionals, are voting with their feet by fleeing Russia.
But at the level of geopolitics, I think tech companies are learning the hard way that they can’t play the “every country is a market for my products, regardless of their government” game anymore. This is going to be extremely painful for Silicon Valley if we find ourselves in a position in the future where NATO and its allies sanction China as they have Russia.
In the past, we could get away with saying that technology eliminates borders. Because of Russia’s invasion of Ukraine, that era is coming to an end. Instead, we’re all going to have to start operating as citizens of our countries as well as open-source community members. That may mean explicitly taking a stance – for example, that it’s okay to support Ukraine, but not okay to support Russia, because the latter is an immoral aggressor and the former deserves democracy and independence.
How to improve the WordPress Plugin Guidelines
Now that we understand the core issue – a lack of clarity in the community guidelines – and we agree that the WordPress team did the right thing here as a stop-gap measure, let’s look at how we can improve the guidelines in the future. This should be an opportunity to improve, so we’re not hanging contributors out to dry with lots of gray areas and relying on a few Automattic higher-ups to make lots of difficult judgement calls.
First, plugins should have to pass a “usefulness” test
The WordPress Plugin Guidelines could add a test that requires the plugin to provide a reasonable amount of useful functionality to a WordPress site to warrant inclusion in the directory. I think this would have been an obvious way for the reviewers to say no to this plugin, without even delving into the politics of it.
A usefulness test could be something like: “Would a reasonable WordPress developer or end user agree that this plugin significantly improves the design, development or content creation process?”
This might rule out some existing decorative or superfluous plugins, including the revered Hello Dolly (which has had other issues) and perhaps even some of the Ukrainian-flag plugins – but I think it would be worth sacrificing some of the “nice” but frivolous plugins in exchange for having a clear directive that plugins must be genuinely useful – and things that are effectively decorative don’t count. We could also provide a grace period of six months or a year before the new rule is enforced for existing plugins, while applying it to new plugins right away.
If we had this rule in place with some specific “here’s what’s useful, here’s what’s not” examples, it would make the reviewers’ jobs easier and completely rule out “propaganda” plugins like this one.
The Plugin Guidelines should clearly define hate speech
I was surprised how little detail was included in the definitions of harassment and discrimination portions of the Plugin Guidelines and Code of Conduct. It would be easy to crib some more complete definitions from the various open-source codes of conduct on the web. We wrote a very extensive non-discrimination policy for our Employee Handbook as well, which we’ve published in the Public Domain so anyone can use it.
Specificity is really important here, because “be nice” means different things to different people and is almost completely unenforceable in real life. To the greatest degree possible, we need to define in writing what’s not allowed.
As an example of why specificity is important, Germany has different hate speech laws than the United States, in part to prohibit Holocaust denial, which is offensive but legal in the U.S. Many American states have very strong rules against discrimination against Black Americans because of our history of slavery and segregation, including relatively new laws addressing hairstyle discrimination. Canada has strong protections for Indigenous People. These laws all have local components that may seem unfamiliar or unnecessary in other countries, so we can’t just assume that a large international community interprets vague concepts like “morally offensive” or “be nice” in the same way, even when everyone is acting in good faith.
We need to define which standards we are using and make it clear that these will be enforced as if the Code of Conduct is actually the law. There are pros and cons to choosing a certain country or state’s laws (we’ve adopted rules form Ontario, British Columbia and California at our company because they’re very comprehensive), but choosing one written standard allows everyone to work from exactly the same clear set of rules. The WordPress community is unable to do that right now, because our standards are so vague that almost everything becomes a judgement call.
Make it clear how to handle questionable behavior
One of the big challenges in writing our Employee Handbook was the paradox of tolerance – the idea that if you are very tolerant, you eventually get to an extreme where you’re asked to tolerate behavior that is in itself intolerant. We often see this in the United States in the context of white nationalism, where our strong free-expression rules are co-opted by people who want to limit the freedoms of others.
Within an organization, this often rears its head in claims of “reverse racism” or, in the specific case of this plugin, a suggestion that “support for Russia” was morally equivalent to support for other countries or political ideas. In fact, I’d argue that supporting Russia is substantially different and worse than supporting other things, but the paradox of tolerance puts me between a rock and hard place in that debate.
In our Employee Handbook, we address this by explaining how decision-makers will interpret the rules in cases of conflict. Here’s an excerpt:
“In everything we do as a company, we aim to protect and empower employees who are members of groups that have been historically marginalized, underserved or underrepresented in employment with tech companies. Company leadership may expand or modify the list above [which is a list of groups protected from discrimination] from time to time to further that goal. If we’re faced with questions or gray areas that are not specifically addressed by the list above, company leadership will be guided in its decision-making by the goal of protecting historically marginalized and underrepresented groups from harassment and discrimination.”
The WordPress Plugin Guidelines should help everyone understand what is guiding decision-making, so that everyone can be on the same page when gray areas arise.
For example, this could include the protection of underrepresented groups (as in our Employee Handbook). It could be extended to say that, since we are an egalitarian and open organization, we will generally favor democracies over autocracies, and make decisions about propaganda and political speech with that preference in mind.
It could say that, when in doubt, a reviewer should err on the side of not publishing a plugin, and provide a detailed way to bring the issue to a larger group for discussion. (I believe this “escalation” process for a review already exists in some form, but it would be better if it were clearly the default path for questionable content.) We do this in the Understrap Code of Conduct by providing a very clear and detailed way to report and appeal violations – again, intentionally constraining me (the ultimate decision-maker for Understrap) so that I can’t make arbitrary judgement calls without a reasonable process that is supported by group consensus.
There’s a lot of work ahead – but the world has changed dramatically in the past month, and everyone’s playing catch-up. I hope the WordPress community takes this as an opportunity for improvement, and that a year from now we can be proud of our new, improved, specific and clear community guidelines.