One thing I love about open stuff, such as open source communities, is that we (try to) measure people by what they contribute.
I’m now Volunteer Development Coordinator for the Wikimedia Foundation (although I am not speaking for them in this post), so I care about the quality and quantity of contributions to MediaWiki, and about the people behind them. In fact, I’ll partially be measuring my success through statistics on the number of people who offer code, bug reports, translations, documentation, talks, mailing list posts, and so on.
And it’s not just doing, it’s doing and sharing. We value collaborative work, not hoarding.
This norm, among others, leads us to use “put up or shut up” to quash unproductive conversations, bikeshedding, trolling, and “you should…” unhelpful suggestions. I once had the satisfying experience of saying, to a guy full of “why didn’t they do foo”, “you should totally post that suggestion to the mailing list!” and seeing him just shut up, defeated. He knew that doing this without embarrassing himself would take a modicum of research and thought, and he had no intention of doing anything that arduous. He’d just wanted to mouth off. And now I’d revealed him as a noncontributor.
I saw another example in Kitt Hodsden’s talk about the Hacker Dojo community center.
all talk, no action
Another aspect of open source development we encountered, an aspect that is also found in just about every volunteer organization ever, are the troll subspecies “we oughta.”
The we-oughtas clan is often very vocal, they know what we should be doing. When it comes to the actual doing, however, they aren’t around, they aren’t available, or that’s not what they meant.
When this is the case, the response is either, that’s nice, and ignore it, or, just as in open source projects, “put up or shut up.” Essentially, if you’re not willing to put forth the effort of leading your own project – even if that leading is just finding someone else to lead your project – we’re not going to follow.
At its best, “put up or shut up” is empowering. In Hodsden’s talk, she shared a story about a potential member whose “project was outside of our expected and supported hardware and software development spaces”:
We gave the answer we have learned to give for people who have crazy, though potentially awesome, ideas that in the future could work wonderfully in our space: lead the project: tell us what it is going to take for your project to succeed, develop a game plan, put in the safety measures, find supporters, work up a budget, start the fundraising, make it happen.
The community defines itself. If the community decides it wants to become a metalsmithing shop or an experimental biology lab, it’ll become that, because that’s what the community wants.
I bet all of us who have held leadership in FLOSS can attest to the two sides of “well go ahead then, patches welcome, make it happen, this is a do-ocracy.” Great, we can empower people. But how often do we use it to shut down discussions, ideas, and people we don’t like? In particular, have you been part of an interaction where a privileged FLOSS project member used “you want it, you make it happen” to wrongly dismiss a concern that might require the whole community to change its behavior?
Look at what I did, in the anecdote I told in the third paragraph of this post. I wasn’t purely kind or rational or ideologically anarchic in telling that guy to write to the list; I found him annoying and wanted him out of my hair. I told him to contribute, superficially encouraging him, but really wanting to discourage him. Have you ever been on either end of that, especially around geek feminist issues?
And I suspect this disproportionately affects newbies and non-native speakers of a community’s language. This is the problem with saying “you want it, make it happen” in response to requests for a harassment policy, or for all of an app’s strings in one file to make localization easier. The very people who need those new policies, procedures and abstractions are least able and worst placed to implement them.
(Small digression: in the case of harassment policies, consider “Did you know how to react?” by Noirin Plunkett, and Bitch Radio’s interview with Valerie Aurora. The Ada Initiative, in suggesting and working towards conference anti-harassment policies, has far more energy and resources than would one individual seeking protection.)
Developers are used to dealing with requests for features or bugfixes, but FLOSS leaders are still learning how to deal with requests to socially engineer our projects.
And no matter whether you’re considering adding a feature, hosting a sprint, changing version control systems, or joining a conservancy, it’s sensible risk mitigation to chat about it before putting substantial effort in. This is a different kind of work, not coding, but building support and getting the lay of the land. And it’s part of contribution.
So, fellow FLOSS leaders: If you want to grow new contributors, along with giving them permission to suck, build personal relationships with them. In private or face-to-face, listen as they vent and discuss their ideas, even the half-baked ones. Listen for the difference between “we should” and “I’d like to/how do I?”. Sometimes they’ll need sympathy, and sometimes advice. If you say “go do it then,” say it encouragingly, not dismissively. Watch out for moments when a marginalized potential contributor is essentially asking you, “help me help you.” And watch yourself in case you’re about to do what I did, using “put up or shut up” to shut down someone you find abrasive. Because sometimes I’m abrasive too, and sometimes I have good ideas. :-)
As hypatia puts it: “a gentle ‘that’s definitely an issue, could you file a bug’ goes a long way.”
