►
From YouTube: Why we join and why we leave open source communities | Kevin Lumbard & Elizabeth Barron | CHAOSScon
Description
Why we join and why we leave open source communities
This talk will present the preliminary results from 40 interviews with corporate open source contributors. We asked them "what project characteristics do they look at when making decisions about joining an open source community" and "what project characteristics may influence their decision to leave a community".
A
How's
everybody
good
hello,
good,
I'm
elizabeth,
I'm
the
chaos
community
manager-
if
I
haven't
seen
you
please,
come
say
hi,
because
I'm
super
super
excited
to
see
everybody
here.
This
is
really
awesome.
A
lot
of
you
have
seen
on
zoom
or
in
the
slack
and
other
places.
So
I'm
really
happy
to
see
people
in
person
yeah.
So
this
is
kevin
I'll.
Let
you
introduce
yourself.
A
A
Okay,
so
several
months
ago,
kevin
and
myself
and
matt
german
pray
sean
goggins
over
here
and
a
student
named
wen,
embarked
on
a
research
journey
to
learn
about
how
corporations
were
engaging
with
open
source
projects
and
what
levels
they
were.
They
were
engaging
with
them.
We
talked
about
a
lot
of
things.
We
talked
to
34
people
so
far,
and
these
have
been
really
in-depth
conversations
about
an
hour
long.
Each.
A
We
have
a
list
of
20
questions
around
that
we
ask
them
all
kinds
of
different
things
about
open
source
everything
from
like
why
they
would.
Why
would
they
engage
with
open
source
communities
like
what
the
criteria
is
if
they
have
their
own
open
source
program
office
if
they
are
just
contributing
back
up
upstream
or
if
they're,
just
using
it?
What
the
structure
is
all
kinds
of
things?
We
also
had
talked
to
people
from
a
variety
of
different
backgrounds
and
roles
within
the
companies.
So
it
wasn't
just
you
know,
kind
of
one.
A
A
I've
been
in
open
source
for
20
years
and
I
have
joined
and
left
open
source
communities
myself,
and
so
I
have
my
own
perceptions
and
my
own
experiences,
but
it
was
just
extremely
interesting
to
hear
from
from
other
people
as
well.
So
after
we
were
gathering
this
information,
as
I
said,
we've
done
34
we're
not
quite
finished
yet,
but
we're
enough
that
we
can
make
some
general
some
general
assumptions
and
we've
seen
some
themes
floating
to
the
top
quite
a
bit,
so
we're
doing
a
qualitative
content
analysis.
A
We
look
at
all
of
the
the
transcripts
of
all
of
the
the
recorded
interviews
and
then
we'll
go
through
and
we
do
pair
coding
to
make
sure
that
we're
getting
a
balanced
perception
of
what
what
is
being
said,
an
interpretation
of
what's
being
said.
So
we
do
that.
We
have
a
couple
people
who
look
through
those,
and
then
we
see
what
themes
come
up.
We
code
code
words
into
them
to
make
sure
that
they're
you
know
we
lump
them
into
buckets.
Essentially
so
yeah,
that's
pretty
much.
B
Okay,
excellent,
so
the
the
themes
that
we've
started
to
pull
out
started
to
kind
of
look
a
little
bit
like
things
that
could
be
measured
by
chaos,
metrics
and
I've.
I've
just
thrown
all
the
themes
up
here
kind
of
randomly,
and
I
did
that
on
purpose,
because
I
want
to
illustrate
we're
we're
not
ranking.
I
can't
tell
you
that
any
of
these
themes
are
more
important
than
others
other
than
other
than
one
theme
on
there
and
that's
utility.
B
No
one
is
engaging
with
open
source
that
we
talk
to
for
altruistic
purposes.
It's
always
about
it's
always
about
utility,
a
problem
that's
being
solved
for
them,
but
but
otherwise
the
the
bold.
The
bold
themes
are
themes
that
we
really
saw
quite
often
from
multiple,
multiple
people,
and
we
saw
them
in
in
subtle
subtly
different
ways
and
I'll
just
I'll
kind
of
go
through
and
and
talk
about
some
of
them.
So
I've
just
mentioned
utility.
B
So
it's
does
the
project
solve
a
problem
for
us,
that's
the
the
first
thing
we
ask
when
we're
when
we
decide
if
we're
going,
to
use
a
piece
of
open
source
software,
but
it's
also
the
first
pers
first
thing
we
ask
when
we
when
we
decide
if
we
want
to
join
a
community-
and
that
really
is
what
we're
talking
about
here-
joining
a
community
and
engaging
in
collaborative
design
of
open
source
software,
all
right
so
oftentimes.
We
we
go
to
the
the
the
project
website.
We
look
for
documentation.
C
D
A
B
Okay,
so
documentation
one
of
the
first
places
we
look
when
we're
deciding
whether
or
not
we
want
to
engage
with
a
with
an
open
source
project
is
documentation.
Documentation
can
tell
us
a
lot
about
a
project.
The
the
documentation
that's
available
can
tell
us
about
the
professionalism
of
the
project.
It
can
start
to
give
us
some
ideas
about
the
quality
of
activity
that
happens
in
in
a
project.
Additionally,
it
can
tell
us
a
big
thing
that
we're
interested
in
and
that's
licensing
so
is
the
is
the
licensing?
B
Does
the
licensing
work
with
our
business
model?
Does
it
work
for
our
organization,
and
that's
that's
a
non-starter.
So
if
the
licensing
is
not
appropriate,
then
then
we
can't
be
there
other
things
that
we
look
at.
We
look
at
organizational
control
and
project
governance.
Those
two
things
are
are
somewhat
similar.
Organizational
control
refers
to
the
corporate
leadership
within
a
project.
So
if,
if
a
project
is
being
dominated
by
one
corporation,
we
have
to
ask
ourselves,
are
we
even
are
our
contributions?
Welcome?
Can
our
pull
requests?
B
Will
they
get
accepted?
Will
our
code
be
accepted
and
then
related
to
that
is?
Is
project
governance?
Does
leadership
of
the
project
share
those
those
same
values?
Are
they?
Are
they
willing
to
accept
our
code
so
we're
interested
in
how
the
project
is
governed
and
what
corporations
are
going
to
be
involved
as
well
usage?
The
usage
of
the
project
is,
is
a
is
a
big
issue
as
well,
so
for
us
to
for
us
to
make
an
investment
in
this
project
and
engaging
it.
B
B
If
we're
going
to
invest
in
engaging
in
this
project,
we
want
to
make
sure
that
we're
not
left
holding
the
bag
right.
Are
we
the?
Are
we
the
only
ones
working
on
it
or
are
there
other
people
involved
and,
interestingly
enough
culture,
and
especially
dei
that
one
kind
of
occurred
in
a
couple
different
places?
It
was
a
lot
of
our
interview,
subjects
located
that
within
sustainability
and
they
also
located
it
within
risk
and
the
so
the
the
risk
of
the
the
project
failing.
B
So
the
next
question
we
asked
was
why
we
leave
and
what
you'll
notice
is
that
a
lot
of
these
themes
were
on
the
previous
slide
as
well
and
we're
back
to
utility
again,
and
so
you
know
when
we,
when
we
stop
needing
that
project.
When
we
stop
needing
that
piece
of
software,
it
makes
it
makes
sense
for
us
to
leave
or
or
if
we
find
a
better
alternative.
B
D
B
So
being
managed
is
actually
so
what
that
one
is
is
when
you're
asked
to
do
a
lot
of
work
right
so
when,
when
you're,
when
you're
being
managed
by
the
by
the
project
and
you're
giving
you
come
in
and
they're
they're
asking
more
of
you
than
you
would
like
to
to
give.
So
it's
it's
different
than
project
governance.
It's
more
the
they're
asking
you
to
take
more
of
the
load
than
you
than
you're
comfortable
with.
B
B
B
B
Once
again,
we
see
we
see
project
governance
and
organizational
control,
so
these
are
the
and
it's
the
same.
It's
the
same
theme
that
we
saw
when
we
for
why
we
join
right.
So
are
our
contributions?
Welcome
and
can
we
make?
Can
we
help
move
the
direction
of
the
project
along
and
then
the
last
thing
we
have
once
again
is
culture,
and
I
will
say
I
will
say
this:
culture
was
probably
the
number
one
reason
that
our
participants
without
ranking
anything.
A
You
know
people
want
to
be
in
stable,
active
and
communities
and
that's
where
they
decide
to
engage,
because
when
you
think
about
it,
like
people's
time
is
very
limited,
and
so
you
know
they
they
tend
to
be
a
little
picky,
and
so
they
can
spend
their
time
wherever
they
want,
and
this
is
this
is
where
how
they're
making
their
choices.
So,
if
you're
running
a
community,
these
are
things
that
you
can
kind
of
grab
onto
and
improve
if
you
need
to
or
or
just
pay
attention
to
so
stability.
A
Again
he
mentioned
activity
having
more
contributors
is
always
a
good
thing,
share
the
load,
a
little
bit
maintenance
and
quality
of
activity.
So
it's
more
than
just
you
know
these
really
quick
comments.
There's
actual
meaningful
discussions
happening,
there's
meaningful
work
being
done,
not
just
you
know,
spammy
comments
or
whatever
that
doesn't
count
as
activity
and
then
inactivity
is
also.
You
know,
if
there's
nothing.
A
You
know,
I
even
had
someone
say
that
if
they
see
a
toxic
behaviors
in
a
community,
even
if
it's
the
best
software
in
the
world,
they
will
not
use
it
in
their
company.
They
will
not
use
it.
That
is
their
policy,
and
I
really
appreciated
those
comments.
I
thought
that
was
really
super.
Interesting.
So
no
longer
are
the
days
when
you
can
just
throw
a
piece
of
software
out
there,
a
piece
of
code
out
there
and-
and
you
know-
expect
it
to
just
do
great
things
you
really
have
to
to
center
dei.
A
E
C
What's
your
opinion
on
the
effects
of
like
optimized
contributor
pathways,
like
just
as
an
example,
one
of
the
communities
I'm
involved
with
there's
there's
like
dozens
like
if
you
stretch
the
definition,
like
potentially
thousands
of
ways
to
get
involved
their
project,
but
I
have
a
hard
time
articulating
like
what's
the
impact.
If
those
pathways
are
inoptimal,
you
know,
do
you
have
any
like?
Did
you
get
any
sense
of
like
the
importance
of
that.
C
A
B
It
was
not
a
theme
associated
with
these
two
questions.
We
did
have
a
few
questions
about
the
organizational
structure
of
their
corporate
ospos
and
some
of
the
the
methods
that
they
help
to
or
that
they
use
to
help
people
get
started
with
open
source
or
or
change
the
culture
of
their
organization
to
open
source.
But
I
I
don't
think
anything
came
up
about
a
distinct
path
or.
B
So
I
I
should
say
the
the
target
of
of
these
interviews
were
very
specifically
corporate
contributors.
So
so
that's
that's
really
the
only
the
only
focus
we
saw
we
we
didn't,
we
didn't
see
anything
for
for
non-corporate,
contributors
or
or
volunteers
of
that
nature.
It
was
all
corporate
participation.