►
From YouTube: Open sourcing for a living - Brian Proffitt
Description
Speaker: Brian Proffitt
Organization: RedHat
A
B
You
thanks,
thank
you
so
hi
good
morning
or
just
a
pitch
aloud,
so
the
the
topic
of
our
discussion
today
is
nominally
around
organizational
affiliation
and
what
it
is
and
why
it's
important
and
how
Kaos
is
going
to
be
addressing
this.
So
to
kind
of
read
off
to
this
talk,
I
just
want
to
kind
of
send
out
a
general
PSA.
B
Americans
are
weird
and
for
those
of
you
who
are
not
Americans,
it's
probably
the
most
redundant
thing
you've
ever
heard.
So,
but
let
me
let
me
give
you
an
idea
of
why
we're
weird
in
this
particular
instance,
I
found
it's
out
at
a
social
gathering
at
one
of
my
daughter's
schools.
This
was
many
years
ago
and
the
kids
were
really
little
and
we
were
meeting
all
the
parents
and
one
of
the
parents
was
from
England
and
I
try
to
be
social.
My
wife
brings
me
out
to
social
events
and
she's.
B
Encouraged
me
to
you,
know:
sort
of
engage
with
other
people.
I
know
that's
a
little
weird
for
me,
but
whatever,
and
so
as
a
person
going
up
to
a
stranger
at
an
event
or
party
like
this.
One
of
the
leading
questions
is
usually
something
around
the
lines.
Oh,
so
what
do
you
do
which?
What
is
your
occupation?
What
is
your
career?
What
do
you?
B
B
That
is
the
number
one
at
red
hat.
The
number
one
requested
thing
that
people
want
to
know
and
I'll
give
you
a
little
bit
of
background
about
this
and
why
red
hat
is
obsessed
with
this.
We
and-
and
those
of
you
who
have
heard
me
speak
before
I've
mentioned
this
periodically.
In
other
tops.
We
have
a
problem
with
organizational
diversity
at
Red
Hat,
because
a
lot
of
our
projects
are
dominated
by
Red,
Hat
employees
and
on
the
you
know,
on
the
first
level.
B
That
sounds
like
a
great
thing
for
us,
because
you
know
we're
dominated
the
open
source
upstream
project.
We
pretty
much
can
guide
it
wherever
we
want
to
go,
but
we
have
found
historically,
that's
actually
not
a
good
thing,
because
two
things
will
happen
there,
one
nobody
will
want
to
come
in
and
be
a
part
of
our
organization.
There
is
a
there's,
a
strong
perception
that
if
we
are
running
a
very
red
hat
control,
the
project
that
outside
developers
are
not
welcome.
B
That
is
not
true,
but
it
has
a
very
hard
perception
to
shake,
and-
and
so
we
want
to-
you
know-
encourage
outside
contributors
to
come
in,
and
that
leads
to
the
second
issue,
which
was
we
have
found
that
our
most
successful
projects
historically
have
been
projects
that
have
really
had
a
lot
of
diversity.
For
example,
when
we
are
part
of
the
larger
OpenStack
community,
that
is
a
wildly
successful
community
and
we
are
just
one
part
of
that.
B
We
are
part
of
we
are
one
small
part
of
the
ya-ya
shuttle
down
back
there,
so
we
are
also
a
big
part
of
the
wildly
successful
kubernetes
community,
and
we
are
just
one
small
component
of
that
and
we
see
a
huge
amount
of
innovation
there.
We
and
then,
to
give
you
an
example
of
something
we
do
do
right.
B
I,
don't
know
how
many
people
are
familiar
with
Red
Hat,
but
everything
we
do
is
in
the
upstream
and
one
of
our
most
successful
projects
and
one
of
the
ones
we
care
the
most
about
is
called
the
Fedora
project.
Fedora
is
an
operating
system
that
is
the
upstream
for
Red,
Hat,
Enterprise,
Linux,
and
because
of
the
way
we
work,
that
is
probably
one
of
our
most
important
upstream
projects
and
it's
a
seed
from
which
almost
everything
else
we
do
expands
and
grows.
B
Okay,
what
people
don't
really
realize-
and
we
just
did
a
survey
about
this
last
spring
right
now-
currently
only
22
percent
of
active
Fedora
contributors
that
that
we've
been
able
to
measure
are
working
for
Red
Hat,
which
is
great
and
and
we
really
loved.
You
know
when
we
heard
that,
because
it
really
reinforced
the
fact
that
okay
in
this
community
we're
doing
it
right.
So
that's
why
we
care
and
that's
part
of
why
you
know
you
should
care,
but
obviously
everybody
here
is
coming
from
different
organizations
and
and
backgrounds.
B
Chaos
hat
and
I've
been
a
member
of
the
Commons
work
group
within
project
Cass
for
a
couple
of
years
now,
and
we
as
though
I
mentioned
earlier
today,
we
just
a
lot
of
the
workgroups
just
released
formal
metrics
and
I
was
a
part
of
the
team
that
put
together
the
organizational
affiliation
metric,
which
was
an
interesting
process
in
and
of
itself,
because
that's
the
first
time
I've
ever
been
personally
involved
in
the
release
of
anything,
let
alone
a
metric.
So
that
was
a
really
educational
experience.
B
What's
the
ratio
of
a
single
company
overall,
the
kimi,
all
the
contributor
base
and
by
the
way,
I
want
to
be
very
clear
here
when
I'm
talking
about
contributors,
I
may
slip
up,
I
may
say
coders
I
may
say
developers,
I
may
say,
because
I'm,
old
and
I
have
habits
and
it
creeps
in,
but
just
make
sure
that
everybody
understands
I'm
talking
about
contributors,
whether
their
documentation,
people,
whether
they're
QA
people,
whether
they're
working
on
the
project
website
or
they're.
Doing
that
you
know
they're
doing
code
for
the
project
itself.
B
It's
all
part
and
parcel,
so
I
should
be
saying
contributors
consistently.
If
I,
don't
once
you
know,
that's
just
a
slip
of
the
tongue
on
my
part,
I
really
am
talking
about
all
contributors
here,
we're
not
trying
to
differentiate
types.
At
this
point,
there
are
some
questions
that
that
will
come
up,
but
really
as
far
as
organizational
affiliation,
COEs
everybody's
equal
in
this
regard:
okay,
whether
they're
a
volunteer
they're
working
for
a
company
they're
working
for
a
foundation,
whatever
they're
doing
and
wherever
they're
coming
from
all
contributors.
B
All
contributions,
rather
are
equal,
so
we're
trying
to
measure
impact
here
because
we
want
to
see
you
know
how
are
different
organizations
over
time
influencing
a
given
project
and
then
there's
the
other
part
of
this
which
this
this
goes
into,
an
area
that
we
have
in
chaos.
On
the
risk
side
of
things.
There
are
different
work
groups
within
chaos.
B
It's
sort
of
a
catch-22
we
the
only
way
to
fix
it
is
to
get
other
people
to
come
in,
but
they
won't
come
in
because
they
think
that
we're
going
to
not
be
good
good
players
in
the
ecosystem.
So
it's
we're
talking
about
we're
measuring
impact
and
we're
also
measuring
influence.
There
are
ways
that
organizational
organizations
can
influence
an
ecosystem
without
actually
definitely
be
a
contributor
Red
Hat.
B
That
was
a
thing
I,
don't
think
they
ever
took
it
active
advantage
of
that
I
think
they
just
basically
people
seem
to
regard
them,
so
you
have
influence
as
an
organization
whether
you
know
it
or
not,
just
by
the
cachet
being
in
a
certain
organization,
Google
Amazon,
Red,
Hat
Sousa.
All
these
players
in
Amazon
I
said
that
already
they
all
have
influence
in
the
open
source
space,
whether
they
know
it
or
not.
B
Just
by
virtue
of
being
these
companies
and
being
act,
players
and
various
open
source
projects,
other
ways
of
influence
were
you
know,
is
you
know?
Where
did
the
code
come
from
and
so
who
built
the
code?
First,
we
recognize
that
kubernetes
is
started
at
Google.
That
was
a
Google
project.
So
by
virtue
of
that,
a
la
socially,
we
tend
to
give
them
a
little
bit
more.
B
You
know
gravitas,
you
know,
I
have
no
idea
right
now,
where
google
sits
on
the
organizational
contributor
ranks
within
kubernetes,
I
suspect,
they're
number
one
and
that's
great,
but
there
may
come
a
day
when
they're
not
number
one
and
that's
totally
fine,
but
I.
Think
people
will
so
give
them
a
lot
of
influence
because
they
started
it.
B
You
know,
because
you
can't
ignore
the
social
implications
of
well
Google
started
this
you
know,
and
and
they
by
virtue
of
that
they
should
be
given
some
or
will
be
given
some
social
difference
as
well.
So
this
is
sort
of
the
reasons
why
we
were
really
looking
at
organizational
affiliation
as
a
metric.
B
So
I
wanted
to
talk
about
about
what
actually
we're
seeking
giving
you
sort
of
the
the
sort
of
the
whys
of
why
we're
involved.
With
this
question
and-
and
so
some
of
you,
this
may
seem
obvious
as
well.
Well,
we
wonder
why
the
sky
is
blue,
so
this
is
not
rocket
science.
As
far
as
why
we
want
to
know
this.
But
what
are
we
actually
seeking
and
and
to
do
this,
as
in
the
Commons
work
group,
where
this
this
particular
metric
came
from?
We
really
had
to
break
it
down
into
bite-sized
chunks
of
them
Meishan.
B
You
can't
just
throw
out
a
metric
and
say:
okay,
we
want
to
know
who's
working
where
and
everybody
just
go.
Okay
that
that's
hard
to
implement
that's
hard
to
implement
from
a
tooling
side
and
that's
hard
to
understand
from
a
conversational
side.
So
because
here's
the
thing
about
metrics
there's
never
going
to
be
one
metric.
That
fits
everybody's
purpose
because
we're
all
coming
from
different
places
we're
coming
from
different
motivations,
different
communities,
we're
going
to
all
be
looking
for
different
things.
B
Okay,
we
want
to
get
these
these
metrics
down
to
atomic
pieces
that
can't
really
be
broken
down
anymore
and
then
you
all,
as
community
leaders,
should
be
able
to
pick
and
choose
which
metrics
you
want
to
answer
a
larger
question
and
so
you're
sticking
together
the
Lego
blocks
and
I'm,
making
a
little
car
or
you're,
making
a
little
rocket
ship
or
somebody's
making
a
palm
tree
or
something
like
that.
It's
the
same
Lego
blocks,
but
by
you
know,
by
virtue
of
being
able
to
put
them
together
in
new
and
creative
ways.
B
B
Five
minutes,
okay,
so
really
quickly.
We've
already
talked
about
organizational
affiliates
and
this
is
organizational
influence
rather
and
how
dominant
are
the
individual
organizations
in
the
project?
What's
the
elephant
factor,
so
we've
already
gone
over
that
relationships.
We
it's
not
just
knowing
who's
involved
in
a
project.
But
how
are
these
projects?
You
know
who's?
What
are
the
relationships
between
these
companies
are?
You
know,
are
these
companies
involved
in
a
larger
consortium
or
a
larger
software
foundation,
so
software
foundations
now
become
a
layer
of
information
that
we
want
to
get?
B
B
Do
we
treat
them
as
separate
or
one
and
trust
me?
These
conversations
are
going
on
with
us
and
software
foundations
when
its
foundation
all
the
time
right
now
and
how
do
you
you
treat
that
affiliation
changes,
people
move
companies
all
the
time.
You
start
at
one
company
you
go
to
another
company
and
then,
which
you
know
are
certain
companies
becoming
magnets,
for
you
know
organizational
affiliation.
As
you
know,
it's
Google
hiring
a
lot
of
people
is
Amazon
hiring
a
lot
of
people.
B
Are
people
suddenly
leaving
a
certain
company
what's
going
on,
so
we
look
at
magnets.
We
look
at
anti-magnus
if
your
company
is
suddenly
losing
a
lot
of
people
in
your
communities
and
as
as
as
hires,
either
way,
you've
got
a
problem.
Why
are
people
leaving
your
company?
Why
are
people
people
coming
in?
So
we
look
at
things
like
that
and
look
at
an
affiliation
changes
and
we
built
metrics
in
that
sort
of
take
that
into
account
contributing
over
time.
A
lot
of
some
of
these
metrics
can
be
taken
as
a
snapshot.
B
Here's
where
we
are
now,
but
then,
when
we
look
at
these
over
time
now
we
can
start
to
see
you
know,
trends
and
and
our
you
know,
and
this
gets
into
other
metrics.
We
have
around
evolution
and
growth
and
maturity
and
decline.
Okay,
so
now
we
want
to
see
you
know
how
active
are
we?
You
know,
Google
is
number
one
in
kubernetes
well,
are
they
going
to
continue
to
be
number
one?
Are
they
slippin?
Are
they
growing?
What's
that
going
to
look
like
Google
might
really
want
to
know
that
so
we
we
take
these
metrics.
B
B
Well,
agile
is
great,
but
if
you
have
somebody
who's
a
volunteer
on
the
outside,
who
is
not
necessarily
going
to
have
the
time
to
devote
to
a
certain
sprint
over
a
given
period
of
time,
you
inadvertently,
maybe
lock
them
out.
So
we
we
want
to
look
at
who
are
volunteers,
so
we
can
identify
them
and
figure
out
what
their
needs
are
within
our
larger
community.
B
Again
organizational
diversity,
we're
talking
about,
commits
we're
talking
about,
merges
we're
talking
about
contributor
who
are
their
contributors
or
the
contributions
they
made
who's
answering
issues,
who's,
creating
issues.
All
of
these
are
separate
small
little
atomic
measurements
that
we
take
into
account
within
the
organizational
affiliation
metric.
B
Peripheral
organizations
who
are
the
people
are
just
coming
in
making
these
brilliant
awesome
contributions
and
then
they're
dropping
you
never
hear
from
them
again.
We
call
those
drive-bys.
Okay,
drive-bys
are
usually
those
are
the
people.
You
really
want
to
come
we're
like
wait,
come
back,
you
you,
you
did
something
really
brilliant
and
cool,
but
how
do
we
get
you
back
so
first
we
have
to
figure
out
who
those
people
are
and
then
we
can
try
to
figure
out.
What's
the
pattern,
what
brought
them,
what
brought
them
in
to
contribute
in
the
first
place?
B
Leadership.
That's
a
big
thing:
it's
not
just
contributors!
How?
How
is
the
organizational
affiliation
in
the
leadership
if
you
have
I
mentioned
Fedora
earlier,
where
we
have
22
percent
of
the
overall
contributors
work
for
Red
Hat,
but
that
percentage
is
much
higher
at
the
leadership
level
about
I.
Think
it's
about.
90
percent
of
the
leadership
functions
within
Fedora,
our
Red
Hat
employees.
So
now
we
have
to
say:
okay,
how
diverse
is
fedora?
B
If
we
not
if
people
aren't
percolating
up,
that
is
actually
a
problem
we've
identified
and
we're
trying
to
correct
that
and
get
more
non
Red
Hat
people
in
leadership
positions.
So
you
want
to
take
a
look
at
that.
That
also
leads
to
a
diversity
issue
very
quickly,
because
a
diversity
in
terms
of
DNI
and
next
door.
We
want
to
make
sure
that
people
of
different
backgrounds,
races,
genders
orientations
are
also
being
included
in
leadership
positions
so
that
overflows
very
quickly
with
that
as
well.
B
This
will
considerations
who's
paying
for
what?
How
do
these
fiscal
considerations
affect
a
project?
If
a
certain
organization
is
doing
all
the
infrastructure
work?
That's
fine,
but
then
there's
that
inadvertently
block
out
other
people
or
does
it
help
get.
You
know
onboarding
made
if
we
don't
have
to
worry
about
the
infrastructure
for
a
given
open
source
project,
that
can
be
a
good
thing
or
it
could
be
perceived
as
a
bad
thing
and
how
do
those
contributions
influence
anything?
So
that's
certainly
a
metric
that
we
look
together.
B
Ownership
distribution
house
code
ownership
distributed
across
the
organization
whether
they
belong
to
a
certain
company
or
not.
Those
are
definitely
considerations
for
projects
like
kubernetes
and
OpenStack
and
and
how
you
know
owning
the
code
is
still
a
thing
and,
and
sometimes
that
gets
into
foundational
ownership
like
who
started
in
some
things
around
trademarks.
So
we
have
metrics
built
in
to
the
organizational
affiliation
set
that
hopefully
will
take
care
of
that
and
look
at
that
as
well
and
again
I'm
just
talking
about
the
Lego
blocks.
B
B
When
we
look
at
this,
you
know
we're
taking
these
atomic
metrics
and
we're
building
bigger
questions.
So
we're
big
we're
looking
at
things
like
what
are
the
roles
they,
you
know
when
we
add
all
these
together.
One
of
the
questions
that
we
can
ask
is
you
know
what
are
the
roles
that
people
have
with
from
different
organizations?
How
do
we?
How
do
we
not
just
look
at
the
baseline
contributions
that
an
organization
makes
to
a
community?
But
what
are
what
are
their
leadership
roles?
You
know
how?
How
do
they
get
involved?
B
Do
they
come
in
I've
seen
this
before?
Did
they
come
in
and
they're
on,
like
a
governing
board,
for
instance,
but
then
they
never
show
up
for
the
meetings
you
know.
Well,
that's
that's
a
thing,
and
maybe
we
need
to
work
to
identify
that,
because
that
can
lead
to
stagnant
growth
or
you
know
no,
no
help
at
all
and
we're
they're
blocking
other
people
who
might
have
more
to
contribute
from
coming
in
so
I've
I.
Think.
Basically,
you
know
this
is
the
outline
of
what
we're
trying
to
do.
B
I
again,
I
would
want
to
refer
you
to
Kaos
dot
community
/
metrics.
There
is
an
excellent
page
of
not
just
the
organizational
affiliation
metric,
but
all
of
the
new
metrics
that
we've
released
I
believe
there'll
be
some
other
discussions
about
that
today,
but
I
encourage
you
to
go
out
there
and
start
looking
and
because
they're
on
github
for
the
love
of
Pete
get
out
there
and
contribute
and
give
us
feedback.
These
are
not
static
things.
B
B
Don't
if
I
understand
your
question
correctly
around
minimizing
code
ownership
automatically
within
an
organization
I'm,
not
a
hundred
percent
sure
that
we
can
do
that
automatically
I,
think
that
has
to
be
done
on
a
case-by-case
basis.
Like
an
example
of
this
problem
would
be.
We
have.
There
are
organizations
that
are
not
as
transparent
as
others
and
I'm,
not
calling
them
out
here,
because
I'm
being
recorded
they're,
not
they're,
not
as
transparent
about
what
they
do
in
the
upstream
versus
what
they
do
in
the
downstream
and
and
that
kind
of
gets
into
the
whole
code.
B
Ownership
thing
if
you're
putting
in
a
lot
of
new
feature,
sets
in
your
downstream
project
that
are
not
going
into
the
upstream
first,
then
that's,
there's
no
automated
way
of
fixing
that
you
really
have
to
go
in
there
and
do
a
self-examination
and
start
encouraging
your
developers
to
develop
in
the
upstream
as
much
as
possible
and
to
be
fair.
Red
Hat's
occasionally
has
a
problem
with
this.
B
We
are
very
open
source
minded,
but
there
are
some
projects
within
our
company
that
have
it
that
hasn't
quite
taken
as
well
as
others
and
and
and
it's
not
even
really
something
maliciously
done.
It's
just
like.
We've
got
all
this
work.
We
have
to
do
on
the
downstream
commercial
project,
our
product
right.
We
want
to
do
it
all
in
there
and
we
have
to
kind
of
keep
reminding
people.
No,
you
want
to
do
it
out
in
the
open
first
and
then
bring
it
down
into
the
downstream.
B
So
there's
no
real
automated
way,
but
identifying
the
problem
is
the
first
step
to
a
solution
and
that's
what
a
lot
of
these
metrics
are.
We
haven't
gotten
into
we
get
into
these
discussions
all
the
time
about.
Well,
how
do
we
after
we
find
this?
How
do
we
fix
it
and
we've
had
this
step
back
and
say?
No,
that's
not
our
job
right
now.
B
B
If
I
defined
fedora
as
our
most
successful
project,
I
may
have
been
in
error,
it
is
certainly
it
is
certainly
our
most
important
project
there.
There
there
there's,
like
maybe
I,
can
name
two
or
three
off
right
off
the
top
of
my
bet
that
are
the
most
important
for
Red
Hat
by
virtue
of
what
they
are.
I
believe
that
Fedora
is
our
most
successful
project
personally,
because
it
has
a
wide
range
of
I
divert
s'ti.
B
We
have
competitors
like
canonical
and
Sousa
who
are
actively
engaged
in
the
Fedora
project
and
we
are
actively
engaged
in
their
equivalents.
So
we
you
know,
that's
for
me,
that's
my
personal
brand
of
success.
So
you're
right,
it
is
a
conversation
for
another
time
and
I'm
sorry
did
gloss
it
over
but
yeah
what's,
but
it's
going
to
be
different
for
me
versus
you
or
anybody
else.
So
that
is
an
excellent
question.
I'd
love
to
follow
up
and
that's
giving
me
the
eyeball
here
so
so.