LibrePlanet, Saturday, 19 March 2016
[These were the written remarks; I deviated in some places when delivering this talk. I have further revised this talk and delivered it at OSCON 2016 as "Inessential Weirdnesses in Open Source" http://conferences.oreilly.com/oscon/open-source-us/public/schedule/detail/49092. I have posted the full text of that talk on my blog . Thus I'm striking out everything below, to encourage you to instead read the OSCON 2016 version.]Hi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in free software". Just some housekeeping to start: I am not using any slides today, I will be taking questions at the end, and I'll be posting the text of my remarks online later today. And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in free software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general free software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use free software and participate in our communities. So if that is not particularly interesting to you then I do encourage you to check out the other talks happening right now -- I am particularly jealous that I can't go to Luis Villa's talk applying a capability approach to issues of software freedom.
ACTIVIST CONTEXT
So, we're coming at this from an activist context, right? We are trying to increase user freedom, and in order to do that, we are trying to reach out to people and persuade them to use free software, to contribute to free software and free culture, and generally to join us in thinking this is an important issue. So it's in our interest to figure out what barriers are stopping them from joining us.
I'd like to quote from the article "It's not "them" — it's us!" by activist Betsy Leondar-Wright http://www.classmatters.org/2006_07/its-not-them.php :
"A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.
For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us."
End of quote.
So today I'll be talking about a few examples, bits of our subculture, the free software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from the habits that we should cut down on when we're doing outreach events and creating online spaces for newcomers -- those are the kinds of habits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and watch out for these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.
STORIES
SYNTAX
Here's my first example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.
Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is contributing to free software, and the language is the command line.
Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable" http://gandre.ws/blog/blog/2015/04/07/why-the-command-line-is-not-usable/ . She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.
"Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated — they don’t have time for that. GUIs aren’t just “shiny“: they are tools which help us remember what is possible."
And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" http://pgbovine.net/command-line-bullshittery.htm where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like nohup tar -jxvf giant.tar.bz2 2> cmd.errs &. And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use free software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".
And in that piece he distinguishes between incidental and intrinsic complexity.
The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.
This underscores that it is just hard to install free software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, http://journal.code4lib.org/articles/11148 "Beyond Open Source: Evaluating the Community Availability of Software" Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.
Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then hit the Back button for fear that they'd broken something, or that they would break something. And what's worse, when we started introducing the what-you-see-is-what-you-get editor, the Visual Editor, some of the experienced editors pushed back with the argument that the syntax was a gatekeeping measure, that the ability to master this syntax was a really good proxy for whether someone was going to be a good editor in general. This is pretty nonsensical and has not been borne out as far as I can tell.
So, what is essential here? what is not?
With wikis, it's essential that everyone can edit an article -- that is part of the freedom of free culture -- and that everyone can see every article's history, because that transparency makes everyone a more informed consumer. And there's more, I'm sure. But using the syntax is inessential. It's incidental complexity.
And I would argue that the most essential aspect of the command line is that people are empowered to control their machines. It's a tool. And it's important that all users have the command line on GNU/Linux available, so they can chain together operations and learn to do development work, if they want. But the command line is such a difficult, alienating experience to new users, it's like it gives them unusable freedom. So, making new users learn the command line in order to use free software is an inessential weirdness.
SMALL TALK
Here's another way we ask people to speak in a sort of different language. We are systematically anti-small-talk.
I have taught scores of people how to use IRC, bug trackers and mailing lists. These are specific tools they have to learn to use, because we do so much of our work online and we're dedicated to people not having to be in any one place, geographically, in order to work with us. And that makes sense -- it is essential that we treat remote workers as first-class citizens, that we have communication tools for that. But when I teach new Wikimedians or OpenHatch workshop participants them how to follow our etiquette, I tell them not to introduce themselves. I tell them that they shouldn't do the thing that they'd do in person, which is to say, "hi, how are you, do you mind if I ask a question." To build connection and check that people are interested in helping.
Peter Block, who wrote "Community: The Structure of Belonging", discussed the common pattern "Connection Before Content". As he described it, "Before a group attempts to use its collective knowledge [to solve problems]... it has to build the relationships that will allow the group to hold an open conversation." This is the kind of dynamic most people are used to when they start talking with strangers about solving a problem. Whether they're sharing suggestions at a community town hall, taking their car to the mechanic, or asking for help at the local dog run -- the first thing that happens is a introductions, even if it's just the smallest, ten-second pleasantries of hi-how-are-you. I mean, in mainstream US culture at least, the only times when we really burst in on a stranger asking for help without saying hi first is when it's an emergency, or if they're a paid servant.
And in contrast, Kim Dodson and Randall Benson studied the culture of Wikimedia, the community behind Wikipedia, including the Wikimedia Foundation, the paid staff. And they saw the opposite tendency: "Content Before Connection".
Dodson and Benson noted that there's an inherent contradiction in the way that Wikipedia and its related communities are very dismissive of small-talk, pleasantries, socializing, and similar conversation. The researchers said: these places "support very close-knit and tight communities with active participation and communication (so are 'social')". But Wikipedians consistently said things like "we're not a social network" or "we're not Facebook" to discourage or dismiss social conversation that, in their view, was not 100% "on-topic" for the task at hand.
They said that communication patterns had a real gatekeeping aspect to them. That culturally, in order for a new person to get their statements and questions heard, they had to prove that they were credible and had good, relevant ideas first, and only then would any kind of relationships happen: "Quality information, ideas, and contribution are crucial prerequisites for acceptance." It's as though people are suspicious of the idea that you might have an illogical emotional reason to like and want to help someone -- because that might lead you to listen to someone who doesn't deserve it.
And so we tell people: don't introduce yourself, don't ask-to-ask, don't check whether anyone's listening, don't do the kind of pleasantries and small talk that make you feel confident or comfortable. We discourage that. Which means that only the people who feel comfortable emitting five-paragraph essays and detailed opinions in their very first interactions get to build the kinds of relationships that led to trust, room for creativity, and a path to leadership.
This is not just across-the-board inhospitable. In the United States, at least, it's also particularly offputting to people who are working-class, and in a lot of cases, to women. You're asking people to perform solo, freestanding utterances. Some people get socialized to do that, from childhood on, way more than other people. They get asked to do it and they get rewarded when they do it. And some people, especially working-class people and women, are socialized more into collaborative and interactive speech, where you work with the existing conversation to incorporate your ideas and questions, in response to other people. And, when you ask people to basically stand up in front of everybody and make a stylized speech, it kind of feels like a school assignment or something their boss would make them do. And for people who feel like standardized education and corporate workplaces are part of the system that's stacked against them and waiting for them to make a mistake, that's not super welcoming. There's more about this in Betsy Leondar-Wright's book, "Missing Class" http://www.classism.org/missing-class/ , and in Jessi Streib's "Class Reproduction by Four Year Olds" http://www.classism.org/class-reproduction-year-olds/ .
I'm not saying every IRC channel and every bug report has to have a bunch of "what did you eat for lunch today". But -- for example, a lot of initial conversations with free software users, who would potentially be open to becoming contributors, are troubleshooting. So those conversations mean we have to understand the series of steps a person has taken to make something or debug a problem).
I think that understanding emerges most easily in conversation with a generous expert. But in our mailing lists and our IRC channels, where people ask for help, it seems like we think that the first thing anybody says needs to be delivered with the concision and throughput of a paramedic running alongside a gurney.
In my experience *building even the faintest of relationships* with this new user makes it a million times easier to ask the question, "what problem are you trying to solve?" In IRC, for example, I've had tremendous success by *starting off saying* (roughly) "Hi [person's nickname]! I'm Sumana, [thing I do] and I live in NYC. Good to meet you, although sorry for the circumstances :/" [wait for reciprocation; most people will reciprocate by giving their name at least] "That problem sounds frustrating. Do you mind if I ask a couple diagnostic questions?" Now we are people together and not just Supplicant and Expert, and I can ask about the environment, and I can say something like "the approach you're using is sort of unusual so I want to check whether you're accidentally making it harder for yourself and there's an easier way to get the functionality you want :) " (although I can't remember the last time I had to literally explicitly say that; usually by this point they are open to talking about their process, their macro goal, etc.).
And in my experience, the affordances of a lot of online tech-help-seeking spaces discourage this kind of necessary trust-building conversation. If the only spaces we have are ones where people need to show up speaking in complete paragraphs at 60 miles an hour, then we don't have an onramp, and that means fewer people can join us.
PYCON 2014
Now another story, and it's actually about a rare failure by one of my favorite conferences. PyCon North America is a yearly community conference about Python. In scheduling PyCon 2014 and 2015, the organizers accidentally scheduled it over Passover, both times. And this means that a nontrivial number of observant Jews couldn't come.
And beyond that, consider how many of our conferences happen over Fridays, Saturdays, and Sundays. If going to a weekly Muslim, Jewish, or Christian religious service is important to somebody, then a weekend conference schedule is going to really crimp their style. (Now, this is important to balance against the fact that some people can't miss that much work in order to attend a conference. Maybe the best approach is to be aware of who seems to be consistently catered to, what demographics aren't having any trouble showing up, and try to change it up a bit so you have some events, some communication channels, and so on that cater to the people you haven't had as much success in reaching.)
I'm not here to try to persuade anyone to join or leave any religion -- I'm a Hindu myself and I'm really grateful that we do not do that here, that in my nearly 20 years in the free software movement no one has tried to convert me. I'm glad our spaces are secular. That is essential to us being open for everyone. But in our aggressive ignorance of religion, and sometimes when we stand by and let anti-religion comments stand without challenging them, we sometimes cause snags for people who want to engage with us.
Sometimes this is in missing opportunities, like partnering with churches, temples, and mosques. Hey, they have communities full of people with free time who are interested in making the world a better place! A lot of them care about privacy from government surveillance, for very good reason! And they have free venues for meetings!
And sometimes it's a little more direct. One person who ran an online technical forum mentioned that, in its "off-topic" section, sometimes people said things that were casually sexist or Islamophobic. He said,
"I just kind of rolled my eyes and ignored them. About three years in to running the forum, I incidentally discovered that we had a few closeted women and Muslims in our membership. Suddenly those jokes that were white noise before made me acutely ashamed and I had to update the rules and enforcement to stop those posts going forward. If you had asked me the year before what I thought the community’s most serious issues were in expanding and increasing engagement, “casual hostility to certain demographics” wasn’t even on my radar." -- Matt, http://crookedtimber.org/2015/04/10/codes-of-conduct-and-the-trade-offs-of-copyleft/#comment-625465
CONTEMPT
And here's my last story today, and it's Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs.
She writes in "Contempt Culture" http://blog.aurynn.com/86/contempt-culture :
"when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.
Right?
This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages."
End quote.
I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.
She writes: "It’s 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn’t feel welcome, and I’d have learned that the idea that the Python community is welcoming wasn’t true.
I’m tired of calling people out again and again for dumping on PHP.
I’m tired of people dumping on Windows, that most popular operating system, because it’s not what we choose to use, tired of the fact that we don’t make it easy to use our tools and teach them how to move, when they’re ready."
End quote.
As I experienced in most of my community management work in free software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out free software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.
So what is essential here and what is inessential?
It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages free software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you offer more doable short-term goals that give them immediate benefits.
I wanted to go into these in depth, so there are topics I mentioned in my abstract that I do think contain inessential weirdnesses but that I don't have time to discuss in depth in this time slot, like how our community acts regarding pop music, patriotism, professional sports, and the primacy of in-person conferences, and the user interface of Git specifically, and assumptions about bandwidth & personal computer quality. I'm happy to discuss any of those during the Q&A or afterwards. This is an incomplete list of examples.
IMPLICATIONS
So what does this imply for free software advocates? Now I'm going to talk about some ways to watch out for these problems and reduce the harm they cause.
I. look for code smells
These are some really rough heuristics to try to find snags that other people are hitting.
Take the same approach that a Software Reliability Engineer would take, and say, any time a user gets hassled or tripped up, that's a symptom of a problem that needs fixing. You treat every downtime, every pager call, as a bug report.
Look out for any advice your project is giving newcomers that has the word "just" in it. I think Greg Wilson calls this the passive-dismissive adverb.
Watch out for any place in your workflow where newcomers have to deal with simultaneous newness on multiple dimensions. Mako Hill has observed that Wikipedia was founded at the same time as a lot of other innovative free knowledge projects, but Wikipedia's the one that thrived and that's still around, because yeah, it was super weird and disorienting and innovative on the workflow level, but the thing it was aiming at, an encyclopedia, that was a vision all the participants understood. You can only innovate on so many levels at the same time. This goes back to that woodworking example at the beginning. People will have a hard time learning a new language while they're also learning to do an entirely new kind of thing.
If you make an application you want people to use, if it has to do with user privacy, ask SimplySecure to take a look at your application's user experience. If it doesn't, you can still use the https://simplysecure.org/blog/shmoocon-talk Simply Secure guides on doing qualitative UX research, such as seeing how users are using your product/application.
And -- I know this is a wacky idea -- but you can ask. You can reach out to individual people who attended one event and drifted away, and ask them what you could fix to be less unappealing. That doesn't always scale, it's artisanal data, but still, it'll give you some thoughts to work off of.
And having those thoughts, a list of some things to look at, helps with the next step.
II. Realistically assess yourself & your goals
Once you have an inventory of some things about your community that are putting off newcomers, you have some choices to make. What are you really committed to keeping in absolutely all your activities, and what do you think you could stand to tone down when you're trying to talk to newbies?
Discerning essential from inessential means being honest about what your real values are. Leondar-Wright suggests that essential weirdnesses include ones "that couldn't be eliminated without doing a deep injustice to someone" (like being accepting of QUILTBAG people) and "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). But "it's rarely essential to impose one's personal choices on others".
So, what are your goals? What are your values? You care about the Four Freedoms and about treating everyone with respect; beyond that, what are you particularly attached to? Who are you trying to reach out to, & what are the gaps between your culture & theirs? I haven't even gone into international, inter-language, and other differences you might want to traverse, but I can recommend classism.org to get some representative thoughts.
"Observe the cultural norms of people you'd like to work with, watch for signs of discomfort, and study what conveys respect and disrespect in their subculture." -- Leondar-Wright
III. Find easy ways to build bridges
Sometimes you're going to find easy wins, which is great! There are easy add-ons you can do that overcome a barrier.
Some old-school people like Mailman mailing lists. Some new contributors really like web forums. If you upgrade to Mailman 3, you get one thing that acts like both, so everyone's happy!
If you have an IRC channel, you can do what OpenHatch did and have an automated welcome bot. It greets new people and gives them a couple tips, including the names of a few people they could reach out to for help who have been active recently. If you have a Slack, you can make a bots with the Howdy framework to do something similar.
You can use pre-existing playbooks to run events like SpinachCon, so that new folks don't have to learn git or the command line to make their first contribution.
But usually those kinds of easy wins are not the whole story. If you are serious about building coalitions with people who are not like you, you will probably want to:
IV. Build and maintain differentiated but connected spaces
Your project can support both experts-only spaces (where jargon and in-group practices are welcome, like really concise speech and Douglas Adams jokes) and mixed-experience spaces (where hospitality is emphasized and legitimate peripheral participation opportunities are available for learning).
These newcomer-friendly spaces are like tidepools, connected to the ocean, but calmer, where things can germinate in a gentler environment. For you, a tidepool might be a community that publicizes beginner-friendly events, where Windows users who prefer GUIs to command lines are welcome, where new people can make relationships through small talk, where there's an occasional installfest at a church.
This means that you would have to learn to be comfortable explaining, nonjudgmentally, that there are high-jargon spaces and low-jargon spaces, and helping steer conversations to where they ought to be.
These newcomer-friendly events and online spaces probably ought to have agreed-upon rules (Example: the Recurse Center rules https://www.recurse.com/manual ) to help everyone feel comfortable saying "I don't understand," and it's probably a good idea to regularly revisit and revise those rules to see if they've lost touch with any of the essential values and weirdnesses that the community needs to preserve.
And this isn't meant to suggest that we should condescend to newer contributors -- just listen to them, and do what it takes to support and encourage them in their free software journey. Everybody's got something to learn from us and everybody's got something to teach us. So while teaching new learners, yeah, we should err on the side of clarity and listening, and call things by their proper names while also collaborating among people with different perspectives to build a common language -- and a common movement.
V. Acknowledge the costs.
"Don't expect you can remain exactly as you are and be a bridge person" -- Leondar-Wright
Engineering is a game of tradeoffs. And yeah, there's a tradeoff here. You are going to reduce the amount of time that the outreach-centric folks spend in the pre-existing expert communities. Let's acknowledge that different spaces are genuinely, irreconcilably different.
Whenever you try out a kind of funnel or ladder that you hope will get you new users, new participants, new collaborators, not all of those people are going to work out. And every one of them who drops out is going to feel like a failure of the new plan. Like, "we spent all this time on making a GUI and negotiating with the local mosque to host a meetup and actually making smalltalk with people, and it's still a grind!" You're going to have demoralizing moments and it's going to feel even harder because you're trying something new that you're not good at yet.
"Figure out which of your weirdnesses are essential to you, and drop the inessential ones when you're doing cross-class outreach or coalition building. Be thoughtful about who your group sends to be the emissary to a culturally different group." - Leondar-Wright So, that means that some of the people in your community who are not very good at adapting to other people's cultures are going to need to hear that, and that's a hard conversation to have.
Another cost is the cost of the weirdnesses you decide to keep.
If you decide to hold onto a weirdness, then acknowledge that in your outreach, you'll need to pay the cost of making new people comfortable with it. Develop good explanations and metaphors and help people understand why you've made the choices you've made.
Figure out what needs teaching in a standalone class. For instance: the nonprofit Software Carpentry has a very laudable goal. http://software-carpentry.org/about/ They teach researchers and scientists of all kinds -- physicists, biologists, sociologists, anybody who has to manage and sort through data to do research -- they teach them basic research computing skills, like version control, the Unix command line, and better programming skills. And the Software Carpentry folks have created these workshops and boot camps, sort of as a coping mechanism for the weirdnesses of Git and the command line.
As a community, it looks like we are sort of doing this with Git by creating learning materials, and by making some workarounds. Look at the GitHub web UI as sort of a costly, unfree mitigation of the horribleness of Git's UI. As with wikis: it's essential, with Git, that everyone can suggest improvements, everyone has access to the whole history, it's possible to search for specific changes or classes of changes. But learning to use the command line and the syntax is just not as essential as a first step.
CONCLUSION
So here's the tiny plug, which is that my firm, Changeset Consulting http://changeset.nyc , can help you with this -- with contributor outreach and with auditing and assessing your current intake and onboarding process. But no matter whether you hire somebody or ask for volunteer help or do all this work yourself, this is going to be tough, but necessary work, for us to build a mass movement.
As Betsy Leondar-Wright says: "None of this is easy. It's one thing to briefly change ourselves for a job interview or for dinner with the in-laws, but it's painful to have to change ourselves in our own activist groups. But as civil rights activist and Sweet Honey in the Rock founder Bernice Johnson Reagan said about coalitions, "If you're comfortable, you ain't doing no coalescing.""
I ask you to try discomfort, to install discomfort and try it out, because that's the only way we're going to build coalitions and make a more just and a freer world.
Thanks to Amy Hanlon, Anne DeCusatis, Leonard Richardson, Denver Gingerich, Betsy Leondar-Wright, Naomi Barrettara, and Kaitlin Thaney for their comments on earlier drafts of this talk, and thank you to Mary Gardiner and Camille Acey for earlier comments on this topic.