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:
Mary Gardiner added more observations (mostly her wording):
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?
10 Aug 2014, 20:05 p.m.
11 Aug 2014, 6:49 a.m.
11 Aug 2014, 14:22 p.m.
11 Aug 2014, 22:27 p.m.
12 Aug 2014, 14:29 p.m.
13 Aug 2014, 8:26 a.m.
13 Aug 2014, 18:37 p.m.
14 Aug 2014, 20:57 p.m.
24 Aug 2014, 5:37 a.m.