Blog by Sumana Harihareswara, Changeset founder
Inessential Weirdnesses in Open Source
Hi, reader. I wrote this in 2014 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.
Hi new readers. I see some folks on Twitter think I'm suggesting we eradicate everything I mention below. Nope. I (Linux user since 1998, open source contributor since 2006, Wikimedia open source community manager 2011-2014) want us to think about barriers that stop or slow down some users and contributors, so that in outreach efforts, we can be better at bridging the gap. Hope that context clarifies things. [Added 13 Aug 2015]
I'm pretty dissatisfied with the August 2014 post below. I should have more clearly stated my assumptions and audience, and my intent to play around with some vocabulary and what-ifs; I'm unhappy that it comes across, to many readers, as a "we should eradicate all these things" manifesto. So I'm revising, clarifying, and deepening these thoughts: here's my latest draft, towards an OSCON talk I'm giving in May. My goal: Open source contributors and leaders who are already comfortable with our norms and jargon will learn how to see their own phrasings and tools as outsiders do, including barriers that often slow down new users and contributors, and to make more hospitable experiences during their outreach efforts. [Added 7 April 2016]
Here's the text of the talk I gave at OSCON. [Added 22 May 2016]
Class Matters features an essay by Betsy Leondar-Wright on activist culture and what we do that accidentally alienates new people, and includes the very useful phrase "inessential weirdness(es)." Please go read it so you'll understand what I am suggesting in the lists below.
Some friends and I started listing the inessential weirdnesses in open source and open culture, some of which shade into missing stairs. We came up with:
git (not all version control systems; specifically git because of its UI/horrible learning curve)- "+1" jargon
- dismissiveness towards Windows/Internet Explorer
- assumption of atheism
- widespread scorn of team sports, Top 40 music, patriotism
- how MANY licenses there are
- all the Monty Python and scifi references/analogies
- dismissiveness towards email addresses from certain domains, such as Hotmail, AOL, etc. (And the hierarchy beyond that as well! A few years ago, my boss's boss emailed a bunch of people, and I was on the To list, and she used my backup GMail address instead of my usual Panix address, so now I looked like just another GMail user in front of all these hoity-toity people whose emails end in @[prestigious-company].com or @[prestigious-university].edu or @[self-hosted-domain].net. I was embarrassed, because that's how email domain name status works in our community.)
Mary Gardiner added more observations (mostly her wording):
- Use of email lists rather than web forums
- Use of plain text rather than HTML email (or even knowing that these are things)
- Use of IRC
- Really context-dependent naming: Almost universal use of wallet names in email and almost universal use of pseudonyms on IRC for example
- Our (very white?) use of standard English, with a mainstream minority using Latin plurals and into older styles of prescriptivist grammar
- All the mathematics and CS terminology: "transitive", "orthogonal", etc.
- Conferences themselves. They come with assumptions of a certain amount of wealth (for travel), and they focus on skills (abstract writing, public speaking) that don't closely correspond to the skills a lot of open stuff workers have developed in the course of their work. In addition, they go with a very common phobia (public speaking). They require spoken fluency in (usually) English (which is really hard on many good CS research students). They're also totalising: you conference from the time you wake up to the time you sleep. Even without travel, and even though childcare is a partial solution, they're therefore very tailored to people without dependents or regular home responsibilities.
Leondar-Wright's essay also gave me language for thinking about defaulting to unconference formats. As I said in my 2012 post "Sometimes an unconference is the wrong choice":
If you are planning an event for people who already know and trust each other, and are good at public speaking and collaboration, and are experts in the field, then an unconference might work! But for newbies who are learning not just a new skill, but a new way of thinking? Give them a more familiar structure.
I am happy with how we are doing AdaCamp, which I think is a modified unconference in the right ways, e.g., with lots of orientation and structured-for-newbies intro sessions in the first few slots.
Camille Acey added the nuance that it's important to distinguish between making a space more accessible to newbies and "dumbing down" ideas. While it's important to avoid needless erudition when teaching new learners, it can be condescending, presumptuous, and paternalistic to reflexively avoid complex topics and nuance. Acey believes we need to build safe spaces with agreed-upon rules to help everyone feel comfortable saying "I don't understand," that we must regularly revisit and revise those rules, and that we should, while teaching new learners, call things by their proper names while also collaborating among people with different perspectives to build a common language -- and a common movement.
I agree with Acey that, while getting rid of unnecessary barriers, we need to watch out for disrespectful oversimplification. Making safe places where people can admit ignorance and teach each other respectfully is key; this implies long-term commitment and relationship-building, I think, and is yet another reason why one-off events are less effective (for example, see the importance of followup in Wikipedia editing workshops and edit-a-thons). Perhaps one way to balance improving the learner's experience and avoiding condescension is for teachers to consciously remember simplifications as placeholders, and commit to exploring the topics' richness with those learners in a later session.
One way to think of essential versus inessential weirdnesses is to think in terms of dependency management. How many packages are you asking your user to install in order to use your project? Are they all really necessary? Won't that take a lot of time and disk space? Can you reduce the amount of time they spend waiting for a progress bar to inch forward, so they can dive in and start getting things done?
Comments
Sumana Harihareswara
http://harihareswara.net
10 Aug 2014, 20:05 p.m.
Calum
11 Aug 2014, 6:49 a.m.
I still find it weird that people find mailing lists weird. Email was designed for people to communicate with each other. The web was not, and the user experience of most web forums (and the chore of having to visit all the different ones you're interested in) still sucks a lot more than the experience of dealing with large quantities of email in a decent email client.
Greg Wilson
http://software-carpentry.org
11 Aug 2014, 14:22 p.m.
What's a "wallet name"?
Zack
https://www.owlfolio.org/
11 Aug 2014, 22:27 p.m.
Calum: I struggle with that one myself. GCC's incredibly email-centric process worked better for me than anything before or since, but was also demonstrably off-putting to new contributors, and I've seen that pattern in other projects as well, albeit less sharply.
I think fundamentally this is a center-periphery issue. Someone who's deeply embedded in a project or three, is accustomed to skimming hundreds of messages a day, and needs to contribute to multiple simultaneous asynchronous conversations that stretch over days or weeks, will be well-served by email. Someone who just wants to fix one bug in one project they're not at all familiar with, and wants to dip a toe in the conversational waters a bit first, will probably be happier with web forums.
There also seems to be a generational aspect to it; people who came to the interwebs after 2000 seem to be much less comfortable with email in general than people who have been around since the elder days. (It's tempting to blame that on the rise of web-based email clients, which took away a bunch of the specific affordances of the earlier dedicated clients, but frankly I'm not sure that's not just rose-colored nostalgia goggles talking.)
Sumana Harihareswara
http://harihareswara.net
12 Aug 2014, 14:29 p.m.
Sorry, Greg - "'Wallet name' is a shorthand term for 'the name that appears on your government-issued ID.'" I use it in lieu of "legal name" or "real name" for various reasons. Sorry for the confusion. I've added a clarifying link to the post.
Nick Coghlan
http://www.curiousefficiency.org
13 Aug 2014, 8:26 a.m.
A few more suggestions for inessential weirdnesses:
- looking down on GUIs (especially GUI text editors and doing system management through a GUI). Most people are never going to have to worry about whether or not their text editor can be used over SSH, or debugging their system in single user mode. (I make a point of telling people my preferred text editor is a GUI application, specifically to counter the "real programmers use vi or emacs" nonsense)<br/>- looking down on the use of IDEs for programming.<br/>- arguing about top vs bottom posting when many email clients default to top posting, and people just use the default<br/>- arguing about (lack of) context pruning when many email clients hide quoted sections by default, so folks often won't even notice
For Calum: as Zack noted, mailing lists optimise for the heavily invested. They're great for things where you need to be heavily involved in a variety of different things, and if you have the skills needed to filter that email flood effectively. They're terrible if you just want to observe casually, or drop in, ask a single question, and get out again. Mailing list archives are also generally horrible in the way they interact with search engines (dropping you into the middle of long threads, often without any context). Unfortunately, web forums aren't an effective solution this problem, because they really are terrible relative to mailing lists if you're the heavily invested one (so I don't actually think this belongs on a list of inessential weirdnesses - we keep using mailing lists because they can be genuinely better than web forums when it comes to managing high traffic volumes across multiple projects). That said, Mailman 3 + HyperKitty is the first project I've seen which looks like it may be a mail/web gateway done right (letting mailing list users and web forum users collaborate effectively), so it will be interesting to see how much difference that makes when Fedora rolls it out later this year. (The "user profiles for mailing lists" aspect may also be interested in terms of helping to bridge some of the context dependent naming issues)
IRC is in a similar situation to mailing lists - people don't insist on using it out of stubbornness, we use it because it's better than the supposed alternatives. New services like Waartaa (https://www.waartaa.com/) aim to improve the usability to a point where folks can treat it just like any other web application, and let them ignore the fact that there's a whole network of IRC servers on the back end.
Nick Coghlan
http://www.curiousefficiency.org
13 Aug 2014, 18:37 p.m.
Another one that occurred to me this morning: language wars. If someone is excited about learning PHP to write their own WordPress plugin (for example), that is not the time to start in on a rant about what other language they should be learning instead. Indulging in such a rant is more likely to put them off programming and open source entirely than it is to convince to learn whatever language the ranter prefers.
karl
http://www.la-grange.net/karl/
14 Aug 2014, 20:57 p.m.
To add to the list: <br/>* Pre-made sentence 'Your API is not RESTful', 'Your code is not pythonic', etc. This plays not only on beginners but creates a hierarchy in between "knowledgeable" people.
* Open source as a guarantee to be better than others. There is a confusion that because it's open source the thinking standards are higher. Unfortunately, be people or organization, we can notice the same type of power struggles and abuse than private companies. The issue is often a lack of thinking in a global social context.
* 'Fix it' or 'the source code is here' triggered by someone making a comment about a project. The assumption that you have the right to have an opinion only if you are ready to commit time and competences for it. It's a very exclusive notion of the society. It relates a bit to the ancient system where only taxpayers had the right to vote.
* For emails. I'm also a big email users and have hard time with forums. But as you said I'm not using a Web mail client. In the last 25 years I'm using emails I have seen that evolution:
* Dedicated client -> Web mail client<br/>* People doing top posting <br/>* Mobility aka accessing emails from different devices.<br/>* Massive Notifications systems through emails
And basically 0 real evolution on mail clients to really handle emails as a conversation tool. They have been plenty of clients for Getting Task Done, aka emails as work or notifications. My own usage of emails is in fact mostly dependent on Spotlight indexing on MacOSX, aka the client is a shell on top of spotlight organizing the information.
Konrad Hinsen
http://khinsen.wordpress.com/
24 Aug 2014, 5:37 a.m.
An interesting list, thanks!
Looking at individual items, I wonder if they are really "weirdnesses", or rather "arbitrary choices that any community has to make". Such as e-mail lists vs. Web forums. There are people who prefer lists, and people who prefer Web forums, and I don't see why either one would be "weird" in an absolute sense. A community has to make a choice in order to function.
A comment concerning "standard English, with a mainstream minority using Latin plurals and into older styles of prescriptivist grammar". The Open Source community is quite international, and the cited description is exactly what non-native speakers of English learn at school.<br/>
As Sarah Sharp tweeted: "If two different newcomers ask about a jargon term, put it on a wiki. Don't include the terms experts think should be on it."<br/>
<br/>Someone asked about git, so I clarified the bullet point to mention that it's the terrible learning curve that's an inessential weirdness. When one points out an inessential weirdness, one is saying that it hinders outreach, and that we should be aware of that, and we have to figure out what tradeoffs we're willing to make in order to make bridges. In the case of git I predict the answer is generally "we can make some workarounds and onramps but git's not going away".<br/>
<br/>You may also be interested in Jed Hartman's experience with a Ruby on Rails tutorial that assumed he wanted to do enterprise-grade software engineering, and was poorly suited for hobbyists. Not everyone will need to learn high-octane software engineering practices, so we need to give the hobbyist crowd explanations that help them<br/>understand what they can skip; we run a risk of intimidating the toying-around crowd if we foist big giant syllabi on them that includes stuff they don't need.