►
Description
Presented by
Evan You, Project Lead, Vue.js
Gina Häußge, Project Lead, OctoPrint
Wes McKinney, Director, Ursa Labs
Sasha Rosenbaum, Senior Product Manager, GitHub
Most technologies built today rely on the work of open-source maintainers. In addition to building highly-valued open source projects, maintainers put in long hours to build software, fix issues, field questions, and manage communities—all while figuring out monetization strategies to sustain their technologies. In this session, you’ll hear from three leaders whose meaningful contributions to the open source ecosystem have become full-time careers. We’ll dive into their lessons learned, discuss the burnout maintainers often face, and share how other developers can prevent and overcome those challenges, solve for monetization challenges, and build healthy, sustainable habits in open source.
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
Hi
everybody-
I
am
sasha
rosenbaum,
I'm
a
product
manager
here
at
github,
and
it
is
my
absolute
pleasure
today
to
host
a
panel
on
managing
boundaries,
balance
and
funding
in
open
source
if
you've
been
watching
github
universe
sessions.
Today
in
the
previous
couple
of
days,
you
know
that
the
world
is
largely
powered
by
open
source,
but
you
also
know
that
open
source
is
not
necessarily
easy
to
get
started
with
or
easy
to
get
into
manage
and
so
on
and
so
forth.
A
A
This
panel
is
for
you,
and
here
we're
talking
with
some
really
great
open
source,
maintainers
gina,
hoyske,
evan,
yeoh
and
wes
mckinney,
and
these
discussions
actually
started
with
the
github
readme
project,
where
we
learned
a
little
bit
about
each
of
the
maintainers
and
had
a
flavor
privilege
to
hear
some
of
their
stories,
and
we
just
wanted
to
bring
it
out
over
to
you,
and
you
can
also
look
it
up
at
github.com
readme
to
read
more
about
each
one
of
our
panelists.
So
with
that,
I
will
let
my
panelists
introduce
themselves
so
gina.
B
C
D
B
I
would
say
it's
like
a
bit
of
a
mixture
of
being
a
gardener,
a
parent
and
an
architect.
At
the
same
time,
on
the
one
hand
you
have
to
take
care
of
your
code
and
make
sure
it
grows,
and
all
that
you
have
to
educate
your
users
and
sometimes
also
resolve
some
struggles
or
something,
and
also
of
course,
you
have
to
build,
build
new
things.
D
Yeah,
I
also
think
it's
it's
a
hybrid
role.
I
I
I
myself
think
of
it
as
a
cross
between
a
librarian
and
a
cat
herder.
So
partially,
you
know
my
my
job
is
to
keep
all
of
the
information,
the
road
map
and
the
issue
tracker.
You
know
organized
and
orderly,
so
that
people
can
arrive
and
make
successfully
make
contributions
to
the
project,
while
also
making
sure
that
that
all
of
the
contributors
and
other
maintainers
are
are
being
productive
and
and
that
the
whole
project
as
a
whole
is
healthy
and
making.
C
Yeah
I
share
pretty
much
the
same.
I
think
gina
and
wes
made
a
lot
of
good
metaphors
that
I
like
completely
agree
with,
I
think
in
the
beginning,
I
was
mostly
just
writing
code,
but
as
the
community
grows,
you
naturally
have
to
deal
more
with
sort
of
coordinating
efforts
in
the
community
trying
to
make
make
sure
the
community
is
a
good
one.
A
So
a
lot
of
code
writing,
maybe
but
also
a
lot
of
sort
of
managing
people,
managing
the
project
and
being
a
kindergarten
teacher
of
of
all
the
things.
So
I
know
all
of
you
had
very
interesting
journeys.
How
would
you
describe
a
typical
journey
from
consumer
to
contributor
to
maintainer
in
open
source
and
gina?
Let's
start
this
one
with
you.
B
I
think
mine
is
probably
a
pretty
typical
one,
so
the
way
that
I
got
heavily
interest
into
open
source
was
that
back
in
2012,
I
got
myself
a
3d
printer
and
it
was
sitting
in
my
office
producing
noises
producing
fumes
and
I
just
wanted
it
wanted
it
out
of
my
office
again
and
still
be
able
to
monitor
it
remotely.
So
I
had
this
itch
that
I
needed
to
scratch.
C
Man,
it's
almost
the
same
again,
because
I
always
also
scratched
my
own
itch.
I
was
working
on
these
very
projects
with
very
fast
turnaround
and
I
was
like
I
want
a
very
smooth
framework
that
you
know
fits
my
mental
model
that
I
can
feel
productive
with.
So
I
essentially
wrote
my
own
and
turns
out
a
lot
of
other
people
liked
it
too.
So
it
kind
of
grew
into
this
thing
today.
A
So
this
is
interesting.
You
start
with
the
project
that
you
care
about
and
then
eventually
the
community
comes
and
joins
you
and
it
grows
into
a
full-blown
framework
that
people
have
conferences
about.
That's
so
cool
so
in
terms
of
this
is
a
very
interesting
question,
because
I
think
people
have
arguments
about
this
all
the
time,
but
what's
the
importance
of
known
cod
node
non-code?
Oh
my
god,
contributions
to
your
particular
project
and
wes
would
I
would
like
to
start
this
with
you.
D
Yeah
I
mean
non-code,
contributions
are,
are
extremely
important
and,
I
would
say,
highly
highly
underrated.
One
of
the
things
that
I
spend
the
most
time
doing
as
a
contributor
and
a
maintainer
is,
is
you
know,
gardening,
the
issue
tracker
so
organizing
the
reports
that
come
in
getting
more
information
from
the
from
the
issue.
D
Reporters
closing
out
duplicates
connecting
issues
together,
setting
their
metadata
because,
ultimately,
a
project
that
is
that
is
well
organized
and
and
where
we
have
as
much
information
as
possible
about
the
the
bug
reports
of
the
future
requests
that
come
in
is
going
to
make
it
that
much
easier
for
people
to
jump
in
and
make
and
make
contributions
and
very
little
of
that
process.
You
know,
results
in
pull
requests
or
commits
landing
in
in
the
main
branch.
So
it's
it's
very,
very
important.
C
Oh
definitely
non-code
contributions,
I
would
say,
are
equally
critical
compared
to
code
contributions
like
documentation
is
very
important.
The
thing
is
when
you,
when
you
contribute
to
documentation,
it
ends
up
being
this
shared
knowledge
that
benefits
everyone
that
comes
after
you
and
also
community
engagement,
say
event,
organizers,
meetup
organizers,
conference
organizers.
They
also
do
a
great
service
to
the
community
by
connecting
people
together.
A
A
So
actually,
newbies
have
a
very
important
role
to
play
in
writing
code.
Documentation
is
what
I'm
hearing
and
that
is
super
encouraging
and
again,
I
would
encourage
anybody
who
wants
to
start
contributing
to
open
source
to
start
with
the
docs,
because
I
think
this
is
a
very
easy
way
to
get
started
and
kath.
Actually,
our
our
host
for
today
actually
just
went
through
the
journey
of
open
sourcing,
github
docs,
which
enables
the
whole
community
to
collaborate
with
us
on
that
work
for
helping
everybody.
A
B
So,
for
example,
when
they
start
calling
people
names
or
just
are
going
starting
to
show
some
kind
of
attitude
that
is
not
yeah,
let's
say
not
productive
to
the
whole
discussion
and
all
that
and
usually
simply
telling
them
that
they
are
crossing
a
boundary
here
and
are
doing
something
that
is
not
welcome,
will
either
make
them
go
away
or
make
them
apologize
and
become
a
good
citizen.
Of
course,
that
is
not
always
the
case,
but
at
least
so
far,
my
experience
with
this
approach
has
been
fairly
good.
C
Yeah,
I
think
there
are
two
types
of
toxic
cases
I
think
like.
For
example,
one
k,
one
type-
is
some
random
user,
just
being
really
rude
in
a
github
issue
or
a
pull
request,
and
in
those
cases
I
mean
I,
I
kind
of
gotten
used
to
it.
If
they
repeatedly
do
this
or
just
block
them
thanks
to
the
block
feature.
D
I've
been
I've
been
lucky
to
not
have
to
deal
with
it
too
often,
but
in
in
the
handful
of
instances
you
know,
I
think
it's
it's
very
important
to
to
bring
people.
You
know
back
to
your
code
of
conduct
and
what
we
you
know
deemed
to
be
good
behavior
in
the
project.
To
say
very,
you
know
very
firmly
like
we
don't
do
that
here,
but
I
think
it's
also
important.
You
know
to
understand.
You
know
some
of
the
you
know
what
causes
the
the
toxic
behavior.
D
A
It's
I
read
it
recently
somewhere
about
like
toxic
behavior
is
about
setting
boundaries
right,
so
it's
not
just
about
the
pers,
the
toxic
person
being
toxic.
It's
also
about
you
telling
them.
This
behavior
is
not
accepted
here.
So
I
I
feel,
like
we
all
know
the
answer
to
this
question,
but
have
you
ever
experienced
burnout
and
what's
your
strategy
to
deal
with
that
and
wes?
Let's
get
us
started.
D
D
So
you
care
so
much
about
this
project
and
this
community
that
you're
involved
with
that
it's
inevitable
that
it
will
that
there
will
be
end
up
being
more
work
than
you
can
personally
handle
and
so
you're,
rather
than
choosing
you
know
what
you're
successful
at
it
feels
like
you're
choosing.
You
know
what
you're
going
to
fail
at
and
so
and
you're
also
exposed
to
a
lot
of
negative,
one-sided
negative
feedback
about
the
project,
bug
reports
and
performance,
regressions
and
people
being
frustrated
about
different
things.
D
And
so
you
know
it's
important
to
remind
yourself
that
that
you
know
project
can't
succeed
or
fail
on
the
basis
of
the
efforts
of
one
person,
and
so
you
have
to
you
know,
forgive
yourself
and
make
some
space
and
make
sure
you're
taking
care
of
yourself
mentally
and
physically,
and
trust
that
that
you
know
trust
that
the
community
will.
That
will
we'll
step
in
to
to
to
do
what.
What
needs
to
be
done.
You
know:
take
care
of
the
most
important
parts
of
the
project.
C
Yeah,
I've
definitely
been
through.
You
know,
phases
where
I
seriously
question
why
I'm
not
doing
this,
but
I
think
a
lot
of
the
stress
comes
from
just
this
constant
influx
of
problems
that
people
are
telling
you
with
and
where
maintainers
are
like
exposed
or
like
major
majorly
to
these
negative
information.
C
So
I
think
one
of
the
tricks
I
did
is.
I
essentially
started
pulling
instead
of
being
pushed
these
information,
so
I
try
to
you
know,
have
a
pretty
strict
work
hours
only
look
at
emails
when
I
want
to
only
look
at
issues
when
I
want
to.
Instead
of
you
know,
whenever
an
issue
comes
in,
I'm
going
to
rush
to
solve
it,
that's
just
not
sustainable.
C
A
It's
yeah,
I
I
feel
like
especially
for
people
who
manage
to
be
full-time,
open
source
maintainers.
It
sort
of
becomes
the
same
thing
as
managing
your
full-time
job
right,
remember,
to
take
vacations
as
well,
and
don't
think
that
you
always
have
to
be
available
whenever
someone
has
a
problem
gina.
I
happen
to
know
your
answer
to
this
question.
But
what
do
you
do
to
manage
burnout.
B
So
I
think
it's
really
really
important
that
we
also
make
it
part
of
our
job
to
take
good
care
of
ourselves,
because
probably
no
one
else
will-
and
that
means
obviously
also
taking
vacations
allowing
ourselves
sick
days
off
and
all
that
so
yeah,
just
basically
full
agreement
to
everything.
That's
already
been
said.
A
So
I
think,
after
watching
this
stream,
it
may
be
that
a
lot
of
people
are
going
to
buy
punching
bags
and
install
them
in
their
offices
right
now,
especially
with
all
the
you
know,
virtual
stuff
going
on
and
where
you
can't
actually
vent
to
real
human
beings
around
you.
So
I
got
another
question,
which
is:
how
can
the
community
help
you
help?
You
manage
work
hours,
help
you
manage
burnout
and
help
you
kind
of
have
positive
experiences
around
your
open
source
project
and
gina.
B
Evan
already
gave
an
example
of
this
that
we
usually
primarily
see
the
negative
things
and
only
hear
the
negative
stuff,
and
this
is
also
something
that
I
observe
with
octoprint
there's
this
huge
silent
majority.
That
is
completely
happy,
apparently
with
what
I'm
doing
and
then
there's
this
side
at
this,
this
very
vocal
minority
that,
whenever
something
breaks
or
they
have
a
problem,
they
become
very
loud
and
scream
at
me.
B
A
C
I
think
the
most
validating
moments
were
actually
at
offline
events,
so
before
the
pandemic,
we
had
quite
a
few
offline
conferences,
view
conferences
that
I
went
to
personally
and
at
the
after
parties.
People
would
actually
come
up
to
me
and
say
thank
you
in
person.
I
think
those
are
the
moments
where
I
felt
like
this
is
totally
worth
it.
You
know
all
the
work
paid
off.
Unfortunately,
we
can't
do
this
anymore,
at
least
for
now,
but
I
really
hope
like
we
can.
A
So
it
sounds
like
some.
You
know
we
have
navigated
into
virtual
world
and
created
some
alternative
to
that
experience,
so
kind
of
like
tweets
and
and
positive
messages.
Right
I
say:
let's
send
your
favorite
open
source,
maintainer,
a
a
holiday
card
or
some
money
via
github
sponsors.
You
all
encouraged.
Do
that
so
important
question
sort
of
a
good
segue
into
that
and
how
did
your
project?
Actually
you
figure
out,
monetization,
so
gina,
let's
start
with
you,.
B
I'm
actually
not
sure
if
I
really
have
figured
it
out,
I
figured
it
out
or
if
there
is
anything
specific
to
figure
it
out
figure
out
right,
because
there
is
no
code
to
crack
or
something
like
that.
In
my
case,
it
was
I
I
I
had
to
somehow
find
a
way
to
continue
to
work
on
octoprint
full-time,
and
so
I
tried
crowdfunding
it.
B
It
worked
in
my
case
at
least
so
far,
but
it
could
also
just
as
well
not
have
worked,
and
I
sometimes
get
question
from
people
who
also
try
to
do
that
like
if
I
have
any
tips
for
them,
and
I
I
usually
just
track
my
my
shoulders,
because
I
I
don't
know
I
I
think
there
is
no
real
do
this
and
then
you
will
have
success
kind
of
recipe
there.
It's
just
yeah,
hoping
for
the
best.
C
So
so,
first
of
all,
I
think
every
project
is
different
in
terms
of
monetization.
It's
like
a
thousand
open
source
projects
is
like
a
thousand
startups
with
completely
different
business
models,
so
you
kind
of
have
to
think
of.
If
you
want
to
monetize
the
project
you
kind
of
have
to
think
about
it
from
a
you
know,
a
product
perspective.
What
are
the
values
people
are
getting
out
of
it
and
how
can
you
sort
of
funnel
that
back
into
the
project
so
specifically
for
vue?
C
It's
it's
simply
because
we
have
so
many
users
that
we
we
figure
out.
You
know
I'm
mostly
doing
crowdfunding
as
well
and
because
view
is
a
pretty
high
exposure
project,
but
that
might
not
work
for
certain
types
of
projects
so
that
that,
as
gina
said,
there
is
really
no
universal
code.
That
applies
to
everything.
D
I
apologize
all
right.
I
had
some
construction
in
the
background
I
in
in
the
past,
I've
relied
on
work.
You
know
working
on
open
source
projects
as
part
of
my
job,
but
in
recent
times
I've
been
fortunate
to
have
corporate
industry
sponsorships
and
for
me
it's
really
been
about
articulating
that
that
that
it
makes
sense
to
to
to
fund
the
development,
because
they're
investing
in
the
ecosystems
that
they
that
they
depend
on
and
enabling
the
the
contributors
and
maintainers
to
do
their
to
do
their
best
work.
A
And
I
think
so
again
and
we
announced
the
corporate
sponsors
corporate
sponsors
at
this
conference,
and
I
think
I
hope
that
this
is
going
to
be
really
helpful,
because
now
enterprise
companies
can
support
open
source
maintainers
for
projects
that
they
rely
on
through
their
existing
building
relationships
with
github,
which
should
make
it
a
lot
easier
for
certain
in
certain
cases.
So
I
I
guess
we
are
coming
up
on
on
talking
about
the
important
part
of
this
conversation
which
is
trying
to
predict
the
future.
A
D
And
so,
if
we
want
to
enable
the
ecosystem
to
continue
to
innovate,
it's
going
to
require
a
significantly
more
funding.
In
particular,
you
know
enabling
more
people
to
work
full-time
on
open
source
projects
to
make
their
their
work
more
sustainable.
To
have
less
you
know
less
contributor
and
maintainer.
D
A
And
I
think
sort
of
I
will
plug
in
with
something
that
we've
had
a
lot
of
discussions
about
in
the
last
few
days,
which
was
like
open
source
is
open
source.
It's
not
necessarily
free
right.
We
still
have
people
working
on
open
source,
contributing
to
it
every
day
and
those
people
got
to
eat
something
and
these
people
got
to
get
funded
and
so
just
being
entitled
like
acting
entitled
to.
I
have
all
the
open
source
software
in
the
world
for
free
doesn't
really
help
the
maintainers
evan.
What
about
you?
C
C
Big
companies
have
access
to,
but
individuals,
it's
a
hurdle
that
they
have
to
jump
over
themselves
and
if,
if
we
can
have
you
know
a
financial
infrastructure
that
just
you
know,
reduces
the
friction
for
people
to
do
this
kind
of
stuff.
I
think
it'll
help
a
lot
in
the
future
like
efforts
like
open,
collective
and
github
sponsors,
I
think,
are
good
efforts
in
this
direction.
B
B
Some
kind
of
of
com
community
shift
also
happening
in
that
regard,
that
this
becomes
also
more
normal
in
the
open
source
community,
because,
like
evan
said,
we
have
way
more
small
projects
with
that
add
a
lot
of
value,
but
are
helped
by
only
a
very,
very
small
amount
of
people
and
those
people,
like
you,
said
sasha
do
have
to
eat.
So
it
would
be
really
great
if
yeah
in
five
or
ten
years,
when
we
meet
again,
we
can
say
hey
that
worked
out.
A
Yes,
so
so
I
think
that,
like
there's
a
similar
vein
coming
from
everybody,
and
that
is
that
we
could
have
all
the
innovation
in
the
world
powered
by
millions
of
people
collaborating
on
things
right,
but
we
do
have
to
figure
out
the
way
to
fund
this
community
effort
as
well
to
enable
people
to
essentially
keep
doing
the
good
work.
So
we're
coming
up
on
time.
And
for
closing.
D
Yeah
I
mean
once
one
small
thing
you
can
do
is
to
talk
to
your
talk
to
your
managers
about
how
you
can
allocate
budget
to
to
support
open
source
projects.
It
could
be.
You
know
something
like
larger
budget
items
like
larger
sponsorships
or
even
something
so
simple
as
every
engineer
having
an
allowance
for
monthly
allowance
for
github
sponsors,
so
you
can
choose
which
which
projects
you
you
want
to.
You
want
to
sponsor.
C
A
B
A
Thank
you
so
much.
Thank
you
to
all
of
you
for
being
with
us
today.
This
was
a
tremendous
panel
as
a
reminder
we're
all
going
to
be
in
discussions,
answering
questions
for
the
next
half
an
hour,
and
you
can
also
read
more
about
it
in
github
readme
project
and
please
find
our
maintainers
on
twitter
on
github
and
send
them
a
holiday
card
and
send
them
a
thank
you
note
for
doing
all
the
good
work.
Thank
you.