►
Description
In this talk by Brandon Keepers, he'll describe how open source has changed and will continue to change the way the world builds software, not only by creating high-quality reusable components, but by giving us a model for producing software that is maintainable and adaptable at scale. He will examine how 'inner-sourcing', adopting open source philosophies and workflows, can improve internal engineering teams.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
All
right,
everybody
thank
you
coming
this
afternoon
last
breakout
of
the
day,
and
then
we
get
to
go.
Listen
to
stories
about
Pixar,
which
I'm
looking
forward
to
my
name
is
Brandon
keepers.
I'm
the
open
source
lead
at
github,
and
today,
I
want
to
talk
about
how
open
source
principles
can
apply
to
our
own
engineering
teams.
So
there's
no
doubt
that
as
an
industry,
we
witness
the
success
of
open
source
software.
We've
seen
the
open
source
process
create
extremely
high
quality
systems,
the
scale
to
some.
A
What
I
hope
you
take
away
from
this
session
today
are
is
somewhat
somewhat
of
a
framework
to
think
about
how
you
can
apply
these
principles
to
your
team.
Not
necessarily,
you
know
there
be
a
few
specific
tactics
you
can
use,
but
I'm,
looking
forward
to
the
ways
that
you
can
see
how
these
principles
fit
into
your
own
team.
A
So
kind
of
the
general
principles
of
open
source
are
our
transparency,
participation
and
collaboration.
When
you
hear
when
you
hear
people
outside
of
the
software
world
talk
about
applying
open-source
to
their
realm,
these
are
the
three
things
they're
talking
about,
so
so,
whether
it's
open
government
or
open
data
open
society,
any
anybody,
that's
seen
the
success
of
open
source
and
wants
to
figure
out
how
to
mimic
it.
What
they're
talking
about
is
we
want
to
figure
out
how
to
bring
these
attributes
to
it.
So
we
want
to.
A
We
want
to
expose
processes
and
information
make
them
transparent.
We
want
to
enable
people
to
participate,
and
then
we
hopefully
through
that
participation,
we
can
actually
collaborate
and
build
something
useful
together,
and
so
today,
I
want
to
talk
about
how
I
think
that
these
principles
have
somewhat
of
a
cascading
effect
yeah.
You
can't
have
collaboration
without
people
participating.
You
can't
have
participation
without
transparency.
A
So,
let's
start
with
transparency,
obviously
in
open
source,
the
source
code
is
open
right,
it's
available
for
anyone
to
its
inspect.
You
can
take
it
apart,
you
can
examine
it,
you
can
even
fix
it.
You
can
learn
about
good
and
bad
design
patterns,
but
that's
not
necessarily
what
we're
going
to
talk
about
today.
I
mean
I
doubt
that
most
of
us
aren't
into
internal
teams,
want
to
release
the
source
code,
but
the
reality
is
that
that's
not
actually,
where
the
value
of
open
source
software
comes.
Some
people
do
do
those
things.
A
A
The
source
code
is
an
artifact
of
a
production
process
and
what's
interesting
about
production
processes,
is
they
generally
have
a
larger
impact
than
the
thing
that
they
create
like
once
you
once
you
figure
way
of
making
things
the
entire
world
can
take
that
process
and
apply
it
to
the
things
that
they
make.
So
we
saw
this
with.
You
know
Henry
Ford
in
the
automobile,
like
it
wasn't
the
fact
that
Henry
Ford
made
a
better
car.
A
He
figured
out
a
better
way
to
make
and
that
thus
enabled
an
entire
industry
to
take
off
and
so
that
this
artifact
again
is
not
of
a
specific
process.
It's
not
of
a
you
know,
saw
the
development
methodology.
It's
not.
You
know
the
result
of
understanding
a
specific
users
needs,
but
I
would
argue
that
it's
the
communication
structure.
A
So
in
the
late
60s
there
was
a
guy
named
Melvin
Conway,
who
wrote
this
paper
called
how
committees
invent
and
that
the
central
thesis
of
that
paper
was
any
organization
that
designs
a
system
will
inevitably
produce
a
design
who
structures
a
copy
of
the
organization's
communication
structure.
I
think
this
is
really
interesting
kind
of
to
give
an
example
of
this.
A
So
I
think
that
this
you
know
this
is
a
really
interesting
observation.
The
paper
that
he
wrote
is
very
short,
so
I
encourage
you
to
go,
read
it,
but
it's
had
a
huge
impact
on
some
of
the
thinking
of
you
know:
development
methodologies
and,
like
the
book,
the
mythical
man-month
by
Fred
books,
Brooks
cites
this
and
kind
of
uses
it
to
form
its
thinking.
A
So
if
we
look
at
the
way
that
open-source
communities
communicate,
we
first
have
to
understand
strengths
that
they
have
so
the
open
source
communities
are
distributed
geographically
across
time
zones
and
even
across
cultures.
This
means
that
they
don't
have
the
benefit
of
you
know
high
fidelity
communication
right.
You
can't
walk
over
and
tap
somebody
on
the
shoulder
when
you're
stuck
on
a
problem.
You
can't
jump
into
a
meeting
when
you're
trying
to
work
through
it
through
a
problem.
A
You
can't
even
know
stand
around
the
water
cooler
and
chat
just
to
get
to
know
each
other,
so
this
means
that
these
projects
have
to
accept
certain
constraints
in
in
their
workflow.
So
several
years
ago,
Ryan
Sumiko,
who
was
actually
the
original
github
engineer.
The
first
engineer,
hired
at
github,
talked
about
a
lot
of
these.
So
so
a
lot
of
what
I'm
going
to
talk
about
next
comes
from
him
and
then
also
Ben
Balter
who's.
A
So
open
source
projects
used
this
basically
to
use
tools
that
enforce
this
communication
structure.
The
medium
is
electronic,
it's
asynchronous,
it's
lock,
free
and
the
result
of
those
three
things
is
that
the
message
is
archived.
So,
let's
dive
into
to
what
that
means.
So
the
medium
is
electronic.
Open-Source
communities
opt
obviously
for
tools
that
are
electronic.
The
Internet
and
Technology
in
general,
has
played
a
huge
role
and
even
enabling
this
like
massive
collaboration.
A
So
you
have
things
like
issue
tracker,
which
is
just
this
ongoing
list
of
either
possible
improvements,
bugs
ideas,
and
this
this
issue
tracker
is
open
to
anybody
that
wants
to
get
involved
in
the
project.
You
can
go
in
and
look
at
all
the
discussions
that
have
happened
in
the
entire
history
of
the
project.
It
kind
of
creates
this,
like
corpus
of
possible
improvements
for
the
software.
A
There's
no
means
in
an
open-source
community
for
me
to
demand
the
attention
of
somebody
else
right
now.
I
can
ping
them
on
chat.
I
can
you
know,
send
them
an
email,
but
there's
no
guarantee
that
that
message
will
come
back
to
me
and
so
there's
no
point
in
me
necessarily
waiting
for
that
and
I
mean
this
is
obviously
open-source
developers
are
rarely
in
the
same
place
at
the
same
time,
let
alone
different
places
at
the
same
at
the
same
time.
So
these
are
constraints
that
they
just
have
to
accept
and
have
to
deal
with.
A
This
also
means
that
the
medium
is
locked
free.
If
I
assume
that
I'm
not
going
to
get
a
response,
then
I
can't
design
processes.
That
expect
an
immediate
response,
and
so
this
is
kind
of
it.
You
know,
if
you
look
at
like
version
control.
This
is
this
is
kind
of
an
inherent
design
of
distributed
version
controls
through
version
control
systems
like
anybody
can
start
to
move
a
feature
forward
without
any
dependence
or
reliance
on
anyone
else.
You
know
I
can
check
out
a
branch
and
start
working
on
it.
A
A
You
also
in
this.
In
this
process
of
open
source,
you
push
approval
and
rejection
to
a
review
phase.
You
don't
have
this
a
situation
where
you
do
a
bunch
of
work.
Do
a
bunch
of
work
do
a
bunch
of
work
and
then
finally
ask
for
review
once
you're
done
like
you
can
start
that
process
as
soon
as
possible,
and
then
the
point
at
which
the
work
is
done.
You
can
continue
on.
A
Mailing
lists
have
archives
an
end
chat
has
a
log,
so
you
can
see
it
at
any.
At
any
point,
when
you
join
the
project,
you
now
can
see
the
entire
history
of
the
project.
Any
time
you
have
an
issue,
so
let's
say
you
run
into
a
bug
in
production
as
soon
as
you
find
out
where
that
bug
is
coming
from,
you
can
trace
back
the
history
of
how
that
came
to
be.
You
can
look
at
the
decision,
making
process,
decision,
making
process
and
all
of
that,
and
hopefully
Institute
changes
to
prevent
that
from
happening.
A
A
Github
and
I
searched
OOP
and
then
at
github,
which
limits
it
to
the
github
organization
and
I
find
out
that
there's
actually
three
hundred
and
thirty-some
conversations
issues
pull
requests
dealing
with
Hadoop
and
aren't
one
of
you
know:
Aria
analytics
team
basically
has
a
Hadoop
cluster
and
so
I
was
able
to
go.
Ask
them
some
of
these
questions,
so
these
are
kind
of
inherently
the
the
things
that
we
get
from
the
tools
that
we
choose:
an
open
source.
A
A
So
what
does
this
have
to
say?
What
does
this
have
to
do
with
transparency?
Well,
here's
here's
the
results
of
those
those
properties
of
the
way
that
we
communicate
an
open
source
information
is
exposed
to
others
working
towards
shared
goals.
Simply
the
process
of
doing
work
makes
that
information
available
to
them.
Work
towards
the
goal
is
rarely
blocked
if
ever
and
anyone
can
participate
regardless
of
geography,
timezone
culture
or
even
role,
so
so,
whether
I'm,
you
know
at
a
meeting
or
out
to
lunch
or
on
vacation
as
soon
as
I
get
back.
A
I
can
catch
up
on
everything.
That's
happened
in
my
project.
You
know,
I
didn't
have
to
worry
about
missing
out
on
information,
because
a
meeting
happened
and
I
wasn't
there.
So
these
trans?
Actually,
these
transparent
parent
communication
tools
help
to
break
down
silos
in
our
organizations
and
eliminate
some
of
the
tribal
knowledge,
and
so
that's
where
we
get
transparency
from
so
next.
I
want
to
talk
about
participation,
so
when
we
embrace
these
tools
that
are
inherently
transparent,
that
create
message
archives
as
we
work,
we
naturally
leave.
A
But
making
this
massive
stack
of
information
available
is
not
actually
enough
to
get
people
to
participate
in
the
work.
Now,
that's
being
done
so
I
want
to
talk
about
two
things
that
I
think
are
extremely
important
in
the
open-source
world
that
we
do
that
enables
people
to
then
participate.
So
we
work
on
minimizing
friction
and
we
work
on
automating
review.
A
A
So
the
way
that
we
do
that
in
open-source
is
we
distill
this
huge
body
of
information
that
we
created,
naturally
from
the
tools
that
we
use.
So
even
you
know,
basically
it's
not
practical
for
somebody
to
come
along
and
say:
okay,
I'll,
just
look
through
all
of
the
issues
and
discussions
and
archive
and
whatever
and
figure
out
how
this
project
works
until
we
work
on
documentation
right,
which
is
as
developers
kind
of
our
favorite
word,
but
the
documentation
is
extremely
important
because
it
allows
us
to
proactively
communicate
the
latest
thinking
about
how
this
project
works.
A
Again,
it
doesn't
matter
what
our
methodology
is,
but
you
take
all
of
the
information
that's
accumulated
over
time
and
you
just
still
it
down
to
knowledge
that
you
can
then
give
to
anybody.
That's
coming
to
the
project.
So
we
do
that
with
you
know,
the
readme
is
an
extremely
important
tool
and
giving
people
insight
into
how
to
get
started
with
the
project
and
use
it
and
then
the
contributing
documents.
Are
you
know
how
do
how
do
you
actually
give
back
to
this
project
now?
Just
how
do
you
use
it?.
A
We
also
do
that
by
automating,
something
so
to
reduce
friction
every
project
inside
of
the
github
organization
that
has
executable
code
in
it
generally
has
these
three
scripts.
So
we
give
you
script,
boot,
scrap
script,
server
and
script
test
and
I
know.
Often
open-source
projects
will
do
something
similar.
Basically,
regardless
of
the
technology,
that's
written
in
whether
it's
you
know
a
node
project
or
a
ruby
project,
or
even
a
c
project
you
can,
you
can
clone
the
repo
run,
script'
bootstrap,
which
will
set
up
your
environment.
A
You
run
script
server
or
the
equivalent
to
run
whatever
the
code
is,
and
script
tests
will
will
run
the
tests.
So
this
allows
you
know,
like
I'm,
not
so
extremely
familiar
with
development
node,
but
I
can
clone
any
of
the
projects
that
we
have
at
github
that
are
node,
get
them
up
and
running.
Make
a
few
changes
because
I
do
know.
Javascript
quite
well:
I
can
run
the
tests
to
make
sure
I
didn't
break
anything
and
then
I
can
submit
a
pull
request.
A
So
removing
the
friction
of
getting
started
is
one
of
the
most
important
steps
to
that.
That's
generally,
where
you
lose
people
and,
unfortunately,
an
open
source
project,
you
don't
actually
know
that
you're
losing
them
because
they
haven't
talked
to
you
at
all
right.
If
our
goal
is
to
make
it
so
that
they
can,
they
can
participate
without
asking
permission.
A
Then
we
don't
know
that
they're
getting
stuck
in
the
first
process,
which
is
actually
getting
the
thing
running
so
the
other
way
we
enable
people
spay.
Is
we
automate
review,
and
most
of
us
have
experienced
this
in
like
automated
tests,
you
know
we
write
unit
tests
to
make
sure
that
the
software
does
what
we
hope
it
should
do
and
that
it
does
what
we
wanted
to
do.
A
You
know
in
six
months
or
a
year,
whereas
people
are
changing
the
code,
but
I
think
it's
important
to
think
outside
of
just
the
the
realm
of
like
traditional
unit
testing,
automate
anything
that
you
can
anything
that
you
do
over
and
over
and
over
again.
So
like
one
of
my
favorite
parts
about
this,
is
that
if
you
have
really,
you
know,
if
you
have
things
that
you
care
a
lot
about,
it
gets
really
annoying
when
you're
constantly
telling
your
your
co-workers
to
also
care
about
it.
But
but
you
can
automate
it
and
put
it.
A
A
So
so
here's
an
example
of
this.
We
have
a
blog
so
to
post
on
the
github
blog,
you
open
a
pull
request
in
a
blog
repo
and
since
2008
we've
actually
had
198
different
employees,
publish
a
blog
post
and
there's
nobody
inside
of
the
organization
that
actually
owns
the
blog
it
might
belong
to
marketing.
It
might
belong
to
PR
I.
A
Think
we're
figuring
that
out
right
now,
but
there's
tons
and
tons
of
information
over
that
we've
gathered
over
the
years
about
what
we
think
is
the
right
way
to
make
blog
posts,
and
so
one
way
to
know
we
could
have
put
that
written
that
down
in
documentation,
said
here's.
What
we
think
is
the
best
way
to
write
blog
post,
but
instead
what
we've
done
is
we've
put
that
into
code.
So
every
time
we
decide
here's
how
we
want
our
blog
to
work,
we'll
write
tests
for
it.
A
So
when
you,
when
you
make
a
pull
request
to
the
github
blog
there's,
at
least
you
know,
these
four
tests
now
run.
The
first
one
is:
is
the
the
editorial
calendar.
So
at
some
point
we
decided
that
we
want
to
only
do
one
post
a
day,
maxximum
and
and
when
this
became
a
problem,
it
would
have
been
I.
Think
a
traditional
organization
would
have
been
really
easy
to
say.
A
Oh,
like
we
want
to
prevent
multiple
posts
from
going
out,
then
we'll
you
know,
sign
Susan,
to
review
every
blog
post
and
make
sure
that
there's
not
one
on
every
day,
but
Susan
probably
has
better
things
to
do
with
our
time.
So
we
can
write
code
to
do
this.
So
all
we
do
now
is
the
first
person
that
opens
up
a
PR
gets
a
pull
request
gets
to
pick
the
day
that
they
want
their
blog
post
to
go
out
and
now
anybody
else
that
opens
a
blog
post,
it'll,
so
it'll
give
them
this
warning.
A
It
looks
like
you
know.
Somebody
else
already
has
that
day.
So
we've
done
this
with
a
ton
of
other
things.
We
review
for,
like
certain
grammar
things,
there's
this
awesome
node
package
called
write,
good,
which
my
wife
felt
the
need
for
me
to
explain
to
you
that
we
know
that
write.
Good
is
not
how
you
would
say
you
say
write
well,
but,
oh
so
yeah.
We
basically
just
check
for
basic.
You
know
like
best
practices.
In
writing.
We
try
to
use.
A
We
try
to
use
active
voice
as
much
as
possible,
or
even
things
like
a
post
should
contain
more
use
than
wheeze,
or
all
images
should
be
hosted
on
github.
If
you
go
back
to
really
old
blog
posts
on
github
you'll
see
that
some
of
them
are
missing
images,
and
so
the
point
at
which
we
realize
that
we're,
like,
oh,
let's,
add
an
automated
test
that
make
sure
that
every
image
we
use
in
a
blog
post
is
is
in
a
medium
that
we
control
so
that
it'll
be
here
in
you
know
five
or
ten
years.
A
So
the
interesting
thing
about
doing
this
as
you
you
know,
so
you
use
tools
that
create
transparency.
You
then
start
to
distill
that
information
into
knowledge
like,
as
you
automate
it.
It
now
enables
the
people
that
you're
working
with
to
focus
on
substance.
No,
your
when
somebody
opens
a
pull
request.
You
have
to
look
like.
Oh,
is
this:
is
this
conflicting
with
another
day?
Are
they
using
active
voice?
All
of
those
things
now
we
know
are
taken
care
of,
and
the
people
that
are
reviewing
it
can
focus
on.
Is
this
good
content?
A
Is
this
something
that
we
actually
want
to
be
talking
about?
Are
we
missing
details?
You
know
that
might
be
relevant
to
a
certain
audience.
So
this
is
the
value
of
automation
as
people
as
more
and
more
people
start
to
participate.
You
get
a
focus
on
on
the
review
of
the
substance,
so,
to
sum
up
this
participation
to
document
the
knowledge
in
prose
or
preferably
code,
if
you
can,
if
you
do
it
in
code,
then
you
can
execute
it
for
free
without
having
to
worry
about
the
time
that
it
takes.
A
When
we
adopt
these
communication
structures
that
expose
information
and
enables
people
to
participate,
then
collaboration
naturally
starts
to
happen.
It's
not
something
that
we
have
to
actually
do
anything
about.
It's
the
side
effect
of
the
tools
that
we've
chosen
actually
exposes
the
process
that
our
teams
go
through.
So
I
love
this
about
github
like
or
any
open
source
project.
Really,
if
you
come
in
and
watch
the
project
for
even
just
a
day,
you
start
to
see
the
way
that
the
project
works.
A
You
start
to
see
the
patterns
that
they
prefer,
and
so
you
know
whether
it's
your
first
day
of
the
job
and
a
company
that
does
this
or
your
first
day
an
open-source
project.
You're
immediately
start
learning,
Jesse
Newland,
who
does
a
lot
of
chat.
Ops
at
github
works
on
our
ops
team
I,
like
the
way
that
he
says
this.
You
learned
by
lurking
and
you
teach
by
doing-
which
I
think
is
a
really
interesting
concept.
A
It's
like
just
simply
by
doing
your
job
you're
teaching
the
person
next
to
you
to
do
their
job
as
well,
and
and
again
it
doesn't
matter
what
your
process
is.
It
doesn't
matter
what
methodology
you
use
this
process
naturally
expose,
or
these
tools
naturally
expose
the
process
that
you
use
and
to
quote
Jessie
again
by
placing
tools
directly
in
the
middle
of
the
conversation.
Everyone
is
pairing
all
the
time.
I
think
that's
an
awesome
of
concept.
A
A
Basically,
I
mean
if
you,
if
you
take
one
thing
away
from
this
talk,
this
is
the
idea,
prefer
tools
that
inherently
capture
information
and
expose
the
process
of
your
team
and
that
might
look
different
for
your
team
than
it
does.
You
know
for
someone
else's
team,
and
so
you
have
to
experiment
with
all
of
these
things
and
figure
out.
What
are
those
tools
going
back
to
Conway's
law,
a
co-worker
of
ours.
A
The
way
that
you
communicate,
you
can
start
to
influence
the
structure
of
the
organization,
so
you
know
say:
you're
working
on
a
team
that
is
very
meeting,
centric
and
information
is
lost
all
the
time.
Your
job
on
that
team
can
be
to
start
to
document.
Those
meetings
like
create
an
archive,
find
figure
out
ways
to
create
that
that
communication
trail
and
then
maybe
you
know,
someday
someday
somebody's
gone
and
misses
a
meeting.
A
A
So
these
are
just
a
few
of
the
lessons.
I
think
we
can
learn
from
open
source.
I
mean
I
focus
mostly
on
communication
structure,
but
I
think
open
source
has
a
lot
to
say
about.
You
know
technical
aspects
like
we
can
learn
about
good
and
bad
design
patterns.
We
can
learn
about
architecture.
We
can
learn
about
new
tools,
I
mean
things
like
git
itself
came
out
of
the
open-source
community
I'm
trying
to
solve
challenges
that
those
those
people
are
facing.
We
can
also
learn
about
social
structures.
A
We
can
learn
about
conflict
resolution,
overcoming
cultural
differences,
collaboration
and
coordination.
Now,
there's
economic
factors
so
dealing
with
motivation,
resource
allocation,
which
is
an
interesting
one
in
companies.
I
hope
somebody
soon
gives
a
talk
about
that
and
we
can
deal
about
political
structures.
So
what
does
it
look
like
and
for
governance
or
decision-making
within
a
company?
A
If
you
want
to
think
be,
you
know,
spend
more
time.
Thinking
about
some
of
these
things
are
reading
about
them,
I
mean
obviously
the
same
advice
that
applies
to
open
source
can
apply
to
our
companies
and
so
I'd
recommend
these
two
books.
The
success
of
open
source
is
written
by
a
political
scientist,
not
a
software
developer
at
all,
but
trying
to
understand
what
is
unique
about
the
software
process,
the
open
source
process
and
then
producing
open
source
software
is
a
really
practical
book
and
actually
how
to
do
it.
A
How
to
do
open
source
from
you
know,
picking
an
issue
tracker
and
version
control
system,
all
the
way
to
dealing
with
conflict
and
and
legal
issues,
so
I,
just
wrap
up
I
want
to
use
a
quote
from
the
success
of
open
source,
so
the
steam
engine
was
the
metal
behind
the
first
Industrial
Revolution.
But
the
revolution
was
a
set
of
ideas
about
organizing
factories,
limited
liability
corporations,
trade
unions
and
daily
newspapers.
A
There's
a
lot
of
things
that
we
can
learn
practically
from
open
source,
but
I
think
the
bigger
impact
is
going
to
be
taking
the
process
and
applying
it
to
other
things,
I
mean
we're
learning
now
how
to
apply
it
to
our
companies,
even
though
the
source
code
doesn't
end
up
being
open.
Other
industries
are
learning
how
to
apply
it.
So
open
government
open
data.
It's
going
to
be
interesting
to
watch
the
trickle
of
some
of
these
principles
into
these
other
organization
or
other
industries.