►
From YouTube: The 10 Biggest Mistakes You Shouldn’t Make In Open Source - Bill Mulligan, Isovalent & Divya Mohan
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The 10 Biggest Mistakes You Shouldn’t Make In Open Source - Bill Mulligan, Isovalent & Divya Mohan, SUSE
Speakers: Divya Mohan, Bill Mulligan
“How can I get started?” is a common refrain heard from newcomers wanting to enter open source. This talk is the exact opposite - where you shouldn't invest your efforts while getting started. Being a new contributor to open source can be intimidating because you don’t know exactly what is helpful and what could hurt the community and frustrated maintainers. While a part of this gap can be attributed to the choose-your-own-adventure nature inherent to open source, there's already tons of material on how to get started technically. What nobody actually shines light on is the cultural dynamics. With this talk, the speakers aim to retell their experience and list common pitfalls almost everyone (including the speakers!) have made. This isn’t just about the right way to make a PR. The hardest, and most rewarding part, of any community is the people. The audience will learn how to engage in open source to ensure that the community they join will continue to be happy and healthy.
A
We're
going
to
be
speaking
about
you
know
the
10
biggest
mistakes,
you
shouldn't,
make
an
open
source
and
that's
partially
inspired
by
what
we've
experienced
and
what
we
have
committed.
As
you
know,
probably
mistakes
in
our
open
source
Journey.
So
before
we
go
ahead,
we
would
like
to
introduce
ourselves
because
not
a
lot
of
a
lot
of
you
all
know
us.
A
So
as
aforementioned
my
name
is
Divya
and
I
work
as
a
technical
writer
at
Susa
also
been
around
the
ecosystem
for
around
two
two
and
a
half
years
right
now,
working
on
a
bunch
of
Open,
Source,
Cloud
native
stuff,
but
yeah.
Most
of
my
you
know
career
prior
to
some
service
and
the
proprietary
side
of
things,
and
this
journey
has
been
really
eventful,
which
is
why
you
know
Bill
and
I
sort
of
thought
of
giving
this
presentation
about
how
folks
could
actually
avoid
this.
B
Yeah
so
I'm
Bill,
Mulligan
and
I
work
in
the
community
around
psyllium
and
ebpf
on
the
open
source
side.
Fun
fact
about
me:
I
actually
don't
know
how
to
code
at
all.
My
under
my
degrees
are
in
Biochemistry
and
social
science.
So
if
you
were
inspired
by
the
keynote
this
morning
and
want
to
get
more
involved
in
a
project
but
don't
know
how
to
code,
don't
worry,
there's
stuff
for
you
in
here
too.
A
But
before
we
go
ahead,
we
just
want,
like
a
you,
know,
show
fans
as
to
who's
actually
contributing
to
open
source
or
who's
actually
trying
to
get
into
contributing
to
open
source
like
oh,
that's,
a
fair
one.
So
the
very
first
thing
that
we'd
like
to
sort
of
share
a
shed
light
on,
is
you
know
basic
etiquette
right.
This
is
what
every
kindergarten
or
every
basic
preschooling
activity
teaches
you
to
say
or
be
pleases
and
thank
yous.
A
Unfortunately,
when
it
comes
to
you
know,
adult
interactions
I
think
we
kind
of
forget
them.
So
one
of
the
very
first
mistakes
that
you
could
possibly
make
is
to
not
actually
be
decently
courteous
to
the
fellow
human
beings
that
are
across
the
world
or
you
know
across
the
computer.
So
it's
very
easy
to
forget
that
you
know
that
that
person
who's
sitting
across
the
computer
is
not
actually
a
person,
so
you
should
definitely
definitely
be
courteous
and
show
basic
human
decency.
A
You
know
our
sponsoring
contributors
to
that
project,
so
as
much
as
we
love
for
you
know,
open
source
to
be
more
considered
and
or
empathetic
towards
the
contributors
and
towards
you
know
the
projects
that
we
projects
that
we
put
out.
We
also
want
for
the
reverse,
to
happen
with
us
right.
We
want
for
companies,
we
want
for
organizations
to
be
empathetic
when
they're,
interacting
with
us
too,
but
in
the
next
slide.
A
We
realize
that
it's
complicated,
because
again
human
interactions
are
complicated.
Humans
are
complicated,
so
when
we
talk
about,
you
know
interacting
with
another
human
being,
maybe
from
a
different
part
of
the
globe
or
maybe
from
a
you
know,
not
a
different
ethnicity
or
maybe
a
different
race.
It's
it's
very.
A
Like
how
can
we
actually
forget
about
you
know
folks,
coming
in
and
asking
maintainers
or
Contra,
like
you
know,
people
and
in
the
contributing
side
of
things
so
buy
a
particular
feature
was
not
implemented.
So
you
know
it's
very
easy
to
actually
say:
hey
I
actually
want
feature
ABC
to
be
implemented
in
this
project.
Why
don't
you
go
ahead
and
do
it,
but
the
thing
is,
it
is
a
lot
of
effort
and
open
source
projects
are
Community
Driven.
They
are
not.
A
You
know,
motivated
by
a
single
persons
or
a
single
company's
desire
to
move
forward,
and
it's
essential
that
we
take
into
account
what's
best
for
the
community
as
well
like.
Yes,
your
feature
is
important
and
it's
probably
important
to
you
as
a
person
or
you
as
an
you
know,
as
a
company
or
an
organization,
but
you
also
have
to
put
the
interest
of
the
larger
community
at
heart
while
making
suggestions
and
be
nice
or
and
show
basic
human
decency
while
requesting
for
features,
because
it's
not
easy.
A
A
lot
of
us
do
this
apart,
I
mean,
as
part
of
our
day,
jobs
and
also
outside
of
it.
So
if
you
know
you're
going
to
pester-
or
you
know,
you're
going
to
be
rude
to
a
maintainer
or
a
contributor
a
base,
maybe
a
side
effect
of
it-
will
probably
be
that
you
know
it'll
fall
on
deaf
years,
and
this
is
a
very
great
example
of
how
contributors
amongst
the
community
in
itself
were
not.
A
You
know
showing
the
basic
human
courtesy
of
actually,
you
know
allowing
another
contributor
to
step
up,
because
communities
strive
when
everybody
tried.
Try.
Everybody
within
the
community
thrives
so
if
you're,
not
allowing
for
other
contributors
to
step
up
or
if
you
as
a
maintainer,
are
not
providing
an
Avenue
for
other
contributors
to
step
up.
A
It's
clearly
a
miss
and
it's
clearly
a
lack
of
empathy
from
your
part
that
you
are
not
ready
to
delegate
or
let
other
people
step
up
and
do
the
work,
and
it
eventually
will
not
bode
well
for
anyone,
because
taking
a
lot
taking
on
a
lot
of
the
work
taking
on
a
lot
of
the
you
know,
pains
for
a
project
will
sort
of
lead
you
into
burnout.
So
nobody
wins.
A
If
you
are
not
actually
helpful-
or
you
know
allowing
others
to
step
up
and
take
on
roles
within
the
community
and
I
think
within
the
ecosystem,
there
is
already
a
guideline,
at
least
in
the
cloud
native
ecosystem.
We
have
a
basic
guideline
in
place
in
the
form
of
a
code
of
conduct
and
that
really
helps
at
the
set
the
Baseline
for
how
Community
interaction
should
be.
A
Although
most
of
the
times
we
do
find
that
events-
and
you
know-
even
just
you
know-
interactions
within
the
community
are
adhering
to
these.
There
have
been
cases
where
this
is
not
followed
and
often
oftentimes
it.
It
leads
into
unwanted
scenarios
where
you
know
you
have
to
take
people
aside
and
scold
them
like
their
little
children
and
that's
not
something
any
one
of
us
as
adults
cherish
so
being
considered.
An
empathetic
is
absolutely
important
when
you
are
getting
into
a
community.
B
The
next
thing
is
what
I
was
talking
about,
thinking
that
only
code
contributions
matter
as
I
was
saying
like
I,
don't
know
how
to
code
at
all,
but
I
still
make
a
lot
of
contribute
contributions
to
open
source
Upstream,
for
example.
What
I'm
doing
here
is
I'm,
adding
a
blog
post
to
the
psyllium
blog.
You
know
helping
spread
the
word
and
the
message
and
helping
other
people
find
what's
going
on
in
the
psyllium
community.
B
A
I
mean
documenting
pray
to
that
fallacy.
It's
not
the
case.
Code
cannot
be
self-documenting
for
everyone.
There
are
a
lot
of
new
contributors,
and
only
when
you
know
you
have
good
documentation,
can
you
drive
adoption
for
your
project
or
your
product?
You
know
if
you're
talking
from
the
proprietary
side
of
things.
B
And
beyond
that,
there's
lots
of
different
ways
to
contribute.
Besides
just
code,
a
community
grows
through
lots
of
different
things.
One
example
is
bringing
people
all
together
at
events
like
kubecon
or
in
more
local,
more
or
more
Regional
events
like
the
kubernetes
Community
Day
program,
bringing
adopters
of
cloud
native
Technologies
together
on
the
local
level,
you
can
become
an
organizer,
a
program,
Committee
Member,
someone
who's,
just
helping
like
spreading
the
message
and
tweeting
about
that,
and
that's
all
contributions
that
you
can
do
that.
Don't
require
you
to
know
how
to
code.
B
The
next
thing
that
you
shouldn't
do
in
open
source
is
trying
to
start
too
big.
You
don't
want
to
come
in
with
a
16
000
line,
PR
to
a
project,
maintainers
aren't
going
to
be
happy
and
it
probably
won't
get
accepted.
Also,
it's
not
a
great
place.
To
start
because
you
might
not
know
everything
about
the
project
and
actually
it's
a
lot
easier
to
smart
with
smaller
contributions.
These
are
actually
my
first
two
contributions
to
open
source
and
actually
kubernetes
2..
B
If
you
can't
quite
see
what
it
is,
the
one
on
the
upper
left
is
fixing
a
broken
link
and
the
second
one
is
adding
in
a
documentation
entry
in
the
kubernetes
glossary,
so
both
very
small
changes
but
helpful
for
people.
Looking
for
information
later,
yeah
and
I
think
your
first
code
contribution
was
similar.
Yeah.
A
A
Given
that
you
know
a
lot
of
people,
try
to
work
on
trivial,
edits
but
or
trivial
parts
to
a
project
but
automating
it
will.
Man
will
help
like
a
lot
of
manual
efforts
for
the
you
know
for
the
manual
efforts
to
be
saved.
Rather,
when
you
know
the
maintainers
actually
have
to
work
on
reviewing
and
everything
else,
so
don't
try
to
start
to
pick
even
minute.
A
Contributions,
help
and
focus
on
trying
to
reduce
the
manual
overhead
overall
rather
than
you
know,
targeting
you
know
for
small
edits
or
small
parts
of
the
documentation
because,
as
you
grow
in
the
community
impact
impact
matters
a
lot.
The
kind
of
work
that
you
do
matters
a
lot
and
making
trivial
edits
will
take
you
so
far,
but
you
should
also
go
beyond
that
and
try
to
help
the
project
in
general
with
reducing
the
manual
overhead
that
they
have.
B
Yeah,
the
next
thing
is
as
you're
starting
to
contribute.
There
are
a
lot
of
resources
in
a
lot
of
projects,
and
you
should
do
your
research
I
know
a
lot
of
maintainers
get
slightly
annoyed
by
the
questions
that
are
asked
repetitively
over
and
over.
If
you
saw
the
Keynotes
this
morning,
we
have
about
a
thousand
maintainers
supporting
seven
million
people.
Unfortunately,
that
doesn't
scale
out.
B
This
is
why
we
try
to
document
a
lot
of
things
and
you
should
try
to
see
what
is
out
there
kind
of
look
around
the
things
that
I
would
recommend
doing
if
you're
approaching
a
new
project
and
trying
to
figure
out
how
it
works
and
how
you
can
contribute
to
it.
The
first
one
is
read
the
readme.
It's
called
read
me
for
a
reason
and
it's
a
really
good
place
to
start.
The
second
one
is:
if
you're,
in
a
project
slack,
a
lot
of
them
have
pinned
items.
B
Those
are
important
things
usually
ways
to
contribute
style
guides,
important
resources,
who
you
should
contact,
look
at
the
resources
that
people
have
pointed
out
for
you
to
use
attend
a
meeting.
This
is
a
great
way
to
get
that
one-on-one
connection.
So
if
you
think
you
want
to
move
forward
with
something
and
you
do
want
to
get
in
contact
with
them,
a
lot
of
projects
do
have
meetings
and
the
last
one
is
most
projects
and
all
the
ones
under
the
cncf
should
have
a
contributing
file.
A
B
Yeah,
for
instance,
so
when
I
joined,
isovalent
I
wanted
to
add
some
things
to
the
website,
but
I
realized
the
how
to
contribute
to
the
website
wasn't
documented
anywhere
in
the
contributing
markdown
and
so
I
added
that
section
to
the
contributing
doc.
So
other
people,
when
they
want
to
contribute
to
the
website
in
the
future,
have
the
resources
to
be
able
to
do
that.
A
And,
like
I
said,
when
you
go
about
this
journey,
you
are
bound
to
require
help.
All
of
us.
Do
it's
not
like
a
lonely
Journey
where
you
have
to
you
know,
go
all
alone
and
reach
the
top
or
whatever,
because
like
I
said,
Community
thrives
when
all
the
members
Thrive,
so
people
are
available
to
Mentor.
It's
just
about
you
seeking
them
out.
One
of
the
major
I
think
mistakes
that
people
assume
when
they
are
experienced
is
that
hey
I
already
have
a
job.
A
I
already
know
XYZ
about
some
part
of
the
tech
industry.
I
don't
need
anybody
coming
in
and
telling
me
about
other
stuff.
I
can
probably
figure
it
out
if
I
read
the
documentation
alone,
but
that's
that's
a
major
flaw,
because
what
tends
to
happen
is
the
human
interaction
or
the
value
that
a
human
interaction
can
bring
is
grossly
under
noticed
by
most
of
us,
primarily
by
because
in
a
more
academic
or
corporate
setup,
mentorship
is
not
something
that's
actively
encouraged.
We
don't
have
programs
for
that,
so
in
open
source,
it's
different.
A
A
Ask
them
for
help,
obviously
ask
them
in
a
nice
way,
because
you
know
they're
humans
too,
but
it's
it's
instrumental
in
you
know
getting
your
journey
off
the
ground,
because
what
what
a
human
interaction
can
do
to
your
career
is
something
that's
that
no,
you
know,
reading
dog
scan.
So
that's
that's
one
thing
and
we
have
several.
You
know:
internship
programs,
it's
not
just
a
Google
summer
of
code
Google
season
of
dogs.
These
are
just
four
that
we
remembered,
but
there
are
several
of
them
and
fun
fact.
I!
A
B
Yeah
and
the
cool
thing
about
all
the
programs
listed
on
this
slide
is
they're,
actually
all
paid
too,
so
you
can
get
paid
to
learn
and
contribute
to
open
source,
for
instance,
right
now
in
the
psyllium
project,
we
have
a
mentee
working
on
improving
the
security
of
the
release
project
for
all
of
our
projects,
which
is
pretty
cool
but
beyond
just
like
paid
ones
or
those
programs.
There's
other
programs
across
the
EQ
system.
A
And
it's
a
it's
a
fantastic
program
to
get
involved
in
for
new
contributors
and
experience
to
like,
because
you
get
to
have
a
grip
of
the
ecosystem,
the
kubernetes
project
ecosystem,
of
course
not
the
entire
cncf
one.
But
you
understand
the
ecosystem
better,
because
there's
someone
to
hand
hold
you
and
show
you
the
ropes,
rather
than
you
trying
to
you
know,
clamp
it
all
alone.
So
this
was
one
of
the
instrumental
programs
where
I
met
a
lot
of
friends
and
I
made
a
lot
of
them
there
in
the
audience.
B
B
Well
there
he
got
inspired
to
start
contributing
to
the
project
and
became
a
Mainer
maintainer
of
one
small
part
of
the
kubernetes
project.
He
was
then
able
to
give
a
lightning
talk
at
kubecon
in
Valencia
in
May,
so
you
really
see
this
from
attending
event,
all
the
way
up
to
becoming
a
maintainer
and
giving
a
talk
at
kubecon.
It's
really
this
whole
Spectrum.
All
kicked
off
by
you
know,
attending
and
being
expired
at
the
local
level.
So
it's
a
great
way
to
meet
people
and
to
start
your
journey.
B
I
actually
also
have
a
similar
story.
This
picture
is
from
me
in
Barcelona
in
2019.
What
I
didn't
know
the
person
just
to
the
left
to
me
was
going
to
be
my
future
boss,
so
I'm
at
Liz,
first
on
a
bike
ride
when
I,
attended
kubecon
and
when
she
tweeted
I
had
actually
already
met
her
a
couple
times
on
bike
rides,
and
it
made
it
easier
for
me
to
find
my
job
at
I
surveillance.
A
So
that
is
one
aspect
of
it,
but
also
it
provides
a
nice
segue
to
the
next
one,
wherein
you
know
they
shared
their
learnings
with
us.
They
shared
their
mistakes
with
us,
whether
it
be
via
talk,
whether
it
be
via
a
blog
post,
whether
it
be
by
an
a
video,
all
of
them
shared
their
learnings
with
us,
and
we
try
to
pay
it
forward
by
doing
the
same
thing
so
I
think
Bill
writes
a
newsletter
every
fortnightly
basis
and
I.
A
Try
to
you
know,
write
a
newsletter
every
week,
not
successful
in
terms
of
the
fact
that
I
stick
to
the
routine,
but
I.
Try
and
that's
my
way
of
paying
it
back
forward.
I
mean
not
paying
it
back
forward.
That
sounds
wrong,
but
paying
it
forward.
So
that's,
that's.
That's
one
thing
that
you
always
need
to.
You
know
do
when
you're
in
an
ecosystem,
because
once
you're
at
the
states
where
you
are
able
to
you
know
you
know
you
know
something.
You
at
least
know
how
to
contribute.
A
It's
your
job
to
lift
others
up
as
well,
and
it's
absolutely
essential
that
you
pass
on
the
knowledge
to
another
contributor.
Maybe
experience,
maybe
you
know
maybe
new,
because
everybody
stands
to
learn
something
from
another
person.
I
learned
a
lot
by
working
with
Will
on
this
one.
So
it's
all
about
sharing
what
you
know
and
learning
from
others.
In
this
case.
B
Yeah
and
sharing
your
learning
is
another
great
way
to
do
non-code
contributions,
so
these
are
divios
and
eyes,
GitHub
repos
and
the
different
ways
that
we've
shared
our
learnings.
So
as
she
said,
we
each
have
newsletters
we've.
Also
given
different
talks
like
this
one
to
share
learning
with
the
community
we've
written
blog
posts
and
spoken
on
different
types
of
podcasts.
Each
one
of
these
are
great
ways
to
help
educate
other
people
and
get
them
involved
in
open
source.
A
A
Experiment
is
not
the
right
word,
but
I
didn't
have
the
time
to
experiment,
because
I
was
doing
my
nine
to
five
going
back
home
doing
the
daily
routine,
but
when
it
comes
to
open
source,
we
have
the
option
to
choose
our
own
adventure.
I.
Think
Taylor
was
the
one
who
actually
said
it
in
today's
keynote.
That
open
source
is
all
about
choosing
your
own
adventure,
so
that
that
is
one
thing
that
that's
afforded
to
us.
A
As
contributors
within
open
source
you'd
get
to
Choose
Your
Own
Adventure,
you
get
to
choose
where
you
go
next
and
if
you
don't
take
that
opportunity,
it's
you
know
going
to
be
sad,
because
every
every
single
interaction
that
you
have
every
single
you
know
talk
that
you
attend
could
be
the
next
thing
that
you
get
interested
in
and
Tinker
on.
So
my
journey
sort
of
looked
like
you
know.
First
I
was
an
electronics
engineer.
A
B
A
A
You
know,
join
people
along
for
the
ride,
because
otherwise
it's
just
going
to
be
a
long
long
journey
with
no,
you
know,
but
nobody
to
accompany
you
so
I
met
a
lot
of
you
know
my
friends,
current
friends
in
the
cloud
native
community,
and
it
also
definitely
helps
solve
the
problem
of
you
know
not
having
to
you
know
not
having
adult
friends
when
you're
30.
so
like
I,
basically
solve
that
problem
as
well,
but
having
a
community
around.
B
Yeah
and
I
think
the
best
part
about
open
source
is
once
you
leave
a
company.
You
still
get
to
work
with
the
same
people.
You
don't
have
to
leave
your
friends
behind
As
you
move
from
company
to
company.
They
keep
going
with
you
on
your
open
source,
Journey,
so
make
sure
you
make
friends
along
the
way.
Yeah.
C
B
A
D
Hi
as
someone
who
created
an
open
source
project
and
then
sort
of
left,
because
it
was
just
too
overwhelming,
how
would
you
recommend
dealing
with
people
who
come
with
a
great
feature?
But
accepting
that
feature
just
leads
to
more
work
for
you
in
the
future,
because
they
leave
and
don't
come
back
and
maintain
the
future.
B
I
would
honestly
just
be
clear
with
them
up
front
and
be
like
this
is
a
great
feature.
Unfortunately,
we
don't
have
the
support
maintenance
or
we
don't
have
the
support
required
to
like
keep
maintaining
this
we're
happy.
If
you
have
your
own
Fork
of
this,
where
you
do
that,
but
unfortunately
we
can't
maintain
it
Upstream
unless
that
person
wants
to
maintain
it
I
think
it's
easier
if
you're
just
transparent
from
the
beginning
and
like
maybe
defining
it
in
your
roadmap.
What
isn't
isn't
part
of
the
project?
A
Yeah
I
kind
of
agree
with
that
setting
expectations
right
at
the
start,
with
the
help
of
a
road
map
and
with
the
help
of
proper
scoping,
because
that
is
sort
of
what
helps
set
the
expectations,
and
you
know,
set
the
Baseline
for
how
you
know.
People
can
interact
with
us,
but
if
there
are
situations
where
that
arise-
and
you
know
with
that
situation
where
such
cases
arise
and
you
know
people
are
coming
and
asking
you
for
a
feature
or
demanding
rather
I.
Don't
think
there
is.
A
You
know
anything
wrong
with
them
asking
for
it,
but
you
need
to
communicate
to
them
and
that's
also
a
very
good
way
for
them
to.
You
know:
invite
potential
new
contributions,
so
if
they
want
to
start
maintaining
an
upstream
folk
of
it
or
whatever,
they
are
also
welcome
to
do
it
or
if
they
are
key
to.
They
are
okay
with
helping
out
with
the
maintaining
or
you
know,
creation
of
the
new
feature
or
enhancement.
A
They
are
welcome
to
do
so,
but
they
will
have
to
expand
the
efforts
that
require
any
further
work
on
it.
They
are
welcome
to
build
a
community
around
it
and
that
could
possibly
pave
the
way
for
newer
contributors
to
chip
in
so
it
again
setting
the
expectations
right
and
communicating
it
right
at
the
start
is
important,
so
I
completely
agree.
There.
B
E
Great
presentation
overall
I
love
it.
There
are
a
lot
of
people
that
I
imagine
here
that
are
trying
to
get
into
open
source.
So
I
love
the
tip
about
you.
Don't
have
to
be
a
developer
or
provide
no
or
code
contributions,
because
I
am
not
a
developer.
That
being
said,
can
you
explain
how
you
both
are
so
awesome.
B
I'm,
just
I
think
the
most
important
thing
is
like
it's
a
community
and
you
create
build
and
maintain
the
community
that
you
want
to
be
a
part
of,
and
so
I
think.
The
key
thing
is:
if
you
want
a
great
Community,
you
have
to
be
fun,
you
have
to
be
helpful.
You
have
to
encourage
other
people
to
contribute,
and
if
you
continue
to
do
that,
those
are
the
people
who
will
be
attracted
to
you
and
if
you
instead
create
a
bad
environment.
Those
are
the
people
be
attracted
to
you.
A
So
going
against
the
laws
of
physics
for
just
a
bit
like
attracts
like
at
this
point,
so
you
embody
the
values
that
you
want
to
build
in
the
community
yourself
and
I.
Think
the
rest
follows
like,
if
you're
transparent,
if
you're
truthful,
if
you're
honest
about
what
you're
doing
I
think
those
are
the
kind
of
people
that
you
attract
and
those
are
the
kind
again
setting
expectations
right
at
the
start
right
so
yeah,
okay,
we're.