►
Description
Presented by Edward Thomson, Microsoft.
A few short years ago, Microsoft called Open Source a "cancer", and likened it to "communism". Today, Microsoft is the organization with the most contributors to open source projects on GitHub. Learn how Microsoft transformed its business to embrace and extend open source technologies, like the Git version control system - but not extinguish them!
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
Hello,
everybody
thank
you
for
coming
out
to
github
universe
today.
I
hope
you're
really
excited
to
be
here.
I
know,
I
am
my
name,
is
Edward
Thompson
and
as
excited
as
I
hope.
We
all
are
to
be
here.
I
hope
you'll
indulge
me
for
just
one
minute
if
you
could
close
your
eyes
and
pretend
for
just
a
second
that
you're
not
actually
at
github
universe
and
when
you
open
them,
I'd
like
you
to
pretend.
Instead
that
the
year
is
1976
and.
A
If
you
weren't
around
in
1976
I
know
most
of
you
probably
weren't
actually
alive,
yet
one
of
the
things
we
didn't
have
in
the
mid-1970s
was
these
brilliant,
high,
color
graphics
displays
you
had
two
options
amber
on
black
or
green
on
black
and
they
actually
weren't.
These
lovely
high-resolution
displays
either
we
didn't
have
these
great.
You
know
Retina
displays
with
all
these
pixels
in
them.
A
A
A
If
you
wanted
a
computer,
you
could
get
a
mainframe
that
would
fill
the
room
or
you
could
get
a
mini
computer.
That
was
the
size
of
a
refrigerator.
It's
not
really
that
many
at
all,
but
MIT's
was
enabling
people
to
build
their
own
computers.
They
would
advertise
in
the
back
of
a
magazine
like
popular
electronics
or
a
radio
magazine,
and
they
would
encourage
people
who
are
already
hobbyists
with
electronics
to
build
a
computer.
A
You
had
a
thing
with
some
switches
and
some
lights
on
it,
and
it
didn't
really
do
all
that
much
and
that's
where
Bill
Gates
and
Paul
Allen
came
in
so
in
the
1970s.
Microsoft
was
building
interpreters
for
these
hobbyist
microcomputers
basic
interpreters
and
selling
them
like
right
there
in
the
back
pages
of
the
magazines
right
next
to
the
ads
for
the
Altair,
but
the
people
who
were
building
these
computers
tended
to
work
together.
A
They
tended
to
talk
to
each
other,
they
they
congregated
in
communities
and
they
were
working
together
to
help
each
other
assemble
these
computers
and
to
get
the
most
out
of
them
and
they
were
sharing
their
knowledge
and
another
thing
that
they
shared
was
the
software.
They
would
actually
share
Microsoft's
basic
interpreters
with
each
other.
Now,
if
you've
ever
seen,
Bill
Gates's
temper,
you
can
imagine
that
he
wasn't
real
happy
about
people
taking
his
software
and
sharing
it
without
paying
him,
and
so
in
1976.
He
wrote
a
letter
to
these
hobbyists.
A
He
put
it
right
there
in
the
back
of
popular
electronics
right
next
to
the
Altair
ads
and
next
to
his
actual
ad
for
his
interpreters,
and
he
said
that
they
were
stealing
his
software.
They
weren't
sharing.
He
noticed
the
the
subtle
language
difference.
They
were
stealing
his
software
and
he
concluded
with
his
address
and
invited
anybody
who
was
reading
this
and
had
stolen
his
software
to
write
him
a
check
to
pay
up.
A
We
weren't
really
all
that
happy
with
people
sharing
software
and
that
didn't
change.
For
many
many
years
in
the
mid-90s,
the
the
workstations,
the
technical
workstations,
were
sort
of
becoming
dethroned.
The
Intel
computers
were
becoming
so
powerful
that
suddenly
you
didn't
necessarily
need
a
Sun
workstation
or
an
IBM
or
an
HP.
To
do
your
computing.
A
You
could
get
a
very
powerful
Intel
machine
and
run
T
on
it
or
you
could
run
Linux
on
it
and
at
the
time
Linux
was
actually
becoming
very
popular
because
it
was
a
unix-like
workstation,
much
like
the
Suns
that
were
more
expensive
and
not
really
all
that
much
more
powerful
and
so
Bill
Gates
went
off
on
these.
These
Linux
workstations
they
ran.
They
used
a
license
called
the
new
public
license
which
Bill
Gates
said
that
Microsoft
disagrees
with.
He
said
that
he
dislikes
open-source
software
because
quote
unquote.
A
A
So
how
did
we
get
here
so
I
work
on
part
of
the
team
at
Microsoft,
working
on
visual
studio
team
services
and
I
can
only
tell
you
my
little
part
of
that
story.
All
a
lot
of
teams
within
Microsoft
were
actually
working
on
open
source
kind
of
independently,
so
I
don't
want
to
take
all
of
the
credit
by
any
stretch
of
the
imagination.
I
can
only
tell
you
what
I
know
so
in
2009,
that's!
Actually,
when
I
started
at
Microsoft,
I
worked
for
a
little
company
called
team
prize.
A
If
you've
never
heard
of
us,
that's
fine.
He
had
four
engineers
and
we
worked.
Our
headquarters
was
in
a
cornfield
in
central
Illinois.
We
worked
on
Enterprise
version
control
systems
and
we
had
cross
platform
clients
for
that.
Microsoft
had
its
own
version
control
systems,
but
they
didn't
have
cross
platform,
so
they
acquired
us
to
kind
of
fill
that
gap
and
if
you've
ever
worked
on
a
team
of
four
people,
you
can
imagine
we
didn't
write
all
the
code
ourselves.
A
So
we
actually
had
three
products.
When
Microsoft
decided
to
acquire
us,
we
had
to
quote-unquote
remediate
all
the
open
source
code
in
two
of
those
products
we
had
to
either
rewrite
it,
or
some
of
the
licenses
of
course
were
acceptable
to
Microsoft.
So
that
was
no
problem.
The
third
product
of
ours
had
so
open
source
software
in
it
like
because
it
was
a.
We
used,
an
open
source.
A
Two
UI
library
framework
and
we
were
totally
dependent
on
that,
but
the
license
was
a
little
unpalatable
to
Microsoft
at
the
time
it
was
so
bad
that
we
actually
had
to
stop
shipping
that
product.
When
we
were
acquired,
we
had
three
the
next
day.
Microsoft
was
selling
it's.
Never
it's
never
seen
the
light
of
day
again.
It
was
incredible
to
us,
despite
that,
our
acquisition
was
what
Microsoft
considers
a
big
success,
so
we
were
able
to
add
the
cross-platform
version,
control
clients
to
what
was
then
Microsoft,
Team,
Foundation
server,
and
so
in
2009.
A
The
industry
analyst
Gardner
I,
won't
bore
you
with
all
the
details,
puts
out
a
Magic
Quadrant
report
and
suffice
it
to
say
that
being
over
on
the
right
hand,
side
of
this
graph
is
good
and
being
up
at
the
top
is
good
and
Microsoft
was
at
the
top
and
the
farthest
right.
So
we
thought
we
were
doing
great.
A
The
problem
with
surveys,
though,
is
that
they
can
be
a
little
bit
misleading.
Sometimes
people
say
they
like
something,
but
in
fact
it's
not
very
good.
If
you
guys
don't
remember
New
Coke,
let
me
give
you
a
more
contemporary
example.
I
think
you
can
just
look
at
the
politicians
and
basically
all
of
the
countries
right
now
and
just
because
they
won
something
on
a
survey
doesn't
mean
that
they're,
actually
any
good
team
foundation
server,
was
a
little
bit.
That
way.
Let
me
let
me
just
real
quick.
A
Give
you
a
little
background
when
Team
Foundation
server
came
out,
it
had
its
own
version
control
system,
a
centralized
version,
control
system
called
TF
BC,
and
it
was
a
checkout
edit
check-in
system.
I
won't
go
like
into
super
deep
version,
control
theory
on
you,
don't
worry,
but
the
idea
is
that
files
are
locked
until
you
actually
communicate
with
the
server
and
make
them
writable.
You
have
to
check
them
out
explicitly
from
the
server
and
the
reason
for
that
is
so
that
they
can
scale
to
insanely
large
code
bases.
A
We
built
this
to
handle
the
Windows
codebase
the
office
codebase
things
like
that
multi
hundred
gigabyte
code
bases,
so
you
want
something
that
has
this
sort
of
characteristics,
but
if
you're
not
working
on
Windows,
if
you
have
a
more
modest-sized
application,
maybe
you
only
have
a
hundred
megabytes
of
code
or
even
just
five.
This
really
gets
in
your
way.
You
have
to
communicate
with
the
server
all
the
time,
so
our
customers
weren't
really
thrilled
with
it.
A
So
in
2012
we
came
out
with
a
different
type
of
system.
We
added
two
TF
PC
and
we
added
what's
called
an
edit,
merge,
commit
system.
The
idea
here
is:
it
looks
to
see
on
your
disk
what
you've
changed
and
it'll
just
it'll
just
tell
you
right
there.
So
in
2012
we
had
rent
reinvented
subversion.
Basically,
however,
we
were
really
proud
of
ourselves
for
doing
this.
Our
customers
still
not
so
much.
A
This
is
just
a
random
sampling
of
things
that
our
customers
were
saying
about
us
at
the
time.
Some
of
them
had
even
taken
to
redefining
our
three-letter
acronym
TFS
as
team
frustration
server.
This
is
a
real
bummer.
This
is
why
you
should
never
use
acronyms
in
your
in
your
product
name,
but
on
my
team,
the
the
cross-platform
team.
To
be
honest
with
you,
we
weren't
much
happier
at
the
time
because
we
were
actually
a
distributed.
Team
I
was
in
Chicago.
A
One
of
my
co-workers
was
in
Raleigh
North
Carolina,
my
buddy
Martin,
another
co-worker
in
Northern,
Ireland
and,
of
course,
our
source
control
server,
because
it's
Microsoft
was
in
Redmond
and
so
one
day,
I
think
it
was
Martin.
His
internet
connection
was
down
and
he
said
guys
come
on.
Maybe
we
should
be
using
a
distributed
version
control
system
and
we
laughed
because
this
seemed
ridiculous
to
us,
because
we
were,
of
course
building
a
version
control
system
and
at
Microsoft
we
eat
our
own
dog
food.
That's
what
we
do.
A
We
use
the
products
that
we
build
so
that
we
make
sure
that
we
are
successful
using
them
idea
caught
hold
for
us.
We
decided
well.
If
we're
gonna
eat
our
own
dog
food,
maybe
we
should
actually
write
our
a
distributed
version
control
system,
and
this
was
a
challenging
idea
for
us
because
distributed
version
control
systems
lack
a
lot
of
the
functionality
that
centralized
version
control
systems
do
that.
A
So
we
were
really
concerned
about
going
down
that
road
of
distributed
version
control
systems
until
we
read
a
book
and
if
you've
never
read
this
I
totally
recommend
it.
The
innovators
dilemma.
The
author
sets
up
two
types
of
technologies,
sustaining
innovations
and
that's
what
team
foundation
version
control
was
our
centralized
version
control
system.
A
It
was
doing
everything
that
we
thought
our
customers
wanted.
We
were
making
incremental
improvements
to
it,
but
it
was,
for
the
most
part,
very
stable
contrast
that
with
a
disruptive
innovation
which
doesn't
seem
to
actually
do
anything
that
our
customers
wanted,
it
doesn't
handle
large
repositories.
It
doesn't
have
fine-grained
permissions
control,
it
doesn't
have,
you
know
very
distinct
auditing.
A
It
has
its
own
set
of
advantages
for
a
distributed
version
control,
it's
usually
lightweight
branching
and
the
ability
to
have
a
much
higher
code
velocity.
Because
of
that-
and
so
the
author
of
this,
this
book
argues
that
disruptive
innovations
will
catch
hold
because
of
their
advantages
and
ultimately
displace
the
sustaining
technologies.
A
So
we
decided
that
we
perhaps
needed
to
at
least
take
a
gamble
and
put
a
distributed
version
control
system
into
our
product.
So
we
decided
to
do
that.
We
would
in
fact
write
a
distributed
version
control
system,
so
we
went
to
our
customers
and
we
said:
hey
guys,
have
you
heard
the
good
news
about
distributed
version
control
and
for
the
most
part
they
were
like
I,
don't
know
what
y'all
are
talking
about,
but
a
couple
of
them
were
were
on
board.
They
were
like
yeah
it's
about
time.
A
We've
been
wanting
PVCs
for
a
long
time,
so
we
said
great
we're
gonna,
build
a
distributed
version
control
system
right
into
Team,
Foundation
server
and
they
kind
of
nodded
they're
like
what
do
you
mean
build
like?
Oh,
we've
got
some
great
ideas
for
how
to
support
that,
and
then
they
they,
it
kind
of
reminded
us
that
maybe
that
wasn't
such
a
good
idea
for
us
what
they
wanted
was
get
and
what
we
were
offering
them
was
something
else.
Some
Microsoft,
DVCS
I,
don't
know
exactly
what
it
looks
like,
but
I.
Imagine
it's
something
that.
A
And
so
they
kind
of
looked
at
us
like
maybe
we
were
a
little
bit
crazy
and
I'll
never
forget
what
they
said
to
us.
They
said,
maybe
you
guys
are
a
little
bit
crazy.
So
at
that
point
we
backed
off
and
decided
that
maybe
it
was
the
answer
we
were
seeing
this
tremendous
upswell
at
github.
The
open
source
technologies
were
absolutely
getting
behind
git
and
we
were
even
seeing
it
used
as
in
ways
that
I
assumed
were
never
intended
like
as
a
deployment
pipeline.
You
could
get
push
your
repository
into
Azure.
A
Do
it
deploy
it,
so
it
made
no
sense
for
us
to
do
anything
else.
We
decided
that
we
had
to
put
get
into
visual
studio,
the
IDE
into
Team
Foundation
server,
our
hosting
platform
and
into
a
new
product
called
visual
studio
team
services,
which
was
team
foundation
server
hosted
in
Azure.
This
was
our
cloud
hosted
code
collaboration
platform
that
we
were
really
excited
about.
A
The
problem
with
putting
it
into
all
of
these
places
is
that
they
were
all
kind
of
a
state
technologies.
So
we
already
built
an
architecture
on
Team
Foundation
server,
around
Microsoft
sequel
server,
and
we
were
building
our
architecture
for
visual
studio
team
services
on
top
of
Microsoft
Azure.
So
as
your
blob
storage
and
sequel
Azure.
A
Now,
if
you
want
to
host
a
git
repository,
this
isn't
the
way
to
do
it.
If
you
look
at
github,
if
you
look
at
their
file,
servers,
they're,
just
Linux
servers
and
all
of
the
git
repositories
that
you
store
are
just
they
look
like
the
dot
git
folder
that
you
get
when
you
clone
the
repository.
It's
really
super
straightforward.
A
The
optimal
way
to
host
a
git
repository
at
the
time
was
just
to
put
it
on
disk,
but
our
architecture
was
totally
abstract
and
had
all
these,
you
know
azure
back
services
that
were
really
high
performance
for
us,
but
would
be
really
low
performance
to
host
a
git
repository
in.
There
was
a
solution
for
us,
though.
A
project
called
Lib
get
to,
instead
of
requiring
everything
to
go
to
the
file
system,
actually
had
this
nice
abstract
pattern
where
we
could
plug
in
our
own
you
to
providers.
A
So
we
could
actually
store
people's
repositories
in
sequel,
Azure
and
sequel
and
Azure
blob
storage.
So
we
started
hacking
on
this.
We
spiked
it
and
we
built
out
a
prototype
where
you
could
host
your
git
repository
in
Azure
using
Lybia.
You
could
push
your
repository,
you
could
clone
a
repository
and
we
were
really
happy
with
the
solution.
So
the
next
step
for
us
was
to
go,
build,
pull
requests,
so
we
built
this
nice
pull
request
workflow,
and
we
realized
that
you
couldn't
actually
close
the
pull
request.
A
You
couldn't
merge
the
pull
request,
because
Lib
get
to
didn't,
have
any
code
to
do
the
merge,
so
that
was
a
bit
of
a
bummer
for
us.
We
realized
that
we
were
gonna
have
to
extend
Lybia
we'd
already
embraced
it
now.
It
was
time
to
extend
it,
and
that
was
no
problem
for
us,
because
we've
been
building
version
control
technology
for
a
long
time.
We
could
absolutely
build
merge
code
into
Libya.
A
No
problem
the
problem
was
lib,
get
two's
license
it's
under
the
GPL
that
GPL,
that
you
know,
Bill
Gates
doesn't
like
so
much,
and
that
means
that
if
we
built
this
merge
code,
we
would
have
to
give
it
back
to
Libya.
We
would
have
to
open
a
pull
request,
send
it
back
and
all
the
other
users
will
live,
get
could
use
our
merge
code.
A
Users
like
github,
so
we're
building
a
code
collaboration
platform
that
fundamentally
competes
with
github
we're
really
going
to
hand
them
our
intellectual
property,
because
we
were
really
excited
about
our
merge
algorithm
it.
We
knew
that
we
could
do
things
in
memory
and
with
fewer
resources
than
what
running
get
on
the
command
line
gives
you,
and
so
we
knew.
If
we
gave
this
back
to
github,
they
would
be
able
to
basically
cut
their
server
resources
every
time
somebody
clicks,
merge,
pull
request
and
Chris
said.
A
However,
mind-bogglingly
many
times
that
happens
in
a
year,
we
were
suddenly
cutting
the
resources
that
github
needed
to
do
that
and
that's
not
theoretical
github
actually
did
adopt.
Libya
two's
merge
engine
to
do
pull
requests
and
it
did
actually
save
them.
A
ton
of
resources,
the
blue
sort
of
line
at
the
top,
the
blue
lines-
are
using
git.
The
command
line
get
to
merge,
pull
requests.
The
green
at
the
bottom
is
using
Libya,
so
it's
much
smoother
and
much
more
predictable
and
it's
a
lot
lower
resources
net
call!
That's
that's
money
right!
A
So
we
were
really
worried
about
going
down
this
path
of
contributing
the
merge
code
back
to
Libya,
but
we
realized
again.
This
was
early
in
our
understanding
of
open
source
at
Microsoft.
We
realized
that
Libya
isn't
really
our
competitive
advantage.
Nobody
chooses
a
code
collaboration
platform
because
they
can
merge
a
pull
request
just
a
little
bit
faster
right,
you're,
never
even
gonna
notice.
So
this
was
an
interesting
discovery
for
us.
A
We
learned
that
open
source
really
isn't
a
some
game,
so
that
was
kind
of
the
the
challenge
for
the
product
team
to
understand
that
we
could
actually
build
or
software
collaborate
in
open
source
communities
and
ultimately
give
back
and
actually
work
and
collaborate
with
our
competitors.
And
that's
when
my
products
even
realized
that
we
we
could
do
this
and
be
successful
with
it.
A
The
problem
was
that
we
had
to
convince
some
other
people
that
we
could
actually
be
successful
with
this,
like
our
lawyers,
the
lawyers
that
made
us
kill
off
one
of
our
products
when
we
got
acquired,
we
were
really
not
excited
about
having
a
conversation
with
them,
but
we
went
to
them
and
we
told
them
that
we
wanted
to
use
git.
We
wanted
to
use
this
GPL
code
and
I.
Remember
my
lawyer
looked
at
us
and
he
digested
all
this,
and
he
said
well.
A
I
have
some
thoughts
on
this,
but
I'm
really
excited
because
right
now,
I
push
all
my
code
to
github,
and
you
know
when
I'm
hacking
at
night
on
my
open-source
projects,
I'd
really
love
to
be
able
to
push
to
a
Microsoft,
and
we
just
our
minds
were
blown
it
turns
out.
Our
lawyer
was
a
software
engineer
like
actually
a
better
programmer
than
I
am
and
contributes
to
open-source
code
when
he
goes
home
at
night.
So
we
got
our
lawyers
on
board.
It
turns
out
that
the
developer
tools,
lawyers
are
actually
a
pretty
cool
bunch.
A
This
is
actually
our
legal
team,
but
there
were
other
people
that
we
had
to
convince
like
our
senior
leadership
and
at
the
time
it
wasn't
sachin
adela.
Yet
it
was
still
Steve
Ballmer
and
this
meeting
I
wasn't
in
I
wish
I
had
been,
but
I
understand
that
we
went
in
and
Steve
said,
I,
don't
I,
don't
know
about
this
and
we
said:
look
the
developers
want
it
and
Steve
said
the
developers.
B
A
Is
of
course,
Steve
Steve
that
I
think
this
was
Microsoft's,
professional,
Developers,
Conference
and
there's
a
lot
of
things
you
can
say
about
Steve
Ballmer,
he's
a
little
excited
and
he's
a
lot
sweaty,
but
he
actually
means
this.
Microsoft
was
built
as
a
developer
tools,
company,
and
so
he
said.
Okay,
the
developers
want
this
I'll
make
it
happen,
and
so
we
put
get
support
into
Visual,
Studio,
the
IDE
and
a
team
foundation
server
and
into
visual
studio
team
services
and
suddenly
people
liked
us
again.
A
Instead
of
people
saying
terrible
things
on
the
internet,
they
told
us
how
awesome
it
was
and
we
were
so
happy,
and
so
my
buddy
Martin,
the
one
in
Northern
Ireland
who
really
helped
make
all
of
this
happen.
He
he
decided
he
wasn't
done
yet.
He
decided
that
we'd
had
such
success
in
working
in
open
source
entities
and
bringing
open
source
into
our
products
that
maybe
we
should
take
it.
A
step
farther
and
so
Martin
went
to
the
dotnet
team
and
open
sourced
dotnet
framework,
the
Rosalind
compiler.
A
He
worked
with
them
to
open-source
a
ton
of
Microsoft
technologies
and
build
out
the
dotnet
foundation
in
order
to
responsibly
manage
that,
and
the
cool
thing
about
the
dotnet
foundation
is
that
it
wasn't
just
handling
Microsoft's
open
source
technologies.
It
was
bringing
in
a
bunch
of
other
technologies
from
the
community
too.
So
there
are
all
sorts
of
groundswell
around
doing
open
source
in
the
dotnet
ecosystem,
we're
so
excited
by
that,
and
that
is
how
we
ended
up
becoming
an
incredible
open
source
contributor
on
github.
A
It
wasn't
just
us,
though,
we
were
actually
bringing
people
into
the
community
to
work
on
dotnet
open-source
projects
in
2015
we
had
a
smattering
of
people
working
on
it
by
2017,
though
they
were
across
the
globe,
and
these
aren't
just
little
changes.
People
from
outside
Microsoft
are
making
huge
impactful
changes
on
the.net
platform.
A
There's
a
guy
named
Ben
Adams,
who
I
think
he's
building
a
game;
I,
don't
actually
remember
what
but
he's
an
independent
developer,
and
he
don't
work
for
Microsoft
at
all
and
he's
decided
to
go
through
basically
step
through
line
by
line
and
profile
the
the.net
framework
as
deeply
as
he
can
and
he's
doing
things
like
reducing
the
number
of
memory
allocations.
You
know,
I,
don't
even
know
what
all
he's
doing
it.
The
guy's
crazy
he's
an
insanely
good
programmer
and
he's
making
dotnet
better
for
everybody
just
because
he
wants
his
game
to
be
faster.
A
That's
great!
That's
the
open
source
ethos
in
work
at
work
and,
while
we're
doing
this,
we're
so
excited
to
see
not
just
again
Microsoft
people
but
we're
bringing
Google
into
the
dotnet
foundation.
So
again,
we're
learning
how
to
work
and
collaborate
with
our
competitors
for
the
good
of
the
entire
ecosystem.
A
We
were
really
happy
with
the
way
we
were
bringing
in
bringing
open,
source
and
and
contributing
to
open
source,
but
what
we
needed
to
do
was
reflect
a
little
bit
so
I,
don't
know
how
many
you
have
seen
this
this
illustration.
It's
a
great
comic.
It
points
out
the
various
org
charts
of
various
high
tech
companies
and
I
wish
I
could
get
into
all
of
them.
You
should
you
know,
check
this
out,
but
let's
just
zoom
in
on
Microsoft's.
A
So
this
is
a
little
bit
unfair,
but
it's
honestly
when
I
started
at
Microsoft,
it's
not
a
lot
unfair.
This
isn't
the
way
we
would
have
described
it.
We
would
have
used
nicer
euphemisms.
We
would
have
talked
about
how
Microsoft
lives
in
silos
and
what
we
mean
when
we
say
that
is
that
the
windows
team
is
basically
its
own
business
unit.
The
office
team
is
basically
its
own
business
unit
same
with
visual
studio
in
the
battle
days
of
Microsoft.
A
Even
though
the
windows
team
absolutely
uses
office
everyday,
they
use
word,
they
use
Excel
and,
of
course
they
use
Outlook,
that's
basically
the
favorite
program
of
any
engineer
or
program
manager
at
Microsoft.
We
live
in
email
all
the
time,
so
the
windows
team
couldn't
escape
having
to
use
office.
The
office
team,
of
course
runs
on
Windows
and
both
of
them
build
their
code
with
visual
studio
and
the
compilers
therein,
and
yet
there's
not
a
lot
of
collaboration
in
these
teams.
A
So
we've
got
a
three-letter
acronym
for
it.
It's
one.
Yes,
with
one
engineering
system,
we
were
going
to
adopt
the
best-of-breed
technologies
for
everything
we
were
going
to
move
everybody
in
to
get.
We
were
going
to
move
everybody
into
visual
studio
team
services,
our
cloud-hosted
code
repository,
and
we
were
going
to
open
it
up.
So
the
idea
now
is
that
we
were
gonna
adopt
an
inner
source
workflow
within
Microsoft.
A
We
would
put
the
windows
codebase
in
to
get,
which
is
an
amazing
story
in
and
of
itself
we
had
to
build
a
technology
called
gvfs
to
do
it
because
get
alone,
like
I
mentioned,
can't
handle
giant
repositories
like
the
windows.
Codebase
windows.
Codebase
is
300,
gigabytes,
I,
don't
know
if
it
needs
to
be
300
gigabytes,
but
that's
what
happens
over
20
years
of
accumulated
technology
growth.
A
So
we
went
down
this
path
of
building
an
inner
source
mechanism,
so
we
put
code
bases
like
Windows
we're
putting
office.
In
now,
all
4,000
developers
on
the
Windows
codebase
are
checking
into
a
git
repository
all
the
time
and
they're
accepting
pull
requests.
So
all
of
the
repositories
within
the
company
are
now
being
hosted
openly.
It
didn't
used
to
be
that
I
could
see
the
windows
codebase
now
I
can
and
there
are
actual
tangible
benefits
from
us
doing
this.
This
isn't
just
a
nice
thing
to
say
that
you
know
we
can
do
that.
A
A
We
moved
office
into
this
inner
source,
one
engineering
system,
and
so
they
built
out
their
continuous
integration
pipeline
and
they
were
pretty
pleased
with
it
until
it
was
time
to
move
their
apps
over
because
you
can
get
the
iOS
apps
and
the
Android
apps
for
office,
and
so
they
started
building
their
CI
pipeline
for
the
apps
and
they
got
to
the
end
the
very
end
they
had.
They
built
the
apps
and
then
what
they
wanted
to
do
is
code
sign
those
apps
because,
of
course,
to
get
into
an
app
store.
You
need
to.
A
You
need
to
be
code
signed,
and
so
they
came
to
us
and
said:
hey
guys.
How
do
I
code
sign
this
and
we
said
I
yeah
can't
it
turns
out
that
we
had
no
mechanism
for
doing
code
signing
at
the
end
of
a
build,
and
they
said
great
well
when
you
get
to
that
and
we're
like
yeah
we're
not
like
this
totally
isn't
on
our
radar.
We
got
a
bunch
of
other
things
to
get
done.
First,
I
know
it's
important
for
you
and
they
said
and
just
like.
A
A
If
this
was
an
open-source
project,
they
forked
the
visual
studio
team
services,
repo
and
they
went
and
added
code
signing
support
so
that
they
could
code
sign
their
Android
app
and
get
it
into
the
Google
Play
Store
code
sign
their
iOS
app,
get
it
into
the
iOS
store
the
Apple
Store,
and
then
they
opened
a
pull
request
and
sent
it
back
to
us
and
of
course
we
went
back
and
forth
a
little
bit.
You
know
we.
We
wanted
a
little
touch-up
here.
We
wanted
a
little
touch-up
there.
A
A
few
changes
a
couple
of
tweaks
and
then
we
merged
it,
and
then
we
deployed
it.
We
deploy
visual
studio
team
services
every
three
weeks
so
a
couple
weeks
later
now
that
was
live
in
bsts
and
not
just
for
the
office
team
for
all
of
our
customers,
so
the
office
team
actually
improved.
All
of
our
customers
lives
through
this
inner
source.
Workflow
and
that's
just
one
example:
we've
been
seeing
these
positive
benefits
throughout
the
company.
A
We've
been
seeing
an
increase
in
velocity
to
bring
our
code
to
market
it's
so
much
easier
to
deploy.
Now
when
we're
all
using
very
similar
systems,
we
don't
have
to
build
out
our
own
deployment
mechanisms.
The
deployment
pipelines
that
are
there
are
excellent
for
us
right,
so
we
can
as
little
parts
of
the
organization
we
can
stop
trying
to
reinvent
the
wheel
and
that's
so
important
for
us
to
just
use
Best
of
Breed
technologies.
A
So
we
were
so
happy
to
go
down
this
path
that
we
never
thought
we
would
go
down
at
Microsoft
where
we
started
just
by
realizing
that
we
couldn't
build
our
own
tools
for
everything
that
sometimes
we
needed
to
take
off-the-shelf
components,
and
sometimes
those
are
open
source.
So
we
learned
how
to
embrace
the
open
source
communities,
how
to
work
with
them.
A
Even-
and
there
are
competitors
like
right
here
at
github
and
with
Google.
We
learned
then
how
to
open
source
our
own
technologies
and
build
communities
around
them
so
that
people
wanted
to
collaborate
and
make
our
products
better.
And
finally,
we
looked
at
ourselves
in
the
mirror
and
realize
that
these
things
that
we
were
espousing
publicly
we
needed
to
do
privately
to,
and
so
we
needed
to
bring
those
into
an
inner
source
sort
of
workflow.
A
A
There's
there's
a
lot
of
us,
so
thanks
so
much
and
if
you
were
interested,
if
you
were
interested
in
the
story
of
how
get
adopted,
how
Microsoft
adopted
get
be
sure
to
check
out
a
new
podcast,
it's
called
all
things
get
we're
talking
to
people
who
are
doing
awesome
things
with
git
and
github
in
their
organizations.
So
thanks
again,.