►
From YouTube: Blurry Lines - GitHub Universe 2016
Description
When working on open source projects, your contributions and opinions on the project and its motives are usually very personal. Jess Frazelle's talk will cover intricacies of "choosing your battles" and how personal passion for a project might conflict with corporate motives.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
A
This
talk
in
content
is
super
personal
to
me.
So
it's
helpful
to
know
a
little
bit
about
Who
I
am
previously
I
was
a
doctor
core
maintainer
I've
contributed
to
projects
like
go.
Kubernetes
and
I
have
a
bunch
of
open
source
projects
of
my
own,
on
github
I've,
experienced
open
source
from
the
side
of
the
contributor,
from
the
side
of
the
maintainer
and
from
the
side
of
the
company
paid
contributor
maintainer,
which
is
really
essential
for
this
talk.
You'll
get
to
know
a
lot
about
me
through
the
content
of
this
talk
as
well
so
yeah.
A
The
first
thing
I
really
want
to
focus
on
is
the
passion
that
it
takes
to
contribute
to
open
source
software.
I,
really
think
it's
the
driving
force
behind
the
people
and
the
communities
that
we
all
are
a
part
of
people
who
believe
in
a
project
and
use
it
are
the
ones
that
contribute
and
give
back
the
most
heavily
and
open
source.
Is
this
rare
opportunity
to
work
with
people,
and
it's
that
want
to
achieve
all
the
same
things
that
you
also
want
to
achieve?
A
I
think
most
of
us
have
probably
contributed
to
open
source
before,
but
I
just
want
to
focus
on
the
main
feeling
that
you
get
when
in
that
pull
requests
that
you
opened
is
merged.
It's
just
almost
magical,
because
at
that
moment
you
become
a
part
of
something
that
is
so
much
bigger
than
yourself
and
your
member
of
this
community
and
it's
just
essential
to
absolutely
everything.
Is
this
passion
for
making
things
better
and
being
a
part
of
communities.
A
So
what
happens
when
this
fiery
passion
is
fueled
by
a
paycheck
from
a
corporation?
This
is
really
where
things
start
to
get
super
complicated.
It
brings
about
the
intricacies
of
when
do
you
fight,
and
when
should
you
compromise
and
kind
of
the
main
scenario
that
happens
here
is
kind
of
a
David
and
Goliath
type
of
thing.
Where
there's
you
know
this
huge
company
and
they
want
some
feature
in
that
will
allow
them
to
make
money
and
then
there's
like
a
contributor
who
or
maintainer
where.
Maybe
they
don't
agree
with
this
feature.
A
But
you
know
they
know
the
community,
they
feel
amongst
their
peers,
you
know
being
a
part
of
it
and
they
disagree
with
the
feature
whatever
it
may
be.
But
the
money
from
this
said
feature
is
actually
what
pays
their
check
at
the
end
of
the
day,
so
we
aren't
gonna
get
anywhere
with
hypothetical
scenarios.
A
One
being
me
and
I'm
gonna
go
through
kind
of
how
we
evolved
as
a
team
and
how
we
decided
to
deal
with
these
types
of
conflicts
and
also
teach
you
how
to
you
know,
stand
up
for
what
you
believe
in
and
not
get
fired,
which
is
huge
so
a
little
bit
about
how
I
joined
docker
I
was
already
contributing
to
the
project
I'd,
given
talks
about
docker
I
used
it
at
the
startup
that
I
was
working
at
previously.
We
used
it
for
all
of
our
infrastructure
relied
on
docker.
A
So
my
first
day
at
docker,
a
couple
of
other
people
ended
up
starting
the
first
day
as
me,
but
not
on
my
team.
They
were
on
various
other
teams
and
one
of
them
made
the
unfortunate
mistake
of
pushing
it
to
docker
docker
master
on
their
first
day
and
this
kind
of
exposed
some
some
problems
with
just
the
way
onboarding
worked.
A
Docker
had
all
these
rules,
you
know
where
you
know
you
open
a
pull
request.
Everything
gets
sent
through
a
pull
request.
It
has
to
be
approved
by
to
maintain
errs,
and
obviously
it
was
a
mistake,
and
everyone
makes
mistakes
on
their
first
day,
but
like
awesome,
pushing
to
prod
on
your
first
day
yay.
But
then
we
decided,
you
know
you
need
to
not
get
just
commit
access
to
everything
on
your
first
day,
obviously,
which
is
really
kind
of
like
a
clear
lesson
here
and
I.
A
Think
like
the
key
things
to
take
from
this
like
are
I
was
hired
from
the
community,
which
is
great
and
I
really
like
stress
how
awesome
it
is
to
hire
for
the
community.
But
you
also
have
to
limit
how
many
people
you're
gonna
hire
from
the
community,
or
else
like
your
community
is
not
then
diverse
and
the
trust
of
having
you
know,
maintain
errs
from
this
company
and
maintain
errs
from
different
companies.
A
You
made
up
all
these
new
maintainer
roles
for
people
that
really
just
do
issue
triage
or
code
review,
and
it's
awesome
and
if
there's
not
a
role
for
you,
we'd
probably
make
one
up
which
is
super
cool,
so
there's
goals
that
you
can
work
for
and
you
earn.
This
maintainer
should
face
off
right
and
it's
all
based
off
data
data.
So
it's
not
just
like
this
person,
I
think
they've
been
contributing
a
lot.
No,
it's
like
not
who
you
know.
It's
not
anything
like
that.
It's
all
data.
A
So
if
we
fast
forward
a
bit
to
a
couple
weeks
in
to
my
time
at
docker
kind
of
one
of
the
first
conflicts
arose
and
it
happened
when
another
team
at
docker
opened
a
pull
request
which
was
more
like
a
patch
bomb
on
the
repo,
and
it
came
in
like
right
before
a
release
cutoff,
and
it
was
something
where
they
were
like
yeah.
We
need
this
and
it
was
people
at
docker
sending
it.
A
So
you
know
people
that
sit,
maybe
just
a
little
bit
wait
for
me,
but
on
a
different
team
and
the
company
and
everything
like
everyone
was
pushing
for
this
feature.
But
all
like
five
of
us
on
the
docker
core
team
were
like
no,
no,
no,
no
one.
It
is
way
too
late
in
the
game
like
we're
about
to,
you,
know,
start
doing
the
release
in
two
days.
So
what
are
you
thinking?
A
There
are
no
tests
for
this
patch
and
it
is
relying
on
a
service
that
is
not
even
deployed
into
production.
So
there
are
parts
of
this
code
that
we
can't
even
test
because
nothing
is
hitting
it
ever.
And
so
what
are
we
supposed
to
do
more
joined
be
like
yay,
hopefully
that
works
and
since
I
had
kind
of
just
joined
and
I
still
had.
In
my
mind
the
Jess,
who
does
you
know
infrastructure
for
this
startup
and
everything
relies
on
it.
There
was
kind
of
this
competing.
A
You
know,
thought
process
in
my
brain,
there's
like
I,
wouldn't
want
them
to
upgrade,
because
that's
super
scary
and
we
don't
want
to
use
the
faith
of
our
users
who
do
upgrade
automatically,
because
you
learn
that
lesson
once
and
then
you
don't
do
it
again,
so
that
Trust
goes
away
like
that.
So
I
fought
super
hard
against
it
and
a
couple
of
my
co-workers
ended
up
kind
of
just
being
like
okay.
Maybe
this
is
fine
and
it's
like
no
no
stop.
A
This
is
so
bad,
and
this
is
just
a
super
stressful
position
to
be
in
because
you're
sitting
there,
like
okay
I,
am
publicly
commenting
on
this
I
am
showing
that
I
like
very
almost
aggressively,
feel
against
it.
This
is
all
out
in
the
open
for
anyone
to
see
it,
but
also
these
people
sit
really
close
to
me
and
you
know,
am
I
going
to
lose
my
job
over
saying
no
to
this
stupid
feature,
I
just
moved
from
New
York
I
was
paying
rent
in
New
York
and
in
San
Francisco
I
was
like
you're
a
dumbass.
A
What
are
you
doing?
So
we
had
a
few
meetings
with
the
other
team
and
finally,
like
we
kind
of
compromised
and
the
fact
that,
like
they
got
the
service
up
and
running
like
come
on,
we
got
to
be
tested
against
it.
We
got
to
run
the
lines
of
code
that
would
have
never
been
run
before
and
make
sure
nothing
panicked,
which
I
actually
think
there
was
a
panic
and
then
they
fix
it.
I
was
like
so
yeah.
A
There
was
just
we
ended
up
getting
through
it,
but
we
also
had
to
hold
off
the
release.
Just
for
this,
which
is
totally
wrong
and
should
never
happen
so
a
few
things
to
learn
from
this
are,
you
know,
allow
saying
no
and
we
had
retrospectives
afterwards,
where
I
kind
of
brought
up
my
fear
being
fired
over
this,
and
everyone
was
like
no,
no.
No.
A
A
You
have
the
people
who
love
the
project
and
you're
giving
them
the
permission
to
say
no,
so
they
can
protect
the
community
and
the
project
and
even
maintain
errs
from
outside
the
project,
who
you
know
maybe
work
for
other
companies
or
maybe
they're
individuals
of
their
own.
They
can
also
say
no.
Obviously,
their
maintainer
is
just
like
everyone
else.
Everyone
plays
by
the
same
rules
and
looks
good
to
me
lost
forever.
A
So,
like
anyone
can
go
back
to
that
polar
quest
and
see
who
looks
good
to
meet
it
and
also
like
once,
you
looks
good
to
me
something
and
merge
it.
It's
gonna
be
there
forever
and
it's
tied
to
the
individual.
That
said
it
like
you,
don't
see
a
company
having
maybe
like
a
company
account,
looks
good
to
me
a
pull
request.
A
No,
it's
tied
to
actually
me
so
that
would
look
bad
on
me
if
it
went
in
and
I
said
that
it
was
fine,
so
it's
like
your
beliefs
really
need
to
be
the
one
that
is
commenting
and
doing
things
so
yeah
there's
a
lot
of
things
that
can
come
from
this,
but
yeah
the
retrospective
that
we
had
after
we
decided
to
come
up
with
a
ton
of
rules
where
it
was
like
everybody
plays
by
the
same
rules.
We
all
need
to
have
things
in
at
a
certain
time.
They
need
to
have
tests.
A
We
need
to
be
able
to
test
it,
so
we
kind
of
just
created
explicit
guidelines
for
acceptable
patches
and
release
cut-offs,
so
that
this
could
never
happen
again.
Hopefully,
and
we
made
a
few
other
changes
too.
So
previous
to
this,
we
were
kind
of
a
separate
entity
like
just
these
five
kind
of
maintained.
A
A
We
got
to
do
pretty
much
whatever
we
wanted,
which
was
awesome,
and
now
we
kind
of
had
this
firewall
in
between
us
so
that
they
couldn't
come
over
and
stress
us
out
or
pressure
us
to
merge
things,
and
we
already
had
a
bunch
of
things
separate.
Whereas,
like
we
as
IRC
for
communication,
the
companies
slack,
we
had
a
separate
AWS
account
than
theirs.
A
We
hosted
all
our
tests
infrastructure
on
it.
The
apt
repo
was
on
our
s3
account
there.
Everything
was
separate.
We
even
had
actual
walls
in
the
office
that
just
like
happen
to
separate
us
as
well.
So
that's
kind
of
interesting-
and
this
is
not
actually
where
you
want
to
take
things.
It's
very
isolating
and
you
should
work
as
one
as
a
company,
but
one
of
the
interesting
things
that
happened
that
we
kind
of
had
to
learn
from
was
our
AWS
account
was
hooked
up
to
someone's
email
that
they
never
checked.
A
So,
when
the
credit
card
that
it
was
hooked
up
to
expired
or
something
they
started,
sending
emails
they're
like
we're
gonna
show
off
your
account,
we're
gonna
shop
for
your
pad
count.
You
need
to
pay.
Finally,
they
shut
it
off
and
then
at
first
we
were
like
what's
happening
because
you
don't
know
that
it's
actually
been
shut
off.
A
Finally,
we
figured
out
it
was
because
of
failure
to
pay
and
then
getting
a
hold
of
AWS
to
turn
back
on.
It's
like
literally
impossible.
So
we
had
to
have
the
corporate
side
use
their
support
contract
to
tell
AWS
to
turn
on
our
AWS
account
again
and
meanwhile,
like
the
repo
is
blowing
up
with
issues.
A
No
one
could
install
docker
because,
of
course
the
s3
bucket
can't
be
reached
and
we're
like
freaking
out,
so
we
finally
worked
everything
out,
and
then
we
set
up
billing
through
the
corporate
account
so
that
they
were
tied
together
and
this
kind
of
taught
us
like
1.
We
can't
be
entirely
isolated
off
from
the
company.
Obviously,
people
still
have
to
pay
for
things
like
thank
God.
A
company
supports
you
and
pays
for
things,
otherwise,
you'd
be
entirely
screwed,
and
it's
just
like
it's
not
the
greatest
thing
to
isolate
yourself
from
the
rest
of
the
company.
A
After
this,
we
then
kind
of
tore
down
the
firewall
between
us
and
we
instead
started
doing
kind
of
more
integrations
where
one
of
us
would
go
and
work
on,
say
you
know
the
distribution
team
and
help
them
with
a
feature
either,
maybe
through
coding
with
them
or
also
just
kind
of
walking
them
through
what
they
need
to
do
for
the
process
to
get
things
into
docker.
So
this
was
way
better.
It's
like
have
someone
there
helping
the
feature
that
these
other
people
want
along,
so
that
it's
not
like
us
versus
them.
A
No,
it's
like
us
and
them
together.
I
mean
we
all
work
for
the
same
company.
It
should
not
be
a
fight
always
so
we
kind
of
evolved
over
time
into
this
thing.
So
if
you
know
you're
thinking
about
open
sourcing,
your
projects
don't
make
all
the
same
mistakes.
We
did.
We
even
changed
our
team
name,
even
though
our
team
had
all
the
same
people
throughout
all
these
changes.
We
weren't
from
the
docker
core
team
to
meta
to
engine
team
and
super-weird
a
different
email.
A
Aliases
became
a
joke,
but
here
is
like
kind
of
some
rules
of
the
road
for
what
you
should
do.
If
you're
thinking
about
you
know
open
sourcing
your
project
as
a
company
and
how
you
can
keep
the
trust
that
the
community
has
that
Europe,
you
won't
just
make
it
as
a
company
project,
so
maintainer
ship
should
definitely
be
earned
higher
from
the
community,
but
not
too
much
because
you
can't
steal
them
all.
Allow
saying
no
looks
good
to
me.
Last
forever
looks
good
to
me
is
tied
to
the
individual.