Download raw (19.6 KB)

Title: Just ask and that will be that
Date: 2011-08-19 09:23
Author: Femke
Tags: Conversations
Slug: just-ask-and-that-will-be-that
Status: published

**A conversation with Asheesh Laroia**

<small>Our conversation took place at the last day of the Libre Graphics
Meeting 2011 in Montreal, a day after the panel '[How to keep and make
productive libre graphics
projects?](http://www.libregraphicsmeeting.org/2011/day-3#AlessandroRimoldi)'.
Asheesh had responded rather sharply to someone in the audience who
remarked that only a very small number of women was present at LGM:
"*Bringing the problem back to gender is avoiding the general problem
that F/LOSS has with social inclusion*". This statement asked for an
explanation.  
Another good reason to talk to him are the intriguing 'Interactive
training missions' that he has been developing as part of the
[OpenHatch.org](OpenHatch.org) project. I wanted to know more about the
tutorials he develops; why he decided to work on 'story manuals' that
explain how to report a bug or how to work with version control.

Asheesh Laroia is someone who realizes that most of the work that makes
projects successful is hidden underneath the surface. He volunteered his
technical skills for the UN in Uganda, the EFF, and Students for Free
Culture, and is a Developer in Debian. Today, he lives in Somerville,
MA, working on OpenHatch.org. He speaks about his ideas to audiences at
international F/LOSS conferences.

Also available at [Future
Tools](http://www.ospublish.constantvzw.org/lgru/blog).</small>

**Bending culture**  
Asheesh Laroia (AL): The Interactive training missions are really linked
to the background of the Open Hatch project itself. I started working on
it because to my mind, one of the biggest reasons that people do not
participate in free software projects, is that they either don't know
how or don't feel included.  
There is a lot you have to know to be a meaningful contributor to free
software and I think that one of the major obstacle for getting that
knowledge, and I am being a bit sloppy with the use of the term maybe,
is how to understand a conversation on a bug-tracker for example. This
is not something you run into in college, learning computer science or
any other discipline. In fact, it is an almost anti-academic type of
knowledge. Bug tracker conversations are 'just people talking', a
combination of a comment thread on a blog and actual planning documents.
There's also tools like version control, where close to no one learns
about in college. There is something like the culture of participating
in mailing-lists and chatting on IRC... what people will expect to hear
and what people are expecting from you.

<!--more-->For people like me that have been doing all these things for
years, it feels very natural and it is very easy to forget all the
advantages I have in this regard. But a lot of the ways people get to
the point where I am now involves having friends that help out, like
"*Hey, I asked what I thought was a reasonable question on this mailing
list and I did not get any answer or what they said wasn't very
helpful*". At this stage, if you are lucky, you have a friend that helps
you stay in the community. If you don't, you fall away and think "*I'm
not going to deal with this, I don't understand*".  
So, the training missions are designed to give you the cultural
experience and the tool familiarity  
in an automated way. You can stay in the community even when you don't
have a friend, because the robot will explain you what is going on.

Femke Snelting (FS): So how do you 'harvest' this cultural information?
And how do you bring it into your tool?

AL: There is some creative process in what I call 'writing the plot';
this is very linear. Each training mission is usually between three and
fifteen minutes long so it is OK to have them be linear. In writing the
plot, you just imagine what would it take a new contributor to
understand not only what to do, but also what a 'normal community
member' would know to do. The different training missions get this right
to different extents.

FS: How does this type of knowledge form, you think? Did you need to
become a kind of anthropologist of free software? How do you know you
teach the right thing?

AL: I spend a lot of time both working with and thinking about new
contributions to free software. Last September I organized a workshop to
teach computer science students how to get involved in Open Source. And
I have also been teaching inter-personally, in small groups, for ten or
eleven years. So I use the workshops to test the missions and than I
simply ask what works. But it is tough to evaluate the training missions
through workshops because the workshops are intended to be more
interpersonal. I definitely had positive feedback, but we need more,
especially from people that have been two or three years involved in the
free software community, because they understand what it feels like to
be part of a community but they may still feel somewhat unsure about
whether they have everything and still remember what was confusing to
learn.

FS: I wasn't actually asking about how successful the missions are in
teaching the culture free software ... I wanted to know how the missions
learn from this culture?

AL: So far the plots are really written by me, in collaboration with
others. We had one more recent contribution on git written by someone
called Mark Freeman who is involved in the OpenHatch project. It did not
have so much community discussion but it was also pretty good from the
start. So I basically try to dump what is in my head?

FS: I am asking you about this, thinking about a session we once
organized at Samedies, a woman-and-free-software group from Brussels. We
had invited someone to come talk to us about using IRC on the
command-line and she was discussing etiquette. She said: "*On IRC you
should never ask permission before asking a question*". This was the
kind of cultural knowledge she was teaching us and I was a bit puzzled
... you could also say that this lack of social interfacing on IRC is a
problem. So why replicate that?

AL: In Debian we have a big effort to check the quality of packages and
maintaining that quality, even if the developer goes away. It is called
the 'Debian QA project' and there's an IRC channel linked to that called
\#debian-qa. Some of the people on that channel like to say hello to
each other and pay attention when other people are speaking, and others
said "*stop with all the noise*". So finally, the people that liked
saying hello moved to another channel: \#debian-sayhi.

FS: Meaning the community has made explicit how it wants to be spoken
to?

AL: The point I am trying to make here, is that I am agreeing to part of
what you are saying, that these norms are actually flexible. But what I
am further saying, is that these norms are actually being bent.

**Things that could be reasonable**  
FS: I would like to talk about the new mission on bug reporting you said
you were working on, and how that is going. I find bug reports
interesting because if they're good, they mix observation and narration,
which asks a lot from the imagination of both the writer and the reader
of the report; they need to think themselves in each others place: What
did I expect that would happen? What should have happened? What could
have gone wrong? Would you say your interactive training missions are a
continuation of this collective imaginary work?

AL: A big part of that sort of imagination is understanding the kinds of
things that could be reasonable. So this is where cultural knowledge
comes in. If you program in C or even if you just read about C, you
understand that there is something called 'pointers' and something
called 'segfaults' and if your program ends in that way, that is not a
good thing and you should report a bug. This requires an imagination on
the side of the person filing the bug.  
The training missions give people practice in seeing these sorts of
things and understand how they could work. To build a mental model, even
if it is fuzzy, that has enough of the right components so they can
enter in discussion and imagine what happened.

**Mixed feelings**  
AL: I have mixed feelings about using 'gender' as an important
characteristic when considering how to grow our communities. It is not a
bad idea maybe, and I am working on projects that are related to this as
well, but I think it permits a misunderstanding of the problem and puts
things in an awkward space, especially when the issue is addressed in a
room primarily filled by men and only a few woman. Is what the men say
sort of judge-able by the few women in the room? Are they speaking to
the women that are not in the room? It becomes all very tenuous and
confusing what you can or should say or do. We can skip this by
understanding the real issue, which is community inclusiveness.

Of course when there are real issues such as groping at conferences, or
making people feel unwelcome because they are shown slides of half-naked
people that look like them ... that is actually a gender issue and that
needs to be addressed. But the example I gave was: "*Where are the
Indians, where are the Asians in our community?*" This is still a
confusing question, but not awkward.

FS: Why is it not awkward?

AL: (laughs) As I am an Indian person ... you might not be able to tell
from the transcription?

It is an easy thing to do, to make generalizations of categories of
people based on visible characteristics. Even worse, is to make
generalizations about all individual people in that class. It is really
easy for people in the free software community to subconsciously think
there are no women in the room "*because women don't like to program*",
while we know that is really not true. I like to bring up the Indian
people as an example because there are obviously a bunch of programmers
in India ... the impression that they can't program, can't be the reason
they are excluded.

FS: But in a way that is even more awkward?

AL: Well, maybe I don't feel it is that awkward because I see how to fix
it, and I even see how to fix both problems at the same time.

AL: In free software we are not hungry for people in the same way that
corporate hiring departments are. We limp along and sometimes one or two
or three people join our project per year as if by magic and we don't
know how and we don't try to understand how. Sometimes external entities
such as Google Summer of Code cause many many more show up at the
doorstep of our projects, but because they are so many they don't get
any skills for how to grow.  
When I co-ran this workshop at the computer science department at the
University of Pennsylvania on how to get involved in open source, we
were flooded with applicants. They were basically all feeling
enthusiastically about open source but confused about how to get
involved. 35% of the attendees were women, and if you look at the photos
you'll see that it wasn't just women we were diverse on, there were lots
of types of people.  
That's a kind of diversity-neutral outreach we need. It is a
self-empowerment outreach: 'you will be cooler after this, we teach you
how to do stuff' and not 'we need you to do what we want you to do',
which is the hiring-kind of outreach.

FS: And why do you think free software doesn't usually reach out in this
way? Why does the F/LOSS community have such a hard time becoming more
diverse?

AL: The F/LOSS community has problems getting more people AND being more
diverse. To me, those are the same problems. If we would hand out flyers
to people with a clear message saying for example: here is this nice
vector drawings program called Inkscape. Try it out and if you want to
make it even better, come to this session and we'll show you how. If you
send out this invitation to lots of people, you'll reach more of them
and you'll reach more diverse people. But the way we do things right
now, is that we leave notes on bug trackers saying: “help wanted”. The
people that read bug trackers, also know how to read mailing lists. To
get to that point, they most likely had help from their friends. Their
friends probably looked like them, and there you have a second or third
degree diversity reinforcement problem.  
But leaving gender diversity and race diversity aside, it is such a
small number of people!

**The How-To-Contribute page**  
FS: So, to break that cycle you say there is a need to externalize
knowledge … like you are doing with the Open Hatch project and with your
project Debian for Shy People? To not only explain how things
technically work, but also how they function socially?

AL: I don't know about externalizing ... I think I just want to grow our
community. But when I feel more radical, I'd say we should just not
write “How to contribute” pages anymore. Put a giant banner there
instead saying: “This is such a fun project, come hang out with us on
IRC... every Sunday at 3PM”. Five or ten people might show up, and you
will be able to have an individual conversation. Quickly you'll cross a
boundary … where you are no longer externalizing knowledge, but simply
treat them as part of your group.

[The Fedora Design
Bounties](http://mairin.wordpress.com/2010/06/03/fedora-design-bounty-f13-feature-profiles/)
are a big shining example for me. Maírín Duffy has been writing blog
posts about three times a year: “We want you to join our community and
here is something specific we want you to do. If you get it right, the
prize is that you are part of our community.” The person that you get
this way will stick around because he or she came to join the community.

FS: And not because you sent a chocolate cake?

AL: Not for the chocolate cake, and also not for the 5000\$ that you get
over the course of a Google summer of code project. So, I question
whether it is worth spending any time on a wiki-page explaining “How to-
contribute” when instead you could attract people one by one, with a
100% success-rate.

FS: Writing a 'How to contribute' page does force teams to reflect on
what it takes to become part of their community?

AL: Of course that is true. But compared to standing at a job-fair
talking to people about their resume, 'How to contribute' pages are like
anonymous, impersonal walls of text that are not meant to create
communication necessarily. If we keep focusing on communicating at this
scale, we miss out on the opportunity to make the situation better for
individual people that are likely to help us.

**Patience is valuable**  
FS: I feel that the free software community is quite busy with
efficiency. When you emphasize the importance of individual dialogue, it
sounds like you propose a different angle, even when this in the end has
the desired effect of attracting more loyal and reliable contributors.  
AL: It is amazing how valuable patience is.  
FS: You talked about Paul, the guy that stuck around on the IRC channel
saying hi to people and than only later started contributing patches
after having seen two or three people going through the process. You
said: "*If we had implied that this person would only be welcome when he
was useful ... we would have lost someone that would be useful in the
future*".

AL: The obsession with usefulness is a kind of elitism. The Debian
project leader once made this sort of half-joke where he said: "*Debian
developers expect new Debian contributors to appear as fully formed,
completely capable Debian developers*". That is the same kind of elitism
that speaks from "*You can't be here until you are useful*". By the way,
the fact that this guy was some kind of cheerleader was awesome. The
number of patches we got because he was standing there being friendly,
was meaningful to other contributors, I am sure of it. The truth is ...
he was always useful, even before he started submitting patches.
Borrowing the word 'useful' from the most extreme code-only definition,
in the end he was even useful by that definition. He had always been
useful.

FS: So it is an obsession with a certain kind of usefulness?

AL: Yes.

FS: It is nice to hear you bring up the value of patience.
[OSP](http://www.ospublish.constantvzw.org) uses the image of a frog as
their logo, a reference to the frog from the fairy tale 'The frog and
the princess'. Engaging with free software is a bit like kissing a frog;
you never know whether it will turn into a prince before you have dared
to love it! To OSP it is important not to expect that things will go the
way you are used to ... A suspension of disbelief?

A: Or hopefulness! I had a couple of magic moments ... one of the
biggest magic moments for me was when I as a high school student
e-mailed the Linux kernel list and than I got a response! My file system
was broken, and fsck-tools were crashing. So I was at the end of what I
could do and I thought: let's ask these amazing people. I ended up in a
discussion with a maintainer who told me to submit this bug-report, and
use these dump tools ... I did all these things and compiled the latest
version from version control because we just submitted a patch to it. By
the end of the process I had a working file system again. From that
moment on I thought: these magic moments will definitely happen again.

**Just ask and that will be that**

FS: If you want magic moments, than streamlining the communication with
your community might not be your best approach?

A: What do you mean by that?

FS: I was happy to find a panel on the program of LGM that addressed how
this community could grow. But than I felt a bit frustrated by the way
people were talking about it. I think the user- and developer
communities around Libre Graphics are relatively small, and all people
actually ask for, is dialogue. There seems to be lots of concern about
how to connect, and what tools to use for that. The discussion easily
drifts into self-deprecating statements such as: "*our website is not
up-to-date*" or "*we should have a better logo*" or "*if only our
documentation would be better*". But all of this seems more about
putting off or even avoiding the conversation.

AL: Yes, in a way it is. I think that 'conversations' are the best,
biggest thing that F/LOSS has to offer its users, in comparison with
proprietary software. But a lot of the behavioral habits we have within
F/LOSS and also as people living in North America, is derived from what
we see corporations doing. We accept this as our personal strategies
because we do not know any alternatives. The more I say about this, the
more I sound like a hippie but I think I'll have to take the risk
(laughs).

If you go to the Flash website, it tells you the important things you
need to know about Flash, and than you click download. Maybe there is a
link to a complex survey that tries to gather data en masse of untold
millions of users. I think that any randomly chosen website of a Libre
Graphics project will look similar. But instead it could say when you
click download or run the software ... "*we're a bunch of people ... why
don't you come talk to us on IRC?*"

There are a lot people that are not in the conversation because nobody
ever invited them. This is why I think about diversity in terms of
outreach, not in terms of criticizing existing figures. If in some
alternate reality we would want to build a F/LOSS community that exists
out of 90% women and 10% men, I bet we could do it. You just start with
finding a college student at a school that has a good Computer Science
program ... she develops a program with a bunch of her friends ... she
puts up flyers in other colleges ... You could do this because there are
relatively so little programmers in the world busy with developing
F/LOSS that you can almost handpick the diversity content of your
community. Between one and a thousand ... you could do that. There are 6
million thousand people on this planet and the amount of people NOT
doing F/LOSS is enormous. Don't wring your hands about "*where are the
women*". Just ask them to join and that will be that!