[clug] Barriers to entry in FOSS

Daniel Pittman daniel at rimspace.net
Sun Sep 13 05:27:33 MDT 2009


Brendan Jurd <direvus at gmail.com> writes:
> 2009/9/12 Jacinta Richardson <jarich at perltraining.com.au>:
>
>> You *can* make FOSS a more fun place for the women who are already involved
>> and for those who have the skills (or who want to develop them) to get
>> involved.  Making FOSS a more fun place for women should make it more fun
>> for men too.  There are lots of men who aren't involved in FOSS for similar
>> reasons to the women; they find it exclusionary, cliquey, they don't like
>> to be flamed for trying to learn, they don't want to dedicate 40 hours a
>> week to a project but would rather be a more casual contributor...  There
>> are lots of men in FOSS who stay despite disliking many of those
>> characteristics.
>
> I'd like to step away from the whole sexism thing and respond to Jacinta's
> more general point about barriers to entry in FOSS.

That sounds great to me; thank you very much for posting this, which I find a
*very* interesting read.  It turns out that my response is rather long, too,
for which I apologize in advance.

Those interested in the executive summary can probably skip to the last few
paragraphs and the footnotes without missing too much.

[...]

> After reading Jacinta's post, I spent some time thinking about the
> FOSS project I'm involved with (Postgres), how the community behaves
> and what I like/dislike about it.  Obviously I'm speaking purely from
> my own personal perspective here.
>
> The Postgres community seems to be pretty good at the whole not-being-sexist
> thing, but it does have a rather deserved reputation for a steep learning
> curve, and being tough for newbies to get into.  That's partially just the
> nature of the project (writing an RDBMS is hard) and partially the way
> members of the community behave on the mailing lists.

*nod*  This is reasonably common; a number of FOSS projects I have worked on,
or followed the technical lists of[1], and usually seems to be seen as coming
from the same source.

> I'm not saying that newbies are "flamed", necessarily, but if you appear on
> the Postgres hackers mailing list with a half-arsed idea or something that's
> already been discussed ad nauseum previously, you'll not get a warm
> reception.

*nod*  I actually have a lot of sympathy for this; asking sensible questions
or investing time learning is something I try to reward, but the irregular
posters who pop up on the LKML, for example, with their brilliant idea that
they just need someone to program up for them...


> To submit a patch, it must meet particular standards, and to have a patch
> committed it must be of exceptional quality.  If you fall short of either
> measure, nobody is going to pull punches in telling you what you did wrong.

I have not been involved in changing the patch review process of a FOSS
project, or seen one where it changed, but I have been involved in a number of
software development businesses where we have worked on these issues.

One of the things we found was that we got better results in the longer term
if we changed this: not by accepting changes that were poor quality, but
rather by investing in helping people produce better changes up front.

I strongly suspect, and would love the chance to test, that this same thing is
true of FOSS projects: by investing more up front you benefit in the longer term.

> In considering how I feel about the Postgres community, those are actually
> attributes that I respect and value very highly.  In getting involved with
> Postgres, I had to learn (and continue to learn) some lessons in humility,
> perseverence and patience.

Another interesting measure is how many people came in, encountered the
environment, and didn't stick around to learn these lessons on their free
time.  Not, I imagine, that it is easy to gauge that.


> I had to learn that being willing to put time into the project doesn't
> entitle me to the time of others.  The communication style, which some would
> find brusque or rude, was to me refreshingly honest, no-bullshit and
> matter-of-fact.  I saw how effective and enjoyable that style could be when
> used (and interpreted) properly.

It is certainly my experience, professionally, that it is quite possible to be
honest, direct, but not confrontational with as much good effect as the sort
of approach you describe above.

The same has held true when I am contributing to FOSS projects; a rude or
confrontational approach wins no friends, while a reasonable and polite
attitude makes it much easier to get my changes committed or recognised.

[...]

> But my experiences seem very much contrary to what you are espousing.
> Frankly I think that if the project had been as you describe, more
> welcoming, supportive and had a lower bar to entry, the pride and
> satisfaction I get from being a part of the project would be diminished.

I am willing to bet it would, but I don't think this is actually a good
thing.  Specifically, one of the ways the human brain works against its best
interests is that if you suffer significantly you will rationalize it as a
good thing, and will feel better about having gotten through the process, than
someone who has not suffered.

For example, in one experiment the volunteers were set to join a club, and
were told that they would receive three painful electric shocks as part of the
initiation.

The two groups were the "uncomfortable" and "quite painful" groups, basically,
and after the experiment those in the later group — who suffered more to get
in — felt much more positive about the club and their membership of it.[2]


In another, volunteers were the subject of, and witness to, a terribly
unflattering personality review by a psych.  The people who received the
reviews felt much better about them, and the whole picture, than the people
who witnessed them.  The later felt it was a nasty thing to do, while the
subjects who received these assessments rationalized them away.[3]


So, my point here is that you shouldn't be fooled by this quirk of your brain
into thinking that the initiation is necessarily good, even though you feel
better for having gone through it.

(...and sorry if I rained on your living-through-it parade. ;)

[...]

> I also recognise that the environment I described may only be fun for
> certain hacker types.

*nod*  Please also keep in mind that this doesn't just drive away the less
technically adept people.  I have quite limited time for contributing to
random FOSS projects, despite working on and discovering bugs with, quite a
few thanks to my work.

Projects that make it hard for me to meaningfully contribute quickly make it
hard for me to actually want to do anything useful for them.

> Sadly a FOSS project needs to attract other kinds of people too, such as
> technical writers, testers, advocacy/marketing types, planning/logistics
> types, and it seems to be just plain hard to create an environment that is
> inviting for all of them.
>
> Postgres has taken the step of splitting the mailing lists up somewhat, so
> you have the "hackers" list, the "general" list, "novice", "www", "advocacy"
> and so on.  This works to some extent, but there is necessarily a lot of
> interaction between the lists and a lot of newcomers post to the wrong list
> on their first try.

This is a good start, I think.  You might find some of the outcomes of the
DreamWidth project interesting.  (Though, if you are thinking about this
seriously you probably already know what follows; in part I include it for the
audience at large.)

That is built on the LiveJournal codebase, which is a *very* big, interwoven
system designed to both scale and provide high availability.

That isn't an easy environment to get into, for anyone, on top of which you
add that it is written in Perl, and built mostly on Perl infrastructure built
by the development team at Danga, for LiveJournal only.[4]

Despite this, DreamWidth have managed to pull a significant number of external
contributors who make significant and effective code changes.


One of the big things they did, and that has been identified as effective in
helping gain contributors, was to make a public statement about their position
on diversity and inclusiveness; I think that is a good model, because it sends
a clear message from the project, to everyone (inside and out) about what they
expect in terms of behaviour.

The Ubuntu Social Contract, for all the failings in implementation, is also a
reasonably effective tool and is targeting the same thing: helping make the
project accessible to other people.


Another major factor in their success was that they built a set of systems
where aspiring developers could get free access to scratch machines that were
already configured and ready to go for development.

This lowered the barrier for entry significantly, although I don't know how
relevant it is to PostgreSQL.  Getting the DreamWidth or LiveJournal codebase
running involves at least a half dozen daemons, several databases, and all the
infrastructure for a distributed work queue system, at least.

I guess, but have not checked, that PostgreSQL can pretty much do internal
verification with the standard './configure; make test' sequence, or so, which
keeps the barrier for entry of new developers and/or testers low inherently.

Regards,
        Daniel

Footnotes: 
[1]  I follow a lot more of those than I get involved in projects, because the
     answers to questions I have float by there more often, even if I don't
     get involved beyond that.

[2]  The effects of severity of initiation on liking for a group: A replication
     HB Gerard, GC Mathewson - Journal of Experimental Social Psychology, 1966

[3]  The peculiar longevity of things not so bad
     DT Gilbert, MD Lieberman, CK Morewedge, … - Psychological Science, 2004

[4]  Having worked on their code before and contributed changes, I can
     personally attest that this is a challenging and complex environment for
     people with many years professional experience in the area.

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.


More information about the linux mailing list