►
Description
Presented by:
Panna Pavangadkar, Bloomberg Engineering
Chandan Singh, Bloomberg
InnerSource takes the lessons learned from the Open Source Software movement and aims to apply them to the way companies develop software internally. This session focuses on the benefits of InnerSource, how to get started within a team and within an organization, and more importantly how to create a culture and movement to benefit not only the enterprise but especially be beneficial to grow, strengthen and coach the developer pipeline internally.
At Satellite 2017, attendees came to exchange cutting edge practices on how to bring together the people and tools you need to build great software. Watch the recordings to find out what GitHub's been working on, and hear how other teams use the GitHub ecosystem to customize the way they work.
We'll be getting together again in San Francisco on October 10th-12th for GitHub Universe. We hope you'll join us for three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
So
Bloomberg,
unfortunately
the
lights,
don't
allow
me
to
see
hand
raises
out
here
so
I'm,
not
gonna
have
to
refrain
from
asking
the
questions.
I
wanted
to
ask,
but
Bloomberg
most
of
you
probably
know
us
as
a
news
and
media
company.
Those
in
the
financial
industry
probably
understands
the
Bloomberg
terminal
and
know
more
about
the
Bloomberg
terminal.
So
what
I
did
was
I
did
put
a
picture
out
here
so
that
you
could
see
what
our
core
product
looks
like,
which
is
really
we
develop
software,
which
is
in
the
business
of
providing
information.
A
We
wanted
to
be
able
to
go
across
the
organizational
boundaries
a
lot
more
than
we
were
already
doing
and
be
able
to
benefit
from
all
the
best
practices
that
were
available
in
the
open
source
world.
So
when
we
started
talking
about
collaborative
development,
we
call
that
collaborative
resource
just
looking
around.
We
discovered
that
it
was
actually
there
were
the
terminology
out
there
in
the
industry.
It
is
called
inner
source
and
it's
really
bringing
in
open
source
best
practices
inside
the
enterprise
and
a
couple
of
years
ago
we
formally
started
down
that
process.
A
Of
course,
I
don't
need
to
go
down
the
list
of
benefits
that
really
come
with
it
and
I.
Guess
as
we
as
we
share
our
journey,
those
will
become
more
and
more
apparent,
but
basically
we
decided
a
couple
of
years
ago
just
to
go
into
it.
Headfirst
just
dive
into
it
and
start
beg
for
forgiveness
later,
and
so
with
that.
How
did
we
go
about
it?
Initially,
we
introduced
the
concept
to
say:
why
do
we
want
to
do
this
collaboration
and
how
is
it
going
to
benefit
everybody?
We
identified
early
adopters.
A
We
engaged
a
lot
of
people
from
across
the
board,
so
we
have
this
concept
called
Shemp,
which
is
really
evangelist
or
people
who,
within
their
own
communities,
can
help
push
forward
a
technology
or
push
forward
and
influence
other
developers
to
adopt
a
good
practice
or
a
best
practice.
So
we
engaged
with
the
champs
we
engaged
with
the
at
the
grassroots
level
from
a
developer
community
and
we
also
sort
of
engaged
the
senior
management
to
say
whether
you
believe
it
or
not.
A
You
must
be
all
familiar
with
your
own
practices
as
well
as
in
general.
Changing
habits
can
be
hard
and
with
5000
developers
you
have
all
sorts
of
resistance
to
change.
It
could
be.
You
know,
religion,
the
way
I
work
or
it
could
be
pure
arrogance
and
being
obstinate.
You
know
just
doing
it
the
way
I
do
it.
It
could
be
the
fact
that
I
do
it
best.
You
have
no
clue
how
to
write
this
stuff
down.
A
I'm
going
to
be
the
I'm
going
to
whatever
I
produce
is
the
best
code
and
what
you've
produced
is
probably
not
worthy
of
being.
You
know
merged
into
my
codebase
trusted
committers.
We
every
repository
or
every
few
developers,
decide
that
they
are
the
ones
who
can
only
manage
this
codebase
and
anybody
else
who
comes
and
introduces
or
contributes
any
change.
It's
probably
going
to
break
my
code,
those
organizationally,
the
or
traditionally
the
things
that
kind
of
chefs
people
back.
A
So
what
we
decided
to
do
was
really
come
up
with
a
set
of
best
practices
and
I
think
Johnson's
going
to
dive
in
a
little
bit
more
into
that.
But
we
started
to
break
away
at
these
organizational
barriers
that
existed
so
first
things.
First,
we
insisted
that
all
repositories
would
be
public.
First,
very
few
repositories
will
be
allowed
to
go
private
and
storing
my
private
keys
or
storing.
My
passwords
in
my
repository
was
not
an
acceptable
reason
for
having
a
private
repository.
A
We
also
started
to
encourage
people
to
make
sure
that
they
were
not
sitting
on
full
requests
or
just
ignoring
them
and
I've
seen
this
team
throughout
a
lot
of
the
presentations
today,
where
you
know
the
concept
of
full
request
is
just
ignored,
because
people
did
not
want
to
either
spend
the
time
did
not
have
the
time
to
spend.
You
know
it
was
not
as
a
part
of
your
the
agile
workflow
they
weren't
getting
enough
time
to
be
into
it.
A
Well,
as
pull
requests
as
to
be
able
to
review
the
pull
request
and
then
be
able
to
create
the
trusted
committees
as
a
community,
so
it's
not
just
the
team
mob.
They
just
the
organizational
team,
but
also
be
able
to
say
from
the
community
from
these
people
who
are
contributing,
you
know
be
able
to
start
to
create
trusted
committers
from
them.
We
have
another
thing
in
the
first
screen
that
I
showed
you
the
terminal.
We
call
things
that
we
put
up
in
the
terminal
called
functions.
A
That's
just
a
terminology
used
internally,
so
we
created
a
function
called
sauce
and
we
talked
a
little
bit
more
about
that.
But
really
it
was
about
introducing
the
fact
that
we
can
put
in
Help
Wanted
tags
and
be
able
to
gamify
the
entire.
You
know
which
repository
is
public
who's
put
in
Help,
Wanted
tags,
who's
going
and
contributing
and
being
able
to
self-help
themselves
as
well
as
make
sure
that
we
have
a
contributing
MD
out
there,
which
states
out
the
rules
of
engagement
really
clearly.
A
So
this
is
a
few
of
the
things
that
I
touched
upon
from
a
from
us.
You
know
accepting
the
change
perspective.
It's
complicated
it's
across
various
dimensions.
There
is
risk
involved,
we're
being
able
to
get
people
who
don't
know
my
code
based
on
to
send
my
codebase
to
be
able
to
submit
pull
requests
to
me,
and
there
is
commitment
both
from
a
time
perspective,
but
also,
as
I
touched
upon
change.
A
One
of
the
things
that
work
the
best
in
this
space
was
really
encouraging
a
lot
of
the
people
to
encourage
their
team
leaders
to
encourage
their
tech
leads
to
buy
into
the
idea.
So
it
really
wasn't
saying:
thou
shalt
do
this.
It
really
was
saying
hey.
This
is
good
for
our
team
to
be
able
to
move
our.
You
know
project
forward
faster
than
we
could
earlier
than
we
could
ourselves.
A
A
What
kind
of
acceptance
criteria
we
would
we
would
want
what
kind
of
comments
we
wanted?
All
of
that
we
clearly
listed
out
because
we
discovered
that
every
team
does
not
work
the
same
way
while
our
work
flows
may
be
similar.
There
were
very
specific
guidelines
that
every
team
wanted
to
abide
by.
Some
was
stricter,
some
were,
you
know,
slightly
more
relaxed
and
we
wanted
to
make
sure
that
each
team
can
get
the
autonomy
that
they
wanted
to
or
retain
the
autonomy
that
they
have
been
used
to,
but
still
open
up
the
codebase
buy-in.
A
This
continues
to
be
our
toughest
part
because
from
a
product
perspective,
our
business
and
products
won
their
teams
to,
obviously
you
know,
do
the
if
we
have
110
percent
or
this
concept
of
120
percent.
Actually
it's
the
80/20.
What
I
keep
calling
it
120,
because
nobody
really
has
an
80/20
concept
going
on
so
for
the
110
or
120.
When
we
talk
to
product
and
business
the
additional
10%
they
want
contributed
towards
moving
that
additional
feature
that
they
could
potentially
move
forward,
and
so
we've
been
working
really
hard
with
them
and
we're
getting
some
traction.
A
But
it's
the
chicken
and
egg
story
you've
got
to
show
that
it
really
works
before
you
actually
get
that
blessed
time
versus
you
know
going
and
asking
for
permission
and
then
moving
it
forward.
So
I'm
not
saying
we've
perfected
that
yet
so
we
continue
to
do
that
and
I'll.
You
know
share
some
types
of
that
and
of
course,
the
last
one
being
it's
my
baby,
don't
touch
it
I,
don't
trust
you
and
really
doing
away
with
that
I!
Don't
trust
you!
Culture
has
been
interesting.
I.
A
Already
touched
upon
some
of
this,
and
some
of
this
has
been
has
come
up
in
some
of
the
other
of
talks
as
well,
which
is
really
around
engaging
and
understanding
that
when
people
want
to
be
able
to
contribute
to
your
repositories,
they
come
from
different,
diverse
backgrounds
and
they
have
different
styles.
And
so
you
know
breaking
that
culture
of
I'm
going
to
bite
your
head
off,
because
whatever
you
submitted
is
not
good
or
you
didn't.
A
Listen
to
my
instructions
or
you
didn't
read
the
contributing
that
MV,
but
being
able
to
engage
in
a
much
more
meaningful
way.
We've
seen
our
cases
where
somebody
puts
in
a
pull
request,
and
it
will
just
be
squashed
down
because
I
don't
agree.
We
had
to
start
to
literally
stalk
those
areas
and
start
to
encourage
those
people
to
start
to
have
an
engaging
conversation
as
to
why
they
think
something
that
was
submitted
as
a
full
request.
Doesn't
you
know
gel
with
them
or
what
additional
conversation
needed
to
be
had
now?
A
It
does
seem
heavy
that
we're
having
these
one-on-one
conversations,
but
this
is
where,
when
I
searched
upon
our
champions,
our
evangelists
all
of
this
community
comes
in
to
be
able
to
help
us
move
the
thing
forward
in
a
meaningful
way,
embracing
the
differences
and,
of
course,
building
this
culture
of
mentoring
and
coaching.
It's
really
about
being
able
to
say
everybody
has
to
take
the
responsibility.
A
Everybody
has
to
take
the
commitment
to
move
this
collaboration
forward,
and
you
know
what
we
found
was
that
as
teams
understood
that
they
could
self
help
themselves
or
they
could
improve
a
particular
area
for
moving
their
product
forward.
We
started
to
see
a
lot
more
contributions
coming
a
lot
more
commitment
to
saying
fine,
we'll
persist
and
persevere
and
go
through
some
of
these
challenges.
That
I
touched
upon
earlier.
A
Teamwork
we
had
to
sort
of
put
together
a
lot
of
you
know:
clarity
around
roles
and
responsibilities,
around
training
up
our
trusted
committees
as
to
how
they
need
to
one
train,
their
team
build
their
pipeline
of
trusted
committees
and
what
are
the
best
practices
for
them
to
be
able
to
move
that
forward?
We
did
a
little
bit
of
skunk
works
here,
so
we
sort
of
stole
time
for
coaching.
We
stole
time
for
mentoring
as
opposed
to
getting
that
less
time
and
for
a
few
of
these
projects
just
to
prove
it
out.
A
Similarly,
as
I
said,
they
have
the
80/20,
we
call
them
X
projects,
so
80%
is
working
on
projects
that
we
are
assigned
to
do
for
20%
is
that
you
know,
and
it
very
seem
to
team.
So
don't
quote
me
on
the
80/20:
it's
really.
Some
teams
are
ninety.
Ten,
some
teams
are
eighty
20-somethings
110
with
those
X
projects.
I
really
started
to
excite
the
people,
because
developers
would
then
go
off
and
do
a
skunkworks
project
or
an
X
project,
and
it
seems
nicer
to
call
it
the
next
project
instead
of
a
skunkworks
project.
A
Call
it
a
next
project
and
then
get
the
contributions
to
that,
and
we
found
that
a
lot
of
times
those
X
project
turned
out
to
be
one
community
driven
because
it
was
a
good
idea.
Somebody
else
agreed
with
me
and
to
moved
forward
our
agenda
much
faster
and
got
adopted
as
more
and
more
of
the
you
know,
workflows
that
were
broadly
adopted.
A
It
also
helped
from
the
coaching
and
mentoring
perspective,
because
now
you
had
people
going
across
team
boundaries
going
across
organizational
boundaries
and
being
able
to
engage
on
something
that
was
a
common
theme,
for
you
know
multiple
people
to
move
that
X
project
forward.
I
can't
emphasize
enough
the
time
we
are
all
stressed
on
time.
So
you
know
that's
that
continues
to
be
a
challenge
for
us.
A
So
people
wanted
to
keep
their
repositories
private
initially
resisted
coming
on
to
our
implementation
of
github
enterprise.
But
as
they
came
to
know-
and
you
know,
the
word
started
spreading
to
say
that
this
tooling
enables
them
to
have
a
better
experience
during
the
development
process.
They
started
coming
in
with
private
repositories
and
we
would
go
in
to
check
who
is
coming
in
with
private
repositories
and
why
so?
The
tooling
did
play
an
important
role
for
us
to
be
able
to
open
up
these
repositories.
A
The
agile
implication
I'm
not
even
going
to
get
into
that
again
because
of
the
fact
that
you
know
you
need
the
product
buy-in.
You
need
to
be
able
to
do
that,
but,
as
I
said,
some
of
the
things
that
we
tried
were
really
we've
pushed
our
way
in
and
then
apologized
for
doing
the
skunkworks
or
the
X
project.
A
A
It
spoke
about
this.
You
know
the
the
blessèd
project,
and
so
we
started
challenging
that
with
our
ex
project
and
a
lot
of
the
ex
projects
have
actually
moved
forward,
and
so
what
we're
going
to
do
next
is
when
I
hand
over
the
children
to
really
talk
about
some
of
the
ex
projects
that
made
our
github
integration
way
better
and
our
developer
workflow
way
better
than
we
had
in
the
past.
A
B
You
hello,
everyone
so
so
far,
I
guess
we
have
talked
about
why
inner
sourcing
works
and
how
it
was
useful
for
us.
But
let's
dive
into
a
little
bit
details
about
how
you
might
start
to
do
it.
If
you
have
a
let's
say:
github
enterprise
installation
and
what
kind
of
tools
and
respects
is
that,
but
for
us,
which
might
be
helpful
for
you
as
well.
B
So
let's
start
by
imagining
a
scenario
where
you're
working
on
your
cool
weekend
project
and
you
find
a
bug
in
this
nasty
library
that
you
want
to
fix,
and
that
is
your
most
impediment
to
getting
your
cool
weekend
project
to
work.
But
you
have
no
idea
where
the
source
code
lives.
You
don't
know
how
to
build
this
thing.
You
have
no
idea
how
to
test
your
chain
if
you
ever
manage
to
make
a
pull
request.
So
this
was
kind
of
one
of
the
problems
that
we
are
trying
to
overcome.
B
So
I
think
there
are
any
two
parts
to
this
problem.
One
part
is:
how
do
you
really
find
your
source
code,
and
that
is
the
problem
in
itself,
and
second
part
is
once
you
have
the
source
code?
How
do
you,
then?
How
do
you
know
how
to
build
that
thing
and
how
to
test
that
a
piece
of
software
so
I
think
adopting
github
enterprise
kind
of
solved
the
first
part
of
the
puzzle
for
us?
B
So
it's
very
good
of
a
concept
that
is
pretty
popular
in
the
open-source
community,
which
is
to
have
a
contributing
dot.
Md
in
your
repository
and
I
think
this
solves
a
lot
of
problems
in
of
itself,
so
you
can
describe
how
they
should
start
interacting
with
your
project,
whether
they
should
open
a
show,
first
sort
of
an
affiliate
first,
how
they
should
build
your
project.
B
How
would
they
test
their
changes
and
how
would
they
do
it
locally,
and
you
can
start
and
be
found
out
that
you
could
start
by
having
a
really
simple
concept
in
there?
We
just
say
that,
yet
this
is
how
you
build
our
project
and
that's
pretty
much
it
and
we
are
improving
on
this
document.
I
think
that's
a
valid
start,
but
as
your
project
rolls,
you
will
eventually
find
that
even
your
contributors
will
start
contributing
even
to
this
contributing
document.
I
think
which
is
pretty
nice.
B
So
once
you
have
set
this
up,
is
someone
somehow
lands
to
your
repository?
They
will
at
least
have
some
idea
of
how
to
work
with
your
software.
The
next
problem
is:
how
do
people
find
issues
to
work
on
so
once
an
area
was
where
I
knew
what
I
wanted
to
fix.
The
other
scenario
is
I
just
want
to
contribute.
Some
of
my
x
time,
as
we
talked
about
earlier
to
a
certain
project
and
what
issue
what
issues
should
I
work
on
and
even
what
repositories
should
I
find
those
issues
to
work
on
so
I.
B
I
might
tag
this
Help
Wanted
and
ask
for
support
with
the
Chams
initiative
that
we
have
so
wibble
is
this
screen
and
the
screen
runs
in
a
Bloomberg
terminal,
and
this
is
called
sauce
dog
which
is
a
play
on
the
world
open
source
source
sauce.
So
what
this
screen
shows
you
is
that
it
shows
you
the
repositories
on
top,
on
the
left,
hand,
side
and
different
statistics
about
that
repository.
On
the
right
hand,
side-
and
this
is
I-
guess
the
idea
of
gamification
that
panels
talking
about
earlier.
B
So
given
a
repository,
tells
me
how
many
contributors
it
has
so
having
more
contributors
is
good
having
how
many
stars
it
has
and
how
many
health
knee
issues
it
has.
So,
on
the
rightmost
column,
you
will
find
the
healthy
issues,
which
is
the
issues
that
you
might
want
to
work
on.
If
you
are
an
external
contributors,
ok,
so
excellent!
So
now,
you're,
like
you,
are
an
external
contributor.
You
have
found
a
shoe
to
work
on.
You
have
managed
to
build
project
everything
built
successfully
to
Nevada.
B
So
now
you
would
want
to
submit
that
set
of
changes
for
code
review.
The
code
review
like
a
sturdy
important
as
we
have
I,
will
not
go
into
details
of
why
we
should
do
code
review
and
I.
Think
all
of
you
will
agree
that
it's
a
if
you
should
not
ship
code
to
production
without
code
review
so
and
some
of
this
content
is
taken
before
github
2.6
Enterprise
came
out
and
one
of
the
problems
that
we
had
before
that
was.
B
It
was
hard
for
a
contributor
and
even
multiple
reviewers,
to
figure
out
what
a
given
reviewer
has
said,
and
let
me
explain
that
let's
say
I'm
a
reviewer
and
I
say:
oh,
you
know
these
set
of
changes,
look
good
to
me,
but
it
would
be
better
with
these
extra
set
of
fixes.
So
what's
likely
meant
there
did
they
want
you
to
merge
the
pull
request
and
just
to
make
a
note
that
it
could
be
made
better
or
did
they
want
you
to
fix,
make
those
fixes
and
only
then
merge
your
pull
requests
and
I
guess.
B
The
problem
was
that
there
was
no
easy
way
for
us
to
represent
statuses
by
status.
I
mean
not
the
these
statuses
but
status
as
in
whether
it's
it
means
work
or
whether
it
means
review
or
what
is
needed
to
get
this
merged.
So
we
decided,
as
we
are
all
programmers
obvious
I,
had
to
solve
the
problem
by
writing
a
bot
of
our
own.
B
B
One
of
them
is
called,
is
fixed
means,
so
fix
means
is
a
you
can
imagine
fix
me
that
the
a
set
of
to-do
list,
so
you
have
a
github
issue
or
pull
request
open,
and
then
you
want
a
list
of
things
in
there
to
be
fixed
before
clickers
get
merged.
So
you
can.
You
can
list
them
out
those
checkpoints,
but
that
doesn't
quite
recently
work
in
all
cases.
So
you
wanted
those
things
to
be
shown
here
as
statuses,
so
example.
This
thing
here,
the
first
status
set
six
me
fix
that
typo.
B
So
you
can
have
those
several
ticks
meet
in
your
pull
request
and
then
once
the
original
contributor
realizes
that
okay
I
need
to
fix
that
they
can
fix
that,
and
then
they
can
mark.
This
fix
me
as
fixed
again
by
using
a
comment
which
says
issue:
one
is
fixed
using
the
standard
syntax
that
the
spot
recognizes.
B
So
that
was
a
first
integration
which
is
called
PR
secretary.
Then
we
realize
that
a
lot
of
people
in
our
some
people
in
our
company
they
like
to
use
fabricators
for
code
abuse
and
one
of
the
reasons
for
that
was
that
it
allows
you
to
see
all
the
reviews
that
are
involved
in
just
on
one
single
screen
so
that
you
can
easily
navigate
to
all
the
reviews
that
you
are
part
of.
It
also
offers
some
neat
functionalities
around
how
you
can
comment
on
multiple
lines.
But
that's
not
what
I'm
talking
about
here.
B
The
point
of
this
talk
is
that
someone
realized
that
it
will
be
really
nice
if,
if
they
could
link
a
BB,
get
to
pull
it
if
I
get
a
pull
request
to
fabricator
so
enter
another
bot
called
fabricator
and,
as
the
name
suggests,
is
a
link
between
github
and
fabricator,
and
hence
the
name
public
ater,
and
this
guy
will
create
a
fabricator
review
for
each
pull
request
that
you
create
and
github.
And
then
you
can
go
back
review
that
pull
request
and
whatever
you
operations
you
do
on.
B
Okay,
so
you
have
submitted
the
clear
pull
requests.
Some
of
the
contributors
have
reviewed
it.
What
next?
Well
it's
test
coverage.
They
would
not
want
to
merge
a
pull
request
without
passing
some
test,
so
we
refer
to
write
another
bot
that
we
call
Mariner
and
but
this,
what
is
going
to
do
is
without
going
too
much
technical,
T
of
IV
needed
and
their
bill
system.
B
But
what
this
part
is
essentially
going
to
do
is
this
is
essentially
going
to
look
for
a
doctor
file
in
your
repository
and
as
you,
it
finds
that
docker
file
it's
going
to
build
that
docker
file
and
show
results
over
here
in
the
format
of
where
each
step
the
response
to
one
instruction
in
your
docker
file.
The
reason
we
did
this
was
we
found
that
it's
really
easy
to
reproduce
this
locally.
So
you
once
you
have
this
docker
file
learning
in
your
CI
framework.
B
Another
thing
that
you
get
for
free
here
is
that
the
system
then
becomes
really
scalable,
so
you
don't
have
lots
of
agents
and
lots
of
master
and
slave,
so
your
system
is
really
scalable
and
you
can
just
have
more
and
more
of
these
worker
nodes
which
will
keep
processing
these
pull
requests
for
you.
So
it's
really
easy
for
us
to
scale
out
and
the
way
that
we
started.
B
This
was
again
as
X
project
and
and
now
and
at
the
time
it
was
only
I
think
that
was
using
it
and
now
I
think
roughly
10%
of
the
organizations
that
are
in
our
entire
github
installation,
roughly
10%
of
their
national,
are
using
Mariner
now,
which
was
inkle
and
since
its
released,
this
is
not
even
properly
released
yet
so
this
was
I
think
made
it
available
for
everyone
I
think
up
over
half
year
ago.
So
that's
the
generate
summer,
just
off
what
Mariner
does.
B
B
And
since
then,
some
of
these
have
done
into
blessed
projects
as
we
might
call
them,
and
some
of
them
are
still
ultimately
divine
X
projects,
and
the
point
I
guess
here
is
that
these
tools
that
were
developed
to
facilitate
better
inner
sourcing
and
better
standards,
they
themselves
benefited
quite
a
bit
from
inner
sourcing.
So
I
think
that
is
a
great
example
of
how
inner
sourcing
works
in
our
practice
and
how
we
might
benefit
from
it,
and
now
I'd
like
to
hand
over
to
planner
to
wrap
up.
Thank
you.
A
So
to
wrap
up
basically
I
call
them
stretch
projects,
and
it
really
is
a
matter
of
being
able
to
say
how
can
we
find
the
low-hanging
fruit
which
are
the
when
you
get
started
within
your
organization's,
because
I'm
sure
your
organization's
already
do
do
this?
You
know
the
collaboration
across
teams,
it's
just
that
it's
not
called
inner
source.
A
It
may
not
be
blessed
so
when
you
do
want
to
get
started,
it's
really
identifying
the
low-hanging
fruit
and
be
able
to
sponsor
more
of
these
cross-functional
projects
that
benefit
more
teams
and
be
able
to
get
the
buy-in
shed.
Infrastructure
project
was
an
easy
way
for
us
to
get
started
and
I
say
it
was
an
easy
way
for
us
to
get
started
because
it
came
under
my
team,
so
I
could
just
say:
hey
we're
going
to
make
every
project
in
our
source.
A
A
We
have,
you
know,
identify
common
pain
points
and
be
able
to
say
if
I
can
encourage
other
developers
to
be
able
to
contribute
to
the
pain
point
that
they're
facing
by
opening
up
my
repository.
Maybe
we
can
start
to
get
others
to
do
the
same,
so
it's
really
by
emulation.
It
is
by
you
know,
being
able
to
showcase
that
chicken-and-egg
story
and
that's
what
it
you
know
boils
down
to
it's:
creating
more
and
more
opportunities
for
people
to
go
across
the
organization
to
be
able
to
contribute
as
well.
A
There's
a
lot
more
to
be
done
yet,
and
you
know
we
have
a
list
of
to
dues
which
are
in
our
backlog,
but
we
wanted
to
share
this
story
anyways
at
this
point.
So
that's
my
getting
started.
Basically,
it's
a
three
pronged
approach
find
that
early
adopters,
evangelized
and
eventually
get
the
sponsorship.
Thank
you.