►
Description
Presented by Mike McQuaid
Every open-source project wishes it had more maintainers to help run things. Learn from Mike McQuaid, maintainer of the Homebrew project for 7 years with over 5500 contributors, how to encourage and increase participation in your open-source project.
About CodeConf
CodeConf improves the software community by providing a forum for thought-provoking talks and forging social connections. The fourth installment of the CodeConf series took place in Hollywood in 2016. This year's event focused on systems engineering projects, practices, and programs in the open source community.
For more information on this year's CodeConf, go to:
https://codeconf.com/
B
B
Not
the
one
that
is
mine
right.
Sorry,
there
we
go
so
I'm
wearing
kind
of
two
hats.
One
ever
I
can
move
all
with
github
stuff
and
my
first
hat,
which
is
my
older
hat,
which
is
me
being
a
Nintendo.
Remember
it
I
started
with
what
going
to
a
brew
in
about
2009
I'm,
still
working
on
it
today,
so
I
think
I'm,
the
oldest
running
maintainer.
So
on.
B
A
B
What
I'm
going
to
talk
to
you
about
today
is
I
think
that
I
kind
of
came
up
with
it's
called
like
the
contributor
funnel
and
I
kind
of
mentioned
it.
As
a
like
offhand
remark,
and
at
a
previous
conference
and
people
seemed
to
think
it
was
interesting
so
that
I
made
like
a
talk
out
of
it,
and
so
it's
basically,
this
kind
of
four
main
things
but
I'm
going
to
kind
of
walk
through
in
this
talk.
B
Now,
for
that,
I
don't
really
understand
but
I'm
going
to
use
anyway
and
then
finally
like
retaining
people,
because
I
think
something
that
doesn't
always
get
talked
about
with
open-source
community
things
is
how
to
make
sure
your
project
doesn't
die.
It's
like
surprisingly
easy
to
have
successful
projects
and
do
one
or
two
relatively
simple
things
which
can
cause
big
problems,
so
hopefully
we'll
kind
of
work
through
this
together.
So
the
first
one
grouping
your
users
together.
So.
A
B
B
So
this
kind
of
I'm
by
this
I'm,
assuming
we're
talking
about
people
who
are
just
users
and
not
people
who
are
users
and
maintainers
like
me
as
well,
for
example,
and
these
people
are
people
who
may
be
like
if
you're,
lucky
kind
of
file
issues
on
your
project,
maybe
talking
your
mailing
list
whatever,
but
like
the
vast
majority
of
them
are
going
to
be
people
who
have
no
interaction
with
you.
They
do
not
have
a
gap
of
account.
B
They
do
not
have
you
know,
maybe
for
the
comprehension
of
who
makes
this
project
and
why
and
whatever
the
next
group
of
people
are
contributors.
So
these
are
people
who
have
at
some
point
like
interacted
with
your
project.
Some
people
would
say,
people
who
file
issues
or
connect
in
tribute
is
I
would
personally
say
people
who
file
like
really
good
detailed
issues
are
connected
should
be.
There
is
someone
who
just
says
like
everything's,
broken
I,
don't
know
what
to
do.
B
It's
more
in
the
a
user
account
than
a
contributor
camp,
and
these
are
like
these
I
guess
and
github
like
these
are
people
who
may
submit
pull
requests
to
your
project,
but
they
don't
actually
have
complete
access
to
your
project
and
then,
finally,
on
home
Google,
we
call
these
maintained
errs.
So
these
are
the
people
who
do
have
commit
access.
B
Your
projects,
they're
the
people
who
interact
with
your
community,
who
review
and
merge
external
contributors
work
and
generally
are
kind
of
both
the
gatekeepers
and
the
people
who
are
probably
setting
the
direction
of
the
process
of
their
project
more
than
anyone
else.
Even
that
may
be
because
they
decide
on
what
goes
into
a
roadmap,
or
it
may
just
be
that
they're,
the
people
doing
the
bulk
of
the
work
and
what
they
work
on
gets
implanted
and
the
stuff
that
they
don't
work
on
doesn't
so.
B
The
next
thing
is
the
funnel.
So
there's
my
understanding
of
sales,
which
is
very
limited,
I
want
my
only
real
self
experience
is
I
once
had
to
do
a
sales
visit
when
the
president
sales
at
previous
company
was
ill
and
it
was
in
Germany
and
all
the
paperwork
was
in
German
and
I.
Don't
speak
any
German,
so
that
was
not
a
good
start
to
my
self
experience.
B
It's
probably
not
a
good
analogy
either,
but
my
understanding
of
like
what
sales
funnel
is
is
that
you
have
like
you
again
group
people
into
kind
of
categories
by
how
far
they
are
through
the
process.
So
at
the
top
you
have
kind
of
leads,
and
this
is
people
who
see
you
think
they
could
be
kind
of
interested
in
buying
your
product
and
but
they
maybe
not
had
any
interaction
with
them.
Yet
you
maybe
not
like
actually
sort
of
said
any
opinions
from
them
or
whatever
the
next
so
kind
of
prospects.
Again.
A
B
Is
that
these
are
people
who
you've
had
some
sort
of
interaction
and
they've
expressed
some
sort
of
interest,
but
they
haven't.
Given
you
that
credit
card
yet
and
then
at
the
bottom
you
have
sales,
which
is
when
things
have
actually
gone
through
and
they're.
You
know
people
who
have
given
you
some
money
and
the
transactions
complete
just
in
some
way,
so
I
kind
of
think
about
this.
B
In
the
same
way,
with
these
through
groups
we
had
before
so
in
any
project
you
have,
you
know,
you're
going
to
have
a
lot
more
users,
then
you
can
have
contributors
and
you
can
have
a
lot
more
contributors
for
way
that
you
have
materials.
When
you
start
a
project
yourself,
you
may
have
one
level
of
these
three
groups
and
that
one
person
may
be
you
em,
or
at
least
you
know,
someone
who's,
a
user
and
a
maintainer.
B
Hopefully,
as
projects
grow,
you're
going
to
have
more
more
users
that
come
along
and
what
I
see
projects
struggling
with,
sometimes
is
how
to
kind
of,
as
your
number
of
users
grows,
and
maybe
you're
not.
But
the
tribute
is
grows,
and
maybe
your
number
maintainers
goes.
How
do
you
keep
kind
of
feeding
into
that
pipeline?
What
are
the
things
that
successful
projects
do
to
get
people
from
one
stage
to
the
other,
so.
A
B
In
a
given
month
in
home,
brews
history,
we
have
about
5,000
contributors,
we
have
probably
five
and
a
half
thousand
six
thousand
but
I'm
going
to
assume
that
a
certain
number
of
them-
or
you
know,
Kubica
emails
or
whatever,
and-
and
we
have
at
the
moment
about
10
actively
maintained-
errs,
unlike
20
people
who
have
been
maintained
as
in
the
poll
so
in
the
kind
of
lifetime
of
the
project.
So
that
puts
the
number
of
contributors
at
like
1%
of
the
users
and
it
maintains
at
0.002%.
B
If
I,
my
math
is
correct,
which
is
probably
not
of
the
total
number
of
users
on
the
project.
So
that's
like
a
really
traumatic,
funnel
I.
Think
if
you
are
in
sales-
and
you
were
doing
something
like
those
type
of
numbers-
you
probably
not
doing
a
very
good
job
and
but
I
think
we
are.
We
consider
ourselves
at
least
like
relatively
successful
for
this,
and
one
of
the
things
that
I
think
kind
of
contributes
to
us.
Having
such
a
decent
number
of
these
contributors
is
what
we
do
to
try
and
like
upsell
people.
B
So
again,
another
sales
term
I,
don't
really
understand,
but
this
is
what
I'm
going
to
call
when
we
kind
of
push
someone
who
maybe
doesn't
want
to
between
one
of
these
levels
here.
So
our
first
kind
of
upselling
thing
that
we
try
and
do
is
if
we
get
like
a
random
Twitter
mention
then
trying
to
connection
because
people
don't
necessarily
have
a
gap,
account
people
don't
necessarily
aren't
familiar
with.
You
know
the
kind
of
open
source
software
a
way
of
like
soliciting
issue
reports,
so
you.
A
B
B
So
after
that,
if
you
have
someone
whose
files
like
a
relatively
good
issue
report-
and
you
know
they
seem
like
they're
kind
of
relatively
savvy
and
or
just
very
motivated
or
it's
a
problem-
that's
very
very
niche
and
just
affects
them.
They
obviously
care
about
a
lot
the
light.
No
one
else
really
does.
Then
we
try
and
like
push
them
towards
making
a
pull
request.
Again.
B
That's
another
wall
tax,
responder
matter,
I
use
when
I
see
these
type
of
issues
that
come
into
the
repository
or
I,
see
kind
of
people
commenting
in
a
certain
way
or
whatever,
and
we've
got
this
nice
little
document.
This
is
kind
of
a
a
subset
of
it
that
kind
of
tries
to
walk
people
through
step-by-step
of
how
to
submit
photographs
to
home
brew.
That's
actually
going
to
get
merged.
I
would
say
a
certain
amount
of
this
like
github.
B
It
should
be
making
it
easier
to
do
these
things
ourselves,
and
we
do
recognize
that,
but
I
think
it's
definitely
worth
documenting
your
project.
I'm,
not
assuming
necessarily
that
people
know
how
to
use
github,
but
assuming
they
know
how
to
use,
get
not
assuming
really
anything
and
or
kind
of
programming,
knowledge
or
whatever,
and
just
trying
to
make
it
as
easy
to
have
a
step-by-step
guide
for
people
as
you
can,
because,
ultimately,
if
so
on
those
all
these
things
already,
they
either
won't
read
the
document
or
they
can
kind
of
skim
through
it
really
quickly.
B
Whereas
if
someone
does
and
have
no
experience
with
this
stuff,
then
having
a
document
like
this
can
help,
you
know
get
a
natural
trust
pull
request
and
we
tend
to
see
reasonable
amount
of
uptake.
For
this.
You
know
at
least
I
would
say
maybe
fifty
percent
of
the
time
we
kind
of
approach,
something
like
this
and
ask
people
to
try.
B
So
again,
on
this,
we
have
a
like
a
nice
little.
We
try
to
open
source
of
all
our
kind
of
docs
for
this
stuff
and
we
have
our
nice
little
checklist
of
how
we
go
about
doing
that
process.
If
we
see
someone
who's
kind
of
contributing,
regularly
kind
of
high-quality
contributions
and
more
one
person
notices,
then
we
kind
of
charmix
ourselves
as
maintainer
as
we
have
like
a
private
slack
room
for
this
type
of
thing,
and
then
we
go
and
kind
of
send
them
an
email.
A
B
So,
like
always
be
thinking
about
these
changes,
you're
making
and
the
kind
of
organizational
structure
you
have
as
a
project
as
how
it's
going
to
repel
or
attract
people
who
are
either
maintainer
as
people
who
are
activities
or
people
are
users
so
slack
off
with
the
users,
and
the
thing
I
think
is
the
most
important
thing
for
any
software
project.
Really
is
users
care
about
the
project
working?
B
It
sounds
like
a
fairly
stupid
thing
to
say,
but
it's
surprising
how
many
projects
will
do
some
big
architectural
rewrite
or
some
big
thing
that
they
feel
is
really
useful
for
them
from
a
technical
perspective,
perhaps
or
an
organizational
perspective,
but
actually
demonstrably
makes
the
software
worse.
The
people
who
actually
use
it-
and
this
is
problematic
because
for
obvious
reasons,
those
organizational
changes.
Those
developmental
changes
are
actually
in
themselves
making
anything
for
the
users
they
may
in
the
longer
term,
make
it
easier
view
the
shift,
features
or
whatever.
B
But
if
you're
like
breaking
their
stuff-
and
they
just
want
to
be
able
to
use
the
software,
then
all
of
a
sudden,
your
users
go
and
find
some
other
piece
of
software
to
use
or,
if
they're,
more
technical,
go
and
start
a
replacement
to
yourself
where
they
actually
it's
like
all
the--
and
the
second
point
here,
I
wrote
a
pull
request
about
this.
So
I
wrote
a
blog
post
about
this
in
the
cata
blog
before,
and
it's
trying
to
make
the
point.
B
The
something
I
struggle
with,
particularly
in
the
early
days
of
homebrew,
is
the
side
effect
of
trying
to
upsell
people
and
getting
people
who
maybe
don't
have
a
super
technical
background.
To
try
and
create
pull
requests.
Is
that
sometimes
you're
going
to
work
and
work
and
work
and
get
to
a
point
where
you
realize
there's
actually
no
way
with
this
person
we're
going
to
get
a
pull
request?
B
That's
high
enough
quality
to
get
into
the
project
and
in
the
early
days,
for
some
of
the
stuff
I
would
go
and
end
up
merging
some
of
this
stuff
anyway,
because
I
felt
so
bad
after
having
this
person
put
in
so
much
time.
Having
me
put
in
so
much
time
so
bad
to
not
have
anything
to
show
for
it
in
the
project
itself,
so
I
would
merge
this
stuff
and
then
like
in
the
long
term.
It
produces
all
these
type
of
issues.
B
You
like
that,
but
also
like
trying
to
deal
with
that
in
a
way
that
you
can
think
about
the
wider
user
base
and
not
just
the
individual
who
is
currently
upset
that
their
work
and
get
it
cleared
and
the
first
one
that's
the
final
one.
Sorry
that's
maybe
a
little
bit
contentious
is
in
homebrew
at
least
we've
taken
this
ethos
of
no
2.0.
We
had
a
document,
I'm
sure
a
lot
of
projects,
habits
and-
and
we
have
a
lot
of
documents
inside
github
as
well.
B
B
B
Questions
and
really
complex
like
architectural
issues,
then
you
won't
get
a
lot
responses.
If
you
ask
someone
what
caused
the
bike
search
should
be
like
everyone
can
shipping.
This
is
a
barrier
to
entry
on
that
discussion.
It's
so
low
so
like
trying
to
keep
kind
of
conversations
fairly
focused
and
trying
to
not
solicit
eight
million
opinions
on
anything
where
people
can
chip
in
I
think
is.
It
helps
your
project
become
a
bit
more
focused
and
helps
contributors,
stay
motivated
and
similarly
having
somewhere
that
people
can
have.
These
conversations
is
valuable.
B
The
reason
for
this
being,
as
I
mentioned
before
you
have
maintainer,
is
who
are
the
people
who
end
up
being
the
bulk
of
the
work
and
unless
a
maintainer
is
actively
working
with
your
feature,
and
none
of
embryo
containers
are
paid
to
work
on
homebrew,
unless
one
of
them
is
passionate
enough
to
build
it
or
external
contributors
passion
enough
to
build
it
chances.
Are
this
isn't
going
to
get
built?
B
If
you
call
someone
out
and
say
hey,
this
is
not
appropriate,
so
our
code
of
conduct
they'll
just
apologize
immediately
and
the
other
percent
of
time
they
might
quibble
a
little
bit
and
the
0.1
percent
the
time
they
get
very
overexcited
and
start
shout
at
you
on
Twitter
or
whatever,
in
which
case
it's.
You
know,
I
feel
like
those
people
were
telling
bottoms
anyway,
so
it's
better
to
just
get
them
out
your
project
and
another
one.
B
If
you're
kind
of
resolving
interpersonal
conflicts
between
maintain
users
to
have
that
privacy
to
be
able
to
do
that,
and
and
the
last
thing
which
I
guess
is
the
the
whole
thing
that
this
whole
talk
is
about
is
trying
to
have
your
project
be
always
growing.
The
thing
that
really
gets
maintained
is
down
and
helps
burn.
People
are
more
than
anything
else,
I
think
it's
the
sense
that
they
can't
go
on
vacation.
B
They
can't
leave
the
project
for
six
months
or
whatever,
because
if
they
do,
the
project
will
die
and
always
trying
to
make
sure
of
no
matter
what
stage
of
projects
out
that
you're
getting
more
and
more
people
contributing
more
more
people.
Maintaining
and
just
trying
to
like
build
that
up
is
I,
think
the
safest,
long-term,
the
safest
thing
long
term
for
your
project
success
to
ensure
that
your
project
will
not
die
if
one
person
decides
them.
These
are
very
quite
now,
and
giving
people
space
to
have
breaks
is
a
good
thing
to
do
so.
B
I
walked
through
these
kind
of
four
things.
Briefly,
like
remember,
you
want
to
prove
your
users
in
two
categories.
Maybe
my
categories
are
not
the
ones
you
want
to
do,
but
it's
still
a
good
way
to
cement
people
to
think
about
things.
Think
about
how
you
can
funnel
people
from
the
top
to
the
bottom,
by
kind
of
upselling
them,
maybe
with
level
kind
of
templates
to
kind
of
push
them
in
the
right
way
and
lots
of
dogs
and
stuff.
B
Like
that
and
then
finally
think
about
when
you
have
people,
who've
moved
from
being
a
user
to
a
contributor
or
contributing
a
maintainer,
how
you
can
keep
them
where
they're
meant
to
be
and
like,
hopefully
contributing
to
your
project
nicely
and
enjoying
working
with
you
and
you
enjoying
working
with
them.
So.
A
B
The
gist,
so
what
I
want
to
tell
you
and
we're
not
doing
questions
right
now,
but
you
can,
if
you
want
to
talk
about
managing
a
healthy
github
community,
or
this
contributes
and
funnel
stuff
or
anything
related
to
homebrew,
then
find
me
afterwards,
I'll
be
around
or
on
Twitter
or
send
me
an
email
or
whatever.
So
thanks
very
much.