This post is subtitled “criticizing for change” because not every criticism is fueled by a desire for change. Some arise because someone is having a rotten day, looking to connect over a shared experience, or even declaring what they value. Treating all criticism equally is as big a mistake as ignoring all criticism.
But this post is for critics, not those being criticized. More specifically, this article is for those of you who see things that you think are wrong in open source, and want tips for sharing your critical feedback in ways that that are more likely to result in a change.
The bigger the change, the longer the game
Organizational change takes time. Big-impact changes take time. Big-impact changes in large organizations take a LOT of time. Change advocacy can be tiring, so I recommend taking the long view and setting yourself smaller, more attainable goals that will pave the way toward your ultimate goal. If you can, if you are privileged enough to have the time and stamina, pace yourself.
Avoid personal attacks
Some open source projects like WordPress have fostered a deeply connected, engaged community of contributors. Open source is also deeply vulnerable to the Five Geek Social Fallacies, which can lead the group to close ranks around a community member if that person is criticized or attacked, even if that person has done bad things.
This doesn’t mean that you can’t say, “this person’s behavior was terrible.” You can. But if you lead with “this PERSON is terrible” and point to their behavior, you will lose a lot of people before you even get to your examples.
For better or worse, repetitive critiques of a particular person or people result in diminishing returns. The reason I encourage people to love their critics is because most people start ignoring messages from “a complainer” or “someone with a grudge,” after a time. If you’re playing the long game and working toward change, then remember to criticize the behavior, not the person.
Build coalitions
In open source — and probably everywhere — it’s easier to get people to listen if you are speaking as part of a group, instead of a lone voice of dissent. This doesn’t mean lone voices of dissent are any less correct, or that a group is guaranteed to be right. I’ve seen large groups of people who were wrong, in open source, and been part of groups that were wrong, myself. That’s just part of being human. (Unfortunately. I sure do love being right.)
That said, building a coalition is the most effective tactic I know, to successfully accomplish change in an organization. Convincing other people of your idea’s merit on a small scale demonstrates a plausible promise. That plausible promise helps more people take your idea seriously. As you continue to test the idea with more people, presumably the idea gets refined and improved, helping it fit better into the fabric of the project. Eventually, the idea builds enough momentum that it takes on a life of its own. By the time that happens, you can usually just sit back and let the organization grow into the change.
Optimism FTW
Open source contributors are optimistic — you don’t put the time into contributing to a project that’s bigger than you, unless you have hope that your work will have an impact. Our work is fueled by hope, and our hope fuels our work. In contrast, advocating for change can be discouraging, which can lead to cynical or despairing attitudes.
I hope this goes without saying, but I’ll say it anyway: you’re going to have a really rough time getting inherently optimistic people to want to work on a change that comes with the message that “we’re all doomed.” And if you believe, down deep, that nothing’s going to help, then you’re probably not criticizing for change in the first place.
Either way, “this idea could make us great!” is a much more motivating message than “this idea could make us less terrible!” Tap into that open source optimism, and let it give your idea wings.
Pragmatism is powerful
It may be that the change you’re suggesting is morally right. I hope it is! But remember that what’s considered morally right… varies between different cultures. And most open source projects include contributors from many different cultures — WordPress certainly does. So I recommend against relying on the argument that “it’s the right thing to do.”
Instead, focus how the change you seek will help the organization move closer toward its goals. Warning: this does require you to understand what the goals of the organization are! But if you don’t know that already, then pause until you learn them. You never know… what you identify as a bug, might actually be considered a feature!
What did I miss?
Any other tips for our change-makers? Does something I’m saying sound wrong to you? Share your advice or ask questions in a comment on this post!
The Thing With The Stuff 