►
From YouTube: How to compete with open source—and win - Universe 2022
Description
Presented by: Shawn Wang
Even though open source has been so transformative, it’s still only a little over 20 years old, and there are still many unsolved problems with building, scaling, and funding open source communities. Airbyte is disrupting the previously tightly controlled data integration industry by building—and paying—the largest community of data connectors in the world. If you're a founder or someone looking to get paid to contribute to open source with GitHub Sponsors, this session will give you some highlights of working with React, Svelte, Temporal, and Airbyte in just 5 minutes.
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
A
T
and
we're
talking
about
the
open
source
monolith
today,
my
subtitle
or
alternative
title
is
why
we
need
maintainers.md.
So
this
is
a
quote
from
a
friend
of
mine,
Pedro
Nock,
who
is
a
maintainer
of
docs,
which
is
one
of
the
major
react
ecosystem
component
libraries
says:
sorry,
everybody
I
failed
in
order
to
develop
docs
I
needed
to
wake
up
every
day
three
hours
earlier
and
go
to
bed
three
hours
later
and
he's
a
family
man.
A
A
The
central
motivation
of
this
talk
is:
does
this
sound
like
a
sustainable,
open
source
culture
and
what
can
we
do
about?
It?
I
think
that's
something
that's
worth
discussing
and
published
a
blog
post
with
github's
readme
project
it
and
I
think
they
invited
me
here
to
share
with
you.
The
first
thing
to
tackle
is
the
biggest
problem
is
funding.
That
is
the
first
thing.
Everyone
says,
if
only
we
paid
enough,
then
open
source
would
be
solved.
A
That's
what
a
lot
of
people
are
working
on,
patreon,
open,
Collective,
GitHub,
sponsors,
I,
think
there's
other
donation
based
organizations
that
I
that
I
haven't
included,
then
there's
also
git
coin
with
bug,
bounties
and
then
there's
also
support
and
training
businesses.
All
these
are
interesting
models.
Probably
the
most
lucrative
model
is
probably
the
VC
approach,
but
also
that
has
run
into
issues
where
what
started
as
open
source
eventually
either
became
closed
Source
or
got
re-licensed
into
something.
That's
not
strictly
OSI,
approved
and
ultimately,
I.
A
Think
if
you
explore
that
in
introspect,
there's
a
few
angles
about
this,
where
I
feel
like
the
financial
Dimension
isn't
enough,
so
we'll
go
through
a
little
bit
of
that
a
money
doesn't
solve
burnout.
Only
the
high
visibility
stuff
gets
any
attention
and
gets
all
the
money.
The
low
visibility
stuff,
the
stuff
that
is
critical
or
boring,
actually
gets
the
least
of
my
attention,
because
the
open
source
system
is
huge.
How
are
we
going
to
do
that
without
any
bias?
If
we're
going
to
try
to
automate
this,
it's
already
a
non-starter.
A
Every
single
metric
has
been
gamified
to
pieces
and
there's
no
fair
way
to
decide
without
human
intervention
and
then
also
allocation
of
the
funds
by
webmetric
right.
You
can
look
at
the
number
of
contributors
out
there,
equal
weight,
all
of
them,
but
obviously
some
are
going
to
be
contributing
a
lot
more
than
others.
A
Here's
a
picture
of
one
such
example:
usually
most
projects
have
one
super
dedicated
person
and
then
people
who
just
drop
in
and
out
and
then
finally,
even
if
you
pay
the
best
like
just
from
existing
data,
the
top
projects
in
the
world
are
already
well
below
Market
salary.
For
that
project,
there's
a
generational
Dynamic.
A
That's
something
that's
a
kind
of
unsustainable
and
unspoken
in
our
industry,
so,
ultimately,
what
we
need
to
figure
out
is
what
we
call
the
open
source
contract.
Typically,
the.
When
people
talk
about
the
open
source
contract,
they
talk
about
the
license,
which
is
the
legal
contract,
but
here
I
think
what
is
underexplored
or
what's
sort
of
the
question
mark
is
the
social
contract
of
Open
Source
and
that's
something
that's
underdeveloped
and
clearly
insufficient
in
in
terms
of
keeping
the
open
source
ecosystem
going
and
open.
A
I
think
the
closest
analogy
I
can
bring
is
what
we
think
about
when
we
think
about
the
developer.
Full
stack
all
of
us
here
as
developers.
We
have
a
much
more
introspection
into
this
industry
than
most
other
disciplines
as
developers.
We
see
a
lot
of
differences.
Here's
a
here's,
a
stack
which
I,
which
I
dreamed
up
inspired
by
The
OSI
layer
model
where
it
goes
from
firmware
developers
all
the
way
to
framework
developers,
language
developers,
Cloud
developers
and
all
the
way
up
to
low
code
and
no
code
developers.
A
All
these
are
different
types
of
jobs
requiring
different
kinds
of
skill
sets.
There's
no
expectation
ever
that
we
would
be
full
stack
in
every
single
thing
has
to
do
from
Human
to
machine.
So
that's
something
that
we
definitely
want
to
see,
which
is
why
should
open
source
maintainers
be
full
stack?
That
is
the
real
question
that
we're
addressing
here
today.
Can
we
break
apart
the
stack
so
before
I
go
into
my
solution
on
my
theories?
A
How
contributor
growth
versus
low
contributor
growth
a
lot
of
the
largest
highest
dependency
and
low
Prestige,
but
a
lot
of
emotional
baggage
projects
do
tend
to
be
stadiums
where
there
are
a
lot
of
users
but
very
low
contributors,
and
that
is
the
fundamental
imbalance
that
concerns
a
lot
of
people,
because
those
tend
to
be
the
very
critical
projects
that
don't
get
enough
love,
and
so,
if
you
really
break
it
out,
you
can
sort
of
break
out
all
the
jobs
to
be
done
of
maintainers.
So
it
goes
everything
from
issue
triage
to
bug.
A
Reproduction
PR
review
user
support,
blah
blah
blah
user
support
is
my
favorite
one
by
the
way,
because
people,
when
they're
using
your
library,
they
actually
don't
know
if
there's
a
bug
with
the
library
or
if
they
bug
their
understanding
and
you
as
the
maintainer,
you
have
to
say
like
did
you
try
this?
Did
you
try
that,
like?
What's
your
operating
system
version?
Did
you
use
it
with
a
compatible
library?
And
often
people
won't
read
the
docs?
A
So
then
you
then
you
have
to
you
know,
do
a
lot
of
the
work
of
support,
which
is
a
real
job,
that
people
are
paid
for
all
the
way
down
in
design,
marketing,
product
manager,
blah
blah,
and
then
oh,
don't
forget
that
you
have
to
code
as
well
right.
You
started
out
with
this
open
source,
Library
writing
code,
but
then
you
ended
up
signing
up
for
all
this
stuff,
as
as
a
result
of
the
social
contract
of
Open,
Source
and
and
that's
a
that's,
a
really
heavy
expectation.
A
So
what
I
think
we
can
do
is
we?
Can
we
don't
have
to
reinvent
everything
from
scratch,
I
think
in
Tech
we
have
a
tendency
to
have
a
not
invented
here
syndrome
for
Tech,
but
also
not
invented
hair
syndrome
for
social
contracts.
We
don't
have
to
reinvent
from
first
principles
everything
because
we
have
a
lot
of
examples
right.
Software
is
180
years.
Old,
open
source
is
40
years
old,
but
social
contracts
are
a
thousand
years
old.
Humanity
has
worked
out
a
lot
of
ways
over
time.
A
We're
not
perfect,
but
we've
learned
a
lot
of
lessons,
and
maybe
we
could
try
looking
outside
of
tech
for
fixing
these
social
contract
issues
rather
than
looking
inside
of
tech
and
trying
to
fix
it
with
money.
Some
examples
that
inspire
me
are
social
clubs.
This
is
maybe
a
little
bit
of
an
old
school
thing.
No
one!
No
one
does
that
anymore,
I'm
inspired
by
the
yacht
clubs
and
the
Social
Clubs
of
my
past,
where
people
serve,
you
know
it's
not
perfect
in
its
own
way.
A
Another
way
it's
government
very
similar,
but
with
formal
legal
power
where
your
budget,
you
prestige,
your
service,
all
sorts
of
motivations
that
are
not
monetary
related
but
defines
and
well
thought
through
forms
of
government,
and
essentially
that
is
a
form
of
service
to
a
community
and
really
ultimately
you're
going
to
think
about
what
drives
people,
that's,
ultimately,
what
we're
driving
at
right,
so
status,
power
impact,
Legacy,
Community,
Services,
Freedom.
All
the
way
at
the
bottom
is
money
if
you're
tempted
to
bring
up
Maslow's
hierarchy
of
needs,
I
would
like
to
just
share.
A
People
have
actually
modified
the
mastles
hierarchy
into
a
boat
where
the
top
half
is
more
about
growth
and
positive
development.
Bottom
half
is
about
lack
of
downside,
so
mitigating
your
risks
and
having
Securities
I
think
that's
a
really
good
way
to
think
about
it.
But
really
you
know
you
want
to
provide
aspirational
things
that
motivate
people,
because
a
lot
of
developers
have
their
core
needs.
Secure.
The
three
elements
that
I
really
think
that
we
can
steal
one
elections
are
fixed
terms.
There's
no
reason
you
should
be
a
benevolent
dictator
for
life.
A
If
you
just
started
an
open
source
project
and
because
there
is
no
pdfl,
if
there
is
no
pdfl,
then
people
with
a
stake
in
the
projects
can
actually
run
for
office
and
and
try
to
have
some
ownership
instead
of
saying,
don't
bother
because
there's
bdfl,
that's
how
things
are
they'll,
never
touch
again.
I
won't
even
try
give
people
hope
and
they'll
at
least
do
something
with
it.
Second,
real
budgets
with
public
accountability,
we
do
I'm,
not
saying
money
is
not
part
of
the
solution.
A
My
money
is
a
part
of
solution,
but
we
need
to
balance
it
with
Audits
and
open
meetings.
Finally
separate
responsibilities:
that's
probably
the
the
biggest
proposal
here,
which
is
to
split
it
up.
Instead
of
one
person
being
the
full
stack
maintainer
setting
it
up
into.
You
know
different
roles
that
we
eventually
Define
as
a
community
to
limit
expectations
and
increase
the
community.
One
of
the
resources
I
consulted
was
actually
complaining
about.
I
was
just
talking
about
how
maintenance
and
open
source
can
be
a
very
lonely
Index.
This
is
not
enough.
A
Community
around
it,
basically
encouraging
materials
as
well
to
say,
like
there
are
these
different
roles.
We
set
these
set.
These
Norms
there's
always
a
place
for
people
who
want
to
step
up
in
a
limited
way
and
defining
that
limited
way
is.
Is
the
bulk
of
the
community
work
that
we're
doing
here?
How
do
we
do
this
we're
going
to
get
into
human
files?
A
What
are
human
files
glad
you
asked
so
a
short
history
of
human
files
2012
10
years
ago
we
had
contributing.md
also
pioneered
by
GitHub,
which
is
fantastic,
and
then
code
owners
done
md5
years
later
architecture.md.
All
these
are
ways
in
which
we
document
our
code
for
humans.
Just
like
write
code
for
machines,
2016
outside
of
code,
human
files
in
2016.
A
We
also
had
the
all
contributors
standard
come
along,
which
is
essentially
a
bot
and
a
standard
recognizing
33
different
kinds
of
contributions,
a
little
bit
too
many
for
my
taste,
because
there's
just
too
many
to
keep
in
your
head,
but
then
in
2019.
One
of
the
interesting
things
was
that
it
was
this.
One
of
these
roles
was
built
into
GitHub,
and
this
is
a
GitHub
feature
that
is
not
still
not
super
well
known.
I
have
to
tell
people
about
it
where
you
can
actually
offer
triage
and
maintain
roles
that
are
not
admin.
A
They
are
not
read,
write
to
to
contributors
right,
it's
a
special
status
and
the
problem
is
GitHub.
Doesn't
do
enough
yet
to
to
promote
this,
so
it's
probably
not
very
well
used
because
most
people
don't
know
about
it.
So
that's
the
short
history
of
human
files
and
really
what
I
think
could
be
something
that
we
do
going
forward
is
maybe
some
kind
of
maintainers
not
MD.
The
file
actually
doesn't
matter.
It's
I'm,
not
I'm,
not
like
I.
Don't
want
you
to
overly
focus
on
the
file.
A
It's
more
about
the
separation
of
concerns
of
maintainers
right
having
a
tech,
lead
documentary,
an
issue
in
PR,
triage
Community,
Builder,
project
manager,
user
research,
quality
assurance.
There's,
there's
a
lot
of
essentially
informal
roles
that
people
could
pick
up
with
limited
terms,
right,
I,
think
The.
Limited
terms
thing
is
the
most
important
part
of
this
design,
because
you
want
people
to
have
to
to
have
the
opportunity
to
step
up.
You
want
people
who
are
who
are
running
things
to
have
an
end
date
where
they
can
move
on
to
other
responsibilities
and
I.
A
Think
that
is
a
very
healthy
and
maybe
self-sustaining
thing,
but
we
do
have
to
put
some
build
some
momentum
around
it.
This
is
just
a
proposal.
It's
not
in
practice
in
any
place
just
yet,
but
I
do
think
that
there's
some
potential
behind
this,
because
we
need
to
borrow
ideas
and
and
try
to
fix
the
social
contract
of
Open
Source
One
pattern,
which
I
think
you
know,
there's
a
strong
amount
of
validation.
A
Already
is
developers
like
having
memberships
as
a
badge
of
honor
people
who
go
through
y
combinator
will
list
their
y
combinator
cohort.
Similarly,
if
you
have
a
social
club
or
if
you
have
a
term
of
service
in
government
or
in
the
military
you'll
talk
about
the
tours,
you
did
you
talk
about
the
service
that
you
did
and
I
think
that
is
something
aspirational
that
we
could
build
for
open
source
and
the
company
where
I
work
we
we
also
build
and
maintain
maintainer
and
contributor
program,
we're
running
one
right
now
for
Oktoberfest.
A
By
the
time
you
see
the
this
in
November
it'll
be
over,
but
we're
constantly
trying
to
encourage
and
Define
clear
roles
for
maintainers
and
contributors
to
participate
in
company
sponsored
open
source
as
well,
and
then
finally,
open
source
projects
die
and
I.
Think
we
need
to
acknowledge
that
and
maybe
have
a
healthy
renewal
process
or
kivo.
A
Recent
examples
are
YouTube,
DL
and
storybook,
both
of
which
technically
died,
but
then
will
also
revive
by
the
community
highly
encouraging
examples
of
Open
Source
projects
which
have
basically
transitions
in
community
ownership,
that
that
was
subsequently
very
well
managed
for
their
user
base,
and
that's
really
it
that's
a
that's
a
proposal
for
breaking
apart
the
open
source
monolith.
Thank
you
for
having
me.