►
Description
With over 250 open source projects in our portfolio, Facebook faces some unique challenges in shepherding these projects and making sure they’re actively serving the community. In this talk, Christine will share how Facebook goes about doing that by describing those challenges, how they’ve attempted to solve them, and lessons learned.
About CodeConf
CodeConf improves the software community by providing a forum for thought-provoking talks and forging social connections. The third installment of the CodeConf series took place in Nashville in 2015. Attendees came together to discuss open source, best practices, documentation, and community.
For more information on this year's CodeConf, go to:
https://codeconf.com/
A
A
And
congratulations
to
all
of
you
who
made
it
to
Friday
afternoon.
Yeah
I'm
really
excited
to
be
here,
I'm
just
going
to
be
talking
about
how
Facebook
does
open
source
at
scale-
and
this
is
something
that
a
part
of
the
open
source
team
at
Facebook
and
our
responsibility
is
just
to
make
sure
that
the
projects
and
the
programs
relate
to
Facebook.
Open
source
are
running
well
and
includes
a
lot
of
different
things
and
I'm
going
to
share
about
what
we're
doing
some
of
the
challenges
we've
faced
and
whether
or
not
you're
running.
A
Actually
a
big
open
source
program
are
just
getting
started.
Some
of
these
may
apply
to
you
as
well,
so
just
to
kind
of
get
a
quick
story.
Our
open
source
roots
go
back
in
2004,
a
young
undergraduate
at
Harvard.
You
know,
put
a
website
together
using
Linux
Apache,
my
sequel
and
PHP,
and
that's
kind
of
where
we
got
started
and
ever
since
then
open
source
has
been
a
big
part
of
Facebook.
In
fact,
as
we've
grown
and
we
scaled,
and
we
found
that
we
can
actually
contribute
a
lot
more
back
to
open
source.
A
So
that's
up:
that's
why
it's
one
of
the
things
that's
important
to
us
and
there's
a
common
pattern
to
how
we
use
open
source
at
Facebook.
So,
for
example,
when
we
take
my
sequel,
we'll
go
ahead
and
use
it
usually,
when
you're
doing
things
on
Facebook
you're
doing
things
at
scale,
so
you
need
to
improve
it,
tweak
it
and
then,
once
again
you
may
actually
go
ahead
and
improve
it
and
contribute
back
to
the
community.
A
There
are
other
programs,
such
as
hack
or
PHP,
that
came
out
of
using
PHP
finding
that
we
needed
a
lot
more
horsepower
going
ahead
and
actually
replacing
at
the
runtime
h/h
VM,
which
was
discussed
earlier
by
Michael
and
then
replacing
it
or
giving
it
back
to
the
community.
Open
Compute
is
another
sort
of
example
of
it,
and
Open
Compute
is
where
he
oversaw
some
of
our
hardware
designs
and
then
also
contribute
that
back
to
the
community.
A
So
these
are
not
vanity
projects
that
a
summer
intern
comes
and
before
they
leave
they're
going
to
ship
it
over
the
wall
and
leave
it
go
everything
we
use
is
being
used
on
our
infrastructure,
so
everyone
is
running
h,
hv
m,
so
Baidu
and
Wikipedia
they're
running
the
same
web
server
that
we're
running
internally
and
there's
some
challenges
that
come
along
with
that,
because
everything
that
we
use
in
is
used
in
production.
Things
kind
of
hang
along
pretty
well,
so
this
is
sent
a
snapshot
of
what
we
have.
A
We've
got
open
computer
hardware
designs,
we've
got
design
tools,
we've
got
web
infrastructure
data
infrastructure
type
languages.
You
saw
some
examples
of
that
and
Michael's
talked
earlier
today
and
I
des
so
there's
a
lot
of
things
that
we
are
open:
sourcing,
our
Facebook
and
sometimes
it
looks
like
we're
open
sourcing
just
about
everything
we
have,
but
basically
we're
open
sourcing,
anything
that
used
in
production
and
we're
very
careful
about
that-
and
this
is
just
like
a
snapshot
of
all
sort
of
the
highlights
of
what
we've
open-sourced,
just
in
the
first
half
of
this
year
alone.
A
It's
not
everything
so
we're
back
in
2013,
we
actually
rebooted
the
Facebook
open
source
programs
at
Facebook,
because
prior
to
that,
what
would
happen
was
had
a
lot
of
projects
that
were
languishing
out
there
and
they
were
not
used.
So
to
give
you
a
quick
sense
in
2012
before
the
programs
reboot,
we
had
14
projects
that
were
launched
in
2013.
A
That's
the
reboot
year
we
had
30
projects
that
were
launched
last
year
2014
we
had
107
projects
that
were
launched
by
Facebook
and
so
far
in
the
first
half
of
this
year,
we've
already
launched
53
projects.
So
it's
looking
like
another
banner
year
and
again
we're
very
careful
about
everything
that
we
are
open-source.
We
want
to
make
sure
that
it's
used
in
production,
so
just
to
give
you
a
quick
sense
of
numbers.
These
are
some
of
the
projects
that
we
have
across
our
portfolio.
We
have
266
repos,
very
popular.
A
We
also
manage
how
many
people
are
forking.
So
for
those
of
you
do
you
know
what
the
background
picture
there
is
yeah,
that's
one.
Last
time
I
saw
so
I
just
had
to
find
somewhere
to
put
it
on
the
slide.
So,
to
keep
in
mind,
the
open
source
is
not
just
important
part
of
our
technology
stack,
it's
actually
a
good
indication
of
hacker
culture.
So
this
is
how
engineering
perceived
Facebook.
So
in
fact
we
are
every
six
months
or
so
we
do
a
survey
of
new
hires
at
Facebook.
A
We
found
that
in
this
most
recent
survey,
70%
of
the
people
who
were
new,
they
knew
about
Facebook
open
source
before
they
joined
64
percent
of
those.
So
that's,
roughly
just
under
a
half
said
that
the
fact
that
Facebook
did
open
source
influence
positively
their
decision
to
join
and
then
just
about
a
third
of
that
said
that
what
they
were
working
on.
Our
Facebook
was
useful
because
of
what
they
had
learned
before
at
open
source.
So
they
could
come
in,
get
ramped
out
really
quickly.
That's
really
a
huge
win.
A
This
is
why
we
do
open
source
on
Facebook.
So
let
me
kind
of
switch
gears
and
talk
about
how
and
then
some
of
the
challenges
that
we
have
faced.
So
when
we're
releasing
our
projects
at
Facebook,
there's
some
challenges
that
we
face
and
I
just
split
it
up
into
three
phases:
I've
got
pre-launch
launch
and
then
what
happens
after
launch?
I'll
go
through
these
step-by-step,
so
the
pre
launch
phase.
This
is
the
place
where
you
want
to
get
ready.
A
You
want
to
make
sure
that
your
open
sourcing
for
the
right
reasons
and
then
what
are
the
steps
that
you
go
through
to
actually
make
this
happen
successfully.
So
I'm
just
going
to
highlight
some
of
the
challenges
that
we
have.
So
one
of
the
challenges
is:
how
do
you
make
your
code
modular?
So
a
lot
of
projects
may
previously
exist
within
Facebook,
and
you
need
to
take
the
code
modularize.
A
It
remove
a
lot
of
Facebook
dependencies
before
you,
shipping
it
out
you're,
also
taking
a
look
at
some
of
the
api's
and
making
sure
that
they
are
really
clean
and
see.
These
are
some
of
the
things
that
might
take
a
lot
a
long
time
but
you're
making
your
code
ready
for
the
world,
and
this
can
take
a
long
time.
It's
not
part
of
what
we
actually
as
the
open
source
team
need
to
look
at,
but
it's
something
that
developers
need
to
be
aware
of.
A
The
next
challenge
is
whether
or
not
you
are
hosting
your
code
internally
or
externally.
So
a
lot
of
our
projects
live
on
github,
but
that
does
not
mean
that
it
up
is
actually
the
source
of
truth
of
that
project
and
the
very
reason
the
various
reasons.
Why
and
we'll
walk
into
that,
but
that
actually
plays
into
some
of
the
challenges
that
we
face.
Another
part
of
when
we're
open
sourcing
projects.
This
we
before
we
our
project
gets
green-lighted
for
launch.
A
It
has
to
go
through
a
review
process
and
we
kind
of
Shepherd
that
through
and
there's
some
things
that
we
need
to
be
thinking
about
during
that
phase
and,
lastly,
a
lot
of
projects,
especially
if
they're
big
they
need
to
have
sort
of
marketing
material
around
them,
do
a
big
splash.
So
there
are
some
things
that
go
along
with
the
launch
that
we
also
need
to
think
about
and
take
care
pre
launch.
So
I'm
just
going
to
start
talking
about
sort
of
the
internal
saying.
How
do
you
get
your
code
or
synced
internally
and
externally?
A
So
Facebook
has
a
lot
of
internal
tools
that
help
them
out
with
when
code
drops,
it
can
do
a
lot
of
tests
like
performance
measurements,
checking
things
out
the
run
directly.
If
it's
an
iOS
app,
it
can
run
code.
In
the
background
that
shows
whether
or
not
you
something
broke,
and
some
of
those
tools
are
only
available
if
things
are
happening
internally.
So
if
your
source
of
code
of
the
truth
is
internally,
then
you
get
a
lot
of
those
winds
on
the
flipside.
A
So
we
what's
happened
in
the
past
is
a
lot
of
projects
when
they
have
code
internally
that
they
want
to
ship
to
github
they'll
write
all
these
really
complicated
custom
scripts
when
the
commit
lands
internally
do
this
or
when
everything
checks
out
then
push
it
out,
and
it
becomes
a
lot
of
work
that
they
rework
over
and
over
again.
So
we
have
the
open
source
team
are
trying
to
build
tooling
and
practices
that
can
help
it
up
with
these
flows,
and
that's
some
of
the
things
that
we
do
so
in.
A
For
example,
again
we
have
this
internal
github
script
that
can
kind
of
watch
changes
in
a
particularly
directly
internally
and
then
get
ready
for
it
to
ship
out,
and
some
of
the
key
features
that
it
has
is
proper
github
attribution.
If
you
don't
think
do
things
right,
I
mean
code
can
come
from
github
into
this.
Internal
report
and
code
can
also
come
internally
into
this,
and
then
you
want
to
push
that
out.
A
If
you
don't
do
things
right,
you
can
kind
of
squash
the
attribution
and
the
person
who
worked
so
hard
to
actually
make
the
external
complete
it
gets
lost.
So
some
of
the
things
that
we
actually
take
care
of.
We
also
want
to
make
sure
that
we
are
scrubbing
all
the
commit
messages.
So
what
get
sent
out
as
sighs
in
a
way
and
then
the
other
thing
that
it
also
does
is
we
do
continuous
imports,
because
otherwise
somebody
would
have
to
actually
every
time
a
commit
comes
in
run
these
bill
scripts.
A
A
The
other
part
that
we're
also
working
on
is
what
happens
when
you
want
to
green-light
a
project
and
send
it
out
for
review.
So
in
the
past,
it's
up
it
kind
of
gets
a
little
tricky,
because
all
these
emails
come
and
I
want
to
open-source
something.
Okay,
tell
us
a
little
bit
about
it.
Yes,
you
can
do
it.
A
No,
you
can,
can
you
give
you
more
information
and
becomes
a
long
email
thread
which
gets
lost
and
then
somebody
jumps
in
and
it's
chaos,
so
we
just
built
tooling
around
that
to
just
ask
all
the
questions
a
nicely
formatted
way
and
send
up
something
which
we
call
a
task.
So
a
facebook,
a
lot
of
things
are
tasked
helpdesk.
You
file
a
task
developer,
developing
something
you
file
a
task.
It's
a
really
nice
like
system
that
we
use
to
communicate.
So
that's
the
output
of
that.
So
that's
how
we
get
us
a
project
review
started.
A
Everybody
needs
to
be
the
loop
gets
to
subscribes
to
those
tasks
and
in
addition
to
that,
as
we
lead
up
to
the
launch,
we'll
use
other
mechanisms
to
disseminate
information
such
as
using
our
Facebook
groups,
or
we
also
use
Facebook
chat
with
everybody
who's
concerned
about
just
getting
us
on
a
chat
and
guess
that
going
now.
The
other
thing
that
we
worry
about
is,
if
you're,
a
big
project.
You
probably
don't
want
just
to
read
me
out
there.
A
You
might
have
a
big
website
which
shows
all
these
nice
things,
so
we've
been
working
some
teams,
some
engineers
don't
want
or
don't
care
about,
writing
HTML.
All
they
want
to
do
is
ship
code.
So
for
those
folks,
what
we
do
is
we've
started
providing
services,
so
we
give
them
templates,
something
that
can
you
say,
github
pages
they
write
code
in
markdown
and
we
give
them
templates
around
that
and
then
we
make
sure
it's
responsive.
A
So
it
looks
good
on
mobile
and
we
ship
it
out
and
we're
starting
to
kind
of
get
those
going
and
then
listen
to
feedback,
because
a
lot
of
different
people
want
different
customizations
so
whether
they
want
a
logo
or
all
these
different
things,
we've
covered
it.
So
these
are
some
of
the
things
that
we
do
and
we
just
want
to
standardize
on
a
lot
of
things.
So
when
people
want
to
go
from
beginning
of
the
project
to
launch
they
have
everything
they
need.
So
now
it's
time
for
launch.
This
is
usually
the
easy
part.
A
This
is
the
part
where
you
just
push
a
button.
The
only
things
that
can
slip
you
up
is
not.
Everybody
knows
what
day
its
launching,
what
time
it's
launching
or
what
they're
supposed
to
do,
but
generally,
this
is
the
easy
part,
and
all
we
do
is
everybody
who's
concerned
about.
It
gets
on
a
Facebook
group
and
we
have
up-to-the-minute
coordination.
A
In
fact,
at
the
recent
f8
conference,
where
we're
over
a
two-day
period
we
launched
about
six
open-source
projects,
we
just
had
a
war
room
and
everybody
was
just
like
clicking
buttons
and
okay,
is
this
group
ready
go,
go,
go
and
that's
what
we
found
works
really
well,
so,
once
you've
actually
launched
the
product,
you
just
don't
breathe
a
sigh
of
relief.
So
that's
where
post
launch!
This
is
actually
the
trickiest
part.
This
is
now
you're
out
and
going
and
some
of
the
things
that
you
need
to
think
about.
A
If
you
listen
to
the
last
talk
by
Lee
I
mean,
do
you
speak,
I
qaeda
Aikido,
so
that
that
was
actually
a
pretty
good
talk
because
a
lot
of
times
some
of
the
challenges
initially
is
you've
just
launched,
and
now
you
got
a
slew
of
requests,
pull
requests.
Why
did
you
do
this?
What
are
you
thinking?
I
found
an
error
in
the
docs,
so
you
don't
just
launch
and
sort
of
leave
it
there.
A
So
a
lot
of
things
teams
just
need
to
know,
especially
if
it's
a
popular
project
or
we
think
it's
going
to
be
that
you
need
to
be
ready
for
kind
of
a
slew
of
requests
to
comment.
So
we
just
advise
the
teams
be
ready
and
we
give
them
best
practices
of
what
they
should
do
and,
for
example,
about
a
week
and
a
half
ago
in
for
launches
the
static
analyzer
for
iOS
and
Android,
the
team
was
based
off
of
android.
We
launched
it
on
us
time.
A
They
had
been
up
really
late,
getting
it
ready,
but
they
basically
have
to
stay.
Probably
another
12
hours
because
of
the
requests
coming
in
and
a
lot
of
them
were
just
coaching
them
like
they'll,
be
respect,
will
be
of
the
community.
Just
do
things
the
right
way
answer
the
questions,
don't
be
quiet,
so
pass
the
initial
launch,
there's
sort
of
another
phase.
This
is
actually
one
of
the
key
elements
is
how
do
you
sustain
the
support?
How
do
you
keep
the
community
engaged?
A
What
are
the
different
things
that
you
can
do,
whether
it's
meetups
blogs
developer
forums?
What
are
the
different
ways
that
you
can
keep
the
community
happy
and
in
addition
to
that,
because
we're
hosting
things
that
github,
when
you're,
reviewing
auric
still
and
requests
are
coming
in?
You
want
to
make
sure
that
that's
not
breaking
your
code
and
you
want
to
make
sure
that
everything
is
working.
Fine,
so
that's
something
that
we
also
need
to
keep
on
Aion.
And,
lastly,
you
know
sometimes
it's
time
to
say
goodbye
to
a
product.
A
It
might
be
that
different
reasons
why
that
might
happen,
but
you
also
want
to
be
aware
of
how
do
you
deal
with
those?
How
do
you
get
in
front
of
the
situation
so
that,
if
something
needs
to
be
sunsetted,
you
know
what
it's
about
so
I'll
start
first
with
just
talking
about
how
we
handle
pool
support,
and
this
is
where
we
provide
a
lot
of
tooling
for
our
teams
internally.
So
in
here
you
can
see.
This
is
like
our
intranet,
where
we
have
a
lot
of
the
different
tools.
A
This
is
a
dashboard
which
shows
a
high-level
aggregate
of
all
of
the
metrics,
so
here
you're
seeing
things
such
as
how
many
repos
are
out
there,
how
many
watches?
How
many
commits
and
teams
can
look
at
this
and
find
a
way
of
seeing
how
are
they
doing?
You
can
also
drill
and
get
metadata
about
accounts,
and
you
can
actually
drill
into
more
details
about
each
account.
A
So,
for
example,
we
have
another
place
where
we
actually
show
all
the
projects
and
in
there
you
can
drill
and
see
and
filter
by
by
name
by
Watchers,
by
issues
and
get
an
aggregate
view,
and
then
each
project
can
drill,
because
each
project
can
drill
down
and
get
their
own
page,
which
has
extra
information.
This
could
be
place
where
they
have
settings
for
the
different
tools
that
we
provide
for
them,
but
here
they're
also
get
a
place
where
they
can
see
some
of
the
drafts
of
things
that
we
pull.
A
A
And
so
here
this
is
a
react
example
showing
how
many
commits
how
many
commits
or
internal
versus
how
many
commits
are
external.
In
addition
to
that,
another
thing
that
we
like
to
do
in
front,
provide
in
terms
of
tooling,
is
to
show
appreciation
to
the
people
who
are
passionate
and
contributing
to
open
source.
So
here
you
see
another
tool
that
we
created,
showing
who
are
the
heroes?
Who
are
the
top
contributors.
So
we
like
to
do
that
externally,
because
some
of
the
teams
may
want
to
come
and
sent
at
the
end
of
the
year.
A
Shoo
act,
all
of
the
people
who
have
been
the
top
contributors
internally
also
like
to
use
this
data,
to
say
thanks
to
a
lot
of
the
internal
contributors,
because
some
of
those
are
just
passionate
about
open
source,
but
it's
not
their
regular
day
job.
So
you
want
to
appreciate
them
so
that
they
get
recognition
because
some
of
those
are
some
of
our
most
key
contributors.
So
we
provide
dashboards
for
that
as
well.
A
In
addition
to
that,
we
also
provide
tooling
for
our
engineers,
who
are
used
to
some
of
the
workflow
and
the
processes
that
are
there
internally
to
Facebook.
So
Facebook
has
a
couple
of
nice
tools
once
called
fabricator.
That's
used
for
reviews.
This
is
a
way
to
review
your
ads
if
things
are
going
through
and
then
there's
another
one
that
I
mentioned
previously
cost
call
tasks.
A
So
here
you
see
a
dashboard
for
flow
showing
all
from
github
all
of
the
recent
pull
requests
and
teams
can
actually
turn
on
a
flag
which
can
pull
issues
from
github
and
make
them
into
internal
tasks.
They
can
work
in
internally.
In
addition
to
that,
we
also
allow
them
to
import
issues
that
come
to
github
internally
through
a
way
for
them
to
review
it
and
in
scenarios
where
github
is
not
the
source
of
truth.
A
They
can
actually
pull
the
code
in
and
use
our
internal
tooling
system
to
run
tests
so
that
they
can
make
sure
that
nothing
is
breaking
internally.
The
other
thing
that
some
of
our
tools
are,
some
of
our
teams
are
using
just
to
make
github
a
lot
more
like
fabricator,
in
terms
of
the
workflow
of
going
through
tools,
as
a
is
just
a
way
to
kind
of
add
labels
and
add
tags
on
github.
A
Look
at
the
issue.
If
it
looks
good,
they
can
go
ahead
and
change
the
label
to
get
up
accepted.
Another
thing
that
we
do
for
teams
is:
we
provide
each
team
on
code,
facebook.com,
slash
projects
their
own
space
where
they
can
host
information
inside
of
our
tooling.
They
can
go
and
set
settings
for
where
are
all
the
places
that
they
have
presence,
whether
it's
Twitter
Google
Groups
and
then
internally?
You
can
source
that
information
and
make
it
available
and
kind
of
RSS
feed.
So
this
is
an
alternative
way
that
they
can
get
promotions.
A
I
know
finally,
I
just
want
to
talk
about
a
part
where
it
might
be
time
to
say
you
know
goodbye
to
a
product.
So
how
do
you
do
that?
So
each
project
has
a
setting
for
who
are
the
owners
of
the
projects,
and
then
we
use
that
information
every
six
months
we're
starting
to
send
out
a
comprehensive
report
to
find
out.
How
are
you
using
the
project?
Are
you
still
the
owner?
A
What
are
some
of
the
pain
points
that
we're
seeing
and
we're
going
to
use
that
to
inform
our
next
decisions
of
what
we
want
to
work
on?
In
addition
to
that,
we
also
have
a
weekly
script,
that
taks,
who
are
the
projects
that
don't
have
an
owner's,
and
then
we
use
that
to
followup
with
the
managers.
For
example,
people
could
leave
people
could
move
on
there
different
ways
that
we
want.
A
So
these
are
sort
of
reactive,
we're
also
trying
to
be
a
little
bit
proactive
where
we
actually
run
scripts
to
see
how
many
issues
have
not
been
looked
at
for
a
certain
period
of
time,
flag,
those
projects
and
reach
out
to
them
and
work
with
them
and
all
say:
are
you
having
trouble?
What
can
we
do
together
to
solve
this
so
I'm
just
going
to
go
through
some
of
the
best
practice
that
we
have
and
some
of
the
things
that
we've
learned?
A
A
Next,
if
you
can
advocate
github
as
the
source
of
truth,
the
very
scenarios
we
may
not
make
sense,
but
if
you
can
do
that,
it
makes
the
conversations
a
lot
more
open
with
the
community
set
proper
post
launch
expectations
with
teams
know
that
they
need
to
support
the
community,
don't
just
throw
something
over
the
wall
and
walk
away.
It's
where
community
needs
to
be
engaged.
A
They
need
to
know
that
you
care
about
that,
and
you
want
to
make
sure
that
you're
sure
the
projects
are
actually
being
actively
maintained
and
then
finally
show
appreciation
to
the
contributors.
Whichever
way
you
can-
and
we
do
a
lot
of
these
things
through
tooling,
so
I
kind
of
get
a
step
back
and
talk
about
when
we
go
to
a
lot
of
these
conferences
and
we
found
out
that
there
was
a
lot
of
folks
who
are
actually
facing
similar
scenarios.
A
So
in
September
2014
we
formed
a
to
do
group,
and
this
stands
for
talk
openly
develop
openly.
It
brings
together
companies
that
are
kind
of
similar
challenges,
and
what
we
do
is
some
of
the
partners
in
there
are
github
Microsoft
Google
who
are
speaking
at
this
conference,
including
many
others,
and
we
want
to
learn
from
our
collective
experiences.
What
are
the
different
best
practices?
How
we
grow
a
scale
and
we're
making
good
conversation?
A
Then
we
want
to
share
this
experiences
with
the
other
people
in
the
community
and
eventually,
maybe
even
actually
have
some
tooling
that
we
can
share
also
with
the
community
around
some
of
the
things
that
we
face.
So
at
Facebook
we
like
to
say
that
we
are
work
is
only
1%
done
and
we
hope
that
by
using
a
glimpse
of
how
we
do
open
source
at
Facebook
that
you
can
take
away
some
of
the
best
practices
that
can
help.
You
scale
up
your
open
source
initiatives.