►
Description
Christine Abernathy and Teddy Reed guide us through the lesser known parts of designing security software: building community trust, managing build & deployment, dogfooding, and empathy.
Almost one year ago, Facebook released osquery, an open source Linux and OS X host-based intrusion detection tool. Since then, the Mac & Linux security communities offered an immeasurable amount of support and guidance. The project has delivered an amazing impact for many companies, including Facebook, thanks to these efforts.
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
A
By
show
of
hands
how
many
of
you
out
there
actually
have
an
open
source
project
that
you're
maintaining
its
a
good
numbers
about,
like
I,
say
fifty
percent.
How
many
want
a
bit
even
more
awesome
communities?
I
was
heaving.
All
of
you
cause.
Do
you
want
to
do
that?
So
that's
what
this
talk
about,
and
we
hope
that
we
can
help
you
with
that.
And
while
this
talk
is
titled,
you
know
building
communities
around
open-source
security
software.
We
think
that
this
should
also
apply
to
any
of
you
who
have
an
open
source
project
out
there.
A
A
What
we
want
to
discuss
is
the
interesting
challenge
that
the
OS
query
team,
as
well
as
the
facebook
security
team
found
when
they
try
to
develop
in
the
open
and
we're
going
to
highlight
some
of
the
difference
of
just
working
with
the
security
tool
versus
all
of
the
other
open
source
projects
that
we
have
and
by
sharing
our
learnings.
We
hope
this
is
going
to
help
any
of
you
out
there,
whether
it's
a
security
tool
or
open
source
project,
if
you're
having
difficulty
building
a
strong
community.
B
B
That
kind
of
means
two
things
one.
We
put
so
much
more
effort
into
open
sourcing,
this
and
so
much
more
effort
into
the
project,
because
we
knew
it
was
going
to
be
open
source
and
we
got
almost
that
same
amount
of
effort
given
back
to
us
by
contributors
by
architecture
reviews
just
by
like
the
general
awesomeness
that
comes
with
putting
a
code
out
in
the
open,
especially
for
a
security
tool
and
having
everyone's
eyes
on
right.
B
So
because
we
noticed
that
how
much
effort
we
were
putting
in
as
a
team
as
Facebook
as
a
security
team
at
large
and
all
the
effort
that
the
community
was
putting
in.
We
wanted
to
get
up,
onstage,
put
something
together
and
try
to
give
back
to
everyone
right
so
and
that's
kind
of
culminating
in
like
hey.
How
can
we
set
everyone
else
up
for
success
to
build
awesome
communities
as
well.
A
So,
let's
take
a
brief
detour
and
actually
figure
out
why
why
not
this
Facebook
the
open
source
software
I,
could
tell
you
a
story
about
our
faithful
day
in
2004,
when
a
young
Harvard
student
said
on
his
desk
and
picked
up
the
lamp
stack
and
started
coding,
so
Facebook
was
built
on
the
on
the
shoulders
of
giants
and
we
definitely
want
to
give
back.
That's
not
enough.
A
I
could
also
tell
you
how
open
source
is
aligned
with
our
hacker
culture,
where
Facebookers
get
together
periodically
and
just
sit
together
and
hack
on
crazy
ideas,
because
we
like
to
say
that
code
wins
argument
and
that's
part
of
the
story,
but
that's
not
all
I
can
also
tell
you
about
the
social
obligation.
Facebook's
mission
is
to
make
the
world
more
open
and
connected,
and
we
can
talk
about
how
sharing
the
projects
with
the
developer
community
kind
of
works
towards
that
mission
yeah.
This
is
really
true,
but
that's
not
all.
There
is
so
why?
A
Why
does
facebook
open
source
for
facebook?
It's
not
ideal
ideological
lips
of
its,
not
even
ideology
at
all.
The
reason
why
Facebook
open
source
is
it's
good
for
the
company
now,
I'm
sure
many
of
you
are.
There
might
also
say
that
it's
good
for
your
company,
but
you
know,
for
example,
there
are
some
business
models
out
there.
There
are
some
folks
who
do
open
source
because
they're
just
have
like
a
Enterprise
version
of
community
software
or
the
providing
professional
services
or
even
a
commercial
support,
but
wait.
A
A
It
actually
accelerates
innovation,
so
we
find
that
when
we
are
actually
open
sourcing,
our
code
or
our
stack,
our
hardware
designs
that
we
are
giving
other
companies
and
individuals
a
chance
to
move
just
as
fast
as
we
do
and
far
from
that's
being
a
competitive
because
remember,
we
actually
are
not
selling
software,
but
finding
that
this
value
actually
is
back
to
us.
So
our
customers
and
our
partners
can
actually
take
the
same
software
that
we
share
and
create
mobile
apps
or
web
apps
much
faster.
A
We
can
help
popularize
still
look
like
the
unconventional
approaches
we
have
and
just
give
them
a
much
more
broader
appeal
and
then
even
better.
We
actually
can
benefit
from
some
of
the
contribution
that
actually
come
back
to
us.
The
second
reason
why
it's
good
for
the
company
it
just
makes
us
write
better
software,
so
it
doesn't
mean
that
we're
checking
for
spelling
mistakes
or
even
looking
for
comments
or
making
sure
that
everything
is
well
documented.
A
But
when
we're
writing
better
software,
we
know
that
our
project
is
going
to
be
open
source,
so
it
just
makes
us
do
a
lot
better
job.
From
the
start,
we
look
at
making
sure
that
the
project
itself
is
well
encapsulated,
the
fact
that
it
can
also
be
extensible
and
we
also
create
much
cleaner
and
much
more
stable
api's.
So
even
until
they
remember,
we
have
thousands
of
engineers
when
we
actually
open
source
a
project.
It
makes
it
that
much
easier
to
reuse
that
project,
because
it's
something
that
doesn't
have
mysterious
tendrils.
A
So
we
run
surveys
periodically
with
some
of
the
new
people
who
join,
and
we
found
that
in
the
last
survey
that
three-quarters
of
the
people
who
were
new
hires
say
that
they
had
some
knowledge
of
facebook,
open
source
and
all
those
people.
Three
quarters
are
just
over
half
said
that
this
actually
positively
influenced
their
decision
to
join
facebook
and
just
about
a
third
of
the
people
who
joined
said
that
they
were
actually
using
their
prior
experience
with
Facebook
in
their
current
role.
A
So
this
means
that
people
can
get
up
and
running,
not
in
months,
not
in
days
but
even
hours
from
when
they
join
facebook.
So
suffice
it
to
say
that
open
source
is
really
good
for
the
company.
It's
a
powerful
argument
for
why
we
open
source.
So
let's
look
I
want
to
make
one
really
key
important
point.
Whatever
facebook
open
sources
out,
there
is
what
we're
actually
using
in
production
and
we
only
open
source
what
we
use
in
production.
A
So
that's
how
we
know
and
that's
how
you
will
also
know
that
what
you're
using
is
projects
that
work
that
they
work
at
scale,
their
men,
they're
well
maintained
and
that
they're
valuable
to
us.
So
how
serious
are
we
about
open
source?
Let's
look
at
some
numbers,
so
today
we
have
320
projects
out
there,
of
which
we've
had
about
46,000
people
who
have
fought
those
projects,
91,000
commits
to
those
repos,
and
we
have
284
thousands.
It's
just
over
a
quarter
of
a
million
followers
that
are
actually
using
our
projects.
A
So
yes,
on
average,
we
have
about
a
thousand
followers
for
repo,
so
follows
are
only
a
representations
of
what
it
means
to
be
other
communities
out
there,
so
we
can
only
accelerate.
We
can
now
write
better
software
and
we
can
feel
comfortable
sharing
what
we
have
with
others
when
we
build
powerful
communities.
So,
let's
talk
about
challenges
and
what
I'm
going
to
talk
about
challenges
of
scale
or
complexity,
we're
going
to
start
talking
about
the
challenges
that
we
faced
and
actually
building
and
maintaining
these
healthy
communities.
B
So
there's
a
really
awesome,
saying:
I
learned
at
Facebook
around
open
source
and
before
I
joined
facebook.
I
was
really
into
open
source
of
light.
I
was
one
of
those
people
that
joined
already
was
familiar
with
a
couple
of
the
stacks
patchy
thrift
and
absolutely
true.
You
can
get
up
and
running
and
start
pushing
code
within
hours,
but.
B
After
you
open
source,
a
project
right,
you've
done
insurmountable
amount
of
work.
It
does
not
stop
there
right.
Actually,
the
hard
part
stop
starts
as
soon
as
you
switch
that
project
from
private
to
public.
That's
when
it
that
and
that
that's
the
point
is
talking
right.
So,
let's
take
a
look
at
0
is
clear
right:
Oh
square
is
a
security
tool,
runs
on
every
machine
that
Facebook
has
it's
SQL
powered
operating
system,
instrumentation
and
monitoring,
so
it
kind
of
exposes
the
operating
system
as
SQL,
so
concepts
in
the
operating
system
are
now
tables
right.
B
So
every
process
that's
running
on
your
system
has
a
bunch
of
attributes.
Those
attributes
are
the
columns
inside
that
table
and
it's
just
one
of
a
bunch
of
security
tools
that
make
up
the
family
of
facebook
security
software
I'll
call
to
out
one's
thread
exchange.
The
other
is
in
fir
first
awesome.
If
you
haven't
tried
that
out,
take
a
look
at
it.
Static,
analyzer
love,
static
analysis,
but
let's
also
take
those
numbers
that
we
just
saw
on
the
screen
and
compare
them
to
OS
crew.
B
So
when
we
say
that
after
we
hit
the
private
to
public,
that's
when
the
real
work
began,
we're
saying
is
that's:
when
building
this
community
around
the
software
and
kind
of
holding
back
and
keep
asking
ourselves
the
question
every
day.
Is
this
going
to
be
successful
right?
That's
when
it
got
challenging
right
and
to
this
day
it's
still
challenging.
We
still
sit
every
morning
we
open
our
computers.
We
look
at
the
github
repo.
We
see
how
many
people
start
it.
We
see
how
many
pull
requests
are
there.
B
B
We
didn't
see
our
first
major
commit
until
april.
First,
like
major
feature
push
into
OS
Korea
until
April.
First,
the
entire
time
at
six
months
between
there
we're
doing
that
nail
biting
like
oh
my
gosh.
Was
this
the
right
decision?
Do
people
really
love
our
software?
We
want
to
hear
experiences
telefe.
Is
it
telefe
tell
us
if
it's
bad
like
give
us
some
criticism,
we'll
fix
it
for
you.
B
We
promise
right,
they're
like
what's
going
in
here,
we're
getting
use
out
of
it
right,
we're
deploying
it
we're
seeing
awesome
things
from
it,
we're
making
our
developers
better
we're
making
our
security
team
better.
Tell
us
if
you
are
too
right
and
we
just
kind
of
expected
that
everyone
was
kind
of
loving
it.
We
went
to
a
couple
of
conferences:
we'd
go
to
like
intrusion,
detection,
meetups
around
the
Bay,
Area
and
kind
of
ask
people
if
they
use
there's
no
like
yeah,
it's
good,
it's
good!
It's
good!
Give
us
some
feedback,
that's
good!
So
awesome!
B
It's
awesome!
So
we're
still
kind
of
like
really
scared
at
this
point.
So
now,
at
this
year,
point
right
and
took
these
numbers.
Two
days
ago,
we
have
5,000
followers
our
github
at
59
contributors
right,
there's,
a
big
difference
between
this
number
we're
like
how
do
we
have
5,000
people
engaged
in
the
security
project,
a
community
that
is
5,000
people
right
and
only
59
of
those
people
are
contributing
to
us
right
and
that's
contributing,
measured
by
pull
requests
and
its
documentation
updates,
fixing
all
our
spelling
errors,
adding
features
fixing
those
exclamation
points
and
the.
B
B
We
take
a
little
bit
deeper
dive
into
those
numbers
and
I
pulled
out
a
curated
list
here
of
a
couple
other
projects,
so
here's
some
Facebook
projects
actually
projects
that
we
use
inside
of
OS
query
I,
would
kind
of
look
at
all
their
numbers
and
stacker
acting
rank
them
against
our.
So
we're
like.
Oh
my
gosh.
We
feel
like
we're
being
blown
away.
We
love
these
projects.
Why
aren't
people
showing
us
the
same
love
right
or
if
they
are,
how
are
they
doing
it?
How
do
we
measure
that?
B
So
then,
we
take
a
look
at
a
couple:
non-facebook
projects
also
security
projects,
and
we
also
see
that
these
numbers
are
outrageous
and
super
jealous.
How
do
we
get
these
kind
of
numbers
all
the
while
coming
back
to
this
59?
And
it
was
much
less
six
months
afterwards,
so
you
could
imagine
kind
of
like
our
frustration
who
we
found
out
and
the
rest
of
this
presentation
of
we
describe
like
how
Facebook
does
open
source,
how
we
support
our
community
with
all
our
projects,
then
compare
them
to
OS
crew.
B
What
we're
going
to
learn
is
that
this
59
is
actually
amazing.
We
have
to
take
away
that
only
and
we
have
to
say
we
have
59
contributors
right
!.
This
was
expected,
but
will
also
teach
you
a
little
bit
of
how
we
were
missed,
representing
the
engagement
right,
there's
different
ways
to
measure
if
someone's
using
a
security
tool
versus
an
open
source,
developer
library.
B
So
at
the
end
of
the
day,
and
hopefully,
at
this
end
of
the
presentation,
demonstrate
how
like
we
did
find
all
that
love.
We
found
all
that
love
that
six
months
we
were
now
able
to
measure
that
love,
and
if
we
were
to
release
another
open
source
security
tool,
we
would
not
be
biting
our
nails
right.
We
would
be
feeling
the
love
the
whole
time.
A
Ask
yourself
a
question:
are
you
actually
solving
their
problem?
Are
you
doing
something
that
they
would
find
useful
so
before
a
project
release
on
the
open
source
team,
we
actually
look
at
every
project
and
we
make
them
ask
the
question:
why
why
are
you
open
sourcing
this?
Why
is
it
good
for
the
community?
Why
is
it
good
for
facebook?
Otherwise
we
don't
greenlight
the
project,
but
this
actually
forces
the
people
working
on
their
projects
to
do
that,
and
you
should
actually
get
into
the
same
discipline.
A
So
beyond
answering
the
question
of,
why
would
you
use
it?
There's
also
a
question
of
how
would
somebody
actually
use
your
project,
so
there
are
very
many
things
that
you
want
to
think
about,
and
I
want
to
give
you
some
examples
from
our
projects.
So
stato
is
an
Android
debug
library
that
was
released
earlier
this
year
and
the
team
went
into
a
lot
of
trouble,
building
in
components
into
their
project
that
are
not
used
internally
at
Facebook,
but
they
just
wanted
to
meet
the
needs
of
the
community.
In
this
case
it
was
great
old
support.
A
Another
project
was
Ted
was
a
presto
suppressed
as
a
diss
buted,
a
sequel
analytics
engine
and
when
they
actually
open
source,
they
were
thinking
about
it
from
the
get-go.
So
the
way
they
did
is
they
built
plug-in
architecture
so
that
if
they
had
to
integrate
with
facebook,
it
would
be
really
easy,
because
a
lot
of
projects
would
then
facebook
before
their
open
source.
A
Storage
engine
also
actually
did
the
same
thing
where
they
have
a
pluggable
architecture
and
makes
it
really
easy
for
external
contributors
to
actually
plug
in
and
do
the
same
thing
so
now
that
you've
kind
of
like
understood
the
audience
next
thing
that
we
actually
ask
people
to
look
at
is
on
that
day,
and
it's
show
time
on
launch
day.
You
want
a
great
do.
A
You
want
to
create
a
really
awesome
initial
experience,
so
a
lot
of
people
we
want
just
like
okay,
I
got
code,
I'm
just
going
to
throw
it
over
the
wall,
and
they
don't
take
time
to
actually
make
sure
that
things
look
really
good
and
believe
me
take
a
lot
of
time
on
that.
It's
well
worth
it
so
that
when
somebody
tries
out
your
project,
you
may
only
get
five
minutes,
a
very
short
amount
of
time
that
you
need
to
make
it
really
clear.
What
is
your
project
is
doing?
A
A
These
are
very
obvious,
but
sometimes
some
of
the
teams
don't
do
that,
and
also
this
is
where
documentation
is
really
critical
so
that
getting
that
quick
start
guide
where
somebody
can
go
in
and
then
one
two
three,
however,
many
the
shortest
amount
of
steps
they
can
get
up
running
and
it
has
to
be
really
accurate.
It
has
to
just
work,
so
the
open-source
team
actually
spends
a
lot
of
time
in
that
day,
zero
experience
where
we
look
at
different
projects
before
they've
launched
and
make
sure
things
work
well,
and
we
also
do.
A
We
also
give
our
website
profile
services
so
that
tears
want
to
create
web
services
that
look
really
awesome
and
work.
We
provide
that
as
well,
so
the
other
thing
that
you
want
to
do
immediately
after
launch
is
to
just
listen
and
educate.
So
after
you
release
the
projects,
that's
when
the
spot
line
comes
on.
That's
when
people
are
posting
on
social
media.
The
first
issues
are
coming
in.
A
You
want
to
make
sure
that
you
are
listening
and
that
you
are
actually
responding
to
those
requests
and,
for
example,
rebound
rebound,
which
is
an
Android
animation
library
that
was
released
when
it
was
first
released.
It
actually
included
a
guava
dependency
that
just
made
this
project
really
huge
and
kind
of
got
really
dinged
about
it
on
social
media
buying
and
influences
so
well.
A
Bailey,
who
is
the
maintainer
actually
took
that
to
heart
and
make
sure
he
kind
of
make
smooth
things
out
added
everything
that
was
needed
and
the
project
has
been
really
successful
after
that,
and
it
actually
set
the
tone
for
a
lot
of
the
Android
libraries
and
how
we
actually
open
source
those
as
well.
So,
whether
or
not
you
actually
go
and
attend
conferences
so
that
you
can
listen
to
the
audience
or
you
just
go
to
meet
ups
or
even
organize
your
own
conferences
anyway,
that
you
actually
meet
the
audience
is
very
valuable.
A
It
might
not
seem
scalable
and
you
don't
have
the
time,
but
it
is
something
that
you
want
to
think
about,
and
react
has
actually
done
a
phenomenal
job.
They
had
actually
two
very
good
conferences
this
year
that
were
very
well
attended,
you're
able
to
meet
with
the
community
and
see
exactly
how
they're
doing
it
they
get
a
chance
to
talk
to
project
authors
see
live
demos,
it's
really
invaluable.
So
this
is
how
you
want
to
actually
go
and
spread
your
message
and
get
to
kind
of
know.
Your
community,
that's
good.
B
So
let's
say
you
don't
know
your
community
right
course.
A
new
person
comes
to
github
to
your
project,
makes
an
issue
or
opens
a
poor
request.
You
click
on
their
username
and
you
don't
see
anything.
This
is
their
first
interaction
or
you
don't
see
any
other
security
projects
or
any
other
projects
related
to
your
software
stack.
What
you
going
to
do
so
googling
their
name,
try
to
figure
out
like
creeped
on
them.
A
little
bit
figure
out
what
they're
about
figure
out
how
to
respond.
B
That's
not
sustainable
right!
I!
Don't
want
to
do
that
at
all.
What
we
found
with
us
query
is
create
a
tag
on
github
called
triage.
Someone
new
comes
to
the
project
tag
that
issue
or
that
pull
request
with
triage,
immediately
write
as
fast
as
possible.
That's
a
really
small
ping
to
the
person
to
say,
like
I
got
it
I
know
you
have
a
problem
or
you
want
to
tell
me
something
I'm
looking
into
it
right.
B
It
gives
them
really
good
feeling
that
kind
of
extends
them
out
of
time
that
you
have
to
like
research
them
or
then
ping
them
offline,
or
go
back
and
forth
on
the
floor,
requester
or
issue.
So
let's
know
our
community
right.
Let's
know
our
communal.
It's
do
some
research
before
we
open
source
this
project
figure
out
who's,
going
to
be
the
users
who's
going
to
get
the
most
impact
out
of
it.
So
we're
building
an
intrusion,
detection
and
host
modern
monitoring
tool.
B
It
uses
SQL
right
you're,
going
to
install
this
tool
on
your
clients,
you're,
going
to
install
this
tool
on
your
agents
right.
Our
community
actually
was
the
system
administrators
and
the
defenders
of
networks
that
was
our
biggest
community.
Those
are
the
biggest
users
of
our
project.
That's
not
what
we
thought
so
we're
like
awesome.
We
got
SQL
everyone
at
Facebook,
loves
SQ,
Oh,
God,
operating
system
concepts
as
tables
right
developers
and
administrators.
Everyone
loves
SQL,
we're
going
to
put
this
SQL
thing
out
there.
B
We
had
an
implicit
thought
that
would
because
we
build
it
in
SQL
and
we
loved
sqo
at
Facebook.
The
entire
world
would
know
exactly
what
to
do
would
see
the
number
of
tables
that
we
put
out
there
on
an
unreleased
day
and
start
adding
to
this
list,
adding
to
this
bucket
of
tables.
One
thing
we
kept
saying
is
like
we're
going
to
put
all
these
basic
tables
out
there
and
it
one's
gonna
fill
this
jar
up
with
all
the
really
complex
awesome
tables
right,
we're
going
to
do
the
groundwork.
B
B
So
we
boil
this
down
to
a
couple
of
concepts,
all
right,
a
couple
of
takeaways,
something
that
we
kind
of
had
to
learn
the
hard
way
after
six
months
of
having
the
security
tool
out.
There
is
it's
okay
to
find
that
core
community
find
the
community
focus
on
that
right,
and
in
this
case
we
were
doing
the
wrong
community.
We
were
doing
the
developers
switch
focus,
start
focusing
on
defenders
that
administrators
the
users
of
this
tool.
Then
we
found
our
core
community
right.
Then
we
found
that
kind
of
love.
B
It
was
giving
them
all
the
data
that
they
could
see
right
and
because
of
that,
because
it
was
kind
of
like
the
secret
capability
that
they're
deploying
they
didn't
really
want
to
kind
of
talk
about
the
data
that
it
was
giving
out
right.
That
kind
of
makes
sense.
Now
you
know
you
deploy
something:
that's
going
to
give
you
visibility
about
problems
on
your
network
with
potential
threats
who
network
you're
not
going
to
talk
about
that
right,
you're
going
to
be
actually
adverse
to
talking
about
that,
and
that's
okay,
that
is
okay.
B
So
then
the
final
piece
of
advice
was
like
a
new
user
experience
that
enables
collaboration-
and
this
case
was
the
wrong
initial
experience
we
should
have
designed
was
a
new
user
experience
I'm
coming
to
the
project
that
allows
them
to
take
it
to
fork
it
to
deploy
it
and
see
value
inside
their
company.
We
want
everyone
to
pull
those
forks
back
right.
B
We
actually
are
kind
of
fork
adverse,
but
in
this
case,
with
the
security
tool,
deploying
it
privately
was
a
good
thing
right
and
we
should
have
built
you
new
users
of
experiences
that
enable
that
right
and
so
the
kind
of
gets
into
our
next
topic,
which
is,
after
you
understand
your
community
after
you
kind
of
understand
who
your
users
would
be
or
who's
going
to
get
the
most
value
from
the
product.
You
then
have
to
learn
or
attempt
to
understand
how
you
can
support
them
going
forward.
A
So
how
do
you
actually
support
and
grow
your
community,
so
growing
and
maintaining
a
healthy
community
is
actually
very
key
to
your
project's
success
and
it
can
be
a
grind
and
there
could
be
days
when
you're
like
I.
Don't
want
to
do
this,
but
if
you
stick
with
it,
it's
well
worth
it
and
we've
seen
that
happen
in
many
of
our
projects.
So
here
are
some
of
the
questions
that
you
want
to
ask
yourself.
A
So
where
is
my
community
and
how
can
I
reach
them
and
then
how
can
actually
interact
on
the
community
and
continue
to
nurture
them?
So
you
want
to
optimize
when
you're
trying
to
find
your
community
for
optimized
for
participation
and
define
all
of
your
communication
channels.
Are
you
going
to
go
with
IRC?
Are
you
going
to
use
stack
overflow?
It's
going
to
be
guetta
strack,
google
groups.
A
So
some
of
the
advice
that
we
have
for
the
different
teams
is
Justin
I'll,
just
start
with
maybe
just
github
issues
and
then,
as
you
go
along,
and
you
find
why
the
community
is
most
active,
then
go
do
that
you
grow
more
people,
so
you
just
want
to
see
what
works
best
for
the
community
and
actually
adapt
to
that.
Now
that
you
actually
know
how
to
interact
on
where
you
can
find
your
community.
So
where
is
it
then
how
you're
going
to
actually
grow
your
community
interact
and
mature
them?
A
A
What's
the
pull
request,
average
age
and
we've
done
a
lot
of
these
dashboards,
so
it's
actually
nice
for
some
of
the
teams
to
try
to
do
kind
of
use,
game,
mechanics
and
see
if
they're
doing
better
than
someone
else,
but
it
actually
encourages
tuned
to
be
really
responsive
now.
The
second
tip
that
I
have
is
just
a
respect
and
power
and
mentor
your
contributors.
A
A
So
react
native
is
another
one
of
our
projects
and
it's
a
framework
for
building
native
apps
on
top
of
react
and
what
they've
done
really
well.
It
had
two
really
key
contributors
and
these
people
just
started
off
with
just
having
push
access
and
they
mainly
worked
on
documentation
as
time
went
on
now.
These
two
key
contributors
are
responsible
for
the
entire
release
process,
the
changelog
they
actually
do,
the
community
newsletters
roundups
and
they
actually
also
post
on
social
media.
So
just
think
about.
A
The
third
pro
tip
is
just
to
kind
of
be
open
and
being
open,
actually
means
that
you
want
to
keep
the
community
up-to-date
on
ongoing
issues.
You
want
to
invite
them
into.
What's
going
on,
you
want
to
make
sure
that,
let's
say
you're
just
too
busy.
Let
them
know
people
understand
that
things
can
happen
want
to
be
transparent.
You
want
to
share
your
roadmap
if
you
can,
because
if
you
do
this,
then
people
are
going
to
feel
vested
in
your
product
because
they
will
feel
part
of
the
process.
The
other
pro
tip.
A
Is
you
just
want
to
make
sure
that
you
are
maintaining
the
highest
quality
and
the
standard
of
your
projects,
and
this
can
happen
whether
or
not
you
have
a
new
release
of
something
major
comes
in.
You
want
to
make
sure
that
the
supporting
cast
words.
It's
the
documentation,
the
unit
tests
sample
apps,
that
everything
is
very
well
maintained,
because
this
can
be
really
frustrating
when
you
come
in
and
you're
trying
a
new
project
and
things
don't
work
so
make
sure
that
you
are
always
always
maintaining
your
quality.
A
The
last
thing
I
want
to
do
so
in
terms
of
tech,
maintaining
quality.
Another
thing
that
Preston
does
is
they
make
sure
that
they
use
CI
so
that
every
time
somebody
actually
contributes
something
to
make
sure
that
they
actually
submit
a
test.
If
it's
a
new
feature
or
some
other
projects
that
we
do
also,
if
somebody's
actually
doing
a
feature
that
requires
documentation,
they
were
not
going
to
accept
the
pull
request
until
the
docs
are
updated.
This
is
a
good
forcing
function.
It's
a
good
discipline
that
you
want
to
have.
A
And,
lastly,
you
want
to
think
about
scaling
and
support
in
an
intelligent
fashion,
because,
usually
especially
if
your
project
becomes
popular,
you
just
don't
have
enough
time.
We've
talked
about
maybe
actually
promoting
people
to
help
with
the
contribution,
but
there
might
be
other
things
that
you
can
use
to
make
things
a
lot
easier.
For
example,
press
two
again
they
have
certain
style
guides,
so
sometimes
you
might
be
kind
of
like
battling
on
a
pull
request
with
somebody
because
they
had
a
spelling
error.
They
didn't
follow
your
guidelines,
so
what
Prester
does?
A
Is
they
use
CI
to
allow
them
to
look
at
make
sure
that
an
incoming
for
request
is
actually
satisfying
the
style
guide
and
they
and
then
so
that
goes
back
and
forth,
so
they
don't
even
have
to
actually
look
at
a
pull
request
that
didn't
actually
pass
that
test.
That's
a
really
good
way
to
kind
of
like
lower
the
support
overhead
documentation.
L
is
obviously
key.
A
You
can
actually
lower
your
overhead
if
you
just
write
good
docs
and
so
don't
underestimate
the
importance
of
documentation
react
native,
which
you
also
talked
about
before,
so
they
do
a
really
good
job
they
actually
using
github
web
hooks
along
with
all
the
different
labels.
They
have
a
way
of
kind
of
managing
the
process
flow
so
that
an
incoming
pull
request
is
very
easy
to
know
who
needs
to
look
at
it.
It's
integrated
with
some
of
our
internal
tools
and
also
our
code
sync
tools.
A
So
it's
very
easy
for
them
to
actually
manage
a
pull
request
and
make
it
more
efficient.
It
makes
the
contributors
the
people
who
are
maintaining
the
code
much
more
likely
to
go
out
and
look
at
incoming
issues,
and
it
makes
everything
work
that
much
faster.
So
these
are
some
of
the
things
and
some
of
the
tips
that
I
would
say.
Would
you
could
take
a
look
at
two?
If
you
want
to
make
sure
that
you
are
actually
maturing
and
growing
your
community.
B
So
we
take
those
tips
about
supporting
our
community
and
we
look
at
them
through
the
lens
of
a
open-source
security
project.
We
said
be
open
right,
but
part
of
that
means
trying
to
facilitate
these
private
conversations.
We
mentioned
before
to
be
sensitive
to
everyone,
that's
using
your
your
tool,
so
for
us
that
means
being
putting
time
on
our
schedule
so
that
we
can
jump
on
a
VC
with
folks
right
putting
time
on
our
schedule.
B
So
we
can
open
up
a
private
slack
channel,
have
a
conversation,
that's
just
one
on
one
between
us,
the
development
team
and
ask
the
team,
that's
using
the
tool,
OS
query
and
the
team
that
wants
to
deploy
it
right
and
not
trying
to
put
a
lot
of
pressure
on
those
folks
to
then
put
their
feature
requests
back
in
to
get
up.
We
would
love
for
them
to
do
it,
but
we
want
them
to
do
it
in
the
right
way.
B
Prioritizing
these
features
will
allow
us
to
evaluate
them
against
what
we
want
to
do
for
facebook
right.
So
this
is
a
tool
that
we
built
in
the
open.
What
our
primary
customer
is
Facebook,
we
will
drive
all
of
the
future
requests
until
someone
else
puts
a
feature
request
and
I.
Think
that's
the
breaking
point
facilitate
the
private
communication,
the
sensitive
communication
until
it's
something
that
they
want
to
put
onto
our
release.
Schedule
at
that
point,
then
it's
time
to
bring
it
into
the
open,
so
we
can
evaluate
it
against
every
other
feature.
B
The
mentor
new
contributors
is
kind
of
hard
mentoring.
New
contributors
to
a
security
project
is
like
park.
You
don't
want
people
that
are
new
to
the
code
base,
putting
things
in
that
might
be
vulnerable
right.
This
is
a
security
tool.
We
have
an
air
of
confidence
that
we
have
to
exceed.
People
are
very
critical
of
us.
B
We
don't
want
kind
of
people
new
to
the
programming
language
new
to
the
stock,
submitting
code
so
to
choose
very
carefully
who
we
want
to
mentor
and
that's
as
easy
as
inside
the
issue
or
inside
the
pull
request,
asking
them
how
big
of
a
deployment
you're
you're
managing
right
is
this
feature
going
to
affect
tens
of
thousands,
hundreds
of
thousands
of
machines
or
people
and
also
how
much
time
on
your
schedule
do
you
have
to
give
back
to
us
right?
What's
your
position
of
the
company?
B
Is
your
company
investing
as
your
managers,
your
directors,
your
CSO
ciso,
investing
in
this?
The
answer
is:
yes,
that's
awesome
right,
we'll
choose
to
definitely
mentor
that
person.
So
looking
all
looking
through
this
lens
of
the
six
months
and
one
year
criticism,
you
know
we
now
measure
this
engagement
differently
right
for
us.
Someone
asks
us
to
jump
on
a
VC
so
that
we
can
talk
about
how
we
use
OS.
Query,
that's
phenomenal!
That
will
make
our
week.
B
B
The
other
thing
I
want
to
talk
about
is
like
this
pull
request.
Gives
me
the
same
endorphin
rush
right
or
when
I
can
click
merge
I
have
that
same
feeling
of
jumping
on
a
VC,
so
we
still
want
to
optimize
for
pressing
this
all
day
right
and
that's
just
at
the
right
point.
So
we
have
these
VCS.
When
we
talk
about
the
security
tools,
we
we
say
hey.
We
want
you
to
also
invest
back
in
us,
the
time
that
you're
putting
into
this
project.
B
We
would
like
to
capture
it
in
the
repo
and,
if
that's
just
you,
opening
up
an
issue
saying
how
you
use
it
later,
once
you've
gotten
all
the
sensitivities
out
of
the
way
or
you
can
write
up
a
little
use
case
for
our
documentation
drop
it
right
in
line
with
the
repo
so
that
we
can
hit
this
pull
request,
it's
a
great
feeling
for
them
right,
so
we
tell
them
like
hey.
This
could
be
just
advice
for
deployment
infrastructure,
documentation
or
how
you
could
harden
your
infrastructure.
B
These
are
all
valid
things
to
throw
up
as
a
pull
request,
so
we
can
hit
this
merge
button,
and
then
we
use
our
awesome
open-source
team
to
give
us
these,
like
CLA,
signed,
approved
in
process.
This
is
like
our
workflow.
This
is
our
software
engineering
workflow
we're
going
to
abstract
away
from
them,
so
they're
not
going
to
have
to
be
burdened
by
it.
B
If
they
got
that
same
endorphin,
rush
from
us
hitting
merge
pull
request,
then
we
tell
them
about
these
priorities
like
give
us
that
wishlist
like
rant
to
us,
tell
us
what
you
would
love
to
see
how
this
tool
and
let's
put
a
bug,
let's
put
a
triage,
let's
put
a
wish
list
tag
on
it,
so
we
know
how
to
evaluate
against
everything
else.
Right
and
now,
you've
captured
this
person.
They've
submitted
no
code,
they
were
definitely
part
of
your
community.
B
You
definitely
want
to
support
them,
and
now
their
name
is
on
the
project
right
now
they
want
to
see
it
succeed.
Now,
they're
going
to
start
jumping
in
supporting
other
features,
doing
things
like
newsletters.
That's
amazing!
That's
when
that's
how
you
build
your
secure
community
around
security
software
right
so
about
two
minutes
left
we're
going
to
kind
of
close
now
and
ask
her
some
questions.
Does
anyone
want
to
jump
up
here?
I
know
we
don't
have
a
mic
to
pass
around,
but
if
you
have
a
burning
question,
please
come
ask
us.
B
A
B
B
Cool,
so
the
question
was
like:
what's
the
process
inside
Facebook
to
get
a
product
open
source?
Is
it?
Is
it
difficult
right
so
they're,
probably
too
starting
points?
One
is
you're
already
developing
this
thing.
It's
already
sing
at
work
in
production
at
Facebook,
and
you
think
it's
now
time
to
give
it
back,
give
it
to
the
community.
B
A
So,
if
usually,
what
happens
is
teams
are
going
to
come
in
and
we've
got
a
tool
which
asks
them
a
whole
bunch
of
questions,
including?
Why
do
you
want
to
open
source
and
then
ask
them
about
dependencies,
a
certain
set
of
questions
that
we
ask
them
and
then
it
kind
of
goes
through
like
okay,
it's
good.
A
It
sounds
like
a
good
idea
to
then
legal
takes
a
look
at
it
and
says
thumbs
up
and
then
after
that,
mostly
the
process
after
that
is
just
getting
the
code
ready
for
open
source,
which
again
means
just
removing
a
lot
of
Facebook
dependency
and
that's
a
coding
pot
when
they're
ready
to
go.
We
just
help
them
with
any
marketing
material,
any
social
media
campaigns
if
they
need
it
and
then
you
ship
it
out
the
door,
and
then
we
tell
them.
The
work
has
just
begun.
Yeah.
B
Because
then
bot
will
subscribe
to
your
repo
Facebook
bots.
That
will
tell
you
if
an
issue
hasn't
been
responded
to
in
30
days
and
start
sending
you
tons
of
pings
and
SMS
a--'s
and
messages
on
facebook.
So,
like
you,
definitely
need
need
to
start
doing
work
for
us
for
it.
The
security
team
we
kind
of
had
to
align
it
to
our
mission
of
defending
facebook.
B
We
kind
of
wanted
to
borrow
the
same
thing
that
we
saw
from
the
developer
community
and
that
they're,
putting
like
development
libraries
out
there
open
source
and
attracting
people
who
already
have
some
familiarity
with
this
and
are
seeing
as
a
reason
to
want
to
come
and
join
facebook.
We
want
the
same
thing
right.
We
want
to
put
security
tools
out
there,
get
like
awesome
security
people,
awesome
defenders
to
see
those
tools
and
have
that
same
feeling
want
to
come
work
for
us
and
once
we,
you
know,
hire
them.
B
A
B
It's
a
great
question,
so
G
log
is
a
good
one.
I
wanted
to
put
up
one
pull
request
to
G
log,
so
email
open
source
at
facebook.com/.
They
look
at
the
commit
and
they
say
yes
and
then
email
them
again
and
go
I've
got
about
five
more
like
do.
You
want
me
to
continue
to
send
it
and
they're
like
oh,
we'll,
take
a
step
back
they'll
do
a
more
extensive
search,
whether
it's
appropriate
for
me
to
continue
to
post,
commits
to
do
log,
and
in
that
case
they
said.
B
Yes,
my
name
goes
on
an
internal
wiki
of
projects,
two
people
working
on
it
and
now
I
have
the
ability
to
continue
to
submit
to
g
log,
and
it's
the
open-source
teams
responsibility
to
continue
to
monitor
my
mic
commits
to
make
sure
I
don't
start
invalidating
licenses
or
do
any
of
that
legal
stuff
right.
So
it
push
the
burden
on
our
open
source
team
in
our
legal
team.
Yeah.