"Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.

 

Introduction

Hi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.

 

Housekeeping

Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes 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 open source 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 open source 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 open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

 

"Inessential Weirdness"

So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "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). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

 

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.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source 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 stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix 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.

[Now: three stories.]

 

Contempt

My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "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.

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.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source 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?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

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 open source 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 get more doable, with short-term goals that give them immediate benefits.

 

Syntax

Here's my next 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 using open source 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". 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.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

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" 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 open source 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 open source 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, "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 Back-button right on out of there, for fear that they'd broken something, or that they were about to 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 writer and contributor 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. MediaWiki is meant to make it easy to edit. By default, when you set up a new MediaWiki installation, every user can edit every article. We aren't going to add a bunch of different permission and access control layers so that there are fifteen layers of privileges to determine who can edit what page. There's other wiki engines that'll do that, that have different core values, but it's inherent to MediaWiki that we default to freedom.

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 and use them the way they want. 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, and because there are people who find it a much more accessible experience. But the command line is such a difficult, alienating experience to new users, it's like it gives them unusable freedom. (Hashtag #unusablefreedom .) So, making new users learn the command line in order to use open source software is an inessential weirdness. Having alternatives available, like the rich desktop environments that GNOME and KDE have made and Ubuntu helped make available, is great. As long as all the GUIs are also accessible to screenreaders.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.

 

Religion

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. You can see an example of how I'm doing that in this talk -- I'm using written questions instead of oral Q&A, because it's a way to make some people comfortable who usually don't get to ask questions. And instead of using slides, I suggested we have the live captions, to help people who usually have trouble following a spoken talk.)

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!

But, again, it's essential to respect people's personal autonomy and freedom. There are people in our communities who have been hurt by religion, been traumatized by religion, who currently face discrimination from religious communities. So of course we have to be mindful of that. So, for instance, if someone in your community isn't going to feel comfortable in a religious space then there's no reason to try to persuade them to do that bit of outreach.

In any case, I'd say that it's an inessential weirdness for us to stand by and allow anti-religious comments in our public spaces. 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, a 'casual hostility to certain demographics' wasn't even on my radar." -- Matt, Crooked Timber comment thread

 

More things I wish I could have talked about

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 open source communication norms, and how our community acts regarding pop music, patriotism, small talk, 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.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.

 

Takeaways

So what does this imply for open source software advocates? Now I'm going to talk about some ways to watch out for these problems and reduce the harm they cause.

 

1. 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. ["Almost Wikipedia: What eight early online collaborative encyclopedia projects reveal about the mechanisms of collective action."] 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, use the Simply Secure guides on doing qualitative UX (user experience) research, such as seeing how users are using your product/application.

And another possibility -- 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.

 

2. 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.

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

This isn't about completely changing the entire core of your work. If you have a strong cultural practice and you're committed to it, own it but be nonjudgmental -- say "if you want [other approach] consider [other project]".

Acknowledge that different people want different things. And acknowledge that when you negotiate that with people who are different from you, that will probably require conversations, not just writing FAQs that live forever. [See this explanation of the success of the English Wikipedia's "Teahouse" for more on this.]

 

3. 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 bot with the Howdy.ai botkit 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:

 

4. 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). [Also see Mark Guzdial's and Greg Wilson's posts on this.]

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 (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 open source 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.

 

5. 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. Which is where the learning happens.

Leondar-Wright says: "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." So, that means that some of the people in your community who are not very good at adapting to other people's cultures should not be doing this work. And if they're trying to do this work and they're not good at it, they 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 teaches 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 command-line 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, through my firm, Changeset Consulting, I can help you with this -- with contributor outreach and with auditing and assessing and improving 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 am asking you to stay safe and loved but to try installing discomfort. Everyone deserves safety. Safety is what makes it possible for us to function. But maybe we could take turns being uncomfortable, so the same people don't always have to be uncomfortable all the time. If you are recruiting for new Google Summer of Code interns, or you're on a newbies-friendly mailing list, and you see a barrier to entry, check whether you're acting like those old-school Wikipedians who thought the Visual Editor was keeping out the riffraff. Ask yourself: "Is this essential to our values, or is it more like adding another way in would make us uncomfortable?"

Just give it a spin. As the Open Source and Feelings Diversity Statement says:

 

"Sometimes we will need to step out of our comfort zones to make everyone feel welcome. We recognize that privilege is real and that the privileged have more bandwidth to be uncomfortable and help make our space more welcoming."

 

Thanks to Amy Hanlon, Anne DeCusatis, Leonard Richardson, Denver Gingerich, Betsy Leondar-Wright, Naomi Barrettara, Darius Kazemi, Brendan Adkins, Nick Murphy, Roan Kattouw, Meredith Patterson, Andromeda Yelton, and Kaitlin Thaney for their comments on drafts of this talk, and thank you to Mary Gardiner and Camille Acey for earlier comments on this topic.

 

Question & Answer

And I'm now ready to answer your written questions. [I received one question.]

Q: Does jargon exist for matters that cannot be understood with preexisting vocabulary?
A: I think the word there is jargon. I think that it's useful to remember that there are -- jargon isn't just about synonyms. It isn't just, you know, we say "quit" or "exit" where somebody else says "end." Jargon isn't just about different words for the same thing. Often one function of jargon is an encapsulated compressed thought that does have dependencies. You can think of trying to reach newbies as a dependency management exercise. How many new concepts and skills are you making them install in order to get to the point where they can do something useful and collaborate with you? And so, I could, you know, if you want some metaphors, I think that's a reasonable one to talk to other coders with. The chunk of thought that this questioner asks about, ideas that cannot be easily expressed or understood with the person's preexisting vocabulary until they learn new words and thoughts, I think "jargon" is a reasonable thing to start there.

Additional note: Thank you to White Coat Captioning for working with O'Reilly Media to provide CART services for this session. I've checked the transcript they provided and improved this post to reflect the question-and-answer session, as well as places where I said something better live than I had scripted for myself to say, and I've included in this post parts of the speech that I did not have time to deliver during my OSCON slot.

This talk is a revision of an earlier talk I delivered at LibrePlanet 2016; in particular, I cut the "small talk" section due to ableism concerns, and may someday expand that chunk of thought into another talk or essay.