►
From YouTube: True Confessions: The Seven Deadly Sins of Open Source Communities | Brian Proffitt |CHAOSSconEU2020
Description
True Confessions: The Seven Deadly Sins of Open Source Communities
This talk would take a humorous approach to explaining what really no one should do when managing and measuring open source community best practices, with the primary goal of instilling positive open source development practices to the audience. Such ""don'ts"" include not documenting anything, establishing no clear paths to success, and not bothering to communicate.
Slides: https://chaoss.github.io/website/CHAOSScon/2020EU/slides/seven_deadly_sins.pdf
-----
Brian Proffitt
Manager - Red Hat Open Source Program Office
@TheTechScribe
Brian is a Manager within the Red Hat Open Source Program Office, active in community content, onboarding, and open source consulting. Brian also serves on the governing board for Project CHAOSS, a metrics-oriented approach to ascertaining community health. Follow him on Twitter @TheTechScribe.
-----
About CHAOSScon
Learn about open source project health metrics and tools used by open source projects, communities, and engineering teams to track and analyze their community work. This conference will provide a venue for discussing open source project health, CHAOSS updates, use cases, and hands-on workshops for developers, community managers, project managers, and anyone interested in measuring open source project health. We will also share insights from the CHAOSS working groups on Diversity and Inclusion, Evolution, Risk, Value, and Common Metrics.
https://chaoss.community/chaosscon-2020-eu/
A
Okay,
hi,
no
I'm,
the
last
talk
and
I
know
I'm
between
you
and
beer,
so
I'm
really
gonna
make
this
as
quick
as
I
can
so
welcome.
Today,
I'm
going
to
be
talking
about
the
seven
sins
of
open
source
communities,
and
my
name
is
Brian
prophet
I
am
a
manager
with
the
Red
Hat,
open
source
program
office
and
we're
weird,
and
those
of
you
who
know
people
who
I
work
with
will
understand.
A
That's
a
multi-level
statement,
because
we
are
wizard
well
as
a
weird
innocence
that
we're
not
like
other
oz
posed,
because
a
lot
of
open
source
program
offices
tend
to
focus
on
like
making
sure
their
compliance
issues
and
getting
open
source
even
started
and
integrated
into
the
culture
of
their
corporation
Red
Hat.
We're
sort
of
past
that
point,
because
we
do
that
every
day,
and
that
sounds
really
flippant.
A
But
it's
literally
true
when
IBM
purchased
us
last
and
it
went
in
effect
last
year
they
said
hey,
we
would
love
to
use
your
contributor
guidelines
and
give
those
to
our
developers
and
they
could
use
them
to.
You
know
contribute
to
open
source
and
we
were
like
that's
great
and
then
we
were
like.
We
never
wrote
them
down,
I'm
not
kidding
so
anyway.
So
we're
a
little
weird.
A
A
Those
on
audits
and
I
want
to
make
clear
we're
not
talking
about
the
sins
that
you
find
in
mythology
in
the
Bible
like
pride,
because
I
have
my
own
action
figure.
So
you
know
that
that's
pride,
that's
bad!
So
we're
not
talking
about
those
we're
talking
about
the
kind
of
sins
that
are
basically
anything
that
detracts
you
from
the
mission
and
the
health
of
your
project.
A
Now
don't
take
a
picture,
that's
all
weird,
all
right,
so
we're
gonna
go
so
the
first
10
lack
of
onboarding,
and
if
this
is
like
101
for
all
of
you,
then
the
beer
is
coming.
Hang
on.
Okay,
onboarding
is
probably
the
number
one
thing
that
we
looked
at
with
any
project
existing
or
new
within
RedHat,
and
when
we
do
our
audit,
we
are
focusing
on
that.
We're
trying
to
see
how
easy
is
it
for
an
outsider
to
your
community
to
get
inside
to
your
community
and
believe
it
or
not
a
lot
of
projects.
A
Don't
always
do
that
very
well.
They'll
put
up
a
really
pretty
flashy
website
and
say
here's
my
code
and
that's
it.
There
are
a
few
things
you
need
to
do.
There
are
three
basic
tenets
to
this.
One
is
tell
people
what
your
project
is.
Make
sure
that
happens.
The
other
is
tell
people.
How
is
it
used?
Okay
and
that
comes
into
use
cases,
documentation
that
sort
of
thing
and
it.
Finally,
the
third
aspect
of
onboarding
is:
how
do
they
get
it?
A
B
A
B
A
Let's
go
right,
I
mean
we
should
be
right
there,
you
know,
and
and
even
in
Red
Hat
I'm
like
worse,
worse
and
download
link.
How
do
I
get
this?
You
know
or
if
it's
not
an
executable,
but
some
cloud.
Think
of
a
jig.
You
know
where's
my
link
to
get
to
how
do
you
install
it?
However,
you
do
that
so
onboarding
is
this.
You
know
not
having.
It
is
a
major
sin
that
we
cover
on
our
audit.
The
other
is
nothing
in
writing.
So
this
is
the
age-old
problem.
A
Nobody
wants
to
do
documentation
because
documentation
is
boring,
I
understand
that,
but
you
should
always
write
it
down
for
your
own
sanity
and
the
sanity
of
those
who
will
come
after
you.
The
only
time
you
should
never
write
anything
down
is
when
you're
maybe
telling
that
girl.
Next
to
you
in
second
grade
that
you
like
her,
never
write
that
down.
I
may
have
experience
of
nothing
okay,
but
that's
it.
A
That's
the
only
time
you
should
write
everything
now,
because
keeping
your
project
healthy
and
the
continuity
of
your
project
going
is
a
key
part
of
that,
and
that
is
where
documentation
comes
in
and
not
just
the
how-to
documentation
write
down
what
your
governance
model
is.
What
write
down
what
your
process
workflows.
Are
you
don't
have
to
write
a
novel,
okay,
you're,
not
James,
Faulkner,
okay,
you
you're,
not
Jane
Austen
just
write
something
down.
It
doesn't
have
to
be
that
prolific,
but
make
sure
it's
accurate,
okay,
the
next
one
who's
in
charge.
A
You
don't
want
that
to
be
a
mystery
to
incoming
people.
They
even
know
like
who.
How
does
this
whole
thing
work?
Who
did
they
go
to
if
there's
a
problem?
What
person
is
going
to
handle
these
commits?
What
person
is
going
to
handle
if
I
have
the
code
of
conduct
issue?
Okay,
leadership
is
a
mystery
that
is
often
hidden.
Smaller
projects
are
very
guilty
of
this
began
and
edits,
and
it's
kind
of
hard
you
don't
want
to
slap
them
around,
but
basically
they're
small
they're
like
well.
There's
like
ten
of
us
here.
A
We
don't
know
who's
in
charge,
but
it's
not
even
really
about
being
in
charge.
It's
like
who's
doing
what
okay,
you
want
to
make
sure
that
that
is
well-defined
somewhere
in
your
projects,
documentation,
no
path
to
success.
Now
this
is
starting
to
get
into
areas
that
mattress
is
talking
about
with
diversity
and
include
and
and
people
not
knowing
how
to
advance
in
the
project.
What
does
it
take
for
me
as
a
love,
you
know
new
contributor
to
become
a
committer
someday
or
to
be.
You
know
part.
A
If
there's
a
you
know,
if
your
privates
picking
up
do
you
have
a
technical
committee,
you
know
how
do
I
become
part
of
that
governance
model?
Okay,
you
need
to
kind
of
outline
that
a
little
bit
and
I'm
not
saying
again
I'm
not
saying
make
bylaws
like
the
Apache,
Software,
Foundation
or
Mozilla,
or
something
like
that
and
there's
there's
nothing
wrong
with
that.
But
I
mean
you
don't
have
to
go
that
far,
but
do
be
explicit.
A
Don't
let
people
just
want
to
be
like
I,
don't
know,
you
know,
that
is
a
sin,
and
these
are
things
that
we're
looking
at
on
the
audits.
As
well
poor
communication,
so
how
many
of
you?
How
many
people
have
gone
to
a
project
did
not
know
where
the
developers
are
like
virtually
you
might
know
where
their
office
is
yeah:
okay,
yeah!
That's
a
problem
to
be
a
good
open
source
project.
You
must
communicate
out
in
the
open
okay,
and
this
is
what
I
tell
these
projects
all
the
time.
A
A
You
haven't
actually
told
anybody
where
to
go
so
if
they
have
a
contribution
or
if
they
have
a
problem
with
the
software,
it
would
be
really
nice
for
them
to
know
actually
where
to
go
so
be
explicit
about
where
your
communication
channels
are,
and
if
you
do
have
communication
channels,
please
for
the
love
of
whatever
DD
you
believe
in
or
not
make
sure
you
actually
communicate
out
in
the
open.
Okay,
don't
don't
be
untransparent,
which
is
actually
skipping
ahead
to
another
sin,
but
make
sure
you
have
your
communication
set
lack
of
transparency.
A
Ray,
you
and
I
are
working
together
in
an
office
we're
developing,
which
is
total
fiction
and
I
can't
code,
but
anyway,
I
have
a
problem.
Okay,
we're
working
on
with
such
project,
I
say:
hey
ray:
can
you
look
at
this
sub
having
a
problem
here?
I
can't
quite
seem
to
get
this
bug
and
you
and
I'll
be
like
yeah.
You
look
at
it.
You're
very
smart
you'll
say
yes,
this
is
the
solution
and
you'll
be
nice.
A
You
want
me
fun
of
me
and
will
get
the
solution
done
and
it's
done
and
I
push
it
out
into
the
open
and
we're
finished.
What
just
happened
was
that
transparent
not
really
and
I
bring
that
up
as
though
as
a
model-
and
that
seems
really
nitpicky,
but
it
happens
all
the
time
and
you
have
to
be
diligent
with
it
now.
Something
like
that
nobody's
gonna,
come
down
and
say:
you're
not
being
open,
but
technically
you're
not
being
open.
A
It's
really
hard
to
get
into
mindset,
especially
when
you're
working
in
smaller
workgroups
with
a
bunch
of
people
who
are
doing
what
you're
doing
and
you're
cutting
in
the
same
modules
day
in
and
day
out
to
keep
those
discussions
private
because
it's
faster
and
more
efficient.
It's
easy
for
me
to
turn
to
Ray
and
say:
hey:
can
you
take
a
look
at
this
weather
is
in
the
office
or
you
know
on
a
virtual
slack
channel
somewhere?
Okay.
A
So
it's
very
important
that
when
you
have
communication
channels
make
sure
that
all
of
your
conversations
are
happening
in
the
open
as
much
as
you
humanly
can
and
be
diligent
about
that,
it's
an
easy
trap
to
fall
into
I,
pull
into
it
all
the
time,
because
sometimes
I
don't
really
want
to
have
a
big
open
discussion
about
something.
I
just
want
to
get
something
done:
okay,
but
that's
that
that
actually
is
another
sin.
That's
pride
again,
I
have
to
kind
of
ease
up
and
let
that
go
and
get
better
input
from
other
people.
A
This
spidel
said
it's
not
something
we
audit
for
you
because,
as
Matt
was
saying
earlier,
this
fits
into
things
like
diversity
and
inclusion
and
neurodiversity
and
understanding
the
differences
in
others,
and
we
don't
have
a
lot
of
metrics
here.
Yet
those
are
the
only
part
of
the
slides
at
my
presentation
are
not
included
in
the
audits
that
we
do
with
in
Red
Hat
ask
them,
because
it
is
very
subjective,
but
I
always
like
to
stick
this
point
in
because
it
is
super
important.
A
We
have
to
try
when
we
put
forth
our
best
efforts
with
the
communities
with
which
we
work
to
see
ourselves
and
others.
I'm
not
saying
don't
be
arrogant
enough
to
be
like.
Oh
well,
I
have
three
daughters
and
a
wife,
so
I
understands
women's
issues.
Right,
don't
be
that
person
I.
Am
that
person
right,
I,
don't
know
nothing
about
being
a
woman.
I
am
never
going
to
be
arrogant
enough
to
say
that,
and
you
know,
I
have
a
daughter
who
is
african-american.
A
A
To
see
your
badge,
so
don't
what
I
say
see
yourself
enough,
others
I
say:
don't
apply
your
value
system
to
everybody
else.
What
I'm
saying
is
try
to
put
yourself
in
a
position
where
you
can
listen
and
understand
and
not
be
defensive.
If
somebody
comes
to
you
and
says,
hey
I'm
having
a
problem
with
the
way
you're
doing
something.
Okay,
we've
all
been
different.
We've
all
been
raised
in
different
backgrounds:
different
locations,
different
nationalities.
A
B
B
A
We
do
a
lotta,
the
lack
of
transparency,
because
we're
looking
for
instances
of
communications
that
are
happening
behind
the
scenes,
so
at
Red
Hat,
it's
a
little
bit
easy
for
us,
because
the
way
our
model
works
is
everything's
done
in
the
open
source
community
and
them
already
that
we
take.
That
code
would
bring
it
to
the
downstream
community
within
Red
Hat.
And
then
we
harden
it
rebrand
it
and
say
it's
Red
Hat
whatever
by
the
way,
the
secret
to
our
whole
branding
scheme
is
we've
never
come
up
with
names
for
our
products.
A
We
just
say:
oh,
it's
a
virtualization
product,
it's
Red,
Hat
virtualization,
no
go
back
and
look
at
our
catalog.
You
see
I'm
right,
but
anyway,
what
I'm
trying
to
do
there?
What
we're
looking
for
is
we
don't
want
the
developers
who
I
know
are
working
on
the
downstream
they're
like
having
conversations
on
the
internal
less
about
the
upstream
projects.
A
So
for
me
it's
a
little
easy
because
I
know
where
they're
all
working.
So
if
I
see
conversations
about
the
upstream
project
in
a
downstream
list
or
channel
we're
gonna
have
a
conversation
and
we're
gonna
say
you
know:
y'all
get
up
there
and
do
it
in
the
upstream,
and
it
happens
occasionally
because
again
nobody's
being
malicious.
It's
just
easy
to
do.
You're
there
you're
talking
to
each
other
and
say:
oh
yeah.
We
found
this
bug.
A
C
I'm
curious
what
you
think
about
diversity,
related
events
or
activities
and
open
source
conferences
as
a
way
of
measuring
not
seeing
ourselves.
There's
two
give
maybe
a
little
bit
of
context
to
that:
some
things
that
we've
trialed
and
some
of
the
Fedora
community
and
other
communities
or
things
like
speaking,
a
native
language,
our
and
doing
things
like
the
candy
swap
where
we
have
these
experiences
to
get
to
know
people
in
our
community
that
are
in
a
technology
context.
Something
I've
been
thinking
about,
but
I
was
curious.
What
you
think
well.
A
C
A
Of
no
it's
no,
it's
cool.
So
what
I
think
is
yes
to
all
of
that,
and
and
that's
why
I
was
excited
about
what
Matt
was
bringing
them.
The
thing
is:
Oscar
is
not
necessarily
focused
on
things
at
the
event
level,
because
we
have
an
outstanding
events
team
at
Red
Hat.
That
is
helping
us
with
that,
and
I
know
fedoras
a
little
bit
different,
but
a
fedora
is
large
enough
and
mature
enough
that
they
handle
their
own
events
themselves
and
Osmo
doesn't
take
away
from
that.
So
I'm
not
trying
to
dodge
the
question.
A
It's
mostly
that
we
really
don't
focus
on
the
event
level
other
than
to
say.
Yes,
we
need
a
code
of
conduct
and,
yes,
we
need,
to
you
know,
have
diversity
and
inclusion,
but
we're
not
using
that
as
a
marker
for
individual
projects.
Yet
because
most
of
the
projects,
Fedora
notwithstanding,
don't
aren't
big
enough
to
have
their
own
events
yet
I
mean
you're,
talking
Fedora
you're
talking
to
sent
us,
which
is
having
one
down
the
street
right
now
and
over
used
to
and
Rdio,
but
that's
part
of
OpenStack.
A
A
Okay,
so
at
the
beginning
of
every
year-
and
there
are
project
to
Ozma
or
directly
responsible
for
they're
on
my
list
and
then
I
put
out
a
blanket
I'll
call
for
any
other
community,
because
some
of
the
communities
in
Red
Hat
are
managed
by
the
business
units
like
ansible
they're,
not
part
of
oz
boat.
They
we
bought
them
that
came
in,
they
have
their
own
community
structure
there,
but
I
will
say:
hey.
A
Do
you
want
to
you
want
to
do
this
and
if
they
say
yes,
I'll
schedule
it
and
then
the
actual
physical
process
is
I
have
a
long
checklist
that
I
that
puts
this
out
and
have
much
more
robust
form
and-
and
we
just
go
through
it,
we
score
on
individual
points.
Some
of
it
is
based
on
things
that
we
found
already
working
with
chaos.
Some
of
it
are
things
we've
built
ourselves,
and
then
we
put
that
all
together
and
give
them
a
report,
and
it
looks
like
I've
done.
Yes,
they
are.