►
Description
Collaboration in open source projects is important for companies, and it requires leadership that takes a strategic approach to sustaining contributions over time. An open source strategy that aligns with your company’s overall goals allows you to maintain the long-term commitment needed to sustain your contributions while building trust and influence in the open source projects that are strategic for your organization. This strategy should include aligning the needs of the company with important open source projects. If the needs of the company and the community are not aligned, this can create unhealthy dynamics that damage your company’s reputation and brand in addition to decreasing job satisfaction for employees. This talk will focus on ways to create this alignment and help all of us be successful together. The talk contains three major sections: 1) Dynamics of collaboration in open source projects between individuals, companies, and communities. 2) How your open source strategy can help you participate in ways that will benefit your company, your employees, and the community. 3) Tips for sustaining long-term, strategic participation in open source projects.
A
Fantastic
sponsors,
so
here
we
are
our
closing
Keynotes
of
the
day.
I
really
appreciate
everybody
being
here
and
I
would
like
you
all
to
please
put
your
hands
together
and
give
a
very,
very
warm
welcome
to
Dawn
Foster
Dr
Dawn
Foster,
who
will
be
the
first
of
our
two
closing
Keynotes
for
today.
Please
welcome
Don.
B
Okay,
thank
you
all
for
for
saying.
I
know
that
Cheryl
and
I
are
between
you
and
drinks,
so
I'll
just
keep
this
moving.
My
talk
today
has
three
sections.
So
I'll
start
by
talking
about
the
Dynamics
of
collaboration
within
open
source
projects
between
individuals,
companies
and
communities
before
moving
on
to
talk
about
contribution,
strategies
and
plans,
and
then
in
the
last
section,
we'll
have
some
tips
for
sustaining
your
contributions
over
the
long
term
and
then
we'll
wrap
it
up
with
links
to
resources
and
then
a
few
final
thoughts.
B
I'll
start
by
telling
you
just
a
little
bit
about
me,
I've,
been
in
the
technology
industry
for
well
over
20
years,
working
mostly
on
open
source
projects
from
within
companies
like
Intel
puppet
and
now
at
VMware,
I'm
responsible
for
our
open
source,
Community
strategy
within
the
open
source
program
office,
I'm,
a
board
member
of
open
UK
I'm,
a
governing
board
member
and
maintainer
for
the
Linux
foundation's
chaos.
Metrics
project
I'm,
co-chair
of
the
cncf
contributor
strategy,
technical
Advisory,
Group
and
I
have
a
PhD
where
I
researched
how
people
work
together
within
the
Linux
kernel.
B
While
there
are
some
exceptions,
contributions
to
most
open
source
projects
are
centered
around
the
individual
right.
Contributions
come
from
individuals,
not
companies
when
someone
submits
a
pull
request
to
fix
a
bug,
add
a
feature,
maybe
update
some
documentation
in
an
open
source
project.
Those
changes
come
from
an
individual
and
you
know
commits
include
a
name
and
an
email
address,
but
in
a
lot
of
cases,
unless
the
person
uses
their
Corporate
email
address,
you
really
can't
even
tell
where
that
person
works,
to
make
this
even
more
complicated
for
companies
in
most
open
source
projects.
B
B
Now,
in
most
projects,
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
pretty
common
right
at
VMware.
We
have
loads
of
people
working
full-time
on
open
source
projects
like
spring
rapidmq
kubernetes,
and
if
you
aren't
sure
how
to
contribute
as
a
company,
you
might
be
able
to
hire
an
existing
contributor
or
possible
whoops,
sorry,
possibly
even
a
maintainer,
to
sorry
this
isn't
my
computer
and
things
aren't
working
quite
as
expected.
B
So
an
approach
that
maybe
dictates
a
specific
solution
might
not
be
accepted
by
a
project,
so
your
strategies
really
need
to
include
flexible
ways
of
approaching
resolving
issues
or
creating
new
features
so
that
you
can
find
ways
to
work
jointly
with
the
community
to
find
solutions
that
work
for
everybody
now
part
of
the
role
of
an
open
source
program
office.
If
you
happen
to
have
one
can
be
to
help
everyone
navigate
balancing
these
individual
company
and
Community
needs.
B
The
various
groups
within
your
organization
really
need
to
understand
that
individuals
need
to
be
able
to
collaborate
and
build
consensus
within
the
community
to
come
up
with
innovative
solutions
for
anything
that
your
company
needs.
Trying
to
force
something
into
an
open
source
project
can
impact
employee
satisfaction
and
retention
for
the
individuals
who
are
contributing
since
the
employee.
B
If
you
put
that
situation
in
an
employee
where
an
employee
can't
meet
the
needs
of
the
community
without
jeopardizing
their
employment,
this
just
isn't
a
good
situation
for
anyone
to
be
in
and
I've
been
in,
that
situation
it
sucks,
and
but
by
taking
this
Dynamic
into
account
when
building
your
open
source
strategies
and
best
practices,
you
can
help.
Managers
and
leaders
within
your
organization
understand
this
Dynamic
so
that
your
employees
can
meet
your
organization's
objectives,
while
also
being
good
corporate
citizens
within
the
community.
B
These,
the
individuals
and
companies
that
we
just
talked
about
they
spend
months
and
years,
building
trust
and
reputations
within
specific,
open
source
communities,
and
all
of
that
hard
work
is
for
nothing
if
those
people
keep
getting
pulled
off
of
the
open
source
projects
to
work
on
other
things.
So
in
this
section,
I'll
talk
about
how
to
build
strategies
and
plans
that
support
your
business
goals
so
that
you
can
justify
continuing
to
work
on
this
over
the
long
term.
B
But
on
the
other
hand,
when
your
goals
are
not
clearly
aligned
with
the
overall
strategy,
people
will
look
at
that
open
source
participation
as
something
that
can
be
cut
entirely
or
just
starved
of
resources
until
it
goes
away
on
its
own,
and
this
will
also
help
you
make
the
case
to
Senior
Management
and
Company
Executives,
who
aren't
involved
in
any
of
the
low-level
details
explaining
how
your
open
source
contributions
support.
The
goals
of
the
company
can
help
the
executive
team
understand
the
Strategic
importance
of
this
work.
B
Now
most
of
our
organizations
use
so
many
open
source
projects
that
it's
really
easy
to
get
distracted
and
not
know
where
to
focus.
It
can
help
to
think
about
which
open
source
projects
are
strategic
in
some
way
for
your
company.
Maybe
there
are
some
projects
that
your
operations
team
uses
to
run
some
of
your
critical
business
infrastructure,
or
maybe
there
are
some
development
and
deployment
tools
that
impact
your
ability
to
release
the
products
that
generate
revenue
for
your
organization.
B
Obligatory
XKCD
comic,
it's
important
to
think
about
risk
as
part
of
your
company
and
product
strategies.
Evaluating
risk
is
important
because
your
business
could
be
disrupted
in
ways
that
impact
your
employees,
your
customers,
even
the
broader
ecosystem.
It's
also
important
to
think
about
risk
as
being
on
a
Continuum
so
like
with
most
things
in
life
there.
There
are
no
sure
bets
right,
there's
no
project
or
technology,
that's
completely
without
risk.
B
There
are
only
projects
with
more
or
less
risk
across
a
variety
of
categories,
and
whether
you
accept
that
risk
is
a
business
decision
and
a
strategic
decision
that
should
also
take
how
you're
using
the
project
into
account.
We
don't
want
to
build
a
key
product
on
top
of
some
really
risky
open
source
technology
right.
So
it's
important
to
think
about
what
elements
of
an
open
source
project
might
introduce
risk
for
us
and
how
we
can
watch
out
for
warning
signs
and
mitigate
potential
risks.
B
But
this
is
bigger
than
just
thinking
about
individual
projects
right.
It's
absolutely
critical
for
all
of
us
to
be
thinking
about
security
and
risk
holistically
across
our
entire
software
supply
chain,
including
every
little
package
that
goes
into
our
products.
Our
infrastructure,
potential,
vulnerability
or
malicious
attack
can
be
in
any
Link
in
the
chain
where
it
can
go
unnoticed.
B
Most
of
us
have
some
combination
of
projects
that
we've
open
sourced
within
our
company
and
other
open
source
projects
that
we
contribute
to
now.
This
is
also
a
decision
that
benefits
from
a
strategic
approach.
In
some
cases,
it
can
totally
make
sense
to
release
a
brand
new,
open
source
project
and
other
times.
B
Now,
as
I
mentioned
earlier,
companies
contribute
to
open
source
projects
by
having
employees
participate
and
then
collaborate
within
those
projects.
So
you
need
to
figure
out
how
many
people
you
need
what
skills
are
required.
In
some
cases,
you
might
actually
have
the
employees
with
the
skills
you
need.
Who've
already
contributed
to
some
of
these
projects,
which
is
a
great
starting
point,
but
it's
really
important
to
keep
in
mind
that
contributing
to
open
source
projects
requires
different
skills
than
participating
in
internal
projects.
B
These
people
need
to
be
comfortable
in
really
ambiguous
environments,
where
they're
going
to
receive
feedback
likely
at
some
point
difficult
or
negative
feedback
and
they're
going
to
be
expected
to
respond
to
that
feedback
in
the
public
in
a
professional
manner,
and
keep
in
mind
that
not
every
engineer
wants
their
work
to
be
in
the
public
Spotlight
so
which
I
mean.
Let's
be
honest,
you
feel
like
being
under
a
microscope.
Sometimes
the
skills
internally,
you
might
be
able
to
find
existing
contributors
that
you
can
hire.
B
Well,
you
do
need
to
provide
guidance
about
things
like
you
know,
licensing,
disclosing
confidential
information
and
any
internal
processes.
This
can
be
done
in
an
educational
way.
So
my
caution
about
the
guidelines
and
processes
is
that
they
can
be
written
in
ways
that
discourage
contributions
back
into
the
Upstream
project,
especially
when
they
make
heavy
use
of
really
scary
legal
jargon.
B
Where
you
talk
about
how
you're
going
to
punish
people
when
something
goes
wrong,
so
instead
you're
better
off
writing
those
in
ways
that
help
Engineers
understand
what
you
need
them
to
do
and
why
and
language
that
they
can
easily
understand
now,
as
with
any
good
strategies
and
plans,
the
outcome
and
results
should
be
measurable
so
that
you
can
tell
whether
your
results
were
successful
or
not.
Now
I
love
data,
and
this
sounds
kind
of
weird
but
measuring
open
source
project.
B
Ultimately,
you
need
to
look
at
your
strategies
and
plans
and
come
up
with
criteria
that
will
help
you
measure
whether
or
not
you're
successful.
So,
for
example,
if
you
want
to
improve
the
performance
of
a
particular
piece
of
Open
Source
software
you'll
want
to
have
success,
criteria
and
measurement
based
on
that
specific
type
of
performance.
B
Some
of
the
commonly
used
tools
can
be
found
in
the
Linux
foundation's
chaos.
Metrics
project
and
many
big
projects
already
have
dashboards
using
these
tools
and
others
to
display
contribution
data
for
the
project.
I
also
recommend,
maybe
over
measuring
a
bit
so
that
you
have
a
little
more
data
so
that,
as
your
strategy
shifts,
you're
more
likely
to
have
some
good
data
to
start
out
with,
and
this
can
help
you
investigate-
maybe
other
areas
that
you
might
want
to
improve
in
your
projects.
B
Upstreaming
your
patches
is
one
of
the
most
important
things
you
can
do
as
you
work
toward.
Can
you
still
hear
me?
Did
the
microphone
cut
out
no
I'm,
still
good,
okay,
so
upstreaming
your
patches
is
one
of
obviously
the
most
important
things
you
can
do
as
you
work
toward
taking
a
long-term
strategic
approach
to
your
open
source
contributions.
B
You
want
to
make
sure
that
you
spend
time
discussing
your
proposed
changes
in
the
community
before
you
start
making
them
by
talking
about
contributions
really
early
in
the
process.
You
can
get
feedback
on
ways
to
architect
those
changes
so
that
they'll
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
when
they're
merged
into
the
project,
and
these
discussions
also
avoid
surprising
people,
especially
for
something
new
or
big
changes.
B
It
can
also
help
to
break
those
changes
into
smaller,
easier
to
digest
contributions.
It
is
way
easier
for
maintainers
to
find
the
time
to
provide
feedback
on
smaller
contributions,
and
it
gives
you
time
to
make
Corrections
or
changes
if
something
you're
doing
isn't
quite
right
by
participating
in
open
source
projects
over
the
long
term,
your
employees
can
build
trust
within
a
community
and
build
the
relationships
needed
to
eventually
move
into
leadership
positions
and
increasing
responsibility
by
moving
into
leadership
positions.
B
A
lot
of
the
work
that
we
do
in
open
source
projects
is
based
on
the
relationships
we
have
with
other
people,
so
my
PhD
research
was
based
on
collaboration
in
the
Linux
kernel
and
as
part
of
that
research,
I
interviewed
a
bunch
of
Kernel
developers
and
in
all
of
the
interviews,
they
talked
about
the
importance
of
their
relationships
with
other
people.
Almost
all
of
them
talked
about
how
those
existing
relationships
made
it
easier
to
collaborate
with
others.
B
All
of
the
people
I
interviewed
mentioned
in-person
collaboration
at
conferences
and
other
meetings
as
something
that
was
really
important.
People
talked
about
how
it's
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.
B
Maybe
you
shared
a
meal
or
a
drink
or
just
had
a
nice
conversation
with
them
at
an
event
and
knowing
the
human
being
on
the
other
side
of
the
keyboard
can
really
make
a
bigger
difference
than
what
you
might
realize,
and
if
your
employees
are
working
on
open
source
projects,
you
should
see
if
there
are
any
conferences.
You
know
like
like
this
one,
like
qcd
Amsterdam,
where
large
numbers
of
the
community
members
attend
by
having
some
key
employees
attend
these
conferences.
B
They
can
build
deeper,
lasting
relationships
with
others
that
will
benefit
your
company
and
your
employees.
I've
spent
a
lot
of
time
at
open
source
conferences
over
the
years
and
I've
deep
and
Lasting
connections
with
the
people
that
I've
met
at
those
events,
and
now,
when
I
need
to
do
something
new
or
I.
Have
a
question.
I
usually
know
someone
who
can
point
me
in
the
right
direction
from
the
community
and
I
often
make
introductions
for
other
employees
to
people
outside
of
the
company
who
can
help
us
learn
something
new
or
maybe
solve
some
tricky
issue.
B
You
also
need
to
take
maintenance
expectations
into
account
when
building
your
open
source
strategies,
putting
large
chunks
of
code
into
an
open
source
project
disappearing
and
expecting
someone
else
to
maintain
it,
for
you
reflects
poorly
on
your
organization.
So
you
need
to
think
about
how
you're
planning
to
maintain
those
contributions
that
you're
making.
B
Now,
if
you
want
to
open
source
a
project
because
it
has
no
users,
it's
old,
it's
crusty
and
you
don't
want
to
maintain
it
anymore.
Please,
please,
just
don't
do
that
dumping
your
project
into
the
open,
SRS
community
and
hoping
that
someone
else
will
be
just
dying
to
take
over
this
piece
of
crap
that
you
don't
want
at
best
is
naive
and
generally
makes
your
company
look
bad
right,
so
make
sure
you're,
open
sourcing,
a
project
for
the
right
reasons,
for
example,
wanting
to
collaborate
and
innovate
with
other
people.
B
That's
a
good
reason
to
open
source
it.
If
you're
working
on
a
project,
that's
going
to
need
to
integrate
with
a
bunch
of
other
Technologies
open
sourcing,
it
can
make
it
easier
for
other
people
to
help
you
integrate
it
with
technologies
that
may
be
you're
less
familiar
with.
But
again
your
company
needs
to
be
prepared
to
maintain
that
project
over
the
longer
term.
Just
as
you
would
with
something
you
put
under
a
proprietary
license,
it
takes
time
and
resources,
so
you
should
take
that
into
account
when
building
your
strategies
before
I
wrap
up
this
talk.
B
Let
me
leave
you
with
a
few
resources
you
might
find
useful.
The
to
do.
Group
has
loads
of
guides
that
have
great
info
about
all
aspects
of
how
companies
work
in
open
source
projects.
The
cancf
contributor
strategy
tag
has
governance,
working
group
and
a
contributor
growth
working
group,
and
we
provide
templates
and
guidance
about
contributor
experience,
contributor,
sustainability,
governance
and
and
other
things
to
help
people
develop
strategies
for
maintaining
healthy
projects.
B
The
open
source
way,
guidebook,
has
loads
of
details
about
building
and
maintaining
open
source
projects,
and
the
chaos
project
has
loads
of
metrics
to
help.
You
measure
open
source
project
health
and
whether
you're
successfully
achieving
your
strategies,
and
these
are
all
great
starting
Place
places
for
understanding
best
practices
for
open
source
projects
in
open
source
projects,
relationships
and
Trust,
facilitate
collaboration
and
allow
your
employees
to
more
easily
contribute
to
the
projects
that
are
important
for
your
organization
and
then
move
into
leadership
positions
within
those
important
projects.
B
These
relationships
and
Trust
networks
are
built
over
time
and
require
a
long-term
commitment,
thinking
strategically
about
which
projects
are
most
important
for
your
organization
and
then
allocating
people
to
work
on
those
projects
over
the
long
term.
Lets
you
maximize
the
impact
that
your
open
source
work
will
have
for
your
organization
with
that.
Thank
you
so
much
for
coming
to
my
talk
and
I
don't
know:
do
we
have
time
for
questions
or
should
I
let
Cheryl
set
up
of.
B
D
D
D
So
we've
got
the
process
if
you're,
if
you're
a
new
contributor,
go
and
find
like
a
great
first
contributions,
something
that
I'd
like
to
see
more
road
maps
offering
is
like
suggested
corporate
sponsored
features,
because
those
are
the
features
that
require
longevity
right
and
it's
not
the
bus
problem.
It's
the
vacation
problem
like
do
you
have
enough
maintainers
in
a
project
that
two
can
go
on
vacation
and
it
still
works.
You
need
a
corporate
sponsorship
for
those.
Is
there
anything
like
that.
B
Not
that
I've
seen
I
mean
I,
think
I
think
probably
the
the
best
way
to
address
it
is
what
you
kind
of
mentioned,
which
is
with
with
road
maps
and
having
having
some
road
maps
and
being
clear
about
what
the
existing
maintainers
actually
have
time
and
space
to
do,
but
the
things
that
you
actually
really
want
that
no
one
really
has
time
for
and
try
to
try
to
get
some
people
to
to
pick
those
up.
And
then
you
know
in
some
cases
those
come
from.
B
You
know
from
the
other
direction
as
well
like
there
are
things
that
companies
need.
You
know
one
of
the
things
that
you
know.
Vmware
worked
a
lot
on
was
cluster
API,
for
example,
because
it
was
something
that
we
needed,
and
so
we
put
a
whole
bunch
of
people
on
it
and
helped
out
as
much
as
we
could
with
kind
of
building
out
some
of
that
infrastructure.
B
So
so
it's
kind
of
both
ways
but
I
would
love
to
see
more
projects
have
detailed
road
maps
for
things
that
they
want,
but
don't
have
time
to
work
on,
and
then
you
know
try
to
recruit
corporates
corporate
types
to
work
on
those,
but
it's
a
hard
problem
right,
like
finding
enough
contributors
and
sustaining
that
over
time
when
maintainers
are
already
burnt
out
and
tired
is,
is
a
big
problem
right
now.
It's
something
we
talk
about
a
lot
in
the
cncf,
any
other
questions.
E
B
I
am
not
stepping
into
that
land.
Mine
yeah,
the
the
CNC
app
and
the
free
software
Foundation
Europe
are
very,
very
different
types
of
organizations
and
I
think
they
I
think
they
serve
different
purposes
like
I.
Don't
I,
don't
like
to
think
of
those
as
like
one
being
better
than
the
other
I
tend
to
think
of
them,
as
both
being
good
for
for
sort
of
different
different
things
like
cncf
is
good
for
getting
a
whole
bunch
of
companies
together.
To
do
some
stuff.
B
C
So
don
well,
my
very
first
contribution
to
open
source
was
with
a
project
that,
probably
nobody
knows,
is
openmusic's
high
performance,
Computing
and
I
did
a
mess
of
it.
The
whole
contribution
was
took
three
months
to
to
get
into
the
the
patch
the
kernel
patch
I
wish
I
had
this
before
at
least
I
know
how
I
had
to
handle
the
whole
thing
before.
Thank
you
very
much.
Yeah.