►
Description
London OpenShift Commons Gathering 2019 Open Source at Credit Suisse
Duncan Lawie, Credit Suisse
A
Yeah
so,
while
day
ends
up
setting
up
the
slides,
I
thought
I'd
just
ask
you
three
questions
to
get
it
started.
Who
here
is
actually
contributing
to
an
open-source
project
from
a
corporate
ID
and
who
here
is
using
an
open-source
product
within
their
environment
without
any
external
support,
then
to
support
or
anything
like
that,
so.
A
Open
source,
my
name
as
Dan
said,
is
Duncan
LOI,
I'm,
an
infrastructure
architect
at
Credit,
Suisse
and
I'd
like
to
give
you
a
brief,
perhaps
discouraging
view
of
where
open-source
fits
into
my
example
of
a
financial
services
company.
It's
my
view.
The
very
fact
of
software
being
open
source
is
not
itself
a
differentiator
and
I'd
like
to
explain
why
and
perhaps
offer
some
reasons
for
hope.
As
with
most
enterprises,
open
source
is
spread
throughout
credit
suisse.
A
A
Instead,
the
choice
will
be
made
on
base
of
on
the
basis
of
functionality,
risk
and
reward.
So,
let's
start
with
functionality
in
terms
of
cost
versus
completeness
playing
with
the
new
technology
and
in
the
cough
of
opportunities
for
reinventing
wheel.
Now
most
commonly
open-source
products
are
used
in
places
like
ours
because
they
cost
less
and
let's
start
by
traveling
back
in
time,
a
little
bit
the
move
from
mainframe
to
UNIX.
Some
of
you
may
remember
it
all
the
way
back
to
that.
We
still
have
a
mainframe
at
credit
Swiss.
A
It
is
still
a
corporate
core
part
of
our
environment,
but
the
move
from
mainframe
to
UNIX
wasn't
because
of
licensing
exactly.
It
was
because
it
was
possible
to
buy
it
in
smaller
units
to
scale
based
on
need,
and
it
was
what
we
actually
called
in
those
days.
An
open
system
within
the
interface
less
dependent
on
the
hardware
vendor
I
think
you've
may
have
heard
exactly
the
same
kinds
of
arguments
in
terms
of
open
source
and
cloud
in
recent
years,
and
the
moon
from
Solaris
to
Linux
had
a
similar
motivation
in
the
larger
enterprise
space.
A
It
was
about
running
computer
systems
at
lower
cost
for
similar
functionality.
The
move
to
Linux
within
the
enterprise
really
only
started
to
scale
when
their
vendors,
who
banks
could
trust
and
deal
with.
Companies
like
Red
Hat
might
be
founded
on
an
open
source
philosophy,
but
they
do
a
lot
of
business
with
places
like
Credit
Suisse,
because
they
can
speak
the
corporate
language.
Indeed,
on
the
way
to
Linux
and
Intel,
we
spent
significant
time
and
effort
working
on
systems
with
odd
mixtures
of
commercial
and
open
source
components.
A
Strange
card
wear
odd
licensing,
different
vendors,
and
we
made
things
as
complicated
as
you
might
imagine,
I
think
we've
become
better
at
managing
that,
but
perhaps
mostly
we've
done
this,
because
we've
made
more
of
our
questions
event
a
problem,
for
example,
when
we
started
playing
with
Hadoop,
we
followed
down
the
open
source
track
to
begin
with,
but
we
pretty
soon
started
looking
at
distributions
and
then
we
started
narrowing
our
options.
One
vendor
who
we
tested
was
dismissed
purely
because
they
couldn't
walk
the
corporate
talk.
A
It
had
nothing
to
do
with
the
quality
of
the
distribution
itself.
Now,
of
course,
people
across
the
enterprise
are
playing
with
the
new
toys,
whether
it's
kubernetes
or
cassandra,
salt
stack
or
chrome.
We
do
things
we
do
see
all
these
things
coming
into
the
enterprise
and
from
various
sources,
and
we
are
building
mechanisms
to
enable
developers
to
experiment
without
immediately
exposing
ourselves
to
the
risk
of
direct
downloads
from
the
Internet
and
in
that
sense,
perhaps
we're
using
open-source
as
a
way
of
try
before
you
buy.
A
We
can
play
with
the
software
before
we
make
a
strategic
decision
now.
Most
major
vendors
I
can
think
of
will
give
me
a
trial
license
to
test
out
their
product,
but
there's
almost
always
a
certain
amount
of
friction
in
getting
that,
and
even
before
that
stage,
it's
a
lot
easier
to
put
free
and
open-source
software
into
the
hands
of
the
next
generation
so
that
they
are
building
up
that
skill
and
knowledge
long
before
they
can
afford
to
engage
with
the
major
enterprise.
A
Another
reason
to
use
open
software,
which
becomes
more
visible
at
smaller
scales
than
luck,
is
becomes
more
visible
at
smaller
scales
than
at
larger
ones.
There
are
very
few
businesses
who
see
value
in
building
their
own
Roth
operating
system
or
database,
but
often
development
teens
find
themselves
writing
a
piece
of
code
which
there
is
a
perfectly
good
open-source
library
buying.
A
I
wrote
a
lot
of
tests
in
Python
before
I
discover
the
unit
test
module,
for
example,
but
open-source
communities
like
to
share
the
things
they
enjoy,
whether
it's
in
person
like
today
or
online
like
muscles
for
the
rest
of
our
week,
and
that
is
one
of
the
ways
of
discovering
these
things
and
working
out
what
you
want
to
do
with
them.
Next,
the
results
of
developers
can
get
on
with
doing
a
new
thing,
a
business
specific
thing
rather
than
building
and
maintaining
non
differentiating
code.
A
A
It
looked
like
a
tough
nut
to
crack,
and
today
we've
made
that
question
much
more
of
a
vendor
problem,
as
I
mentioned
earlier,
I
remember
the
days
of
fadh,
fear,
uncertainty
and
doubt
when
the
viral
nature
of
open-source
licenses
meant
that
corporations
felt
that
they
needed
to
keep
clear
of
these
products
in
case
suddenly,
the
proprietary
business
functionality
was
exposed
to
the
eyes
of
the
world.
Now
some
licenses
still
do
worry
a
bit
such
as
the
Afro
license.
A
Indeed,
I
tend
to
see
that
particular
license
as
a
way
of
getting
in
the
front
door
on
an
open-source
basis
and
then
encouraging
companies
to
move
to
an
alternate
commercial
offering,
so
they
have
better
protection
against
them.
The
remaining
viral
elements
of
that
particular
license,
but
in
most
cases
the
perceived
threat
has
retreated.
There
are
three
key
reasons
for
this.
Firstly,
there
are
better
commonly
shared
definitions
of
what
open-source
means
and
many
open-source
projects
now
a
package
definition
off-the-shelf,
rather
than
writing
their
own
license
for
the
ground-up.
A
Secondly,
the
business
has
built
legal
expertise.
While
there
is
still
not
a
lot
of
case
law
in
this
space,
there
is
a
much
more
general
understanding
on
the
part
of
us
as
consumers
as
to
what
we
do
and
don't
get
the
right
to
do
with
software.
And
thirdly,
as
I've
mentioned
a
couple
of
times,
business
relationships
with
intermediaries
and
suppliers
of
open-source
give
our
corporate
Warrick
worriers
comfort,
but
our
corporate
worries
have
other
things
to
consider.
Also,
there
comes
a
point
in
the
process
where
this
stuff
becomes
critical
infrastructure.
A
A
Sometimes
perhaps
that
contract
is
a
comfort,
blanket
I've
seen
how
much
pressure
we
need
to
bring
to
bear
on
a
commercial
vendor
when
they,
when
we
want
to
patch
the
software
that
isn't
on
their
priority
list
or
we
see
a
valuable
enhancement
to
a
product,
but
it's
not
on
the
product
managers
critical
path.
Yes,
when
the
product
is
open-source,
we
could
just
fix
it
ourselves.
Of
course,
there
are
people
within
our
environment
who
can
use
and
manage
open-source
product
products.
They
can
understand
the
documentation
when
they
can
find
it.
They
can
apply
it.
A
Perhaps
they
can
even
supply
patches,
but
we
tend
not
to
choose
to
do
this
because
we
would
rather
be
writing
out
having
our
coders
spend
their
time
writing
stuff
for
our
own
in-house
applications.
That
staff
is
part
of
our
business,
our
intellectual
property
and
increasingly
the
other
software,
particularly
for
infrastructure,
isn't
considered
business,
differentiating
once
upon
a
time,
Credit
Suisse
actually
wrote
our
own
H
a
solution
for
UNIX
because
it
was
met.
A
Our
availability
needs
better
and
cheaper
than
what
was
available
on
the
market
at
the
time,
and
what
has
happened
since
is
that
we've
got
rid
of
that
product
completely.
We
take
it
from
a
third-party
vendor,
whether
it's
a
commercial
offering
like
Veritas
or
an
open-source
offering
like
pacemaker,
and
we
don't
wish
to
employ
people
for
expertise
which
they
very
rarely
need.
But
when
the
answer
is
slack,
Stack
Overflow
and
a
mailing
list,
then
nervousness
is
going
to
result.
A
We
don't
think
it's
a
valid
strategy
to
hope
that
a
bug
or
an
issue
is
going
to
be
fixed.
The
organization
wants
to
know
what
its
mitigation
strategy
is,
and
that
means
refining
a
commercial
intermediary
who
will
provide
us
with
insurance
at
that
point,
what
does
it
matter
that
Linux
is
an
open
source
product
that
Hadoop
is
Apache
Hadoop
when
someone
from
Rio,
DBD
sale,
sales
team
tells
me
that
their
product
is
open
source.
What
are
they
trying
to
tell
me?
A
Perhaps
it's
the
code
that
the
code
can't
be
made
proprietary,
but
even
my
sequels
ownership
by
Oracle
as
a
corporation,
has
not
actually
removed
GPO
now
to
be
fair
to
Moorea,
DB
and
Postgres.
They
have
structures
defined
to
make
sure
that
they
will
not
be
a
single
company
which
has
a
majority
share
in
the
software
assets.
A
But
what
difference
does
that
make
to
me?
Perhaps
the
argument
is
that
I
can
go
somewhere
else
to
get
my
commercial
support
for
the
open
source
product,
but
when
one
support
organization
has
the
majority
of
the
support
capability,
why
would
I
pick
a
junior
player?
Indeed,
there
is
a
concern
that
a
small
vendor
couldn't
bear
the
weight
of
providing
critical
infrastructure
and
compare
that
with
an
open
source
product
where
there's
no
commercial
supplier
at
all.
A
Indeed,
taking
significant
amounts
of
risk
of
software
from
such
sources
might
even
be
seen
as
poor
risk
management
by
our
regulators,
and
we
have
many
regulators.
The
biggest
potential
for
risk,
though
in
a
bank,
is
on
the
security
of
or
vulnerabilities
with
the
product.
Now,
in
practice,
a
spyware
Trojan
horse
may
well
be
more
likely
to
come
into
the
bank
in
a
virus
than
in
an
open
source
program,
but
there
is
certainly
a
danger
of
dodgy
code,
particularly
when
most
of
us
have
seen
commercial
code,
deliver
the
wrong
results
or
create
security
holes.
A
The
first
open
source
response
may
well
be
the
old
line
that
many
eyes
make
bugs
shallow,
but
we
can't
really
rely
on
that,
particularly
if
the
coding
question
is
going
to
be
operating
on
valuable
or
private
data.
The
cost
of
mistakes
is
high
and
the
number
of
Ceuta
faults,
suitably
qualified
eyes
might
well
be
very
low
and
whilst
most
problems
of
the
result
of
mistakes,
there
is
also
the
possibility
of
bad
actors.
A
There
is
also
a
very
distinct
concern
about
the
maintenance
effort
that
we
are
creating.
Yes,
it
was
the
latest
and
best
when
we
obtained
it
from
the
repository,
but
that
doesn't
stay
the
case
forever.
Whilst
we
may
not
be
able
to.
Whilst
we
might
be
able
to
afford
not
to
take
the
new
functionality,
some
proportion
of
change
in
the
code
base
is
going
to
be
resolving
known
issues
where
the
simple
bugs
or
security
vulnerabilities-
and
there
are
two
fairly
modes
at
least
here.
A
A
Finally,
in
the
risk
context-
and
perhaps
most
critically,
there
is
a
significant
CERN
about
data
safety
and
leakage
of
intellectual
property
that
property,
which
that
code,
which
creates
our
competitive
advantage.
I've
already
mentioned
the
danger
of
bringing
spyware
in-house.
Equally
worrying
is
the
possibility
of
leaking
information
when
contributing
to
an
open-source
project.
Some
of
the
leakage
could
seem
innocuous
names
of
internal
projects
or
staff
as
part
of
comments
or
commit
information.
A
Next,
there's
a
possibility
of
hard-coded
test
data
or
infrastructure
information
in
the
code.
Most
important,
though,
is
when
the
code
itself
is
that
differentiating
intellectual
property
I
doubt
any
bank
plans
to
share
its
high-frequency
trading.
Algorithms,
at
least
not
on
purpose
but
unconsidered,
commits
to
a
public
repository,
can
also
share
information
and
value
to
competitors,
and
that
worries
our
corporate
warriors
so
with
so
much
to
worry
about.
Why
would
we
even
consider
contributing
to
open
source?
A
Perhaps
the
most
obvious
item
is
something
I
already
mentioned
a
faster
cycle
time.
If
we
can
avoid
reinventing
the
wheel,
then
we
can
improve
the
cycle
time
of
our
of
our
own
deliveries,
and
perhaps
we
can
end
up
reducing
the
amount
of
code
that
it
is
our
job,
the
job
of
our
own
staff,
to
maintain
yes,
the
code
still
needs
to
be
maintained,
but
if
we
could
meet
the
cycle
that
external
parties
work
at
that
effort
is
spread
much
more
widely.
A
A
Another
benefit
is
a
better
tech
landscape
inside
the
bank.
This
applies
even
when
the
code
we
share
is
not
actually
open-source
in
a
source
or
internal
open
source
helps
to
build
a
mindset
that
code
could
be
edited
by
people
in
other
teams
in
other
parts
of
the
organization
and
therefore
coders
need
to
supply
sufficient
context
when
writing
code
and
tests
equally
improving
the
codebase
is
no
longer
so
much
constrained
by
the
resources
of
a
single
team.
Perhaps
this
is
easiest
to
observe
in
IT
for
IT,
where
the
results,
for
example,
are
used
in
development
pipelines.
A
A
pipeline
originally
defined
for
Java
can
be
extended
to
C++
or
dotnet,
with
a
by
different
teams
with
the
different
set
of
skills
we
want
to
take
advantage
of
the
underlying
pipeline.
The
result
is
a
better
tech
landscape
for
the
whole
organization
and
perhaps
even
provides
training
wheels
towards
full
open
source
contributions.
A
There
are
other
benefits
too,
as
a
developer
works
with
and
understands
a
broader
codebase.
He
or
she
builds
skills
that
are
transferable
to
other
projects.
It
also
helps
to
build
Abnett
work
across
the
bank,
perhaps
the
most,
perhaps
mostly
informally,
but
it
can
also
contribute
to
communities
of
practice
or
guilds
or
whatever.
The
right
set
of
buzzwords
is
in
your
organization.
A
There
is
also
a
set
of
benefits
for
both
the
individual
and
the
organization
in
being
able
to
give
code
back
to
the
open-source
community
now,
obviously,
contributing
fixes
and
improvements
to
the
trunk
benefits.
The
open-source
project
itself,
perhaps
less
obvious,
is
that
we
create
complexity
inside
the
organization.
When
we
don't
contribute
code
changes.
Many
licenses
allow
us
to
adjust
the
code
as
much
as
we
like.
A
Interestingly,
I've
heard
stories
from
other
organizations
who
just
branched
and
developed
and
began
building
their
own
product.
When
two
or
three
years
later,
they've
worked
out
how
to
give
give
back,
they
discovered
their
work
was
effectively
redundant.
The
open-source
version
was
already
straight
ahead
and
the
best
they
could
do
was
work
out
how
to
dump
their
own
code
and
go
back
to
trunk.
That
pain
and
complexity
can
be
avoided.
A
There
is
also
generally
a
benefit
to
the
individual
developer,
who
can
contribute
to
the
public
codebase
if
they
do
a
competent
job,
it
builds
their
reputation.
It's
also
an
opportunity
to
learn
a
variety
of
skills,
both
technical
and
in
dealing
with
distributed
products.
Possibly
large-scale
and
global
transferable
skills
might
sound
like
a
threat,
some
managers,
but
that
transfer
of
skills
and
knowledge
can
benefit
each
of
us
in
our
day
job
as
well.
It
can
also
assist
the
bank's
ability
to
recruit
in
two
different
ways.
A
Firstly,
it
improves
the
ability
of
recruiters
to
learn
who,
on
the
market,
has
similar
skills.
Indeed,
I
recently
heard
a
development
lead
in
an
IT
company,
not
a
bank
saying
that
they
wouldn't
hire
anyone
who
doesn't
have
a
github
account
being
able
to
see
what
someone
who
has
already
done
is
a
great
way
to
reduce
the
amount
of
technical,
interviewing
necessary
and
measuring
their
reputation
in
the
field
becomes
a
lot
simpler.
It's
not
just
about
who
you
know
down
the
pub,
although
that
probably
still
counts
quite
significantly.
A
Secondly,
new
starters
might
well
be
able
to
get
up
to
speed
more
quickly,
based
on
their
familiarity
with
the
technology
in
question.
Of
course,
this
is
always
applied
in
almost
all
recruiting,
I'm
sure
there
are
people
here
who
remember,
maybe
even
have
an
MC
se,
but
actually
being
familiar
with
the
codebase
very
unlikely
without
open
source.
Interestingly,
this
is
also
one
of
the
ways
that
lagging
organized
actions
are
being
pushed
to
use
more
open
source
I
had
a
long
chat
with
the
developer.
A
A
Perhaps
direct
invoice
costs
are
less
obvious,
but
open
source
projects
can
go
out
of
fashion
as
easily
as
a
small
vendor
can
go
to
the
wall
and
in
all
cases
a
security
is
paramount.
A
data
breach
could
lead
to
a
critical
loss
of
trust,
whilst
unintended
sharing
of
code
could
lead
to
a
loss
of
commercial
advantage.