►
Description
"Make it better!" "Make it more secure!" "Deliver it quicker!"
Dev Teams used to be able to just choose two from the list above—but are coming under increased pressure to do all three.
While trying to move faster and produce better and more secure software, teams are usually slowed down by a variety of organizational and technical barriers.
Join Daniel Figucio, Field CTO at GitHub, and Faten Healy, Senior Solutions Engineer at GitHub, to highlight three common barriers to shipping software faster, their potential negative impact, and how application teams can use GitHub Enterprise to overcome them. Share your experiences and thoughts via live Q&A in this interactive session.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
A
He
believes
that
he's
the
world's
worst
coders,
but
I
can
tell
you
that
he
is
one
of
the
best
who
can
get
things
done
in
a
very
short
time
and
doesn't
matter
what
language
it
is.
So
this
is
my
opinion.
His
bio
stays
a
little
bit
differently,
but
I
can
tell
you
that's
not
true
daniel
is
he
lives
in
the
blue
mountains,
west
of
sydney,
and
my
name
is
fatan
hili,
I'm
a
senior
solution,
engineer
at
github,
based
in
sydney
as
well.
A
I
have
been
at
github
for
a
bit
over
four
years
now
in
my
previous
previous
life,
I
was
a
developer
support,
engineer,
qa
tester
consultant
all
of
these
different
hats
that
I
used
to
wear
next,
please
now
before
we
get
started,
I
have
just
a
couple
of
house
sleeping
notes
for
you.
The
first
one
is:
we've
got
the
chat,
which
is
at
the
top
right
hand,
corner
where
please
get
involved,
say
hi
to
us.
A
Tell
us
where
you're
joining
us
from
which
city
which
country
you're
joining
us
from
and
as
well
I've
got
my
colleague
adrian
lee
who's,
a
solution
engineer
at
github
who
will
be
monitoring
the
chat
and
helping
us
with
the
q
and
a
as
well
the
next
to
the
church.
You
can
see
that
we've
got
the
polls,
so
during
the
session
we're
going
to
make
it
a
little
bit
more
interactive,
so
we're
going
to
process
some
folds
through
through
the
session.
A
So
please
make
sure
that
you
will
cast
your
vote
and
we've
got
the
q
and
a
so.
If
you
have
any
questions
to
our
speakers
to
daniel,
and
I
please
we
make
sure
that
you
drop
them
into
the
q
and
a
tab
at
the
right
hand.
Corner
adrian
will
be
also
helping
us
with
the
q,
a
if
you
like
what
you
see
and
you
would
like
a
deep
dive
or
you
would
like
to
learn
a
little
bit
more
about
any
of
the
topics
that
daniel
will
be
covering
today.
There's
a
big
blue
request.
A
A
demo
button
at
the
top
right
hand
side
that
you
can
click
on
as
well
and
we
will
get
out
in
touch
with
you,
after
that.
I
just
want
to
give
you
a
couple
of
tips
before
we
get
started
to
so
you
can
get
a
better
viewing
experience.
So,
first
of
all
make
sure
that
you
are
joining
us
from
your
desktop.
We
could
recommend
using
chrome
edge
or
safari
firefox
will
works
as
well
with
the
most
recent
with
the
latest
version.
A
If
you
aren't
able
to
see
the
stream
try
to
refresh
the
page,
maybe
if
you've
got
some
troubles,
you've
got
if
you're
on
the
vpn,
try
to
disable
it
and
refresh
again
try
to
click
the
link
that
you've
got
in
your
calendar,
invite
and
see
if
that
will
work,
if
that
all
of
that
still
not
working,
we've
got
some
help.
Troubleshooting
documents
available
under
the
docs
and
we've
got
our
partners
from
gold
coast.
B
Thanks,
fatten
and
hi
everybody,
I'm
super
happy
to
be
here
with
you
today
for
the
improve
forum
for
github
in
focus
2022.,
my
name
is
daniel.
My
get
up
handle
is
afraid.
It's
named
after
a
world
of
warcraft
night
elf,
droid
that
I
used
to
play
years
ago,
and
I've
been
with
github
now
for
over
six
years,
helping
to
build
out
our
amazing
team
in
apac,
starting
with
just
two
of
us
and
then
growing
from
there.
B
It's
so
different
nowadays,
and
on
that
note,
I
just
want
to
give
a
huge
shout
out
to
the
entire
give
up
apac
team.
You
are
all
awesome,
no
matter
where
you
are
and
anyway
today.
What
I
want
to
do
is
take
a
look
at
a
few
things.
You
can
do
to
kind
of
put
you
on
the
right
path
for
success
in
innovating
and
improving
your
shipping
speed,
mainly
to
target
those
disruptors
that
are
probably
hitting
your
industry
and,
if
you're,
one
of
those
disruptors,
then
oops
hello.
B
B
Right
so
we've
all
heard
this
a
million
times,
and
yet
there
are
still
many
organizations
that
are
facing
upheaval
from
disruptors
entering
their
space
and
they
just
don't
know
what
to
do.
We
know
technology
plays
a
central
role
in
the
disruptors
ability
to
execute
and
out
innovate.
The
competition
now
disruption
affects
every
industry
and
no
company
is
safe
and
it's
happening
outside
of
the
traditional
tech
spaces
as
well.
You
know.
Banks,
for
example,
have
moved
from
in-person
banking
to
atms
and
and
now
to
web
and
mobile
banking,
and
more
of
us
are
dealing.
B
You
know
with
banking
software
and
we
never
actually
talk
to
a
person,
and
this
change
has
accelerated
in
the
last
couple
of
years.
I
mean
to
the
pandemic
right
and
it
is
creating
this
self-reinforcing
loop
for
businesses
of
just
needing
to
keep
up
and
it's
a
repeatable
recipe.
You
know,
digital
disruptors
have
realized
that
by
shipping
faster,
not
only
can
you
deliver
new
features
and
bug
fixes
more
quickly.
You
also
get
to
learn
faster
than
the
market
on
what
your
customers
like
and
don't,
like.
B
You
know
they're
using
things
like
a
b
testing
methodology,
feature
flags
to
roll
out
new
features
and
they
use
data
driven
approaches
to
learn
from
customer
behavior,
which
parts
they
should
continue
down.
But
it's
important
to
note,
though,
that
what
we're
starting
to
see
happen
is
not
just
disruption
from
the
startups,
but
also
from
the
current
incumbent
leaders.
You
know:
we've
got
target
versus
walmart
tesla
versus
ford
paypal
versus
citibank.
B
B
You
know
via
hiring
or
reorganizations,
and
then
we'll
look
at
understanding
what
code
you
already
have
and
where
there's
a
lot
of
wasted,
effort
duplicating
the
same
functionality
and
then
finally,
I
want
to
touch
on
the
area
of
you
know
the
time
and
effort
it
takes
to
remediate,
discover,
discover
discovered
issues,
especially
those
are
the
regarding
security
concerns,
both
in
your
code
and
the
code
that
you
use.
You
know
your
open
source
supply
chain
and
then
each
time
what
we're
going
to
do
is
we're
going
to
look
at
the
potential
situation.
B
A
B
You
know
what
I
wasn't,
but
here's
the
thing
I
actually
set
this
up
to
be
a
bit
of
a
trick
question.
You
should
always
be
thinking
way
too
long.
All
right,
in
other
words,
think
always
think
of
ways
to
make
things
better.
You
know
never
be
satisfied
with
where
things
at
now
always
look
at
how
you
can
make
things
better.
You
know
so
way
too
long
is
a
great
answer.
B
B
A
A
Know
so
seven
percent,
and
so
the
highest
highest
percentage
at
the
moment,
is
way
too
long
with
46
percent
I'll
close
the
poll.
Thank
you
all
for
participating
and
if
you
would
like
to
share
with
us
any
more
details
about
the
experience
and
how
long
why?
What
are
the
blockers
that
are
blocking
the
developers
from
contributing
successfully
in
the
chat
window,
feel
this
feel
free
to
do
so
I'll
pass
it
back
to
you,
daniel
thanks
cool.
B
No
worries
this
was
my
first
poll,
so
that
was
pretty
awesome.
I've
never
actually
seen
it
work
before
that's
great
all
right.
So
when
developers
first
start
working
on
a
project,
they
need
to
be
able
to
set
up
their
development
environment.
You
know,
for
example,
their
laptop
and,
if
they're
new,
there's
a
new
system
that
has
to
be
procured
and
brought
up
to
whatever
it
management
standards
are
mandated.
You
know
within
your
organization,
especially
for
a
new
employee,
and
this
can
be
a
challenge
nowadays,
simply
because
we
all
know
about
global
supply
chain
issues.
B
And
then
each
environment
for
each
project
has
to
be
established,
you
know,
and
if
there
are
conflicting
requirements,
for
example,
different
java
versions
or
different
ides,
that
becomes
a
headache
to
manage
as
well.
It's
not
impossible,
I'm
not
saying
it's
impossible,
but
it's
annoying
right.
So,
let's
just
assume,
we've
gotten
past.
All
of
that
all
right
we've
got
all
of
that
set
up.
Then
there's
a
lot
more.
We've
got
to
deal
with.
How
does
the
developer
know
how
to
build
tests
from
the
code?
B
B
These
scenarios,
you
run
the
risk
of
the
following
right:
developer.
Onboarding
time
will
not
improve
that
results
in
lost
productivity,
reduce
flexibility
in
your
new
starters.
The
rest
of
your
development
team
will
need
to
spend
more
hands-on
time
with
the
new
developer.
This
leads
to
more
lost
productivity,
even
possibly
slowing
down
of
your
developer
onboarding.
Now,
I'm
not
talking
about
mentorship
programs
right
they're
super
important
right.
What
I
am
talking
about
is
all
that
unplanned
interruption
that
affects
developer
flow
and
all
those
kinds
of
fun
things
you
always
end
up
with.
A
B
So
when
we
look
at
projects
that
are
deemed
successful,
they
generally
provide
excellent
documentation
for
three
different
types
of
actors.
You
have
your
general
public.
They
need
to
understand
what
the
project
is,
what
it
does,
and
this
kind
of
documentation
is
focused
on
driving
new
uptake.
It's
probably
marketing.
Documentation
is
a
great
way
to
describe
it.
You
have
your
end
users.
They
need
to
understand
how
to
use
and
be
successful
with
the
product.
B
You
know
this
kind
of
documentation
includes
user
manuals,
examples
all
of
that
kind
of
stuff,
but
then
you
have
your
contributors
and
they
need
to
understand
how
to
contribute
to
the
upkeep
and
the
improvement
of
the
product.
You
know
from
opening
a
bug
or
a
security
report,
feature
requests
all
the
way
up
to
you
know
contributing
the
actual
code,
and
today
we're
interested
in
documenting
for
the
contributor,
the
actor
that's
actually
often
neglected.
B
But
it
should
also
be
your
project's
constitution
as
a
great
way
to
describe
it.
Your
readme
file
should
not
just
be
that
set
of
instructions.
It's
a
place
to
talk
about
your
goals,
your
product
vision
and
your
road
map,
and
it
helps
new
contributors
to
understand
what
your
vision
is
and
why-
and
it
makes
it
far
easier
for
them
to
align
and
contribute
accordingly,
and
it
sits
right
next
to
your
code.
B
B
B
B
B
B
B
Now,
when
people
think
of
automation,
you
know,
especially
when
we
talk
about
software
development,
we're
talking
about
continuous
integration
and
continuous
delivery,
slash
deployment
and
that's
super
important,
but
it's
also
possible
to
automate
a
whole
bunch
of
other
stuff
as
well.
You
know,
for
example,
when
maintainers
find
problems
in
a
pull
request.
They'll,
you
know
report
back
to
the
contributors.
The
contributors
will
fix
the
code
and
then
the
pull
request
gets
merged
and
contributors
generally,
you
know
they
don't
expect
a
merge
of
their
code
unless
it
works.
B
So
that's
kind
of
okay,
but
things
get
a
little
tricky
when
a
change
works,
but
it
violates
some
technical
documentation
standard
and
then
often
when
giving
that
kind
of
feedback
in
in
these
kinds
of
cases
they
can
be
accusations
of
pedentry
or
personal
preference
or
whatever
it
happens
to
be,
because,
generally,
you
know,
as
human
beings
we're
more
receptive
to
feedback
from
pedantic
robots
than
we
are
from
pedantic
people.
There's
my
code
love
it
all
right.
B
So
my
recommendation
is
to
automate
all
the
things
you
know:
use
automation,
not
humans,
to
enforce
coding
and
documentation
standards
and
anything
else
that
you've
detailed
in
your
contributing
file.
As
much
as
you
can,
you
know,
and
if
you
do
this,
you
drop
the
emotional
barriers
to
productivity
by
taking
that
human
to
human
pedantic
risk
out
of
the
conversation
and
there's
plenty
of
opportunity
here,
you
know
in
this
screenshot
of
github
pull
request
test
results.
I've
highlighted
two
tests
that
actually
check
blog
articles
for
inclusivity
as
well
as
grammar
and
spelling.
B
You
see
most
think
people
think
of
tools
like
github
actions.
As
you
know,
cicd
tools,
but
in
reality
actions
performs
a
an
automation
platform
that
can
react
to
a
whole.
You
know
wide
range
of
events
to
enhance
developer,
workflow
and
other
productivity,
so
you
know
go
check
it
out
now,
once
you've
hit
that
low
hanging
fruit,
you
know
documentation,
scripting
automation.
B
What
else
can
you
do
to
help
developers?
You
know
come
up
to
speed,
and
this
is
where
we
start
talking
about.
Finally,
moving
the
dev
environment
to
the
cloud
you
know:
we've
we've
moved
so
many
applications
and
services
to
the
cloud.
One
of
the
last
things
they've
actually
managed
to
go
over
is
the
actual
developer
environment.
B
You
know
embracing
the
cloud
to
run
databases
in
a
container
with
non-production
data.
That's
pretty
straightforward,
especially
for
configuration
and
bootstrapping.
You
can
be
done
as
managed
as
code.
You
know,
use
kubernetes
or
terraform
all
of
that
kind
of
stuff.
But
what
about
the
actual
ide
now
some
specialized
cloud
platforms
out
there?
B
They
can
host
a
custom
ide
for
their
own
projects,
all
right
and
then
some
people
have
looked
at
things
like
well,
let's
use
virtual
desktops
and
move
that
to
the
cloud,
but
the
problem
with
virtual
desktops
is
in
reality,
you're
just
shifting
the
problem
right.
So
what
about
the
visual
studio
codes,
the
eclipses
of
the
world?
You
know
where
environments
and
projects
can
be
quite
varied
in
type
and
language,
and
the
best
way
to
get
this
up
and
running
is
to
use
something
like
a
hosted
cloud
developer
environment.
There
are
several
out
there.
B
We
have
one
called
codespaces,
it's
probably
as
closely
integrated
with
a
with
a
source
code
management
system,
as
you
could
probably
get,
and
these
environments
reduce
time
to
set
up.
You
know
the
dev
of
space
for
new
or
transferring
developers.
You
know,
and
you
can
change
it
from
hours
or
weeks
down
to
seconds
right
and
they
allow
developers
to
access
like
this
consistent
developer
experience
uses
a
virtual
environment.
B
They
can
access
it
from
anywhere
without
cloning,
installing
dependencies
tweaking
configurations,
all
of
that
kind
of
thing,
and
you
get
to
reduce
the
churn
related
to
those
environmental
issues.
You
know
like
every
time
a
developer
says
it
works
on
my
machine.
You
can
get
rid
of
all
of
that
problems.
B
B
A
good
tool
is
going
to
provide
you
with
a
backing
vm,
that's
dedicated
to
that
developer
environment.
So
you
can
have
a
full
terminal
experience
and
allow
for
multiple
machine
types.
So
you
can
choose
the
kind
of
machine.
You
need
virtual
cpu
cores
memory,
storage.
That
kind
of
thing
it
can
also
allow
you
to
open,
share
and
externally
connect
to
ports
in
that
environment.
For
user
experience,
testing
to
you
know
to
showing
what
you
have
in
progress
at
this
point
in
time
and
bonus
points.
B
B
Visual
studio
code
extension
supports
a
great
example
of
that
now.
If
you're
looking
for
a
case
study
about
how
this
can
work
head
over
to
github.blog,
we
actually
moved
our
developer
team
over
the
code
spaces
in
august
2021,
and
you
can
read
about
everything
that
we
went
into
there.
Just
head
over
to
github.blog
search
for
engineering
team
code
spaces
should
be
one
of
the
top
two
or
three
results,
and
the
github
code
base
is
now
over
14
years
old
right.
B
So
you
don't
have
to
be
a
new
project
to
kick
this
off
and
clint
from
synergy
over
in
western
australia
sums
it
up.
Well,
what
used
to
be
a
15
step
process
is
just
one
step:
open
code,
spaces
and
you're
off
and
running,
and
with
that
I
think
we
might
just
have
a
quick
break,
see
if
we've
got
any
questions
or
any
comments.
A
B
A
I
think
it's
a
very
common
scenario,
so
I'm
gonna
open
the
pool.
Have
you
ever
struggled
to
find
out
what
could
exist
in
your
organization
and
the
choices?
The
options
are
never
occasionally
frequently
or
way
too
often,
so
this
one
I'll
expect
to
way
too
often
to
be
the
highest.
Well,
let's
see
how
it
goes
so
far.
A
We've
got
frequently,
I
think
it's
very
common
when
you
start
a
project
or
like
you're
new,
and
you
start
working
on
a
specific
task,
and
then
you
find
that
maybe
fifty
percent
of
that
task
already
been
done,
that
you'd
have
been
able
to
use
reuse
so
so
far
we've
got
the
highest
occasionally
I'll.
Keep
it
open
for
a
couple
of
more
seconds
to
give
everybody
a
chance
to
vote,
but
it
seems
that
occasionally
so
far,
it's
like
46
percent,
frequently
37.39.
B
A
B
B
B
All
right
thanks
everyone
for
popping
in
there
all
right
so,
let's
say,
for
example,
you've
got
two
teams,
there's
one
producing
an
api
and
there's
another
team
consuming
that
api
and
say
a
dashboard
user
interface.
Now,
if
you're,
a
single
developer,
you'll
never
run
into
this
and
great
and
the
consuming
team
realized
that
they
need
some
kind
of
new
api
endpoint
to
meet
a
deadline
for
a
feature
ship,
but
it's
not
on
the
api
team's
backlog,
let
alone
prioritize.
B
So
what
can
the
consuming
team
do?
Well,
they've
got
three
choices
right.
They
can
wait
it
out.
There's
no
effort
required
there,
but
it
runs
the
risk
that
the
functionality
is
never
delivered.
They
can
implement
a
workaround,
but
that
could
end
up
sitting
somewhere
where
another
consuming
team
that
might
need
the
same
endpoint.
They
can't
use
it.
They
can't
get
at
that
workaround
and
you
know
the
team
have
to
maintain
it,
and
it's
likely
that
it's
going
to
happen
several
times
for
different
consuming
teams.
B
So
there's
a
ton
of
duplicated
code,
that's
not
great
right
and
then
finally,
they
can
also
escalate
to
management.
Now
that
sounds
okay,
but
it's
diverting
engineering
talent
to
a
non-engineering
task
of
doing
the
escalation
and
there's
only
so
many
times
you
can
do
that
before.
You
damage
your
credibility
within
the
organization
and
it's
disruptive
for
the
members.
You
know
the
producing
team
because
it
breaks
their
workflow
and
prioritization
methods
to
have
to
deal
with
these.
B
B
If
you
don't
open
up
those
communication
channels,
you
know,
planning
is
going
to
become
difficult,
more
work
will
become
unplanned
work
and
that
disrupts
timelines.
It
interrupts
developer
flow.
All
of
that
kind
of
thing,
and
what
you'll
see
is
that
teams
may
start
blaming
each
other
for
the
inability
to
deliver
now
you're
going.
B
Great
talent,
right
and
that
can
be
trapped
inside
a
silo,
and
yet
they
have
the
potential
to
collaborate
and
provide
expertise
across
other
projects.
But
no
one
knows
that
talent
exists,
and
so
all
of
this
leads
to
missed
opportunities
to
share
experiences
and
code
right
in
order
to
prove
improve
the
quality
and
improve
the
security
as
well
as
leading
it
leads
to
this
increasingly
disconnected
and
isolated
workforce.
B
Now,
in
an
ideal,
world
code
is
easy
to
discover
and
adapt
for
your
own
purposes.
Cross-Project
collaboration
that
allows
for
consuming
teams
to
openly
contribute
the
figure,
the
features
that
they
require
to
be.
You
know
into
a
producing
team's
code
base
and
that
allows
innovative
new
features
to
be
built
and
released.
B
So
there's
only
one
thing
I
really
want
to
talk
about
here,
and
that
is
inner
sourcing
and
inner
sourcing
is
the
adoption
of
open
source
culture,
principles
and
workflows
internally
within
a
company.
You
know
the
the
quality,
readme
and
contributing
files,
the
scripting
and
bootstrapping,
and
running
servers
and
tests
all
that
stuff
I
spoke
about
in
the
previous
section.
All
of
that
grew
out
of
and
became
defining
features
of,
successful
open
source
projects
and
engineering
teams
get
to
organically
grow.
You
know
when
demand
requires
it
in
an
environment
where
they're,
where
folks
can
contribute.
B
You
know
their
own
required
features
to
a
code
base
in
a
well-governed
manner.
Teams
grow
when
more
features
are
required,
and
then
they
head
back
to
the
core
team
when
they're
no
longer
required
and
code
ends
up
being
where
it
needs
to
be.
You
know,
other
consumers
can
more
easily
discover
the
code
and
take
advantage
of
what
already
exists
and
that
reduces
that
risk
of
producing
duplicated
code
and
then
also
keeping
the
discussions
around
the
code
as
close
as
possible
to
the
code
itself
in
issues
in
pull
requests.
B
It
provides
greater
transparency
into
that
decision
making
process.
Now
this
allows
newer
developers
to
understand
why
the
code
is
where
it
is
at
today
remember
early
on
in
the
slide.
I
had
something
like
why
don't
we
do
blah
right?
It's
even
possible
that
a
new
developer
can
bring
a
newer
perspective
to
those
older
conversations
and
by
encouraging
things
like
modularization,
providing
pre-built,
binaries
and
packages
when
it
makes
sense,
teams
get
to
focus
on
the
quality
and
the
security
of
their
particular
area
of
responsibility.
B
Now
we've
got
data.
We
can
prove
this.
We
have
the
data
that
shows
that
when
organizations
bring
open
source
practices
into
the
organization,
they
can
see
a
substantial
increase
in
productivity
from
onboarding
new
developers
to
reducing
that
duplication
of
effort.
So
let's
look
at
a
couple
of
things
from
the
inner
source
world
that
can
help
reduce
that
duplicate
effort
and
help
you
ship
code
faster,
so,
firstly
make
sure
you're
using
a
source
code
management
system
that
gives
you
tiers
of
visibility
for
a
project.
B
Secondly,
use
one
source
code
management
system,
and
preferably
just
one
instance
of
it.
You
thought
I
was
going
to
say
github,
then,
but
just
one
instance
of
one
source
code
management
system,
because
doing
so
makes
it
far
easier
to
find
what
you
want.
And
if
you
want
to
customize
that
discovery
experience,
you
can
always
slap
an
inner
source
portal
on
top
of
it
and
then
finally,
look
at
ways
that
you
can
link
similar
repositories
so
that
folks
can
find
related
work.
B
B
Is
for
the
june
fans
I
wanted
to
throw
that
in
there
so
feel
free
to
screenshot
this?
Hopefully,
you
understand
what
it
is,
but
one
thing
I've
not
mentioned
yet
is
the
fact
that
you
have
to
get
rid
of
your
fear
of
failure.
If
you
want
to
innovate
and
ship
faster
and
nareshi
announced
it
perfectly
when
he
says
that
by
seeing
each
other's
work,
you
can
learn
from
each
other,
you
can
share
and
improve
as
a
community,
and
you
get
the
motivation
you
need
to
innovate
further,
but
also
faster.
A
We
have
we
have
a
couple
around
the
measures
and
kpis,
but
I
know
that
you'll
be
covering
that
later
on.
So
we
can
skip
that.
But
there's
one
interesting
one
about
how
much
managers
familiarity
with
the
code
base
is
required,
since
that
can
help
in
making
sure
that
not
two
people
are
working
on
the
same
thing
and
neither
neither
of
them
go
implement
something
which
already
exists.
So
you,
when
you
were
talking
about
duplicate,
work,.
B
A
B
Yeah,
no,
I
absolutely
get
it
so.
One
of
the
things
about
inner
sourcing
is
that
if
you
do
this
right,
it
becomes
part
of
your
planned
work
model.
So
often
people
will
talk
about
when
you
have
an
inner
source
model.
You
have
the
contributor
and
the
trusted
committer
and
the
contributor
is
the
person
trying
to
add
the
new
feature
to
the
code
base
and
the
trusted.
Committer
is
the
person
who
has
been
authorized
and
trusted
to
make
sure
that
it
fits
all
the
standards
and
then
they
allow
it
to
come
in,
but
there's
actually.
A
B
My
owner
and
they've,
had
a
conversation
with
the
api
teams,
product
manager
and
owner
and
they've
agreed
that
this
is
planned
work,
and
so
it
actually
becomes
part
of
your
planned
work
mechanism
from
there
on
in
so
you
know,
and
that
comes
back
to
the
the
manager's
awareness
of
the
code.
Well,
it
depends
where
they
are
and
and
what
they're
kind
of
doing
from
there
in
some
cases.
B
A
A
Yeah
about
all
that
kind
of
stuff,
so
yeah
like
having
the
it's
like,
as
you
mentioned,
it's
like
the
culture,
the
mentality
having
that
visibility
that
open
mind,
not
not
just
totally
silos
between
teams,
because
the
developers
themselves
they'll
be
able
to
find
other
developers
from
other
teams.
Who've
done
similar
or
same
job
same
maybe
functional
procedure,
and
they
can
work
on
that.
Yeah.
B
A
B
B
You
know
successful,
open
source
projects
are
quite
governed,
and
there
are
you
know,
communication
hierarchies
and
all
of
that
kind
of
thing,
and
the
same
thing
applies
to
inner
source
as
well.
You're,
not
just
like,
I
said,
you're,
not
just
making
all
your
repos
public
and
then
turning
on
some
automation
to
to
check
that.
You
know
your
pull,
requests
and
stuff
like
that,
there's
more
to
it
than
that
and
there's
actually
a
great
website
innersourcecommons.org
go
and
have
a
look
over
there.
They
they
speak
about
it.
B
All
right,
so
we've
covered
a
little
bit
off.
You
know
about
how
inner
source
can
help.
You
know
reduce
that
duplication
of
effort.
So
let's
now
talk
about
one
of
those
big
four
dora
metrics
that
you
hear
about
the
the
mean
time
to
remediation
or
mttr,
and
today
we're
going
to
drill
down.
You
know
quite
specifically
into
remediation
of
identified
security
issues
and
you
might
have
been
at
the
security
session.
You
know
yesterday,
where
they
went
in
to
get
up
advanced
security.
B
B
Do
this
one
all
right
cool?
So
how
often
has
your
team
work
long
and
hard
on
a
new
feature
only
just
to
find?
Well,
I
need
to
find
just
before
deployment
that
your
security
team
discovers
a
vulnerability
and
it
substantially
delays
your
release.
You
know
because
you've
got
to
retool,
it
rework
it
and
so
on
what
options
do
we
have
fatten.
A
B
A
B
B
Question
saying
way
too
often
might
sound
a
bit
mean
all
right,
but
let's
think
about
this
from
the
mindset
of
continuous
improvement,
not
blaming
security
for
your
woes
all
right,
but
it
definitely
happens
a
lot
and
it
really
gets
in
the
way
people
you
know
being
able
to
release
code.
You
know
security
is
doing
their
job
too.
You
know
and
and
keeping
up
with
security
requirements
and
checks
and
coverage,
and
all
that
kind
of
thing
today
it's
getting
hard
and
it's
getting
harder
as
environments
and
and
devsecops
pipelines
change
at
an
even
faster
rate.
B
There's
overworked
developer
teams.
They
become
more
stressed
when
security
comes
knocking
on
the
door
and
this
breaks
that
again
state
of
flow
and
then
it
creates
an
us
versus
them
approach
to
security
and
then,
on
top
of
that,
the
security
teams
themselves
they're
also
overworked
right.
So
your
notification
processes
can
slow
down.
I've
got
a
customer
in
australia,
I'm
not
going
to
say
who
it
is,
but
they've
told
me
that
it
can
take
anything
up
to
six
weeks
before
a
security
notification
gets
back
to
the
developer
team,
let
alone
when
they
get
to
start
remediation.
B
Work-
and
this
is
because
a
lot
of
the
current
security
tools
really
were
purpose-built
for
waterfall-based
deployment,
sorry
development
and
it's
that
last
step
of
before
deployment,
and
it
often
means
that
they
kind
of
bottleneck.
You
know
agile,
based
dev
seconds,
and
it's
similar
to
the
way
we
used
to
think
about
car
manufacturing
right.
We
we
couldn't
stop
the
production
line.
It
was
all
down
to
quality
control
before
it
rolled
off
at
the
end,
and
if
there
was
a
problem
discovered,
then
there
was
a
lot
of
required
retooling
and
delays.
B
Now,
these
false
positives
are
a
real
problem,
because,
as
scanners,
you
know,
they
lack
the
context
needed
to
determine
whether
or
not
they're
real
vulnerabilities
that
expose
risk
or
are
they
being
you
know,
flagged
incorrectly
as
alerts,
and
so
devsecop
teams
are
forced
to
waste
all
this
time
chasing
down
problems
that
they
aren't
relevant
or
they
may
not
even
be
there
and
then,
on
top
of
all
of
this,
many
security
solutions
built
for
devsecops
introduce
deployment.
Friction
right,
they're
agents
in
a
production
environment
and
they
also
lack
a
lot
of
breadth
of
technology
coverage.
B
You
know
and
they
can
actually
negatively
impact
application
performance
start
time.
Stability
can
be
affected
by
these
agents
and
and
given
all
of
this,
the
the
challenge
of
actively
you
know
of
security,
actively
slowing
down
devsecops
rather
than
bolstering
it.
It's
reached
this
critical
mass,
it's
lost
time,
it's
lost
money
and
it's
lost
opportunity
now,
not
only
that
this
gateway
approach
is
yielding
less
than
satisfactory
results.
B
If
we
look
at
the
industry
norm
today
and
what
that
data
is
telling
us
is
that,
typically,
within
seven
days
of
a
vulnerability
being
identified
in
a
repository,
only
15
of
those
findings
are
getting
addressed
and
that
number
goes
up
to
about
45
after
90
days.
So
just
think
about
that
for
a
moment,
all
right,
time's
up
right,
it's
pretty
rough.
Okay.
B
Now
this
is
just
about
finding
issues
in
the
code
you
write,
I'm
going
to
deal
with
supply
chain
analysis
a
little
later,
in
other
words
the
code
you
obtain
versus
the
code.
You
write
now
again
by
not
shifting
here
by
not
taking
any
action.
You
do
run
the
risk
of
the
following
right.
You
have
increased
pressure
to
move
faster,
it's
going
to
be
exacerbated
by
remaining
stuck
on
tools
that
were
never
designed
to
be
fast
or
agile.
This
is
going
to
lead
to
friction
between
the
security
and
the
devops
teams.
B
You
know
that's
going
to
lead
to
employee
stress,
decreased
satisfaction
and
ultimately
you're
going
to
have
an
increased
turnover
of
staff
and
when
there's
such
a
shortage
right
now
talent,
this
is
going
to
reinforce
a
spiral
of
just
falling
behind
your
disrupting
competitors.
It
could
even
be
catastrophic
in
turn
the
ability
to
innovate
and
ship.
It's
only
going
to
continue
to
remain
low,
but
it
could
even
go
backwards
now.
B
Devsecops
programs
that
are
well
into
this
journey-
and
you
know
I'm
not
going
to
use
the
word
mature
here,
because
mature
kind
of
implies
that
you
get
to
a
certain
state
and
that's
it.
You
don't
have
to
fix
anything
and
that's
not
the
way
to
look
at
this
right.
It's
a
continuous
journey,
you're
always
looking
at
ways
to
improve,
but
devsecops
programs
are
the
well
into
this
journey.
B
They're
executing
a
full
suite
of
application,
security,
automation,
the
reports
and
the
user
experience
they're
focused
on
empowering
developers
and
enabling
developers
to
fix
their
code
in
the
same
way
that
they
fix
a
failed
unit
test
or
a
performance
test.
You
know
it
just
becomes
second
nature
and
they
become
awesome
at
it.
Security
teams
are
then
seen
as
partners
right
they're,
not
the
final
boss
in
this
week's
world
of
warcraft
raid.
B
They
they
become
mentors
and
guides,
and
and
this
true
community
grows
around
security
even
to
go
so
far
as
to
become
part
of
a
vital
part
of
any
inner
source
project
that
you
might
be
undertaking
and
then
finally,
an
open
source
governance
model.
It
allows
you
to
understand
and
manage
what
open
source
software
can
or
will
be
used.
It
helps
developers
clearly
plan
for
what
they
need
to
create
themselves.
B
A
B
B
B
Look
for
a
tool
where
the
queries
are
not
proprietary
or
at
least
make
sure
you
don't
have
to
wait
for
a
vendor
supplied
software
update
containing
new
and
improved
queries
right,
open
source.
Query
communities
are
for
the
win,
and
this
is
super
important
if
you're
part
of
an
industry
with
unique
standards.
Mizra,
for
example,
that's
a
set
of
guidelines
essential
in
embedded
systems
and
autosar
is
similar
for
the
automotive
industry
and
then
finally,
it
should
all
be
about
the
developers
all
right
bring
the
process
to
them.
B
Have
the
results
appear
alongside
the
unit
tests
and
all
their
other
tests
make
sure
they
can
see
the
results
within
their
space
as
close
as
possible,
with
the
code
provide
developer-centric
explanations,
sample
code
and
plenty
of
links
to
help
them
read
and
learn
more
if
they
need
to,
and
the
results
of
this
approach
will
speak
for
themselves.
Now.
B
To
talk
about
is
securing
your
supply
chain
because
we
see,
on
average,
about
80
to
90
of
code
within
most
organizations
is
from
open
source.
This
is
really
important
because
developers
do
not
want
and
do
not
need
to
reinvent
the
wheel.
You
know
that
10
to
20,
that's
left
that's
for
cool
code.
It's
your
secret
source!
It's
where
developers
should
spend
their
time
truly
building
out
that
differentiation
and
to
complete
to
compete
effectively.
B
You've
got
to
use
open
source
because
that's
what
the
disruptors
are
doing,
but
doing
it
without
a
plan
for
securing
the
dependencies
you
rely
on
is
risky
all
right.
You
might
not
have
great
visibility
into
what
you're
using
how
secure
that
code
is
or
if
the
license
chain
is
inconsistent
with
your
company
policies.
You
know
supply
chain.
Security
can
be
time
consuming,
but
it's
critical
to
increase
your
velocity
and
this
screenshot
another
one.
It's
our
dependable
tool!
B
It's
what
we
have
you
know
it's
our
response
in
this
space,
but
no
matter
what
you're,
using
once
you
have
your
environment,
set
up
it's
important
to
ensure
that
all
the
code
you
are
developing
or
using
is
secure
from
end
to
end,
and
that
includes
your
open
source
dependencies
supply
chain
analysis
tools.
They
work
like
this.
B
They
what
what
they
do
is
they
get
notified
through
various
channels
of
a
vulnerability
in
the
dependency
it
could
be
the
national
vulnerability
database
or
github
advisories,
there's
several
other
sources
as
well,
and
when
they
get
notified,
they
start
working
to,
let
you
know
so.
If
you're
looking
for
a
tool
to
help
secure
your
supply
chain,
look
for
tools
that
well,
okay,
great,
they
can
alert
you
to
vulnerable
packages,
but
look
for
a
tool
that
can
automatically
create
a
branch
and
open
a
pull
request
to
bring
your
dependencies
up
to
a
more
secure
version.
B
You'll
be
surprised
how
much
this
simple
act
will
take.
The
pressure
off
your
teams
and
you'll
also
have
an
automated,
consistently
applied
update
process
for
your
dependencies.
That's
going
to
work
just
like
a
developer
opens
a
pull
request.
You
know
changes
the
the
code,
submits
it
to
your
ci
cd,
all
the
tests
run
and
everything
passes
you
just
merge
and
away.
You
go
now
bonus
points
if
you
can
also
set
these
kinds
of
tools
up
to
provide
for
general
non-security
updates
as
well
right
because
it
just
helps
there.
We
always
want
performance.
B
We
always
want
our
code
to
run
faster,
for
example,
and
again
should
be
all
about
the
developers.
So
if
you
can
notify
a
developer
when
they're
introducing
a
known,
vulnerable
version
of
a
package,
you
know
before
that
code
is
merged
into
production.
The
developer
can
go
and
update
the
version
they
want,
or
they
can
go,
find
an
alternative.
It's
no
different
to
fixing
a
failed.
B
You
know
performance
test
or
a
you
know,
unit
test
and
then
finally,
your
tool
should
be
able
to
pull
from
a
large,
rich
pool
of
vulnerability
data,
including
having
multiple
sources
as
possible.
The
national
vulnerability
database
is
a
good
one
there,
knowing
that
the
vendor
is
maintaining
a
team
of
both
enterprise
and
community-based
security.
Researchers
is
super
important.
We
do
that
and
we
also
provide
an
advisory
database.
B
Now
I
can't
compare
this
to
repositories
on
github
that
don't
have
the
features
enabled
because
we
respect
your
privacy
and
if
you
don't
turn
the
feature
on,
we
have
no
idea
whether
or
not
you've
got
a
vulnerability
or
not,
but
I
can
talk
about
industry
metrics
from
sona
type
and
snick,
and
they
indicate
an
mttr
of
months.
All
right.
B
Sonotype
says
that
the
nttr
from
you
know,
disclosure
to
patch
in
some
projects
can
be
180
days
and
snickers
found
some
for
some
projects
to
be
more
than
two
years
and
just
to
hear
this
from
someone
else,
makari
is
an
e-commerce
platform.
They
connect
millions
of
people
to
buy
and
sell
almost
anything
from
fashion
to
toys,
sporting
goods
to
electronics,
jewelry
to
shoes,
and
they
realized
a
lot
of
benefit
and
shifting
left
and
bringing
these
security
scans
and
dependency
scans
right
into
the
developer.
B
Workflow
from
reducing
cost
to
fix
right
through
the
developer,
satisfaction
and
happiness
through
to
getting
new
features
onto
their
sites
out
as
quickly
as
they
possibly
could,
and
this
method
of
securing
their
software
and
dependencies
became
such
a
natural
way
to
work
for
them.
They
didn't
really
notice
it
anymore.
They
just
do
it
so
folks.
Today,
I've
covered
a
lot
of
ground
very
short
period
of
time
from
helping
new
developers
get
started,
all
the
way
how
to
secure
the
code.
They
write
and
hopefully
write
it
only
once
I've
tried
to
keep
it
fairly
generic.
B
A
A
B
Sure
so
state
of
the
octopus
is
a
great
one
fat
and
if
you
can
drop
a
link
into
that,
when
you
get
a
chance
that'd
be
awesome.
That's
basically
a
lot
of
the
data,
that's
driven.
What
I've
spoken
to
you
about
today
comes
from
that
report.
The
other
thing
I
would
look
at
it's
rather
kind
of
topical
right
now
is
twitter.
Has
a
site
bootstrap.
I
think
it's
called
and
two
twbs
that's
an
excellent
example
of
how
open
source
exists
and
does
really
well.
B
They
do
things
like
have
the
first
time
contributor
label
they
they
do
all
of
those
kinds
of
things
that
we've
spoken
about
here
and
if
you're
looking
for
a
great
example,
go
and
look
at
that.
Another
interesting
site
to
look
at
would
be
the
open
source
of
swift,
which
is
the
programming
language
for
ios.
B
They
have
a
very
interesting
inner
source
model
that
when
you
can,
you
have
to
fork
it
normally
and
then
submit
a
pull
request.
But
if
you
get
five
pull
requests
or
something
like
that,
that
haven't
required
a
massive
amount
of
rework,
you
actually
get
invited
to
be
a
trusted
committer,
and
you
can
actually,
you
know
directly
contribute
code.
There's
there's
tons
of
examples
out
there
and
they
all
do
things
different
ways.
So
it's
a
little
bit
difficult
to
kind
of
cover
all
of
them
again.
B
I
would
the
inner
source
commons,
I
believe,
also
lists
some
successful
ones
as
well
and
again
they
talk
about
the
patterns
that
go
because
you
do
have
a
few
more
patterns
that
go
beyond
just
open
source
like
we
spoke
about
before
you
know
the
the
the
project
managers
talking
to
each
other
and
things
like
that.
Does
that
help.
A
Yes,
thank
you
so
much.
I
know
that,
as
like
languages,
all
different
languages,
as
well
as
the
projects
are
and
from
all
the
big
companies
are
available
as
open
source
from
microsoft,
google,
his
apple,
his
danish
vocaloid
swift.
They
have
flutter
as
well
from
google,
so
lots
of
projects
open
source
that
you
can
use.
A
B
B
B
We'll
we'll
talk
about
onboarding,
then
so
first
thing,
I
would
say,
is
don't
fall
into
the
trap
of
associating
developer
activity
with
developer
productivity
right.
It's
it's
a
common
myth
and
there
are
some
seriously
undesirable
outcomes
if
you're,
not
careful,
so,
for
example,
developers
often
have
to
stretch
to
deal
with
some
poor
planning
or
implement
workarounds
in
a
bad
system.
Something
like
that.
B
That's
extra
activity,
it's
not
necessarily
product
productive,
though
they
might
have
obtained
a
better
engineering
system
or
a
better
tool
and
they're
super
excited
and
they're
pushing
hard
at
that
at
the
moment,
because
they're
having
a
lot
of
fun
and
that
will
also
see
a
lot
of
you
know
increased
activity
but
again,
not
necessarily
productivity.
So
you've
got
to
be
careful
that
when
you
look
at
activity
metrics
like
the
number
of
lines
of
code-
or
you
know
the
number
of
commits
that
are
made-
they
don't
necessarily
reveal
what
the
real
situation
is.
B
So
don't
use
those
in
isolation.
Look
at
a
couple
of
other
things.
I
would
think
about
focusing
on
outcomes
instead
of
output.
This
is
pretty
simplified,
but
think
about
things
like
did
the
code
written
by
the
developer
reliably
do
what
it
was
supposed
to
do
right
and
for
that
look
at
the
quality.
Look
at
the
reliability,
the
code,
the
absence
of
bugs
your
ongoing
service
health.
You
know
what
happened
when
you
deployed
it.
Look
at
the
impact.
You
know,
look
at
your
your
cs,
csat
scores!
You
know
your
customer
satisfaction
scores.
B
B
Metrics
that
are
really
super
important
for
you.
You
know
how
many
lines
of
developer
lines
of
code
are
developers.
Writing
means
nothing
really
nowadays.
The
other
thing
I
probably
look
at
too
is
your
new
higher
satisfaction
model.
You
know
you,
you
should
have
an
employee,
onboarding
roadmap
of
some
sort
and
you're
using
things
like
employee
interviews
and
anonymous
surveys.
B
They're
key
parts
of
that
experience,
you
know,
have
a
net
promoter
score.
You
know,
is
a
good
way
to
kind
of
get
a
feel
for
how
successful
your
onboarding
is.
Look
at
your
new
higher
turnover.
You
know,
are
you
you're
finding
it
your
developers
are
leaving
after
a
few
weeks
or
a
few
months,
because
they're
too
frustrated,
you
know
what?
What
kind
of
information
do
you
grab
out
of
an
exit
interview?
I
mean
they
sound
ugly,
but
it's
really
really
important
info.
Have
a
look
at
your
retention
rate.
B
Now,
let's,
let's
say,
for
example,
that
you've
got
50
of
your
employee
turnover
happens
within
you
know
the
first
18
months
of
employment.
Use
that
as
your
standard,
you
know.
So
this
is
a
slightly
long-term
measurement
cycle.
Look
at
what
happens
once
you
implement
this,
what
your
turnover
rate,
what
your
retention
rate
is
after
18
months,
you
know
the
other
things
you
need
to
look
at
are
absenteeism.
B
A
Yeah
and
as
well
any
all
of
the
data
coming
from
github
we've
got
apis
available
for
you
to
export
the
export
the
apis
and
use
them
in
any
tools
that
you
would
like
as
well.
There's!
Okay,
so
we've
got
yes!
Thank
you!
So
thanks
daniel
there's,
a
question
not
related
to
the
session,
but
around
redesigning
the
find
and
github
website.
I
think
he's
referring
to
the
core
search.
A
B
For
those
who
are
not
aware
of
what
it
is,
we
we're
having
a
huge
focus
right
now
on
coach
search
on
github.
It's
we've
never
been
happy
with
it.
I'll
be
honest.
We've
never
been
happy
with
it
and
we're
looking
at
ways
that
we
can
make
it
much
better,
and
so
we
have
a.
We
have
an
experiment,
we'll
call
it
an
experiment
for
now
it's
it's
not
a
feature
but
say
just
yet,
but
it
is
an
experiment
that
we
would
love
to
get
some
feedback
on.
B
A
Yeah,
thank
you
for
that.
Okay.
So,
if
there's
and
if
there's
any
last
minute,
question,
please
feel
free
to
add
that
to
the
q,
a
and,
if
you're
interested
in
the
new
concert,
feel
free
to
register
and
send
your
github
handle.
So
we
can
enable
it
for
you
and,
as
daniel
mentioned,
we'll,
be
very
happy
to
to
get
some
feedback.
So
we
can
pass
up
to
the
product
team
to
improve.
B
Happening
there,
but
we
will
be
making
a
recording
of
this
session
available
right.
So
if
you
haven't
managed
to
grab
stuff
now
that
you're
interested
in
you'll
always
get
come
back
to
be
able
to
kind
of
have
a
look
at
this
again
later
on,
I'm
not
sure
exactly
what
we're
doing
with
the
slides
right
now.