►
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.
Be a Good Corporate Citizen in Kubernetes - Dawn Foster, VMware
As an employee, it can be difficult to strike the right balance between the needs of the company and the needs of the open source Kubernetes project. This can create friction and put significant pressure on employees who participate in Kubernetes on behalf of their company when the needs of the individual, the company, and the community are not aligned. This talk will focus on ways to create this alignment between individuals, companies, and the community required to be successful participants in Kubernetes. The talk contains three major sections: * How collaboration happens within the Kubernetes project. * How to build a strategy for participation that will benefit your company, your employees, and the Kubernetes community. * Tips for being a good corporate citizen as you contribute to Kubernetes.
https://sched.co/Zeju
A
First
I'll
tell
you
a
bit
about
me.
I've
spent
more
than
20
years
working
in
the
technology
industry
and,
most
of
that
time,
I've
been
working
on
open
source
projects
from
within
a
variety
of
different
companies.
I've
been
the
director
of
community
at
puppet
and
community
lead
for
intel's
open
source
technology
center.
I
also
have
a
phd
from
the
university
of
greenwich
in
london
that
I
got
by
researching
how
people
working
at
many
different
companies
collaborate
within
the
linux
kernel
before
the
vmware
acquisition
of
pivotal.
A
So
lately
I've
been
more
active
in
the
cncf
contributor
contributor
strategy,
sig
in
particular
the
governance
working
group,
I'm
also
a
board
member
of
open
uk,
which
is
focused
on
developing
and
sustaining
leadership
in
open
technology.
Here
in
the
uk,
I'm
a
governing
board
member
and
maintainer
for
the
linux
foundation's
chaos,
project,
which
is
focused
on
using
metrics
to
evaluate
the
health
of
open
source
projects,
I'm
also
on
the
advisory
board
for
petergia,
which
is
a
company
that
builds
open
source
health,
metrics
dashboards.
A
A
A
The
change
comes
from
an
individual
commits,
usually
include
a
name
and
an
email
address,
but
in
many
cases,
unless
someone
uses
their
corporate
email
address,
you
can't
even
tell
where
a
person
works
as
individuals.
There
are
plenty
of
opportunities
to
move
into
positions
of
leadership
within
the
community,
and
these
are
all
documented
in
more
detail
as
links
off
of
the
community
page
on
github,
but
I
wanted
to
provide
a
short
overview
to
help
people
understand
the
community
structure
within
kubernetes.
A
The
starting
point
is
here
at
the
bottom,
as
an
org
member
after
you've
made
a
few
contributions,
and
this
allows
people
to
assign
you
to
issues
and
other
activities
in
github
after
you
have
a
history
of
making
solid
contributions
and
reviewing
other
people's
contributions,
you
can
made
a
reviewer
and
eventually
an
approver.
These
roles
are
documented
in
owner's
files
which
indicate
the
parts
of
the
repository
where
you
have
those
responsibilities.
A
To
make
all
of
this
more
interesting
for
employers,
the
leadership
positions
within
kubernetes
stay
with
the
individual.
If
that
person
moves
to
a
new
company
and
let's
face
it,
kubernetes
skills
are
in
high
demand.
So
you
see
quite
a
bit
of
movement
between
employers,
for
example
within
the
past
year,
or
so
we've
seen
a
couple
of
people
on
the
steering
committee
and
many
other
leads
change.
Employers,
since
an
employee
can
take
their
leadership
position
in
our
project
to
the
next
job.
A
Companies
are
well
served
to
make
sure
that
they
keep
these
contributors
happy
in
the
kubernetes
project.
As
I
mentioned,
there
is
no
direct
way
for
companies
to
participate
other
than
dedicating
time
from
individual
employees
who
contribute
on
behalf
of
the
company,
which
is
becoming
increasingly
common
across
many
different
kinds
of
open
source
projects.
I
work
at
vmware
and
we
have
loads
of
people
working
full-time
on
kubernetes.
A
In
addition
to
devoting
time
from
your
employees
to
the
project,
the
cncf
also
relies
on
funding
that
comes
from
member
companies
to
fund
infrastructure
events
and
other
project
needs
and
I'll
talk
more
about
all
of
this
later.
Since
corporate
involvement
in
kubernetes
is
indeed
the
main
focus
for
this
particular
presentation,
the
kubernetes
community
is
made
up
of
a
wide
variety
of
individuals
who
are
working
together
to
make
kubernetes
awesome.
A
A
It's
important
to
keep
in
mind
that
you
are
likely
to
run
into
these
same
individuals
again
and
again
so
be
thoughtful
and
kind
when
working
with
others.
If
you're
a
big
jerk
in
one
community,
it
is
likely
that
other
people
will
remember
this
and
bring
your
reputation
with
them
into
new
projects
which
can
reflect
badly
on
you
and
on
your
company
as
an
employer.
It's
worth
doing
a
bit
of
due
diligence
to
see
how
someone
has
behaved
in
other
open
source
communities
before
you
have
them
contribute
to
kubernetes.
A
On
your
behalf,
this
individual
employer
and
community
triad
creates
unique
challenges
as
an
individual
contributing
to
kubernetes
or
any
other
open
source
project.
There
will
be
times
when
you
will
need
to
find
ways
to
create
balance
between
what
your
employer
wants
you
to
do
and
doing
the
right
thing
for
the
kubernetes
community,
which
can
create
really
awkward
and
uncomfortable
conversations
with
your
managers.
Sometimes
the
worst
case
scenario
is
when
there
are
direct
conflicts
and
what
your
employer
wants
you
to
do
would
go
against
the
best
interest
of
the
kubernetes
community.
A
A
You
can
make
this
easier
on
your
contributors
by
taking
the
time
to
understand
the
types
of
kubernetes
contributions
that
will
be
welcomed
by
the
community.
It's
important
to
have
regular
conversations
with
your
contributors
to
understand
what
the
project
needs
and
to
learn
how
you
can
work
within
the
community.
A
Personally,
I've
been
in
a
couple
of
situations
where
I've
left
companies
because
of
this
conflict
and
other
open
source
projects-
and
I
know
lots
of
really
amazing
people.
Who've
done
the
same
thing:
kubernetes
contributors
are
in
high
demand,
so
helping
your
employees
avoid
these
conflicts
in
the
first
place
will
help
you
retain
this
great
talent
now
that
we
have
a
better
idea
of
how
collaboration
works
in
kubernetes.
A
Next
up
we'll
talk
about
how
to
build
a
kubernetes
contribution,
strategy
and
plan
for
your
company
before
the
vmware
acquisition
of
pivotal,
I
was
responsible
for
creating
our
kubernetes
contribution
strategy.
One
key
to
having
a
successful
strategy
for
your
open
source
contributions
is
to
align
them
with
the
overall
business
goals
for
your
entire
company.
A
This
is
why
I
started
by
looking
at
pivotal's
corporate
and
product
strategies
when
writing
kubernetes
contribution
strategies.
I
made
sure
that
I
could
show
our
show
how
our
work
on
kubernetes
supported
our
overall
goals
as
a
company.
This
can
really
help
make
the
case
to
senior
management
and
company
executives,
who
are
not
likely
to
be
involved
in
the
low-level
details
of
the
project,
explaining
how
your
kubernetes
contributions
support
the
goals
of
the
company
can
help
the
exact
team
understand
the
importance
of
this
work.
A
On
the
other
hand,
when
your
goals
are
not
clearly
aligned
with
the
overall
strategy,
people
will
look
at
your
participation
in
the
kubernetes
community
as
something
that
could
can
just
be
cut
or
starved
of
resources
with
open
source
projects.
It
is
so
easy
to
fall
into
the
trap
of
describing
your
contributions
as
something
that
can
sound
an
awful
lot
like
charity
to
an
executive.
A
There
is
a
strong
open
source
ethos
of
contributing
to
the
common
good
of
the
project
or
what
people
often
refer
to
as
chop
wood
and
carry
water
tasks,
and
these
are
really
important.
We
all
need
to
pitch
in
and
help
in
a
variety
of
areas,
but
even
many
of
these
tasks
can
be
described
in
ways
that
help
your
executives
see
why
these
tasks
are
also
important.
A
It's
also
a
good
idea
to
encourage
employees
to
work
on
these
activities
when
they're
blocked
on
other
tasks,
like
maybe
waiting
for
pull,
request,
reviews
some
employees
might
see
contributing
to
kubernetes
to
be
its
own
reward.
Having
a
solid
strategy
can
also
help
employees
understand
how
their
work
contributes
to
the
success
of
the
company
as
an
employee.
It's
really
nice
to
see
that
your
work
has
an
impact
in
helping
the
company
achieve
their
goals.
A
Most
of
the
work
within
kubernetes
happens
within
the
dozens
of
special
interest
groups,
working
groups
and
other
committees,
and,
as
you
can
see
in
the
slide,
there
are
a
lot
of
them.
It
can
be
overwhelming
at
first
and
it's
unlikely
that
you
will
be
able
to
have
employees
contribute
to
all
of
these
areas.
A
So
you
want
to
focus
on
a
few
areas
that
are
the
most
important
for
you,
based
on
what
you're
trying
to
achieve
as
a
company
determining
where
you
need
to
contribute
within
these
areas
is
likely
to
be
the
focus
of
your
kubernetes
contribution
strategy
at
pivotal.
I
spent
a
lot
of
time
talking
to
product
managers
and
engineering
leadership
to
better
understand
both
our
current
pain
points
and
our
future
product
strategies,
so
that
I
could
understand
both
our
short
and
long
term
needs
for
the
various
kubernetes
technologies.
A
We
also
had
some
efforts
underway
to
start
shifting
our
applications
to
run
on
top
of
kubernetes
so
that
over
the
longer
term,
we
could
just
run
everything
on
kubernetes
to
support
this
longer
term
strategy.
We
had
people
start
working
within
sig
api
machinery,
since
most
of
our
product
teams
would
eventually
need
to
use
the
kubernetes
apis,
and
these
are
just
a
couple
of
couple
of
examples
of
where
we
decided
to
focus.
But
ultimately,
you
need
to
figure
out
the
best
places
for
your
employees
to
contribute.
A
If
you
aren't
sure
where
to
start
contributor
experience,
docs
and
release
are
all
great
things
that
are
both
friendly
to
newcomers
and
they
help
provide
more
insight
into
the
overall
project.
As
you
learn
more
about
how
kubernetes
really
works,
since
companies
contribute
to
kubernetes
by
having
employees
participate
and
collaborate,
you'll
need
to
figure
out
how
many
people
you
need
and
what
skills
are
required
for
those
people.
In
some
cases
you
might
have
employees
with
the
skills
you
need,
but
this
goes
beyond
just
knowing
the
right
technologies
or
having
particular
specialized
skills.
A
Contributing
to
any
open
source
project
like
kubernetes
requires
some
different
skills
than
participating
in
internal
projects.
These
people
need
to
be
comfortable
in
really
ambiguous
environments
where
they
will
receive
feedback,
possibly
difficult
or
negative
feedback
and
they'll
be
expected
to
respond
to
this
feedback
in
the
public
in
a
professional
manner.
Likewise,
they'll
also
be
providing
feedback
to
other
community
members
and
keep
in
mind
that
not
every
engineer
wants
their
work
to
be
in
the
public
spotlight
which
can
feel
like
being
under
a
microscope.
A
Sometimes,
if
you
don't
have
the
skills
internally,
you
might
be
able
to
find
existing
kubernetes
contributors
that
you
can
hire,
but
you
need
to
be
just
a
little
bit
careful
about
this
option
too,
because
you
don't
want
to
get
a
reputation
for
aggressively
poaching
employees
from
other
companies.
It
requires
a
bit
of
nuance
to
make
it
known
that
you're
interested
in
hiring
people
to
work
on
kubernetes
without
aggressively
hiring
them
away
from
other
employers.
A
A
It's
a
good
idea
to
always
join
the
main
mailing
list
for
your
sega
working
group
so
that
you
get
project
meeting,
invites
and
other
important
information.
Then
you
should
also
join
any
relevant
sub
project,
mailing
lists
or
slash
channels
that
you're
interested
in.
If
your
time
zone
permits
attending
the
sig
working
group
and
subproject
meetings
is
a
really
great
way
to
learn
more
about
the
current
work,
but
the
meetings
are
recorded,
so
you
can
watch
them
later.
A
You'll
also
want
to
have
a
close
look
at
project
documentation,
especially
the
contribution
docs
spend
whatever
time
it
takes
to
fully
understand
the
contribution
guidelines,
code
of
conduct
and
other
expectations
for
collaboration.
The
expectations
for
contributors
are
different
for
each
project,
so
don't
assume
that
you
know
how
to
contribute
to
kubernetes.
A
Even
if
you
have
experience
with
other
open
source
projects,
also
note
that
most
sigs
and
working
groups
have
their
own
contribution
guidelines,
they
cover
anything
specific
to
their
area.
So
you
want
to
have
a
look
at
those
too.
The
good
news
is
that
kubernetes
has
a
ton
of
really
amazing
documentation
and
virtual
workshops
for
new
contributors,
so
it
should
be
fairly
easy
to
understand
how
to
get
started.
A
I
also
recommend
taking
the
time
to
lurk
in
your
sig
or
working
group
to
understand
how
people
participate.
I
have
seen
too
many
over-eager
new
community
members
in
various
open
source
communities
who
jump
into
the
community
with
both
feet.
They
make
mistakes
by
violating
community
norms,
talking
about
things
that
aren't
relevant
and
just
generally
kind
of
making
a
mess
of
things.
A
You
should
start
with
something
small
like
bug
fixes
to
learn
about
the
contribution
process.
A
good
place
to
start
is
by
looking
at
the
issues
for
your
sig
or
working
group
and
finding
ones
that
are
tagged.
Good
first
issue
and
after
gaining
some
experience,
doing
a
couple
of
the
good
first
issue
issues
you
can
move
on
to
an
issue
that
you
find
interesting
or
you
can
look
for
issues
tagged
as
help
wanted,
which
are
issues
that
often
require
a
bit
more
experience
than
good
first
issues,
but
are
also
great
places
to
get
involved.
A
Once
you
start
participating,
you
should
expect
feedback.
In
some
cases
you
might
need
to
have
hard
discussions
with
people
about
the
merits
of
your
contribution,
but
you
can
focus
on
the
problem.
Deliver
your
feedback
with
a
bit
of
kindness
and
also
avoid
any
attacks
on
the
other
person
for
tough
conversations.
It
can
also
help
to
have
someone
else.
Read
your
response
before
you
post
it
publicly
to
help
catch
any
issues
with
tone
that
might
make
you
sound
more
harsh
than
you
think
you
do.
A
This
is
an
incredibly
difficult
line
to
walk,
sometimes,
but
staying
professional
and
being
kind
to
other
people
when
responding
to
difficult
feedback
can
make
a
big
difference
to
your
personal
reputation
and
the
reputation
of
your
employer
within
the
kubernetes
community.
In
many
cases,
especially
when
you're
new
to
kubernetes,
you
should
expect
to
iterate
on
the
feedback.
A
A
By
talking
about
these
contributions
very
early
in
the
process,
you
can
make
sure
that
they
will
be
consistent
with
the
expectations
of
the
project.
You
can
also
learn
about
anyone
else
who
might
be
working
in
similar
areas
to
hopefully
avoid
conflicting
changes
that
won't
work
together
once
they're
merged.
A
These
discussions
also
avoid
surprising
people,
especially
for
new
features
or
other
really
big
changes.
It
can
also
help
to
break
big
changes
into
smaller,
easier
to
digest
contributions.
It's
a
lot
easier
for
maintainers
to
find
time
to
provide
feedback
on
smaller
contributions,
and
it
gives
you
time
to
make
corrections
if
anything,
you're
doing
maybe
isn't
quite
right.
This
allows
you
to
iterate
on
the
feedback
through
several
contributions,
making
it
less
likely
to
have
bigger
fundamental
issues.
A
With
your
contribution,
it's
also
important
to
keep
in
mind
that
you
don't
really
have
any
control
over
other
participants
in
the
project.
This
is
different
from
working
within
a
company
where
you
can
escalate
any
issues
to
managers
who
can
work
to
resolve
problems,
non-responsive
employees
in
kubernetes
and
other
open
source
projects.
You
don't
have
a
strict
chain
of
command
or
other
ways
to
exert
control
over
the
people
you
collaborate
with.
A
Community
members,
and
especially
leaders
within
the
kubernetes
community,
should
expect
to
spend
some
time
helping
to
bring
up
the
next
wave
of
new
contributors
and
as
employers.
We
should
plan
to
have
our
contributors
put
some
effort
into
this.
This
could
mean
having
employees
who
are
experienced,
kubernetes
contributors,
mentor,
junior
employees
to
help
them
get
started
in
the
community,
or
it
could
mean
participating
in
the
many
mentoring
programs
that
are
available
within
the
kubernetes
community
meet
our
contributors
is
a
meeting
where
anyone
can
join
to
ask
questions
of
experienced
contributors.
A
We
also
have
shadow
programs
where
a
new
person
can
shadow
an
experienced
contributor
for
a
specific
role.
This
was
first
adopted
within
the
release
team,
where
each
release
has
a
leader
for
every
role
on
the
release
team,
and
each
of
those
leaders
has
a
couple
of
shadows
when
the
new
team
is
formed
for
the
next
release.
The
leads
for
each
role
are
usually
selected
from
the
previous
shadows,
so
this
is
a
great
way
to
move
into
a
leadership
position.
A
Now
this
term
is
a
little
bit
confusing
since
a
lot
of
people
think
of
financial
sponsorship,
but
in
this
case
it
means
using
your
position
in
the
project
to
advocate
for
someone
who
might
not
otherwise
have
the
same
opportunities
as
you
do.
This
can
be
as
simple
as
recommending
someone
to
help
out
with
some
part
of
the
project,
sponsoring
someone
for
org
membership
or
maybe
recommending
someone
as
a
new
reviewer
or
approver.
This
is
especially
important
for
the
underrepresented
folks
that
might
be
overlooked
or
might
not
be
as
forthcoming
about
asking
for
a
leadership
role.
A
A
lot
of
the
work
that
we
do
in
kubernetes
and
other
open
source
projects
is
based
on
the
relationships
we
have
with
other
people.
My
phd
research
was
based
on
collaboration
in
the
linux
kernel
and
as
part
of
that
research,
I
interviewed
a
bunch
of
kernel
developers
in
all
of
the
interviews.
They
talked
about
the
importance
of
their
relationships
with
other
people.
A
A
People
talked
about
how
it
was
sometimes
easier
to
work
through
really
difficult,
big
issues
at
conferences,
it's
easier
to
communicate
with
someone
online
if
you've
met
them
before
and
maybe
shared
a
meal
or
a
drink
or
just
had
a
nice
conversation
with
them.
Knowing
the
human
being
on
the
other
side
of
the
keyboard
can
make
a
bigger
difference
than
you
might
realize
now
granted.
This
is
a
bit
harder
right
now,
given
the
current
pandemic
at
all,
but
we're
making
do
with
virtual
events
like
this
one
with
video
calls.
A
If
your
employees
are
contributing
to
kubernetes,
then
you
should
encourage
them
to
attend
kubecon
and
kubernetes
contributor
summits
even
attending
virtually.
By
having
some
key
employees
attend
those
conferences,
they
can
build
deeper,
lasting
relationships
with
others
that
will
benefit
your
company
and
your
other
employees.
A
Upstreaming
your
patches
helps
you
become
a
good
corporate
citizen,
but
it
also
has
quite
a
few
internal
benefits
for
your
company.
If
you
aren't
familiar
with
upstreaming,
this
just
means
that
when
you
make
patches
to
fix
a
bug
or
solve
some
internal
need,
you
submit
those
updates
back
into
kubernetes,
rather
than
continuing
just
to
maintain
them
internally.
A
When
you
maintain
patches
internally,
every
time
we
cut
a
kubernetes
release,
you
need
to
go
through
the
work
of
reapplying
your
patches
and
even
possibly
rewriting
some
of
your
patches
if
they
touch
bits
of
code
that
were
changed
in
the
release.
The
side
effect
of
this
sometimes
difficult
process
is
that
people
then
tend
to
put
off
applying
updates,
which
can
be
a
big
problem.
A
If
the
release
contains
security
fixes,
while
it
takes
more
time
up
front
you're
better
off
taking
the
time
to
submit
these
patches
into
kubernetes,
where
they
can
be
properly
maintained
as
part
of
the
project
and
where
other
people
can
benefit
from
them,
the
easier
you
can
make
it
for
your
employees
to
contribute
these
changes
back
into
kubernetes
and
other
open
source
projects.
The
better
off
you'll,
be
in
general
upstream
patches
is
considered
the
right
thing
to
do
in
open
source
projects
which
will
help
maintain
your
company's
status
as
a
good
corporate
citizen.
A
I'm
going
to
wrap
up
this
talk
with
a
discussion
of
the
kubernetes
community
values,
because
these
values
do
a
really
good
job
of
summing
up
my
advice
for
being
a
good
corporate
citizen
in
kubernetes.
This
slide
has
most
of
the
community
values,
but
the
full
list
can
be
found
online,
along
with
descriptions
for
each
one.
A
In
kubernetes,
distribution
is
better
than
centralization
with
a
project
as
massive
as
kubernetes.
This
scale
is
only
viable
through
high
trust
and
high
visibility,
distribution
of
work,
so
authority
decision
making
technical
design
code,
ownership
and
documentation
is
delegated
to
the
various
special
interest
groups,
working
groups
and
committees.
A
This
is
why
I
recommend
that
you
focus
on
particular
sigs
and
working
groups
when
building
your
strategies
and
have
each
employee
focus
their
energy
on
at
most.
A
couple
of
areas.
Inclusive
is
better
than
exclusive.
Within
the
kubernetes
community,
successful
technology
requires
different
perspectives
and
different
skills,
which
are
easier
to
achieve
in
a
welcoming
and
respectful
environment.
A
A
We
show
respect
for
the
time
and
effort
put
into
a
contribution,
regardless
of
whether
the
contributor
is
brand
new
to
the
community
or
whether
they're
a
veteran
of
the
project.
Your
employees
need
to
be
prepared
to
engage
with
people
in
a
way.
That's
respectful
and
kind,
while
showing
appreciation
for
the
hard
work
of
other
contributors
in
kubernetes
evolution
is
better
than
stagnation.
A
It's
the
duty
for
leaders
in
the
community
to
find
sponsor
and
promote
new
community
members
leaders
should
expect
to
eventually
step
aside
community
members
should
expect
to
step
up
your
experienced
employee
contributors
should
expect
to
spend
some
time,
mentoring
and
or
sponsoring
newer
contributors.
These
can
be
other
employees,
interns,
google,
summer
of
code,
students
or
anyone
else.
Looking
for
a
new
opportunity
to
participate,
kubernetes
values
community
over
product
or
company.
So
it's
important
for
your
employees
to
think
of
the
needs
of
the
community
first,
for
the
benefit
of
all
its
members
and
users
everywhere.
A
Individuals
gain
status
through
their
work
in
the
community
and
companies
gain
status
through
their
commitments
to
support
this
community
by
providing
the
contributors
required
for
the
project
to
operate.
This
goes
back
to
when
I
was
talking
about
that
balance
between
individuals,
companies
and
the
community
as
an
employer.
It's
in
your
best
interest
to
make
it
easy
for
your
employees
to
prioritize
the
needs
of
the
community
and
not
try
to
push
your
own
agenda
when
it
isn't
in
the
best
interest
of
the
overall
kubernetes
community.