►
Description
Presented by:
Jamie Jones, Director of Field Architects at GitHub
Tosha Ellison, Director of Member Success at FINOS
John Mark Walker, Director, Open Source Programs Executive at CapitalOne
Gil Yehuda, Sr. Director of Open Source at Verizon Media
This fireside discussion with open source leaders with experience in some of the largest organizations in the world will expose achievements, best practices, and some pitfalls along the way to embracing open source, even in risk adverse environments. They'll share the successes and challenges they’ve overcome as they’ve integrated open source technologies, methods, and culture into its daily business operations. You'll also hear insights from the State of Financial Open Source Survey (sponsored by the FinTech Open Source Foundation and GitHub) to better understand how industries, specifically financial services, are adopting open source.
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
Good
morning,
everyone
thank
you
for
joining
us
this
morning,
through
a
panel
on
embracing
open
source
in
risk,
adverse
organizations,
I'm
Jamie,
Jones
I,
lead
our
field
architecture
team
here
at
github
really
happy
to
be
sort
of
moderating
or
trying
to
moderate
this
wonderful
panel.
We
have
for
us
today,
as
you've
heard
throughout
the
last
two
days,
open
source
and
its
value,
and
not
only
the
community
and
security
but
on
organization
and
organizations,
is
something
that's
constantly
growing.
A
A
Organizations
who
are
also
sort
of
embarking
on
or
deeply
down
this
open-source
journey
I
would
really
want
to
have
an
opportunity
for
them
to
share
their
own
stories,
their
experiences,
their
successes,
and
maybe
some
of
the
pitfalls
they've
had
along
the
way
of
how
they've
been
able
to
sort
of
drive
open
source
within
their
organizations.
Real
quick,
even
if
we
can
see
you
beyond
these
bright
lights,
goodbye,
a
show
of
hands,
are
there
those
who
work
in
risk
adverse
organizations,
heavy
security
compliance
regulation
and
are
maybe
still
trying
to
do
open
source
wonderful.
A
B
I'm
John
Mark
Walker
I
run
the
open
source
program
office
at
Capital
One.
You
may
know
me
from
such
hits
as
VA
Linux
and
SourceForge.
Sorry
for
the
kids
out
there,
SourceForge
was
github
before
get
out
all
right
and
then
hi,
Pyrrhic
and
groundwork,
and
more
recently,
Gluster
in
Red
Hat
I
I
spent
the
last
20
years,
working
on
open
source
communities
being
a
community
manager
or
community
facilitator,
developer
relations,
and
about
five
or
six
years
ago,
I
started
asking
myself
the
question
I
feel
like
I'm
good
at
what
I
do.
B
But
the
central
question
is
how
much
valued
is
what
I
do
actually
add
to
the
organization
for
which
I
work?
How
does
that
translate
my
dollars
and
cents?
And
so,
as
I
started
thinking
about
that,
you
know
I
start
thinking
about.
Why
is
it
that
technology
vendors
are
ever-present
in
all
these
open-source
communities
and
if
we
agree
that
so
much
innovation
happens
in
these
open-source
spaces?
B
Why
is
it
that
it's
so
heavy
with
software
vendors
and
software
makers
and
not
some
of
these
larger
traditional
enterprises
and
so
that's
kind
of
beyond
the
the
journey
towards
where
I
am
now
at
Capital
One,
because
I
thought,
you
know,
be
a
really
good
chance
to
dive
in
and
figure
out.
You
know
how
is
open-source
being
used
within
Capital
One
and
companies
like
it,
and
how
can
we
make
the
participation
rate
greater
and
how
can
we
add
value
and
get
value
because
it's
you
know
has
to
be
a
symbiotic
relationship.
B
C
The
director
remembers
success
at
finis
and
I'll
start
Wirth.
First,
with
what
finis
is
we're
the
FinTech
open-source
foundation,
so
we're
an
independent,
non-profit,
501,
C,
6
and
really
our
aim
is
to
get
financial
services
institutions,
so
large
banks,
hedge
funds,
asset
managers
to
do
more
with
open
source.
So
they
tend
to
be
very
large
consumers
of
open
source,
but
not
great
on
the
contribution
side,
and
so
really
that's
why
we
exist.
We
have
many
large
banks.
As
our
is
our
members.
C
We
have
Capital
One
a
Citibank
JP
Morgan
Morgan,
Stanley,
Goldman,
Sachs,
Wells,
Fargo,
HSBC,
Georges
Bank.
You
know
all
the
big
players,
some
smaller
ones
as
well,
and
then
we
have
tech
companies,
github,
Red,
Hat
and
financial
services,
focused
tech
companies,
IHS
market
trade,
Web
Reef
in
of
and
then
service
companies,
some
smaller,
smaller
fintax
green
key,
just
some
interesting
stuff
with
voice
wit-pro.
C
You
know
big
organization
and
come
in
and
a
lot
of
the
financial
services
institutions.
So
really
we
bring
them
all
together
to
help
them
figure
out
how
to
collaborate
and
innovate
using
open
source
and
the
way
we
do
that
is.
Is
twofold?
Really
one.
It's
for
those
companies
who
don't
have
policies
or
processes
to
be
able
to
contribute.
We
work
with
them
to
kind
of
them
along
the
scale
so
that
they
can
actually
engage.
C
And
then
we
also
host
a
number
of
projects
within
the
foundation
where
these
banks
and
technology
companies
can
come
together
to
collaborate
on
open
source
software
and
standards,
and
so
the
way
the
way
I
got
into
finis
was
my
career
has
always
been
in
financial
services
in
technology,
I
started
in
a
Silicon
Valley
startup
just
down
the
peninsula
developing
risk
management.
Software
for
thanks
I
then
went
to
work
for
a
bank.
C
I
worked
there
for
a
credit
suisse
for
about
fourteen
years
in
technology
and
in
front
office
in
electronic
trading,
and
one
of
the
things
that's
very
remarkable
is
that
it's
a
lot
of
the
same
software
built
again
and
again
and
again
often
within
the
same
institution,
and
certainly
across
the
street,
so
across
the
banks,
how
many
trade
bladders?
Do
you
really
need
yeah?
So
that
led
us
some
few
of
us
internally
to
think
about?
Well,
what
what
can
we
do
to
help
these
banks
mutual
eyes?
C
The
software
to
take
out
some
of
that
duplicate
have
spent
to
then
spend
more
time
on
the
interesting
stuff
and
so
I.
We
co-founded
a
startup
founded
by
Credit
Suisse,
which
was
a
little
bit
harder
than
we
had
hoped
and
then
did
some
consulting
and
then
came
to
finis.
And
so
it's
really,
you
know
the
transition
has
been
within
the
financial
services
and
seeing
where
you
can
take,
you
know
those
opportunities
to
collaborate,
and
you
know
we
truly
believe
that
open
source
is
is
the
way
forward
for
financial
services,
a
risk
versus
cover
institution
Gil.
D
Hi
I'm
Gil,
yahuda
I
run
the
open
source
program
at
Verizon,
media
and
I'll.
Tell
you
the
short
story.
Many
years
ago
I
was
an
Enterprise
Architect
at
fidelity
investments
and
at
the
time
when
open
source
came
up,
I
was
vocally
opposed
to
running
an
open
source
program
and
doing
anything
with
open
source.
I
thought
it
was
a
horrible
idea,
and
people
knew
that
I
thought
it
was
a
horrible
idea.
D
Just
I
was
I
was
I
was
the
person
on
the
other
side
of
that
conversation
and
through
self-reflection
education,
personal
involvement,
evolvement
I
switched
so
a
few
years
later,
I
found
myself
running
the
open
source
program,
office,
Yahoo
and
I've
been
at
Yahoo
for
almost
10
years
now
running
the
open-source
program
there
Yahoo
was
acquired
by
Verizon
merged
with
AOL,
so
I'm
running
the
open
source
program
at
Yahoo
and
AOL
in
a
division
of
Verizon
called
Verizon
media.
So,
where
I
started
in
this
very
risk-averse
financial
services,
open
source
is
bad.
D
Flipped
to
a
open
source
is
awesome.
Let's
give
away
Hadoop
and
see
what
happens.
You
know,
let's
create
Big
Data
as
an
ecosystem
and
see
what
we
can
do
with
it
right.
So
this
sort
of
complete
opposite
to
now
the
nexus
between
a
division
of
Verizon,
which
is
an
internet
media
company
and
very
has
a
very
positive
sentiment
towards
open
source
in
an
organization.
That's
traditional
and
risk-averse,
and
you
know
not
as
much
into
hey.
Let's
do
open
source
right
so
I'm
watching
that
game
play
out
again.
Wonderful.
A
Well,
thank
you
all
for
joining
us.
Hopefully,
we
can
sort
of
build
on
your
backgrounds
and
the
things
you're
doing
today
at
your
at
your
businesses
or
with
the
groups
you're
supporting
to
sort
of
pull
together,
how
your
organizations
are
able
to
sort
of
handle
open
source
and
succeed
in
it
today.
So
on
that
same
topic,
one
of
the
things
we've
heard
multiple
times
today,
I
heard
erica,
be
mentioned
that
today,
during
the
key
during
the
keynote
applications
built
today
started
right
now
are
comprised
of
upwards
of
90
percent
open
source
software.
A
This
isn't
the
case
even
five
years
ago,
ten
years
ago,
so
the
way
applications
are
built
and
designed
is
changing.
How
is
this
actually
changing?
The
way
your
organization's
are
building
software?
Are
they
racing
open
source?
The
same
way
different
ways?
What's
been,
the
actual
results
you've
seen
internally,
we've.
B
Been
pretty
forward-looking
when
it
comes
to
how
we
use
open
source
software
and
how
we
utilize
it,
and
we
embraced
it
I
think
over
five
years
ago,
when
our
company
CIO
step
and
said
we're
in
open
source
first
organization,
so
I
would
say
it's.
It's
changed
substantially.
How
we
assemble
software,
how
we
distribute
it
internally
within
the
company
and
also
you
know
kind
of
it
kind
of
led
the
way
to
us
being
a
publicly
a
public
cloud
embrace
ur,
especially
for
you
know,
compared
to
other
people
in
our
industry,
so
I
would
say
substantially
I.
A
C
With
and
so
we
see,
you
know,
we
see
quite
a
variety,
there
are
people
who
aren't
even
fully
tracking
their
consumption
of
open
source,
yet
which
obviously
has
risks
that
have
to
be
addressed,
and
so
you
know
that's
an
issue
and
then
maybe
have
done
a
single
contribution,
but
can't
contribute
back
bug
fixes
to
you
know,
standards,
pieces
of
software,
so
you
know
I
think
there.
There
definitely
definitely
is
a
change,
even
in
the
last
ten
five
years,
in
being
more
accepting
of
that
contribution,
but
that's
a
long.
C
It
takes
a
long
time
to
get
from
right.
We
probably
have
to
do
it
and
and
not
everybody
is
still
there
yet
by
the
way.
There's
you
know
you
still
talk
to
some
people
in
you
know
big
financial
institutions
and
they
say
open
source.
Now
we're
good.
We
build
all
our
stuff,
we're
fine,
we're
used
to
building
it
on
my
trailer
right.
There
he's
telling
me
what
he
wants.
I'm
just
gonna
take
care
of
it
this
way.
So
there
is
a
cultural
shift
that
has
to
change
and
I.
C
Think,
that's
that's
starting
to
happen
and
it
just
takes
a
lot
of
pushing
and
pushing
and
pushing
across.
You
know
an
organization
that
has
50,000
people
or
20,000
people
or
25,000
technologists,
let
alone
the
rest
of
the
stuff.
And
so
you
know
we
do
see
that
movement,
but
a
lot
of
it
has
to
be
that
cultural
shift
and
and
that
you
know,
and
finding
some
simple
or
specific
opportunities
to
make
a
few
things
happen
and
then
build
on
that
and
build
on
that.
So
it's
getting
there,
but
it's
it's
not
fast.
Yeah.
D
Where
we
see
it
at
least
where
I
see
it
in
my
world
is
that
within
the
organization
there
are
different
behaviors
in
different
pockets,
because
one
of
the
things
that
makes
the
one
things
that
you
find
common
in
risk-averse
organizations
and
financial
services
organizations
in
particular
is
that
they're
very
complex
such
that
you
might
have
people
who
are
in
technology
but
they're
building
products.
Other
people
who
are
in
technology
but
they're
building
platforms
and
the
way
you
build
platforms
is
different
than
or
support.
Platforms
is
different
than
the
way
you
build
products.
D
There
are
other
people
in
technology,
but
they're
on
the
CIO
organization
and
they're,
providing
products
and
services
internally
exclusively,
so
the
adoption
of
open
source,
whether
it
be
bringing
code
from
the
outside
or
using
an
open-source
vendor
versus
a
traditional
software,
license
vendor
or
using
open
source
methodology
to
build
something
might
differ
in
different
parts
of
the
company.
So
in
some
parts
of
the
company
you
say
well
we're
really
enlightened,
and
this
will
save
us
money.
D
B
If
I
may
interject
here
a
lot
of
what
drives
that
culture,
change
and
change
going
forward
is
the
day
to
conversation.
Okay,
we
built
this
thing
now.
What
how
do
we
maintain
it
going
forward
or,
as
my
as
my
manager
likes
to
say,
open-source
is
free
as
in
puppy
right,
because
now
you're
responsible
for
caring
for
this
thing
and
making
sure
that
it's
you
know
well-fed
and
well-managed
and
all
this
stuff.
So
a
lot
of
it
that
think
that
changes,
the
thinking
is
it's
not
just.
Can
you
build
this
thing,
but
can
you
build
it?
B
C
I
would
I
would
also
add
that
not
everything
needs
to
be
open
sourced.
You
know,
there's
5,000
applications
in
a
in
a
typical
Bank
between
three
and
seven.
Let's
say
they
don't
all
need
to
be
fully
open
sourced
and
they
might
all
use
open
source
software,
but
you
know
they're
their
degrees
and
so
there's
enough
opportunity
in
the
stuff
that
doesn't
hold
your
secret
sauce
to
be
identifying
opportunities.
C
I
mean
we
think
you
know
one
of
those
places
has
to
be
in
meeting
regulatory
requirements,
not
so
much
for
you,
but
definitely
you
know
that
you,
it's
all
about
transparency.
You
have
to
meet
common
standards,
your
you're
trying
to
interpret
thousands
of
pages
of
you,
know,
documentation
and
surely
that's
done
better
together
and
there's
not
a
lot
of
competitive
advantage.
Although
I
will
tell
you
that
one
time
several
years
ago
we're
having
a
conversation,
a
couple
of
big
banks,
there's
a
piece
of
incumbent
vendor
software
that
they
both
wanted
to.
C
Well,
somebody
had
a
proprietary
inbuilt
system,
another
one
using
a
vendor
tool
that
they
weren't
super
happy
with,
and
so
we
thought
all
right.
This
is
a
good
matchmaking
opportunity.
Let's
take
your
really
good
proprietary
tool,
see
how
we
can
you
know,
get
you
to
use
that
instead
and
the
guy
said
well,
but
compliance
is
a
competitive
advantage
for
us.
Why?
Why
would
we
share
this
software
and
you,
my
colleague
and
I,
just
sort
of
thought?
C
A
Super
interesting
there,
so
one
of
the
things
we
talked
about
it
get
up.
A
lot
is
sort
of
customer
obsession
and
how
we
want
to
drive
the
best
outcomes
and
the
best
successes
for
our
customers.
Thinking
that
we'll
do
that
by
compliance
being
a
competitive
advantage
right,
it's
sort
of
the
antithesis
of
that.
So
you
know
definitely
seeing
in
driving
open
source.
That
way
is
definitely
I
think
helps
out
everyone,
not
just
developers
and
engineers,
but
our
customers
in
general
I
wanted
to
dig
it
a
little
bit
on
Sir
John
Mark.
A
He
made
a
great
comment
that
a
Capital
One
a
couple
years
ago.
It
came
down
from
your
CIO
that
you
are
a
tech
first
company
you're,
an
open-source
first
company.
That's
one
way
to
embrace
open
source
right
when
it
comes
from
the
top,
but
that's
not
the
only
way
to
embrace
open
source.
Sure
Tasha
I'd
love
to
hear
from
you,
as
you
have
sort
of
insight
into
what
multiple
banks,
multiple
organizations
are
doing.
What
are
some
of
the
different
ways?
C
Absolutely
so
I'm
actually
going
to
talk
about
a
specific
interspersing
project
which,
which
then
kind
of
prompted
a
bigger
you
know
bigger,
move
towards
open
source
and
actually
putting
in
a
board.
There's
the
this
big
bank
in
Europe
refers
to
this
as
a
skunkworks
project.
They
there's
a
team
who
is
developed,
doing
a
lot
of
development
for
their
web
applications
and
internal
and
external,
and
they
they
were
doing
a
lot
of
the
same
stuff
again
and
again
and
again,
then
they
thought
alright.
C
Surely
there's
got
to
be
a
way
to
reuse
some
of
this
code
and
teams.
Other
teams
would
be
coming
them
to
say.
You
know,
for
you
know,
for
some
support
and
they're
having
to
redevelop
the
same
stuff,
so
they
took
it
upon
themselves,
a
team
of
three
to
to
try
and
just
do
more
on
automation
and
tooling.
C
You
know
to
make
it
easier
when
they
were
answering
these
questions
for
these
different
teams
who
needed
you
know
new
tools
or
services,
and
you
know
that
kind
of
built
and
then
all
of
a
sudden
lots
of
people
were
wanting
to
reuse
their
tools,
and
it
was
you
know,
is
it
was
making
the
commonly
needed
data
more
accessible.
It
was
making
sure
that
all
of
your
brand
guidelines
and
compliance
was
kind
of
built
in
it
was
you
know,
giving
you
prefabs
pages.
C
You
know
all
sorts
of
things
that
or
tools
all
sorts
of
things
that
make
sense,
and
so
this
small
group
of
three
was
then
a
bit
overwhelmed
with
the
requests
coming
in
and
I
said.
Well,
hey,
why
don't
you
help
out?
You
know
you
can
build
some
tools,
two
and
two
and
a
half
years
later.
It's
you
know
a
really
big
success
story
for
them:
they've
saved
they
say
twelve
million
euros.
C
C
They
have
all
of
the
right
people
involved,
they're.
Looking
at
more
opportunities,
there
make
sure
that
they
can
collaborate
externally.
You
know
and
github
repos,
and
so
you
know,
I
think
there
are
lots
of
different
approaches
and
I
think
you
might
have
some
examples.
Some
other,
you
know
ways
that
this
can
happen
to,
but
you
know
certainly
that's
I,
think
that
was
a
big
success,
so.
A
D
I
see
I
see
you
know.
Typically,
the
pattern
is
bottom-up.
In
some
cases,
it's
top-down,
it's
very
rarely,
starting
from
the
middle
right.
Middle
management.
Rarely
is
going
to
be
the
push,
but
middle
management
is
is
an
important
part,
usually
where
the
open
source
program
offices
reside,
is
somewhere
in
middle
management
and
yet
middle
management
isn't
always
the
friendliest
part
of
of
where
open
source
is
in
a
company
feel
attacked.
A
D
Not
the
CIA
we're
not
the
CTOs
and
we're
not
the
line
developers.
And
yet
it's
you
know,
it's
an
enlightened,
CTO
or
an
enlightened,
CIO
will
say:
yeah
open
source
is
a
good
thing.
I
read
about
it
somewhere.
We
should
do
it
and
then
sort
of
leave
it
there
right
and
then
developers
come
in
and
say
well
of
course,
we
have
to
do
open
source.
After
all,
I
have
a
career
to
manage
and
I'm,
not
gonna
rewrite
somebody
else's
code.
D
I
mean
I
need
to
need
to
be
effective
right,
and
if
somebody
in
the
middle
is
saying
oh
I
have
a
problem
with
this,
like
I
have
a
problem
with
somebody
contributing
to
my
repo
that
I
don't
control
their
time.
I
have
a
problem
with
incurring
risk
for
somebody
else's
project
and
I.
Don't
really
know
what
the
SLA.
D
It
is,
or
whatever
the
risk
is,
and
what
I
find
from
from
the
perspective
of
the
open
source
program
office
or
of
the
Advocate
within
the
risk-averse
organization,
of
whatever
it
is
in.
Your
particular
case,
is
that
you
have
to
have
the
agility
to
have
one
of
three
conversations.
One
conversation
is
one
about
fear,
which
is
the
compliance
conversation
and
it's
the
who
patches
this
and
how
is
secured
and
and
what
are
the
license,
compliance
issues
that
typically
come
up
right.
It's
the
fear
conversation,
the
other
conversation
is
sort
of
the
opposite.
D
It's
the
love
conversation.
How
do
we
enable
engineers
to
be
effective
right,
and
how
do
we
have
somebody
who's,
not
only
a
hero
when
they're
group,
but
a
hero
within
the
comp
through
inner
source
or
a
hero
when
everyone's
company
through
open-source,
like?
How
do
we?
How
to
foster
that
love?
And
the
third
is
a
conversation
about
money
like?
Are
we
saving
money?
D
Are
we
deferring
costs
and
in
some
cases,
are
we
able
to
make
money
by
giving
something
to
the
open
source
community
that
leads
them
into
some
sort
of
economic
system
that
we
have
like?
Some
of
the
larger
companies
tech
companies
do
now.
You
can't
have
the
love
conversation
with
somebody
who
wants
to
have
the
fear
one
with
you,
and
you
can't
have
a
fear
conversation
with
somebody
who
wants
the
money
conversation
with
you.
D
You
got
to
be
able
to
figure
out
who
are
you
talking
to
and
are
you
talking
to
somebody
who
is
begging
for
you
to
assure
them
that
the
fear
that
they
have
is
going
to
be
handled
by
a
good
program?
Or
are
you
talking
to
somebody
who
really
wants
to
make
sure
that
you
understand
that?
There's
something
in
it
for
them
and
have
that
love
conversation
or
indeed
the
money?
B
I
have
the
scars
from
having
the
love
conversation
with
people
who
really
just
want
to
talk
about
ROI
and
money.
So,
yes,
I
can
speak
to
that.
One
very,
very
clearly,
I
loved
your
point
about
how
Tasha's
point
about
how,
inter
source,
can
be
kind
of
a
open
source
in
a
non
scary
way
for
people
who
think
of
in
sources
super
scary,
because
it
does
take
a
lot
of
things
off
the
table
that
can
stymie
an
open
source
conversation.
So,
let's
say,
for
example,
we'll
talk
about
license.
B
Compliance
will
talk
about
vulnerabilities,
we'll
talk
about
all
the
things
that
people
bring
up
when
they
say.
Oh,
my
god,
all
this
open
source
stuff,
so
inner
source
is
great
way
to
kind
of
push
those
off
to
the
side
and
really
focus
on
the
things
that
deliver
real
value.
And
so
you
know
I,
look
at
my
team's
role
as
kind
of
like
how
do
we
provide
the
air
cover
and
deal
with
all
those
problems
around
risk
management
and
internal
audit
and
all
that
stuff,
so
that
you,
the
developer,
don't
have
to?
B
How
do
we
automate
the
processes?
How
do
we
get
that?
Going
but
to
the
point
around
you
know,
inner
source
can
be
a
great
kind
of
halfway
stuff
or
a
first
step.
I
absolutely
agree,
and
that's
that's
something
that
you
know:
we've
run
things
like
hackathons
and
sort
of
enablement
sessions
with
other
engineers
to
sort
of
build.
B
This
broad
base
of
support
we'll
need
to
go
further,
and
so,
if
you're
looking
for
a
way
to
accumulate
the
stakeholders
that
you
need
to
drive
in
a
shoes
forward,
if
you're
looking
for
ways
to
get
other
executives
involves-
and
you
can
build
again,
the
momentum
that
you
need
inner
source
activities
are
a
great
way
to
do
that.
As
long
as
you
have
support
from
the
right
people
who
can
get
involved
and
push
you
forward,
one.
A
You
spoke
really
well
on
how
even
within
Verizon
and
the
many
pieces
of
Verizon
there's
pieces
that
are
areas
that
are
much
more
forward-leaning
with
open
source
and
areas
that
are
not.
What
do
you
tell
it
as
a
developer
as
an
engineer
right
who
may
be,
unfortunately,
stuck
in
a
pocket
of
the
organization,
that's
less
forward-leaning,
with
open
source,
even
with
a
NOS
PO,
even
with
other
portions
of
the
org
that
are
embracing
open
source.
What's
your
advice
to
that
engineer,
right
who
needs
top
cover
and
can't
find
it
or
what?
D
C
D
Will
swing
at
that?
It's
a
good
story,
because
it
taught
me
to
really
think
about
risk
differently,
so
the
situation
that
we
had
is
we
have
a
product
group
that
needed
a
technology
and
we
had
a
platform
group
that
built
this
technology
and
I
asked
them
like.
Why
did
you
build
and
they
said?
Well,
we
looked
at
open
source
and
we
found
that
what
was
available
wasn't
good
enough
and
we
had
to
build
something
better
and
I
asked
him.
Well,
did
you
contribute
it
back
and
they
said
well?
No,
because
it
was
a
different
architecture.
D
It
wouldn't
have
worked
to
contribute
back.
We
really
had
to
build
this
on
her
own.
Okay,
fine
I
went
to
the
product
group.
Why
don't
you
want
to
use
that?
They
built
this
for
you
and
they
said
it's
too
skee
I
said
well,
what
do
you
mean
and
they
said
well,
that
group
can
be
defunded
right.
Those
people
can
leave.
In
fact,
one
of
the
people,
like
the
main
engineer,
I
know
he
wants
to
leave
cuz.
D
He
interviewed
with
our
group
and
he's
interviewing
elsewhere,
and
if
we
use
this
technology
that
they
built
for
us
we'll
be
like
we'll
be
stuck
if
they
get
defunded
or
if
a
blow
up,
so
we
would
much
rather
use
an
open-source
technology.
Cuz
at
least
still
work.
Now,
as
it
turns
out,
the
open
source
technology
would
have
cost
them
a
lot
more
money
to
use
in
terms
of
the
number
of
servers
they
needed
to
run.
D
So
they
were
willing
to
spend
more
money
on
an
open
source
technology
because
in
their
world
it
was
less
risky
than
using
the
internally
built
technology.
I
went
to
the
group
that
built
the
technology
and
I
said
great.
What
if
you
open
sourced
that
and
turn
that
into
an
open
source
technology
and
proved
that
it
actually
was
really
valuable
and
we
did
and
it's
open
source,
it's
called
Apache
pulsar.
D
Now
the
way
we
were
able
to
get
to
that
conclusion,
the
conclusion
that
benefits
all
of
you
in
case
you
want
to
use
Apache,
Kafka,
right
or
Apache
pulsar.
The
way
we
got
there
is.
We
asked
good
questions
like.
Why
aren't
you
using
this?
What
is
the
risk?
What
are
you
concerned
about?
Why
do
you
want
to
use
open
source?
Is
it
cause
it's
cool
or
because
there's
a
legitimate
risk
like
this,
this
team
might
not,
you
know,
be
there
for
you
next
year
right
so
for
the
engineer,
who's
getting
pushed
back.
D
Sometimes
the
pushback
is
legitimate.
A
risk-averse
company
isn't
risk-averse
because
they're
wrong
they're
risk-averse,
because
that's
what
they
are
so
in
that
environment,
ask
the
questions.
What
are
the
risks?
I'm
gonna
understand
the
answers
and
then,
with
those
answers,
figure
out
a
way
to
abate
the
risks
so
that
you
can
find
success.
That's
what
I
would
do.
B
I
I
think
so,
following
up
on
that
comment,
you
know
I
think
about
how
engineers
work
together
in
risk-averse
environments.
The
first
piece
of
advice,
I,
would
give.
You
is
really
develop
your
empathy
skills,
because
people
who
work
in
risk
management
and
internal
audit
and
legal
and
Finance
they're
not
bad
they're,
not
evil
people
they
they
have
jobs
to
do
and
I
think
it
works
really
better
if
you
can
kind
of
understand
where
they're
coming
from
and
how
you
can
actually
work
with
them
going
forward.
B
You
know
we
have
you
know
several
groups,
they
do
risk
management
who
do
who
do
internal
audit
and
I've
gotten
to
know
them
very,
very
well
over
the
last
few
months
and
I've
thought
about
you
know,
it's
really
great
that
we
have
these
resources
because
we
can
actually,
you
know
one
of
our
superpowers
that,
because
we
have
to
work
within
these
environments,
we
actually
are
finely
honed
in
ways
that
say
technology
companies
are
not
and
we're
able
to
produce.
These
kind
of
risk
management
strategy
is
about.
Okay,
well,
I
know
the
risk
of
that.
B
A
C
Some
of
the
things
that
that
you
know
we've
seen
be
successful
are
finding
you
know
specific
use
cases
as
well,
so
that
it's
not
this
amorphous
well
I
want
to
do
open
source,
you
know
and
where
legal
is
clearly
gonna,
say:
okay
well
or
unrest
and
compliance.
What
does
that
mean
specifically?
And
so
sometimes
you
know
finding
a
use
case
where
you
can
get
some
senior
buy-in
and
it
doesn't
necessarily
have
to
be
a
big
thing
but
and
where
it's
something
that
isn't
necessarily
competitive,
where
you
can
see
that
there's
an
ROI
from
collaboration.
C
So
we
have
a
project
around
cloud
service
certification,
thanks
they're,
all
going
to
the
cloud
they're
a
little
bit
slow,
they're
all
gonna
need
to
be
multi
cloud.
They
all
have
to
certify
more
or
less
the
same,
because
there
are
regulations
that
say
you
have
to
meet
it.
This
way.
Of
course,
their
regulations
from
you
know
15
different
regulators,
but
you
know
they're
all
pretty
much
regulated
across
the
board.
So
why
not
do
that
together?
C
And
so,
if
you
can
take
that
kind
of
case
and
look
it's
not
super
risky
and
we
have
a
little
bit
of
time
to
develop
it,
and
you
can
see
everything
if
you
can
take
a
specific
use
case
and
walk
through.
You
know
what
are
the
real
risks?
What
are
the
perceived
risks?
Are
we
gonna
be
sharing
data?
Well,
no,
all
right!
Well,
that
makes
it
an
easier
one
to
start
with.
You
know
our
our
we,
you
know
is
their
IP,
that's
gonna
like
well
well!
This
is
how
we
address
this.
C
C
D
I
mean
in
fact
like
I
would
I
would
take
one
of
those
examples.
So
one
of
the
things
you
just
said
reminded
me
of
a
conversation
I
recently
had
with
somebody
you
said:
oh,
we
we
can't.
We
can't
approve
this
particular.
We
can't
open
up
these
repos
because
there
might
be
you
know,
customer
data
in
them
right
and
and
my
question
that
I
shot
back
sort
of
immediately
and
a
little
perhaps
too
directly
was
like
what
wait.
You
really
think
there
could
be
customer
data.
D
If
that's
the
case,
we
have
a
huge
problem
here
like
find
out
who
those
developers
are
lying
them
against
the
wall
right
and,
let's
see,
if
any
of
em
put
customer
data
in
that
repo-
and
let's
have
you
know
everything
lock
and
loaded,
because
if
they
do
right,
you
know-
and
it
was
like-
let's
turn
this-
the
fact
that
you're
even
able
to
raise
this
risk.
That's
really
you
know
that
and
say
what
the
hell
are:
people
putting
customer
data
and
my
code
repositories.
D
Do
they
not
understand
that
that
is
like
a
huge
file
like
that's,
and
you
think
that
it's
acceptable
to
have
if
the
repo
is
private
like
that
right?
That's
the
solution!
Yeah!
Oh!
If
we
keep
it
private,
then
work.
No,
then
that's
even
greater
risk.
In
fact,
we
should
open
this
up
and
make
sure
that
it
isn't
the
case
cuz.
If
you
and
they're
they
say,
oh,
no,
no,
we're
sure
that
no
one
would
ever
put
any
customer
data.
Oh
well,
if
you're
sure,
then
why
did
you
bring
it
up?
C
A
Yes,
I
worry,
we
don't
talk
enough
about
day,
two
of
open
source
and
it's
it's
that
my
favorite
quote
on
this
topic
is
when
people
stop
being
nice
and
start
getting
real
as
preparation
for
this
I.
Did
you
know
that
the
real
world
is
on
season
33
right
now,
I
M
TV
may
not
show
music
anymore,
but
they
still
show
the
real
world,
which
is
impressive,
but
I'm.
A
Didn't
have
to
date
when
you
watch
the
real
world,
but
on
this
same
topic
like
open
source,
is
great
on
day
zero.
You've
shared
information,
but
I
often
talk
to
organizations
who
are
like
well
that
worked
until
we
found
out
our
competitor,
forked,
our
repo
and
they're,
now
selling
it
as
a
product
or
marketing
came
to
me
yesterday
and
said:
have
you
seen
the
thing
that
people
are
saying
on
this
get
up
website
about
our
company
and
how
we
haven't
updated
this
thing
forever
and
how
that
means
we're
XYZ.
A
These
are
like
real
challenges
that
we
have
to
prepare
for
and
sound
even
just
getting
the
first
open
source.
But
how
do
you
deal
with
it
after
it's
out
there?
Is
there
you
from
from
whether
it
be
legal,
whether
it
be
marketing,
whether
it
just
be
life,
I'd
love,
to
talk
a
little
bit
about
what
that
looks
like
sort
of
day.
B
One
because
well,
this
I
get
to
tout
and
laud
some
of
our
prior
accomplishments,
because
about
a
little
over
three
years
ago,
we
released
our
first
major
open
source
project.
It's
called
hi
Gia,
it's
a
DevOps
dashboard
and,
speaking
about
the
risk
management
conversation
just
had,
you
can
see
a
lot
of
our
views
around
risk
management
kind
of
baked
into
this
piece
of
software.
But
you
know
we
released
that
three
years
ago
and
you
know
I
think
if
you
had
asked
the
people
at
the
time
if
they
really
understood
how
this
would
work
on
day.
B
Two
after
we
have
the
initial
kumbaya
join
us
now
and
share
the
software.
What
happens
afterwards?
I'm
not
sure
they
could
have
given
a
good
answer,
but
now
that
we've
had
like
three
years
of
history,
developing
that
and
doing
it
in
a
very
open
and
transparent
way
and
following
all
the
good
governance
policies
of
open-source
management,
you
know
I
feel
that
it's
been
a
learning
experience
for
all
the
engineers
have
been
involved.
There's
allowed
us
to
you
as
an
hospitably,
instructive
and
enabling
of
other
engineers
who
want
to
follow
down
that
path.
B
B
B
A
B
But
it
doesn't
come
up
as
far
as
well.
Does
this
give
away
your
competitive
advantage
and
I
tribute
that
to
the
fact
that
we've
done
our
homework
and
we've
sort
of
done
it
in
a
piecemeal
fashion,
leading
up
to
this
point
where
we
can
say
yes,
this
is
this
adds
real
value.
We
can
go
about
it
in
a
risk,
managed
way
that,
doesn't
you
know,
open
up
the
store
and
can
actually
give
real
value
to
us
and
to
the
greater
community.
Large
yeah.
C
I
think
we
have
some
obviously
we're
all
about
collaboration
amongst
competitors,
so
it
happens.
It
happens
in
our
inter
foundation.
It
happens
on
github
and
repos,
but
I
do
think
that
you
know
the
bad
things
do
happen.
Yeah
and
and
and
it's
gonna
go
wrong
and
somebody's
gonna,
you
know,
do
something
that
somebody
else
doesn't
like
and,
and
that
happens
internally,
it's
gonna
happen
externally
and
you
just
have
to
work
through
it
and
so
partly
when
you
open
source
something
you
have
to
make
sure
that
you're
aware
that
those
things
happen.
C
B
C
D
Things
happen,
rarely
that's
a
tautology,
but
when
you
do
things
a
lot,
the
rare
things
happen
because
you're
doing
thing
is
a
lot
right,
so
something
that's
very
obscure
like
very
rarely
well,
we
find
ourselves
checking
in
a
key,
you
know
or
a
hash
or
something
into
a
repository
that
can
cut
open
source.
But
when
you
do
it
50
times
a
year
over
50
billion
launched
15
new
open
source
projects
a
year.
Well,
okay,
that
one
and
50.
Ok,
that's
once
a
year,
you
know
and
then
that's
a
really
bad
day.
D
You
know
you,
you
gain
a
lot
of
respect
for
the
risk
aversion
that
your
company
had
you
gain
a
lot
of.
You
actually
get
a
little
bit
of
ammunition.
You
get
to
go
back
to
your
bosses
and
say:
listen.
We
had
a
really
bad
day.
We
did
we
made
a
mistake.
We
got
on
Hacker
News
or
we
got
like
something
happened
and
that
it
wasn't
well,
it
wasn't
the
outcome
we
wanted,
but
what
we
need
is
really
to
improve
our
processes,
maybe
hire
somebody.
D
You
know
that
we
couldn't,
you
know,
handle
this
part
of
the
process
that
we
had
overlooked
and
assumed
that
everything
would
go
well.
So
bad
things
will
happen.
Risk-Averse
companies
are
risk-averse
because
they
recognize
that
their
aversion
is
is
a
message
to
you
saying
you
know.
If
you
come
back
from
the
conference,
saying
I
got
stickers,
I
got
t-shirts.
This
is
really
cool.
I
had
a
great
time
that
message
isn't
going
to
translate
into
Oh
awesome.
D
You
can
now
do
everything
you
want,
because
you
have
stickers,
you
know,
but
you
have
to
come
to
them.
With
this
strong,
like
I,
understand
the
risk.
I
understand
the
fear
I
understand
the
love
like
I
understand
how
to
get
there
and
I'm
working
with
people
I'm
with
an
organization
in
my
industry,
whether
it's
Finnis
or
or
complements
in
other
industries,
I'm
working
with
people
who
know
what
they're
doing
and
recognize
and
respect
this.
And
then
we
can
staff
up.
D
But
the
processes
in
place
learn
from
what
other
open
source
programs
do
and
actually
succeed,
because
the
risk
of
not
doing
something
is
as
great
as
the
risk
of
doing
something
and
and
the
doing
something
is
not
just
day
one
but
is
like
creating
the
organizational
muscle
to
succeed.
An
open
source
yeah.
A
Gil
putting
you
on
the
spot,
then
for
a
second:
what's
the
worst,
without
any
names
or
projects
or
where
in
your
career,
what's
the
worst
sort
of
like
open
source
outcome?
Is
it
checking
in
keys?
Is
it
the
in
in?
How
did
you
is
it
because
of
these
relationships?
You
had
previously
that
you're
able
to
get
past
this
event
this
this
problem,
or
was
it
something
or
you
you
had?
You
had
a
phone,
a
friend
that
was
like
okay,
I
need
I
need
this
one
out,
yeah.
D
D
This
is
what
they're
saying,
and
you
know
what
they're
right
there's
this
this
is
and-
and
you
know
what
it's
actually
good,
that
they're
saying
that,
because
you
give
us
a
moment,
ask
ourselves:
oh,
how
did
we
get
there
and
why
is
it
there?
You
know
and
yeah.
It
was
embarrassing
and
uncomfortable,
but
we
matured
from
it.
So
yeah
we
had.
We
had
those
yeah
I,
don't
want
to
spill
all
the
beans.
B
D
A
To
its
I,
like
the
you
know,
it's
it's.
You
need
the
right
mindset,
not
just
of
your
team
but
of
Management
and
leadership
right,
but
to
turn
these
truly
are
opportunities
right.
It's
maybe
we
don't
look
inward
enough
to
say.
Is
my
code
of
high
highest
quality,
or
are
we
actually
doing
enough
to
make
sure
customer
data
or
PII
isn't
getting
checked
in
right?
The
problem
isn't
the
open
source?
It's
sometimes
it's
us
and,
like
that's
a
hard
problem,
that's
a
hard
feeling
to
have,
but
it's
a
real
thought
to
have
one.
B
B
Sometimes,
but
working
environment
like
this
teaches
us
that
the
means
to
collaboration
the
the
governance,
all
the
things
that
are
not
necessarily
highly
valued
in
engineering
organizations,
turn
out
to
be
actually
really
super
valuable
and
because
we
work
in
the
environments,
we
do
we're
forced
to
have
a
more
holistic
view
of
what
a
project
looks
like
and
what
project
governance
looks
like,
and
source
code
is
obviously
valuable
if
it
weren't
for
source
code.
We
wouldn't
be
here
and
we
wouldn't
have
jobs,
but
but
there's
a
whole
lot
else
around.
A
C
I
want
I
want
people
to
know
that
financial
services
is
actually
embracing
open
source
and,
and
there
are
all
sorts
of
reason
why
compressed
margins
and
continued
spend
on
Reg
means.
They're
gonna
have
to
do
things
differently,
the
talent
that
they
used
to
get
they're
not
getting
anymore,
and
so
we're
already
seeing
a
shift.
And
so
you
know,
people
who
are
into
open
source
and
want
to
build
open
source
technology
should
not
shy
away
from
the
financial
services
industry.