►
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
Panel: State of the Kubernetes Union - Steering Committee Discussion - Davanum Srinivas, Timothy St. Clair, Jorge Castro, VMware; Paris Pittman, Google; Derek Carr, Christoph Blecker, Red Hat; & Nikhita Raghunath, Loodse Jorge Castro
The steering committee[1] is tasked with decision-making and oversight with all things related to Kubernetes. This panel discussion is a chance for some navel gazing on where we are today, what got us here and where we are headed to next. This will also be a chance for the newly elected steering committee (October `19 election) to meet face to face with their constituents in the community and wider ecosystem. [1] https://github.com/kubernetes/steering
https://sched.co/UadL
A
Hello,
hello,
everyone-
I
am
stephen
augustus,
I'm
gonna
be
the
track
us
for
this
lovely
lovely
panel.
The
steering
committee
so
first
off
we're
under
the
CN
CF
code
of
conduct,
so
just
be
aware
of
that
be
kind
to
everyone
when
you're
asking
questions
and
all
that
good
stuff.
Second,
make
sure
that
you
are
make
sure
that
you
provide
some
feedback
for
this
panel
after
we're
done
on
Skadden
and
let's
get
let's
get
intros
going
so
from
left
to
right.
B
C
D
Hi
everyone
stop
like
her.
I
have
been
around
the
project
like
closing
in
on
four
years
now,
I
started
getting
involved
in
contributor
experience
I'm,
currently,
a
technical
lead
for
the
contributor
experience,
special
interest
group
I
have
just
kind
of
I've
moved
around
and
I've
done
a
lot
of
little
things
and
a
lot
of
different
parts.
F
So
I'm
Nikki
I
have
been
involved
in
the
kubernetes
community
for
a
couple
of
years
now,
so
not
as
much
as
these
folks.
I
am
unser.
Technical
lead
for
a
cig,
contributed
experience
along
with
Christoph
and
I
work
on
github
automation
and
automation
for
a
project
along
with
participating,
many
other
things
and,
of
course,
helping
garden
steering.
H
You
can
see
a
trend,
I
will
say
it's
the
best
group
and
I
must
say:
I
am
so
stoked
to
see
so
many
people
in
these
chairs
right
now
that
are
interested
in
governance
of
this
project.
So
it's
just
a
side.
Note
I
primarily
work
on
it's
like
community
management,
for
instance
chairs
and
how
they
operate.
We
have
95
chairs
within
the
project
who
all
operate.
Different
special
interest
groups
like
Tim
mentioned.
H
I
My
nickname
is
Dimps
longer
D,
you
can
ask
me
later.
I
work
for
VMware
I've
been
doing
open-source
for
a
very
long
time
and
recently,
maybe
around
the
time
Christophe
came.
I
also
joined
at
around
the
same
time
and
I
spend
my
time
in
cross-cutting
SIG's,
like
testing
architecture
releases
and
things
like
that
to
specific
things
if
I
want
to
mention,
one
is
co-chair
and
the
cig
architecture
group
and
running
a
few
sub
projects
there,
so
that
that
is
something
you
know,
I
strongly
believe
in
the
other
one
is.
I
D
Before
that
I
would
be
remissed.
If
we
didn't
also
add
there
is
a
seventh
member
of
our
steering
committee.
Yeah
was
not
able
to
join
us
at
cube
con
today,
Aaron
Creek
and
Berger
he's
a
chair
of
cig
testing
and
the
kubernetes
infrastructure
working
group.
He
currently
works
at
Google
and
he
is
amazing
and
we
miss
him
and
we
wish
he
was
here,
but
the.
B
Co-Chairs
sick
beard
have
you
seen
the
back
alright,
so
the
title
is
a
state
of
the
kubernetes
Union
I
think
we
want
to
get
to
that,
but
we
also
want
to
get
the
audience
and
community
involved.
So
anyone
have
any
burning
questions
to
start
with
and
as
we
go
through
we'll
fill
in
on
the
blanks
about
the
state
of
the
kubernetes
Union.
Anyone
have
any
burning
questions.
J
I
C
Mostly
administrivia
so
like
making
sure
all
the
apples
and
everything
else
were
passed
down.
We
had
zoom
issues
for
the
most
part.
What
I
think
we
already
have
a
backlog?
That's
already
there
so
and
we
all
have
a
very
when
we.
When
everyone
came
on
board,
we
talked
openly
about
existing
issues
and
problems
inside
the
community,
so
I
think
I
think
the
biggest
problem
was
Echols
in
him
in
mr.
bian
yeah.
E
Lot
of
the
hard
work
of
like
taking
a
community
of
this
size
is
to
figure
out
how
to
subdivide
it
and
charter
it
and
empower
others
to
do
good
work
and
we're
just
here
hoping
not
to
screw
it
up.
But
a
lot
of
that
hard
work
was
done
by
the
abit
shop
committee
and
then
some
of
the
inaugural
elected
folks
and
Tim's
and
everyone
else,
who's
come
since.
K
So,
first
of
all,
thanks
a
lot
for
the
great
work
that
you
guys
do.
It's
been
really
impressive
to
watch,
so
my
question
is
around
sessions
and
meetings
to
include
Asia.
Pacific
region
is
very
difficult
at
the
moment
many
sessions
or
like
4
or
5
a.m.
that
kind
of
stuff.
So
any
any
thoughts
or
plans
around
that
aspect.
F
I
So
we
changed
our
time
to
make
sure
that
we
do
for
sure.
We
have
this
ongoing
debate
about
even
simple
things
like
can
all
the
meetings
be
in
UTC,
so
everybody
feels
the
pain
right,
not
just
the
people
in
Asia
back
so
I
had
a
issue
and
I
think
it's
close
by
now,
but
yeah
we've
been
trying
off
and
on
to
do
this
kind
of
stuff
people
aware
of
this,
so
Nikita
runs
some
yeah.
F
So
in
certain
six
we
also
run
a
PAC
friendly
meetings
so
that
other
people
from
a
PAC
can
join
in.
We
are
also
trying
to
move
other
like
normal
non,
a
back
meetings
to
early
Pacific
time
so
that
other
folks
can
join
in
as
well,
and
we're
also
trying
to
kind
of
get
like
have
a
periodic
audit
of
when
we're
having
this
meeting
should
like.
Should
we
move
it
again
and
move
it
to
some
other
time?
So
we
did
that
with
steering.
F
I
We
have
to
lead
the
way
here
so
for
the
everybody
else
to
follow.
So
the
other
thing
that
we
are
doing
here
is
we
are
trying
to
encourage
countries
specific
channels
or
Geo
specific
channels.
Like
we
talked
about
the
New
Zealand
Australia,
we
have
the
India
Channel
and
the
China
channel.
So
if
people
self
organize
on
those
channels
then-
and
they
hit
a
seg,
then
you
can
be
sure
that
this
thing
will
have
a
the.
D
D
There
is
now
a
steering
committee
public
channel
in
the
kubernetes
Lac,
so
that
we
have
more
of
our
communications,
like
even
the
short
brief,
real-time
ones,
where
we're
pinging
each
other
on
a
discussion
topic
if
it
doesn't
need
to
be
done
in
private,
do
it
out
in
public
so
that
folks
are
seeing
seeing
what
we're
doing
seeing
what
we're
talking
about
can
common
if
they
have
something
something
burning
or
if
you
want
to
reach
us.
That
is
also
like
just
another
communication.
Medium
or
mailing
list
is
also
open
to
to
folks.
D
A
F
The
biggest
thing
that
I
have,
on
my
mind
the
sustainability
of
the
project
like
whoever's,
open
to
PR
and
the
coupon
ideas.
People
probably
knows
that
it's
hard
to
get
P
as
reviewed,
sometimes
because
reviewers
are
oversubscribed
and
they
have
a
lot
of
other
things
going
on.
So
we
want
to
make
sure
that
that
doesn't
happen,
that
you
open
a
PR.
You
get
timely
reviews
and
one
of
them,
and
that's
kind
of
one
of
the
things
that
we
want
to
drive.
F
F
We
wanna
increase
that
we
want
to
make
sure
that
we
have
more
automation
around
it.
We
want
to
build
a
tool
which
can
help
find
reviewers
or
such
as
reviewers,
who
are
actively
doing
their
actual
reviewing
so
I
think
there
are
some
things
that
something's
related
to
owners,
files
and
sustainability.
That
just
definitely
on
my
mind,.
H
Gonna
go
a
little
further
into
communication.
I
would
love
to
get
more
people
involved
in
steering
and
what
we
do,
and
also
in
contributor
experience
selfishly
because
contributor
experience
does
a
lot
of
the
governance
operations
work
that
not
many
people
see,
and
that
is
the
administrivia
when
you're
administering,
like
40
zoom
accounts.
All
of
a
sudden,
you
are
now
in
Enterprise,
zoom
Administrator
for
an
open
source
project.
That
kind
of
stuff
isn't
necessarily
sustainable
an
open
source
or
trying
to
figure
out
how
to
make
that
sustainable.
H
With
the
help
of
contributor
experience
but
improving
communications
to
get
people
involved
and
know
the
stuff
that
we're
working
on
and
understand
it
a
little
bit
more
I
think
it's
really
crucial,
I'd
like
to
find
someone
to
eventually
take
my
place
in
steering.
So
that's
something
that
I'm
always
trying
to
look
for
too
and
try
to
grow
our
leaders
to
look
for
as
well
and
do
more
leadership,
trainings
I
think
as
well.
H
We
have
so
many
software
engineers,
for
instance,
and
leadership
roles
they're,
not
necessarily
managers
in
their
day
job,
but
all
of
a
sudden
they're
managing
thousands
of
people
in
open
source.
So
it's
key
that
I
think
we
is
steering
figure
out
training,
opportunities
and
and
things
for
them
to
get
access
to
either
through
ciencia
or
other
ways,
and
we
can
figure
that
out
together.
D
The
only
the
only
thing
that
I
don't
like
to
add
is
we
were
definitely
an
interesting
position
now,
where
the
seven
of
us
that
are
on
are
all
elected
from
the
community.
When
the
bootstrap
committee
wasn't
was
in
place,
there
was
nobody
to
basically
give
them
power.
They
kind
of
just
needed
to
assume
there
were
all
these.
These
very
respected
trusted
leaders
in
our
community,
but
the
power
that
they
had
was
one
that
they
have
assumed
to
just
like.
D
The
position
that
we're
in
now
is
the
seven
of
us
definitely
have
a
mandate
to
carry
carry
that
work
forward,
and
the
community
has
trusted
us
to
kind
of
carry
that
torch
forward
into
the
next.
The
the
years
to
come
so
I'm
also
be
looking
at
things
like
that.
Taking
a
look
at
the
decisions
that
have
been
made
around
sig,
Carter's
governance,
and
now
that
we've
tried
these
things
out
for
a
couple
of
years,
have
another
look
at
them
in
and
see?
Are
they
working
in
the
best
interest?
D
Our
community
are
the
ways
that
we
can
refine
them
to
work
even
better.
Are
there
places
or
blind
spots
that
now
now
that
we've
tried
them
for
two
years
or
the
things
that
are
missing
from
our
sig
charters?
Things
like
that
will
be
definitely
interesting.
Questions
that
we'll
have
to
review
and
look
at
in
the
coming
years.
F
C
Sustainability
and
scalability,
we
have
I,
make
this
joke
all
the
time
in
state
cluster
lifecycle
that
we
we
build.
An
automated
system
to
you
know
automate
away
the
ops
instead
of
most
organizations,
but
we're
actually
really
bad
at
an
organization
at
automating
away
a
lot
of
the
roles
and
responsibilities
we
have,
but
it's
not
just
the
roles
and
responsibilities
inside
of
kubernetes
proper,
but
it's
also
the
code
itself,
the
the
code.
C
When
we
built
kubernetes,
we
built
a
rocket
ship
while
blasting
it
off
at
the
same
time,
and
we
amassed
in
a
tremendous
amount
of
technical
debt
and
it's
not
glorious
for
companies
to
want
to
pay
down
that
debt.
They're,
not
incentivized,
to
do
that.
They're
incentivized
to
make
profit.
So
how
do
you
incentivize
other
organizations
to
want
to
pay
down
this
massive
amount
of
technical
debt
which
is
not
glorious?
It's
a
it's
a
hard
problem
to
solve.
So
sustainability
is
one
word,
but
there
are
many
problems
underneath
that
umbrella
I.
I
Can
talk
about
two
things:
one
is
when
you're
talking
about
the
sustainability
and
scalability
and
then
a
core
organizations
of
project
and
architecture
where
we
try
to
do
more
about
the
structure
of
the
core
itself
repositories
and
things
like
that.
If
you're
anybody
is
interested
in
that,
that
is
one
way
to
get
involved.
The
other
one
is
in
the
cigar
collector.
We
are
starting
a
tech
tech
group
which
will
go
back
in
time
and
try
to
review
some
of
the
things
why
we
did.
I
What
we
did
are
there
any
follow-ups
that
we
are
missing
those
kinds
of
things,
but
then,
on
the
other
aspect,
we
have
to
go
from
West
Coast
9:00
to
5:00
to
all
around
the
world.
That's
something
that
we
need
to
make
sure
that
the
way
we
work
the
way
we
interact
with
each
other.
You
know
changes
from
this
West
Coast
9:00
to
5:00
to
round
the
clock.
I
Otherwise,
it's
gonna
be
really
hard
for
us
to
keep
going
this
forward.
We
have
to
catch
the
long
tail
and
make
sure
that
people
who
work
part
time
who
work
only
when
they
get
some
time
to
work
on
this
are
able
to
contribute
effectively
to
the
project.
Otherwise,
it's
gonna,
be
you
know
harder
on
everybody.
I
think.
E
I
agree
with
both
what
Tim
and
then
said,
I
think
if
I
contrast,
where
I
saw
like
some
of
the
greatest
threats
to
keeping
the
kubernetes
community
alive
in
its
early
days,
I
do
think.
We've
had
some
winds
as
the
project's
matured
that
are
worth
calling
out
like
I,
remember
in
the
early
iterations
of
Corinne
days.
Basically,
everyone
wanted
their
project
in
kubernetes
and
it
was
a
constant
discussion
of
saying.
E
I
want
to
give
a
call
out
to
is
that
we've
made
it
possible
for
so
many
people
to
extend
and
build
around
kubernetes
that
they
don't
need
to
do
it
directly
in
kubernetes
and
to
me,
that's
like
the
biggest
sustainability
win
for
maintainer
x',
because
it
gives
them
time
to
go
focus
on
what
they
have
to
refine
and
refactor
and
improve,
but
allows
the
broader
ecosystem
around
communities
to
flourish
like
just
walking
around
the
sponsor
lab.
Here
it's
mind,
boggling
and
I.
M
I
C
I
It's
awesome
that
we
enable
that
to
happen,
and
it
is
all
big
reflecting
on
the
work
that
we
have
done
here,
that
they
are
able
to
I
trait
and
they
are
able
to
make
sure
that
they
can
cater
to
their
own
customers
and
I.
Think
it
is
a
really
good
thing.
I
I
hope.
More
of
you
end
up
doing
bigger
projects
similar
to
that
as
well.
I
guess.
E
In
the
I
forget
how
many
years
ago,
I
feel
like
I
feel
like
the
COO
Bernays
architecture
is
intentionally
distributed
to
decompose
that
if
a
component
isn't
working
for
somebody,
then
you
should
be
empowered
to
go
and
replace
it
to
meet
your
need
right,
so
that
the
schedule
is
a
great
example
of
like
an
area
of
people
had
particular
scheduling
needs.
Then
you
should
go
really
read
new
scheduler.
E
What's
important
is
just
that
we
have
clear
API
contracts,
thinking
about
like
in
the
signal
community
there's
CNCs
projects
around
like
the
virtual
cubelet
and
like
as
long
as
you
can
present
and
support
the
interface
I.
Don't
think
it's
a
bad
thing
for
people
to
innovate
and
I
wouldn't
want
to
discourage
anyone
from
innovating
and
so
well.
E
K3S
might
be
a
project
that
is
going
out
at
the
same
time
like
the
virtual
cubelet
was
being
discussed
here
and
people
are
offering
that
and
as
someone
in
the
Signet
community
I
think
you
know
it's
interesting
like
you
only
get
better
by
seeing
innovation
around
you
and
understanding
what
people
want
to
do
differently.
Otherwise
you
might
be
too
rigid
in
your
thinking.
So.
I
And
you,
as
a
user
you
can
choose
to,
would
you
can
say
that?
Okay,
these
are.
These
are
the
aspects
that
is
important
to
me.
I!
Don't
care
about
these
other
specs
of
cuban
artists.
You
know
you
pick
and
choose
as
well
at
some
point,
so
virtual
cubelet,
you
have
to
make
a
decision
saying:
okay,
I
don't
care
about
some
features
that
don't
work
in
which
will
give
that
right.
That
would
be
how
you
would
work
for
something
or
against
something.
I.
D
Would
add
like
based
off
of
Derek's
the
answered
Eric's
answer
to
the
previous
question?
We
have
designed
a
product
that
is
is
very
extensible
and
there
was
a
lot
of
discussions
around.
What
would
be
part
of
kubernetes
will
be
outside
kubernetes.
The
fact
is,
a
healthy
ecosystem
around
kubernetes
benefits
us
as
a
project,
and
it
benefits
everyone
as
a
user.
So
if
folks
are
looking
at
a
technology
like
kubernetes
and
saying
like
okay,
I
can
I
like
these
parts
of
kubernetes,
but
I.
Think
I
could
do
these
ones
better.
E
I
mean
some
of
it
mean
this
is
a
governance
project
discussion
but
like
there
is
work
that
we
have
to
do
as
community
make
communities
awesome
at
the
edge
and
like
someone
in
the
the
signo
community,
like
disconnected
workers
or
workers
that
lose
connectivity
and
be
able
to
do
what
they
need
to
do
when
you
power
cycle
like
these
are
very
real
world
problems
and
I.
Think
it's
amazing
that
folks
in
any
ecosystem
are
innovating
and
exploring,
and
then
we
see
what
works
or
doesn't
work,
and
maybe
some
of
it
comes
into
the
core
project.
I
Is
doing
is
directly,
you
know
he
benefits
directly
from
the
work
that
we
do
right
to
been
added,
provide
a
less
support
for
make
files,
and
you
know
they
greatly
benefited
from
that.
We
added
support
for
big,
manifests
for
multiple
containers
and
running
the
conformance
tests
and
they
benefited
from
that.
B
More
questions,
I
have
one
you've
mentioned
charters
and
sixth
and
stuff.
Can
you
give
us
a
just
a
quick
summary
I
know
getting
sick
charters
in
was
a
long-term
project.
That's
finally,
coming
to
completion.
Can
you
kind
of
catch
up
the
community
on
your
responsibilities
there,
specifically,
what
steering
doesn't
do
so.
C
I
L
C
That
is
a
very
tough
question.
I,
don't
exactly
know
how
we
answer
it,
but
it
is
real.
It's
totally
real
and
you
see
that
like
if
anybody
submits
a
PR
that
touches
an
API
in
any
way,
shape
or
form,
you
need
to
get
approval
across
the
board
with
all
the
SIG's,
and
it
is
a
painful
process
you
need
to
plan
for
it.
You
need
to
manage
it.
You
need
to
figure
out
all
the
details
that
go
along
with
it.
C
That's
a
concrete
example
of
how
how
we've
created
an
organizational
structure
that
imposes
restrictions
on
the
community.
It's
a
good
question.
I
think
I'd
want
to
ruminate
it
I,
don't
think
I
have
a
hot,
take
right
away,
but
I
deal
with
this
internally
in
organizations
all
the
time,
but
I
haven't
really
given
it
that
that
much
thought
in
the
community,
but
that's
a
good
one.
It's.
E
If
you
look
at
the
technical
output
of
the
project
right
as
a
user,
it's
largely
the
API
and
I
think
it's
appropriate
that
the
bar
to
change
the
kubernetes
api
is
very
high.
I
think
those
that
have
been
with
the
community
as
long
as
they
have
and
can
bring
their
expertise
like.
We
really
lean
on
that
expertise
to
know
with
their
history
with
the
project
and
what
they
they
understand
about
all
the
subsystems
that
we
don't
mess
it
up,
because
you
know
having
having
been
on
this
project
now
for
like
six
years.
E
Think
the
broader
ecosystem
of
projects
that
can
go
and
build
around
cube-like
I'd,
encourage
them
to
innovate
and
fail
and
innovate
again
and
hopefully
be
successful
but
like
where
we
are
in
the
project's
lifecycle.
We're
in
my
view,
later
in
the
maturity
curve
or
due
diligence.
Responsibility
is
like
super
important,
say.
I
H
Was
just
gonna
say
saying,
though,
is
important,
I
think
at
this
stage
and
also
I
guess
saying
no
with
documentation
as
to
why
to
makes
things
a
little
easier,
I've
seen
a
lot
of
what
could
have
been
hairy
situations
get
you
know,
ironed
out
through
people
looking
at
art
and
sharing
best
practices
and
context
and
previous
things
that
people
have
tried,
and
things
like
that.
So
you
know.
I
So
I
would
like
to
use
this
as
a
shout-out
to
say:
don't
get
involved
deep
into
just
one
sake.
Go
across
six
because
there's
only
a
few
of
us
who,
like
spread
across
multiple
SIG's,
so
it's
harder.
So
please,
you
know,
consider
spending
time
in
other
SIG's
as
well.
Not
just
you
know
deep
into
like
sick
storage.
I
can
even
though
I
work
on
other
things,
I
still
feel
that
I'm
part
of
sig.
Note
I,
don't
know
if
you
agree.
L
Okay,
so
some
of
you
guys
on
the
panel
working
for
companies
that
add,
like
enterprise
features
on
top
of
the
open-source
kubernetes.
So
how
was
sick
members?
Do
you?
You
manage
those
those
requirements?
Those
companies
probably
don't
want
some
of
those
features
making
it
back
into
the
open-source
project.
How
do
you
keep
that
side,
sort
of
open
and
honest.
C
Joey
used
to
have
a
statement
where
you
say
you
wear
your
agenda
on
your
sleeve
right
and
it's
got
a
it's
got
a
test.
It's
got
a
pass.
The
sniff
test
with
inside
of
the
the
cigs
in
the
organization
to
get
your
agenda
to
come
to
fruition
right
because
and
they're
also
Tim
had
another
statement
where
they're
at
the
during
his
keynote,
where
community
comes
before
your
individual
company
right.
C
So
if
you
keep
those
values
in
place,
if
you
keep
those
values,
sustainable
and
shout
out
to
Sarah,
for
keeping
us
honest
with
the
values
that
you
you
have
a
means
by
which
or
a
rubric
by
which
you
evaluate
criteria
for
feature
enhancement
or
what
changes
you
want
to
make
and
I
think
that's
what
keeps
our
community
really
interesting
and
honest
with
each
other
is
that
we
have
a
core
set
of
values
and
we
it
allows
us
to
evaluate
it
in
a
vendor-neutral,
community-based
fashion.
We're.
D
N
H
N
C
This
is
another
aspect,
not
every
cig
is
the
same.
We
have
in
sequester
lifecycle.
We
saw
this
a
lot.
There
was
a
lot
of
individual
contributors
because
a
lot
of
people
had
their
own
provisioning
tools.
They
were,
they
were
producer
consumers,
so
we
developed
a
process
model
by
which
you
vote
with
your
feet.
If
you
are
there
to
show
up
to
do
the
work
and
we
will
reprioritize
things
according
to
not
only
bandwidth,
but
people
that
are
gonna
show
up
to
do
the
work.
So
every
cycle
and
the
beginning
of
this
cycle
we
do.
C
We
do
a
planning
session
right
and
I
might
say,
deem
something
is
p0
or
high
priority
item
and
we
might
have
people
to
work
on
it.
But
if
other
people
come
to
the
group-
and
they
say
no-
we
are
going
to.
We
have
this
other
thing
that
we
care
a
lot
about,
and
we
are
gonna
put
more
people
on
it
in
the
community.
Then
the
answer
is,
you
are
now
the
highest
priority
thing,
so
we
do
this
through
a
transparent
planning
cycle
inside
of
our
sake,
I
think.
E
It's
a
good
question
and
you
can
look
at
it
from
two
perspectives.
One
sometimes
and-
and
really
this
is
a
responsibility,
as
Tim
said
like
to
delegate
out
to
the
sig,
because
ultimately,
that
sig
is
who's,
maintaining
it
and
then
once
code
comes
in
there,
it's
like
an
expectation
that
you
will
patch
it.
E
You
will
support
it
like
if
it
has
a
CV,
you
will
fix
it
and
so
like
as
a
new
contributor
coming
often
times,
you'll
see
folks
who
are
in
the
ecosystem
that
do
want
to
get
their
feature
in
and
their
first
contribution
of
the
project
is,
is
aspiring
to
be
something
really
big
and
grand
and
many
times
those
ideas
are
great
and
they're
awesome.
But
then
there
is
a
natural
concern,
I
think
at
any
open
source
community
Brown.
E
Will
you
be
there
to
maintain
it
once
comes
in
and
I
think
it's
healthy
to
push
back
on
that?
What
I
think
you
ultimately
want
to
do
to
fix?
It
is
just
use
those
opportunities
to
ask.
Is
there
a
missing
point
of
extension
to
empower
you
to
do
what
you
wanted
to
do,
or
are
so
many
components
so
tightly
knitted
together
that
you
can't
just
swap
out
and
replace
something
that
you
want
to
do
like?
E
There's
a
lot
of
things
in
the
project
that
are
plugable
like
you're
kms
provider,
I
just
talked
about
really
really
the
cue
book
could
be
swapped
out
container,
runtimes,
so
I
think
as
a
community
like
warehouse,
friction
points
have
come
up.
We
have
fixed
sure
that
there's
points
of
variability
or
points
of
extension,
yeah.
K
D
Would
also
add
like
beyond,
beyond
software
engineers,
we
have
other
sustainability
issues
that
we
don't
necessarily
have
a
clear
answer
for
yet
in
our
project.
Well,
we
might
have
plenty
of
software
engineers
who
are
paid
to
do
features.
You
know,
even
if
it
is
a
25%,
we
still
have
lots
of
other
roles
within
our
community,
like
Community
Managers,
like
build
really
build
test
engineers
like
in
other
types
of
roles,
that
we
don't
necessarily
a
clear
answer
for
okay.