►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Evaluating Business Risk for Open Source Cloud Native Projects - Dawn Foster, VMware
Most business decisions boil down to an assessment of risk and making tradeoffs. We should all be thinking about risks relative to how we’re using cloud native open source projects within our business. If we build our business on top of an open source technology, we want it to be as low of a risk as possible. This talk will: * Compare the risk between projects under neutral foundations vs. those owned by individual companies. * Provide details about how governance impacts risk relative to leadership selection, decision-making processes, and communication. * Evaluate business risk in terms of contributors and organizations to determine the level of risk associated with individuals or organizations leaving the project. * Look at how security and release processes can impact risk. The audience will walk away with practical advice about how to assess risk and evaluate projects for your organization while also learning about ways to decrease risk in your own projects.
A
But
first
I'll
tell
you
just
a
bit
about
me.
I've
been
in
the
technology
industry
for
over
20
years,
working
mostly
on
open
source
projects
from
within
companies
like
puppet
and
intel
at
pivotal.
I
was
responsible
for
driving
pivotal's
kubernetes
contribution
strategy
and
I
was
actively
contributing
to
the
kubernetes
contributor
experience
special
interest
group
now,
I'm
working
in
vmware's,
open
source
program
office
and
I'm
responsible
for
our
open
source
community
strategy.
A
So
lately
I've
been
active
in
the
cncf
contributor
strategy
sig
in
particular
the
governance
working
group,
I'm
also
on
the
steering
committee
for
the
linux
foundation's
to-do
group,
where
companies
collaborate
on
ways
to
run
successful,
open
source
program
offices,
I'm
also
a
board
member
of
open
uk,
which
is
focused
on
developing
and
sustaining
leadership
and
open
technology.
Here
within
the
united
kingdom,
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.
A
Unfortunately,
the
scenario
on
the
slide
is
probably
more
common
than
many
people
realize.
One
of
the
biggest
examples
of
this
was
a
couple
of
years
ago,
when
it
was
discovered
that
openssl
had
a
security
bug
in
their
cryptography
library
referred
to
as
heartbleed
openssl
is
the
technology
that
almost
every
company
in
the
world
uses
in
one
way
or
another,
and
it
was
during
this
crisis
that
most
of
us
learned
that
openssl
received
about
two
thousand
dollars
in
donations
per
year
and
was
maintained
mostly
by
a
single
person.
A
A
While
this
situation
was
resolved
relatively
quickly,
we
might
not
be
so
lucky
in
other
cases,
so
evaluating
risk
is
important
because
it
can
disrupt
your
business.
It's
also
important
to
think
about
risk
as
being
on
a
continuum
like
with
most
things
in
life.
There
are
no
sure
bets
and
no
project
or
technology
is
completely
without
risk.
A
In
this
talk,
I
wanted
to
start
by
talking
about
why
it
is
so
important
to
think
about
who
owns
or
controls
an
open
source
project,
because
it's
something
that
many
of
us
don't
spend
as
much
time
thinking
about
as
we
should.
The
project's
governance
documents
can
help.
You
learn
more
about
the
ownership
control
of
a
project
and
from
a
risk
perspective,
you
should
be
looking
for
projects
with
neutral
governance,
where
decisions
are
made
by
people
from
a
variety
of
different
companies.
A
A
In
the
case
of
mongodb,
they
created
a
new
license
called
the
server-side
public
license.
They
would
be
used
for
mongodb,
but
would
also
be
used
for
security
patches
for
previous
open
source
versions
of
the
software,
to
prevent
people
from
just
continuing
to
use
an
older,
open
source
version
and
applying
the
security
patches
to
it.
A
It's
important
to
note
that,
while
they
say
that
the
sspl
is
based
on
an
osi
approved
license,
they
were
not
able
to
actually
get
the
sspl
approved
by
the
osi,
primarily
because
of
some
concerns
about
the
restrictions
put
on
how
people
use
the
software.
So
the
ssbl
is
not
an
osi
approved,
open
source
license.
A
This
means
that
by
most
definitions,
mongodb,
elasticsearch
and
kibana
are
no
longer
open
source
projects.
Situations
like
this
one
increase
your
business
risk
and
can
impact
your
ability
to
deliver
software
license.
Changes
require
time
from
lawyers
to
help
us
interpret
these
new
licenses
and
new
restrictions
on
how
we
use
an
open
source
project
could
delay
our
product
delivery
and
decrease
our
productivity.
A
Governance
issues
caused
by
corporate
ownership
of
open
source
projects
can
undermine
the
project's
success
and
lead
to
disruptions
within
the
project.
In
some
cases,
these
disruptions
make
it
difficult
to
make
progress
on
a
project,
but
they
can
also
result
in
the
project
working
and
becoming
two
completely
separate
projects.
A
A
So
here
are
a
couple
more
tangible
examples.
My
sequel
was
forked
into
what
became
mariadb
when
oracle
acquired
sun.
Many
of
the
original
mysql
core
developers,
including
the
creator
monty,
didn't
think
that
oracle
would
be
a
good
owner
of
my
sequel
and
they
wanted
to
ensure
that
the
code
base
would
remain
open
in
a
similar
fashion.
Shortly
after
the
same
acquisition,
libra
office
was
forked
from
open
office
and
less
than
a
year
later,
the
developers
who
are
being
paid
to
work
on
openoffice
were
laid
off
and
open
office
was
donated
to
the
apache
software
foundation.
A
A
Later
google
decided
that
they
were
not
going
to
transfer
them
to
cncs
and
because
they
owned
the
trademarks.
The
rest
of
us
had
no
real
choice
in
the
matter.
In
both
of
these
cases,
the
communities
have
been
able
to
negotiate
for
better
governance,
which
has
helped
stabilize
the
projects,
but
I
still
think
these
projects
are
at
risk
of
eventually
being
replaced
by
other
technologies
or
eventually
forked,
if
they're
not
put
under
a
more
neutral,
neutral
foundation
or
neutral
governance.
A
One
way
we
can
avoid
situations
like
the
ones
I
just
talked
about
on
the
last
two
slides
is
by
supporting
projects
that
are
under
neutral
foundations
like
the
cncf
whenever
possible,
however,
it
isn't
always
clear
whether
a
foundation
is
neutral
or
not
if
the
board
of
directors
or
other
leadership
bodies
are
made
up
of
people
who
work
at
a
wide
range
of
companies,
especially
competing
companies.
That's
a
good
indication
that
it's
a
neutral
foundation.
A
Trademarks
are
another
thing
to
look
at
in
a
neutral
foundation.
The
foundation
should
own
the
trademarks
associated
with
especially
the
name
of
the
foundation,
but
probably
also
most
of
the
projects
if
the
trademarks
are
all
owned
by
a
company,
especially
a
single
company
across
most
of
the
projects,
that's
a
red
flag
that
the
foundation
is
probably
not
actually
neutral.
A
A
A
Think
back
to
the
examples
from
earlier
where
projects
moved
to
non-open
source
licenses
or
were
forked
for
company
originated
projects.
Consider
the
reputation
of
that
company
as
a
steward
of
open
source
projects,
but
always
keep
in
mind
that
they
can
change
their
strategy
at
some
later
date.
I'm
not
saying
that
you
shouldn't
participate
in
open
source
projects
owned
by
companies,
but
you
should
think
about
the
risks
that
you're
taking
in
some
cases.
A
Governance
can
be
found
in
all
open
source
projects
in
one
form
or
another,
to
specify
the
processes
for
how
people
work
together
within
the
project.
Ideally,
it
will
be,
it
will
be
clearly
documented,
but
for
some
projects,
especially
smaller
ones,
it
might
be
a
bit
more
ad
hoc
and
informal,
regardless
of
what
form
it
takes
evaluating
projects.
Governance
is
an
important
element
of
assessing
the
risk
of
using
or
contributing
to
that
project.
A
A
project
with
only
a
few
people
won't
need
elaborate
elections
to
select
leaders,
but
the
project
should
have
at
least
a
few
basic
roles
to
find
like
maintainer,
for
example,
for
cncf
projects.
Governance
documentation
is
encouraged
for
all
projects,
but
by
the
time
a
project
hits
the
incubating
stage.
A
The
overall
cloud
native
ecosystem
is
complex,
with
many
different
projects
containing
overlapping
functionality.
A
charter,
especially
a
scope,
can
help
end
users
understand
how
your
project
fits
into
the
overall
ecosystem
and
what
functionality
it
does
and
does
not
offer
as
compared
to
the
many
alternatives
having
this
documented
early
can
help
avoid
issues
and
misunderstandings
later.
A
One
way
to
help
mitigate
this
risk
is
to
have
some
discussions
about
governance
within
the
community
to
gauge
interest
in
getting
some
help
with
governance
in
a
lot
of
communities.
There
can
be
various
types
of
informal
governance
that
just
isn't
documented.
Quite
a
few
people
tend
to
avoid
working
on
governance.
A
Because
leadership
is
such
a
critical
piece
of
governance,
I
wanted
to
spend
a
little
more
time
talking
specifically
about
it
at
a
minimum.
There
should
be
some
kind
of
documentation
about
leadership
within
the
project
for
small
projects.
Maybe
it's
just
a
list
of
maintainers
in
a
readme
file,
or
maybe
owners
or
maintainers
files
that
indicate
which
people
are
responsible
for
the
various
aspects
or
areas
within
the
project
for
bigger
projects.
You'll
want
to
see
more
details
about
the
specific
roles
and
responsibilities
for
different
leadership
positions,
along
with
how
others
can
move
into
leadership
roles.
A
If
you
become
an
active
participant
in
a
project,
you'll
want
to
understand
how
your
contributors
can
move
into
leadership
roles
having
employees
in
leadership
roles
helps
reduce
your
risks
as
a
company,
since
these
employees
will
be
in
a
position
to
understand
more
about
how
the
project
actually
works
and
be
able
to
help
mentor.
Other
employees
then
bring
them
into
the
project.
A
This
should
be
documented
so
that
all
participants
can
clearly
understand
the
criteria
and
process
for
moving
both
into
and
then
out
of
leadership
positions.
Most
of
the
bigger
projects
like
kubernetes
have
an
election
process,
at
least
for
the
the
top
levels
of
leadership.
Like
a
steering
committee,
you
should
also
look
for
programs
that
give
people
opportunities
for
shadowing
mentoring
and
sponsoring
new
potential
leaders,
which
shows
that
the
project
is
serious
about
growing
a
diverse
set
of
people
into
new
leadership
roles
within
the
project.
A
The
key
is
that
having
a
fair
and
transparent
process
for
selecting
leaders
like
elections,
for
example,
reduces
your
risk
of
participating,
since
your
contributors
can
participate
in
the
elections
and
have
a
say
in
the
governance
of
the
project.
Higher
risk
options
would
include
organizational
leadership
seats
where
a
certain
number
of
positions
are
allocated
to
specific
companies
where
those
companies
get
to
decide
who
gets
their
leadership
positions
and
there's
no
easy
way
for
new
leaders
who
work
outside
of
those
companies
to
move
into
those
leadership
positions.
A
A
A
One
thing
that
can
reduce
the
risk
of
embracing
an
open
source
project
is
if
the
project
is
adopted
by
a
bunch
of
other
people,
since
active
projects
with
plenty
of
users
are
less
likely
to
be
abandoned.
It
isn't
always
easy
to
know
who
uses
a
project,
but
an
adopters
file
is
a
good
start.
If
the
project
has
one,
an
adopter's
file
is
actually
required
for
cncf
projects
to
reach
the
incubated
stage,
although
it
may
not
be
public
until
the
project
is
graduated,
other
projects
might
choose
to
have
this
earlier
and
for
cncf
projects.
A
People
often
worry
about
security
for
open
source
projects
under
the
premise
that
if
everyone
can
see
the
code,
they
might
also
be
able
to
find
and
exploit
security
vulnerabilities.
But
the
flip
side
to
this
is
that
there
are
also
more
people
who
can
view
the
source
code
for
the
purpose
of
fixing
those
security
issues.
A
This
is
where
innovation
and
diversity
of
ideas
comes
in
so
within
a
product
team
working
internally
on
a
project
at
your
company,
you'll
have
a
limited
number
of
people
assigned
to
the
product
and
an
increased
chance
that
your
shared
backgrounds
lead
you
to
think
of
things
in
similar
ways
with
people
from
many
different
companies
and
different
backgrounds,
contributing
to
an
open
source
project.
These
innovative
ideas
will
also
apply
to
proactively
making
the
project
more
secure
along
with
then,
of
course,
reactively
fixing
any
vulnerabilities
that
might
arise
later.
A
A
There
are
a
few
documents,
even
a
small
one
or
few
documents
that
every
project,
even
the
small
ones,
should
have.
It
should
go
without
saying
that
open
source
projects
need
appropriate
licensing,
documentation
and
some
licenses
require
things
like
notices,
file
or
notices
files
or
license
headers
within
each
source
file.
In
addition
to
just
putting
a
license,
file
in
the
repository
projects
should
also
have
a
code
of
conduct
that
people
can
easily
find
with
details
about
how
to
report
incidents,
along
with
the
consequences
of
violating
that
code
of
conduct.
A
A
If
everyone
understands
how
people
within
the
project
communicate
with
each
other,
it
avoids
frustrating
experiences
for
both
new
and
existing
contributors.
One
way
to
mitigate
these
risks
is
to
volunteer
to
help
some
of
this
documentation
and
established
projects.
Long-Term
contributors
may
not
notice
that
their
contribution
documents
are
incomplete
or
even
incorrect,
and
someone
new
to
the
project
can
often
be
a
big
help
in
finding
the
problems
that
are
needed
to
improve
that
documentation
and
the
better.
A
The
community
is
usually
the
first
thing
I
look
at
when
deciding
if
a
project
is
healthy,
is
the
community
actively
engaged
in
productive
discussions
around
the
project?
Are
they
helpful
when
people
have
questions
or
problems?
Are
they
welcoming
for
new
contributors
and
new
users?
Do
they
treat
each
other
with
kindness
and
with
respect?
A
A
You'll
want
to
look
carefully
at
how
people
treat
each
other
on
the
mailing
lists
and
in
github
reviews
and
slack
and
irc,
and
all
of
the
other
communication
channels.
Projects
with
a
culture
of
treating
each
other
with
respect
and
kindness
are
going
to
be
a
lower
risk
because
your
employees
will
want
to
continue
to
contribute.
A
On
the
other
hand,
projects
with
toxic
cultures,
put
your
employees
and
other
contributors
at
risk.
There
could
be
real
mental
and
physical
health
risks
for
your
employees,
and
these
toxic
environments
can
impact
retention,
since
employees
might
be
so
eager
to
leave
the
project
that
they'll
look
for
another
employer
where
they
won't
have
to
work
in
this
toxic
community,
and
if
the
culture
is
too
toxic,
it
can
be
very
difficult
or
possibly
even
impossible
to
mitigate
that
risk,
and
if
the
community
isn't
amazing
for
a
variety
of
reasons,
this
this
is
a
risk.
A
It
doesn't
necessarily
mean
that
you
shouldn't
get
involved
or
use
the
software,
but
you
should
approach
it
with
caution
and
understand
that
there
is
a
risk
that
things
could
go
terribly
wrong
with
the
project
as
a
whole.
If
things
get
even
worse
within
the
community
and
your
key
contributors
just
start
disappearing
out
of
the
project.
A
A
Seeing
large
numbers
of
issues
and
pull
requests
on
a
project
is
a
red
flag
for
me,
because
it
can
indicate
that
either
they
don't
have
enough
contributors
to
handle
the
incoming
contributions
or
worse,
that
they
don't
actually
care
about
or
want
contributions
from
others,
which
is
something
you
see
in
some
company
and
open
source
projects.
Now
out
of
these
two
scenarios,
not
having
enough
contributors
to
respond
to
pull
requests
and
issues
is
probably
more
common
and
most
projects.
I've
worked
on
have
struggled
at
one
point
or
another,
with
keeping
up
with
full
requests.
A
A
This
is
a
bigger
risk
for
projects
that
are
highly
complex
or
contain
technologies
that
require
specialized
expertise
like
we
saw
a
few
years
ago
with
the
openssl
heartblade
example,
you
should
also
look
at
organizational
diversity
as
a
part
of
the
health
and
risk
for
open
source
projects
if
all
or
most
of
the
contributors
are
from
a
single
company.
What
happens
when
that
company
has
a
shift
in
strategy
or
gets
acquired
or
runs
out
of
money
and
just
goes
out
of
business?
A
Now,
before
I
wrap
up
the
talk,
let
me
leave
you
with
a
few
resources
that
you
might
find
useful.
The
cncf
contributor
strategy,
sig
has
a
governance
working
group
and
a
contributor
growth
working
group
which
provide
guidance
about
contributor
experience,
sustainability,
governance
and
openness
to
help
cncf
projects
develop
strategies
for
maintaining
project
health.
The
to
do
group
has
a
bunch
of
guides
that
have
great
info
on
all
aspects
of
creating
and
managing
open
source
projects.