►
From YouTube: Open Source Adulthood: What We Learned About Growing Up - Jean-Philippe Evrard & Kendall Nelson
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Open Source Adulthood: What We Learned About Growing Up - Jean-Philippe Evrard, SUSE & Kendall Nelson, OpenStack Foundation
With dozens of companies and countries, with thousands of people contributing to a single open source project, the community is bound to face some growing pains. On the rise there are more and more people every day hoping to contribute their new feature whether it actually fits in the project or not. For a while there are more resources than community knows what to do with, but eventually, a new project will come along and hopefully they can learn from the challenges that the projects before them faced. In this talk, attendees will learn about one open source community's rise in popularity and the transition to stable, mature project. Attendees will learn from the struggles of the OpenStack community and will be able to take the lessons we learned back to the Kubernetes and other CNCF communities.
https://sched.co/Zen0
A
A
I
am
kendall
nelson.
I
work
for
the
openstack
foundation
and
I've
been
actually
actively
involved
in
the
openstack
community
since
2015.
So
before
I
started
at
the
foundation
I
was
involved.
I
have
been
in
a
variety
of
roles
from
everything
from
technical
committee
vice
chair
to
the
release
management
team,
I'm
heavily
involved
in
contributor
onboarding,
so
I
work
a
lot
on
the
contributor
guide
and
the
in-person
training
we
have
called
upstream
institute.
A
I
have
also
done
a
lot
of
work
with
the
women
of
openstack,
which
is
now
our
diversity
and
inclusion
working
group,
but
other
than
openstack.
I've
also
been
involved
in
the
kubernetes
community
since
2019
in
sig
cloud
provider,
specifically
provider
openstack
and
sig
contributor
experience
when
I'm
not
working
on
open
source.
B
Hello,
I'm
jean-philippe,
you
may
remember
me
from
open
source
software
communities
that
are
not
communities,
because
I'm
new
in
here
as
jean-philly
might
be
hard
to
pronounce
what
the
non-french
speakers
you
can
call
me
jp,
I'm
working
for
souza
and
I've
been
involved
in
multiple
open
source
projects.
I
go
live
like
openstack,
sorry,
why
a
member
of
the
technical
committee
and
reviewer
in
a
few
projects?
B
B
A
So
today
we're
going
to
talk
about
the
stages
of
life,
not
just
for
a
person,
but
also
through
a
person
in
an
open
source
community
and
the
open
source
project
itself,
we'll
go
through
the
kind
of
life
events,
explain
them
on
those
different
scales
and
all
the
similarities
between
them.
So
we'll
we'll
walk
through
all
of
that.
While
we
also
walk
through
this
graph,
which
I
hope
you
are
familiar
with.
A
B
B
I
think
the
resulting
graph
can
match
events
in
personal
life
or
even
in
projects
life,
and
your
first
stages
in
lives
are
the
childhood
and
adolescence
phases.
I
hope
you
can
relate
to
this
graph
when
people
are
younger
they're
supposed
to
be
in
an
always
increasing
curve
of
fun,
slowly,
starting
then
growing
fast
and
then
slowing
down
at
least
the
curve
applied
to
me.
When
I
was
a
kid
I
had
tons
of
fun.
Let's
talk
about
this.
B
B
I
was
playing
both
games
with
a
certain
group
of
friends,
computer
games
with
another
and
well
you
get
the
gist,
and
basically
I
learned
to
play
games
with
friends
and
mostly
in
small
groups.
I
considered
that
I
was
like
a
kid,
because
there
was
very
little
I
had
to
worry
about
when
I
grew
up.
The
fun
factor
started
to
slow
down
because
I
had
tests
and
exams,
but
it
was
still
mostly
fun.
Even
during
those
test
periods,
I
was
still
playing
games
and
having
fun.
B
B
And
guess
what
it's
often
the
same
for
an
open
source
project
you're
in
a
new
class,
a
new
class
of
software?
You
do
something
different
than
the
other
class
of
software
before
you,
it
regroups
people
that
are
very
similar
with
it
with
identical
problems.
And
that's
the
start.
That's
the
monoculture.
You
start
with
you're
having
some
fun
with
the
people
which
contribute
to
the
project
like
you.
B
At
the
beginning
of
your
project,
you
don't
care
about
many
things,
except
getting
your
code
to
work.
So
you
don't
worry
too
much
about
your
project
community
building,
because
you
might
think
the
community
will
grow
automatically
with
the
workability
of
your
code.
At
least
you
feel
good,
because
you
see
new
people
joining
the
small
group.
B
Keep
in
mind
that
the
project
has
this
test
too.
The
projects
sometimes
have
hiccups.
It's
not
always
fun
to
set
up
what
you
don't
really
want
to
set
up
like
ci
cd,
for
example.
If
you're,
not
a
cicd
person
would
have
to
work
on
things
that
are
broken.
If
you
want
to
focus
on
acting
on
some
new
code,
imagine
yourself
as
a
new
contributor
of
a
project
at
first.
B
You
only
want
to
get
your
first
contributions
in
it's
fun,
you're
learning
from
the
other
people
having
the
same
problems
you
might
get
lucky
and
have
someone
mentoring,
you
or
maybe
you
ask
one-on-one
questions
with
someone
on
a
communication
channel.
The
next
stage
is
to
start
to
help
to
help
other
others,
sorry
and
learn
some
more
by
participating
in
project's
life.
B
But,
yes,
it
can
get
a
little
less
fun,
it's
a
little
less
fun
when
the
tests
are
not
passing.
For
example,
you
don't
have
to
care
about
the
test.
You
have
to
figure
out
and
fix
it,
but
at
the
end,
you're
even
happier
because
you
achieve
to
merge
something
and
you
help
the
community.
At
the
same
time,.
A
A
Fun
is
important
and
a
big
part
of
any
project,
but
it's
not
the
be
all
and
all
of
the
future,
so
moving
into
adulthood
now
adulthood,
as
like
a
stage
of
life,
I'd
like
to
think
I'm
an
adult
most
days,
definitely
not
as
fun
as
it
was
as
a
kid.
You
have
a
lot
more
responsibilities
now
I
like
help,
take
care
of
a
house,
and
I
have
to
pay
rent
or
help
with
the
mortgage.
I
you
know
have
to
work,
have
all
of
those
responsibilities.
A
This
is
all
things
that
you
think
about
when
you
are
a
contributor
in
a
project
too,
it
can
often
feel
overwhelming,
because
there's
so
much
work
to
be
done.
I
know
I
have
a
to-do
list
in
openstack
a
mile
long
and
another
one
and
kubernetes
a
mile
long,
but
making
friends
in
the
community
is
what
makes
it
all
worth
it.
All.
The
overwhelming
stress
of
everything,
building
and
maintaining
those
long-term
connections
with
other
contributors
is
my
favorite
part
of
my
job
they're,
my
friends
and
my
support
network.
A
I
will
do
whatever
I
can
to
help
them
get
jobs
and
if
I
needed
a
job,
I
would
like
to
think
they
would
do
the
same
for
me.
So
you
work
on
growth
and
community
roles
figuring
out
what
those
goals
are
might
also
be
difficult.
There
are
so
many
different
roles
in
every
community
and
they're
all
defined
differently
and
subtly
different
so
like
in
openstack.
A
You
have
a
core
reviewer
and
a
ptl
and
tc
and
all
of
this
alphabet
soup-
and
there
are
similar
roles
in
the
kubernetes
community
with
like
maintainers
and
like
sig,
chair
and
stuff,
like
that
and
figuring
out
which
roles
you
want
to
work
towards
can
also
be
hard.
If
your
focus
is
on
non-traditional
contributions,
it's
not
just
code
and
docs
all
the
time
time.
Maybe
you
want
to
help
with
the
sig
contributor
experience,
for
example,
and
once
you
achieve
these
goals,
you
realize
there's
even
more
responsibility.
A
You
go
from
working
towards
buying
the
house
and
then
now
you
have
to
maintain
the
house.
So
you
work
towards
achieving
this
role
in
the
community
and
then
now
there
are
even
more
meetings
and
there's
more
things.
You
want
to
do
and
there's
no
end
to
what
is
the
next
step
as
a
like
open
source
project.
There
are
events
that
happen
all
the
time
they
might
be
focused
just
on
your
project.
A
They
might
also
be
hosted
by
a
different
community
and
you
want
to
participate
and
help
bridge
the
two
communities
your
focus
becomes
on
simplification,
because
during
childhood
it
was
build.
All
the
things
go,
all
the
directions
at
once
explore
all
the
opportunities,
and
now
you
kind
of
have
to
bring
that
back
in
and
you
kind
of
become
the
enemy
of
your
own
popularity,
where
people
are
trying
to
do
things
that
were
not
within
the
original
scope,
and
you
have
to
bring
that
back
in.
A
So
there's
a
little
bit
more
resource
delegation
and
strategizing
that
you
have
to
do,
especially
if
your
project
came
about
at
the
same
time
as
one
or
two
others
that
really
weren't
that
different.
You
have
to
distinguish
yourself
from
them,
and
why
are
you
the
solution
or
maybe
they're
a
solution
to
a
slightly
different
problem?
A
And
what
do
you
do
with
like
all
these
contributions,
you're
you're,
drowning
in
patches
from
people
and
pull
requests
and
they're
like
more
things
than
you
know
what
to
do
with,
and
then
you
also
maybe
at
the
same
time,
are
drowning
in
people.
But
some
of
the
original
contributors
are
starting
to
move
on
and
you
have
to
adjust
to
that
as
well.
A
Well,
one
of
those
things
that
an
open
source
project
should
start
to
do
is
invest
in
the
community
working
on
communication
and
documentation,
kind
of
cleaning
up
the
onboarding
process.
There
are
probably
a
lot
of
barriers,
or
it's
not
clearly
written
down
anywhere,
so
the
documentation
is
important.
A
Documentation
is
always
the
most
important
thing
it
does
not
get
enough
time
and
then
the
last
thing
that
you
do
as
a
adult
open
source
project
is
maybe
kind
of
clarify
the
mission
a
little
bit
more
and
redefine
it.
If
you
need
to
to
help
separate
yourself
from
those
other
projects
and
kind
of
rain
in
on
the
sprawl
that
happened
during
childhood
and
the
rapid
growth.
B
So
during
so
during
early
adulthood
of
the
project,
we
wanted
to
continue.
We
wanted
to
continue
growing.
The
amount
of
people
grow,
diversity,
readjust
goals,
and
we
address
the
buyer
of
entry
like
improved
access
mandatory,
but
there
were
problems,
not
everyone
had
the
same
expectations.
The
new
goals
don't
fit
everyone.
B
People
have
frustrations
and
it's
more
work
than
you
expected.
So
what
we
learned
during
adolescence
and
early
adulthood
is
that
it's
hard
to
support
everyone
in
one-to-one
fashion
like
it
was
in
childhood,
so
we
had
to
deal
with
on
boarding
differently.
We
understood
the
need
to
simplify,
delegate
and
strategize.
B
We
need
to
do
something
for
the
project
and
we
co,
because
we
can't
continue
losing
people.
We
can't
continue
having
detractors
so
after
early
adulthood,
you
might
enter
the
next
phase,
the
midlife
crisis.
We
could
argue
that
some
projects
don't
go
through
that
crisis,
but
some
individuals
and
projects
do
so.
Let's
talk
about
it.
B
B
You
might
be
asking
yourself.
Why
do
I
have
to
deal
with
all
of
that?
I
don't
tell
this
too
tedious,
too
annoying.
Why
can't
I
take
a
little
bit
more
fun
where
I
can?
How
can
I
find
the
inevitability
of
life?
And
there
comes
the
midlife
crisis
you
can.
You
can
knock
your
face,
no
more
song
in
your
brand
new
sports
car,
but
then
you
realize
it
just
a
moment
and
you
acquire
more
wisdom.
B
B
B
I
should
probably
explain
what
the
big
tent
is,
and
the
tldr
of
it
is
that
the
big
tent
exploded,
the
list
of
openstack
projects
allowing
them
to
be
official
openstack
projects
at
the
end,
which
is
something
I
guess
we
could
talk
more
during
the
next
stage
of
the
maturity
cycle.
The
big
tent
helped
grow.
B
The
clear
scope
of
of
the
big
tent
was
a
good
thing
in
my
opinion
anyway
enough
talking
about
it
would
stack
it's
possible
at
the
time
at
the
time
that
midlife
crisis
happens,
that
people
leave
the
community
for
new
chinese.
But
yes,
people
also
join
your
project
and
the
crisis
of
the
downfall
of
contribution
of
contributions.
B
Before
we
talk
about
the
next
step
in
in
in
cycle
of
life,
I
wanted
to
share
my
experience
as
a
long-term
contributor
for
projects
for
which
uncertainties
also
happen
at
some
point.
If
you're
a
long
time
contributor
to
a
project,
you
might
be
getting
worried
about
what
you're
doing
where
you're
heading
you
might
be
concerned
that
software
defines
you
forever
have
a
label
on
you.
B
You
have
uncertainty
about
the
next
step
and
might
want
to
change
the
course
of
your
career
like
starting
to
raise
your
chip
in
the
mountains.
Instead
of
doing
software
development,
I
think
it's
fair
to
say
it's
normal
to
think
about
cardio
movement
and
it's
normal
to
test
or
not
new
chinese
software,
and
you
have
to
make
peace
with
you
or
other
people
doing
it.
B
It's
normal
that
your
friends
from
the
same
project
might
feel
the
same,
and
what
I
find
nice
myself
is
that
during
the
time
I
worked
on
a
project,
I've
established
some
nice
relationship
that
I
wish
to
keep.
Maybe
they
won't
be
on
the
same
next
open
source
project
as
I
do,
but
maybe
it's
gonna
be
the
one
after
that,
and
in
fact
that's
the
part
I
I
like
I
I
leave
with
that's
my
constant,
constant
during
uncertainties,
the
relationships
I've
built
in
the
open
source
communities.
A
A
A
It's
also
stable
at
this
point:
there's
not
a
whole
lot
of
growth
or
like
backward
steps,
which
could
mean
a
lot
of
different
things,
depending
on
where
you
are
specifically
in
your
life.
But
I
imagine
you
like:
have
your
budgets
pretty
solidified
by
then
and
you're
paying
bills,
or
maybe
you're
completely
done
paying
off
loans
and
100
debt
free
I'm
getting
there,
but
you
know
obviously,
there's
always
going
to
be
more
debt
to
acquire
too,
but
everything
is
self-driven.
A
I
have
spent
a
good
amount
of
time
over
the
last
two
years,
working
on
kubernetes
bridging
that
community
with
the
openstack
community,
because
there's
a
lot
of
good
that
can
be
done
together.
If
we,
you
know,
are
a
little
bit
more
mindful
about
what's
going
on
in
this
community
in
that
community,
that's
so
new
friends,
there's
you're
you
never
stop
making
friends
in
open
source.
That's
for
sure!
A
You
see
a
lot
of
the
same
people
and
there's
a
lot
of
the
same
connections,
but
there
are
always
new
people
that
are
joining
this
project
or
that
project
that
you
get
to
meet
and
connect
with,
and
then
old
friends.
They
obviously
stick
around
too.
Like
I
said,
the
the
same
people
keep
coming
back
around
and
they're
understanding.
A
You
might
be
in
maintenance
mode
and
not
taking
on
a
bunch
of
new
features
and
stuff,
and
that's
totally
fine,
you
might
be.
You
know,
focused
on
lowering
technical
debt
still
and
simplification,
and
that's
that's
good.
That's
a
different
sort
of
stability
and
maybe
you're
just
keeping
requirements
up
to
date,
different
sort
of
stability.