►
From YouTube: Balancing Yin (Community) And Yang (Company) In OSS - Nikhita Raghunath & Kiran Mova, VMware
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.
Balancing Yin (Community) And Yang (Company) In OSS - Nikhita Raghunath & Kiran Mova, VMware
The Kubernetes Annual Report [1] shows that there are very few contributors, especially senior and experienced folks, who are paid to work on k8s. The report also shows that PR reviews were down -24% across the k8s repo. The existing contributors are burnt out and have started to move away from the project. This is affecting the sustainability, quality and velocity of the project, with major regression-related backports in recent releases. It clearly shows that most companies profit from k8s but don’t contribute back. Continuing this model is a huge risk to the whole CNCF ecosystem. We will show strategies on how employers can practice “Business Aligned Open Source”. We will cover how to: - Add value to internal products, improve speed to market and innovation - Build expertise and better support customers - Have employees dedicate a certain percentage to upstream - Incentivize career growth - Surface areas of risk that require investment - Establish company’s influence and credibility in the community [1] https://www.cncf.io/reports/kubernetes-annual-report-2021/
B
So,
just
a
quick
disclaimer
that
this
is
all
our
personal
opinions.
We
are
now
speaking
on
behalf
of
our
employer
or
the
kubernetes
project,
or
anything
like
that.
But
most
of
our
experiences
are
derived
from
the
kubernetes
project
itself.
So
you're
going
to
find
a
lot
of
references
to
it.
I'm
a
kubernetes,
oh
I've,
got
to
do
the
intro,
so
I'm
a
kubernetes,
maintainer
kirin's,
also
yep.
A
B
A
A
You
can
keep
going
here,
I
think
she's
holding
the
controls.
So
why
does
it
matter
so
what's
open
source
is
pretty
simple
and
why
do
open
source
matters
every
app
or
like
you
know
we
have
to
if
you
have
to
stay
competitive
and
lead
the
industry
towards
a
certain
direction?
Doing
it
together
is
the
only
way
to
do
that.
B
A
A
B
B
And
just
wanted
to
give
a
quick
shout
out
and
thank
you
to
all
the
community
members.
We've
been
friends
with
so
many
of
them
and,
like
we've,
been
speaking
to
so
many
folks
who
work
on
open
source
as
part
of
their
day,
jobs
who
don't
work
on
open
source
as
part
of
their
data
jobs
and
the
struggles
that
they
face.
The
wins
that
they've
had
and
we've
tried
to
compile
them
into
sort
of
patterns
and,
if
you've
tried
to
present
them
in
the
slide.
A
Yeah,
and
also
thanks
to
all
those
people
that
work
behind
the
scenes
in
an
Enterprise
taking
the
projects
that
we
build
and
converting
to
a
product.
So
it's
not
really
about
like
a
project
or
a
product
both
have
to
go
together
right.
So
what
we
want
to
establish
or,
like
you
know,
share
with
you
are
the
patterns
where
we
can
co-work
and
help
each
other
out
right.
A
So
this
is
like
the
standard
in
and
Ang
kind
of
a
thing,
so
we
can't
do
this
alone.
We
need
the
support
of
the
product
teams
and
product
teams
can't
do
it
alone.
They
need
the
support
of
the
project
teams
and
the
whole
thing
I
just
wanted
to
plug
in,
like
the
Indian
context
of
this,
like
the
Inland
yang
is
like
a
popular
one,
but
we
also
see
that
manifested
in
almost
like
every
other
culture.
This
is
one
of
those
in
the
dancing
picture.
A
A
Open
source
gives
you
the
power
and
product
teams,
control
the
business
outfit
right
cool,
so
as
open
source
projects
right,
like
I,
think
the
we
all
understand
the
projects
that
we
maintain
and
we
are
really
good
at
it.
We
we
are
the
managers
and
the
product
managers,
everything
about
that
open
source
project,
but
that
project
alone
is
not
something
that
a
customer
needs
right.
A
They
have
to
put
together
a
lot
of
things,
so
the
product
companies
that
we
are
all
employed
in
have
this
need
to
assemble
all
of
them
together
and
make
a
solution
out
of
it.
And
it's
not
an
easy
problem
right
as
many
project
contributors
we
have.
We
also
need
product
Developers
for
that
one
right
and
this
list
is
just
growing.
A
part
of
the
growth
in
the
number
of
projects
that
we
are
seeing
is
also
a
problem
that
we
created
and
we'll
come
to
like.
A
B
So
from
the
2021
cncf
annual
report
and
I
think
this
is
almost
also
public
knowledge.
We're
seeing
that
kubernetes
has
crossed
the
chasm.
A
lot
of
companies
are
adopting
it,
they're
productizing
it
so
you've
got
a
lot
of
users,
building
platforms,
services
and
products
on
top
of
kubernetes,
which
also
means
that
kubernetes
experts
who
were
originally
contributing
to
the
kubernetes
project
they
are
required
by
their
companies,
their
employers
to
work
on
the
products,
because
that
is
where
the
customers
are
interacting
directly.
Now.
B
What
this
also
means
is
that
the
project
level
is
losing
contributors
and
if,
if
you
are
a
new
contributor,
if
you
even
if
you
are
an
existing
contributor
and
you
create
a
pull
request
or-
and
you
are
looking
for
reviews-
you
just
don't
get
that
right
now,
like
it
has
happened
with
me-
it
has
happened
with
a
lot
of
kubernetes
contributors
who
are
sitting
here.
You
create
a
pull
request.
B
Maybe
you
will
get
a
few
review
comments
and
the
con
and
the
review
is
disappear
for
a
few
days
and
they'll
come
back
again
whenever
they
have
time
now.
This
is
okay,
but
this
slows
down
the
project
in
terms
of
like
how
the
piaz
are
merged,
the
commits
are
merged,
which
also
means
that
this
is
a
problem
to
companies
and
businesses.
This
is
just
not
a
hypothetical
scenario.
It
is
a
problem
to
you
as
well.
B
A
B
The
kubernetes
2021
annual
report
from
the
steering
committee
also
says
that
a
lot
of
contributors
are
not
working
on
Upstream,
kubernetes
100
of
their
time
anymore,
which
was
true
a
few
years
ago.
Now,
it's
okay,
if
contributors
are
working,
say
80
of
the
time
50
60,
whatever
percentage
of
their
time,
but
it's
starting
to
affect
like
I,
said
reviewers.
B
Another
pattern
that
we've
also
seen
is
that
a
lot
of
senior
Engineers
they've
been
asked
to
work
on
the
products
and
so
on,
which
means
we're
also
losing
senior
Engineers
from
the
kubernetes
project.
We've
got
a
lot
of
new
contributors
showing
up.
We've
got
a
lot
of
students
showing
up
which
is
great,
like
I,
don't
want
to
say,
that's
not
good,
but
we
also
need
senior
Engineers
to
to
move
the
project
forward
and
that's
a
huge
problem
that
we've
been
facing
and
we'll
talk
a
lot
more
about
it
as
we
go
forward.
A
So,
with
senior
Engineers
going
out
of
the
picture
right
like
or
like
you
know,
there
could
be
so
many
reasons.
Maybe
they
have
gone
gotten
a
career
growth
and
they
have
taken
on
a
bigger
role
they
just
got
burnt
out,
which
is
also
like
a
real
case
that
happens
with
most
of
the
senior
engines
that
work
on
this
Project's
day
in
and
day
out.
Beyond,
like
you,
know
their
day
job
right,
so
it
results
an
interesting
pattern.
Now
companies
already
start
using
these
projects.
A
Now
those
companies
want
to
enhance
that
with
some
new
features
that
the
new
customers
are
asking
when
those
requests
are
coming
back
to
the
project.
The
project
maintenance
are
not
able
to
respond
to
those
requests
which
is
actually
seen
happening.
You
know
some
of
these
requests
take
longer
to
go
and,
like
you
know,
get
introduced
into
the
project.
A
This
means
product
companies
can't
wait
for
like
that,
long
for
a
open
source
project
to
show
the
roadmap
or
when
that's
going
to
be
done
so,
and
they
end
up
building
like
parallel
projects,
or
they
could
be
actually
maintaining
Force,
which
becomes
like
a
dangerous
situation
where,
like
you'll,
be
pulling
more
and
more
Engineers
away
from
open
source
and
also,
like
you
know,
increasing
the
complexity
in
terms
of
like
number
of
projects
that
are
like
coming
back
to
the
cnco.
For,
like
you
know
that
we
have
to
deal
with
for
Integrations.
B
And
one
of
the
biggest
challenges
that
I've
personally
faced
that
we've
all
personally
faced
is
just
convincing
Executives
to
in
and
Leadership
to
invest
in
Upstream
to
actually
hire
Upstream
Engineers.
So
when
we
first
proposed
it
to
our
leadership,
I
went.
We
went
in
with
a
proposal
which
said
okay,
if
it's
ignored,
for
whatever
sake
right
like
here's.
What
you
need
to
do
here
are
the
problems
that
the
Sig
is
facing.
Here
are
the
features
that
we
need
in
our
product
and
blah
blah,
blah
blah
and
all
I
got
was
blank
faces.
B
Execute
like
one
thing,
we've
understood
is
that
Executives
won't
understand
your
Sig
or
the
the
minute
problems
that
you're
facing
what
you
need
to
talk
about
is
numbers.
What
they
understand
best
is
numbers.
You
need
to
talk
about
customers,
the
customer
impact
that
they've
been
creating.
It
actually
reminds
me
of
an
analogy
that
Jace
had
once
read
who's,
also
a
kubernetes
project,
contributor
and
maintainer,
like
think
of
it
as
a
city
park
that
needs
to
be
clean,
and
the
park
is
too
large
for
any
one
company
to
clean
it
up.
B
So
if
you
as
a
company,
know
that
you're
going
to
have
a
picnic
in
one
part
of
the
park,
then
you
go
clean.
That
area
first
versus
all
the
other
areas.
That
is
a
logical
thing
to
do
because,
and
that
also
makes
you
good
citizens
and
it
also
serves
the
needs
of
your
company
and
open
source
projects
are
no
different.
So
if
you
as
a
company,
are
looking
to
invest
in
open
source,
you
need
to
build
a
strategy
which
impacts
your
customers
and
also
it
does
good
to
the
community
as
well.
B
The
other
thing
that
we
found
it
hard
to
convince
was
like
I
talked
about
senior
Engineers.
We
need
senior
Engineers,
who
can
invest
certain
percentage
of
their
time,
even
if
not
100
I
know
that's
hard
in
Upstream,
it's
still
a
hard
problem
for
us
to
solve.
It's
not
like
we've
solved
it
completely,
but
what
has
helped
in
the
past?
Is
we
talk
about?
Okay?
These
are
the
customer
issues
that
would
can
get
resolved
if
we
have
certain
senior
like
for
testing.
B
Another
huge,
huge
problem
that
we've
seen
is
comp.
Like
say:
we
saw
the
Staffing
problem,
the
hiring
problem,
so
companies
will
hire
Engineers
to
work
on
open
source.
They
might
hire
Engineers,
who
are
already
working
in
Upstream
and
they
might
even
give
them
time
to
develop
Upstream
expertise,
but
then
they
get
tasked
to
solve
customer
issues
and
now
again
this
is
not
a
bad
thing.
B
A
I'm,
a
manager
and
I
get
pulled
into
these
discussions,
so
the
pro
it
takes
a
long
time
for
any
feature
to
get
like
actually
into
the
product
or
like
into
the
release
of
the
open
source.
So
they'll
be
looked
at.
Like
you
know,
this
process
is
free,
they're,
not
working
on
anything
urgent,
but
this
customer
issue
is
urgent.
Let's
pull
them
and
make
them
work
on
this
right.
B
A
B
Here
are
some
data
points
to
kind
of
that?
What
we
are
all
talking
about,
this
graph
shows
the
average
monthly
commits
in
the
kubernetes
kubernetes,
so
the
main
kubernetes
repo.
So
we
saw
a
32
decline
in
2020.
It
was
likely
fueled
by
the
pandemic,
but
there
were
a
lot
of
other
reasons:
burn
out
the
world's
been
going
through
a
crazy.
B
A
B
So,
like
the
number
of
comets
has
been
it's
not
a
small
number,
it's
it's
like
when
you
look
at
the
graph.
It's
it's
going
around
like
crazy
and
what
happens
in
the
future
is
the
big
question
now
again,
why
might
this
be
happening?
So
this
crafts
from
stats
shows
company
contributions,
and
this
has
been
decreasing
over
time.
We've
not
included
any
company
names,
because
the
point
is
not
to
like
name
or
shame
anyone,
but
it
clearly
shows
and
it
like
companies
have
been
contributing
less.
The
comments
have
been
going
down
as
well.
A
B
And
we
have
almost
70
000
or
odd
contributors
in
the
kubernetes
project,
with
10
000
contributors
getting
added
every
single
year.
10
000
is
not
a
small
number.
We
are
not
increasing
our
reviewers
or
approvers.
We
call
approvers
as
folks
who
can
actually
sign
off
on
changes
to
any
pull
requests.
So
we're
not
adding
that
number.
So
the
ratio
has
been
getting
unbalanced
as
we
move
on
so
10
000
new
contributors
adding
every
year
the
number
of
reviewers
actually
declining.
B
The
other
thing
I
want
to
quote
mother
here
that
he
pointed
out
was
so
there's
this
thing
called
Chop
wooden
carry
water.
If
you
aren't
familiar
with
it,
it's
basically
the
unglamorous
work
that
you
do
it
to
be
something
as
triaging
issues
or
answering
questions
on
slack
or
mentoring,
a
new
contributor
and
so
on.
B
And
this
is
the
hardest
thing
to
measure
ever
like
the
metrics
on
this,
like
it's
very
hard
to
get
any
metrics
on
this
and
Dev
stats
just
like
counts
the
GitHub
events.
So
how
do
you
really
measure
mentoring
or
you're?
Answering
questions
on
slack
like
how
do
you
measure?
All
of
that?
That's
been
really
hard,
the
other
thing
that
takes
up
not
just
my
like
the
my
time
or
folks
in
working
in
my
employer,
but
like
everywhere,
we've
seen
this
everywhere
is
justifying
it
right,
and
this
takes
up
a
lot
of
our
time.
B
A
So
I
think
chopped
would
carry
water
people
that
come
to
this
conference.
We
they
get
called
out
in
like
the
Keynotes
they
get
awarded
in,
like
the
contributor
submits,
but
then
who
are
the
audience
that
are
actually
seeing
this
right?
So
we
do
need
to
carry
this
information
and
have
the
conversations
at
a
senior
leadership
level
where
these
are
important.
If
you
are
not
going
to
credit
these
people
that
are
doing
this
cwcw
work,
then
the
Investments
are
going
to
be
pulled
out
right.
A
So
we
have
to
have
like
some
way
in
which
we
can
quantify
that
the
ratio
that
we
have
between,
like
the
number
of
contributors
that
are
coming
in
to
like
the
number
of
maintenance
of
that
project,
that's
pretty
bad.
One
way
to
look
at
this
is
Imagine
like
if
you
are
running
a
product
product
Enterprises
have
like
really
good
metrics
around,
like
you
know
how
many
people
in
a
team
should
be
like
Junior
versus
Senior.
Why
is
it
different
for
an
open,
Source
right?
A
It
should
be
something
similar
right
and
the
other
problem,
also
like
with
respect
to
like
the
getting
new
contributors
has
been
senior
Engineers,
are
already
like
burnt
out.
So
we
end
up
like
when
new
contributors
come.
They
don't
know
how
to
navigate
this
entire
thing
and
get
to
contributors
or
like
maintenance
status,
and
then
they
just
run
away
right
or
like
they're
just
disappearing.
B
But
I
also
want
to
talk
about
some
positive
aspects
here.
So
if
you
look
at
the
number
of
unique
PR
monthly,
unique
PR
authors
they've
slightly
decreased,
maybe,
but
it's
almost
remained
the
same,
so
people
are
creating
issues,
they're,
creating
PRS
and
so
on.
If
you
look
at
the
average
number
of
monthly
pis
opened
it's
again
so
that
one
was
about
issues.
This
is
about
PR,
so
it's
almost
remained
the
same,
but
the
number
of
reviews
they
have
been
going
down
like
anything,
it's
again,
almost
like
a
linear
graph.
B
A
I
think
the
solution
is
probably
like
very
easy.
It's
right
in
front
of
us.
We
need
like
more
senior
Engineers
working
and
also
training
more
new
members
to
become
like
the
maintenance.
But
how
do
we
do
this?
That's
probably
where
this
is
and
I
think
like.
Some
of
these
graphs
have
helped
to
some
extent,
but
we
do
need
to
build
like
a
lot
more
data
around
what
the
senior
engineers
in
the
community
are
doing
to
encourage
more
investments
into
that
field.
So
this
is
an
interesting
graph.
B
Yeah
this
one
is
a
little
interesting,
so
this
graph
shows
the
number
of
review
comments.
One
thing
we've
noticed
is
the
number
of
review
comments
have
been
increasing
anecdotally.
What
we
are
like
correlating
it
is.
One
thing
is
that
the
project
is
becoming
complex,
so
the
newer
features
that
you
add
you
need
to,
like
the
reviews
are
pretty
complex.
The
second
thing
we've
also
noticed
is
that
new
contributors
try
to
jump
in
and
help
out
with
reviews
as
well,
which
leads
to
quite
a
bit
of
review
comments
too
yeah.
A
B
The
best
way
to
solve
all
of
this
is
mentorship
but,
like
you
said
all
seen,
almost
all
senior
Engineers
are
burnt
out
and
if
they're
not
employed
to
work
on
open
source,
they
just
don't
have
time
to
mentor
and
a
project
as
large
as
kubernetes.
A
lot
of
context
is
undocumented.
It's
just
lost
so
like
I
was
saying
like
I've
had
instances
where
you
create
a
PR,
you
need
someone
who's
who's.
The
original
author
of
some
part
of
the
code
base
to
actually
show
up
and
approve
that
PR.
B
A
I
think
like
a
related
problem
to
this
is
like
I've
spoken
to
some
people
where
their
companies
are
allowing
the
engineers
to
work
on
open
source,
at
least
like
you
know,
20
or
40
of
the
time,
but
they
don't
know
how
to
do
that.
So
it
comes
back
to
like
us
goes
back
to,
like
you
know
the
complexity
of
the
project.
It's
pretty
important
to
like
have
some
programs
in
each
of
these
open
source
projects
to
get
new
people
to
make
dinner
level
right
yeah.
A
A
So
one
quick
way
to
find
out,
like
you
know,
if
we
are
doing
the
right
thing
or
not,
is
like
a
quick
poll
on
people
who
are
contributing
to
the
open
source.
Are
they
doing
it
for
their
company
or
helping
someone
else
right?
If
the
answer
comes
as
like
I'm
helping
someone
else,
we
have
to
drill
down
on
that
right.
That's
not
a
very
sustainable
model.
A
There
could
be
like
a
handful
of
people
that
can
continue
in
that
mode
for
a
very
long
time
it
this
model
becomes
sustainable
when
we
have
more
maintenance
and
contributors
that
are
doing
this
for
their
company
or
themselves
right
yeah.
This
one
is
like
something
that
we
can
all
relate
to.
We
have
to
make
sure
like
we
put
the
mask
on
the
project
or
the
product
before
we
help
the
other.
So
what
do
you
think?
Which
one
is
the
project
in
this
case
mother
or
the
child
I.
B
A
B
A
B
So
one
other
thing
we
like
you
can
see
from
here
is
that
we
need
to
always
align
with
business
right
like
we,
business
alignment
is
the
biggest
thing
you
are
like.
Companies
aren't
going
to
fund
Upstream
Engineers
or
let
us
work
on
projects
in
Upstream
unless
it's
aligned
to
something
that
is
bringing
us
Revenue.
So
the
way
we
see
it
is
it's.
It's
a
very
basic
success
metric,
so
the
project
that
you're
contributing
to
must
be
thriving
and
the
products
that
you're
building
should
enable
your
customers
and.
A
One
thing
to
call
out
is
like
I
think,
like
most
of
the
organizations
know
the
importance,
there's
actually
like
a
central
body
that
helps
with
all
the
open
source
strategy
and
like
identifying
the
projects.
But
what
we
are
talking
about
here
is
each
product
needs
to
have
somebody
in
that
bu
or
like
the
product
team
or
the
portfolio
team.
That's
constantly
advocating
for
the
need
for
sustained
investment
in
the
project,
and
this
is
not
something
that
we
can
do
as
an
Engineers
day
in
and
day
out.
A
So
we
need
like
somebody
at
a
senior
level.
That's
constantly
talking
to
the
leadership
to
make
the
case
for
this
growth,
so
we
we've
been
like
lucky
I
would
say
not
like
a
really
bad
than
other
organizations
where
we
have
like
a
VP,
a
director
and
like
a
product
manager
that
understands
this
problem.
It's
important
to
have
that
kind
of
people.
In
this
case.
A
The
other
thing
that
I
just
wanted
to
bring
out
here
is
it:
when
these
things
are
not
there,
the
burden
comes
down
to
like
the
maintainers
and
what
should
the
maintenance
be
doing
right
I've
had
this
situation,
this
I'm,
just
quoting
in
my
own
team,
right
like
there
was
or
now
who
was
trying
to
help
out
with
the
recent
patch
release,
and
they
were
like
something
that
came
up.
I
had
to
pull
him
out,
but
if
I
keep
doing
this
again
and
again,
then
that's
not
a
sustainable
model
right.
A
So
there
has
to
be
a
solid
reason
for
pulling
somebody
out
of
a
commitment
in
the
open
source.
In
this
case,
we
had
to
pull
him
out
because
there
was
a
CV
related
stuff
that
was
going
on
to
figure
out
like
you
know,
if
we
should
be
doing
something
more
into
the
patch,
so
it
resulted
in
a
good
thing,
but
such
instances
have
to
be
like
minimized
as
we
go
forward
right.
A
They
have
to
do
this
extra
stuff,
like
act
as
a
engineering
manager
act
as
a
product
manager
or
you
know,
be
a
mentor
for
the
new
people
right
and
also
constantly
work
on
giving
small,
tangible
wins
so
that
the
team
is
motivated.
It's
very
easy
to
get
into
this
thing
that
okay,
things
are
not
working
good,
I'm
going
to
go
out
of
open
source
project,
that's
not
going
to
solve
anybody's
problem
right,
so
we've
been
lucky
to
have
dims
on
the
kubernetes
project
who
helped
us
navigate
this
thing,
yeah.
A
B
A
All
right
so
I
think
one
of
the
biggest
challenge
that
we
have
had
with
open
source
project
was
like
creating
silos
around
it
I.
So
the
pattern
that
we
have
observed
is
we
are
pretty
good
as
an
open
source
Community
serving
our
users.
This
is
pretty
much
like
a
great
correlation
between,
like
everything
that
happens
in
an
a
project
open
source
project,
and
if
you
consider
users
as
a
customers,
we
have
figured
that
out.
We
do
great
job,
you
know
great
products
are
coming
out,
but
the
moment
it
goes
into
customers
right.
A
We
kind
of
like
have
like
a
different
team
called
a
product
team,
so
we
don't
like
work
together
really
well,
it's
context.
Switching!
It's
not
always
like
going
to
be
easy
to
do
this
right
and
we
are
not
suggesting
that
like
people
who
are
contributing
to
the
project
should
be
contributing
to
product
teams,
but
there
has
to
be
some
kind
of
a
Synergy
here
right
so
listening
to
the
pain
that
our
Downstream
for
lack
of
better
word,
people
are
like
facing
and
trying
to
see.
A
If
we
can
address
anything
in
the
Upstream
will
be
like
a
great
way
to
create
this
balance
right.
So
just
like
how
users
get
into
a
customer's
Persona
and,
like
you
know,
users
are
like
the
early
adopters,
but
when
customers
with
it
like
a
lot
of
people
like
kubernetes
as
cars
and
kind
of
thing,
these
customers
have
a
totally
different
mindset
about
how
to
use
the
project
and
the
burden
of
like
enabling
them
falls
on
the
product
teams.
A
We
shouldn't
let
product
team
say,
like
you
know,
you're,
like
someone
else,
you
deal
with
the
projects
and
we
are
like
only
going
to
talk
about
like
the
community
right.
We
have
to
have
those
conversations
we
have
to
have
channels
where
we
engage
with
each
other
again,
just
to
be
clear.
We
are
not
talking
about
the
same
person
working
on
two
things.
It's
about
like
having
the
conversations
with
each
other.
B
I'm
sorry
I
should
have
been
pretty
clear
about
that.
So
we
we
mainly
care
about
three
things:
I'm
gonna
be
go
a
little
quicker
here,
because
we've
got
just
five
minutes
left,
so
one
is
actually
writing
the
code.
So
that's
the
implementation
part.
The
second
part
is
we
call
enablement,
so
that
is
actually
enabling
other
internal
teams
at
VMware.
So
we
act
as
the
feedback
loop
between
the
community
and
the
product
teams
and
finally
engagement.
A
So
I
think
we
all
want
to
grow
both
as
a
project
as
a
product,
but
also
as
individuals
right
and
it's
not
always
going
to
be
a
straight
path.
There
are
times
it's
a
sine
wave,
that's
what
we
have
realized
working
on
this
and
they
both
have
to
go
together.
If
one
one
of
them,
like
you
know,
falls
apart
like
it
pulls
down
the
other
one.
That's
really
important
for
us
to
like
understand.
So
this
is
like
from
the
Detroit
streets.
A
B
Yeah
and
things
that
have
worked
well
for
us
is
one
is
customer
trust.
So
if
any
Upstream
like
kubernetes
or
any
other
open
source
project
escalation
comes
in,
like
customers
would
trust
us
to
solve
that
issue,
because
we
have
expertise
in
that
project
and
also,
even
if,
like
just
because
we
are
participating
in
the
kubernetes
project.
Like
we
build
friends,
we
build
a
network,
so
we
build
karma
in
the
project.
For
example,
I
don't
work
on
security,
but
I
know
pushkar,
who
does
who's?
B
A
B
A
B
Some
and
the
biggest
thing
that
so
all
of
this,
like
it
doesn't
really
matter
to
be
honest
at
the
end
of
the
day,
what
really
matters
is
how
we
feel
when
we
are
contributing
and
the
biggest
thing
that's
worked
out
for
me
and,
like
you
can
see
in
all
of
these
quotes
from
nabara
and
who's.
Also,
a
steering
committee
member
is
the
global
impact
that
you
create,
the
impact
that
you
create
both
internally
externally
and
how
you
see.
B
A
And
for
me
manager
perspective
right,
it's
you
know
when,
when
you
work
in
an
Enterprise
product,
you
have
like
some
customer
success
and
all
those
metrics
that
you
can
pull
in,
but
it's
also
important
to
get
your
managers
to
attend.
Events
like
this,
especially
the
contributor,
Summit
or,
like
you
know,
ask
them
to
like
see
the
Twitter
there's
like
so
much
that
your
team
is
doing
that's
out
there.
The
appreciation
is
all
out
there.
A
You
know
I
think,
like
somebody
has
to
act
that
you
know
put
that
bridge
on
bringing
that
back
into
the
company.
I
think
like
CNC
or
like
kubernetes
Community
does
a
great
job
of
like
if
you're
already
contributing
you
reach
out
to
them
and
tell
that,
like
you
know,
we
want
to
use
this
for
promotion
of
like
an
individual
or
things
like
that,
and
that
works
right.
B
You
actually
bring
up
a
good
point.
This
is
like
personalized,
but
I
wanna
like
bring
your
manager
to
these
events.
I
was
just
speaking
to
someone
this
morning
and
they
were
telling
how
their
manager,
mostly
it,
has
like
customer
meetings
and
so
on,
because
that's
really
tighter
their
revenue
and
they're
not
active
in
the
contributor
Summits
or
the
open
source
maintainer
sessions,
but
like
bring
your
manager
here.
So
they
can
actually
see
the
impact
that
you're
creating-
and
here
are
the
shout
outs
and
everything.
A
For
one
minute,
so
we
just
wanted
to
leave
you
with
like
call
it
Commandments
or
the
principles
that
we
have
to
work
together
as
a
product
and
a
project.
So
if
the
product's
goal
should
be
around,
like
you
know,
minimizing
the
internal
patches,
which
basically
means
we
have
to
support
that
by
making
the
Upstream
more
extensible,
the
products
goal
should
be
not
to
replicate
and
create
a
fork,
but
rather
like
build
the
secure
Pipeline
and
the
long-term
support
around
the
product.
Yeah.
A
Yeah
I
want
to
just
touch
on
the
last
one
though
I
think
companies
understand
like
sending
individuals
to
Customer
Events
or
like
company
events.
That's
pretty
much
given,
like
you
know,
they're
growing,
but
it's
also
very
important
to
send
the
people
that
are
working
in
the
project
to
the
community
events.
That's
where
you
build
the
karma
and,
like
you
know,
you.