I’ve been outspoken about my dislike of the term “non-code contributors” for a while now. I mentioned it again on my socials recently, beginning:
“I suggest that if you find yourself about to use the phrase “non-code contributors” or “non-technical contributions,” you should stop, remind yourself of your goals, and use entirely different language.”
The response (including these) has encouraged me to elaborate.
In short, defining people by what they are not is othering, diminishes what they are, and works at cross-purposes to known good practices in inclusive organizing.
Representation matters
We know representation matters in event organizing, marketing, and recruiting. We put in extra effort to reach out to communities of underrepresented people, and make sure underrepresented people are on stage and in marketing materials.
We want people to be able to see themselves there. We want people to feel, “If someone like me is wanted there, then they want me too.” It’s just one part of the work to ensure that those who show up are increasingly reflective of the world around us.
Code supremacy
We have a code supremacy problem in free and open source software. We overvalue code, and we undervalue design, user experience, technical writing, marketing, community management, and glue work.
It shows, too. We see this manifest in the relative numbers of contributors across disciplines, the quality of tools and documentation, and the resulting software. Where we see projects that do better, it’s always because there has been significant cultural and structural work to achieve those goals.
What are we really trying to achieve when we say “non-code contributor?”
Given what we know, it’s puzzling to me that so much ink is spilled writing to a massively diverse set of audiences under the consolidated term “non-code contributors” in an actual attempt to increase representation.
The designers I know don’t describe their work or contributions as “non-code.” They identify it as design. The documentarians I know don’t describe their work as “non-code,” they describe it as technical writing.
It’s only after they spend years being told they’re “non-code contributors” by a culture of code supremacy that they begin to identify their work as “non-code,” but even then it’s only how they identify it within the context of the problematic culture. No one tells their friends outside of open source that they’re “non-code contributors,” they say they help with interface design.
Without fail, as I have practiced excising “non-code contributor” from my vocabulary, I find it’s not the tool I ever really needed. Typically, I find that other language will serve me better, or that I’m making a strategic error.
Am I trying to get designers into my open source project? I need to meet them where they are, use their language, write articles and docs specifically for them, and treat them as first class contributors.
Self-determination and breaking the cycle
Now, granted, if someone tells me they want to be identified as a “non-code contributor,” I’ll respect that.
I’ll respect that the same way I’d respect how they pronounce their name, their pronouns, or what label they put on their sexual orientation or racial/ethnic identity. Consent and self-determination are paramount.
And when I am trying to shape a community? I’ll use a vast array of descriptors to signal to lots of different types of people: “you belong here.”
Let’s break the cycle of code supremacy and the other representation issues it intersects with. Let’s put the term “non-code contributor” to rest. Let’s celebrate people for who they are and meet them on their terms.
The result will be better cultures and better software.
Leave a Reply