Just Ask and That Will Be That

This conversation took place in Montreal at the last day of the
Libre Graphics Meeting 2011. In the panel How to keep
and make productive libre graphics projects?, Asheesh had responded
rather sharply to a remark from the audience that only a very small number
of women were present at LGM: Bringing the problem back to gender is
avoiding the general problem that F/LOSS has with social inclusion.
Another good reason to talk to him were the intriguing 'Interactive
training missions' that he had been developing as part of the
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 on the Debian team. Today, he lives in Somerville, MA. He speaks
about his ideas to audiences at international F/LOSS conferences.

The interactive training missions are really linked to the
background of the OpenHatch 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.

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.

So how do you 'harvest' this cultural information? And how
do you bring it into your tool?

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.

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?

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 interpersonally, 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.

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?

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?

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?

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.

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

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.

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?

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

Why is it not awkward?

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

But in a way that is even more awkward?

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.

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.

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?

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!

So, to break that cycle you say there is a need to
externalize knowledge … like you are doing with the OpenHatch
project and with your project 'Debian for Shy People'? To not only explain
how things technically work, but also how they function socially?

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

And not because you sent a chocolate cake?

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.

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

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.

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.

It is amazing how valuable patience is.

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.

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

Yes.

It is nice to hear you bring up the value of patience. OSP
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?

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.

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

What do you mean by that?

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.

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

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!