►
Description
Presented by Mario Rodriguez, Senior Director of Product Management (GitHub)
Learn best practices and features you can leverage to efficiently manage GitHub at an enterprise scale. From SAML SSO to group management, to security and compliance, this session has you covered.
About GitHub Satellite 2019
A community connected by code
Explore our interconnected community—and how collaboration turns ideas into innovations.
Join us in November at San Francisco's Palace of Fine Arts for GitHub Universe - https://githubuniverse.com/
A
My
name
is
Mario
Rodriguez
and
I'm,
a
head
of
product
for
the
enterprise
queue
of
get
up.
So
if
you
have
any
questions
and
concerns
about
github
Enterprise
itself,
please
find
me
after
the
talk
I'm,
very
good
at
listening,
and
in
fact
you
know,
my
URI
of
my
job
is
actually
going
out
there
and
meeting
customers
and
kind
of
translating
that
into
a
vision
and
strategy
and
the
execution
of
the
product.
So
thank
you
so
much
for
being
here
today
before
we
go
deeper
into
the
talk.
A
A
Actually
it
was
more
like
sessions
of
video
games
and
then
coding
sessions
of
video
game
and
decoding.
But
you
know
like
the
reality
of
it.
Is
we
don't
act?
We
cannot
do
it
with
the
support
before
the
waterline
and
with
the
support
of
everyone
over
here
as
well.
So
the
announcements
and
there's
a
lot.
If
you
actually
been
to
other
satellites,
you
will
notice
that
this
one
is
kind
of
action-packed.
A
lot
of
things
that
we
announced
on
security,
my
favorite
one
is
the
dependable
I've
been
talking
to
grey
for
a
long
time
now.
A
It
seems
you
know
about
about
that
product
about
the
feature
about
the
laws
that
people
have
with
it,
and
then
we
talked
a
little
bit
about
enterprise
and
you
can
see
their
enterprise
accounts.
Internal
repos
are
is
mainly
for
inner
sourcing
to
our
new
roles
and
permissions
and
insights
all
the
way
to
community
tribution
in
everything
in
beholden
sponsors.
So
I'll
add
there
again
after
the
talk
you
could
find
me.
I
could
probably
talk
about
any
of
those
items.
A
If
you
didn't
go
to
the
other
talk,
so
I
want
to
get
more
details,
then
we
could
actually
do
that
as
well.
So
that's
that's
kind
of
a
summary
of
it.
So
within
Enterprise
for
us
in
enterprise,
it
actually
starts
with
trust.
That's
the
Meyer
II
of
the
conversations
that
I
go
into
there's
a
little
bit
about
features
a
little
bit
about
transformation.
A
You
can
see
a
little
bit
there
about
tokens,
discover
in
public
repos,
28
million,
which
is
kind
of
interesting,
that
we
discover
secrets
20
million
times,
but
we're
actually
adding
value,
and
hopefully
that
number
continues
to
go
down,
not
not
up
that.
That's
one
of
the
metrics
that
we
actually
try
to
not
increase,
instead
of
because
we're
probably
not
doing
the
right
thing
at
the
end.
So
I
will
give
you
more
features
in
there
too.
For
that.
So
the
talk
today
it's
about
scale,
but
you
might
be
asking
yourself:
ok,
Mario!
A
There's
you
have
to
kind
of
ways
to
deploy
github
Enterprise.
Today
you
have
the
server
product
and
you
have
the
cloud
product.
When
it
comes
to
the
cloud
we
manage
all
these
scaling
for
you
all
of
the
other
scaling.
So
like
we
could
probably
spend
5
milliseconds
on
that,
and
maybe,
after
that,
we
will
have
to
talk
about
bid,
comes
price
or
something
else.
So
then,
on
server,
it's
a
little
bit
more.
A
All
we
have
to
do
is
kind
of
put
it
over
here,
hit
this
button
and
it's
up
and
they
say,
and
it
took
them
longer
actually
to
research
that
we
were
telling
the
truth
that
it
took
them
to
set
up
the
appliance.
So
it's
pretty
easy.
So
the
talk
is
really
not
about
how
to
scale
of
your
infrastructure
and
all
of
those
type
of
things.
There's
a
lot
of
great
content
out
there
on
it.
What
I
really
really
want
to
talk
about
when
it
comes
to
scale?
A
It's
really
how
to
scale
your
organization
and
the
practice
of
you're
gonna
session
on
github.
So
there's
three
things
that
when
I
go
to
an
enterprise,
I
get
asked
continuously
about
one
is
you
know
we
want
to
use
more
open
source?
How
can
we
do
that
effectively?
How
can
we
both
consume
and
how
can
we
contribute
more
effectively?
In
fact,
one
of
the
you
know
the
features.
A
A
lot
of
people
run
right
now
is
just
being
able
to
actually
take
a
public
repo
and
then
put
it
in
a
github
instance
servery,
on-premises
and
and
had
that
fort,
actually
work
very
well,
but
you
know
they
want
to
consume
the
one
I
utilized
and
they
want
to
contribute
in
a
seamless
way
with
open
source.
Now,
how
can
you
actually
do
that
at
scale
really
with
one
repo
it
works
by
hugging?
Do
it
at
scale
what
what
are
the
things
that
need
to
happen
to
do
that
there
then
there's
collaboration
and
inner
source?
A
How
should
I
actually
be
studying
on
the
structure
of
my
github
enterprise
internally,
to
all
our
collaboration
to
faster
I
was
talking
to
another
customer.
They
had
three
servers.
Very
hard
for
actual
collaboration
to
happen
in
three
different
servers
with
three
different
set
of
identities
and
all
of
that
and
then
the
last
one
is:
how
can
we
do
all
of
this
in
a
way
that
really
has
that
security
and
compliance,
because
I
am
an
enterprise
I
had
to
pass
audits?
A
I
have
to
you
know,
show
a
set
of
people
that
we're
doing
this
at
the
right
way
and
to
understand
if
there's
a
breach.
You
know
there's
a
lot
more,
that
I
ends
up
going
in
our
enterprise.
That
needs
to
be
met,
that
you
don't
get
that
maybe
at
the
OSS,
the
maintainer
level,
as
much
so
kind
of
my
life
revolves
around
making
a
set
of
you
know,
listening
trying
to
figure
out
what
everyone
is
doing,
trying
to
make
sure
there's
a
set
of
best
practices
around
it,
and
that's
really.
A
What
I
wanted
to
talk
about
today
is
what
are
those
set
of
best
practices
that
we're
recommending,
as
you
try
to
kind
of
scale,
your
the
amount
of
people
that
end
up
using
github
and
kind
of
within
those
three
pillars
and
and
themes.
So
the
first
thing
that
I
want
to
do
is
kind
of
talk
about
the
core
structure
of
how
to
help
things
about
an
enterprise
and-
and
really
you
know,
there's
a
couple
of
slides
over
here
that
are
really
really
important.
A
Some
of
them-
you're,
not
gonna,
agree
with
and
again
I'm
very
good
at
listening
and
taking
that.
But
this
is
what
we
see
as
best
practices
out
there.
So
the
first
thing-
and
this
is
new-
and
we
did
it
because
it
was
needed
to
actually
tell
their
story-
is
that
we
introduced
the
concept
of
an
enterprise
account
and
that
enterprise
account
actually
ends
up
being
able
to
manage
a
set
of
organizations
that
are
at
the
bottom.
So
if
you
think
about
github
enterprise
in
the
cloud,
you
might
have
multiple
works.
A
In
fact,
there's
very
good
reasons
to
have
multiple
orcs
in
organization,
and
you
want
to
kind
of
manage
them
holistically,
but
you
had
no
construct
no
way
of
doing
that
in
a
way
that
was,
you
know
a
lot
of
people
kind
of
wrote
scripts
and
then
hit
our
api's
and
did
a
bunch
of
hacks,
because
we'll
hackers
or
developers,
but
there
was
actually
nothing
helping
them,
and
you
know
we
needed
to
step
in
and
help
them
an
anti
Enterprise
account.
Is
that
so
when
should
you
then
have
organizations?
A
We
get
asked
this
a
lot
as
well,
which
is
should
I
have
one
or
should
I
have
two
works?
You
have
50
orcs
or
a
thousand
orcs,
and
what
we
usually
say
is
the
following:
we
don't
want
you
to
map
an
org
to
a
product.
We
see
sometimes
that
a
lot
like
okay
I
have
a
product.
Let
me
just
do
a
note
for
it
that
that's,
probably
not
the
right
granularity
level
for
it.
A
An
org
should
be
something
like
a
division
within
your
company,
or
a
set
of
things
are
grouped
together
in
some
type
of
theme,
so
a
set
of
products
are
grouped
to
getting
some
sang
with
some
type
of
theme
and
something
creating
that
organization.
And
again
sometimes
we
see
that
as
divisions
within
the
company
business
units,
sometimes
they
could
be
very,
very
small.
Sometimes
they
could
be
big.
There
are
times
that
you
want
to
keep
things
completely
private
and
having
an
org
that
allows
you
to
do
that
and
have
this
core
ability
of
everything
within
it.
A
Sometimes
we
see
these
old
names
in
github.com.
They
are
like
you
know:
1
2,
3,
F,
78
and
I'm
like
okay,
that's
probably
some
secret
project
that
they're
trying
to
do
but
organizations
think
about
it
as
business
units.
It's
kind
of
a
theme
of
that
pulls
together
a
set
of
products,
so
an
enterprise
account,
and
today
you
could
get
one.
If
you
talk
to
your
account
representative,
are
you
buy
and
you
have
your
help?
A
Enterprise
there's
a
way
for
you
to
actually
try
that
out
and
then
organizations
we
also
introduced,
which
I
don't
think
we
showed
I
wanted
to
demo
for
you
guys,
but
we
have
no
way
of
doing
demos
in
in
the
stage,
but
this
is
what
we
call
in
kind
of
admin
Center
for
that
enterprise
account.
So
why
you
see
in
here
is
all
of
the
organizations
that
belong
to
this
enterprise.
None
of
them
have
we
love
avocados,
so
I
get
hub.
A
So
there's
a
bunch
of
things
within
that
theme
there
and
you
see
all
of
the
organizations.
You're
gonna
see
the
description
a
little
bit
more
metadata.
This
is
kind
of
raw
on
purpose.
You
also
see
people
on
the
left-hand
side
there,
so
you're
gonna
be
able,
as
an
administrator
of
the
enterprise
you're
gonna,
be
able
to
go
into
that
people
tab
and
see
every
member
across
all
of
those
three
orgs
and
repos
that
you
have
in
your
organization's
every
member
of
them.
A
You
know
we
do
them
and
all
of
those
types
of
things
and
then
you're
also
gonna
be
able
to
manage.
Who
are
your
enterprise
admins?
Who
are
your
building
admins
and
a
couple
of
other
things
like
that?
But
you
know
that
people
tab.
Is
you
know
if
you
have
an
auditor
coming
in
and
says
who
has
access
to
github,
you
could
probably
go
to
the
people.
Tab
and
those
people
have
access
to
get
help
yeah.
A
So
so
that's
that
the
other
thing
that
you
see
in
it
is
this
concept
of
policies,
and
right
now
is
the
beginning
of
what
kind
of
division
of
policy
at
github
is
at
the
enterprise
level,
but
think
about,
like
you,
have
some
SDLC
or
software
lifecycle
management,
and
you
want
to
do
you
want
to
start
implementing
a
set
of
best
practices
and
a
set
of
policies
on
it?
We're
gonna
allow
you
to
do
that
at
the
enterprise
level.
Have
that
cascade
nicely
to
your
entire
set
of
organizations?
A
Underneath
we're
very
excited
about
that,
and
we
could
pick
out
later
on
everything
that
is
there
and
the
last
thing
is
just
a
set
of
settings
normal
stuff
that
allows
you
to
maybe
implement
single
sign-on
at
the
enterprise
level.
Manage
to
manage
buildings,
manage
what
hooks
and
things
like
that.
So
that's
that.
So
what
about
beneath
the
organization
how
she
would
be
thinking
about
it
so
tread
the
way
that
we
explain
it
usually
is
the
way
there
are
two
main
constructs
that
you
should
be
thinking
about.
A
There
are
products,
and
there
are
people
working
on
those
products
like
those
are
the
main
two
things
that
you
should
be
optimizing
for
inside
an
organization,
so
repos,
usually
map
to
products.
Now
there's
many
of
you
that
actually
practice
micro
services
and
they
might
have
multiple
repos
per
product
and
that's
perfectly
fine-
please
don't
make
it
a
hundred
repos
per
product
I.
A
And
then
we
want
you
to
represent
the
people
working
on
those
products
by
actually
utilizing
the
team
construct.
So
many
enterprises
actually
don't
utilize
it
and
it's
one
of
the
best
features
we
have
and
will
continue
investment
on
that
that
allows
a
significant
amount
of
value
so
think
about.
Okay,
maybe
there
are
squads,
maybe
they're.
A
You
know
they're
feature
teams
whatever
you,
you
kind
of
want
to
think
about
them,
so
you
put
them
in
a
team
and
those
are
the
people
actually
within
that,
and
then
you
add
those
teams
into
the
repos,
and
now
you
allowed
the
collaboration
to
happen.
That
way,
so
enterprise
account
and
probably
have
a
summary
slide.
Okay,
so
the
core
structure.
Essentially,
then,
is
this
an
enterprise
account
for
everything
managed
by
the
waying
ghe
server.
So
that's
our
premises
queue.
A
You
also
had
this
concept
of
an
enterprise
account
and
then
you're
going
to
be
able
to
use
it.
So
if
you
go
to
2.7
for
our
ghts
release
of
2.17,
which
you
just
announced
today,
then
you're
going
to
be
able
to
see
an
enterprise
account
in
it,
you're
going
to
be
able
to
see
all
of
the
orders
that
belong
on
it
and
then
kind
of
play
with
some
of
these
features
as
well.
A
In
addition
to
that,
you
could
even
connect
that
enterprise
account
on
your
server
to
an
enterprise
account
in
the
cloud
and
allow
kind
of
collaboration
to
happen.
That
way
does
through
a
gear
hub
Connect
feature
that
we
shipped
last
year
and
there's
more,
you
know
we
improved
it.
We
added
more
features
and
there's
more
value
coming
later
in
that
too,
so
we're
pretty
excited
about
that.
So
enterprise
account
organizations
to
group
products,
teams
to
to
group
people
working
on
those
products
and
then
kind
of
repos
for
your
products.
A
So
that's
kind
of
like
what
we
call
the
core
for
your
help,
and
you
know
there
are
times
we
should
do.
You
should
deviate
from
this,
but
please
maritime,
if
you
do
this,
as
we
add
features
to
the
product
you're
going
to
get
a
significant
amount
of
value
for
free,
because
you're
kind
of
mashing
what
we
determined
to
be
the
best
practice
out
there.
Okay,
so
after
you've
done
that,
then
I
want
you
to
think
about
layering
identity.
On
top
of
what
we
said,
this
is
one
of
the
hardest
things
that
github.
Sometimes
it's
a.
A
How
do
you
do
identity
management
and
there's
a
lot
for
us
to
improve,
keeps
me
up
at
night
at
times,
but
you
know
start
by
layering
identity
on
top
of
it,
and
what
do
we
do
by
that?
We
want
you
actually
to
use,
even
though
a
developer
and
every
github
member
uses
a
github
account.
That's
perfectly
fine,
but
in
the
cloud
that
give
up
account
actually
follows
them
through
jobs.
It's
kind
of
like
you
know,
for
the
majority
of
the
time,
it
searches
the
resume
as
a
developer.
A
So
if
I
started
on
company
a
then
I
moved
to
B
to
C
to
D
as
an
employer,
D
you're
gonna
be
able
to
kind
of
see
okay.
He
worked
in
all
of
these
things.
He
you
know
this
whole
contributions
to
open
source
and
all
of
that
so
cut
out.
The
github
account
follows
the
human
around
right,
but
the
reality
is
the
credentials
to
access
the
resources
of
an
organization
does
not
so
if
I
was
a
company
a
and
they
assigned
me
an
identity
with
an
email
and
I
have
a
password
for
that.
A
It's
very
different
than
my
give
up
one.
You
know
whenever
I
actually
leave
that
company,
then
my
identity
kind
of
disappears
from
that
those
credentials.
I
could
no
longer
use
them
right
because
I'm
no
longer
working
at
that
company
so
think
about
it.
The
same
way
like
I
want
you
to
think
about
that
enterprise
account
as
your
company
and
I
want
you
to
then
hook
that
up
through
samo
to
actually
the
identity
provider
that
you
have
in
your
organization,
the
identity
provided
that
determines
ok.
This
is
this.
A
You
know
human,
but
within
this
org
and
it's
very
different
under
personal
account
right
and
these
are
really
the
credentials
to
access
everything
that
let's
say,
avocado
Corp
has.
So,
if
you
do
that,
then
every
time
I
try
to
access
anything
within
an
organization.
I'm
gonna
get
SSL
I'm
gonna
get
single
sign-on
with
with
that
identity
provider
and
then
I
could
then
put
the
credentials
of
avocado
Corp
in
it
and
then
I'm
in
and
if
I
want
to
go
and
do
something
else
in
an
open
source
project.
They're,
not
gonna.
A
You
know
they're
not
going
to
ask
me
for
those
credentials,
so
I'm
gonna
be
using
just
my
github
account
and
and
kind
of
the
information
that
that
carries
so
again
layer
identity
at
the
enterprise
layer
before
we
had
it
at
the
organization.
You
know
now
we're
making
a
super
easy
to
do
it
at
the
enterprise.
A
Then
after
that
I
want
you
to
think
about.
We
recently
release
a
feature
to
allow
member
synchronization
into
a
team,
so
I
layer
that
you
know
I
later
identity
at
the
enterprise
level
and
then
after
that,
then
what
I
want
you
to
do
is
say.
Usually,
if
you
have
an
application
you
what
you
want
to
do.
Is
you
want
to
go
to
your
identity
providers?
In
a
group?
It's
probably
usually
a
security
group.
You
ID
be
a
developer
and
by
doing
that,
they
get
access
to.
Maybe
you
know
github.
A
They
may
get
access
to
JIRA
some
Jenkins
stuff.
Some
other
kind
of
providers
that
you
have
to
network
shares
to.
You
know
a
lot
of
entitlements
at
the
and
you're
managing
all
of
that
through
one
groove
and
it's
great,
actually
it's
great
for
auditability,
because
now
you
know
that
if
I
remove
that
person
from
that
groove,
they
lose
access
to
that
application
and
everything.
You
know
it's
not
just
github,
but
it
lose
access
to
every
other
service
as
well,
so
we
want
to
participate
as
part
of
that
ecosystem.
A
So
one
of
the
things
that
we
will
release
on
my
seventh
and
now
we're
making
publicly
available
in
a
beta
format
is
the
ability
to
sync
membership
from
that
identity
provider
group
into
a
github
team.
So
again,
when
you
add
that
person
in
it
automatically
gets
added
to
the
team,
they
have
access
to
what
they
needed
to
when
you
that
person
leaves
that
team
and
then
goes
to
another
group
within
your
company
if
they
actually
let
the
company
that's
easier
because
there's
other
ways
to
the
provision,
the
user.
A
But
let's
say
that
person
doesn't
need
access
anymore.
You
remove
them
from
a
team.
We
have
a
job,
a
background
job
that
ends
up
doing
the
sync,
and
then
we
remove
them
from
that
team
and
they
don't
have
access
then
to
those
repos
anymore,
so
think
about
it.
That
way,
so
I
want
you
to
layer,
identity
at
the
top
and
kind
of
separate
the
credentials
of
your
organization
from
the
github
account
at
the
end.
A
I,
don't
want
you
to
force
that
human
to
create
two
github
accounts,
the
one
it's
not
very
nice
for
them,
and
the
other
thing
is
it's
just
not
sustainable.
To
do
so.
I
wanted,
you
think
about,
like
you,
know,
put
SSO
on
it
and
use
the
credentials
of
your
organization
and
then
do
team
sync.
It
would
actually
save
you
a
lot
of
time
and
that's
what
we
did
that
feature.
Okay,
then
third,
thing
is
kind
of
think
think:
a
lot
about
access
control
and
what
are
the
rules
that
you're
gonna
support?
A
Today
we
announced
two
new
roles,
the
triage
role
and
think
about
three
edge.
As
you
know,
you
don't
get
commit
access
and
it's
not
you
know
the
my
unit
at
the
time.
People
think
is
about
trust,
and
it's
not
about
trust.
It's
not
like
that
person
doesn't
trust
them.
Although
there's
probably
a
lot
of
developers
in
my
team
that
don't
trust
me
to
actually
have
real
access
to
a
repo,
and
we
have
some
one
of
them
over
here.
But
it's
it's
my
real
time.
A
It's
not
really
about
trust
is
really
about
scenarios
like
if
you
are,
for
example,
if
you're
a
maintainer,
and
you
want
to
get
help
from
someone
to
triage
in
issues
being
able
to
actually
do
labels
and
things
like
that.
You
want
to
extend
that
to
them,
because
that's
what
they're
going
to
be
mainly
doing
and
they
don't
need
access.
It's
kind
of
like
separation
of
concerns
a
little
bit
right.
They
don't
need
access
to
it
like
it's
very
scenario,
driven
same
thing
in
the
enterprise.
A
A
But
it's
really
about
kind
of
editing
descriptions
you
know
being
able
to
maintain
a
set
of
things
force,
push
into
a
branch
there's
a
set
of
permissions
in
it
right
now,
we're
in
beta,
so
there's
three
of
them
coming
in
and
then
three
after
once
we
g8
the
feature
but
think
about
access,
control
and
rules.
You
could
envision
that
the
next
step
for
us
to
do
is
to
really
provide
you
the
way
to
do
custom
roles
and
have
full
control
of
it.
A
So
if
you're
following
the
course
structure-
and
then
you
know
when
we
introduce
a
set
of
features
to
allow
more
granular
permissions
and
fine-grained
permissions,
then
you're
going
to
be
able
to
use
those
features
very
seamlessly,
so
think
about
your
access
control.
My
real-time
be
thinking
about
them
as
as
our
back
or
roles,
it
kind
of
simplifies
the
model
a
lot,
but
will
give
you
flexibility
if
you
don't
want
to
actually
think
about
it.
That
way,
Tim!
A
So,
just
a
quick,
then
summary
on
everything
we
discussed
sam'l
with
single
sign-on
at
the
enterprise
IDP
with
2fa
I,
know,
you're
thinking
actually
I
was
in
a
conversation
when
our
customer
today,
what
we're
seeing
right
now
in
the
industry
is
that
people
are
not
relying
on
github
to
do
2fa
they're,
relying
on
their
identity
provider
to
do
that
to
a
PHA.
So
when
you're
setting
up
sam'l
and
single
sign-on,
you
know
if
your
identity
provider,
you
know,
allows
you
know
to
FA
you
automatically
get
to
a
Facebook
or
on
it.
A
A
After,
like
all
of
them,
I,
think
supported,
then
you
can
even
hook
up
with
an
app
like
duo
or
with
a
service
like
duo,
for
example.
That's
what
at
the
end
as
well.
So
please
think
about
it.
Now
that
github
level
think
about
it
at
the
identity
provider.
There's
a
lot
of
efficient
identity
provider
supports
you.
A
External
collaborators
are
tricky,
we're
not
doing
anything
right
now
on
it,
but
I
will
tell
you
like
every
time
I
go
into
an
enterprise,
it's
probably
a
five
to
ten
minute
conversation
about
external
collaborators
and
what
we
should
be
doing
there.
The
the
thing
that
I
will
tell
you
towards
the
future
is
have
a
way
to
represent
them.
A
Guys
is,
if
you
have
a
way
to
say
these:
are
the
external
collaborators
or
the
inverse
of
it
and
say
these
are
these?
Are
all
the
people
that
I
trust
in
a
given
boundary
that
are
not
the
external
collaborators
so
think
about
them?
You'll
hear
more
from
us
in
the
coming
months
on
that
set
up
your
team
synchronization
with
your
IDP
and
understand
access
roles,
so
open
source.
There
are
two
ways
they
to
think
about
open
source
and,
in
my
opinion,
it's
not
a
religious
debate.
A
I,
like
both
sides,
have
a
equally
good
argument
on
this.
I
see
two
core
ways
to
set
it
up
in
an
enterprise,
as
specifically
when
you're
in
the
cloud
right,
because
open
source
and
on
server
that
doesn't
really
mean
anything
because
there's
no
community
in
there
for
that,
so
that's
more
like
inner
source,
but
you
could
create
one
org,
which
is
your
brand,
where
all
of
your
SS
projects
are
going
to
be.
A
So
again
you
have
an
enterprise
account,
but
you
have
one
org
that
it's
gonna,
be
your
branded
OSS
org,
like
all
of
the
projects
that
wanna
be
OSS,
need
to
be
there.
So
that's
one
path
that
path
actually
I've
seen
it
be
extremely
successful
and
scale
very
well
for
the
most
part,
then
there's
another
one
that
you
could
utilize
to
wishes
know
like
I,
don't
want
that
central
management
I
want
to
just
say:
I,
have
an
org
I
want
to
use,
put
a
public
repo.
A
So
if
I
have
five
orgs
and
I
have
five
public
repos
for
open
source,
then
I
have
500
words
and
500
dribbles.
It
could
actually
work
as
well
there.
You
know
there
are
ways
that
you
could
add
the
org
level
say
you
know,
repo
admins
can
not
get
do
not
have
the
ability
to
take
a
project
public.
They
need
to
pass
through
the
org
owner.
So
there's
ways
to
actually
do
that.
The
right
way.
The
thing
that
I
have
found
is
to
kind
of
items
that
become
interesting
over
here.
A
One
is
that,
once
you
have
a
lot
of
words,
this
system
starts
getting
a
little
bit,
not
as
systemic
as
it
should
be
and
number
two,
the
customer
itself
and
so
being
going
through
a
lot
of
brands
of
your
company
to
be
able
to
enter
interact
with
your
company,
and
some
people
are
good
with
branding
their
open-source,
repos
and
stuff
some
people
or
their
organizations.
Some
people
are
not,
and
things
like
that.
A
And
we
see
that
a
lot
and
the
only
way
that
they
were
able
to
make
it
successful
is
by
actually
having
a
program
office
for
it.
So
if
you're
in
an
enterprise-
and
you
don't
have
a
program
office
and
you
when
I
use
and
both
consume
and
contribute
to
open
source,
think
about
creating
a
program
surface
on
it.
Jeff
Macke
Hoffer
from
github
is
here.
He
used
to
run
the
off
program
office
at
Microsoft.
A
Yes,
a
ton
of
information
how
to
take
a
company
that
many
people
thought
that
hated
open-source
to
what
it
is
today,
which
is
one
of
the
biggest
contributors
of
open-source
so
and
then
the
last
thing
is
kind
of
what
open
source
are
you
using
right
so
right
now,
I'm
just
showing
over
here
some
of
the
org
insights,
the
open
source
that
you
using.
But
another
thing
is
a
kind
of
figuring
out
what
you
have-
and
this
is
not
actually
the
long-term
right
view
for
what
your
hope
should
be
providing.
A
But
it's
kind
of
like
the
closest
thing
that
we
have,
but
it's
a
dual
thing
is:
what
open
source
are
you
using
I
was
everything
that
is
being
open,
source
and
being
able
to
actually
figure
out.
You
know
what?
How
can
you
improve
on
both
sides
of
the
equation,
so
kind
of
be
thinking
about
that?
There's
a
lot
more
EPS
I
wanted
to
give
you
to
be
able
to
do
that
effectively.
A
But
if
you
want
to
increase
open
source,
have
enough
installed
open
source
program
office
and
then
figure
out
exactly
how
much
you're
consuming
how
much
you're
actually
contributing
as
well.
So
that's
that-
and
we
only
have
eight
minutes
so
time
goes
by
fast,
so
I
go
faster,
so
inner
source.
So
we
have.
We
announced
internal
repos
today.
So
the
way
I
wanted
to
think
about
it
in
the
cloud
today,
if
you
were
using
github
Enterprise
Cloud,
you
had
only
two
visibility,
private
or
you
had
public
public
means
open
source.
Everyone
can
see
it.
A
There
was
nothing
like
Shopify
said
we
want
to
be
open
by
default.
There
was
no
way
for
them
to
do
that
unless
they
hacked
everything
around
it
by
creating
this
team
and
then
having
everyone
in
a
repo
on
it
and
all
of
that,
so
we
what
we're
doing
right
now
is
enabling
every
company
that
wants
to
do
open
by
default.
To
do
that,
but
you're
saying
you
know
what
every
repo
that
you
get
started,
especially
frameworks,
and
things
like
that
should
be
internal
by
default,
and
that
means
everyone
in
your
enterprise
can
see
it.
A
You
don't
need
to
add
them
as
members
or
anything
like
that,
you
that
person
can
fork
the
repo
can
contribute
pull
request.
If
that
person
leads
the
company,
we
delete
the
fork
from
their
personal
account,
so
everything
kind
of
is
covered
on
it,
but
this
is
kind
of
the
foundation
of
what
we
calling
inner
source,
an
inner
source
at
scale
at
a
company,
a
lot
more
plan
on
this
area,
so
we're
super
excited
to
actually
take
the
first
step
towards
it
in
our
cloud
product
today.
A
One
thing
that
I
did
go
over
their
mash
incentives
to
code,
reuse,
we've
seen
a
lot
of
companies
say
we're
open
by
default,
but
they
their
culture
does
not
incentivize
at
all.
Meaning
me,
a
developer
will
get
paid
more
if
I
don't
reuse
that
if
I
would
reuse
right,
so
you
do
have
to
think
a
little
bit
about
culture
when
it
comes
to
inner
sourcing.
So
you
just
don't
think
about
it.
As
okay,
we
haven't
turned
our
rebus,
not
everything
is
gravy
so
and
then
the
other
thing
is
organization,
insights
and
this.
A
Well,
this
allows
you
to
do
it's
kind
of
understand.
You
know
many
people
by
github
in
order
to
transform
right,
like
github,
is
not
really
just
a
git
repository.
You
know
management,
there's
plenty
of
them
out
there
and
to
tell
you
to
if
you
helped
Enterprise
a
premium
product.
So
if
you're
gonna
compare
the
pricing,
we're
not
even
gonna,
be
close
to
some
of
the
people
just
offering
get
hosting
so
we're
really
a
platform.
A
You
know
in
this
planet
scale
and
it,
but
it's
a
really
a
cloud
I'm,
sorry,
a
collaboration
platform
at
the
end
that
offers
significantly
more
than
just
raw
SCM,
so
many
people
when
they
adopt
github
what
they
want
to
see
is
a
transformation
of
their
practices.
There's
a
set
of
them
that
don't
do
code
reviews,
for
example,
and
the
one
I,
or
do
them
in
only
two
teams,
and
they
want
to
kind
of
say
everyone
should
be
using
them,
and
this
is
the
way
kind
of
going
forward.
A
You
know
pull
request
code
reviews
and
all
of
that,
so
this
allows
you
to
actually
get
insights
on
it.
Another
thing
that
we've
been
very
surprised
by
how
people
are
thinking
about
is
top
languages
that
across
all
of
the
repos
they
use.
So
what
this
allows
you
to
do
is
say
you
know
what
there's
some
people
actually
using
rust
or
Russ
is
gaining
traction
in
my
organization
and
she
probably
hire
more
Ross
developers
right,
like
as
you
get
ahead
of
that
talent
curve
as
much
as
possible.
A
So
if
they
leave
the
company
I
could
still
you
know,
management
applications
so
so
from
an
in
resource
perspective.
Please
use
that
internal
brief
of
visibility.
Think
about
humans,
like
incentives,
all
of
us
do
they
were
motivated
on
both
intrinsic
and
on
intrinsic
ways
and
then
forced
a
foster
internal
communities
and
then
understand
how
everything
is
getting
used
from
a
github
perspective.
A
So
last
thing
actually
two
more
things:
security
and
compliance.
I
talked
a
little
bit
about
the
admin
Center
at
the
enterprise
level.
There
is
a
feature
there
that
is
pretty
powerful,
which
is
hooks,
so
you
could
actually
end
up
subscribing
to
hooks
and
get
notified
about
events
across
all
of
your
organizations.
So
now
you
don't
have
to
have
now
one
app
is
installed
in
each
one
of
them.
You
don't
have
to
configure
every
time
you
set
up
an
org
to
actually
you
know
be
able
to
receive
those
hooks.
A
You
could
just
do
it
at
the
enterprise
level
collect
that
data
eventually
we'll
hook
up
that
with
actions
and
allows
you
to
actually
do
something
from
an
LC
LC
perspective
enforce
policy
from
that
central
location
that
admin
Center,
and
then
it
allows
you
to
see
all
other
people
as
well.
Another
feature
that
was
not
announced,
you
didn't
see
it
in
there,
but
it's
also
new
and
we're
very
excited
about.
It
is
our
audit
log
API.
We
added
this
mainly
for
those
cyber
teams
and
those
compliance
scenarios.
A
So
now,
you're
gonna
have
an
API
against
cloud
that
it's
going
to
give
you
a
bunch
of
rich
data
about
the
events
that
happen
within
an
organization,
and
we
are
a
lot
of
metadata
there.
So
we're
gonna
publish
a
little
bit
more
and
sort
of
best
practices,
some
how
you
should
be
thinking
about
that,
but
you
know,
monitor
you're
out
of
luck.
That's
a
good
practice!
New
API
would
last
metadata
is
an
announcement
that
we
made
today
and
then
alert
and
have
a
remediation
plan
when
you
have
alert.
A
So
if
someone,
you
know-
and
you
see
some
activity-
sometimes
that
someone
use-
let's
say
a
path
against
a
repo
and
they
downloaded
it,
and
then
you
know
20
seconds
later
they
try
to
download
all
the
repos
in
your
organization,
like
you
should
be
able
to
detect
that
very
quickly
and
figured
out
a
way
to
remediate.
In
fact,
we
also
release
as
far
the
enterprise
work,
an
API
to
revoke
a
path
anytime.
A
You
see
it
being
used
in
a
way
that
is
malicious
and
we
have
a
way
now
to
disable
that
path
across,
and
you
know
all
of
the
repos
in
your
organization
as
one
so
play
around.
With
this
give
us
feedback.
We
also
talked
a
little
bit
about
from
a
security
perspective
about
dependencies
and
getting
inside
in
those
dependencies
making
use
of
kind
of
automatic
fixes,
and
all
of
that
you
know
you
could
go
with
why
github
provides
you.
We
have
two
great
partners
in
white
shirts
and
sneak
as
well.
A
That
can
you
know
are
actually
be
able
to
provide
a
little
bit
more
security
on
your
dependency
management.
So
but
the
biggest
thing
for
me
to
stress
on
that
is
get
clean
and
stay
clean.
That's
one
of
the
things
that
enterprises
struggle
I
with
that
is
super
important
as
you
go
forward
and
you
want
to
scale
it
across,
then
the
last
things
is
get
out.
Server.
I
do
have
a
couple
of
slides
on
this.
A
What
I
would
tell
you
is
our
appliance
set,
loves,
loves
this
Kyle,
like
it
consumes
them
like
incredibly
incredible
amounts
of
time,
so
you're
gonna
be
resource
constrained
at
the
appliance.
At
any
point,
it's
probably
gonna,
be
your
desk
so
buy
the
best
SSDs
that
you
could
buy
at
this
moment
or
deploy
to
the
cloud.
You
know
cloud
providers
usually
start
getting
better
and
better
about
their
SOC
throughput.
A
It
allows
you
to
actually
scale
as
well,
but
this
guy-
oh
so
if
you,
if
you
have
ideal
of
enterprise
server
this
guy,
oh
it's
gonna,
be
the
best
thing.
Don't
make
your
developers
actually
have
slow
experiences?
Give
up
invest
a
lot
of
you
know,
sweat
and
tears
on
actually
being
the
most
performant.
You
know
application
out
there,
and
you
know
it's
because
in
without
this
you're
not
gonna
be
able
to
provide
that
experience
to
your
developers
internally.
A
So
please
buy
good
as
as
these
they're,
not
that
expensive
so
and
then
take
advantage
of
our
build
team
monitor
and
are
learning
a
lot
of
people.
Don't
know
that
we
have
built-in
monitor
in
the
appliance
and
then
end
up
doing
all
of
these
things
are
redundant.
So
please
take
advantage
with
those
help
dogs
and
do
the
right
thing
there
and
then
the
last
thing
is
high
availability
github
for
the
majority
of
the
enter
process.
It
cannot
be
down
like
an
hour
down
of
github
means
at
times
millions
of
dollars
in
developer.
A
Spend
you
know
one
of
one
of
our
customer
has
70,000.
You
know
users
on
one
of
these
appliances,
so
it
cannot
be
down.
High
availability
is
super
important,
so
there's
two
stages
on
that.
One
of
them
is
nothing
to
do
with
high
availability,
but
it's
like
you
have
a
set
of
backups.
Please
test
those
backups
as
well.
So
when
the
funny
event
happens,
you
have
a
way
to
have
a
run
book
and
be
able
to
restore
that,
and
all
of
that
quarterly
is
perfect.
A
If
you
don't
like
quarterly,
you
know
twice
a
year
is
good
too
or
use
our
high
ability
set
up
to
protect
against
software
crashes
and
anything
that
could
happen
within
the
appliance
and
understand
how
to
actually
do
that
fell
over
that's
what
we
see
the
moons
at
times
for
our
successful
customers
is
how
to
actually
do
a
highly
ability
with
one
active
you
know,
and
one
that
is
just
on
standby.
It's
not
really
active
active,
but
you
know
since
time
by
you
have
to
do
a
couple
of
other
things
and
then
bring
that
off.
A
At
the
same
time,
it
uses
replication
pretty
proud
of
the
work
there.
We
need
to
continue
to
improve
that
we're
never
done
with
those
type
of
features,
and
we
are
out
of
time.
So,
thank
you
so
much
for
everything.
So
it's
35
minutes.
I
walked
you
through
a
lot
of
it
happy
to
talk
to
you.
After
about
anything
that
is
top
of
mind
for
you.
So
thanks.