►
From YouTube: Lessons Learned from Cultivating Open Source Projects and Communities - JJ Asghar, IBM
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Lessons Learned from Cultivating Open Source Projects and Communities - JJ Asghar, IBM
Over the last decade, I’ve had the privilege professionally of building and cultivating some Open Source projects and communities. I’ve grown other projects along the way some successful, and some not. I’ve learned a ton on this journey; honestly still am, and I want to tell this story.
https://sched.co/Nrmp
A
So
hi
everybody
I'm
JJ,
yes,
I
really
do
have
that
email.
Just
as
I
said
a
minute
ago,
I
am
a
developer
advocate
for
the
IBM
cloud
for
IKS,
which
is
the
IBM
kubernetes
service.
You
can
reach
me
through
your
Twitter
email
or
I,
even
even
set
up
WeChat,
because
the
first
time
I've
ever
been
in
China
and
it
was
kind
of
cool,
so
Tiffany
you
have
any
questions
or
thoughts
or
whatever
a
lot
of
this
talk
is
basically
things.
A
I've
learned
over
the
last
10
years
of
doing
open
source
projects,
I
started
about
back
in
2001
or
so
or
a
little
bit
earlier.
I
guess
where
I
was
being
part
of
a
small
small,
open
source
project
called
crux
and
Linux.
Sorry
see
our
UX
new
I
spent
some
time
going
through
eventually
got
into
the
OpenStack
world
I'm
not
going
to
brag
on
OpenStack
too
much.
A
But
there
were
some
really
interesting
lessons
to
learn
there
and
it's
neat
to
see
in
the
kubernetes
in
today's
ecosystem,
how
they've
taken
those
lessons
learned
and
appropriated
them
to
make
sure
they're,
successful,
successful
and
and
I'm
going
to
just
kind
of
keep
going
through
through
there.
So
first
thing
I
want
to
talk
about
this.
Isn't
the
tools
talk?
This
is
more
of
a
cultural
talk.
There
are
successful
ways
of
using
tools
to
help
get
success
for
your
open-source
projects,
get
no
joke.
A
A
In
the
days
of
when
I
first
started
back
in
back
in
2000
2000
one
or
so
it
was
really
easy
to
scope
a
open
source
project,
because
you
would
have
something
like
just
guts
get
Linux
out
there.
We
need
versions
of
Linux,
you
had
all
the
major
ones,
but
there
was
a
swim
specific
one
that
they
said
called
crux.
That
I
knew
where
we
used
the
BSD
style
ports
tree
where
everything
was
written
in
bash,
so
who
all
likes
bash
yeah.
We
got
a
couple
got
a
couple,
so
it
was
easy
to
use.
A
It
was
really
easy
to
to
bring
in
so
instead
of
you
having
to
deal
with
all
the
other
stuff
around
redhead
at
the
time
or
I
sent
to
us
was
just
starting
up.
You
would
just
have
like
your
init
scripts
being
bash
scripts.
You'd
be
able
to
do
make
files,
you
build
everything
from
source
and
you
would
actually
have
full
control
over
your
machine.
A
It
said
that
gen
2
actually
came
out
of
of
the
crux
original
tree
if
he
will,
through
all
that
process,
and
it's
it's
important
to
look
at
the
grand
thing
of
a
grand
scope
of
your
project
because
you
will
start
appropriating
other
things.
Scope
creep
is
a
real
thing
that
causes
real
problems
and
I'm.
So
sorry,
my
phone,
my
watch
keeps
buzzing
because
I
get
notification
so
showed
of
tongue
goes
off
my
bad
anyway.
A
So,
let's
take
of
one
of
the
negative
sides
of
scoping
your
project.
Let's
go
back
to
OpenStack
OpenStack
had
a
really
big
problem
where
they
wanted
to
bring
in
the
whole
world.
They
wanted
to
say
that
this
is
going
to
be
the
open
source
cloud
to
make
things
happen.
They
created
this
thing
called
the
big
tent,
which
allowed
for
anyone
to
start
an
OpenStack
project
and
get
it
put
into
its
say,
was
part
of
OpenStack.
A
Believe
it
or
not,
I
actually
have
three
of
them
to
my
name
is
we
do
have
three
OpenStack
projects
in
my
name?
First
is
the
OpenStack
chef
project,
because
I
was
a
chef,
employee
and
I
was
running
chef
at
the
time
and
I'll
talk
about
that
in
a
minute,
one
called
OS,
ops
and
then
an
Austin
for
the
OpenStack
summit.
I
actually
didn't,
took
me
only
15
minutes
to
start
an
OpenStack
project
and
get
it
actually
submitted
to
the
thing.
A
A
It's
a
good
way
of
saying
it
you
need
to
when
you,
when
you
are
scoping
your
project,
it's
personal
way
back.
You
can
sit
down
and
really
truly
build
it
to
what
it
wants.
Now,
if
you
look
at
what
Linus
did
with
the
Linux
kernel
and
then
you
look
at
something,
you
want
to
do
like
a
little
go
app
or
something
like
that
to
go.
Do
something.
There
are
two
totally
different
ecosystems
right,
but
they
come
from
the
same
idea
that
it
was
a
personal
project,
a
personal
drive,
to
get
something
done.
A
You
had
your
own
itch
to
to
scratch
right.
You
you
had
this.
This
problem,
you
needed
to
get
it
done.
The
beauty
of
personally
Brak
scoped
project
is
you
have
true
control
over
it,
unfortunately
few
and
far
to
between
to
be
truly
successful.
Nowadays,
open-source
projects
are
usually
collaboration
of
multiple
companies.
Multiple
people
to
come
together.
Very
rarely
do
you
ever
see.
One
person
truly
get
a
project
that
companies
we
use
in
the
major
force
totally
wrong.
B
A
Have
corporate
backed
open
source
projects-
and
this
is
this-
is
a
really
important
distinction,
because
with
corporate
back
you
actually
have
people
truly
sitting
down
and
working
on
the
projects.
You
still
have
people
like
hell,
I
work
at
IBM,
right
and
I'm
paid
to
work
on
open
source
projects,
because
the
things
that
I
get
to
work
on
help
benefit
IBM
to
be
successful.
It's
important!
A
A
Unfortunately,
there
are
a
lot
of
people
out
there
who
have
this
lack
of
word,
lack
of
a
lack
of
term
or
a
bit
of
salon
work
before.
Unfortunately,
there
are
people
out
there
who
create
a
firewall
between
their
project
and
their
audience
there.
You
need
to
be
inclusive,
you
need
to
bring
people
in.
You
need
to
be
able
to
convince
people
that
your
projects
good,
but
at
the
same
time
you
need
to
be
able
to
succeed
in
okay.
A
If
you
don't
spend
the
time
and
effort
to
work
and
reach
out
to
your
community
who
uses
your
project,
your
project
you're
not
going
to
be
successful,
you
cannot
have
an
open-source
project
where
it's
just
you
sitting
in
the
corner.
Writing
the
things
so,
yes
and
also
read
knees
are
important,
be
sure
to
write
a
good
read
me
to
be
able
to
make
sure
that
people
come
together
and
see
what
the
project
is
about
about.
There's
many
different
options
out
there
and
read
meets
are
extremely
important.
A
This
is
gonna,
take
a
little
bit
of
a
weird
turn,
but
there's
a
really
big
push
now
to
start
celebrating
specific
people
who
do
awesome
things
inside
of
inside
of
different
open-source
projects.
There
are
things
I'm,
gonna,
take
I'm
gonna,
pick
on
chef
software,
real
quick,
because
I
used
to
work
for
them.
They
had
this
concept.
A
If
you
can
talk
to
them
or
not
as
humans
I
mean
honestly,
who's
ever
actually
walked,
or
maybe
you
do
know-
maybe
you
don't,
but
if
you
know
Kelsey
Hightower
how
many
people
have
actually
walked
up
to
him
and
shook
his
hand.
I
to
this
day
have
never
been
able
to
bring
myself
to
do
it
and
that's
a
perfect
example
of
that
type
of
celebrity
celebrity
that
happens
with
these
celebrations.
I'm
not
saying
that
we
don't.
A
A
If
you
will
in
my
mind
that
was
a
defeat
in
my
mind.
It
showed
this
aspect
of
of
negativity
that
wasn't
great.
We
all
need.
We
are
trying
to
build
a
community
we're
trying
to
build
a
project,
we're
trying
to
be
successful.
We
need
to
be
able
to
create
an
aura
of
inclusive
inclusivity.
I
can't
speak
and
be
able
to
have
success
around
it.
Unfortunately,
when
you
start
bringing
in
going
back
to
OpenStack
when
you
start
bringing
too
many
things
like
I
said
about
the
big
tent
earlier
there's
this
aspect
of.
A
What's
a
good
word
for
it
way
too
much
too
many
things
coming
in
fact,
I'm
trying
to
make
the
sense
again
when
he's
not
using
my
idioms,
so
I'm
not
getting
across
what
I'm
trying
to
say
anyway
long
story
short,
a
a
the
open
source
project
can
be
defeated
by
the
wrong
people
being
involved.
The
wrong
purse
cope
of
what's
going
on
and
also
when
you
start
trying
to
eat
too
much
right.
A
If
you're
trying
to
bring
too
many
things
in
an
open
source
project
can
almost
try
to
get
in
and
opens
those
parts
that
can
fail
because
of
that
so
be
wary
of
the
scope
of
the
project.
Why
I
started
at
the
scope?
Because
if
you
bring
too
many
things
in,
you
could
take
you're
trying
to
boil
the
ocean
I,
hopefully
that
idiom
gets
across
well.
A
Let's
talk
about
some
successful
citrates
of
open
source
projects
now
so
things
that
I've
seen
actually
happened
that
are
successful.
First,
as
I
was
saying
about
a
good
readme,
a
way
for
people
to
come
in
and
actually
use
your
open
source
project
successfully
at
the
very
very,
very
beginning.
One
of
the
best
examples,
I've
ever
seen
is,
in
my
opinion,
a
vagrant
file.
Does
everyone
know
what
vagrant
is
yes,
okay?
So
there
was
an
open
source
project
that
you
saw
that
they
said
pull
down.
A
This
vagrant
file
do
a
vagrant
up
and
it
would
build
up
the
whole
project
in
its
a
vagrant
box
on
your
actual
laptop.
So
it
would
pull
the
code
down
in
from
github.
It
would
compile
it
for
you
and
all
of
a
sudden,
you
had
a
isolated,
a
sandboxed
version
of
that
software
on
a
vagrant
box.
So
it's
not
messing
up
your
machine.
So
if
you
realize,
if
you
need
to
use
it,
you
don't
have
to
worry
about
breaking
your
own
laptop
or
your
own
computer.
It
was.
A
It
was
an
unbelievably
powerful
way
of
doing
it
and
it
was,
it
was
very
secure.
It
was
great,
another
thing
is,
and
one
of
the
things
I
really
truly
loved
about
the
OpenStack
community
and
believe
was
successful.
Trait
is
that
they
forced
weekly
meetings.
They
made
sure
that
the
people
within
were
involved
actually
came
together
and
and
work
together
and
I
believed
at
the
time
not
Civ
act,
but
it
was
IRC.
A
We
were
able
to
get
on
IRC
allow
for
people
who
aren't
native
English
speakers
to
be
able
to
write
out
what
they
wanted
to
say.
So
it
was
very
clear
in
between
the
communication
was
very
clear,
so
it's
not
like
getting
on
a
zoom
or
a
video
conference.
It's
it's
like
getting
on
actual
text,
so
people
actually
had
exactly
what
you
meant
to
say
was
said
right
then,
and
there
I
still
remember
this
one
gentleman
from
the
OpenStack
chef
project.
His
name
was
Mars
I.
Think
there's
a
real
name
was
way.
A
Chen
and
I
was
really
hoping
to
meet
him
here.
I
didn't
happen,
though
he
actually
worked
at
IBM
at
the
time,
and
I
ran
ship
off
with
him,
because
we
were
able
to
talk
through
through
text
and
really
be
very
clear
about
what
we're
doing
we
were
able
to
get.
The
project's
done
eventually
became
a
very
high
ranking
member.
Our
project
over
the
open
source
for
OpenStack
chef
same
is
another
friend
of
mine
from
from
Germany.
His
name
was
Yann.
I
bet
about
the
friendship
through
him
through
IRC
of
the
works
we
were
doing.
A
Another
very
successful
point
of
of
an
over-sized
project
is
not
only
the
communication,
not
only
the
first
day
touching.
The
documentation
is
extremely
important
and
also
reach
ability,
and
then
it's
a
different
word.
It's
a
weak
word
to
say,
but
the
ability
to
have
to
actually
have
people
show
up
instead
of
just
at
that
meeting,
but
when
they're
working
on
our
projects
that
they
are
reachable
they're,
actually
human,
so
you
can
come
come
talk
to
him.
It's
a
very
important
portion
of
it.
A
So
when
you
start,
you
start
building
your
project
up
more,
you
start
having
to
deal
with
with
trust
issues.
So,
if
you're,
not
talking
about,
if
you're
talking
about
your
personally
backed
project,
I
mean
talking
about
your
corporate
back
project,
there's
still
this
intersection
on
that
Venn
diagram
of
trust
as
your
project
grows
and
as
you
get
more
people
involved,
which
is
the
ultimate
goal,
because
it's
open
source
you
steam,
you
steam,
you
need
to
start
letting
go
of
the
reins.
A
You
need
to
start
letting
to
trust
your
people
who
are
working
with
you
on
your
project
to
be
successful.
Unfortunately,
there's
are
a
lot
of
humans
out
there.
Don't
really
like
the
idea
of
trust.
They
can't
because
it's
their
baby,
it's
their
project,
they've
spent
all
their
time
and
effort
and
loving
on
it,
and
it
causes
this.
This
level
of
uncertainty
I
truly
believe
this
is
the
largest
mountain
for
most
people
to
climb,
especially
if
you're
a
leader
inside
the
project
or
if
it's
your
project
alone,.
A
And
it's
it
brings
in
this
it's
the
hardest.
It's
the
hardest
mountain
to
try
climb,
there's
also
a
maturity
thing
in
my
opinion.
Oh
as
the
project
has
become
more
and
more
mature,
there's
this
beauty
of
trust
that
can
happen
between
the
people
who
actually
put
the
software
out,
and
it's
actually
changed
over
time,
because
it
is
a
living
being
right.
As
the
project
code
becomes
scattered,
there's
different
portions
someone
can
take
an
ownership
of
a
specific
column
of
specific
things
inside
of
a
code
tree
or
whatever,
and
you
trust
that
those
persons
are
gonna.
A
Do
the
right
things
and
I'm
not
going
to
hit
the
button
anymore.
I'm,
just
gonna
use
my
left
mouse
there
we
go
I'm
going
back
to
the
read
means
from
originally.
The
idea
of
having
a
clear
vision
about
the
project
and
be
to
be
successful
is
extremely
important.
Have
a
scoping
paragraph
in
that
and
in
in
your
read
me
chef
eventually
got
to
doing
this
with
their
cookbooks.
So
there's
a
lot
of
open
source
code
books
at
chef's
out
there
and
unfortunately,
people
started
building
cookbooks.
That
would
do
everything
they
would
have
some
app.
A
That
would
be
like
I
deploy
my
app
and
it
turns
out
it
brings
in
RabbitMQ,
Postgres
and
and
tomcat
for
some
some
crazy-ass
reason,
modularity
and
and
clarity
became
so
important
at
chef,
so
we
actually
started
deciding
that
every
single
top
of
every
single
readme
had
a
scope
of
this
is
exactly
what
this
cookbook
does.
Does
nothing
more
nothing
less,
and
people
just
really
want
to
come
in
this
door
uh-huh,
and
it's
it's
very,
very
important
and
every
single
project,
in
my
opinion,
again
it
needs.
This
clarity
needs
that
scope.
Wine,
please!
A
A
Over
time,
as
you
start
becoming
more
successful,
you're
not
going
to
be
running
your
project
forever.
Let's
just
be
honest:
you're
gonna,
move
on
you're
gonna,
get
a
new
job.
You're
gonna
find
a
new
passion.
You're
going
to
do
you
need
a
plan
to
move
on.
You
need
people
back
to
the
trust.
You
can
hand
this
off
to
to
be
successful.
A
A
And
I'm
gonna
this
that
I'm
gonna
end
on
this
very
very
simple
question
is
even
worth
it
worth
it
in
the
long
run.
Doing
all
this
open-source
work
because
there's
a
lot
of
hassle
there's
a
lot
of
things.
You've
got
to
think
about,
especially
if
you're
trying
to
be
successful
in
this
world,
like
with
most
computers,
it
depends
like
it
really
does.
A
There
are
certain
times
where
a
closed
source
application,
where
you
can
only
you
only
do
inside
of
your
corporation,
but
you
never
released
to
the
rest
of
the
world.
It
might
actually
be
a
much
better
idea
than
open
sourcing
it.
You
really
do
need
to
think
about
all
the
things
around
it
and
the
community
building
that
is
required
to
be
successful.
Luckily,
there
are
people
out
there.
They
are
usually
known
as
developer
advocates
now
or
dev
rel,
or
things
like
that.
Who-Who
specialize
in
building
communities
for
projects.
A
A
A
A
I've
had
a
lot
of
release.
I've
had
some
great
successes.
I've
had
some
really
bad
defeats
hell.
If
you
go
to
my
github
page,
which
is
just
jayjay
Asghar
you'll
notice,
I
have
a
bunch
of
code
out
there.
That's
really
really
stale.
Also
so
I
know,
I
know
how
to
walk
away
from
a
project
of
any
tunes,
so
thoughts,
questions
too
everything's
open,
I,
don't
really
mind,
or
it
is
quite
warm
in
this
room.
Saying.
B
At
the
beginning
of
the
projects
initiated
in
the
upstream
and
ER,
do
you
have
any
suggestions
and
how
to
make
your
projects?
Well,
they
are
welcome
lot
of
people's
because,
especially
for
something
some
engineer,
especially
who
who
initiates
our
projects.
Some
of
them
are
not
very
good
that
you
give
such
a
presentation
some
conference.
So
do
you
have
any
suggestions
out
that
I'm.
A
So
yeah,
so
it's
about
your
question
is:
how
do
you?
How
do
you
recruit
more
people
into
your
project?
Is
that
that
is
another
question,
so
that's
a
very
that
is.
That
is
a
very
hard
thing
to
do,
because
you
need
to
find
the
right
people
to
be
really
involved
and
be
able
to
come
together
to
build
that
community.
Believe
it
or
not.
There
are
a
lot
of
Engineers
out
there
who
have
passion
for
very
specific
things
and
just
like
personality
traits.
There
are
people
who
really
truly
love
databases.
A
There
are
people
who
truly
love
messaging
ques
right.
What
you
need
to
do
is,
if
you
have
your
project
and
you're,
trying
to
find
people
to
be
involved
in
you.
You
move
that
you
move
yourself
into
one
of
those
groups
that
are
what
you're
looking
for
and
try
to
recruit
people
talking
about
the
cool
idea
you
have
and
with
that
eventually
you'll
get
that
you'll
you'll
see
people
come
along
to
your
project
to
be
successful.
A
It
requires
a
lot
of
effort
on
your
part,
because
you're
evangelizing,
you
are
going
out
to
tell
your
story
to
get
people
to
be
involved.
It's
like
finding
someone
for
your
company.
It
takes
time
to
really
really
Whittle
someone
down
to
come.
Join
you
right,
because
we
are
hype.
We
are
successful.
Engineers
I
mean
you're
at
a
kubernetes
conference.
You
obviously
are
the
the
cutting
edge
of
technology
right.
We
are
people
want
us
to
work
for
them.
Unfortunately,
we
also
get
to
choose
where
we
go
on
to
fit
into
normally
did
I
answer
your
question.